Slashdot Mirror

← Back to Stories (view on slashdot.org)

Node.js Now Runs COBOL and FORTRAN (arstechnica.com)

Posted by EditorDavid on from the party-like-it's-1959 dept.

Last summer a developer created a plugin which made it possible to run snippets of COBOL code embedded in JavaScript using the Node.js interpreter. Now Slashdot reader techfilz writes: Romanian developer Bizau Ionica has engineered a software bridge called node.cobol which can execute Node.js scripts from within COBOL programs.
The link shows COBOL code executing a Node.js script that launches a Web server and creates ASCII art from a JPEG image -- in this case, Admiral Grace Hopper, who helped create COBOL in 1959. And Ars Technica points out the same developer has also built a Node.js bridge for FORTRAN.

45 of 86 comments (clear)

  1. Great by Registered+Coward+v2 · · Score: 1

    Now if I could just figure out a way to rein those 1000+ Hollerith card decks...

    --
    I'm a consultant - I convert gibberish into cash-flow.
  2. Stop him - by any means necessary by Hognoxious · · Score: 5, Funny

    He needs to be stopped before he gets round to Visual Basic.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  3. Bizau by campuscodi · · Score: 2

    No surprise Bizau did it. This guy has been making JavaScript do weird stuff for a long time. Just check out his GitHub repo.

  4. Worthless by 110010001000 · · Score: 4, Funny

    Until it runs ADA it will be a toy language for hipsters.

    1. Re:Worthless by Anonymous Coward · · Score: 1

      It's called Ada, not ADA! Now hand in your Geek card!

    2. Re:Worthless by Anonymous Coward · · Score: 1

      Don't they use ADA a lot in military, aerospace and air line industry? When they make ADA work, the next thing any flying thing will need is a fscking insecure and crashing browser. And apps. And app developers. And app stores.

      NO

    3. Re:Worthless by TheRaven64 · · Score: 1

      I have three words for you: Ada on rails.

      --
      I am TheRaven on Soylent News
    4. Re:Worthless by itsdapead · · Score: 1

      It's called Ada, not ADA! Now hand in your Geek card!

      Actually, I think its "Ada(tm)" because I recall that the books on the orange (later grey) wall used to read "VAX Pascal; VAX BASIC; VAX C; and VAX(r) ADA(tm)".

      --
      In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
    5. Re:Worthless by Fnord666 · · Score: 1

      Until it runs ADA it will be a toy language for hipsters.

      Let me know when it runs Lisp.

      --
      'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
    6. Re:Worthless by ClickOnThis · · Score: 1

      Until it runs ADA it will be a toy language for hipsters.

      Let me know when it runs Lisp.

      I'll hold out for Brainfuck (more politely known as B****fuck.)

      Then again, why stop there?

      --
      If it weren't for deadlines, nothing would be late.
  5. Monuments of unageing intellect in code by sittingnut · · Score: 2

    ...
    Monuments of unageing intellect. ...
    Once out of nature I shall never take
    My bodily form from any natural thing,
    But such a form as Grecian goldsmiths make
    Of hammered gold and gold enamelling
    To keep a drowsy Emperor awake; ...

    from Sailing to Byzantium by William Butler Yeats

  6. They were so eager to see if they could... by Ngarrang · · Score: 4, Funny

    ...they never stopped to think if they should.

    Please, stop creating excuses to keep all that old FORTRAN and COBOL code around. Think of the children!

    --
    Bearded Dragon
    1. Re:They were so eager to see if they could... by Anonymous Coward · · Score: 1

      JavaScript belongs to the same garbage bin as COBOL and Fortran anyway. Associating these three languages together is actually a good thing. They should all die.

    2. Re:They were so eager to see if they could... by Theovon · · Score: 2

      No, Javascript belongs in an entirely different bin. Javascript is an interpreted object-oriented language that makes functions a first-class datatype. The other languages were compiled, completely procedural, and at least Fortran didn’t even support recursion until the 90’s.

    3. Re:They were so eager to see if they could... by ooloorie · · Score: 5, Informative

      The other languages were compiled, completely procedural, and at least Fortran didn’t even support recursion until the 90’s.

      I'm not sure what you mean by "were". Fortran is widely used in scientific computing. It has supported recursion since the 1970's, although it only was standardized in 1990. Fortran 200x is object oriented, supports operator overloading, and has excellent support for array and parallel computing.

    4. Re:They were so eager to see if they could... by Theovon · · Score: 1

      Fine. So there’s some overlap between Fortran 200x and Javascript. Name two things in the universe that are completely disjoint (besides Creationists and honesty).

    5. Re:They were so eager to see if they could... by Rockoon · · Score: 1

      1) Your grasp of the facts
      2) The actual facts

      --
      "His name was James Damore."
    6. Re:They were so eager to see if they could... by Anonymous Coward · · Score: 1

      Fortran is actually faster than C at certain math-heavy algorithms. However, I have seen the LuaJIT heuristics beat both at the same heavy math stuff so these days I have replaced all my Fortran stuff with Lua. LuaJIT is nicely easy to use and very fast at everything other than string stuff, it absolutely fails at heavy string manipulation.

    7. Re:They were so eager to see if they could... by K.+S.+Kyosuke · · Score: 2

      It's also quite difficult to customize code on the fly with Fortran with any decent speed, whereas you can feed code transformed at run time into LuaJIT on the fly and end up with something that actually runs fast.

      --
      Ezekiel 23:20
    8. Re:They were so eager to see if they could... by K.+S.+Kyosuke · · Score: 1

      Oh, by the way, have you considered writing your own string library? The immutable string model should lend itself to some tree-based approach pretty nicely. Gauche Scheme does similar things, even going so far as to pretend mutable strings on top of mutable ones, including giving you functions for delayed concatenation etc. so as to give you decent speeds without resorting to dirty tricks.

      --
      Ezekiel 23:20
    9. Re:They were so eager to see if they could... by K.+S.+Kyosuke · · Score: 1

      ...on top of immutable ones...

      --
      Ezekiel 23:20
    10. Re:They were so eager to see if they could... by ClickOnThis · · Score: 1

      The other languages were compiled, completely procedural, and at least Fortran didn’t even support recursion until the 90’s.

      I'm not sure what you mean by "were". Fortran is widely used in scientific computing. It has supported recursion since the 1970's, although it only was standardized in 1990. Fortran 200x is object oriented, supports operator overloading, and has excellent support for array and parallel computing.

      I'm not sure what you mean by "it." Just because some compiler vendors may have supported non-standard extensions that allowed recursion does not mean you can claim the language supported it in general. GP is right: Fortran, as a standard, did not support recursion until 1990. Granted, it was possible to "hack" recursion with F77 constructions but that's more of a conceptual exercise than a viable practice. When it's that hard to do something in a language, you need to use a different one.

      For better or for worse (mostly the latter) Fortran has been very slow to adopt new paradigms throughout its history. That has condemned it to a niche existence in scientific computing. Its main virtue (not to be taken lightly) is that it has excellent compiler support for efficient numerical computing.

      --
      If it weren't for deadlines, nothing would be late.
    11. Re:They were so eager to see if they could... by ooloorie · · Score: 1

      I'm not sure what you mean by "it." Just because some compiler vendors may have supported non-standard extensions that allowed recursion does not mean you can claim the language supported it in general

      Almost all C programs in existence depend on implementation-define features, so by that measure, there exist almost no C programs at all.

      For better or for worse (mostly the latter) Fortran has been very slow to adopt new paradigms throughout its history.

      How? The first C standard ever came out in 1989, the first Fortran standard with recursion in 1990, one year later. The first C++ standard came out in 1998, the first Fortran standard with OOP came out in 2003. And, of course, C++ still lacks many of the numerical features, parallel programming features, and multidimensional arrays found in Fortran.

      Perhaps what you are referring to by "adopting new paradigms" is the fact that C++ standards often wrote stuff into the standard that then took many years to implement correctly for compiler writers; I don't see that as an advantage.

      That has condemned it to a niche existence in scientific computing.

      That "niche" is its purpose in life. C++, unfortunately, has found no niche at all; C++ seems to be a waystation for people moving up from C before they then abandon C++ for greener pastures.

    12. Re:They were so eager to see if they could... by hey! · · Score: 1

      Well, it's object oriented features suck, but it's really quite nice for functional programming. I'm glad to see that paradigm make such a comeback.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    13. Re:They were so eager to see if they could... by ClickOnThis · · Score: 1

      I'm not sure what you mean by "it." Just because some compiler vendors may have supported non-standard extensions that allowed recursion does not mean you can claim the language supported it in general

      Almost all C programs in existence depend on implementation-define features, so by that measure, there exist almost no C programs at all.

      What "implementation-define[d] features" do you mean, and how do "[a]lmost all C programs in in existence depend" on them?

      My experience with both languages is that it is Fortran, not C, that has suffered historically from a lack of portability due to implementation-defined features.

      For better or for worse (mostly the latter) Fortran has been very slow to adopt new paradigms throughout its history.

      How? The first C standard ever came out in 1989, the first Fortran standard with recursion in 1990, one year later. The first C++ standard came out in 1998, the first Fortran standard with OOP came out in 2003. And, of course, C++ still lacks many of the numerical features, parallel programming features, and multidimensional arrays found in Fortran.

      That's a straw-man. You seem to think that C and C++ are the only languages and standards to be compared with Fortran.

      First of all, support for recursion dates back to Algol 68. And the de facto definition of the C language was contained in Kernighan and Ritchie's 1978 book, which was subsequently updated in 1988 to the ANSI standard that was adopted officially in 1989. The concept of object-oriented programming dates back to the late 1950s. Its first appearance in a formal language was with Simula 67. In subsequent years, languages such as Smalltalk, Lisp derivatives, and Object Pascal were followed eventually by C++ in the early 1980s. Object-oriented programming surged in popularity beginning in the early 1990s. Fortran caught up eventually, but as usual, it was late to the party.

      I'm not sure what you're talking about regarding "numerical features, parallel programming, and multidimensional arrays." C++ supports all of that, just not the same way as Fortran.

      I say again: Fortran has been very slow to adopt new paradigms. It didn't even support a DO-WHILE officially until 1990. Oh sure, most compiler vendors had it in their F77 offerings, but you could never be sure it was there when you ported your code to another machine and its compiler.

      Perhaps what you are referring to by "adopting new paradigms" is the fact that C++ standards often wrote stuff into the standard that then took many years to implement correctly for compiler writers; I don't see that as an advantage.

      Compared to what? Standards that pre-date their implementation provide a common adoption plan for vendors. Standards that post-date a number of divergent implementations are an attempt to remove redundancy and incompatibility between them.

      And no, that's not what I meant by "adopting new paradigms." There you go again with a straw-man.

      That has condemned it to a niche existence in scientific computing.

      That "niche" is its purpose in life. C++, unfortunately, has found no niche at all; C++ seems to be a waystation for people moving up from C before they then abandon C++ for greener pastures.

      Again, you seem to think that C and C++ are the only valid comparisons to Fortran.

      Go ahead and Google for rankings of language usage. This one, for example. I challenge you to find a ranking that even has Fortran on the list.

      --
      If it weren't for deadlines, nothing would be late.
    14. Re:They were so eager to see if they could... by JanneM · · Score: 1

      The parallel array stuff in later Fortrans are really neat. But last time I looked, doing it explicitly yourself with MPI in FORTRAN77 was still quite a bit faster. Have compilers improved to the point where that speed difference is mostly gone?

      --
      Trust the Computer. The Computer is your friend.
    15. Re:They were so eager to see if they could... by ooloorie · · Score: 1

      That's a straw-man. You seem to think that C and C++ are the only languages and standards to be compared with Fortran.

      No, I simply corrected some nonsense that you and Theovon were saying.

      Again, you seem to think that C and C++ are the only valid comparisons to Fortran.

      Mostly, I think that you just don't have anything interesting to say.

    16. Re:They were so eager to see if they could... by ooloorie · · Score: 1

      The parallel array stuff in later Fortrans are really neat. But last time I looked, doing it explicitly yourself with MPI in FORTRAN77 was still quite a bit faster. Have compilers improved to the point where that speed difference is mostly gone?

      You're thinking coarrays; that's only one of several parallel programming facilities.

      Coarray performance depends on the hardware and compiler. For MPI-like setups, you can use OpenCoarrays, which simply maps coarray code into MPI code, so performance should be similar.

    17. Re:They were so eager to see if they could... by 0100010001010011 · · Score: 1

      that old FORTRAN

      That old FORTRAN code works. It's been beaten to death and unit tested left and right.

      Thousands of Engineering Apps are built on that FORTRAN code. Numpy is just a wrapper on it. Matlab is just a wrapper on it. Even the C tools are just wrappers.

      Everything from Computational Fluid Dynamics to Finite Element Analysis to Wireless RF Modems uses the FORTRAN (even if it's not exposed as such to the end user). Modern society would grind to a halt without that FORTRAN code.

    18. Re:They were so eager to see if they could... by Ngarrang · · Score: 1

      This technology could extend the useful many languages, it seems.

      node.ada
      node.apl
      node.pl1
      node.snobol

      --
      Bearded Dragon
    19. Re:They were so eager to see if they could... by JanneM · · Score: 1

      Well, duh. But F77 is obsolete and MPI is now only used for distributed systems (which are harder to write for than shared-memory systems). You want to see equally painful, write the same MPI code using a pre-ANSI C-compiler because that's the equivalent of what you're complaining about.

      The modern way to do this is OpenMP and Fortran 95 (which is supported by all major compiler vendors) or Fortran 2003 (which is 90% supported by all major compiler vendors). Just tell the compiler what you want, and you have parallel code. No fuss, no muss.

      I certainly love OpenMP, and I much prefer it over MPI. But big machines are all distributed, not shared memory. If your code is going to run on anything on the top100 list, for instance, or any university cluster, then OpenMP is not enough. All the big systems I've worked with need a hybrid design where you use OpenMP for within-node parallelism, and MPI across the nodes.

      With that said, there are some encouraging signs. Things like XScalableMP attempt to implement OpenMP-like semantics on top of MPI, and mostly succeeds. Although you still need to do explicit synchronization on occasion. The offloading infrastructure in the latest GCC versions could possibly also abstract away this in the future, but again, we're not there yet.

      --
      Trust the Computer. The Computer is your friend.
  7. So I read both articles by rebelwarlock · · Score: 3, Insightful

    No one says why this was done. I'm beginning to suspect the people who did it don't know why either.

  8. But it doesn't by El_Muerte_TDS · · Score: 1

    It just forwards code between runtimes/compilers and executes the separate process. You cannot run fortran or cobol unless you install GNU's implementations of them on your machine.

  9. Re:Now to wait for all the JS haters to decend.... by Anonymous Coward · · Score: 1

    Ultimately all JS haters argue against third rate languages conceived in an afternoon in 1995 for simple web client prettification to hobble together crap by hipsters selling poor quality junk that nobody asked for.

    Abstraction is useful when 1) it genuinely means you can stop worrying about underlying systems, rather than having exactly the same performance etc. problems to solve based on the particular implementation detail of your abstracted platform; 2) it doesn't mean you need a 2 GHz CPU to do what could be done on an Amiga in 1985; 3) It doesn't mean you have to learn a whole new platform every year, so nobody's ever an expert on anything.

  10. Pfffft by JustAnotherOldGuy · · Score: 4, Funny

    I won't be happy until I can run COBOL in my browser under WINE through a VM running on a aliased instance of Win XP under AmigaOS.

    Oh, and I want a high frame rate too.

    --
    Just cruising through this digital world at 33 1/3 rpm...
  11. Re:So, Node.js is just Perl for hipsters? by Alan+Shutko · · Score: 1

    No, they just wrote something that will run the GNU cobol compiler.

  12. Finally by Opportunist · · Score: 4, Funny

    About time my malware runs on payroll mainframes!

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  13. Re: Visual Basic is an improvement over JavaScript by hackwrench · · Score: 2

    The original Visual BASIC was backward compatible for the most part with Quick BASIC. QB64, while not backward compatible with VB is also backward compatible with QB, with its own extensions.

  14. Re:Getting confused by edittard · · Score: 2

    The title give one way and the main text give the opposite.

    # Meet the new editor,
    Same as the old editor... /#

    --
    At the bottom of the /. main page it says 'Yesterday's News'. Well they got that right.
  15. Re:COBOL by ceoyoyo · · Score: 2

    Yeah right. Payroll NEVER makes any mistakes.

  16. Don't hate on JavaScript until you have tried it by itsdapead · · Score: 1

    Until you have actually tried JavaScript, don't hate on it...
    ...because only once you've tried it will you really learn to know the meaning of hate :-)

    Problem is, having a cross-platform language & API for which the runtime is already installed on most systems - so end users with zero technical skills (you know, the ones where you ask them what operating system they're running and they say "Microsoft Office 2013") will actually be able to run your programs - is jolly useful... Sadly that language is JavaScript. Pity Java kinda went wrong.

    --
    In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
  17. Re:Getting confused by BlackPignouf · · Score: 1

    Both seem to have been written : COBOL on Javascript last summer (see title), Javascript on COBOL recently (that's the piece of news, so it's not mentioned in the title).

  18. Re:Visual Basic is an improvement over JavaScript. by Tablizer · · Score: 1

    Almost everything is better than JavaScript. JavaScript was good enough as a light-duty scripting and glue language, which it originally was designed for in browsers.

    Now people are trying to write GUI frameworks and systems software with it, which is NOT what a scripting language is meant for. Scripting languages should be using/connecting-to systems software, not implementing it.

    JavaScript is the wrong tool for the job. It's only popular because it's built into browsers, not because people love it. I'm sure a few will disagree, but a wider survey would show no love of JavaScript for bigger projects.

    (It's not even a good scripting language, but that's another topic.)

    --
    Table-ized A.I.
  19. Thank the Lords of COBOL by rcase5 · · Score: 1

    Battlestar Galactica will be pleased.

  20. Dijkstra by jonathandarndt · · Score: 1

    Since the Slashdot community seems to appreciate the work of this fellow, I just read another of his lectures (EWD273) where he had some harsh criticism for both of these languages. (The whole article is a good read, but the first mention of FORTRAN and COBOL can be found in just the last few paragraphs of the transcription.)