Live data from Hacker News

Lisp Machine Manual (1984)

hanshuebner.github.io

81–90 of 165 posts

Re: Lisp Machine Manual (1984)

#81
post #44

Earlier quoted context omitted.

> 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 k…

The MIT version was commercialized, too. Lisp Machine Inc. employed Stallman and Greenblatt, and was back primarily by Texas Instruments.

Re: Lisp Machine Manual (1984)

#82
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?

According to TIOBE, in 1987 only C was more popular than Lisp. Thirty years later, C is #2 and Lisp is #31. Lisp was mainstream and for some reason other languages overtook it. I think it's a good question.

[deleted]

Re: Lisp Machine Manual (1984)

#83

Earlier quoted context omitted.

I also dream of what it would be like if lisp in the browser had become mainstream, but it's possible that if he had implemented it like he wanted to, it wouldn't have received such wide spread adoption like javascript did.

True. My optimistic/pessimistic daydream is that, as the only game in town for some period of time, it would have introduced enough developers to the language to really give it traction. We'd now be seeing people asking "Why can't I run the same language on the server as in the browser?" It would be the second renaissance!

If I had more free time on my hands, or were king of the world and could make it so, a fun exercise would be to retrofit Firefox / Chromium to support Scheme as replacements for HTML/CSS/Javascript and get a merry band of geeks to build a shadow web.

Re: Lisp Machine Manual (1984)

#84

Earlier quoted context omitted.

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 example…

Some things stay "true" even long after they are not. Lisp is also unbearably slow... as compared to C on 1979 microcomputers.

Re: Lisp Machine Manual (1984)

#85

Earlier quoted context omitted.

> It ran on several machines, but not the ones that mattered. And why wasn't it ported to the ones that mattered? I keep hearing about how easy it is to build a (simple) Lisp compiler. Why wasn't it ported, or a fresh one built? > The existing code was irrelevant and not portable. Why was the existing code irrelevant? In ten years, nobody wrote anything in Lisp that mattered to anyone? In fact, there were Lisp compil…

I don't have to explain why Lisp failed to take off. I just have to explain why C did, because network effects are more significant than language advantages. This is my central thesis. I don't think awareness of Lisp was evenly distributed among people developing on PCs in the time period when the network advantage was obtained. Even if it was, if there were already a decent C compiler, I don't think most practical e…

> What I don't have an explanation for is why the C compilers produced better code than the Pascal compilers.

I was not aware of this, but I can think of one reason: Pascal does bound checks on array references.

Having lived through the Pascal-to-C transition in academia, I was under the impression that the main reason for C's success was that it came with Unix, and Unix was free (at least to schools at the time), while other languages and OSes cost money.

Re: Lisp Machine Manual (1984)

#86

Earlier quoted context omitted.

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…

The odd thing about the fully parenthesized syntax is that it's offputting at first, but once you've been doing it for a little while, in an editor that does parenthesis matching and auto-indentation , it gets to be just as easy and pleasant to work with as more common languages, or even more so. (Packages like Emacs 'paredit' make it even better. (I haven't tried 'parinfer'.)) I understand this is hard to believe if…

Completely agree. Lisp code I wrote 10 years ago is still very readable to me. It makes perfect sense once you're "over the hump" but you gotta make that investment.

Contrast this with Forth, which I was at one time equally expert at, and where I could rarely read my own code 10 days later.

Re: Lisp Machine Manual (1984)

#87

Earlier quoted context omitted.

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…

I understand where you're coming from and agree to a large extent, but I think your hypothetical person's characterization of infix as a "basic capability" is a bit off. It's antithetical to Lisp's design to make use of infix notation. As far as Forth goes, I would say the same thing.

Agreed. Straightforward arithmetic is the capability, in Lisps represented in such a way as to fit with the philosophy of the language.

It's not like the majority* of languages see infix (or prefix, postfix, postcircumfix, etc.) notation as a basic enough concept to allow defined functions to make use of it. Arithmetic always seems to be the special case. No operator overloading, but arithmetic is pre-overloaded. Parentheses of function calls are all you need to keep track of subexpressions, but arithmetic will have an arbitrary and large list of precedences.

*correct me if I'm wrong. I know a fair few languages but mostly deep dives into particular niches. That could bias me.

Re: Lisp Machine Manual (1984)

#88
post #30

Earlier quoted context omitted.

I don't even disagree on the infix math point, really. I do find it awkward that it makes up a small fraction of what you actually do in most programs. Seems odd that such a minorly applicable point holds such high regard. Sadly, I assert that this being the main irritation of LISP is one more of fashion than it is of actual applicability. Sad, because I do have pride in our communities to want them to be above fashi…

On lisp hate: back in the mid-/late-90s on Slashdot it was en vogue to make jokes about lisp. I'm fairly certain it originated in the spirit of the Unix haters handbook, in that it was in-group therapy for the initiated. But then I think it just became a thing that won karma points, and thus was repeated as a truism. I remember working the university computer helldesk in the late nineties and repeating such a joke to…

I should be clear that I think I fell victim to that. Specifically, I recall I used to at least laugh at those jokes. Can't remember making them, but I also don't remember really understanding them.

So, I could just be projecting. Likely, I am. I would love to be wrong, at least.

Re: Lisp Machine Manual (1984)

#89

The cover of the Lisp Machine Manual had the title printed in all caps diagonally wrapped around the spine, so on the front you could only read "LISP CHINE NUAL". So the title was phonetically pronounced: "Lisp Sheen Nual". My friend Nick made a run of custom silkscreened orange LISP CHINE NUAL t-shirts (most places won't print around the side like that). https://www.facebook.com/photo.php?fbid=74206161754&l=54ec4e..…

Link to an image of the manual, for the lazy: https://c1.staticflickr.com/1/101/264672507_307376d26c_z.jpg

Re: Lisp Machine Manual (1984)

#90

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.

It goes on to say

> The Lisp Machine uses your username (or the part that follows the last period) as a first guess for your password (this happens to take no extra time).

Looks like they won in the long end and got a perhaps semi-surreptitious way to at least opt-in to an open environment.

Post reply on HN