4 ms·
I messed around with it, thinking it seemed interesting and could be useful to know Just-In-Case. One thing I didn't get, until I started messing with it, is th
by deaddodo 3y ago
I messed around with it, thinking it seemed interesting and could be useful to know Just-In-Case. One thing I didn't get, until I started messing with it, is that COBOL isn't a general purpose language. There's a whole category of things it just can't do, and if you ask about it you'll just be told "COBOL isn't C". There's another set of things it's really effective at, primarily transactions and large iterations.
Mess around with it if you want, sure. Just realize it's a limited language with specific use cases and you're unlikely to ever touch it outside of those, even as a hobby/"for fun".
- pixl97 3y agoYa, transactional processing of what I would consider simple and well defined data it's what typically occurs with cobol at financial institutions. In this context the code has been around forever and all the 'Oops we lost your money' bugs have generally been purged from it'.
- whartung 3y agoCurious what the limitations were. Anecdotally I was talking with a COBOL vendor way back in the mid-80s and he had mentioned that their COBOL compiler was itself written in COBOL. FORTRAN also suffered limitations back in the day, notably lack of dynamic memory, yet folks were able to write sophisticated systems in it as well.
- deaddodo 3y agoIt lacks a whole slew of things you would expect in a GP language, or requires you to jump through massive hoops to achieve the same results. Imagine trying to program a desktop application in SQL. You could probably achieve it through some use of triggers and interfaces, but it would be a nightmare. It's not quite as bad for COBOL, but a similar story.
- sreeramvenkat 3y agoIIRC it doesn't have a stack. So all variables are globals. There is no way to call a function with a parameter - to be accurate, there are only subroutines; no functions.