Live data from Hacker News

Lisp Machine Manual (1984)

hanshuebner.github.io

141–150 of 165 posts

Re: Lisp Machine Manual (1984)

#141

Earlier quoted context omitted.

I was just looking at that same list. I'm surprised Lua is that low considering how many applications embed it.

https://www.tiobe.com/tiobe-index/programming-languages-defi... The reason those rankings are (mostly) useless is that it's based on search engine hits. An active, effective community that for whatever reason doesn't generate a million and one blog entries a month will not perform as well on the index. This makes it very useful for indicating fads in programming, but not reality.

There's also http://redmonk.com/sogrady/2017/03/17/language-rankings-1-17... which uses # pull requests on github with # of tags on Stack Overflow. Another biased methodology for sure, but it paints a different picture.

Re: Lisp Machine Manual (1984)

#142
post #132

Earlier quoted context omitted.

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…

"parens ... make them optional ... and I would argue (again at my peril) that if it was optional in a lisp-style language as well, that would be great." ^ making parens optional in a lisp would IMHO make everything more complicated at best. Someone else in this thread mentioned SRFI 49. Personally I don't find it's syntax... define fac x if = x 0 1 * x fac - x 1 ... to be any easier to read or understand than the usu…

SRFI 49 went too far the other way. In F# the expression would be:

  let rec fac x =
    if x = 0 then
      1
    x * fac (x - 1)
Or with pattern matching:

  let rec fac = match x with
    | 0 -> 1
    | _ -> x * fac (x - 1)

Re: Lisp Machine Manual (1984)

#143

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…

> 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), wh…

That was part of the reason, yes.

On MS-DOS, Turbo Pascal and Turbo C had equal code quality and for the use cases where bound checking or integer overflow checking could be a performance issue, it was possible to disable it.

In both cases you would end up using Assembly anyway, because on those days compilers were pretty bad generating code.

Re: Lisp Machine Manual (1984)

#144
post #136
post #134

Earlier quoted context omitted.

Please don't assume that the Lisp compiler on some Symbolics could not output micro code. It could, IIRC. But it was not what a Lisp developer normally would do, he/she would use the compiler in such a way that it outputs the usual machine code, not micro code.

Computer Architecture is not defined by what a Lisp developer normally would do. What hardware features of the CADR do you feel provide support for GC and tagged words ? I have built the CADR microcode from the same source to use both 24 and 25 bit pointers, it is just software.

Computer architecture on the user level is defined by the data format and instruction set the CPU offers. How it is implemented is another level. I don't know how some Intel i7 is implemented, but it probably has writable microcode and some very different architecture inside.

That Intel hides the microcode and the CADR didn't is just another detail.

Re: Lisp Machine Manual (1984)

#145

Earlier quoted context omitted.

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

> Lisp trolls existed even back the Recently while reading, Appel's Compiling with Continuations, I read some mistaken claims about Lisp and scope, one doesn't have to be a troll, which requires intent, to make ignorant claims about Lisp, parsing or any subject. Although the amount of ridiculous arguments from people who clearly haven't used it (or at most used it very briefly) does make one's blood boil at times.

I agree, but just because I'm curious, what did Appel say? Different dialects of Lisp have had different scoping rules, but beyond that I don't know what is true or false. I believe earlier ones were dynamically scoped, because I vaguely recollect that lexical scoping was an important change in Common Lisp and Scheme. Of course Common Lisp has a special way to ask for dynamic scope.

Re: Lisp Machine Manual (1984)

#146

Earlier quoted context omitted.

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

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

Thank you for your charitable assumptions. You might be even more charitable and state what's wrong with what I said.

My understanding is, 1, that every newly-created cons pair requires an allocation, 2, that every new list entry is a new cons pair, and 3, that you can avoid creating them but you have to keep a very careful eye on your code in order to do so - the normal way of writing code will cons frequently.

Which, of those statements, do you consider to be wrong, and why?

Re: Lisp Machine Manual (1984)

#147
post #143

Earlier quoted context omitted.

> 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), wh…

That was part of the reason, yes. On MS-DOS, Turbo Pascal and Turbo C had equal code quality and for the use cases where bound checking or integer overflow checking could be a performance issue, it was possible to disable it. In both cases you would end up using Assembly anyway, because on those days compilers were pretty bad generating code.

That erodes part of my argument. Why did C overtake Pascal? If it wasn't performance or availability, was it just preferences? Or portability from other existing codebases?

Re: Lisp Machine Manual (1984)

#148
post #91

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…

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.

I thought that the prevalence of Pascal compilers was partly due to p-code as a compiler implementation technique, not that they were generating it.

As I mentioned above, this raises questions about why C came to dominate Pascal. They both had a comparable early foothold on PCs.

Re: Lisp Machine Manual (1984)

#149

Earlier quoted context omitted.

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

> 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. Thank you for your charitable assumptions. You might be even more charitable and state what's wrong with what I said. My understanding is, 1, that every newly-created cons pai…

> Which, of those statements, do you consider to be wrong, and why?

Every one of them. You do not understand the difference between what the program code does and what the programming language implementation does, and your underlying assumption is that there is a difference in how a Lisp runtime without garbage collection would manage memory allocation and how the C standard library manages memory allocation.

I am going to assume you need a stdlib.h refresher:

    void *malloc(size_t size);

    void free(void *ptr);
How do you think free works? How would you write a linked list implementation in C?

I just happened to have done some software archaeology on a Lisp implementation without a garbage collector a while ago (https://github.com/vsedach/Thinlisp-1.1), and the memory allocation and lifetime management is exactly the same there as in C++ - manual management and dynamic extent regions (RAII).

Now I really want to get pedantic with each of your points, because individually each is wrong in interesting ways:

> 1, that every newly-created cons pair requires an allocation

This statement is a redundant tautology ("every new allocation requires an allocation"), but even the correctly phrased assertion that "CONS always allocates" is not always true:

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

http://3e8.org/pub/scheme/doc/lisp-pointers/v1i3/p17-white.p...

> 2, that every new list entry is a new cons pair

Again, redundant, and again, not always true, because of hash consing and CDR coding:

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

> 3, that you can avoid creating them but you have to keep a very careful eye on your code in order to do so - the normal way of writing code will cons frequently.

If you do not need to allocate lists, do not allocate lists. There is no "normal" way of writing code that exists outside of what your performance requirements are, what the language semantics are, and what the language implementation provides in terms of those semantics. The only situation where you cannot avoid frequent allocations is when all the data structures are immutable.

Re: Lisp Machine Manual (1984)

#150

Earlier quoted context omitted.

> Lisp trolls existed even back the Recently while reading, Appel's Compiling with Continuations, I read some mistaken claims about Lisp and scope, one doesn't have to be a troll, which requires intent, to make ignorant claims about Lisp, parsing or any subject. Although the amount of ridiculous arguments from people who clearly haven't used it (or at most used it very briefly) does make one's blood boil at times.

I agree, but just because I'm curious, what did Appel say? Different dialects of Lisp have had different scoping rules, but beyond that I don't know what is true or false. I believe earlier ones were dynamically scoped, because I vaguely recollect that lexical scoping was an important change in Common Lisp and Scheme. Of course Common Lisp has a special way to ask for dynamic scope.

Can't find the quote I was remembering, but it said that Lisp didn't had lexical scope. The book was published in '92, so Lisp already had lexical scope. (Which was introduced by Scheme IIRC)

Here is another one I found looking for the quote I was remembering.

> "It has higher-order functions, meaning that a function can be passed as an argument and return as the result of another function – as in Scheme, C and Haskell, but not Pascal and Lisp.

Post reply on HN