4 ms·

>LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. Yeah, let's just forget about decades of Lisp development sinc

>LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. Yeah, let's just forget about decades of Lisp development since. >something like the Java ArrayList makes more sense. Except you lose the most important detail of Lisp pairs: persistence.

dasmoth 12y ago
And in practice, compromise is possible. E.g. Clojure's vectors which are unashamedly LISP-like to work with, but still avoid much of the pointer-chasing of a linked list.
- davexunit 12y ago
  Yes, there are various implementations of persistent vector-like lists, Clojure's being one of them. They are extremely useful, however, they are far more complex than a cons cell. Most of the time, I want simple cons cells.
  - gsg 12y ago
    There are schemes to "unroll" conses, too. CDR-coding, Appel's paper (although IIRC that requires immutable conses), etc.
PaulHoule 12y ago
Persistence has some good properties, particularly if you are writing compilers. Just about every language that promises an advance in parallelism (other than solidly "worse is better" approaches such as Hadoop and Pig) is selling some kind of snake oil, and immutability is one of the worst of them. Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughput. With modern memory hierarchies a lot revolves around never letting two threads touch the same cache line and this happens at all you lose at least an order of magnitude in performance. Garbage collection involves global properties of the system, so there will always be some "stop the world" element of GC, so GC itself becomes a scaling bottleneck when you allocate lots of memory and throw it all behind your rear.
- davexunit 12y ago
  >Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughput. I'll take correctness over raw performance any day.
  - pjmlp 12y ago
    I am with you, specially since we all know where languages obsessed with performance over correctness lead to. http://web.nvd.nist.gov/view/vuln/search-results?query=&search_type=all&cves=on http://web.nvd.nist.gov/view/vuln/search-results?query=&sear...
    - hga 12y ago
      Although the funny thing is, as the 2nd oldest surviving computer language after FORTRAN, and at least back then used for very difficult problems, to be competitive let alone justifiable on extremely scarce and expensive hardware, "Lisp" has always been "obsessed" with performance. ADDED along with a bit before: It first ran on the IBM 704, a vacuum tube computer. It was derived from the IBM 701, which initially used Williams tubes for memory (https://en.wikipedia.org/wiki/Williams_tube https://en.wikipedia.org/wiki/Williams_tube). Scare quotes because "anyone" can program up a Lisp "in a week". High performance LISPs not surprisingly require very roughly the same amount of effort as any other high performance language implementation. Lisp got its first compiler in 1962, 4 years after its launch (and it was the first self-hosting compiler, i.e. written in itself). As the inventor of garbage collection, it's long been a major driver of innovations in GC (although of course much less so now that Java etc. gave GCed languages mainstream cred). But by and large, except for strictness of dynamic type checking (often a tunable variable), sacrificing correctness for speed has never been part of Lisp's DNA.
      - pjmlp 12y ago
        Yes, but there are many ways to be obsessed with performance while keeping correctness. As you might imagine by my post history I had a specific language in mind. Funny that you mention FORTRAN, as it reminds me of a systems programming language used for writing several OS, about the same age as FORTRAN and Lisp, namely Algol and its variants. When they questioned their customers if Algol compilers should support disabling bounds checking, they said no responsible engineer would ever need it. As described by Hoare on his Turing award.

dasmoth 12y ago

And in practice, compromise is possible. E.g. Clojure's vectors which are unashamedly LISP-like to work with, but still avoid much of the pointer-chasing of a linked list.

davexunit 12y ago
Yes, there are various implementations of persistent vector-like lists, Clojure's being one of them. They are extremely useful, however, they are far more complex than a cons cell. Most of the time, I want simple cons cells.
- gsg 12y ago
  There are schemes to "unroll" conses, too. CDR-coding, Appel's paper (although IIRC that requires immutable conses), etc.

PaulHoule 12y ago

Persistence has some good properties, particularly if you are writing compilers. Just about every language that promises an advance in parallelism (other than solidly "worse is better" approaches such as Hadoop and Pig) is selling some kind of snake oil, and immutability is one of the worst of them. Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughput. With modern memory hierarchies a lot revolves around never letting two threads touch the same cache line and this happens at all you lose at least an order of magnitude in performance. Garbage collection involves global properties of the system, so there will always be some "stop the world" element of GC, so GC itself becomes a scaling bottleneck when you allocate lots of memory and throw it all behind your rear.

davexunit 12y ago
>Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughput. I'll take correctness over raw performance any day.
- pjmlp 12y ago
  I am with you, specially since we all know where languages obsessed with performance over correctness lead to. http://web.nvd.nist.gov/view/vuln/search-results?query=&search_type=all&cves=on http://web.nvd.nist.gov/view/vuln/search-results?query=&sear...
  - hga 12y ago
    Although the funny thing is, as the 2nd oldest surviving computer language after FORTRAN, and at least back then used for very difficult problems, to be competitive let alone justifiable on extremely scarce and expensive hardware, "Lisp" has always been "obsessed" with performance. ADDED along with a bit before: It first ran on the IBM 704, a vacuum tube computer. It was derived from the IBM 701, which initially used Williams tubes for memory (https://en.wikipedia.org/wiki/Williams_tube https://en.wikipedia.org/wiki/Williams_tube). Scare quotes because "anyone" can program up a Lisp "in a week". High performance LISPs not surprisingly require very roughly the same amount of effort as any other high performance language implementation. Lisp got its first compiler in 1962, 4 years after its launch (and it was the first self-hosting compiler, i.e. written in itself). As the inventor of garbage collection, it's long been a major driver of innovations in GC (although of course much less so now that Java etc. gave GCed languages mainstream cred). But by and large, except for strictness of dynamic type checking (often a tunable variable), sacrificing correctness for speed has never been part of Lisp's DNA.
    - pjmlp 12y ago
      Yes, but there are many ways to be obsessed with performance while keeping correctness. As you might imagine by my post history I had a specific language in mind. Funny that you mention FORTRAN, as it reminds me of a systems programming language used for writing several OS, about the same age as FORTRAN and Lisp, namely Algol and its variants. When they questioned their customers if Algol compilers should support disabling bounds checking, they said no responsible engineer would ever need it. As described by Hoare on his Turing award.