Linking the old world of programming with the new, a Web developer from Romania has built a bridge between highly fashionable Node.js and that venerated but antiquated business programming language: Cobol.

Found on Github, the node-cobol project enables the running of Cobol code from Node.js, the popular server-side JavaScript platform. "I just thought it would be funny to create a bridge between a popular actual programming language -- Node.js -- and an old one -- Cobol," developer Ionica Bizau said in an email. "Honestly, I don't really think there is a real need, except the nostalgia that it creates especially for the Cobol programmers and people who know what Cobol is."

[ Need a JavaScript tool for your dev shop? InfoWorld looks at 17 JavaScript editors and IDEs ready for adoption. | Keep up with hot topics in programming with InfoWorld's Strategic Developer blog and Application Development newsletter. ]

While Cobol is not in vogue these days, there is a lot of Cobol code still running, Forrester analyst Kurt Bittner said. "Most development work done in Cobol is maintaining or extending that large code base." There is still some demand for Cobol experts. A search on the Dice.com IT jobs site this week turns up 493 jobs for Cobol developers and 1,156 positions for those with Node.js skills.

The bridge requires the use of the GnuCobol compiler. Cobol code is received as input and uses GnuCobol to build an executable in the background, then it runs it, Bizau said. "This method allows the programmer to have full control on the input Cobol code -- such as piping the stdout and stderr streams, providing command-line arguments, etc. A nice idea would be to use a JavaScript-based Cobol compiler to compile the input, removing GnuCobol as [a] dependency."

Bittner, though, disagrees with Bizau's approach. "The ability to run Cobol snippets from Node.js seems like a clever but misplaced solution to the reuse problem and may actually cause more problems by tightly coupling Node.js code and Cobol code." A better solution, he said, would be to wrap the Cobol code in services and solid APIs. "That way, any application can use that code in a controlled manner and in a way that lets the Cobol code evolve independently from any application that calls it, even to the point of completely replacing the Cobol code over time, where desirable."

Bizau, in response, said there was always something to improve and what Bittner suggests could be made into a feature request in the repository issue tracker. He pledged to improve the bridge if people like it based on the initial release.