Tangentially, seeing this code snippet made me wonder whether we lost something in our push to make programming languages/statements more and more terse.
DISPLAY "Write something and then press the <Enter> key"
OPEN INPUT SYSIN
READ SYSIN
AT END SET EOF TO TRUE
END-READ
PERFORM UNTIL EOF
Perhaps a little verbosity is good to make programming accessible to a larger audience. I've been programming for over twenty years, but the seemingly redundant "AT", "TO" and "PERFORM" does help the flow in my head. Almost as if it brings into play more of my brain's language centres because now the code can actually be read out aloud.
named arguments a la Objective C or Gleam do a similar thing - oftentimes a named argument will start with a preposition or simply be one, "from" or "to", so you can read and write:
Perhaps a little verbosity is good to make programming accessible to a larger audience.
Careful, though, or you end up with AppleScript.. :-)
But yes, fair point, and AI-powered IDEs could actually make it productive, too. One problem with such verbose code is it can be easy to forget the particular incantations needed because it gets mixed up too much with natural language, but autocomplete, Intellisense, Copilot, etc. could probably bridge the gap.
Interesting choice for the inline code option in the examples to parse the COBOL out of a comment in the string representation of a function. Especially considering the JSDoc suggests it also accepts a plain string. Would love to know the reason for that.
It’s an old trick for pleasant-ish multi-line strings from before node/JavaScript had `backticks`. You can stringify the function and parse the string out of the embedded comment.
OK, cool science project and all, but . . . why? The problem in COBOL land isn't being able to execute snippets embedded in another language. It's a) migrating the COBOL to something else before all the devs who know it retire/die and b) getting stuff on to commodity hardware or other solutions as things like Solaris aren't supported anymore.
Strange comment for Hacker News. Maybe the author wanted to learn more about COBOL and this was a fun way to explore that and share their findings. Not every personal project needs a business case to justify its existence.
It was a good question to ask, and they have a strong nose for when there's a missing factor in an explanation: GP, it's a joke about Next.js abusing a language keyword to make it easy to in-line server side code in client code via require ("server"), there's been an explosion in memes about it over the last day
Sorry people got personal and berated, I really do mean it when I say you have a good nose for a missing factor
Sun and Solaris weren't around back in COBOL's heydey (well maybe they were at the tail end of it) so that makes sense. COBOL is only really still popular on mainframes because a lot of core early buisness data processing code was written there in COBOL. So much in fact that it's basically impossible to manually rewrite (not to mention the performance hit if you rewrite it in something like Java which seems to be the "new COBOL" in terms of being super vanilla and business-y, or you use an automated rewriting tool which you might imagine is going to come out pretty nasty looking).
There is a big niche of hooking all of that stuff up with modern frontends and running it remotely via browser interface and maybe a Node server on a mainframe and that sort of thing. That is how you end up with projects like this. The author jokes about it being ready for production, but I'm not joking I have really seen some stuff not dissimilar from this running in production, but with it calling the IBM Enterprise COBOL compiler instead. Doesn't look like it's supported here but it could be modified trivially to run on a real mainframe, just change the name of the executable it's calling and handle the case of a different path format when given a path outside of the Unix file system (there is a Node library already that can handle this, or you can compile C code since weird path support is provided by C libraries as well and can be made into a native node extension).
A more interesting discussion might be had about dynamic linkage and how that works in mainframe COBOL environments and how it's different from C environments. And in particular how that all fits together with transaction monitor systems, which are like very primitive containers. The closest comparison would be AWS Lambda functions and other serverless abstractions. A lot of COBOL actually looks like serverless, with lots of small very modular programs that link and load each other dynamically, which is part of why there was a tendency to reject some aspects of structured programming. I've seen apps that use too much serverless that feel a lot like classic COBOL spaghetti code.
Anyways, that's my big bunch of stuff I know about COBOL, which is quite a lot but unfortunately have never had much opportunity to write it.
