Comment by hga | Hacker News Reader

Comment by hga | Hacker News Reader

Parent Full thread

Lisp lucked out in the temporary hack of s-expressions plus its basis in the lambda calculus such that it has managed to modernize itself without too many changes in its essential nature. E.g. there are I would say (from my '80s and on background) three major changes, each more "modern" than the next:

Mainline Lisp, which is for the most part stuck in amber with Common Lisp.

Scheme, which is semi-stuck in its MIT design style "do it right or not at all".

Clojure, the new hot Lisp that many think is the future of Lisp.

Scheme made some major departures from mainline Lisp, only one of which was adopted by the later (static scoping and all that implies (I now forget how good its support for closures is)).

Clojure is a further departure: not very multi-paradigm (and much more functional than Scheme) and its unification of data types (lists, maps, etc.). It's also like Scheme in getting rid of a lot of legacy cruft (starting with cons!) but is not an essence of purity language like Scheme, e.g. while a Lisp-1 it has mainline Lisp style macros.

So I'd say it's "more modern", e.g. its embrace of STM, which is an idea of the mid-80s to mid-90s. Most other new Lisp dialects strike me a "yet another Lisp"; I'm not sure about Arc, though.

I agree at least in part with the comment you are replying to, a modern language needs concepts newer than the '60 and 70s (closures are I think the only '70s concept in what Flow enumerated).

While its mathematical roots are fairly old, aggressive Hindley–Milner style type inference is I think a "modern" language concept. '70s at least???

Aggressive Hindley-Milner inference is old but getting it to mesh well with the OO concepts that developed independently of it (subtyping/inheritance, run-time polymorphism, virtual functions, etc.) is seriously tricky and is an area of cutting-edge research. I'm not a type theory expert but my impression of the current state of things is that you can have aggressive HM inference (infers the type of everything and does so correctly) or OO language features but not both.* If you want both you have to settle for "best effort" inference where the compiler infers things when it can but sometimes needs the programmer's help. This flavor of inference is just now (within the last decade) making it into mainstream languages, cf. C#'s var, C++0x's auto/decltype, Scala, etc. And ooc's inference appears to work this way too (or at least it's going to.) So how is this not modern? What are the "modern" features that ooc language is missing?

* My limited understanding of Ocaml is that it supports both, but nobody uses the OO features of the language so I assume there's a reason for that.

"What are the "modern" features that ooc language is missing?"

Good question; I'm not up enough on this direction of languages to answer.

It has closures, as noted.

One might say that functional programming is new again, or at least strong functional programming where you have guarantees that certain varieties (almost said "classes" there, which in this context would be confusing at best :-) of data will not change out from under you. Haskell has this, of course, as does Clojure in a weaker form.

What about first class continuations? Continuations per se are too basic to be entirely modern, e.g. Steve Russell, inventor of obscure things like Spacewar and the Lisp REPL invented them for the second implementation of LISP (on the vacuum tube 704), but they weren't first class until Scheme in the 1975 (all this according to Wikipedia, and Scheme's aren't quite first class enough for my tastes).

Modern concurrency stuff? For that matter, what's its concurrency story? A search for various keywords like that, thread and SMP didn't find anything.

I'm sorry to say that I personally am only interested in new languages that have a good concurrency story, that and languages per se are the only areas of pure CS that I find interesting. (And of course I have Clojure for concurrency.) If it's "functional-ish" but not functional enough, it might be hard to graft that onto the language.

Don't be sorry by what you're interested in =)

Concurrency is obviously one of the last points (with exceptions) to tackle before we throw together a 1.0 spec.

We haven't settled on a final solution there, but there are definitely discussions and hacktivity in that area.

We're not so foolish as to pretend to be a modern language without even caring about concurrency =) It just takes some time to get it right.

"We're not so foolish as to pretend to be a modern language without even caring about concurrency =)"

I was wondering.... You might want to make a note of that on the home page, as well about exceptions.

"It just takes some time to get it right."

Indeed, as do exceptions. Go doesn't have them yet, many languages have problems with them, especially if grafted on later, and I know they were a work in progress (well, the work had about finished, I think) when I left the Lisp Machine community in mid-1983.

If I wasn't in love with Lisp, i.e. if I hadn't started programming in 1978 and therefore had long ago established a variety of preferences, I might well be interested in your language, it does have variety of tasteful features. I wish you luck.

while I don't want to fall too much into vaporware, the homepage mention might indeed make sense.

Thanks for the luck-wishing, we'll definitely need it.

However it ends up, it will still have been a wonderful journey. Every programming experience should be so.

You're very welcome.

I understand the vaporware concern, but if you e.g. are saying to yourselves "this won't be successful without concurrency" then you might as well mention it as an in progress feature. If you are at least playing around with it, serious discussions, designs or even have cut a little code for it, that's not dishonest in any way.

For a lot of people, including myself, it's now a "checklist" feature. So are exceptions, but those are a bit obscure, or perhaps more appreciated by the more experienced or something like that. Those who know about these things also know they're hard to do (right).

Reply on news.ycombinator.com