Bill Clementson

Sigh. I followed this discussion on c.l.l and it was too painful to contribute to. I was hoping it wouldn't follow me here, but since it's here, I guess I'll put in my $0.02. I trust HN readers more than c.l.l.

No one denies the power and goodness of Lisp. Also, everybody knows its issues

1) misconceptions based on its history (it's a slow, AI language)

2) portability issues among implementations (pathnames, sockets, GUI, etc

3) lack of standard implementation

#1 is a marketing problem - tractable with effort (just look what pg's essays alone have done). #2 is a coding resource problem - many hands make light work.

For #3, once there is a platform implementation with all the right features (threads, unicode), this problem goes away. If CLisp added threads or if SBCL worked on Windows, the game would be over - other implementations would continue but there would be an unambiguous choice for n00bs. De facto portability standards would form around that implementation and the burden would be on other implementations would make it compatible with the de facto winner.

I'm not invested in any of the implementations but it looks to me like SBCL is the closest to being the full featured, cross platform, open source implementation that is currently lacking. So as a pragmatist wanting Lisp to become bigger, I have three choices:

1) through my writing, encourage people to choose SBCL

2) contribute coding help to the SBCL windows port

3) whine

Most people choose #3. …

I am reminded of an oldie but a goodie: http://bc.tech.coop/blog/081201.html

Rich Hickey's quote I found interesting from the above article:

"There are other ways to model identity and state, one of the more popular of which is the message-passing actor model, best exemplified by the quite impressive Erlang. In an actor model, state is encapsulated in an actor (identity) and can only be affected/seen via the passing of messages (values). In an asynchronous system like Erlang's, reading some aspect of an actor's state requires sending a request message, waiting for a response, and the actor sending a response. It is important to understand that the actor model was designed to address the problems of distributed programs. And the problems of distributed programs are much harder - there are multiple worlds (address spaces), direct observation is not possible, interaction occurs over possibly unreliable channels, etc. The actor model supports transparent distribution. If you write all of your code this way, you are not bound to the actual location of the other actors, allowing a system to be spread over multiple processes/machines without changing the code.

I chose not to use the Erlang-style actor model for same-process state management in Clojure for several reasons:

* It is a much more complex programming model, requiring 2-message conversations for the simplest data reads, and forcing the use of blocking message receives, which introduce the potential for deadlock.…

I see. Yeah, I stand corrected.

I was conflating continuation-based and closure-based webservers because both allow straight-line code instead of explicitly managing url handlers.

And the traditional rhetoric in favor of this technique has come from Seaside, which popularized the name 'continuation-based' (http://www.linux-mag.com/id/7424; http://www.bluishcoder.co.nz/2006/05/server-side-javascript.html)

I'd never seen anybody say this is just an early-prototyping technique. But searching found Patrick Collison concur: http://www.quora.com/Whats-the-best-continuation-based-web-framework

It was too harsh to say it paints us into a corner; it is possible to replace fnid links with new defops. I went back and looked at the frontpage when not logged-in, and saw that there are 0 fnid links in that common case. (One possible way to gradually use a second server would be to just serve the frontpage off it. You'd need to move to a centralized store for user/profile/story objects, but the fnids table could continue to live on one server.)

It also turns out that there's at least one company trying to scale continuation-based servers (http://bc.tech.coop/blog/040404.html). So it was overly harsh to call it a dead end.

So, Yahoo acquires Viaweb and rewrites it. The end result
is inferior to the original Lisp-based product. Sony
acquires Naughty Dog and decides to eliminate the
Lisp-based development infrastructure. The end result is
an inferior game development environment. Sure, there
were probably a lot of reasons for these decisions by
Yahoo and Sony (probably none of which had anything to do
with productivity or technical excellence - large
companies have other drivers which have more importance
than these two); however, the end result for both
companies has been something inferior to what they
originally acquired.

Quoted from http://bc.tech.coop/blog/060118.html

Edit: The post has more about in what respect the author considers the replacements inferior.

Yeah, If you are being bogged down by legacy code and increasingly falling behind competitors due to slow innovation, it makes sense to do a rewrite. Mozilla had nothing to lose by a rewrite and everything to gain. In the short term they suffered immensely falling behind even more but in the long term it helped them emerge stronger.

It is the same with Classic Mac -> OSX. The former was crumbling under its own weight but OSX enabled Apple to out innovate others.

The key point is that a rewrite should always produce something better and leaner. Two cases where it didn't happen are

* In case PG's viaweb -> Yahoo store. http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02367.html

* When Sony acquired Naughty Dog. http://bc.tech.coop/blog/060118.html

a Porsche from 1970 is still awesome. There are many things that have timeless qualities. Every time I hear 'The Man Machine' from Kraftwerk I think how awesome it is.

'The Grand Canyon is awesome' - how does that depend on WHEN I see it. As long as there is a Grand Canyon, it is awesome. It is of no concern if there are things less or more awesome. The Grand Canyon is just 'awesome'.

Lisp has for some people also timeless qualities. One of these people is Alan Kay (of Smalltalk, Dynabook, etc.) fame. Check some day what Alan thinks about Lisp: http://bc.tech.coop/blog/060224.html

"Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science."