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

91–100 of 165 posts

Re: Lisp Machine Manual (1984)

#91

Post by rjsw »

fusiongyro wrote: post #76
AnimalMuppet wrote: post #73

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…

There were native Pascal compilers available for the PC at the same time as the first C compilers. The Pascal ones didn't generate p-code, people just preferred writing in C.

Re: Lisp Machine Manual (1984)

#92

Post by TeMPOraL »

progman wrote: post #47
dwheeler wrote: post #21

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…

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

I think the best cure for the "lots of silly parentheses" argument is to ask someone to count the amount of (, ), [, ], {, }, characters in their code. Java, for example, is easily on par with Lisp here.

Re: Lisp Machine Manual (1984)

#93

Post by erikj »

Zigurd wrote: post #81
ScottBurson wrote: post #48

Earlier quoted context omitted.

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.

Both Lisp Machines Inc. and Symbolics were selling the MIT version before redesigning it into their own brand new products, the LMI-LAMBDA and the Symbolics 3600.

Re: Lisp Machine Manual (1984)

#94

Post by taeric »

Animats wrote: post #33
pjmlp wrote: post #11

Earlier quoted context omitted.

Lisp workstations were quite expensive with proprietary source code, while UNIX workstation were built on source code available almost for free (AT&T could not sell it so they licensed it for a symbolic price), which made them cheaper to sell. Also the companies involved in selling Lisp machines did quite a few management errors.

Ask anyone who owned a Symbolics 3600, a single-user machine the size of a refrigerator. Overpriced hardware. Poor maintenance service and low hardware reliability. A level of company arrogance seldom seen in a small company. (They thought they were going to rule AI. Didn't happen.) And, originally, 45-minute garbage collections. (Virtual memory plus slow disk plus naive garbage collection.) What really killed them w…

I'm beginning to find that small companies have more arrogance than larger. Just, confirmation bias seems to get people to remember the ones with the skills to back it up. Most companies fail without you ever hearing of them.

Re: Lisp Machine Manual (1984)

#95

Post by nocman »

AdeptusAquinas wrote: post #69
nocman wrote: post #66

Earlier quoted context omitted.

"replacing every curly bracket with 20 parenthesis (minor hyperbole)" It isn't even minor hyperbole, it's just plain false. It has been my experience that, generally speaking, the combination of curly brackets { }, square brackets [ ], and parens ( ) in languages with C-like syntax is at worst roughly equivalent to the number of parens in most lisp dialects. Some people freak out because they see a function in a lisp…

You might be right in aggregate counts, but the difference is that in a C-style language you have different types of fluff: curly braces, parenthesis, semi colons etc. So the count of any one type is not overwhelming (unless you let your cyclomatic complexity get away from you). In Lisp its almost all parenthesis, so yes it is more. Besides which my point is more that why have any of this at all? Only the insane writ…

"Only the insane write code without tab or space indentation"

^ um, and who exactly suggested that? Certainly not me.

And if you think lisp style languages are generally written without tab or space indention, then you clearly haven't read much lisp code.

I thought you said you tried Clojure? Clojure's data literals use curly braces (maps, sets), square brackets (vectors) and parens (lists). I think that's a good thing -- they function like parens but are just distinct enough to make the underlying type more obvious.

Even so, the parens don't get in the way of scheme/lisp programmers. You really do get used to it (usually even like it) after a while (oh and many scheme's use square brackets for function arguments, etc).

"why have any of this at all?"

^ because the parens serve a very important purpose. They group code and data in a very compact, clear, and easily parseable(sp?) way -- a way that allows for extremely powerful manipulation of both. The fact that you don't understand this is evidence that you haven't put in enough effort to appreciate the power of lisp-like languages. I'm not suggesting that you have to like lisp or its syntax, but to suggest that the way it is designed is "insane" is just ridiculous.

Using indentation as grouping is by no means "saner" than using parens. Whitespace is too easy to get wrong or to misinterpret. Heaven help you if you try to implement macros that use whitespace for grouping.

Re: Lisp Machine Manual (1984)

#97

Post by abecedarius »

dreamcompiler wrote: post #86
ScottBurson wrote: post #65

Earlier quoted context omitted.

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.

The biggest reasons for this are local variables vs. stack ops and parenthesized expressions vs. having to know the arities of the words called. You can add local variables to Forth, but afaik nobody did during its heyday; and "phrasing" your code with whitespace can help some on the latter issue, but it's admittedly not as explicit as parens.

(From another one-time Forther and more recent Lisper.)

Re: Lisp Machine Manual (1984)

#98

Post by fusiongyro »

AnimalMuppet wrote: post #80
fusiongyro wrote: post #76

Earlier quoted context omitted.

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…

> 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. My assertion is that you're looking at the wrong decade for C's network effects. You should be looking at the PDP-11 decade, not the PC decade. And in the PDP-11 decade, I believe there was much wider awareness of Lisp. (I was a kid then, so that's just my impression. I d…

> My assertion is that you're looking at the wrong decade for C's network effects. You should be looking at the PDP-11 decade, not the PC decade. And in the PDP-11 decade, I believe there was much wider awareness of Lisp.

This is the crux of it I think, and unfortunately my flashlight isn't bright enough to get much further. I was born in 1981, so this is all reconstruction for me. Unfortunately, the people who were there are getting scarce. Anyway, thanks for talking it through with me!

Re: Lisp Machine Manual (1984)

#99

Post by AdeptusAquinas »

nocman wrote: post #95
AdeptusAquinas wrote: post #69

Earlier quoted context omitted.

You might be right in aggregate counts, but the difference is that in a C-style language you have different types of fluff: curly braces, parenthesis, semi colons etc. So the count of any one type is not overwhelming (unless you let your cyclomatic complexity get away from you). In Lisp its almost all parenthesis, so yes it is more. Besides which my point is more that why have any of this at all? Only the insane writ…

"Only the insane write code without tab or space indentation" ^ um, and who exactly suggested that? Certainly not me. And if you think lisp style languages are generally written without tab or space indention, then you clearly haven't read much lisp code. I thought you said you tried Clojure? Clojure's data literals use curly braces (maps, sets), square brackets (vectors) and parens (lists). I think that's a good thi…

Criticising lisp was a mistake, and I should have already ripcorded my way out of this discussion thread already, but you make some good points, so I'll respond at my own peril:

I didn't suggest you implied that lisp isn't written without indentation. Yes I have coded with lisp, and I know they use other syntax than just parens.

Parens serve an important purpose with lisps, just like the semi colon does in c languages. As a C# programmer I can, and have, written long statements on one line; in particular, LINQ statements lend itself to this if you use the method syntax, which I use exclusively over its query syntax form. To make it readable you break it over lines but terminate with a semi colon to finish: it is still run as a single statement. This is powerful.

In F# you can still do this, but it requires that the entire statement start at the appropriate indentation in order for the compiler to infer the closure.

Indentation can cause misinterpretations, but I'd argue, at least for me, that the happy case (i.e. 99% of a given codebase) that using indentation instead of parens, curly braces or similar, is a less clutter free way of writing code. And, since its something that is generally done anyway, it makes curly braces/parens redundant. Note that in F# you can use parens as well to group code, if you need to enforce a closure, which is a good design decision: make them optional. C# would be much better, and I would argue (again at my peril) that if it was optional in a lisp-style language as well, that would be great.

Re: Lisp Machine Manual (1984)

#100

Post by white-flame »

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.

If that's the case, then why is Emacs such a poor facsimile of the LispM environments? ;-)
Post reply on HN