Comment by striking | Hacker News Reader

Comment by striking | Hacker News Reader

Parent Full thread

They were powerful desktop workstations (first of their kind!) They had up to 40 bits per instruction word in a tagged architecture, so a byte could be identified by object type without having the program say it outright. The processor was a stack machine that ran a bytecode compiled version of Lisp that did type checking and dispatching, in hardware, at runtime. Some of them had very powerful graphics boards that did all kinds of rendering.

tl;dr: They had special hardware that aided in dynamic language processing, like 40-bit words and hardware dynamic dispatch.

And it would not help you at all today because the most prohibitive part of the system is really the size of the CPU silicon wafer and its efficiency, and C is faster than Lisp and people are totally okay with writing code in it.

EDIT: RE: getting into Lisp in a big way: https://web.archive.org/web/20080709051856/http://www.lambda... tells you all you need to know. Specifically:

"And the problem with Lisp? The answer is tailor made for the minds who program it. It is the koan of Lisp.

"The answer is that there is no problem with Lisp, because Lisp is, like life, what you make of it."

Your Lisp code (unless it's an emacs tool) will never work with anything or anyone else. You're invited to write everything from scratch, and doing so is easy; it's just difficult for anything you do to be used by or with anyone else's code.

Lisp is so beautiful, and yet so dangerous.

> Your Lisp code (unless it's an emacs tool) will never work with anything or anyone else.

I wonder how the Lisp I'm using got its Cocoa user interface. Oh, it has an Objective C bridge, so that it can create natively looking Mac applications...

CCL is dead, move on :P

I was not talking about CCL.

CCL is also not dead.

CCL is not dead. It's the best choice for Windows and also for ARMs (like Raspberry Pi), because SBCL doesn't have native threading support on the latter.

> Your Lisp code (unless it's an emacs tool) will never work with anything or anyone else. You're invited to write everything from scratch, and doing so is easy; it's just difficult for anything you do to be used by or with anyone else's code.

Not really true these days, with the prolifiration of high-level-languages most libraries present a C interface which is no harder to bind to lisp than to other languages.

"Your Lisp code (unless it's an emacs tool) will never work with anything or anyone else. You're invited to write everything from scratch, and doing so is easy; it's just difficult for anything you do to be used by or with anyone else's code." - That might have been true once, but arguably isn't true any more, now that we have Clojure, ClojureScript, ClojureCLR, ABCL, Kawa, etc. And if you are willing to go for a multiprocess solution, there are numerous ways to integrate multiple languages over IPC or the network, from decidedly old-fashioned approaches like ONC RPC or CORBA, all the way through to the REST microservices of today, and there exist Lisp bindings for all of them.

> Your Lisp code (unless it's an emacs tool) will never work with anything or anyone else. You're invited to write everything from scratch, and doing so is easy; it's just difficult for anything you do to be used by or with anyone else's code.

Since everyone else is jumping on this point, I might as well also point out that there are things like Chicken Scheme that actually transpile to C and are therefore compatible with it (and anything else that's compatible with C).

> and C is faster than Lisp and people are totally okay with writing code in it.

While C is indeed faster than Lisp (sometimes, at least; IIRC, some Common Lisp implementations like SBCL come within the same ballpark depending on the code being worked with), people are decreasingly comfortable with it as alternatives emerge and the cost of running a high-level language decreases (originally due to Moore's law, but nowadays also due to better-optimizing compilers and interpreters). I expect that we'll eventually hit a point where - much like how it's very difficult (if not borderline-impossible) to produce hand-written assembly that's faster than what a compiler will generate - it'll also be very difficult to write any sort of low-level code in a way that's faster than what a HLL compiler will spit out.

Reply on news.ycombinator.com