Hacker News Reader

Comment by webreac | Hacker News Reader

When I was student, my school has decided to stop using Ada as teaching language. They were hesitating between CAML Light and Scheme. They asked me my feeling because I was one of the rare student to know well both of them. I like both of them, but I choose CAML Light. Scheme has a lot of parenthesis that makes it look very old fashion. Scheme type system was also outdated. Programming in CAML Light was more fun for me, the syntax was simple and pleasant. The currification was cleaner in CAML Light. 20 years latter, CAML Light does not exist anymore, but I still think that my choice was right. My school has choosen CAML Light.

View on HN

I went from SML, Caml Light, and OCaml to Common Lisp, and then to Scheme.

I prefer Scheme by far to any other language I've ever used (which includes a whole bunch of languages not listed above).

For me, Scheme is much more fun to program in than OCaml, etc. With OCaml I found myself constantly wrestling with the compiler to get my program to compile, and had problems decyphring its obscure error messages, which seemed to require taking university-level courses on type theory in order to be understandable.

With Scheme, my programs mostly "just work", and I can program the way I think.

Some people have problems with Scheme's parenthesis, but I personally quickly learned to love them because they make scope explicit and obvious. Through long and bitter experience, I've learned to value explicitness and clarity in programs above almost everything else. Scheme is great for that.

True, Scheme might not be as safe as OCaml and friends, but for ease of programming, speed of development, and sheer pleasure, I find it very hard to beat.

The most useful didactic feature I've found in ML-like languages--Haskell for me, but they're all somewhat similar--was pattern matching. Honestly, pattern matching is what really got me to understand recursion. It also makes the language feel much more declarative than using `if` and `cond` statements.

It's possible to do pattern matching in Scheme, though it's not standardized (AFAIK). Here are some approaches:

https://curiousprogrammer.wordpress.com/2006/12/08/pattern-m...

http://www.javaist.com/blog/2008/11/12/pattern-matching-in-s...

http://wiki.call-cc.org/eggref/3/pmatch

http://wiki.call-cc.org/man/3/Pattern%20matching.html

http://www.ccs.neu.edu/home/samth/match-ifl-full.pdf

http://download.plt-scheme.org/doc/203/html/mzlib/mzlib-Z-H-...

Hi,

>CAML Light does not exist anymore

French classes prépa[1] have been using it in the CS course until this year (I have heard it would be dropped in favour of Python next September). So even though there hasn't been any development for the past 10 years[2] it still exists! And then there is OCaml which is still lively.

Even though a CS graduate may say that S-expressions are the simplest syntax possible - not that he's wrong - I'm happy I discovered functional programming through OCaml, whose syntax feels way more natural (to me at least).

1: http://en.wikipedia.org/wiki/Classe_pr%C3%A9paratoire_aux_gr...

2: at least according to http://caml.inria.fr/caml-light/release.fr.html

"Scheme has a lot of parenthesis that makes it look very old fashion."

Might I argue that this is a huge advantage? No one knows scheme, and it's very obscure, and looks nothing like other programming languages. This means that you can teach concepts using it and pre-judgements about the language don't get in the way.

Then, I suppose the same could be said of CAML and its obscurity.

Which one is obscure ? define factorial (lambda (n) (if (= n 0) 1 (* n (factorial (- n 1))))))

let rec fact = function | 0 -> 1 | n -> n * fact (n - 1);;

There is a little more syntax to learn in caml, but the suppression of 90% of the parenthesis makes the code far easier to read.

With syntax hilighting and proper indenting, the Scheme code is pretty easy to read:

http://img1.imagilive.com/0413/scheme-fact.png

You could even simplify it a little by getting rid of the lambda:

http://img1.imagilive.com/0413/scheme-fact2.png

In any case, I find toy examples like this less than convincing. In real-world programs, issues of style, design, and documentation usually trump most anything else, as far as clarity is concerned.

Also, I personally find the penchant for one-letter variable names in the OCaml/SML/Haskell world to be very confusing and obfuscating.

The Scheme way is to be more verbose and explicit. For me, that results in much greater clarity -- especially when looking at unfamiliar code or code that you've stepped away from for a few months.

Of course, there also such a thing as being too verbose and explicit. But for me, Scheme is in the sweet spot between verbosity and terseness.

I find the lisp easier to read.

E.g. Haskell has enough syntactic sugar for some an even simpler version

    factorial n = product [1..n]

Something similar is achievable in scheme, just takes a little work http://repl.it/InA (click run session) :)

Oh, you don't even need macros for something similar. E.g. Python's range function works just fine.

Was the school in France?

These don't seem like very good reasons to choose one over the other; the choice probably came down to culture.

Can you elaborate? Is your school still using CAML Light, or have they moved on to some other language (O'Caml?)? How effective was it as a teaching language?

According to their site, they have switched to python followed by java the second year. As it was after I finished, I have almost no feedback.

Dynamic typing is outdated?!

I'm a big fan of Clojure but I think this is true. I expect that in this decade we'll start seeing a shift to programming languages with so-called algebraic type systems.

Java, Python, Ruby, and Clojure will seem outdated just like C++ seems outdated now (not that it doesn't have its uses).

C++11 is not outdated. Except for backwards-compatibility artifacts like header files, it's actually quite modern and pleasant to use. If performance is a consideration, then, put bluntly, it's the only high-level language available.

hopefully rust will fill this void, pun not indented

Yes, since at least 80s or so. Languages based on Hindley-Milner type system (https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner) are static and nice to work with. E.g. OCaml or Haskell.

I have some professional experience in rewriting Python and Ruby programmes in Haskell. I make the same amount of stupid mistakes in Python as in Haskell. But whereas Python blows up at runtime / test time, in Haskell it's the compiler yelling at me. The nice thing: that's much faster to detect, and also saves me writing about half the tests.

Don't get me wrong, dynamic typing beats inane static typing like C's or Java's. But good static typing beats dynamic typing.

I have experience with OCaml, and I don't find its static typing to be nice to work with at all.

I like the final result of safety, and how whole classes of bugs are excluded once I get my OCaml program to compile. But the process of getting my program to compile in the first place is pretty painful and not fun.

Then again, writing endless unit tests in a dynamically typed language like Scheme is not much fun either. But I don't have to write the unit tests until I've written some functional portion of my program (or even the whole thing) and am satisfied with its design and how it works. Then I could add unit tests or even rewrite it in a safe language like OCaml, if I wanted to.

As I said elsewhere in this thread, for fast prototyping and sheer pleasure of programming, I find Scheme very hard to beat.

The soon-to-be-released GHC 7.8 (Haskell) can defer type errors until runtime to allow you run your program even if part of it is broken, and you can also add "holes" in place of an arbitrary expression and the compiler will tell you the type of the expression you need to replace it with (of course, this will explode if run). I suspect GHC's error messages are better than Ocaml's as well.

That's good to know, and gives me extra incentive to learn Haskell some day.

On the Scheme side of things, I've heard that the newish (4.8.0 and up) versions of Chicken can perform flow analysis to catch some type errors at compile time, and optimize based on types.

There's also Typed Racket, and Chicken has a contracts egg that allows procedures to have pre- and post- conditions.

For some years now, I've heard predictions that in the future languages will allow their users to "dial up" or "dial down" safety features on demand. I guess the above features of Scheme and Haskell are some early steps along that path. We live in interesting times.

Actually, -fdefer-type-errors is already in GHC 7.6: http://www.haskell.org/ghc/docs/latest/html/users_guide/defe...

-XTypeHoles will be in GHC 7.8: http://www.haskell.org/haskellwiki/GHC/TypeHoles

I agree. A type system is good if it allows you to express everything you want to express, if not (as in Java), it is a tool for oppression.

I wrote a simple OCaml compiler for a class in college. I particularly enjoyed using different operators for floating-point and integer math — brilliant usability there, really sold me on static types. Haskell does better with its type classes, except my four attempts to understand monads and arrows have, so far, met with rather mixed success.

Static typing has its place in some people's hearts, and I respect that, but saying that dynamic typing has been outdated since the 80s is (1) trolling, and (2) happens to also just be, like, your opinion, man.

If you want to have another go at it, I recommend Learn you a Haskell for Great Good (available online for free at http://learnyouahaskell.com/) for your Haskell learning needs. Don't stress the Monads and Arrows so much. I know what arrows do, but can't spot their applications in practice. And still I get paid for writing Haskell programmes.

Oh, and please excuse my snarky tone. Your ancestor comment seemed to ask for it. Yes, they are, even now, languages around that are even worse. But better ways have been around for ages. A similar example is garbage collection: It, too, has been around since basically the dawn of programming languages, but only made serious inroads into the mainstream in the last decades.

Honestly, Python 2.x's dynamic typing doesn't make the experience of floating-point/integer maths much better.

The value of 3 / x changing depending on whether I pass 2 or 2.0 is the trade-off of the Python approach, and I honestly don't know which I prefer.

Type inference like in ML languages can provide a similar development experience with the added benefit of performance and tooling.

Additionally when doing big projects where the team does not care for unit testing, dynamic typing can turn out to be a big problem.

Having said this, it has its places, I do use dynamic languages a lot, just not in big enterprise projects.

Reply on news.ycombinator.com