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

101–110 of 165 posts

Re: Lisp Machine Manual (1984)

#101

Post by pjmlp »

TeMPOraL wrote: post #92
progman wrote: post #47

Earlier quoted context omitted.

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.

My approch is always to start with a normal language example and then start moving parenthesis to the left.

Re: Lisp Machine Manual (1984)

#103

Post by sedachv »

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…

> 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 don't actually know.)

I was not around but from the literature it seems Lisp trolls existed even back then - for example Ted Nelson's Computer Lib / Dream Machines contains some very negative and very mistaken statements about Lisp, and it was published in 1974.

> Lisp allocates all the time. You have to work hard if you want it not to. So if you want explicit allocation, you'd have to invoke it all the time, and it would really get in the way - far more than it does in C. (Far more things are allocated in Lisp than in C... Lisp, to my (very limited) knowledge, doesn't have a way to treat an allocated block of memory as anything other than a cons pair.

Between this comment and your ignorance of the difference between a PDP-10 and a PDP-11 I get the impression that you do not know anything about computer history or about Lisp or about what constitutes memory allocation. Please stop trolling.

Re: Lisp Machine Manual (1984)

#104

Post by sedachv »

AdeptusAquinas wrote: post #99
nocman wrote: post #95

Earlier quoted context omitted.

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

> Yes I have coded with lisp, and I know they use other syntax than just parens... I would argue (again at my peril) that if it was optional in a lisp-style language as well, that would be great.

The reason you are getting downvoted is not just because you are criticizing Lisp, it is also because you are posting a bunch of BS without understanding the difference between a context-free and a context-sensitive language. Please learn some basic parsing theory and then you will understand why your suggestion for a white space sensitive syntax for a homoiconic programming language is nonsense.

Re: Lisp Machine Manual (1984)

#105

Post by dreamcompiler »

abecedarius wrote: post #97
dreamcompiler wrote: post #86

Earlier quoted context omitted.

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.)

Mach 2 Forth for the Mac in the late 80s had local variables and when I wrote a Forth compiler for the TI 34010 I included local variables. They helped a lot, but they still don't make Forth as readable as Lisp.

Re: Lisp Machine Manual (1984)

#106

Post by lispm »

Jach wrote: post #59
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…

Lacking infix syntax out of the box is a problem, though not hard to add as a sibling mentioned; for those curious I like linking to this gem dating back to '93 since it's part of quicklisp now https://github.com/rigetticomputing/cmu-infix The rest of the syntax being somewhat alien-ish is also a problem, but it goes away with practice. ( https://www.thejach.com/imgs/lisp_parens.png ) But I don't think syntax alone i…

The Lisp Machine manual documents their infix reader macro:

https://hanshuebner.github.io/lmman/rdprt.xml#reader

  #⋄x:y+car(a1[i,j])⋄
which gets read into something like

  (setq x (+ y (car (aref a1 i j))))

Re: Lisp Machine Manual (1984)

#107

Post by lispm »

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 different purpose. It wasn't developed as a systems programming language and wasn't used much as such. Though it had been used for some very specialized machines from the mid 70s to early 90s, see the Lisp Machine Manual. But if you read the manual. you'll see that it was initially developed for a very narrow group of people: high-end personal workstation users in research&development. This required very deep pockets. When this manual was published (1984) the cost was in the range from $70k upwards. Most of the machines at that time were bought with government money (aka DARPA).

C spread, because it was a low-level systems programming language and various operating systems were written in C.

The Lisp Machine softwre OTOH was written in a high-level language with special requirements for the hardware: tagged memory, stack-based instruction set CPU, large memory space, garbage collection support in hardware, ...

Thus the software was not stripped down to a minimum and not very portable - which Unix and C was.

Re: Lisp Machine Manual (1984)

#108

Post by howlgram »

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…

I will agree that lisp syntax is hard to read and write, not because it's hard to come up and figure out in what order the parenthesis should be set (or because it uses prefix notation, that's the easiest to get used to), but because it's nigh imposssible to keep track of the parenthesis mentally and visually. Writing lisp involves too much parenthesis-checking to be anywhere near fun. It's not hard to understand, but when it comes to writing complex functions it just spills out of proportion, or maybe I'm just bad at diluting functions into small enough parts. Either way, some large function in C is much simpler to get a grasp of the general control flow. Love the idea, hate actually using it.

Re: Lisp Machine Manual (1984)

#109

Post by jasonm23 »

peatmoss wrote: post #84
kazinator wrote: post #43

Earlier quoted context omitted.

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.

Lisp is pretty slow in comparison to C, that's acceptable.

As a quick self test stand up a C http server using gnu microhttp, hit it with AB or Wrk.

Next stand up a http server in sbcl (e.g. using wookie) and do the same AB or Wrk load test.

If you are expecting common Lisp to come close to C or even JVM you will be quite disappointed.

I know I was.

I love Lisp but it's a unwise to compare it with C on performance.

Re: Lisp Machine Manual (1984)

#110

Post by throwanem »

howlgram wrote: post #108
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…

I will agree that lisp syntax is hard to read and write, not because it's hard to come up and figure out in what order the parenthesis should be set (or because it uses prefix notation, that's the easiest to get used to), but because it's nigh imposssible to keep track of the parenthesis mentally and visually. Writing lisp involves too much parenthesis-checking to be anywhere near fun. It's not hard to understand, bu…

If you have to cope with parens and indentation by hand, then sure. A proper editor deals with those for you, and provides facilities for semantic traversal and editing besides.
Post reply on HN