Scientists still use Greek, lawyers still use Latin.
Romance language users will use both at the same time to create new terms.
COBOL has been “dead” for so long, my grandpa wrote about it
321–330 of 448 posts
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#322I think many would dispute that its dead.
Apparently more than 95% of ATM swipes and 43% of banking systems are written in COBOL. No idea how true that is.
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#323Re: COBOL has been “dead” for so long, my grandpa wrote about it
#324Earlier quoted context omitted.
4GL were supposed to be even more of that, with more "human-language-like" constructs added to the language to deal with things besides general logic, simple data structures and arithmetic. The author mentions "4GLs" were all the rage in the early 1990s, but I doubt that that was true outside of the mainframe world. The 4GL movement, as a conscious movement, seems to have always been highly mainframe oriented (the Wi…
dBase and its numerous descendants and competitors (FoxPro, Clipper etc) were extremely popular for line-of-business desktop applications in the 90s. And, yes, they are indeed traditionally categorized as 4GLs - and, given how nebulous the definition always has been anyway, I think that "traditionally categorized" is the most practical definition that you can use here. But, yes, I agree that aside from the generally…
That class of software also allowed for very efficient data capture against normalised tables. A recall as early as Paradox for DOS (something I haven't thought of for a while) in about 1990 being really simple tools for creating one-to-many database capture 'forms' (with selection boxes, date drop downs, the lot). The richness of form design and tight coupling to the database meant that the language did not need to be very powerful and could just run as a script on top of a rich database environment. The PC-based successor to mainframe 4GL concepts was late-nineties RAD (Rapid Application Development) of Delphi and VB. MS Access was the Windows successor to those tools and was wildly successful as a way for 'business people' to build apps. It took many years for windows low-level app development or the web to catch up to the richness, but they have never really achieved the same level of non-programmer usability.
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#325Earlier quoted context omitted.
In my experience, often it’s hard to find that person with deep domain knowledge, and even when they do, it’s unstructured, they take things for granted they shouldn’t* and the have no appreciation of the demands of formalism. Getting anything you can use to construct a work plan, never mind a detailed feature list, out of clients can be a dark art. *To the point I have repeatedly experienced a point close to the end…
I recall a spec doc from a domain expert that said something like: "The transaction consists of a credit stub and a debit stub. If the debit stub is missing and is of type X then we do A and if it is of type Y then we do B." How to know what flavour the missing item was? Absolutely no mention of that...
It's interesting that domain experts all exhibit the same cognitive issue - their assumptions are just so ingrained that they cannot articulate it at all.
The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X.
But that fact might not ever be recorded in the computer system, in a way that the old business process would've had a record of.
And this is just one small example - imagine something more complex!
So realistically, the job of a programmer is to force an expert to articulate all of their assumptions. IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do.
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#326Earlier quoted context omitted.
>A bit like writing enchantments to force demons to do your bidding. But without the cool chanting and poetic language; just like cyberpunk was realized without the vivid imagery and neon lights :(
> just like cyberpunk was realized without the vivid imagery and neon lights :( The 21st century never ceases to disappoint. It’s a cheap, low budget and dystopian version of what we imagined.
To be fair, what we imagined was dystopian, too. It's just that some people with a lot of ambition and not much media literacy didn't realize it was dystopian, and set about to build that future.
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#327Earlier quoted context omitted.
dBase and its numerous descendants and competitors (FoxPro, Clipper etc) were extremely popular for line-of-business desktop applications in the 90s. And, yes, they are indeed traditionally categorized as 4GLs - and, given how nebulous the definition always has been anyway, I think that "traditionally categorized" is the most practical definition that you can use here. But, yes, I agree that aside from the generally…
Gosh it's a long time since I heard 'Clipper' mentioned. I used to do 'PC' apps for Banks in the early 90s. Turbo Pascal and Clipper were popular with us. (We used PL/1 rather than COBOL for batch processing) Then VB 4.0 started to get popular around 1996 and ruled the roost... So many technologies... does anyone remember 'SUPRA' from that era! (think it was supposed to be a 4GL language/interface for mainframe datab…
Sigh I work at a company that not long ago added support for applications written to use SUPRA to their portfolio. It's not dead yet, there are companies out there still running it in production and willing to spend money to replace it, while keeping their business logic.
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#328COBOL is not dead, but it's difficult to get access to, because there is almost no open-source tooling around it for Linux. We (OCamlPro) have created a project, called SuperBOL, to create an open-source environment around the GnuCOBOL open-source compiler (that is now very mature and used by companies). We have already released the VScode extension with an LSP for COBOL to get a modern IDE, and we are working on oth…
What about https://gnucobol.sourceforge.io/ https://cobolworx.com/pages/cobforgcc.html
We are among the major contributors to GnuCOBOL, we use https://github.com/OCamlPro/gnucobol to review our contributions before pushing them on the SVN of Sourceforge.
Cobolworx is indeed working on a gcc frontend for COBOL. It's an impressive work (that was presented at FOSDEM this year), but less mature than GnuCOBOL, and tied to gcc, whereas GnuCOBOL can work with any C compiler (llvm, msvc, etc.) by translating COBOL to C.
Though we desig SuperBOL to work with GnuCOBOL, it could also be used with GCOBOL when it will be officially stable.
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#329COBOL is not dead, but it's difficult to get access to, because there is almost no open-source tooling around it for Linux. We (OCamlPro) have created a project, called SuperBOL, to create an open-source environment around the GnuCOBOL open-source compiler (that is now very mature and used by companies). We have already released the VScode extension with an LSP for COBOL to get a modern IDE, and we are working on oth…
The problem is not so much access to tooling, but access to mainframes. I can learn COBOL in a day or two, and I would love to work on a "boring" COBOL job, but I have no experience with mainframes.
The goal of SuperBOL (https://superbol.eu) is to allow companies to migrate from mainframes to Linux workstations, to get a "modern" experience of development and deployment.
Indeed, mainframes are hard to get access to, and require a training by themselves, I have worked on Linux and Windows for years, and development on a Mainframe has nothing in common :-)
I think the problem of COBOL is not only the lack of COBOL developers, it is the lack of expertise in COBOL environments, because they have become obsolete (both on mainframe and proprietary tooling for Linux/Windows). By providing a modern environment on Linux for COBOL, our goal is to solve the hardest part of the problem, as learning COBOL itself is not so hard for existing open-source developers...
Re: COBOL has been “dead” for so long, my grandpa wrote about it
#330Earlier quoted context omitted.
The problem is not so much access to tooling, but access to mainframes. I can learn COBOL in a day or two, and I would love to work on a "boring" COBOL job, but I have no experience with mainframes.
Is there anything particularly different about mainframes compared to working on a server besides it probably being a different operating system? I assume it has a command line and you ssh into it somehow (or something similar)? Or are they still running punch cards or something?
You can find videos on Youtube, it's like an IDE where you would do everything in a user interface with menus, but the interface is a 25x80-char screen only :-) Everything is "almost" similar to a Unix system, but with different names, files are called "datasets", there are very few tools, but every one of them has a language to do very complex tasks...