<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 1, 2015 at 6:30 AM Jerzy Karczmarczuk <<a href="mailto:jerzy.karczmarczuk@unicaen.fr">jerzy.karczmarczuk@unicaen.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Le 01/09/2015 08:59, Mike Meyer a écrit :<br>
> There are application areas for which COBOL is clearly superior to -<br>
> and hence more worthy than - Java. Or Haskell.<br>
<br>
Perhaps.<br>
But could you<br>
<br>
1. Tell us which application areas? Concretely.<br>
2. Explain what does it mean "superior"?<br>
3. Explain WHY Java is inferior?<br></blockquote><div><br></div><div>Since you asked nicely, I'll explain my earlier one-liner.</div><div><br></div><div>First, a language is "superior" (or "more worthy") if it fails to meet the constraints of the problem at hand, or if a constraint is the optimization of a measurable quantity, and solutions using that language will clearly have better values for that quantity than an inferior language choice.</div><div><br></div><div>In the real world, problems often come with a legacy code base of some kind. In which case, optimizing cost or development time - or possibly even performance of the code, depending on the languages in question - may well involve using the legacy code base. You see such decision everywhere in the Haskell ecosystem, from compilers that generate C code instead of native code, to wrappers that wrap FORTRAN number-crunching systems.</div><div><br></div><div>And an apology. When I wrote "government systems" last night, I was searching for a short way to describe a complex issue, and failed to recognize the ambiguity in the phrase and that the most likely interpretation wasn't the one I had in mind.</div><div><br></div><div>I meant systems whose output was determined in large part by a large body of government regulations. For instance, anything that deals with calculating taxes.  This stuff not only has vague and confusing specifications in the form of regulations written by legislators, but it tends to be revised every year, without the developers of such systems being consulted.</div><div><br></div><div>So in this case, your legacy code is not merely decades old, but has been undergoing revision for decades.</div><div><br></div><div>One of the strengths of COBOL is the ability to deal with data files in formats that were in common use by businesses when the system was designed. Given that these problems are often CRUD of some sort or another, these features tend to be heavily used in such systems.</div><div><br></div><div>The output formats we've pretty much kept - the people reading them were happy, and didn't want them to change. COBOL's ability to generate reports using them was good, and I don't believe Haskell has any comparable functionality. Java doesn't seem to have it in the "official" libraries, but there are third party report generation tools that are probably better. Except you have to write your report specification on Java, or worse yet XML - which is so bad you probably get a tool for creating them.</div><div><br></div><div>Input, on the other hand, is a mess. Nobody in their right minds would use the input formats COBOL can deal with - we've learned a lot about making input easier on humans since then (XML wasn't designed to for human input; it's SGML stripped down to the point where merely competent programmers can  write a correct parser). But if you're dealing with such legacy systems, you've probably got data files in those old formats. Sure, java re's or Haskell's parser combinator libraries make writing parsers for those - or better yet, sane - formats possible, but COBOL does it natively.</div><div><br></div><div>While we're talking about native features, COBOL's native formats were designed for dealing with money - which is often the data type such systems have to deal with. Last time I looked - about a year or so ago - Haskell didn't have a high quality data type for doing that. Java probably does, but not as a native type. And this makes wrapping the legacy code an interesting proposition - what do you map a data item declared as "PIC 9(8).99" to?</div><div><br></div><div>Ok, that's the problem and some of the issues that with it. The optimization constraint is, of course, to minimize the cost of ongoing maintenance over a relatively short term, say a couple of years.</div><div><br></div><div>And for the record, I've known people whose job was maintaining just such systems. When given a problem that involved low-level bit-twiddling, or creating linked lists as discussed earlier, they quite happily started writing a WORKING-STORAGE section.</div></div></div>