4 ms·

Seems to me the big failure was sticking with the Von Neuman architecture. Perhaps that was a forcing function towards where we’ve ended up.

noosphr 11mo ago
The big failure is that we stick with languages designed for computers and not people. A C (or Rust) kernel is a heroic effort that takes man-years to complete. A Lisp one is an end of semester project that everyone builds for their make belief machine (also implemented in Lisp).
- bee_rider 11mo ago
  How is Lisp performance these days? It was around in the 70’s, right? So I guess the overhead couldn’t be too bad!
  - aDyslecticCrow 11mo ago
    Considering how much of modern software is written in JavaScript and python, I have a hard time seeing how lisp overhead would pose much of a problem. Erlang is good enough for telecom equipment for 30 years ago, so that also gives us a data point. If entertain the idea that the Von Neuman architecture may be a local maxima, then we can do even better; lisp machines had specialized instructions for lisp which allowed it to run at competitive performance to a normal programming language. The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp. - https://en.wikipedia.org/wiki/Erlang_(programming_language) https://en.wikipedia.org/wiki/Erlang_(programming_language) - https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
    - noosphr 11mo ago
      >The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp. Lisp is not too difficult to grasp, it's that everyone suffers from infix operator brain damage inflicted in childhood. We are in the same place Europe was in 1300. Arabic numerals are here and clearly superior. But how do we know we can trust them? After all DCCCLXXIX is so much clearer than 879 [0]. Once everyone who is wedded to infix notation is dead our great grand children will wonder what made so many people wase so much time implementing towers of abstraction to accept and render a notation that only made sense for quill and parchment. [0] https://lispcookbook.github.io/cl-cookbook/numbers.html#working-with-roman-numerals https://lispcookbook.github.io/cl-cookbook/numbers.html#work...
      - nerdponx 11mo ago
        It's not about prefix notation, it's that the fully uniform syntax has legitimate ergonomic problems for editing, human reading, and static analysis. Sexprs are better for computers than for humans in a lot of ways.
        pjmlp 11mo ago
        Only when not using one of the many Lisp editors that exist since Lisp Machines (Symbolics, TI), Interlisp-D (Xerox), that survive in Emacs SLIME, Cursive, LispWorks, Allegro Common Lisp, Raket, VSCode Calva.
        nerdponx 11mo ago
        Not true at all IMO. Reading code is reading code regardless of whether you have a fancy IDE or not. S-expressions are indisputably harder to learn to read. Most languages have some flexibility in how you can format your code before it becomes unreadable or confusing. C has some, Lua has some, Ruby has some, and Python has maybe fewer but only because you're more tightly constrained by the whitespace syntax. Sexpr family languages meanwhile rely heavily on very very specific indentation structure to just make the code intelligible, let alone actually readable. It's not uncommon to see things like ))))))))) at the end of a paragraph of code. Yes, you can learn to see past it, but it's there and it's an acquired skill that simply isn't necessary for other syntax styles. And moreover, the attitude in the Lisp community that you need an IDE kind of illustrates my point. To write a Python script you can pop open literally any text editor and have a decent time just banging out your code. This can scale up to 100s or even 1000s of LoC. You can do that with Lisp or Scheme too, but it's harder, and the stacks of parentheses can get painful even if you know what you're doing, at which point you really start to benefit from a paren matcher or something more powerful like Paredit. You don't really need the full powered IDE for Lisp any more than you need it for Python. In terms of runtime-based code analysis Python or Ruby are about on par with Lisp, especially if you use a commercial IDE like Jetbrains. IDEs can and do keep a running copy of any of those interpreters in memory and dynamically pull up docstrings, look for call sites, rename methods, run a REPL, etc. Hot-reloading is almost as sketchy in Lisp as it is in Python, it's just more culturally acceptable to do it in Lisp. The difference is that Python and Ruby syntax is not uniform and therefore is much easier to work with using static analysis tools. There's a middle ground between "dumb code editor" and "full-power IDE" where Python and Ruby can exist in an editor like Neovim and a user can be surprisingly productive without any intelligent completion, or using some clunky open-source LSP integration developed by some 22 year old in his spare time. With Lisp you don't have as much middle ground of tooling, precisely because it's harder to write useful tooling for it without a running image. And this is even more painful with Scheme than with Lisp because Scheme dialects are often not equipped to do anything like that. All that is to say: s-exprs are hard to deal with for humans. They aren't for humans to read and write code. They never were. And that's OK! I love Lisp and Scheme (especially Gauche). It's just wrong to assert that everyone is brain damaged and that's why they don't use Lisp.
  - mjhay 11mo ago
    Depends on the Lisp, but Clojure is in the same order of magnitude as Java for the most part, and SBCL Common Lisp is one of the fastest GC languages.
  - tmtvl 11mo ago
    Both Lisps (Common and Scheme) are garbage-collected, so they're in the 'slow as molasses' group of languages (which covers pretty much everything outside of C, C++, Rust, Fortran, Pascal, Ada, and assembly); but among the 'slow as molasses' group, Common Lisp (at least SBCL, which may be the most prolific implementation) is blazingly, scorchingly, stupendously fast. If you know how to use it it's a bat out of hell outrunning greased lightning. On the Scheme side of things Chez is pretty fast. It's not 'I've gained a whole new level of respect for the people who engineered my CPU' levels fast, but it's still pretty decent.
    - gus_massa 11mo ago
      In the arbitrary collection of programs in https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... , SBCL runs x5 slower than C, Racket x15 slower than C. Chez Scheme shoud be in between, like x10 slower than C. (Anyway, some C programs use very advanced low level tricks, so the difference with realistic programs may be slower.) It's a pity they don't rune benchmarks for Clojure, and I have no idea to make up a number.
      - igouy 11mo ago
        > Chez Scheme shoud be in between ? The default implementation as of Racket version 8.0 uses Chez Scheme as its core compiler and runtime system. https://docs.racket-lang.org/reference/implementations.html https://docs.racket-lang.org/reference/implementations.html > some C programs use very advanced low level tricks * possible hand-written vector instructions or "unsafe" or naked ffi" are flagged https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/clang-sbcl.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- ejflick 11mo ago
  It is unfortunate that this field underestimates the importance of the "people" part in favor of the "computer" part. There's definitely a balance to be stricken. I do believe that languages that are designed for computers have done a pretty decent job at adapting features that are geared more towards the "people" part of the equation. Unfortunately, programmers are very tribal and are very eager to toss the wine out with the cork when it comes to ideas that may help but they've misapplied.
- jane2plane 11mo ago
  A toy C kernel is also an end of semester project. What makes real kernels take man years to complete is the hardware support, the majority of Linux source code is drivers - the endless tables of hardware register definitions, opcodes and state machine handling.
  - blue_pants 11mo ago
    But couldn't we do something about that as well? Couldn't drivers be built on some abstraction that would simplify some work? I have zero knowledge about this area though
    - gf000 11mo ago
      FWIW android has HAL which is just this.
    - scottLobster 11mo ago
      If you could get every hardware manufacturer in the world onboard with such an interface, perhaps. But even if 90% of them were onboard there would be edge cases that people and companies would demand support for and there goes your standard. Drivers exist to ultimately turn actual hardware circuits off and on, often for highly specialized and performance-critical applications, and are often written based on the requirements of a circuit diagram. So any unified driver platform would also involved unified hardware standards, likely to the detriment of performance in some applications, and good luck telling Electrical Engineers around the world to design circuits to a certain standard so the kernel developers can have it easier.
    - Ygg2 11mo ago
      > Couldn't drivers be built on some abstraction that would simplify some work? That's like asking the alchemist to publicly publish their manuscripts. In an ideal world, yes. However, we don't live there. Until a few years ago, GPUs and other drivers were guarded more carefully than the fucking Fort Knox. Once you publish your drivers, you reveal a part of the inner workings of your hardware, and that's a no-no for companies. Plus, what the other commenter said - getting hardware guys to design for a common driver interface is probably not gonna get traction.

noosphr 11mo ago

The big failure is that we stick with languages designed for computers and not people. A C (or Rust) kernel is a heroic effort that takes man-years to complete. A Lisp one is an end of semester project that everyone builds for their make belief machine (also implemented in Lisp).

bee_rider 11mo ago
How is Lisp performance these days? It was around in the 70’s, right? So I guess the overhead couldn’t be too bad!
- aDyslecticCrow 11mo ago
  Considering how much of modern software is written in JavaScript and python, I have a hard time seeing how lisp overhead would pose much of a problem. Erlang is good enough for telecom equipment for 30 years ago, so that also gives us a data point. If entertain the idea that the Von Neuman architecture may be a local maxima, then we can do even better; lisp machines had specialized instructions for lisp which allowed it to run at competitive performance to a normal programming language. The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp. - https://en.wikipedia.org/wiki/Erlang_(programming_language) https://en.wikipedia.org/wiki/Erlang_(programming_language) - https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
  - noosphr 11mo ago
    >The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp. Lisp is not too difficult to grasp, it's that everyone suffers from infix operator brain damage inflicted in childhood. We are in the same place Europe was in 1300. Arabic numerals are here and clearly superior. But how do we know we can trust them? After all DCCCLXXIX is so much clearer than 879 [0]. Once everyone who is wedded to infix notation is dead our great grand children will wonder what made so many people wase so much time implementing towers of abstraction to accept and render a notation that only made sense for quill and parchment. [0] https://lispcookbook.github.io/cl-cookbook/numbers.html#working-with-roman-numerals https://lispcookbook.github.io/cl-cookbook/numbers.html#work...
    - nerdponx 11mo ago
      It's not about prefix notation, it's that the fully uniform syntax has legitimate ergonomic problems for editing, human reading, and static analysis. Sexprs are better for computers than for humans in a lot of ways.
      - pjmlp 11mo ago
        Only when not using one of the many Lisp editors that exist since Lisp Machines (Symbolics, TI), Interlisp-D (Xerox), that survive in Emacs SLIME, Cursive, LispWorks, Allegro Common Lisp, Raket, VSCode Calva.
        nerdponx 11mo ago
        Not true at all IMO. Reading code is reading code regardless of whether you have a fancy IDE or not. S-expressions are indisputably harder to learn to read. Most languages have some flexibility in how you can format your code before it becomes unreadable or confusing. C has some, Lua has some, Ruby has some, and Python has maybe fewer but only because you're more tightly constrained by the whitespace syntax. Sexpr family languages meanwhile rely heavily on very very specific indentation structure to just make the code intelligible, let alone actually readable. It's not uncommon to see things like ))))))))) at the end of a paragraph of code. Yes, you can learn to see past it, but it's there and it's an acquired skill that simply isn't necessary for other syntax styles. And moreover, the attitude in the Lisp community that you need an IDE kind of illustrates my point. To write a Python script you can pop open literally any text editor and have a decent time just banging out your code. This can scale up to 100s or even 1000s of LoC. You can do that with Lisp or Scheme too, but it's harder, and the stacks of parentheses can get painful even if you know what you're doing, at which point you really start to benefit from a paren matcher or something more powerful like Paredit. You don't really need the full powered IDE for Lisp any more than you need it for Python. In terms of runtime-based code analysis Python or Ruby are about on par with Lisp, especially if you use a commercial IDE like Jetbrains. IDEs can and do keep a running copy of any of those interpreters in memory and dynamically pull up docstrings, look for call sites, rename methods, run a REPL, etc. Hot-reloading is almost as sketchy in Lisp as it is in Python, it's just more culturally acceptable to do it in Lisp. The difference is that Python and Ruby syntax is not uniform and therefore is much easier to work with using static analysis tools. There's a middle ground between "dumb code editor" and "full-power IDE" where Python and Ruby can exist in an editor like Neovim and a user can be surprisingly productive without any intelligent completion, or using some clunky open-source LSP integration developed by some 22 year old in his spare time. With Lisp you don't have as much middle ground of tooling, precisely because it's harder to write useful tooling for it without a running image. And this is even more painful with Scheme than with Lisp because Scheme dialects are often not equipped to do anything like that. All that is to say: s-exprs are hard to deal with for humans. They aren't for humans to read and write code. They never were. And that's OK! I love Lisp and Scheme (especially Gauche). It's just wrong to assert that everyone is brain damaged and that's why they don't use Lisp.
- mjhay 11mo ago
  Depends on the Lisp, but Clojure is in the same order of magnitude as Java for the most part, and SBCL Common Lisp is one of the fastest GC languages.
- tmtvl 11mo ago
  Both Lisps (Common and Scheme) are garbage-collected, so they're in the 'slow as molasses' group of languages (which covers pretty much everything outside of C, C++, Rust, Fortran, Pascal, Ada, and assembly); but among the 'slow as molasses' group, Common Lisp (at least SBCL, which may be the most prolific implementation) is blazingly, scorchingly, stupendously fast. If you know how to use it it's a bat out of hell outrunning greased lightning. On the Scheme side of things Chez is pretty fast. It's not 'I've gained a whole new level of respect for the people who engineered my CPU' levels fast, but it's still pretty decent.
  - gus_massa 11mo ago
    In the arbitrary collection of programs in https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... , SBCL runs x5 slower than C, Racket x15 slower than C. Chez Scheme shoud be in between, like x10 slower than C. (Anyway, some C programs use very advanced low level tricks, so the difference with realistic programs may be slower.) It's a pity they don't rune benchmarks for Clojure, and I have no idea to make up a number.
    - igouy 11mo ago
      > Chez Scheme shoud be in between ? The default implementation as of Racket version 8.0 uses Chez Scheme as its core compiler and runtime system. https://docs.racket-lang.org/reference/implementations.html https://docs.racket-lang.org/reference/implementations.html > some C programs use very advanced low level tricks * possible hand-written vector instructions or "unsafe" or naked ffi" are flagged https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/clang-sbcl.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
ejflick 11mo ago
It is unfortunate that this field underestimates the importance of the "people" part in favor of the "computer" part. There's definitely a balance to be stricken. I do believe that languages that are designed for computers have done a pretty decent job at adapting features that are geared more towards the "people" part of the equation. Unfortunately, programmers are very tribal and are very eager to toss the wine out with the cork when it comes to ideas that may help but they've misapplied.
jane2plane 11mo ago
A toy C kernel is also an end of semester project. What makes real kernels take man years to complete is the hardware support, the majority of Linux source code is drivers - the endless tables of hardware register definitions, opcodes and state machine handling.
- blue_pants 11mo ago
  But couldn't we do something about that as well? Couldn't drivers be built on some abstraction that would simplify some work? I have zero knowledge about this area though
  - gf000 11mo ago
    FWIW android has HAL which is just this.
  - scottLobster 11mo ago
    If you could get every hardware manufacturer in the world onboard with such an interface, perhaps. But even if 90% of them were onboard there would be edge cases that people and companies would demand support for and there goes your standard. Drivers exist to ultimately turn actual hardware circuits off and on, often for highly specialized and performance-critical applications, and are often written based on the requirements of a circuit diagram. So any unified driver platform would also involved unified hardware standards, likely to the detriment of performance in some applications, and good luck telling Electrical Engineers around the world to design circuits to a certain standard so the kernel developers can have it easier.
  - Ygg2 11mo ago
    > Couldn't drivers be built on some abstraction that would simplify some work? That's like asking the alchemist to publicly publish their manuscripts. In an ideal world, yes. However, we don't live there. Until a few years ago, GPUs and other drivers were guarded more carefully than the fucking Fort Knox. Once you publish your drivers, you reveal a part of the inner workings of your hardware, and that's a no-no for companies. Plus, what the other commenter said - getting hardware guys to design for a common driver interface is probably not gonna get traction.