6 ms·

Short: Haskell made a bunch of poor design decisions that they've since doubled down on, the fastest implementation isn't very good, the art of writing compiler

by kick 7y ago

Short: Haskell made a bunch of poor design decisions that they've since doubled down on, the fastest implementation isn't very good, the art of writing compilers and interpreters has effectively been lost, and Miranda was written by and designed by professionals.

jolux 7y ago
"the art of writing compilers and interpreters has effectively been lost" I'm curious, how does that happen? Were the techniques used in compilers and interpreters of yore never recorded for posterity in academic papers or technical documentation?
- kick 7y ago
  Spent a good while thinking on your question: The best stuff was all proprietary for decades. Even now, we only got Miranda's source code weeks ago. Miranda was written in the 1980s! It's the same for a lot of languages. Nial's the example I usually bring up for one that was freed far too late. People with the domain knowledge that would have helped deal with the complexity of modern systems are all either retired, have ditched PL-design, or have died. Turbo Pascal, too, although that one's kind of strange because the author of it later went on to do a complete 180° turn while still working in PL design and implementation (plus it was never freed). Ken Thompson's cc suite for Plan 9 was behind a million-dollar license fee until a decade ago, and it wasn't even for any modern CPUs. He once quit the industry to become a flight instructor; he's at Google, but he's retired now. The best advice is "Stay small!" which most Free Software compilers seem to be violently against. It's not their fault, though: it's hard not to take new code when it's offered to you! We'll probably never see the source code behind any version of the k interpreter by Arthur Whitney, and trying to get an interview with him is like going on a snipe hunt, so good luck figuring out anything about his approach besides "Small!" It doesn't help that Kx sues the hell out of anyone who's actually seen the k source and tries implementing anything remotely like it that's not a toy. Every modern compiler is for multiple architectures in convoluted ways. This is generally a terrible idea, especially with how divergent they're getting in the times we're in, even between chips that have the same instruction set. Intel x86_64 processors aggressively speculate almost as intensely as Transmeta did back in the day, but we're still treating them and AMD chips more or less the same, and we're using the same compilers that we're using on that instruction set for RISC-V and for ARM and for Itanium and for obscure 16-bit CPUs and so on. Portable compilers aren't bad in principle, but when you look at pcc compared to GCC you'll see exactly where we went wrong: pcc wasn't very optimized, it was simple, and it was understandable. Great for bootstrapping. Not great for getting the most out of your CPU. Having portable compilers that try to heavily optimize is a mistake. No one seems to know what a CPU cache is! And how many compilers do you know that compile to C, or to LLVM bytecode or similar? It's insane: nobody should be doing that! That approach doesn't make much sense! And the only argument any of these people can make is "But our language is too big for it to be practical to write something unique for each architecture! Piggybacking makes it way quicker!" No one seems to realize that their languages are getting too large. They aren't even getting too large in a graceful way: Common Lisp is probably the biggest language there is, but it's extremely portable, and is easy to write an interpreter for. Things got complicated really fast, and domain knowledge was sort of lost in the waves of proprietary compilers as they were destroyed by GCC. I appreciate that free software "won" to some extent, but if it hadn't have won as fast, we might have had some knowledge transfer happen that was actually useful. Walter Bright isn't doing magic, but he and the people he work with seem to be some of the only people in Free Software who are making a compiler that's fast and good in the x86_64 world.
  - onei 7y ago
    Why is compiling to LLVM bytecode insane? Compiling to bytecode and then working with a simpler language has worked for decades since the introduction of BCPL. It's also the approach used by Open64, where you compile to WHIRL which is then optimised with successive passes until you eventually output whatever the architecture can run.
    - kick 7y ago
      Good question! BCPL's O-Code is far different from LLVM bytecode. O-Code was little more than a virtual stack machine. Very similar to Forth, though slightly more complicated. I could be wrong, but isn't Open64 more or less dead? The only thing I can think of that actually uses it (CUDA) isn't best-in-class.
      - ZeRoo 7y ago
        So u say, LLVM or whatever is insane because it's large. so what do u think about QBE[0] ? 0 : https://c9x.me/compile/ https://c9x.me/compile/
        kick 7y ago
        I don't know enough about QBE to give a well-informed assessment of it, so I'll refrain.
      - onei 7y ago
        I believe you're correct about Open64, but it was an interesting examples of a compiler when I was researching them last, particularly its usage of WHIRL [1]. It's a similar approach as used by GCC and LLVM with their front, middle and back-end approach, although I can't quite remember if it pioneered that approach or not. [1] https://www.mcs.anl.gov/OpenAD/open64A.pdf https://www.mcs.anl.gov/OpenAD/open64A.pdf
    - pjmlp 7y ago
      Compiling to bytecode is almost a decade older than BCPL, was the way to go at Xerox PARC and most mainframes that survive to this day.
greydius 7y ago
Would you mind elaborating on these points?
- kick 7y ago
  I have for most of it elsewhere in this thread (I think you can find my answers by checking my /comments), but for what I didn't get to, I'll get to tomorrow. My responses are getting worse as I tire.

by kick 7y ago

jolux 7y ago

"the art of writing compilers and interpreters has effectively been lost" I'm curious, how does that happen? Were the techniques used in compilers and interpreters of yore never recorded for posterity in academic papers or technical documentation?

kick 7y ago
Spent a good while thinking on your question: The best stuff was all proprietary for decades. Even now, we only got Miranda's source code weeks ago. Miranda was written in the 1980s! It's the same for a lot of languages. Nial's the example I usually bring up for one that was freed far too late. People with the domain knowledge that would have helped deal with the complexity of modern systems are all either retired, have ditched PL-design, or have died. Turbo Pascal, too, although that one's kind of strange because the author of it later went on to do a complete 180° turn while still working in PL design and implementation (plus it was never freed). Ken Thompson's cc suite for Plan 9 was behind a million-dollar license fee until a decade ago, and it wasn't even for any modern CPUs. He once quit the industry to become a flight instructor; he's at Google, but he's retired now. The best advice is "Stay small!" which most Free Software compilers seem to be violently against. It's not their fault, though: it's hard not to take new code when it's offered to you! We'll probably never see the source code behind any version of the k interpreter by Arthur Whitney, and trying to get an interview with him is like going on a snipe hunt, so good luck figuring out anything about his approach besides "Small!" It doesn't help that Kx sues the hell out of anyone who's actually seen the k source and tries implementing anything remotely like it that's not a toy. Every modern compiler is for multiple architectures in convoluted ways. This is generally a terrible idea, especially with how divergent they're getting in the times we're in, even between chips that have the same instruction set. Intel x86_64 processors aggressively speculate almost as intensely as Transmeta did back in the day, but we're still treating them and AMD chips more or less the same, and we're using the same compilers that we're using on that instruction set for RISC-V and for ARM and for Itanium and for obscure 16-bit CPUs and so on. Portable compilers aren't bad in principle, but when you look at pcc compared to GCC you'll see exactly where we went wrong: pcc wasn't very optimized, it was simple, and it was understandable. Great for bootstrapping. Not great for getting the most out of your CPU. Having portable compilers that try to heavily optimize is a mistake. No one seems to know what a CPU cache is! And how many compilers do you know that compile to C, or to LLVM bytecode or similar? It's insane: nobody should be doing that! That approach doesn't make much sense! And the only argument any of these people can make is "But our language is too big for it to be practical to write something unique for each architecture! Piggybacking makes it way quicker!" No one seems to realize that their languages are getting too large. They aren't even getting too large in a graceful way: Common Lisp is probably the biggest language there is, but it's extremely portable, and is easy to write an interpreter for. Things got complicated really fast, and domain knowledge was sort of lost in the waves of proprietary compilers as they were destroyed by GCC. I appreciate that free software "won" to some extent, but if it hadn't have won as fast, we might have had some knowledge transfer happen that was actually useful. Walter Bright isn't doing magic, but he and the people he work with seem to be some of the only people in Free Software who are making a compiler that's fast and good in the x86_64 world.
- onei 7y ago
  Why is compiling to LLVM bytecode insane? Compiling to bytecode and then working with a simpler language has worked for decades since the introduction of BCPL. It's also the approach used by Open64, where you compile to WHIRL which is then optimised with successive passes until you eventually output whatever the architecture can run.
  - kick 7y ago
    Good question! BCPL's O-Code is far different from LLVM bytecode. O-Code was little more than a virtual stack machine. Very similar to Forth, though slightly more complicated. I could be wrong, but isn't Open64 more or less dead? The only thing I can think of that actually uses it (CUDA) isn't best-in-class.
    - ZeRoo 7y ago
      So u say, LLVM or whatever is insane because it's large. so what do u think about QBE[0] ? 0 : https://c9x.me/compile/ https://c9x.me/compile/
      - kick 7y ago
        I don't know enough about QBE to give a well-informed assessment of it, so I'll refrain.
    - onei 7y ago
      I believe you're correct about Open64, but it was an interesting examples of a compiler when I was researching them last, particularly its usage of WHIRL [1]. It's a similar approach as used by GCC and LLVM with their front, middle and back-end approach, although I can't quite remember if it pioneered that approach or not. [1] https://www.mcs.anl.gov/OpenAD/open64A.pdf https://www.mcs.anl.gov/OpenAD/open64A.pdf
  - pjmlp 7y ago
    Compiling to bytecode is almost a decade older than BCPL, was the way to go at Xerox PARC and most mainframes that survive to this day.

greydius 7y ago

Would you mind elaborating on these points?

kick 7y ago
I have for most of it elsewhere in this thread (I think you can find my answers by checking my /comments), but for what I didn't get to, I'll get to tomorrow. My responses are getting worse as I tire.