Hacker News Reader

Comment by Crito | Hacker News Reader

> "Plus, the (classic intro-to-LISP) notion that "it has a simple syntax with few constructs so it must be easy to program in" has to die. Assembly has very simple syntax too. I wouldn't write a large program in it."

Suppose we amend that to simple high-level constructs?

I don't think I've ever picked up a language as fast as I picked up scheme. Not even python.

View on HN

Scheme's extremely simple* but it's a perverse simplicity.

My experience from tutoring CS students in Scheme back in the day was that it usually either clicked immediately, or not at all. The folks who'd perhaps never get good at it aren't necessarily poor programmers. I don't know that any of them were great programmers, but that might be my prejudice as someone who was having a hard time teaching them a programming language. Some of them went on to get more impressive ones than the one I have, so probably definitely it was just prejudice. Anyway, the point remains, I've met a lot of people who struggled with Scheme, and it was most certainly not for want of smarts. My best guess is that it's just that the language is only suitable for people who have a certain approach to thinking that's perhaps unusual.

* And beautiful - easily one of the most lovely languages I know.

I believe this is where Common Lisp got it right and scheme got it wrong. The scheme designers wanted a more pure language when often, the dirty imperative method is desirable. Common lisp has many features to make programming of real, large-scale projects easy (a great example is looping constructs which are often more obvious and easier than the more 'pure' tail recursion preference of scheme).

Scheme has plenty of dirty imperative methods, if you want. Their names end with `!`, like `set!` to mutate a variable. In most cases it's cleaner to be purely functional, but it's not required.

Predicates end with `?`, like `equal?`.

This naming and consistency makes it easier to learn Scheme.

What makes Common Lisp more practical is libraries. Hairy and crufty some may be, but many of them, and many of good quality. You know the old saying about how X is a badly implemented version of half of Common Lisp.

The Scheme-descendant Racket is, however, plenty practical in this regard.

I really don't like the Common Lisp naming and the 2-space nature of the language makes this even worse. The conflict of the implementors appears in many places. I like many things about scheme, but I won't whitewash it's problems.

Non-standard, non-portable racket libraries aren't the answer to scheme's basic nature (though I believe r7rs-large will solve a lot of these issues). More serious dealbreakers in my work are the lack of declare, no built-in OOP, and no spec for optional and keyword parameters.

Scheme has other issues too such as the inability to turn off continuations (they are great in some situations, but can cause performance issues and specifically cause increased memory usage).

Racket's extensive collection of libraries aren't meant to answer anything about Scheme -- they're for Racket. That's why we changed the name.

Racket is, however, a great answer to "is there a Lisp that's both conceptually consistent and has lots of libraries".

If you're using it seriously and for a significant period of time, the time and effort spent initially learning a programming language ends up becoming a smaller and less relevant factor.

What ends up mattering most is how productive you are once you're familiar with it. This is where a language like Python, and most other widely used languages, tend to be much better than Scheme for most programmers.

Scheme may be easier to learn initially, but it's generally much less useful in the long run in most cases.

The discussion might be irrelevant, but nevertheless the discussion is about ease to learn.

Racket is the answer to schemes practicality problems.

Reply on news.ycombinator.com