Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp Machine Manual (1984)

hanshuebner.github.io

Post reply on HN
Print view View original

41–50 of 165 posts

Re: Lisp Machine Manual (1984)

#41

Post by fusiongyro »

AnimalMuppet wrote: post #36
fusiongyro wrote: post #18

Earlier quoted context omitted.

A more powerful language is not enough of an advantage to defeat entrenched alternatives with strong network effects. There isn't a reason why language X is not entrenched, but there are historical reasons why C, C++ and Java are entrenched. Lisp just isn't enough more powerful than them to beat their home-court advantage. I guess I'd say, Lisp might be 10x better, but the network effects are orders of magnitude more…

> Lisp just isn't enough more powerful than them to beat their home-court advantage. Note, however, that Lisp had a 10 year head start on C. Lisp had the home-court advantage, and C ate its lunch anyway.

Lisp had a 10 year head start on expensive academic machines that were low on industry uses. C had a head start on high-end mainframes for actual work. Then the main contenders on the nascent PC were assembly, C and Pascal. P-code based compilers arrived quickly and were faster to develop with, but the resulting code was inefficient—and early PCs were sufficiently resource-constrained that inefficient code was very noticeable. So C obtained the territory that mattered: high-end business machines and the low-end machines that would spark the computing revolution, and just had to grow the two together.

Lisp had a head start, but wasn't on the track that mattered.

Re: Lisp Machine Manual (1984)

#43

Post by kazinator »

dwheeler wrote: post #21
hoodoof wrote: post #2

There seems to be plenty of people who think Lisp is awesome. If so, then why hasn't it become "mainstream"?

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple , bu…

If we randomly sample no-longer-used languages, I suspect we will see infix support more often than not. Infix won't save a language.

> fact many people believe programs in Lisp syntax are hard to read.

It's not a fact; it's just a couple of trolls, plus people just repeating what they have heard. People who reply to "lisp" with "lots of irritating silly parentheses" haven't necessarily even tried to read any examples of Lisp; they are just repeating a joke they heard.

Just like how people who say "fix it again, Tony" when they hear "Fiat", who have never driven a Fiat, and have no idea about the statistics of Fiat reliability relative to other makes of car.

Re: Lisp Machine Manual (1984)

#44

Post by lispm »

Animats wrote: post #22
fusiongyro wrote: post #8

The classic joke in here is that if you look up "fascism" in the index, it goes to the section about logging in. User authentication wasn't part of the dream, so having been forced to build it, they embedded a dig on it right in the manual. https://hanshuebner.github.io/lmman/files.xml#fascism I think there are a few other jokes in the index but I don't recall what they are.

That was probably Stallman's doing. He wrote most of the LISP machine code.

> He wrote most of the LISP machine code.

That's nonsense. The Lisp Machine code was written by several people, some which had significant contributions.

Re: Lisp Machine Manual (1984)

#45

Post by [deleted] »

AnimalMuppet wrote: post #25
setzer22 wrote: post #9

Earlier quoted context omitted.

I don't see why language quality should have anything to do at all with mainstream usage. PHP can be considered a mainstream language today. Even COBOL in some parts of the industry. Are they any better because of that?

Well... for a language to succeed long-term, it needs to be either significantly better than the alternatives (at some particular kind of use), or else it needs to be entrenched in existing code. When C began to spread, it was significantly better than alternatives for writing operating systems and associated tools on commodity hardware. Part of that "better" was cost - cost of the machines it ran on, cost of buying…

[deleted]

Re: Lisp Machine Manual (1984)

#46

Post by cat199 »

fusiongyro wrote: post #8

The classic joke in here is that if you look up "fascism" in the index, it goes to the section about logging in. User authentication wasn't part of the dream, so having been forced to build it, they embedded a dig on it right in the manual. https://hanshuebner.github.io/lmman/files.xml#fascism I think there are a few other jokes in the index but I don't recall what they are.

not surprising since many of the early lisp people grew up on ITS which had a built in 'crash' command available to all users which crashed the system..

https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste...

Re: Lisp Machine Manual (1984)

#47

Post by progman »

dwheeler wrote: post #21
hoodoof wrote: post #2

There seems to be plenty of people who think Lisp is awesome. If so, then why hasn't it become "mainstream"?

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple , bu…

Your perception confirms my previous post that mediocre developers have a hard time to think in different ways, even to code in non-infix notation. Linux suffers a similar problem. Many people are so used to Windows desktops that they have a hard time to think in different ways, and to appreciate the Linux way which provides not one common desktop but many ones which can freely be chosen.

It reminds me of the quote "Who knows only hammers as a tool considers every problem a nail".

Also the typical claim that LISP just means "lot of silly parentheses" points out that those critics have never tried to develop in the Lisp way. Ironically, as time goes on and complexity rises, more and more developers appreciate new features which have been available in Lisp for more then 50 years -- lambda expressions, maps, and macros for instance. Lisp was so far ahead of its time that people today still have problems to realize what is so fascinating about Lisp, and why Lisp machines are so awesome. They should take a look at the graphical shell [1] of McCLIM [2] (a revival of the famous CLIM GUI) to see that powerful desktop computing can be very different.

[1] https://common-lisp.net/project/mcclim/static/media/screensh...

[2] https://common-lisp.net/project/mcclim/excite.html

Re: Lisp Machine Manual (1984)

#48

Post by ScottBurson »

lispm wrote: post #44
Animats wrote: post #22

Earlier quoted context omitted.

That was probably Stallman's doing. He wrote most of the LISP machine code.

> He wrote most of the LISP machine code. That's nonsense. The Lisp Machine code was written by several people, some which had significant contributions.

Indeed. Before they left to found Symbolics, David Moon, Howard Cannon, Dan Weinreb, and others (I'm sure I'm forgetting at least one name) wrote the vast bulk of the system. I think Richard Greenblatt wrote most of the microcode (he also did most of the hardware design and construction).

After Symbolics formed, RMS did an amazing job at reimplementing many of the new features Moon and company were adding, so as to keep the MIT version of the system at rough parity with the Symbolics version. So his name belongs in the story, but not first.

Re: Lisp Machine Manual (1984)

#49

Post by AnimalMuppet »

fusiongyro wrote: post #41
AnimalMuppet wrote: post #36

Earlier quoted context omitted.

> Lisp just isn't enough more powerful than them to beat their home-court advantage. Note, however, that Lisp had a 10 year head start on C. Lisp had the home-court advantage, and C ate its lunch anyway.

Lisp had a 10 year head start on expensive academic machines that were low on industry uses. C had a head start on high-end mainframes for actual work. Then the main contenders on the nascent PC were assembly, C and Pascal. P-code based compilers arrived quickly and were faster to develop with, but the resulting code was inefficient—and early PCs were sufficiently resource-constrained that inefficient code was very n…

> C had a head start on high-end mainframes for actual work.

No. C started on low-end minicomputers, not high-end mainframes.

And why didn't Lisp take over the low-end minicomputers? Because Lisp was too resource-hungry, and those low-end minicomputers didn't have the muscle to run Lisp well. They ran C just fine, though.

Post reply on HN