5 ms·

> 10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again. My main desktop machine has 16 GB RAM,

> 10 Mbyte. Today Lisp runs fine on an modern processor and some people tinker with Lisp-based operating systems, again. My main desktop machine has 16 GB RAM, and its processor cycle speed is probably also 1600 times as much as that of a machine from back then. Why can't I get my computer to perform 1600 times as much concurrent work as back then? > Every iPhone does that now, since Apple's Objective-C and the iOS frameworks are actually that: efficient dynamic allocation, of runtime-typed small and large objects. That's a luxury that we can nowadays afford. Even the cheapest entry-level smartphone is ridiculously more powerful than an 80's era workstation. But the amount of work computers do for us hasn't grown proportionally to the amount of computing power.

qwertyuiop924 10y ago
...exactly. So there's computing power to spare.
- catnaroek 10y ago
  To spare, you say? I want to use that computing power for my own purposes. I suddenly decided I want to multiply gigantic matrices.
  - qwertyuiop924 10y ago
    Okay. Go write some C, or some Asm. It might feel unpleasant to you, but if you use most other langauges, you'll be wasting too many cycles, and you won't be using that computing power for your own puposes. Don't forget to use as few abstractions as possible, and remember: every function call takes valuable time and computation.
    - catnaroek 10y ago
      > Don't forget to use as few abstractions as possible Huh? I'm perfectly fine with abstractions. Just not with abstractions that are suboptimally designed and implemented. > Don't forget to use as few abstractions as possible Maybe you're confusing abstraction with runtime dispatch? > every function call takes valuable time and computation. Stroustrup's (whom otherwise I don't regard as a great language designer) principle applies: abstractions must elaborate to the best possibly code you would've manually written.
      - qwertyuiop924 10y ago
        Every abstraction has a cost somewhere. If you want to use your computer to its full potential, avoid them all.
        catnaroek 10y ago
        > Every abstraction has a cost somewhere. It's very simple: (0) Runtime performance degradation is unacceptable. (1) Increased compile times are annoying, but they're tolerable in exchange for more exhaustive automatic static analysis. Anything of interest that the compiler can't prove about my code, I would have to prove myself by hand anyway, which would take even more time than the slowest automated static analysis.
        lispm 10y ago
        > Runtime performance degradation is unacceptable Requirements like these are not grounded in real software use. In economic terms: a cheaper/slower software can be acceptable over a more expensive/faster software. Example: Java-based software vs. the same written in C++. In reliability terms: a more robust / slower software can be acceptable over a more expensive/faster software. Example: Erlang-based software vs. C++ software on a network switch. And so on. Abstract/absolutist requirements like 'Runtime performance degradation is unacceptable' is not often found in actual software development/use. Software usually has a multitude of different important qualities. Raw performance is just one of these. Especially one then needs to say what performance exactly and how to measure it. Performance can be measured in many ways: throughput, latency, micro-benchmark speed, etc. etc. Optimizing one (say, throughput) then has effects on others (say, latency). To achieve faster throughput, some functionality can be affected.
        qwertyuiop924 10y ago
        All abstractions degrade runtime performance. Even "zero cost" ones, as they get you to think in less efficient ways, about things like encapsulation, and whatnot. If runtime perf degradation is really unacceptable to you, you shouldn't be writing in functional languages, or even C. You should be writing in raw asm, as low-level as possible.
lispm 10y ago
> Why can't I get my computer to perform 1600 times as much concurrent work as back then? Is that a real question? > But the amount of work computers do for us hasn't grown proportionally to the amount of computing power. I don't know about you, but my laptop is much faster than previous machines. Software which used to compile with the Lisp compiler in half an hour, now compiles in a few seconds.

qwertyuiop924 10y ago

...exactly. So there's computing power to spare.

catnaroek 10y ago
To spare, you say? I want to use that computing power for my own purposes. I suddenly decided I want to multiply gigantic matrices.
- qwertyuiop924 10y ago
  Okay. Go write some C, or some Asm. It might feel unpleasant to you, but if you use most other langauges, you'll be wasting too many cycles, and you won't be using that computing power for your own puposes. Don't forget to use as few abstractions as possible, and remember: every function call takes valuable time and computation.
  - catnaroek 10y ago
    > Don't forget to use as few abstractions as possible Huh? I'm perfectly fine with abstractions. Just not with abstractions that are suboptimally designed and implemented. > Don't forget to use as few abstractions as possible Maybe you're confusing abstraction with runtime dispatch? > every function call takes valuable time and computation. Stroustrup's (whom otherwise I don't regard as a great language designer) principle applies: abstractions must elaborate to the best possibly code you would've manually written.
    - qwertyuiop924 10y ago
      Every abstraction has a cost somewhere. If you want to use your computer to its full potential, avoid them all.
      - catnaroek 10y ago
        > Every abstraction has a cost somewhere. It's very simple: (0) Runtime performance degradation is unacceptable. (1) Increased compile times are annoying, but they're tolerable in exchange for more exhaustive automatic static analysis. Anything of interest that the compiler can't prove about my code, I would have to prove myself by hand anyway, which would take even more time than the slowest automated static analysis.
        lispm 10y ago
        > Runtime performance degradation is unacceptable Requirements like these are not grounded in real software use. In economic terms: a cheaper/slower software can be acceptable over a more expensive/faster software. Example: Java-based software vs. the same written in C++. In reliability terms: a more robust / slower software can be acceptable over a more expensive/faster software. Example: Erlang-based software vs. C++ software on a network switch. And so on. Abstract/absolutist requirements like 'Runtime performance degradation is unacceptable' is not often found in actual software development/use. Software usually has a multitude of different important qualities. Raw performance is just one of these. Especially one then needs to say what performance exactly and how to measure it. Performance can be measured in many ways: throughput, latency, micro-benchmark speed, etc. etc. Optimizing one (say, throughput) then has effects on others (say, latency). To achieve faster throughput, some functionality can be affected.
        qwertyuiop924 10y ago
        All abstractions degrade runtime performance. Even "zero cost" ones, as they get you to think in less efficient ways, about things like encapsulation, and whatnot. If runtime perf degradation is really unacceptable to you, you shouldn't be writing in functional languages, or even C. You should be writing in raw asm, as low-level as possible.

lispm 10y ago

> Why can't I get my computer to perform 1600 times as much concurrent work as back then? Is that a real question? > But the amount of work computers do for us hasn't grown proportionally to the amount of computing power. I don't know about you, but my laptop is much faster than previous machines. Software which used to compile with the Lisp compiler in half an hour, now compiles in a few seconds.