Thankth to thith manual my lithp thkillth are thignificantly inreathed. Thplendid manual, with great tipths for all levelth of lithp experienth. Thuper tipth for beginnerth athwell.
Lisp Machine Manual (1984)
111–120 of 165 posts
Re: Lisp Machine Manual (1984)
#112Earlier 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…
> Packages like Emacs 'paredit' make it even better.
Not just better — it's a leap from editing code as plain sequence of lines of characters to editing code structurally. And lisp syntax enables complete and uniform structural editing across all contexts from simple arithmetic expressions to complex top-level definitions.
Re: Lisp Machine Manual (1984)
#113Earlier 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 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 d…
The hardware that ran the software described in this manual didn't have tagged memory or garbage collection support in hardware and the real instruction set was similar to any RISC CPU.
Somebody could have produced a workstation on conventional hardware that just ran Lisp but they didn't. Maybe Tektronix would have been a good candidate as their 4400 series wasn't sold to run UNIX, they ran either Smalltalk or Franz Lisp on top of a minimal OS.
Re: Lisp Machine Manual (1984)
#114Earlier 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…
I disagree. Keeping track of parenthesis is learnable very quickly, and you do it pretty much subconsciously.
A trick that did it for me: I started solving SICP exercises using pen and paper. It took few lines of Lisp written with correct indentation style in mind, and my brain internalized the concept, making me no longer consciously count the parens.
Re: Lisp Machine Manual (1984)
#115Earlier quoted context omitted.
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.
What.
I do entirely expect SBCL to come within factor of 2 to C (if you instrument your Lisp code with type declarations properly), and definitely to get JVM performance. And even unoptimized CL code I expect to run faster than Ruby, Python or JS.
Modern CL implementations are good, and the language itself gives you plenty of ways to help the program compile down to efficient native code.
Re: Lisp Machine Manual (1984)
#116Earlier 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…
Here is the thing about infix: the lack of infix probably does hurt, but not lack of the arithmetic infix . There is various syntactic sugar used in programming languages that is front-and-centre, expressing program and data structure, used everywhere. I believe that most programmers won't have that much problem with (+ (* x x) (* y y)), but even those who don't will balk at cruft like (aref a 3), and (slot-value obj…
That's funny because all the popular languages are mostly prefix too. (foo bar baz) is prefix, but so is foo(bar baz).
Re: Lisp Machine Manual (1984)
#117There 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…
The thing is most people who say things like "Lots of irritating silly parentheses" or think it is hard to read are generally people who have never used it, or at best had a couple of weeks of Lisp/Scheme in a programming language survey course. Lisp doesn't look like just another ALGOL-like language and so it looks "weird" if you don't know it. It's like somebody who only knows closely related Romance languages like Spanish and Italian thinking English is weird because it isn't just a variation of something they know.
Re: Lisp Machine Manual (1984)
#118Earlier 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…
It might just boil down to the fact that programs of some complexity in almost any language are hard to read, even more so when you're a beginner in said language and might not even know its coding/formatting conventions...
PS: The Part regarding Fiat is interesting, because we have a similar saying in Germany, namely: "Fehler in allen Teilen", which translates to "Errors in every part".
I have really no idea about the statistics about fiat reliability though, so don't take that as a statement from me^^
Re: Lisp Machine Manual (1984)
#119Earlier quoted context omitted.
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…
I disagree. Keeping track of parenthesis is learnable very quickly, and you do it pretty much subconsciously. A trick that did it for me: I started solving SICP exercises using pen and paper. It took few lines of Lisp written with correct indentation style in mind, and my brain internalized the concept, making me no longer consciously count the parens.
[deleted]
Re: Lisp Machine Manual (1984)
#120The 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
Thanks for this! Looks elegant.