3 ms·

> are even more niche Exactly. Compilers construction is a very specific problem domain, which requires specially tailored DSLs, not a "general purpose" langu

by sklogic 11y ago

> are even more niche Exactly. Compilers construction is a very specific problem domain, which requires specially tailored DSLs, not a "general purpose" language. Haskell is a way too general purpose for this task. > and no major programming language has been written in them. C is even more unsuitable for this than Haskell, and yet most of the compilers are written in C. Technical superiority does not count at all in choosing an implementation platform. > Because no known programming language resorts to "a few lines of Prolog" to save a few tens of lines for "region inference"? JFYI, a prototype implementation of SSA for GCC was written in Prolog (see the Sebastian Pop works [1]). If embedding Prolog in C was technically feasible, it would have stayed this way. Also, to see how much Prolog rocks, check out Harlan [2] In order to avoid unnecessary flame war: I give no crap to any popularity based arguments. Got any technical, well-grounded, rational arguments? Go on, I'd be delighted to comment. Otherwise I'm not interested. And, btw., you're clutching to just one out of four of my points against Haskell. Nothing to say about the other three? [1] http://www.cri.ensmp.fr/classement/doc/A-381.pdf http://www.cri.ensmp.fr/classement/doc/A-381.pdf [2] https://github.com/eholk/harlan https://github.com/eholk/harlan

coldtea 11y ago
>C is even more unsuitable for this than Haskell, and yet most of the compilers are written in C. Technical superiority does not count at all in choosing an implementation platform. Or maybe technical superiority is a more varied thing than what you consider (merely a language's features and "expression" capabilities), and includes tooling, portability, speed, direct access to hardware, existing codebase to work upon and lots of other parameters, for which C was king or very near the top for many decades... >In order to avoid unnecessary flame war: I give no crap to any popularity based arguments. And from my side: I don't give a crap for "technical arguments" that focus only on a very narrow area of technical benefits ignoring lots of others. Even "familiarity of the team with a language" is a technical argument (in the sense that it speaks to the capability of a teams to practically use something). I also don't think that "popularity" is just fluff. It might not be a 100% solid proof, but it does point to real, battle proven, results (as oposed to vapour-ware and hand-waving about superiority). In the end, history and actual results are the only criteria. That's being pragmatic and empiricist -- as opposed to mere beliefs that don't pan out in practice.
- sklogic 11y ago
  The features I am talking about are very platform-agnostic. The only requirement for implementing them is a compile-time metaprogramming, which is trivial to add to any language, including C. The only explanation for not using this approach is a plain ignorance. Majority of people have no understanding of compilers at all. And yet they are writing compilers. In C or Haskell. And, btw., teams that cannot learn a tiny DSL in an hour (or write this DSL in a week) should not be allowed to write compilers. It's kinda obvious.
  - coldtea 11y ago
    >The only explanation for not using this approach is a plain ignorance. Majority of people have no understanding of compilers at all. And yet they are writing compilers. In C or Haskell. That includes people like Lars Bak, Martin Odersky, Anders Hejlsberg, Simon Peyton Jones, etc? I wonder where the burden of proof should be placed in these kind of arrogant arguments -- as if "compile-time metaprogramming" is some magic bullet for compiler design...
    - sklogic 11y ago
      I am glad you did not list anyone related to GCC and LLVM, because both rely on the static DSLs (and code generation) heavily. As for the rest - yes, compiler construction is not their main research topic. They can all be great language designers, but their approach to compiler construction is needlessly overcomplicated. A view of a compiler as a chain of stupidly trivial passes, ideally expressed as term rewriting, is not very common among the researchers, but so far it yields the best results.
      - coldtea 11y ago
        >They can all be great language designers, but their approach to compiler construction is needlessly overcomplicated. Actually Lars Bark and team are not "language designers". Smalltalk (Strongtalk), Java (Hotspot), Javascript (V8), all have been designed as languages by other people. They are world reknowed experts in compiler design.

by sklogic 11y ago

coldtea 11y ago

>C is even more unsuitable for this than Haskell, and yet most of the compilers are written in C. Technical superiority does not count at all in choosing an implementation platform. Or maybe technical superiority is a more varied thing than what you consider (merely a language's features and "expression" capabilities), and includes tooling, portability, speed, direct access to hardware, existing codebase to work upon and lots of other parameters, for which C was king or very near the top for many decades... >In order to avoid unnecessary flame war: I give no crap to any popularity based arguments. And from my side: I don't give a crap for "technical arguments" that focus only on a very narrow area of technical benefits ignoring lots of others. Even "familiarity of the team with a language" is a technical argument (in the sense that it speaks to the capability of a teams to practically use something). I also don't think that "popularity" is just fluff. It might not be a 100% solid proof, but it does point to real, battle proven, results (as oposed to vapour-ware and hand-waving about superiority). In the end, history and actual results are the only criteria. That's being pragmatic and empiricist -- as opposed to mere beliefs that don't pan out in practice.

sklogic 11y ago
The features I am talking about are very platform-agnostic. The only requirement for implementing them is a compile-time metaprogramming, which is trivial to add to any language, including C. The only explanation for not using this approach is a plain ignorance. Majority of people have no understanding of compilers at all. And yet they are writing compilers. In C or Haskell. And, btw., teams that cannot learn a tiny DSL in an hour (or write this DSL in a week) should not be allowed to write compilers. It's kinda obvious.
- coldtea 11y ago
  >The only explanation for not using this approach is a plain ignorance. Majority of people have no understanding of compilers at all. And yet they are writing compilers. In C or Haskell. That includes people like Lars Bak, Martin Odersky, Anders Hejlsberg, Simon Peyton Jones, etc? I wonder where the burden of proof should be placed in these kind of arrogant arguments -- as if "compile-time metaprogramming" is some magic bullet for compiler design...
  - sklogic 11y ago
    I am glad you did not list anyone related to GCC and LLVM, because both rely on the static DSLs (and code generation) heavily. As for the rest - yes, compiler construction is not their main research topic. They can all be great language designers, but their approach to compiler construction is needlessly overcomplicated. A view of a compiler as a chain of stupidly trivial passes, ideally expressed as term rewriting, is not very common among the researchers, but so far it yields the best results.
    - coldtea 11y ago
      >They can all be great language designers, but their approach to compiler construction is needlessly overcomplicated. Actually Lars Bark and team are not "language designers". Smalltalk (Strongtalk), Java (Hotspot), Javascript (V8), all have been designed as languages by other people. They are world reknowed experts in compiler design.