Advanced programming languages (Haskell, Scala, SML, OCaml, Scheme)

http://matt.might.net/articles/best-programming-languages/

by gnosis • 17 years ago

52 44 17 years ago

matt.might.net

Locke16893• 17 years ago

In fact, experienced functional programmers become adept at encoding correctness constraints directly into the Haskell type system. A common remark after programming in Haskell (or ML) for the first time is that once the program compiles, it's almost certainly correct.

A difficult position to defend but the reason I end up favoring strictly typed languages over dynamically typed (I'm ambivalent about duck-typed, so Python ends up being my favorite language for other reason). I love Haskell, as you may be able to tell.

DenisM3• 17 years ago

Here's an argument I always use in such cases:

Imagine this setup: You use a fully dynamically typed language. You write unit tests and ensure 100% code coverage. You run those unit tests during the build phase.

Now, is there really difference in terms of guarantees that can be given about the app after it compiles? This arguably gives you better guarantee than static typing because it is also protects you from variety of errors such as using one expression of type FOO in place of another expression of the same type.

gnosis6• 17 years ago

Now let's say you write the same program in a statically typed language, with the same unit tests. Which is safer?

docmach• 17 years ago

If you have 100% code coverage you don't necessarily have 100% path coverage, so there could still be errors that a statically typed language would catch at compile time. Realistically, most programs aren't going to have extensive test suits that get anywhere near 100% code coverage, so static typing becomes even more valuable. Also, running a full test suite for every build would take much more time that running a type checker.

Locke16893• 17 years ago

You write unit tests and ensure 100% code coverage.

Let's image this counter scenario: You write a couple unit tests for your most common cases and a couple corner cases. You don't even try for code coverage over ~80%.

For me, the second case is more common. I simply don't have the time to keep the unit tests up to date with every iteration. In these cases I like static typing as it finds errors I miss.

camccann6• 17 years ago

You write unit tests and ensure 100% code coverage.

That sounds like a lot of extra effort; it would be nice to automate the testing a bit. Maybe some sort of simple declarative system to check that the code obeys certain constraints. Ideally, you could make your auto-test system clever enough to actually deduce a lot of the constraints itself, based on the structure of the code--you'd really save time that way! Then you could focus your effort on just testing the things your auto-testing system can't check.

I wonder if anything like that exists?

tel3• 17 years ago

From a Haskell background, I'd say static languages of a sufficient power still have the advantage due to things like QuickCheck. 50% of the battle with a unit test is writing up good edge cases, thus smart typing and QC systems can make (up to) half the problem disappear.

WalterBright• 17 years ago

There are limits to unit tests. For example, suppose I have a function I need to be pure (i.e. it does not modify any global state). No amount of unit testing will prove that it is pure. But a static type system check by the compiler can prove it is pure.

Unit testing and static type checking have some overlap, but it is not complete overlap. Both are desirable.

wheels• 17 years ago

The thing that I've found ironic as I've been spending more time with duck-typed languages is that all of the supposed concision and rapid development games are pretty much wiped out by the necessity to write unit tests just to assure even basic functioning.

Is my Ruby code more concise than my C++? Yep. But the C++ is smaller than Ruby + unit tests.

spitfire• 17 years ago

I'll bite: Your unit tests might be wrong.

xtho• 17 years ago

So you write unit tests for all possible scenarios and you write unit tests and unit tests and unit tests ... most of which you wouldn't have had to write if you had used a statically typed language right away.

jefffoster• 17 years ago

A unit test covers a some particular properties hold for some cases (e.g. you verify that foo gives bar). A type system guarantees that for all instances of the types, certain properties hold.

Given the choice, I know which I'd choose!

In practise it's not quite that simple, but designing around the types and shifting the burden of testing on to the compiler seems like the way forward.

tetha• 17 years ago

In my opinion, we need to split 'statically/strictly typed' languages further.

I love pythons dynamic types, and I love haskells typesystem, because once you get used to it, it becomes pretty much as painless as having dynamic types.

On the other hand, I utterly hate Javas typesystem, because it tends to be pretty obnoxious and in the way (probably I am not enough of a type theorist to actually understand why this is the case, but I can see that there are a lot of cases in the java type system which are just annoying roadblocks).

fhars• 17 years ago

The problem with java's type system is not that you are not enough of a type theorist, but that the people who designed it weren't. It is exteremly weak, inconsistent and confuses some fundamental concepts (like the difference between inheritance and subtyping). Many weirdnesses in generics and complexities in making modern languages interop with java on the JVM are for example just workarounds for the fundamentally broken semantics of java arrays (covariant, can you believe that?)

alrex021• 17 years ago

Surprised that Erlang is not in that list.

gnosis6• 17 years ago

I don't think it's supposed to be an exhaustive list. There are thousands of programming languages, and (arguably) hundreds of them could be considered "advanced". I think this is meant to be more of a sampling.

Still, given all that, Erlang would be on my list. :)

magoghm2• 17 years ago

I'm very surprised that Clojure isn't mentioned.

aerique2• 17 years ago

Why, because it's the hyped language du jour?

I actually found it well-written compared to other such articles that have been linked here before. Although it should have been called "Functional languages every programmer should know."

My personal list would include: Erlang, Forth, Scheme, Haskell, Prolog and omit Scala and *ML.

Why Clojure when Haskell and Scheme have already been mentioned? I think the latter two are more educative than the former.

magoghm2• 17 years ago

Because the author seems to like both functional languages and Lisp.

Advanced programming languages (Haskell, Scala, SML, OCaml, Scheme)

Related Stories