Live data from Hacker News

Why we need Lisp machines

fultonsramblings.substack.com

151–160 of 220 posts

Re: Why we need Lisp machines

#151

Earlier quoted context omitted.

I think many people have conjectures, such as this one, but I don't think it's a tech problem, or a "Lisp is too powerful for its own good" problem. It's a "people aren't writing software" problem. History has demonstrated umpteen times that developing large, sophisticated, maintained, and maintainable projects in Lisp is entirely and demonstrably possible. Modern Common Lisp coding practices gravitate toward modular…

The obvious answer as to why people aren't writing software is that almost all of the people able to write good software don't like the language and are writing software in some other language or for some other platform. I know Lisp enough to have written programs of a few thousand lines in it. I'm not even slightly fazed by functional programming and (tail-)recursion instead of loops. I've read Steele's Common Lisp…

> I politely told them I thought their system could not practically be implemented in Lisp.

I'm curious to what that was, it sounds like a challenge more than anything.

I'm off a younger generation of programmers, and I've recently found lisp after coming from python. I still adore python and I can understand python's success, but I also adore lisp and its syntax, and I feel like I get the "powerful" argument for it.

For me, for what it's worth, I think the difficulties for lisp to join mainstream is really the thousands of little differences and gotchas that there's no single standard body looking after the users of the language. Princ instead of print, mapcars everywhere, etc. Trivial examples sure, but there's a lot that prevented me from making a few programs without doing through a book.

I'm not saying it's wrong, or it should be such and such a way. I am just simply comparing it to python and pointing to the first big elephant I come across.

Fwiw I also think that clojure is a lang that is capable of capturing more love because it's capable of tying in with Java ecosystem.. but it java is old and slow*; jobs in Java are slowing down, and clojure isn't filling in the gap, kotlin might be.

I take common lisp with me to holidays, because I like to learn it and all the funny words for things, but by far the lisp I use the most in day to day stuff is fennel, which is a lisp that compiles to Lua, and allows me to write plugins for neovim as well as a few other things that uses Lua.

TLDR: yes lisp needs software to be popular but it's not just a case of "make more applications" nor is the problem parents or operator precedence. People like sensibly named keywords.

I personally think things would be a little better if there was a CL to JavaScript transpilier, then you'd start to get some of the js crowd, same with python.

Re: Why we need Lisp machines

#152
post #123

Earlier quoted context omitted.

An unappreciated means of code reuse under *nix is the static and dynamic library. This seems to be the go-to whenever you need something more involved than simply reusing a full binary via pipes.

C's greatest feature is that it trivially maps onto .so files. Linking to and creating .so files isn't just cheap, it's effectively free. Most higher level languages I've worked with seem to focus on using .so files rather than producing them. This means the lowest common denominator for the unix ecosystem is what C can provide. Otherwise stated, unix is marching forward at the pace of C.

No wonder, given that C was created to turn UNIX from an originally Assembly written OS into a portable one, UNIX is effectively a C Machine.

Re: Why we need Lisp machines

#153
post #83

I'm as big of a Lisp fan as can be. I'm a proud owner of Symbolics and TI hardware: a MicroExplorer, a MacIvory, two 3650, and two 3620. Not to mention an AlphaServer running OpenGenera. Today, we have computers that run Lisp orders of magnitude faster than any of those Lisp machines. And we have about 3–4 orders of magnitude more memory with 64-bits of integer and floating point goodness. And Lisp is touted to have…

Personally, I think the problem is that CommonLisp is just another programming language, whereas Lisp really shines when it provides a full-fledged programming environment. Nowadays, it would seem best to create such an environment on top of commodity hardware as a "virtual machine" that abstracts away from the hardware in a general, portable way. However, a good environment (1) needs a purpose, and (2) somebody need…

To me development with SLIME is much better than with a fast-compiling language.

- Debugger is always ON.

- I can inspect the data I'm working with.

- I can redefine things without starting everything all over, avoid losing current context. Fast restart is not the same.

- I can evaluate pieces of code without the need of a REPL. Point to an s-expression and evaluate that piece of code, inspect the result.

I don't see how Smalltalk is much more interactive. It is more powerful at graphics and tools integration, but SLIME provides an interactive enough experience IMO, and it is significantly better to any fast compiling + restart language.

Re: Why we need Lisp machines

#154
post #48

Meh the problem is "Which Lisp?" There are dozens of incompatible Lisps. Even this site is written in a Lisp dialect written by its author (Arc). In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don't interoperate well. They haven't built up a big ecosystem of reusable code. Whereas Python, JavaScript, R, C, C++, and Rust programmers can reuse each others' code via Unix-sty…

> Meh the problem is "Which Lisp?" Not a problem - you don't need (or want ) a single Lisp. A hypothetical Lisp OS would support a standard runtime and typed IPC system that host programs can use (a la Windows and COM, or dbus), and nothing prevents you from using your own custom communication protocol over pipes/sockets instead. I don't agree with your implicit assertion that there is a single reason why Unix is mor…

This feels like a whole bunch of misunderstandings about what I'm saying ... Almost everything here was directly addressed in the article.

For that matter, why do you exclude the idea that JSON or XML aren't "common denominators" between Lisp programs, or even between Lisps, Python, and C++?

JSON is mentioned in the post as A narrow waist, not THE narrow waist (of an operating system or of the Internet). I also mention CSV and HTML as "on the same level".

Likewise, bytes and text have a similar hierarchical relationship. I mention that in the post and also show some diagrams in the previous post.

If anything, Lisps are more interoperable than Unix, because the "lowest common denominator" of Unix utilities is "plain text" (which by definition cannot encode structure), while the lowest common denominator of Lisps is some common subset of their s-expression formats, which can encode structure.

JSON, CSV, and HTML are all built on top of plain text. You can store them in source control and you can use grep on them, and you can build more specialized tools for them (which has been done multile times.)

What I'm contrasting this with is people who say that we should build s-expressions into the kernel -- i.e. passing linked data structures directly, rather than bytes/text.

See the threads linked in the posts -- a variant of this same argument came up. This is very related to the idea of building Lisp into hardware, which I view as a bad idea.

You say this, but you haven't given a reason for why that's the answer.

The article is analyzing why empirically Unix, the web, and the Internet have worked in multiple respects -- interoperability, generality, scalability in multiple dimensions and multiple orders of magnitude, extensibility over decades, the polyglot nature, etc.

These are obviously successful systems, and I think it is pretty crazy to have the opinion that because it makes you parse things that a design that tries to eliminate parsing much be better along many/all dimensions!

These kinds of (IMO naive) arguments are exactly why I wrote the last 2 posts. They were popular and highly commented upon, and most people got it, or at least appreciated the tradeoffs I highlighted.

So I don't need to convince everybody -- as I said in the intro to the post, the more important task is to build something that embodies these ideas. I look forward to your code and blog posts; I do think there is something to the top criticism in the thread: https://news.ycombinator.com/item?id=30812626

Re: Why we need Lisp machines

#155

I'm as big of a Lisp fan as can be. I'm a proud owner of Symbolics and TI hardware: a MicroExplorer, a MacIvory, two 3650, and two 3620. Not to mention an AlphaServer running OpenGenera. Today, we have computers that run Lisp orders of magnitude faster than any of those Lisp machines. And we have about 3–4 orders of magnitude more memory with 64-bits of integer and floating point goodness. And Lisp is touted to have…

> We don't "need" Lisp machines. We "need" Lisp software. What made a Lisp machines extraordinary wasn't the hardware, it was the software. Nothing today is impeding one from writing such software, except time, energy, willpower, and/or money. Discussed here https://news.ycombinator.com/item?id=30800520 The main issue is that Lisp, for all its inherent "power", has very limited tools for enforcing modularity boundari…

> . You can see the modern GC-based/"managed" languages, perhaps most notably with Java, as Lisps that avoided this significant pitfall.

An interesting perspective. From my POV, it's hard to think of a less Lisp-like language than Java. COBOL, maybe.

Re: Why we need Lisp machines

#156
post #48

Meh the problem is "Which Lisp?" There are dozens of incompatible Lisps. Even this site is written in a Lisp dialect written by its author (Arc). In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don't interoperate well. They haven't built up a big ecosystem of reusable code. Whereas Python, JavaScript, R, C, C++, and Rust programmers can reuse each others' code via Unix-sty…

> In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don't interoperate well. They haven't built up a big ecosystem of reusable code. And why are there so many? IMO the language is too flexible for its own good. It promotes this curious intellectual solo-competition where you try to prove you are worth of the elite who get all the fancy FP stuff and make all this bespoke func…

Haskell has its share of fancy FP stuff, and people manage to develop workable things in it. I still think Lisp really is too dynamic to be useful beyond a small scale of development.

Re: Why we need Lisp machines

#157
IMO the biggest difference is that that there is no longer a difference between binaries and libraries. Everything is a library. In UNIX there are a bunch of utilities which you just can't use from C. Also the idea of just passing data structures around instead of using a pipe passing streams of characters around is an improvement since there is no longer the need to serialize / deserialive it.

Re: Why we need Lisp machines

#158
post #125

Earlier quoted context omitted.

> people aren't writing software Maybe not OSS, but somebody is keeping Lispworks and Franz in business.

I'd love to know who. The example apps in Lispworks site aren't commercial successes, as far as I know.

Looks like it's just a small unit in an office park in the tech center in Cambridge: http://www.lispworks.com/contact.html

It doesn't really take many contracts to scrap together office park rent and a staff of a few people. We're talking like Good on them. Not every company needs to try to be the next Amazon

Re: Why we need Lisp machines

#159
post #123

Earlier quoted context omitted.

An unappreciated means of code reuse under *nix is the static and dynamic library. This seems to be the go-to whenever you need something more involved than simply reusing a full binary via pipes.

C's greatest feature is that it trivially maps onto .so files. Linking to and creating .so files isn't just cheap, it's effectively free. Most higher level languages I've worked with seem to focus on using .so files rather than producing them. This means the lowest common denominator for the unix ecosystem is what C can provide. Otherwise stated, unix is marching forward at the pace of C.

This is one of the things I like so much about Lua, LuaJIT in particular: it's designed around being just another .so file, from another clib's perspective Lua is a library for manipulating a calling stack, and the LuaJIT ffi makes it short work to adapt a header file so that structures and functions can be used from within Lua.

Re: Why we need Lisp machines

#160
post #48

Meh the problem is "Which Lisp?" There are dozens of incompatible Lisps. Even this site is written in a Lisp dialect written by its author (Arc). In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don't interoperate well. They haven't built up a big ecosystem of reusable code. Whereas Python, JavaScript, R, C, C++, and Rust programmers can reuse each others' code via Unix-sty…

The canonical Lisps still widely used today are Common Lisp, Scheme and Emacs Lisp. They all belong in the same family, and syntax / semantics are close. Porting code from Scheme to Common Lisp can be a lot easier than going from Python 2 to Python 3. Clojure is something else entirely which is why a lot of people don't consider it a Lisp. > Honest question: how do you communicate between two Lisp processes on two di…

> Common Lisp, Scheme and Emacs Lisp... all belong in the same family

Could you say more about what you mean by this? Is there another family of Lisps that excludes these three? I've met people who make a big deal about lisp-1 vs lisp-2 (https://en.wikipedia.org/wiki/Lisp-1_vs._Lisp-2), and which is the right way to be a Lisp, but I think maybe those people just enjoy being pedantic.

Post reply on HN