Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
I am a professional software engineer. My favorite ecosystem is the Java one which may explain some things.
Why is verbosity such a bad thing? Especially in the context of maintaining something someone else wrote? I would much rather maintain old Java than say, old Perl. I want big long names. So I have a better idea of what they were for! I can pretty much read any line of Java from anywhere and have a very good idea what it’s actually doing.
Sure, it’s more of a pain to type but as a kid one of the best investments I made in myself was to take a typing class. I did this way before I discovered my passion for programming. I can type fast. And I can make my editors type boilerplate for me.
Edit: Give me the time to learn it (I’m confident I can learn it fast) and the ability to work remotely and I would jump at the chance. I can do the fun programming (in Java) in my spare time.
oh the names aren’t long. cobol has keyword alternatives for all operators and all numbers up to 20. since the language was designed for non-programmers, code in the wild follows no paradigm and mixes these alternatives freely. names are usually kept as short as possible.
there’s also a lot of boilerplate required for each file wrt the actual structure of the sections, assembly style. sure most of this can be automated with tooling but there’s no tooling available. the cobol people have mainly worked in their own sphere and not been included in the tooling explosion of the last 15 years.
What would scare me the most is the bad tooling. I do rely on my tools to search for references, etc. I wonder if it’s even possible to write a good analyzer for COBOL. Verbose operators and literals wouldn’t scare me at all.
Still would jump at the chance. It would have to be remote and I would strongly prefer being the only engineer touching the code.
you’re not going to get a position remote if your client is a bank or some other entity that does cobol. that shit is running on an airgapped machine running a vm of a machine from the 90s running a vm of a machine from the 70s. if you’re really unlucky the source will be on punch cards because they didn’t invest in a machine with storage and asked the VM developers for the same workflow as before
I am a professional software engineer. My favorite ecosystem is the Java one which may explain some things.
Why is verbosity such a bad thing? Especially in the context of maintaining something someone else wrote? I would much rather maintain old Java than say, old Perl. I want big long names. So I have a better idea of what they were for! I can pretty much read any line of Java from anywhere and have a very good idea what it’s actually doing.
Sure, it’s more of a pain to type but as a kid one of the best investments I made in myself was to take a typing class. I did this way before I discovered my passion for programming. I can type fast. And I can make my editors type boilerplate for me.
Edit: Give me the time to learn it (I’m confident I can learn it fast) and the ability to work remotely and I would jump at the chance. I can do the fun programming (in Java) in my spare time.
oh the names aren’t long. cobol has keyword alternatives for all operators and all numbers up to 20. since the language was designed for non-programmers, code in the wild follows no paradigm and mixes these alternatives freely. names are usually kept as short as possible.
there’s also a lot of boilerplate required for each file wrt the actual structure of the sections, assembly style. sure most of this can be automated with tooling but there’s no tooling available. the cobol people have mainly worked in their own sphere and not been included in the tooling explosion of the last 15 years.
here’s an example of some well-written cobol. most of it is nowhere close to this consistent, or source-controlled for that matter.
What would scare me the most is the bad tooling. I do rely on my tools to search for references, etc. I wonder if it’s even possible to write a good analyzer for COBOL. Verbose operators and literals wouldn’t scare me at all.
Still would jump at the chance. It would have to be remote and I would strongly prefer being the only engineer touching the code.
you’re not going to get a position remote if your client is a bank or some other entity that does cobol. that shit is running on an airgapped machine running a vm of a machine from the 90s running a vm of a machine from the 70s. if you’re really unlucky the source will be on punch cards because they didn’t invest in a machine with storage and asked the VM developers for the same workflow as before
True most COBOL is in person only. At least from what Ive seen. Big detriment but most systems are on physical computers…so gl!