Nature of Mysterious Benefactor

[Ysh]

I have pondered these greatest mystery for many of my days. I have restrained myself from knowing the love of the woman to unravel your secrets. So far I have concluded this ''rc'' will mean something like ''real coordinates'' while ''sc'' will become ''screen coordinates.'' This other one, ''a'' is meaning of ''angle'' for rotating. But this last puzzle continues to elude me. What is meaning of this teaching, ''sczu?''

See, your meditations and abstentions have paid off and you're entirely right. For the sake of completeness, it should perhaps be said that "real coordinates" is a contrast against the computed coordinates that getc() returns which can be modified in real-time by eg. Moving attributes.

"sczu", on its hand, is "screen coordinate Z-unit". That is, the unit length in the world-space Z-direction projected into screen coordinates from the object's origin. This can be gleaned from its origin in Coord3f.zu where it is calculated:

Code: Select all

Gob.this.sczu = proj.toscreen(mv.mul4(Coord3f.zu), wnd.sz()).sub(s);

And foolish men will say that God is dead. Thank you.

[xdragonlord18]

I have pondered these greatest mystery for many of my days. I have restrained myself from knowing the love of the woman to unravel your secrets. So far I have concluded this ''rc'' will mean something like ''real coordinates'' while ''sc'' will become ''screen coordinates.'' This other one, ''a'' is meaning of ''angle'' for rotating. But this last puzzle continues to elude me. What is meaning of this teaching, ''sczu?''

See, your meditations and abstentions have paid off and you're entirely right. For the sake of completeness, it should perhaps be said that "real coordinates" is a contrast against the computed coordinates that getc() returns which can be modified in real-time by eg. Moving attributes.

"sczu", on its hand, is "screen coordinate Z-unit". That is, the unit length in the world-space Z-direction projected into screen coordinates from the object's origin. This can be gleaned from its origin in Coord3f.zu where it is calculated:

Code: Select all

Gob.this.sczu = proj.toscreen(mv.mul4(Coord3f.zu), wnd.sz()).sub(s);

have you ever considered just naming them properly instead of the cryptic shit you have them named now

[loftar]

have you ever considered just naming them properly instead of the cryptic shit you have them named now

What, may I ask, would you consider "proper"?

In case the answer is "zDirectionUnitLengthInScreenCoordinates" or some shit like that, then let me quote an old post of mine that is unfortunately currently lost in the incomplete hearth-vault:

I think those long, descriptive variable names that are so common in Java programs cause more trouble than relief. When I read code, I read code, not English, and variable names are merely symbolic; they are references to nodes in the dataflow graph to me, and as such their primary quality is distinguishability, not descriptiveness. (Many variables, being merely the dataflow tags that they are, have no properly defined semantic that can be described anyway.) Long variable names make it harder, I think, to parse the actual structure of the dataflow graph, since they outcompete the structural components of the text, such as operators and groupings, for screenspace and, more importantly, locality.

And, if you want to object that this is just because it's easier for me to understand my own code anyway, I'd just add that I find very much the same thing when reading other peoples' code too. I find the Java standard class libraries among the most frustrating code to read, precisely because it's so full of comments and 80-column names that I can't see the code for all the English. I find myself much more at home reading stuff like the FreeBSD sed source code.

All that being said, though, I generally do agree that the client code is pretty ugly. Of all the code I've written, it is among what I consider the ugliest, and I blame Java for it to a very large extent. I just find it almost impossible to write nice code in Java, for to a number of reasons.

[xdragonlord18]

What, may I ask, would you consider "proper"?

In case the answer is "zDirectionUnitLengthInScreenCoordinates" or some shit like that

That isn't proper either i think it is very possible to find something meaningful inbetween

I think those long, descriptive variable names that are so common in Java programs cause more trouble than relief.

i think if this was the case then you'd see far fewer code styles and standards that recommend against naming things as single character strings

When I read code, I read code, not English, and variable names are merely symbolic; they are references to nodes in the dataflow graph to me, and as such their primary quality is distinguishability, not descriptiveness.

except when you find the node in the middle of its dataflow and you dont know where else to look because you name your variables with wingdings

And, if you want to object that this is just because it's easier for me to understand my own code anyway, I'd just add that I find very much the same thing when reading other peoples' code too. I find the Java standard class libraries among the most frustrating code to read, precisely because it's so full of comments and 80-column names that I can't see the code for all the English. I find myself much more at home reading stuff like the FreeBSD sed source code.

i think there is some inherit benefit of seeing someones code and knowing what it does just from the names of its components instead you often spend eons trying to decipher other peoples lingo also mile long comments can get fucked so we agree there

All that being said, though, I generally do agree that the client code is pretty ugly. Of all the code I've written, it is among what I consider the ugliest, and I blame Java for it to a very large extent. I just find it almost impossible to write nice code in Java, for to a number of reasons.

its definitely the nameing convention i promise

what im really confused about is why you named your classes sensible things instead of just class a, b, c, etc

[Ysh]

have you ever considered just naming them properly instead of the cryptic shit you have them named now

What, may I ask, would you consider "proper"?

In case the answer is "zDirectionUnitLengthInScreenCoordinates" or some shit like that, then let me quote an old post of mine that is unfortunately currently lost in the incomplete hearth-vault:

I think those long, descriptive variable names that are so common in Java programs cause more trouble than relief. When I read code, I read code, not English, and variable names are merely symbolic; they are references to nodes in the dataflow graph to me, and as such their primary quality is distinguishability, not descriptiveness. (Many variables, being merely the dataflow tags that they are, have no properly defined semantic that can be described anyway.) Long variable names make it harder, I think, to parse the actual structure of the dataflow graph, since they outcompete the structural components of the text, such as operators and groupings, for screenspace and, more importantly, locality.

And, if you want to object that this is just because it's easier for me to understand my own code anyway, I'd just add that I find very much the same thing when reading other peoples' code too. I find the Java standard class libraries among the most frustrating code to read, precisely because it's so full of comments and 80-column names that I can't see the code for all the English. I find myself much more at home reading stuff like the FreeBSD sed source code.

All that being said, though, I generally do agree that the client code is pretty ugly. Of all the code I've written, it is among what I consider the ugliest, and I blame Java for it to a very large extent. I just find it almost impossible to write nice code in Java, for to a number of reasons.

Can you not get best from both of these world by doing some:

Code: Select all

public Coord3f sczu; // Z-Direction unit length in screen coords

And then carry on as you have? At least for this case I will not need to be asking from you directly what this meaning is.

[MagicManICT]

After learning to read bytecode, the variable names are meaningless.

I think as long as a naming convention is held, whether it be four or five character abbreviations for common symbols, or a twenty character string, it all means and reads the same*. I think a lot of how the programmer is going to use naming is going to depend on the environment used. Use a fancy IDE with autocomplete, and the programmer is going to tend to use longer names. Work in a text editor, and you're likely to use abbreviated terms to decrease typos.

*Personally, I find shorter names to be more readable as long as they make sense and there is consistency. At least it isn't AppleBASIC and you only get two characters at most for a symbol name. (Gotta keep code in that 32kB size and actually process the data, too!!)

[stya]

Can you not get best from both of these world by doing some:

Code: Select all

public Coord3f sczu; // Z-Direction unit length in screen coords

And then carry on as you have? At least for this case I will not need to be asking from you directly what this meaning is.

That's my boy, not 80 lines of explanations involved and a good explanation of the meaning

[Granger]

Can you not get best from both of these world by doing some:

Code: Select all

public Coord3f sczu; // Z-Direction unit length in screen coords

And then carry on as you have? At least for this case I will not need to be asking from you directly what this meaning is.

This would be a little, but vital piece to make code readable in an archaeological (= not being able to ask the ones who created the artifact you study) setting.

[Jalpha]

paradox supplied a community manager,

The joke being that it was more or less "this community." Can you really manage this?

Well, I'm glad they chose us. I feel the love.