Other Do you want to learn 12 or just 8 programming languages next year?

[mer]

Classroom teaching and passing exams gives you some initial familiarity, but you really need to work on a real project or two that you can get your teeth stuck into, to learn much about programming; that's when it starts to "sink in". Best of all is to work in a team of other good people with different levels of experience and expertise, and learn from each other by doing real work solving complex problems. Of course this isn't unusual or unique to programming, most acquired skills work like this.

Agree 100% (or more if I can). The best way for me to learn something is to have a need. Work, writing code? Requirements, what language? I'll do more than learn syntax. My best work/team stuff was me doing technical lead (system engineer) others implementing in a language I had minimal exposure to. I learned syntax so I could understand stuff for code reviews but that let me be more effective in telling the team "this is what the code needs to do"

And yes it's not unique to programming. I would toss out "try cooking a family recipe with grandma watching" (yes I can sautee onions but....)

 

[PMc]

I am sad to hear that.

Na, me not. More or less it worked out, and where I really didn't get what I wanted, that was in a different realm.

I just had hoped that in my later days I could still do some consulting, for fun and to have entertainment.
But maybe that is not my destiny. Maybe I should rather do "Foundation": prepare the civilisation for the coming dark age.

 

[cracauer@]

I don't know how others feel, but for me another obstacle is that many marketable languages are not fun.

C++ is huge and grows every 3 years by a degree that I disapprove of. But at least it has a sane library mechanism - just stuff everything into Boost. And plain C libraries for interfacing to things. And direct access to all of Posix' C interface. Works for me.

Rust is supposed to be hard to code for, especially protoityping and it has a package mechanism that many disapprove of. And no POSIX access. The way I read AARs Rust doesn't allow a prototype and forces much of production quality before anything runs. I am not sure that is what I want all the time.

Golang looks like more fun, though. Very large standard library, so less exposure to random packages on the market. Stupid name, though, you can't google "go".

 

[blackbird9]

Golang (I hate that) looks more like a real evolution from C than the others, and comes from the same stable. It does look more fun. I guess google must have thrown some money their way which is why "Go", but it's s silly name. I suppose 'D' was already taken...

C++ isn't my idea of fun. I haven't looked into rust in any depth yet so I'll suspend judgement until I find the time to have a look at it, but it has a lousy rep from what I've heard so far.

 

[drhowarddrfine]

Golang looks like more fun, though. Very large standard library, so less exposure to random packages on the market.

Well, of course! Consider who created it (as a Unix/C lover).

 

[bgavin]

I've gotten more than a few snickers over the decades about my writing style.

First and foremost, I write for clarity and ease of reading.
The compiler doesn't care at all, and produces the same output.

Back in the 80s, I wrote the fastest file finder on the planet for MSDOS, all in Assember.
It used every shitty trick in the book, such as self-modifying code at runtime.
I needed extra registers so I dipped into using the 8087 for this.
I loaded my own copy of the file allocation table into RAM for faster access than constantly going to disk.

Fortunately, my writing style was very clear, and every line heavily commented.
I looked at that code some 40 years later, and thought "WTF was I thinking..."
It would be impossible for me (in my old age) to read it, without that clarity.

 

[blackbird9]

Candidate : "Excuse me, how do Hilbert space and eigenstates fit into a programming job?"
HR : "Our web stack is written in Perl."
Candidate : "Understandable. I have no further questions."

We had a guy join our test team years ago who had just done a PhD in string theory. I don't think his string theory helped him much in his new test job, but he said it paid better than being a physicist.

 

[lgrant]

That's the number coming out of a survey:

https://survey.stackoverflow.co/2024/technology#3-programming-scripting-and-markup-languages

Those learning to code want to try more languages
next year compared to their professional counterparts.
On average, each user who is learning to code wants
to try 12 other languages in the next year versus users
who are professional devs who want to try eight.

I mean... As far as I can tell I learned an above average number of languages (slowed down by rising complexity of C++ mainly). But this is just nuatz. And of course many of these people also call themselves "full-stack" developers, which would require input bandwidth way out of proportion.

I used to work for an IBM mainframe shop that used assembly language for everything. Part of this was because some of the code had to work closely with the operating system, but a lot of it was inertia. About a year before I retired, they company decided to start using METAL C, an embedded C for the mainframe that had a minimal runtime, and could run in authorized state (unlike regular C).

One of my coworkers said "I retire in seven years. I'm not learning a new language."

I was kind of amazed, since I learn new languages all the time, whenever they are needed for some project. Most of these guys were in their 50s or 60s, had been coding assembler their whole lives, and had no interest in learning anything new.

 

[lgrant]

I've gotten more than a few snickers over the decades about my writing style.

First and foremost, I write for clarity and ease of reading.
The compiler doesn't care at all, and produces the same output.

Back in the 80s, I wrote the fastest file finder on the planet for MSDOS, all in Assember.
It used every shitty trick in the book, such as self-modifying code at runtime.
I needed extra registers so I dipped into using the 8087 for this.
I loaded my own copy of the file allocation table into RAM for faster access than constantly going to disk.

Fortunately, my writing style was very clear, and every line heavily commented.
I looked at that code some 40 years later, and thought "WTF was I thinking..."
It would be impossible for me (in my old age) to read it, without that clarity.

Good comments FTW. More than once in my career, I have looked at code I wrote a year or two ago, and said, "What was I thinking? This code is all wrong.", then, just as I was finishing up fixing it, remembered why I wrote it that way.

It only took me a couple episodes like that to start leaving good comments about anything weird. Sometimes you have to do stuff that does not align with the current Best Practices. A comment explaining what the issue was, and why you had to deviate works wonders.

I always try to be kind to the next person who will be looking at my code, especially since the next person is frequently a slightly-older me.

 

[mer]

Ahh comments. Some "styles" think you need a comment for every line, which leads to comments like "increment X" for a line like X++.
I've always commented heavily for the sections that took me way too long to figure out because I know I'm revisiting this in the future.

Good comments are priceless, bad comments make you miss the good ones.

 

[bgavin]

When writing ASM it is often helpful to leave a comment about INC ECX as to “why”

I use symbolic names instead of displacements for index registers because they are more intelligible.

Mov AX, ESI [cTagOffset]
Mov AX, ESI [0]

These are self commenting

 

[mer]

When writing ASM it is often helpful to leave a comment about INC ECX as to “why”

I use symbolic names instead of displacements for index registers because they are more intelligible.

Mov AX, ESI [cTagOffset]
Mov AX, ESI [0]

These are self commenting

ASM is a special case (in my opinion) because of "registers". A comment that hints "at this point in the code this register has a value that points to that thing over there in memory" is drastically different from a comment in C saying "increment X".
Symbolic names are (almost) self commenting.

 

[doul]

Three comment maturity levels :​

1. Describe what the code does (beginner)
2. Explain the logic’s purpose (intermediate)
3. Refactor code so comments are often unnecessary (advanced)

Useless :

timeout = 1000; // set timeout to 1000

bettrer :

if(x < 42) // 42 is the max sensor reading before overflow

No comment needed :

modules[driver_ID].status = MODULES_DRIVER_STATUS_DEFAULT;

 

[drhowarddrfine]

I needed extra registers so I dipped into using the 8087 for this.

That was the cool thing about the 68K processor. Lots of registers. And that reminded me of a meeting I had with a programmer at work years ago.

I was developing the hardware--a standalone computer with a real time operating system--and my good friend, Gideon, was writing the application and hardware interface software in assembly. Gideon spoke very good English but sometimes there were still misunderstandings.

One week, he came in and asked me about all those registers I told him the 68000 had. "So I can have eight registers to do X?" he asked. "Sure," I said. "Well can I have eight for doing Y?" to which I gave an affirmation.

These question went on for several days and I couldn't understand why Gideon was so excited but the questions stopped and he went plugging along writing his code.

Then, one day, I found out Gideon thought these were all unique registers to hold unique values at the same time! He was up to something over 68 registers for different tasks and all his mixed C and assembly code was based on that!

Gideon was a pretty smart guy but you would never know it based on that story.

 

[lgrant]

I've gotten more than a few snickers over the decades about my writing style.

First and foremost, I write for clarity and ease of reading.
The compiler doesn't care at all, and produces the same output.

Back in the 80s, I wrote the fastest file finder on the planet for MSDOS, all in Assember.
It used every shitty trick in the book, such as self-modifying code at runtime.
I needed extra registers so I dipped into using the 8087 for this.
I loaded my own copy of the file allocation table into RAM for faster access than constantly going to disk.

Fortunately, my writing style was very clear, and every line heavily commented.
I looked at that code some 40 years later, and thought "WTF was I thinking..."
It would be impossible for me (in my old age) to read it, without that clarity.

I have sometimes had the experience of looking at very complicated (and well documented) code that I wrote several years ago, and thinking "Wow, I used to be a lot smarter back then." (Usually it's just that I was much more engaged in that particular problem at the time.)

 

[Crivens]

Converting between big and small endian is a breeze in ASM.

Xchg AH, AL
ROR EAX,16
Xchg AH,AL

assign data_swapped = {{data[07:00]},
{data[15:08]},
{data[23:16]},
{data[31:24]}};

Runtime: 0
Sorry, couldn't resist.

 

[Maturin]

Good comments are priceless, bad comments make you miss the good ones.

To write good comments is an art of it's own.
When I programmed in assembler - which is a "language" that teaches you to document your code - I started on writing the comments first, before I even dropped a single line of code.
Prose: What I'm going to, my ideas about how I'm going to do it, and maybe some core details about the algorithm.

The theory is to write as close to the details you could just replace the text by code. That of course don't really work, neither is it recommendable to do so, because it's by far too inefficient. You are versed about a language you're coding in. So you need to compromise reasonably. But doing it parallel: review and update comments, documentation, and the code parallely not only saves the tedious job of doing the comments afterwards - they are already done - but produces better comments, and better code, I think. Because you rethink the code more, and additionally in natural language. And I have the feeling you produce code even faster. But since I am no pro, pros may tell you otherwise.

I also learned another lesson myself:
Get some code of your own! Something you wrote just a few years ago. Then try to understand what you did yourself. This can be an eye opener (at least to me it was.)

I love this Master Foo and the Programming Prodigy about it. (I love all "Master Foo's")

 

[cracauer@]

To write good comments is an art of it's own.

The worst things happen when you force somebody to add comments who is just not suitable to imagine what other people need for comments.

 

[Espionage724]

Get some code of your own! Something you wrote just a few years ago. Then try to understand what you did yourself. This can be an eye opener (at least to me it was.)

I was looking into small web browsers again and needed to check the man page for a refresher as to what all this did (still worked from a year ago)

surf -a 'a' -b -D -f -g -I -k -m -n -S -t -x 'http://localhost:8888'

 

[Maturin]

I was looking into small web browsers again and needed to check the man page for a refresher as to what all this did

Nah, that doesn't really count. I wasn't talking about markup languages, nor shell commands with lots of options.
But if you used that in a script, you now learned better had commented that in the first place.

 

[drhowarddrfine]

This is kind of related regarding commenting or understanding code: Learning to read Arthur Whitney's C

 

[Maturin]

Thanks, drhowarddrfine very interesting in deed.

This discussion is as old as programming languages themselves. And for sure I don't want to start it again.
As far as I can say, there is no silver bullet.
An infinite number of improvements are possible, but perfection cannot be reached.

One has to differ between if you're working alone, or in a team. And in a team you have to follow their guidelines - doesn't matter if you agree, if they are right, or wrong. Because starting a discussion on it while a project runs will only bring a lot of disturbance, lower productivity, and anyway will not bring up the silver bullet. (I excluded projects which guidelines really needed to be revised. But those often have other, more urgent issues than just their guidelines. [Don't ask! I will not name any. It's my very personal opinion. And I don't want to start any brawls.])

Programmers simply hate to document their own code. IMO many don't see the need for it, because they understand it themselves - when they just wrote it. And I know from myself: When the shit finally runs, the need for documenting it afterwards is just Right? That's why I said in my former post to start with it, and do it parallel to the coding.
And while programmers are good at coding, writing prose, especially about code, is a complete other challenge, but also needed, and can be learned. And you can put only the form into guidelines, not the thinking.
But that's no reason for not doing it at all, nor for refuse to improve it.
While that's clear to me, I know there are many now want, and will contradict:
Writing documentation about the code has at least the same importance as coding itself.

"Would you rather spend 10 days reading 100,000 lines of code, or 4 days reading 1000?" is a very good point.
My (very personal) opinion is: The claim to prefer easy to read code over efficient code is attributable to the fact that it's almost impossible to bring programmers to f###ing document their f###ing code. So, when in any case there will be no useful documentation, or none at all, anyway - well, then the code has to be written as easy to read as possible.
There are high-flyers like Arthur Whitney, who can comprehend even weird code by just reading it and don't need no documentation at all.
But I dare say those ain't the majority.
And to refuse to document the code and accuse others just being too stupid to comprehend it without any documentation, does not make one a high-flyer!

To me:
When it improves efficiency I am pro weird looking code - IF it's documented well, so explained.
Personally I prefer having two, or three lines of weird looking code, and fifty, sixty lines of comment, explaining it.
But that's the point: There are no fifty lines explaining it. Well, in my personal stuff there is. But that is not conform to any guideline I know. Most of the times there is nothing, explaining nothing, just the code only.

With someone who's versed in the language comments are not needed for large parts, would only trash up the place, lowering readability instead of increasing the understanding of the code. And better having no comments at all, then confusing ones. I fully agree. (Texteditors provide the possibility to blind out comments, if they are too distracting.)
Anybody did some more coding a bit beyond beginners classes knows:
Sometimes there are situations you have to do "weird things".
The reason may be often you simply won't come up with a better idea. But at least to me it seems, sometimes there actually is no other way than doing it weird. Those parts need to be documented - well!
A well commented code is always faster to comprehend, than a code that's completely undocumented.
Because you don't need to reconstruct from the code what it's doing, and then guess what the thoughts were the writer had why doing it this way. You get the ideas first, and then see how the code fits into that.
There are situations you look at some one elses code and think:"This idiot wrote some pretty crap here!" While I exclude real idiot's crap there are situations where the writer was no idiot at all, but had very good reasons to do it that way. What you may find out a lot later, when you are trying to rewrite this part better, but the shit simply ain't work otherwise than as it was written originally.
Because the author was no idiot at all.
She or he simply did not shared his ideas, thoughts, reasons, and conclusions.

 

[cracauer@]

I know people, and more than a few, who would remove comments from codebases based on "they could become outdated" to "I look cool when my diffs remove more lines than they add". Absolutely disgusting, but some companies' reward system creates favorable conditions for this.

Same for #ifdef'ed / #+nil'ed outed piece of debug code that the original author of the code left. People nuke them when they don't compile anymore for trivial to fix reasons, never mind that they are still very valuable insights into what matters to look at in that area of code. They are very valuable documentation.

 

[blackbird9]

I hate it when you put a load of debug code in with #ifdef's, go back a couple of years later and some idiot has deleted it... Even when I actually said something like :-
#ifdef DEBUG ...

"It wasn't being compiled so we got rid of it as part of the cleanup".

 

[blackbird9]

This is kind of related regarding commenting or understanding code: Learning to read Arthur Whitney's C

I always wondered if guys like that really write the code that way for their own consumption. Or whether they have their own private version with proper readable names so they know what's going on, and a sed script they run over it to replace those readable names with 's', 'f', 'fx', 'a', 'aa', etc before they show the code to anyone else.. . There used to be commercial source code obfuscators you could buy that would try to make your code unreadable by changing all the variable and function names etc. Yeah, I guess I'm just a cynic, surely he wouldn't do something like that, no, the guy must be a genius...