GNU APL 1.0

Holy cow! I am floored that they are doing that. That is a hugely ambitious departure from the high-end enterprise niche they've always been limited to. How exciting.

Please tell me this is all open source?

Yeah, but what I am saying is that you put the same people on both sides. Virtually everyone in haskell land is a C fan, it was a recent topic of discussion actually.

>Ocaml is more pragmatic than Haskell, in my opinion

There's a reason the haskell community is far larger than the ocaml community, and that the tools and libraries for haskell are way ahead of those for ocaml. From a purely pragmatic perspective, haskell is a far more useful language than ocaml. I say this as someone who switched from ocaml to haskell for entirely practical reasons.

>Eagerness is more practical than laziness

No it isn't. In 95% of cases it isn't relevant. In the other 5%, you want to use the right one. For practical purposes, it does not matter if a language is lazy by default or strict by default, as long as it is easy to do the other one. Ocaml makes it easy to do lazy, haskell makes it easy to do strict.

>refs more practical than e.g. state monads

Refs are not comparable to state monads. They are comparable to IORefs, or MVars, or TVars. Which are more useful than ocamls refs. A state monad is an extra thing ocaml simply lacks altogether.

>so correct me if I'm wrong, but my impression is that OCaml is in most senses an impure superset of Haskell

Not at all. Ocaml and haskell share a similar subset, but both have large area the other doesn't. There is very rarely a simple translation from haskell to ocaml, as ocaml is missing so many things that are commonly used in haskell code. There is more often a simple translation from ocaml to haskell, as idiomatic ocaml rarely uses objects. First class modules is generally the issue with translating in that direction.

>http://jxyzabc.blogspot.com/2009/03/haskell-vs-ocaml-or-ravi.... echoes my impression.

Yes, and it repeats the same weird memes about haskell that don't actually make any sense to someone who has used haskell for a non-trivial project. Like "needing monads for state".

In my opinion, APL's array capabilities are far stronger and notation less noisy, i.e. less syntax and punctuation. R seems to have been developed with tools like Lex and Yacc and the language has a certain look and feel.

The problem with regular expressions is the "regular expressions gone wild" effect. Also, the lack of a mechanism for documenting intent is a serious hindrance. One such example are the various forms of email validity regex strings floating around out there.

I'll also say that there's somewhat of a lack of "topology" with regex expressions. What I mean is probably best explained with an analog. If you look at a page full of cleanly written mathematical notation you will quickly identify what I am calling a "topology" of sorts. You'll see the equal sign creating a demarcation between sides. You might see integral signs providing further grouping. The same is true of division lines, parenthesis, exponents and radicals.

Now, a page full of equations can be insanely opaque. Alone they mean very little to most people. However, properly inserted comments and guidance can take something that was impenetrable and turn it into a more approachable problem. Of course, all of it assumes that you know both the notation and the mathematics behind it. Hard to understand differential equations if you never studied them.

A language like APL can be very similar to this. I can write an ugly impenetrable hunk of code in one line and good luck figuring out what it does. On that point you are absolutely correct.

If one starts to work with APL on a daily basis one invariably develops "idioms" --short chunks of reusable code-- that are applied with some regularity. Perhaps the most famous library of APL idioms is the Finn APL Idiom Library [0].

Here you have a set of expressions that do very useful stuff that can be plugged into any program. Generally speaking, a good programmer would include a comment identifying the idiom any time it is used. These little chunks of code, again, if APL is your daily 8 to 12 hour focus, become like words that you use in your code. You learn to recognize them very quickly.

Unlike regex, the symbols in APL, similarly to the mathematical example I gave above, create a topology of sorts that helps you read and understand the code. The programmer has to be sensitive to the fact that, very much like regex, APL can easily become impenetrable, particularly to the casual observer. It is important to recognize this and both format and comment code appropriately.

My general rule for programming, regardless of the language I use, is that I need to leave myself enough information, breadcrumbs and documentation to be able to understand what I was doing after five years of not having looked at the code or used the language it was written with. This approach has saved my butt multiple times to the point that I can say, at least to my satisfaction, that it is the only way to create code --regardless of language-- that can survive the test of time and is easy to maintain.

The short answer to your observation, then, is that a good programmer should easily eliminate the impenetrability issues the language might have.

[0] http://aplwiki.com/FinnAplIdiomLibrary

Since you worked with APL so intensively for so long, would you care to describe what you think is good about it? And how it differs from more familiar approaches? (Apart, of course, from charset and order of operations.)

I had a friend whose Dad got him a job in high school working for Ken Iversen at IBM, who taught him APL programming.