800

Not mocking cobol devs but yall are severely underpaid for keeping fintech alive (lemmy.world)

submitted 11 months ago by Potatos_are_not_friends@lemmy.world to c/programmer_humor@programming.dev

150 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] affiliate@lemmy.world 31 points 11 months ago

what i’m gathering from this thread is that i should learn cobol

[-] CanadaPlus@lemmy.sdf.org 23 points 11 months ago* (last edited 11 months ago)

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

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

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

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

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.

[-] pomodoro_longbreak@sh.itjust.works 10 points 11 months ago

Once you get into it you'll wonder how you ever programmed without "divisions"! I mean honestly, just declaring variables anywhere? Who needs that. Give me a nice, defined data division any day 😌