3 ms·

What I don't like about these discussions is how they completely skip the pragmatic part. That's why "expression-oriented" Erlang (and Elixir) simply has the s

What I don't like about these discussions is how they completely skip the pragmatic part. That's why "expression-oriented" Erlang (and Elixir) simply has the single-branch if while the academics still debate whether or not it should, should be optional etc.

chriswarbo 4y ago
Those implementations are useful as empirical tests of what works/doesn't. However, it's also useful to keep such academic debates going; since it's unlikely that our current abstractions are the most optimal. For example: - Hoare added `null` to Algol because it was pragmatic; and he later regretted it. In contrast, "academics" like Milner added algebraic datatypes to ML, which turned out to provide a much safer alternative (Option/Maybe). - "Pragmatic" languages like Python, Javascript, etc. added try/throw for exceptional control-flow. Then added for/yield for resumable control-flow. Then added async/await for concurrent control-flow. Meanwhile, "academics" refined Scheme's call-with-current-continuation into shift/reset, which allows all of those to be written in libraries, rather than having to keep changing the language implementation. - Languages like ML and Scheme used call-by-value, which happened to make side-effects quite pragmatic. Meanwhile "academics" debated call-by-need semantics, Moggi figured out that effects are monadic, and Wadler added it to Haskell. That enabled a bunch of functionality that would have been undermined by the presence of side-effects (e.g. implicit parallelism, software-transactional memory, parser combinators, promises/futures, etc.)
masklinn 4y ago
> That's why "expression-oriented" Erlang (and Elixir) simply has the single-branch if while the academics still debate whether or not it should Erlang's single-branch if is essentially an assertion, it throws if the one branch is not taken. I don't find this very pragmatic, or even at all useful since erlang ships with a slew of assertion macros (https://www.erlang.org/doc/man/assert.hrl.html https://www.erlang.org/doc/man/assert.hrl.html). Your "pragmatic" also doesn't do anything useful for a statically typed language. A statically typed language requires that the program be well-typed, so you have to define what "well typed" implies for a single-branch if.

chriswarbo 4y ago

Those implementations are useful as empirical tests of what works/doesn't. However, it's also useful to keep such academic debates going; since it's unlikely that our current abstractions are the most optimal. For example: - Hoare added `null` to Algol because it was pragmatic; and he later regretted it. In contrast, "academics" like Milner added algebraic datatypes to ML, which turned out to provide a much safer alternative (Option/Maybe). - "Pragmatic" languages like Python, Javascript, etc. added try/throw for exceptional control-flow. Then added for/yield for resumable control-flow. Then added async/await for concurrent control-flow. Meanwhile, "academics" refined Scheme's call-with-current-continuation into shift/reset, which allows all of those to be written in libraries, rather than having to keep changing the language implementation. - Languages like ML and Scheme used call-by-value, which happened to make side-effects quite pragmatic. Meanwhile "academics" debated call-by-need semantics, Moggi figured out that effects are monadic, and Wadler added it to Haskell. That enabled a bunch of functionality that would have been undermined by the presence of side-effects (e.g. implicit parallelism, software-transactional memory, parser combinators, promises/futures, etc.)

masklinn 4y ago

> That's why "expression-oriented" Erlang (and Elixir) simply has the single-branch if while the academics still debate whether or not it should Erlang's single-branch if is essentially an assertion, it throws if the one branch is not taken. I don't find this very pragmatic, or even at all useful since erlang ships with a slew of assertion macros (https://www.erlang.org/doc/man/assert.hrl.html https://www.erlang.org/doc/man/assert.hrl.html). Your "pragmatic" also doesn't do anything useful for a statically typed language. A statically typed language requires that the program be well-typed, so you have to define what "well typed" implies for a single-branch if.