4 ms·

The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this: GHC Haskell and Rust with have an inte

The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this: GHC Haskell and Rust with have an intermediate language (Core and MIR + Chalk, respectively), which keep the rest of the language in tight check. No other mainstream language has this (Java bytecode doesn't really speak to high level safety properties). This ensures the vast majority of the languages are forgettable sugar, and making consistencies of various sorts tractable. I would argue that even outside of languages as we conventionally think of them, the lack of separating functionality into core languages/interfaces and sugar is the central failure in letting complexity spiral out of control. And indeed, just about everything has.

Ericson2314 8y ago
Also the Dependent Haskell work of Richard Eisenberg I'd argue is more important as an attempt to shrink the language than add expressive power. The main thing it does is combine existing language features, which only yields more constructs insofar as the old features had friction. You can think of it roughly as taking the convex hull (or probably better bounding parallelepiped) of the existing feature space. Seen in this light, I've never such a thing attempted at this scale (GHC's size and GHC/Haskell's age), and very much commend it. Hope other things can do the same thing someday.
kccqzy 8y ago
I agree with you, but complexity is perceived by newcomers through the surface syntax of the language, not through an internal, mostly invisible IR. It's great that as advanced users, most of the perceived complexity can simply be thought of as sugar, but to a newcomer without an understanding of the core of the language yet, the complexity is often intimidating. It's easy for a language designer to say things are just "forgettable sugar" whereas in the eyes of the users, they are anything but forgettable.
- Ericson2314 8y ago
  For starters, I think newcomers should look at the core languages more. It's a great way to develop a (shared) mental model, rather than do so independently, reinventing the wheel and then maybe finding that yours disagrees with others'. But even discounting that, I think it's still meaningful. Sugar is easier to deprecate; The desugaring can be used to remove deprecated sugar in the wild too. Core language complexity is a lot harder to eradicate.
jarjoura 8y ago
At the end of the day, we're all just writing syntactic sugar over assembly that a very complex state machine has to execute.
- Ericson2314 8y ago
  No (safe) Rust is safe, while arbitrary assembly is unsafe. "Sugar" where the difference between the range (of elaboration) and codomain is significant is not sugar. If we had an assembly+proofs language and a compiler from Rust to it, then I would agree. See CakeML for an example of research towards correctness-proof-preserving compilation.
  - zbentley 8y ago
    I think you are using a different definition of "safe" than Rust folks use.
    - Ericson2314 8y ago
      Actually this is for any definitional of "safe". The important part is codomain vs range. As long as the target language allows source language invariants to be preserved (by explicit proof or by construction (proof in meta theory)), I'd call it sugar. This doesn't obviously match with Felleisen's notion of expressitivity (which might be used to draw the line between desugaring and general compilation), but I think I like it better. I value invariants over expressiveness.
DannyBee 8y ago
That is not an important facet at all. It's not a thing your users see. The "syntactic sugar", as you call it, is the interface between you and your users. No amount of pretending otherwise will change that. No amount of separation will change this. It does not give you any more ability to change the syntax over time, or get it righter. Your users care only about this syntactic interface. In a good world, they do not care how the rest happens in practice. Worse than this, the idea that a mid level IR should be the "thing that keeps the syntax in check" seems beyond broken. The lower levels do not drive the higher level in roughly any case. Instead, they exist to serve the higher levels. First you understand what users want at a high level, then you try to understand how to make it fast/well. If you need to change the mid level IR to do so, you do. There are nothing but tradeoffs in mid level IRs, and those tradeoffs change over time based on the needs of languages, not the other way around. Driving a language based on what you can accomplish in a mid level IR would be incredibly silly - "Welp, we better use this form of parallelism at a high level because we chose coroutines in the mid level IR" should never occur. Instead, the answer is "we change the mid level IR to best support the form of high level parallelism we want in the language"
- Ericson2314 8y ago
  OK yours is the second comment to talk about "Users". IMO this first-impression-based design methodology, like we're writing some consumer CRUD app for the startup [proverbial] you're gonna quit in <= 3 years, is a terrible skeumorphic philosophy for designing languages. Languages are for more terrible; programs last (too?) long; long-future readers may be expert or knowledge. Let me response point-by-point > It's not a thing your users see. The "syntactic sugar", as you call it, is the interface between you and your users. Users can and should learn the core language too. It's can allow compressing the information in the brain just as it allows reducing the code in the implementation. > In a good world, they do not care how the rest happens in practice. Again, I believe the core language is a meaningful thing to study and learn, not just some shove-under-the-rug implementation detail. You clearly don't, and your conclusion is indeed implied by that presupposition. It's hard to argue either from other principles so let me say it is widely held by those that study programming languages and work with cutting-edge programming languages: My axiom has more buy-in by the relevant in-groups. Maybe out-groups with yours are right and we are bad designers, or maybe those out-groups should accept a non-trivial learning curve vs permanent complexity. > The lower levels do not drive the higher level in roughly any case. This is wrong. As someone active with RFC discussion for both Rust and Haskell, this empirically not the case. Ideas are constantly proposed and vetted based on whether they fundamentally extend expressiveness or are just sugar. > First you understand what users want at a high level Yes, languages changes should and are be driven by end goals, but end goals != surface syntax!! > There are nothing but tradeoffs in mid level IRs What does this even mean? Surface syntax is full of tradeoffs too. > those tradeoffs change over time based on the needs of languages, not the other way around. Again, once the MIR/core exists, RFCs heavily reference them so this is false. > Driving a language based on what you can accomplish in a mid level IR would be incredibly silly - "Welp, we better use this form of parallelism at a high level because we chose coroutines in the mid level IR" should never occur. Instead, the answer is "we change the mid level IR to best support the form of high level parallelism we want in the language". This leads me to think you don't know much about IRs in these langauges in practice. Neither Rust's or Haskell's IR has any notion of concurrency precisely because nothing good enough has presented itself. Both language use syntactic / "encapsulation tricks" (See Haskell using the IO monad to avoid the value restriction of OCaml, Rust's Send and Sync) to chew off some safe subset that works with many modules. An IR with a deep/"semantic" understanding of concurrency doesn't exist for these "production" languages, though I hope http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ could get Rust there someday.
millstone 8y ago
Is the discussion of the intermediate language meant to rebut the claim of "reputation for overcomplexity" or "loss of users?"
- Ericson2314 8y ago
  "Reputation for overcomplexity", especially there being little on w technically level to stop the language from growing and devolving into inconsistent design.

Ericson2314 8y ago

Also the Dependent Haskell work of Richard Eisenberg I'd argue is more important as an attempt to shrink the language than add expressive power. The main thing it does is combine existing language features, which only yields more constructs insofar as the old features had friction. You can think of it roughly as taking the convex hull (or probably better bounding parallelepiped) of the existing feature space. Seen in this light, I've never such a thing attempted at this scale (GHC's size and GHC/Haskell's age), and very much commend it. Hope other things can do the same thing someday.

kccqzy 8y ago

I agree with you, but complexity is perceived by newcomers through the surface syntax of the language, not through an internal, mostly invisible IR. It's great that as advanced users, most of the perceived complexity can simply be thought of as sugar, but to a newcomer without an understanding of the core of the language yet, the complexity is often intimidating. It's easy for a language designer to say things are just "forgettable sugar" whereas in the eyes of the users, they are anything but forgettable.

Ericson2314 8y ago
For starters, I think newcomers should look at the core languages more. It's a great way to develop a (shared) mental model, rather than do so independently, reinventing the wheel and then maybe finding that yours disagrees with others'. But even discounting that, I think it's still meaningful. Sugar is easier to deprecate; The desugaring can be used to remove deprecated sugar in the wild too. Core language complexity is a lot harder to eradicate.

jarjoura 8y ago

At the end of the day, we're all just writing syntactic sugar over assembly that a very complex state machine has to execute.

Ericson2314 8y ago
No (safe) Rust is safe, while arbitrary assembly is unsafe. "Sugar" where the difference between the range (of elaboration) and codomain is significant is not sugar. If we had an assembly+proofs language and a compiler from Rust to it, then I would agree. See CakeML for an example of research towards correctness-proof-preserving compilation.
- zbentley 8y ago
  I think you are using a different definition of "safe" than Rust folks use.
  - Ericson2314 8y ago
    Actually this is for any definitional of "safe". The important part is codomain vs range. As long as the target language allows source language invariants to be preserved (by explicit proof or by construction (proof in meta theory)), I'd call it sugar. This doesn't obviously match with Felleisen's notion of expressitivity (which might be used to draw the line between desugaring and general compilation), but I think I like it better. I value invariants over expressiveness.

DannyBee 8y ago

That is not an important facet at all. It's not a thing your users see. The "syntactic sugar", as you call it, is the interface between you and your users. No amount of pretending otherwise will change that. No amount of separation will change this. It does not give you any more ability to change the syntax over time, or get it righter. Your users care only about this syntactic interface. In a good world, they do not care how the rest happens in practice. Worse than this, the idea that a mid level IR should be the "thing that keeps the syntax in check" seems beyond broken. The lower levels do not drive the higher level in roughly any case. Instead, they exist to serve the higher levels. First you understand what users want at a high level, then you try to understand how to make it fast/well. If you need to change the mid level IR to do so, you do. There are nothing but tradeoffs in mid level IRs, and those tradeoffs change over time based on the needs of languages, not the other way around. Driving a language based on what you can accomplish in a mid level IR would be incredibly silly - "Welp, we better use this form of parallelism at a high level because we chose coroutines in the mid level IR" should never occur. Instead, the answer is "we change the mid level IR to best support the form of high level parallelism we want in the language"

Ericson2314 8y ago
OK yours is the second comment to talk about "Users". IMO this first-impression-based design methodology, like we're writing some consumer CRUD app for the startup [proverbial] you're gonna quit in <= 3 years, is a terrible skeumorphic philosophy for designing languages. Languages are for more terrible; programs last (too?) long; long-future readers may be expert or knowledge. Let me response point-by-point > It's not a thing your users see. The "syntactic sugar", as you call it, is the interface between you and your users. Users can and should learn the core language too. It's can allow compressing the information in the brain just as it allows reducing the code in the implementation. > In a good world, they do not care how the rest happens in practice. Again, I believe the core language is a meaningful thing to study and learn, not just some shove-under-the-rug implementation detail. You clearly don't, and your conclusion is indeed implied by that presupposition. It's hard to argue either from other principles so let me say it is widely held by those that study programming languages and work with cutting-edge programming languages: My axiom has more buy-in by the relevant in-groups. Maybe out-groups with yours are right and we are bad designers, or maybe those out-groups should accept a non-trivial learning curve vs permanent complexity. > The lower levels do not drive the higher level in roughly any case. This is wrong. As someone active with RFC discussion for both Rust and Haskell, this empirically not the case. Ideas are constantly proposed and vetted based on whether they fundamentally extend expressiveness or are just sugar. > First you understand what users want at a high level Yes, languages changes should and are be driven by end goals, but end goals != surface syntax!! > There are nothing but tradeoffs in mid level IRs What does this even mean? Surface syntax is full of tradeoffs too. > those tradeoffs change over time based on the needs of languages, not the other way around. Again, once the MIR/core exists, RFCs heavily reference them so this is false. > Driving a language based on what you can accomplish in a mid level IR would be incredibly silly - "Welp, we better use this form of parallelism at a high level because we chose coroutines in the mid level IR" should never occur. Instead, the answer is "we change the mid level IR to best support the form of high level parallelism we want in the language". This leads me to think you don't know much about IRs in these langauges in practice. Neither Rust's or Haskell's IR has any notion of concurrency precisely because nothing good enough has presented itself. Both language use syntactic / "encapsulation tricks" (See Haskell using the IO monad to avoid the value restriction of OCaml, Rust's Send and Sync) to chew off some safe subset that works with many modules. An IR with a deep/"semantic" understanding of concurrency doesn't exist for these "production" languages, though I hope http://plv.mpi-sws.org/rustbelt/ http://plv.mpi-sws.org/rustbelt/ could get Rust there someday.

millstone 8y ago

Is the discussion of the intermediate language meant to rebut the claim of "reputation for overcomplexity" or "loss of users?"

Ericson2314 8y ago
"Reputation for overcomplexity", especially there being little on w technically level to stop the language from growing and devolving into inconsistent design.