From when this has come up in the past, it's a lucrative career path, but probably tricky to break in to since nobody's maintaining a COBOL system they can afford to put into the hands of someone inexperienced.

The dudes earning half a million are able to do so because they've been at it since before their boss was born.

[–] Knusper@feddit.de 16 points 11 months ago (1 children)

Yeah, and from what I understand, learning the language itself isn't the hard part. It actually has rather few concepts. What's difficult, is learning how to program a computer correctly without all the abstractions and safety measures that modern languages provide.

Even structured programming had to be added to COBOL in a later revision. That's if/else, loops and similar.

[–] CanadaPlus@lemmy.sdf.org 10 points 11 months ago (1 children)

It seems that back in the day, people effectively ran a simple compiler by hand on paper. It could work pretty well; Roller Coaster Tycoon was famously written in assembly.

[–] rottingleaf@lemmy.zip 1 points 11 months ago (1 children)

Well, I only wrote simple exercises in Intel assembly in uni, but there were more of those with AVR assembly.

You can structure things nicely and understandably if you want.

It's an acquired skill just like many others. Just today writing something big fully in assembly is not in demand, so that skill can usually be encountered among embedded engineers or something like that.

[–] CanadaPlus@lemmy.sdf.org 1 points 11 months ago (1 children)

Is there a tutorial you could recommend? I'm actually pretty curious how exactly you would go about that now.

[–] rottingleaf@lemmy.zip 2 points 11 months ago* (last edited 11 months ago)

Sorry, I don't remember what I used then as a tutorial, possibly nothing, and I don't write assembly often, it was just an opinion based on the experience from the beginning of my comment. That said:

You have call and return, so you can use procedures with return. You have compare and conditional jump instructions. And you have timers and interrupts for scheduling. That allows for basic structure.

You split your program functionally into many files (say, one per procedure) and include those. That allows for basic complexity management.

To use OS syscalls you need to look for the relevant OS ABI reference, but it's not hard.

So all the usual. Similar to the dumber way of using C.

In general writing (EDIT: whole programs, it's used all the time in codecs and other DSP, at the very least) in assembly languages is unpopular not because it's hard, but because it's very slow.