Flatfingers wrote:
I have no idea what programming language engineers are taught these days. Whatever it is, I'll bet they still aren't required to take a Data Structures class.

For me, the answer to the former is Python and FORTRAN, bizarrely, and both were for explicitly numerical purposes. To the latter, to quote Paul Atreides, "That's a wager you'd win" because I can't pass up a Dune opportunity.

If it's any consolation, the codes I use that have large portions written by actual computer scientists are incomprehensible... while my fellow computational scientists have clearly a lot of sense because in their parts of the codebase the code is obvious

I guess I should add that I know there are CS grads who've learned some arcane new paradigm and sniff that the code of anyone who doesn't use it is obviously "wrong."

That's never been me.

I believe that the vast majority of programs ought to be written simply, with clarity prioritized over theory or cleverness or elegance. If high performance is required, get it through proper algorithm design if possible; otherwise comment the heck out of it.

That said, there are more appropriate data structures for some purposes than the array.

I am so much like you in this, Flatfingers, it makes me near-giddy. Most people I've talked to go crazy over elegance, but I've never seen the point. I prefer to go with "what works" rather than "what's flashy" - after all, nobody's going to see your code in the finished product. The outcome is what matters.

I'm glad you guys say this, top answers on stackexchange usually drive me nuts because they're 'clever' and 'obviously the best way'

i should also add that the reason the aforementioned code is incomprehensible to me is because it is legitimately trying to do some very tricky data handling in what has to be an absolutely memory-efficient way, and it kind of ends up being necessarily labyrinthine anyway

That being said the comments are still the annoying kind of "declare the GAB object" right above a statement clearly declaring a GAB object, and no one ever says what a GAB object actually is but I know it's bloody important

Right on, gents. But now that you bring up these points, I hope one more comment is OK.

Talvieno wrote:I prefer to go with "what works" rather than "what's flashy" - after all, nobody's going to see your code in the finished product. The outcome is what matters.

This has the right spirit in the sense that when you're writing code for a customer, they care about functionality: Does it do what it has to do? Is how to use it clear?

That agreed to, I actually emphasize code clarity in a regular production environment to promote good code maintenance. In that setting, it is wrong to write code that other people -- including normal human beings who know how to program -- can't understand. This clarity is needed for multiple reasons: peer review, backup support in case the primary developer gets hit by a bus, and long-term maintenance and enhancement.

I consider this a customer service requirement.

Scytale wrote:I'm glad you guys say this, top answers on stackexchange usually drive me nuts because they're 'clever' and 'obviously the best way'

I cannot stop my eyes from rolling at how many useful answers on StackExchange are followed by "that is obviously incorrect; do you even know how to code?"-style responses.

It has to be admitted that, sometimes, they're right. I've seen a lot of initial suggestions that weren't quite right, even if they get the person who asked the question going in the right direction (which is the most important thing). I just wish the clarification responses didn't come laden with so much Attitude.

I've also seen some great responses from people who've actually read the applicable standards documents, who deeply understand them, and who are good at explaining how to apply them. Interestingly, when these respondents provide a correction, they're usually pretty decent about it, or at least not insulting.

Scytale wrote:i should also add that the reason the aforementioned code is incomprehensible to me is because it is legitimately trying to do some very tricky data handling in what has to be an absolutely memory-efficient way, and it kind of ends up being necessarily labyrinthine anyway

Understood. This sort of thing does exist, and it's why I was careful to qualify my previous comment by referring to "the vast majority of programs."

There are cases in which the prioritization changes so that clarity is not so clearly the most important thing:

games whose core code will only ever be seen by a single gifted programmer

I do consider these the exceptions, though.

Scytale wrote:That being said the comments are still the annoying kind of "declare the GAB object" right above a statement clearly declaring a GAB object, and no one ever says what a GAB object actually is but I know it's bloody important

Commenting style always seems to have a lot to do with the personality of the developer. Unless you're willing and able to stand over their shoulder while they code, at some point you have to rely on them to follow a coding standard (whether they like it or not... and it's almost always "not").

At that point, either they naturally "get it" -- that the meaning of the comment needs to be one level up from the text of the code itself -- or they never will, and it will be an ongoing fight that ends only when one of you retires or gets a different job. (Of course there also usually needs to be explanatory text more than one level above the code, but that should probably be handled in requirements and design docs.)

Finally, I want to be sure I'm not dissing Josh by my comments about "elegance." Knuth's admonition that "premature optimization is the root of all evil" is a good warning about the value of one's time. I mention it because I think a quest for ever-increasing elegance can have the same effect. The value of optimizing code, when it's running well enough, before the whole program is basically feature-complete is not zero, but it's pretty close because at any time, that code might go away completely due to an algorithm change. At that point all the sweat that went into making those lines of code performant or elegant was for nearly nothing. "Nearly" because all coding teaches better coding... but the real point was to produce working software, and you're not doing that if you're spending hours or days shaving off milliseconds on non-core loops or working out the simplest conceivable common format for similar functions.

All that said, Josh's needs for LT are a little different than those of most programmers. For him, elegance seems to have more value because it lets him see a large amount of code in a normalized format. By pushing the "meaning" of code into how that code is structured, he can understand more code. That actually is useful because he's the only developer.

So when I'm banging on about how seeking elegance is dangerous, I'm talking about coding in a typical multi-developer business setting.

Flatfingers wrote:It used to be I could always tell who had gotten a degree as an engineer of some kind (usually electrical but sometimes mechanical).

If their engineering had any connection to computers, they learned FORTRAN. After that, the only data structure they used in any code they ever wrote -- which computer science geeks like me had to figure out and maintain -- was the array.

Should I feel bad because I'm an engineer and never heard about FORTRAN?

Talvieno wrote:I am so much like you in this, Flatfingers, it makes me near-giddy. Most people I've talked to go crazy over elegance, but I've never seen the point. I prefer to go with "what works" rather than "what's flashy" - after all, nobody's going to see your code in the finished product. The outcome is what matters.

Well, as Flat said, this is a good temporary approach. If you just want to test out what works or might work, do it "quick and dirty", meaning as long as it works it doesn't matter how it looks. But it's important that you rewrite this code as soon as you have tested it and it works.
Don't use too much time on code design when testing stuff, but don't forget to apply proper design after you have tested it.

Flatfingers wrote:
Commenting style always seems to have a lot to do with the personality of the developer. Unless you're willing and able to stand over their shoulder while they code, at some point you have to rely on them to follow a coding standard (whether they like it or not... and it's almost always "not").

At that point, either they naturally "get it" -- that the meaning of the comment needs to be one level up from the text of the code itself -- or they never will, and it will be an ongoing fight that ends only when one of you retires or gets a different job. (Of course there also usually needs to be explanatory text more than one level above the code, but that should probably be handled in requirements and design docs.)

Oh god. Commenting. I am so bad at commenting. I never know what to write. I just write stuff like "loop depending on state of xy, used for incrementing var xz based on size of integer yz". I think I never really listened when we got thought how to comment on stuff, because I wanted to code, and not comment.

JanB1 wrote:Should I feel bad because I'm an engineer and never heard about FORTRAN?

Yes, yes you should.

JanB1 wrote:Oh god. Commenting. I am so bad at commenting. I never know what to write. I just write stuff like "loop depending on state of xy, used for incrementing var xz based on size of integer yz". I think I never really listened when we got thought how to comment on stuff, because I wanted to code, and not comment.

Real coders abuse their audience when writing comments, because anyone reading it is about to break it.

JanB1 wrote:Should I feel bad because I'm an engineer and never heard about FORTRAN?

Yes, yes you should.

Well, would you be so kind to enlighten me then why this is so important to me and how I could benefit from learning this programming language?

Silverware wrote:

JanB1 wrote:Oh god. Commenting. I am so bad at commenting. I never know what to write. I just write stuff like "loop depending on state of xy, used for incrementing var xz based on size of integer yz". I think I never really listened when we got thought how to comment on stuff, because I wanted to code, and not comment.

Real coders abuse their audience when writing comments, because anyone reading it is about to break it.

Hmm...sounds about right. Now I have found an excuse to why I will not comment on things. Just gotta make sure I will not get confused by my own code if I have to work on it again after a few months.

JanB1 wrote:Should I feel bad because I'm an engineer and never heard about FORTRAN?

Yes, yes you should.

Well, would you be so kind to enlighten me then why this is so important to me and how I could benefit from learning this programming language?

Silverware wrote:

JanB1 wrote:Oh god. Commenting. I am so bad at commenting. I never know what to write. I just write stuff like "loop depending on state of xy, used for incrementing var xz based on size of integer yz". I think I never really listened when we got thought how to comment on stuff, because I wanted to code, and not comment.

Real coders abuse their audience when writing comments, because anyone reading it is about to break it.

Hmm...sounds about right. Now I have found an excuse to why I will not comment on things. Just gotta make sure I will not get confused by my own code if I have to work on it again after a few months.

Oh there is !!absolutely!! no reason to learn Fortran, just knowing about it's existance is enough. Same with COBOL and a few others.