[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 =)