8 ms·

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

by noahm 10y ago

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"

behnamoh 10y ago
> 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 10y ago
  We can do more than that. If everybody followed the trend, then Lisp would be dead, and we'd all just write Java. shivers
  - behnamoh 10y ago
    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 10y ago
      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 10y ago
        Chicken + some plugins they provide are almost more than enough for most people! Great project.
        qwertyuiop924 10y ago
        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.
  - JBiserkov 10y ago
    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 http://clojure.org [2] http://clojurescript.org http://clojurescript.org
    - qwertyuiop924 10y ago
      Not a super fan of Clojure, but it's a good language. Shame it's still stuck in the Java ecosystem, though.
      - smnplk 10y ago
        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 10y ago
        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 10y ago
        Yes, there are a few aborted attempts. The problem with all languages that decide to implement their own runtime, instead of building it on top of JVM or .NET eco-systems is that their native code generation and GC implementation are always going to be worse. Also there is the issue of having to implement the whole set of third party libraries from scratch, just like PyPy and JRuby have issues using libraries that rely on CPython or Ruby FFI. So unless you get a set of developers really committed to go through the efforts of making it succeed, everyone will ignore it.
qwertyuiop924 10y ago
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).
gumby 10y ago
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 10y ago
  "Programming by successive approximation" is hardly scorn worthy in my mind.
  - gugagore 10y ago
    I too am left wondering, what is the alternative?
    - gumby 10y ago
      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.
nickpsecurity 10y ago
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 http://www.symbolics-dks.com/Genera-why-1.htm

by noahm 10y ago

behnamoh 10y ago

> 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 10y ago
We can do more than that. If everybody followed the trend, then Lisp would be dead, and we'd all just write Java. shivers
- behnamoh 10y ago
  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 10y ago
    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 10y ago
      Chicken + some plugins they provide are almost more than enough for most people! Great project.
      - qwertyuiop924 10y ago
        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.
- JBiserkov 10y ago
  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 http://clojure.org [2] http://clojurescript.org http://clojurescript.org
  - qwertyuiop924 10y ago
    Not a super fan of Clojure, but it's a good language. Shame it's still stuck in the Java ecosystem, though.
    - smnplk 10y ago
      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 10y ago
        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 10y ago
        Yes, there are a few aborted attempts. The problem with all languages that decide to implement their own runtime, instead of building it on top of JVM or .NET eco-systems is that their native code generation and GC implementation are always going to be worse. Also there is the issue of having to implement the whole set of third party libraries from scratch, just like PyPy and JRuby have issues using libraries that rely on CPython or Ruby FFI. So unless you get a set of developers really committed to go through the efforts of making it succeed, everyone will ignore it.

qwertyuiop924 10y ago

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).

gumby 10y ago

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 10y ago
"Programming by successive approximation" is hardly scorn worthy in my mind.
- gugagore 10y ago
  I too am left wondering, what is the alternative?
  - gumby 10y ago
    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.

nickpsecurity 10y ago

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 http://www.symbolics-dks.com/Genera-why-1.htm