[noahm]

I used to work with a number of LISP machine believers at the MIT AI Lab/CSAIL. They all had more modern computers for day to day tasks, but used the lispm for most of their programming. This wasn't that long ago (I left in 2010), and I suspect that those machines will remain in active use for as long as people can keep them running.

They all believed that the loss of the lisp machine was a serious loss to society and were all very much saddened by it. I never used the system enough to come to my own conclusions in that regard, but it was interesting food for thought. As somebody for whom Linux/POSIX is very deeply entrenched, would I even recognize a truly superior system if it was dropped in my lap? More importantly, would society in general? The superior technology is rarely the "winner"

[gumby]

It was by far the most productive programming environment I have ever used. The level of integration of the editor, debugger, IO system, and interpreted and compiled code is unparalleled. Interestingly it philosophically descended from MACLISP development on a machine (PDP-10) that was designed with Lisp in mind and that had an O/S (ITS) whose "shell" was a debugger, so you could also do pretty tightly coupled development with EMACS (in TECO) and your code in a mix of interpreted and compiled Lisp. In theory this deep level of integration need not be Lisp-specific, but I haven't seen it that often.

The closest I've used were the three environments at PARC when I was there: Smalltalk, Mesa/Cedar and Interlisp-D. When I use Xcode or Eclipse I feel removed from the machine. In these other environments I felt simultaneously able to think at a higher level and yet more tightly coupled to the hardware.

I've used various GNU Emacs modes and the coupling between them and the runtime environment is not tight enough. Today I use SLIME+SBCL and it's OK. It too lacks the tight coupling of the lispm. However for production we'll end up re-coding in C++ for performance.

PS: A good friend of mine scorns the lispm-style of development as "programming by successive approximation." There's some truth in that.

[kjhughes]

"Programming by successive approximation" is hardly scorn worthy in my mind.

[xenophonf]

I prefer to think of it as "rapid prototyping".

[gugagore]

I too am left wondering, what is the alternative?

[gumby]

Well, with exploratory programming you tend to build up a couple of data structures, add some functions to manipulate them, and then extend out from there. In a more structured way you think up front about a lot more things. In the second you probably doodle some stuff out on the whiteboard or on paper before coding; in the first you probably simply start with an empty buffer type straight into the REPL. There's a time and place for each and certainly not a well-defined dividing line between the two (except in some highly structured UML/TDD processes which may not even exist any more outside aerospace).

For example I talked about the Lisp implementation of the code I'm working on: for deployment it looks like it'll be be an implementation in C++ based on what we end up learning about performance; certain implementation decisions that were particularly good or particularly bad, or that we iterated on several times before settling on something good; and that handles memory management more directly.

[jacquesm]

> programming by successive approximation

That's called 'Agile' nowadays...

[pjmlp]

How was using Mesa/Cedar?

From my Native Oberon experience and having devoured all Xerox PARC related papers, I imagine it was a great experience.

But having used the real thing is quite different assessment.

[gumby]

It was fun although at that point in my life I was not comfortable with statically typed languages. So it was good for me as well.

I really just experimented in it and the (more welcoming to me) Smalltalk environment. I used InterLisp-D as my "day job" language (actually we implemented 3-Lisp in it, with some custom microcode).

BTW there was a good paper from the Mesa group which I can't find online (my copy must be buried in a box someplace) comparing the performance of counted strings vs delimited strings (e.g. [3, 'f', 'o', 'o'] vs ['f', 'o', 'o', \0] in C syntax). According to the paper the bounded strings were much faster. All three languages (Smalltalk, Mesa and Lisp) used counted strings.

[pjmlp]

I think that is the one discussing about ropes structures.

Thanks for the feedback.

Nowadays I use .NET and Java environments as an "almost like" experience of what mainstream computing could have looked like.

But when I see companies like Apple releasing playgrounds, Oracle adding a REPL and the edit/continue and REPL in .NET, there is some hope left.

[gumby]

> I think that is the one discussing about ropes structures.

No, this was simply counted vs terminated strings. I would like to find that paper and revisit the data again to see if it is still true.

[anthk]

Emacs + Geiser + Scheme =)

[behnamoh]

> The superior technology is rarely the "winner"

True dat. Unfortunately, as Theo de Raadt once said:

"In some industry markets, high quality can be tied to making more money, but I am sure by now all of us know the computer industry is not like that."

I think the only thing we can do is follow the trend. This whole industry is not perfect anyway.

[qwertyuiop924]

We can do more than that. If everybody followed the trend, then Lisp would be dead, and we'd all just write Java.

shivers

[JBiserkov]

Thankfully Rich Hickey & co wrote Clojure so we can program on a modern Lisp in the Java Virtual Machine and in the browser! (ClojureScript) (even the .NET CLR is supported)

[1] http://clojure.org

[2] http://clojurescript.org

[shakna]

Though it kind of sucks that Tail Call Elimination is such a difficult task on the JVM.

Scheme kind of gets you thinking in a way that works iteratively, but gets expressed recursively. Its easy to read, and can make for some great optimisation without being premature.

The JVM does not really support this style of programming - despite LISP's syntax leading towards it.

[ScottBurson]

Ironically, the Lisp Machines didn't have TCO either.

[shakna]

I wouldn't say that it was appropriate there, either.

I really wish I could get my hands on a LISP Machine.

I love the idea of LISP being so close to the metal, but that power means some design tradeoffs.

Scheme makes sense with TCE.

I'm not sure InterLISP and the like need it - memory is limited and you work without so many of the system overheads I'm used to with modern systems. Iteration is less costly here, and that makes it easier to not need recursive design. (Which is more expensive).

In simple terms:

Why worry about blowing up a stack you don't need, when you've thought long and hard before you allocated it?

[qwertyuiop924]

One of their great failings. I'm a Scheme user, so I feel a bit weird without TCO.

[JBiserkov]

Funny enough, it seems JavaScript will get TCO before Java. JavaScript, for f*ck's sake! This will provide even more argumentative power to the people who claim JavaScript is 'Scheme in C clothes'.

[smnplk]

recur in clojure is also easy to read in my opinion.

[shakna]

True.

However, a named let in Scheme is not a loop. Its still a lambda.

Which means you can have nested lets with TCE, and you can construct them on the fly, depending on what your needs are, usung patterns like currying.

That flexibility just doesn't work on the JVM. You can force it, but it'll be slow and horrible compared to another pattern - and I don't think a LISP should tell me how to do something. That's Python's ideology.

[qwertyuiop924]

Yeah, it's super nice.

[qwertyuiop924]

Not a super fan of Clojure, but it's a good language. Shame it's still stuck in the Java ecosystem, though.

[smnplk]

I believe the whole point was to target the JVM, because of reuse and maturity. And actually it's not stuck just in java ecosystem, clojure got wings years ago. Yoy can find it inside a browser today too :)

[metaobject]

I wonder if there ever has been talk of a native Clojure? I guess it may not be very usable without the JVM ecosystem, though. Frankly, I find calling JVM library calls from Clojure to be quite ugly and really stand out in the code (mostly because of the mix of the lower-case-dash-delimited variable and fn nameing convention of Clojure and the mixed-case/camelCase naming style of Java.

[pjmlp]

Yeah, but for many of us the Java ecosystem is a feature.

You only get tooling comparable to Visual VM or Mission Control in commercial Common Lisps.

Also I think many that bash Java don't realise it is the only language ecosystem that matches C and C++ in availability across OSes, including many embedded ones.

[qwertyuiop924]

I realize, I just can't stand the ecosystem. Everything is super verbose, frustratingly overcomplicated, and full of XML. Yuck.

[pjmlp]

Even though I prefer static typing to dynamic typing, Clojure is a pleasure to do some coding for fun while traveling.

It would be nicer if the performance was better though, many that only know Java via Clojure don't realize the performance impact of Clojure.

At least 1.8 did had some improvements in that direction.

[behnamoh]

I used to think likewise (you can check my previous comments). But at the end of the day, you gotta pay the bills...

Nonetheless, I have huge respect for CL. I think I'm gonna learn it well once and for all. (maybe use it for back-end).

[qwertyuiop924]

True 'nuff.

I prefer Scheme to CL. The tooling isn't as developed, but Chicken and Guile are both plenty usable, and Scheme is less crufty than CL.

[sotojuan]

Chicken + some plugins they provide are almost more than enough for most people! Great project.

[qwertyuiop924]

Indeed. It's actually my preferred language for writing code. It may not have as many libraries, and it might not be as mature as, say, CL, but it's just so pleasant to program in.

[qwertyuiop924]

The blub paradox would indicate that you wouldn't recognize it.

Richard P. Gabriel's famous "Lisp: The Good News, The Bad News, And How To Win Big" (aka "Worse is Better") discusses this very thing. I'd reccomend reading it.

But frankly, it's hard to say that an environment is objectively better. What one person may view as a step up, another may view as a step down, and we all have a kneejerk reaction to unfamiliar environments. The lispm is a really nice environment, to be sure, but I'll likely never know if it's better. Emacs will have to be good enough (which it certainly is).

[nickpsecurity]

There's still significant things on the list below you cant do with Linux, C, etc. So, yeah, I'd say a modern version of Genera would give hou a worthwhile experience.

http://www.symbolics-dks.com/Genera-why-1.htm