[Haskell-cafe] Why Haskell is beautiful to the novice

[Mike Meyer]

On Tue, Sep 1, 2015 at 6:30 AM Jerzy Karczmarczuk <
jerzy.karczmarczuk at unicaen.fr> wrote:

>
> Le 01/09/2015 08:59, Mike Meyer a écrit :
> > There are application areas for which COBOL is clearly superior to -
> > and hence more worthy than - Java. Or Haskell.
>
> Perhaps.
> But could you
>
> 1. Tell us which application areas? Concretely.
> 2. Explain what does it mean "superior"?
> 3. Explain WHY Java is inferior?
>

Since you asked nicely, I'll explain my earlier one-liner.

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.

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.

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.

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.

So in this case, your legacy code is not merely decades old, but has been
undergoing revision for decades.

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.

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.

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.

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?

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150901/82fb227e/attachment.html>