4 ms·

> The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing fun

> The hypothesis I aim to test with a new programming language is: By making different tradeoffs, these issues can be mitigated and a more broadly-appealing functional language can be built. With such a language, I hope that the true promise of functional programming for parallel computing can be widely realized. Proceeds to give zero indication how to achieve this.

jalk 4y ago
> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I'm sure there are a multitude of different reason and likely require different conflicting tradeoffs to address
- bslatkin 4y ago
  It's true and that is one of the largest challenges. Producing something that feels familiar (but not error prone) has been the way I've solved such conflicts so far.
User23 4y ago
It basically comes down to nondeterminism. Pure functional languages supposedly make it easier to exploit associativity, commutativity, and distributivity to allow many expressions to have nondeterministic semantics that are amenable to concurrent execution. Argument evaluation also can be specified nondeterministic so the runtime is free to execute something like the following with two or more CPU threads: f(g(), h()) Of course a well designed imperative language could also avoid overspecifying deterministic semantics and open itself up to similar optimizations, but for various reasons that hasn’t caught on. One example would be specifying the conditional to select a branch with a true guard nondeterministically rather than deterministically in the order of appearance in the program text. Dijkstra’s EWDs give many practical examples of why one might want such a thing. Another example would be deducing when statement composition is symmetric and allowing nondeterminism when it is. For example if f and g don’t have access to each other’s data then the following can be executed in two threads even with mutation: f(); g() Side effects will appear nondeterministically though which may or may not be a problem. As always an algorithm needs to be designed for the semantics the language has not those the programmer wishes it does.
- alexisread 4y ago
  This makes a good case for effect systems in conjunction with FP, so they can be reasoned about as well. Something like https://koka-lang.github.io/koka/doc/index.html https://koka-lang.github.io/koka/doc/index.html Having said that, having something like Daedelus in there as well would give a handle on temporal-based determinism, and then some allowance for delimited continuations would top things off nicely.
worksonmine 4y ago
In his defense the title is "why" not "how". I guess you'll have to spend some sleepless nights waiting for the follow-up.
- bslatkin 4y ago
  I'm sorry to make you wait.
lolinder 4y ago
It's a four paragraph blog post answering the question "why?". I'm not sure why you expect him to delve into the how at this stage: he probably doesn't have anything fully formed yet.
- iampims 4y ago
  https://twitter.com/haxor/status/1582878447134572544?s=20 https://twitter.com/haxor/status/1582878447134572544?s=20 Looks like the syntax is taking shape at least.
  - noelwelsh 4y ago
    No language syntax needs return in 2023.
    - bslatkin 4y ago
      How should an early return if statement work instead?
      - noelwelsh 4y ago
        When if is an expression early returns aren't really a problem.
        bslatkin 4y ago
        I understand what you mean. But I expect most potential users want explicit returns because they're familiar and more approachable for beginners.
        noelwelsh 4y ago
        I disagree. You make two claims: familiarity, and beginner friendliness. For the first, I think it's a mistake to perpetuate the mistakes of the past. I don't think JS developers have had problems adjusting to the lack of return in arrow functions. Beginners have no preconceived notions of how a programming language should operate, and return makes the language model more complex. 1 + 1 evaluates to 2, but (in a language that requires return) def foo = 1 + 1 foo doesn't for no good reason. This breaks the simple substitution model of evaluation. These claims could be addressed emperically, but I guess neither of us are going to do the research. :-)
karmakaze 4y ago
Very disappointed by the non-announcement. If it were a corp, it would be FUD. I'm curious as to what these different trade-offs are. > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. My conclusion is because most everyone is taught to think empirically and 'play computer' that functional doesn't fit in their preconceived brains. I once had someone say SQL didn't make sense because it's SELECTing fields (i.e. vars) before they're defined/assigned later in the (binding) expressions. People having trouble with FP is like how people who learn databases using ORM's don't deal well with SQL as expressions of set operations. There are varying limits to how much people like and handle abstract constructs before applying the construction to the data at hand but you can do a whole lot of effective and unsurprising development before getting to such esoteric levels. Edit: I was super-excited to open the link, and now on re-reading expect this new FP language to be as much an advancement as Go was to 'systems' programming. I hope I'm mistaken. Also odd that only Haskell and Lisp were mentioned when there are so many others. On the plus-side if Google were to make F# and back it as well as they have Go, that would be a win-win.
- karmakaze 4y ago
  After reading their other post "The case for dynamic, functional programming", I would classify this as FUD, or rather NIH. Go got support by being touted as "Not Java". I can't say that this would gain much by being declared as "Not Elixir".
- lolinder 4y ago
  > it would be FUD I thought FUD stood for Fear Uncertainty Doubt—it's usually used to indicate that something is designed to sow fear for clicks or for some ulterior motive, not for insubstantial non-announcements. Did something in this post evoke fear?
  - karmakaze 4y ago
    The point of FUD is usually to carve out a space where existing products/solutions can't compete with idealized vapourware. I updated my opinion to NIH (though could be both)--and still hope to be mistaken.

jalk 4y ago

> My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. I'm sure there are a multitude of different reason and likely require different conflicting tradeoffs to address

bslatkin 4y ago
It's true and that is one of the largest challenges. Producing something that feels familiar (but not error prone) has been the way I've solved such conflicts so far.

User23 4y ago

It basically comes down to nondeterminism. Pure functional languages supposedly make it easier to exploit associativity, commutativity, and distributivity to allow many expressions to have nondeterministic semantics that are amenable to concurrent execution. Argument evaluation also can be specified nondeterministic so the runtime is free to execute something like the following with two or more CPU threads: f(g(), h()) Of course a well designed imperative language could also avoid overspecifying deterministic semantics and open itself up to similar optimizations, but for various reasons that hasn’t caught on. One example would be specifying the conditional to select a branch with a true guard nondeterministically rather than deterministically in the order of appearance in the program text. Dijkstra’s EWDs give many practical examples of why one might want such a thing. Another example would be deducing when statement composition is symmetric and allowing nondeterminism when it is. For example if f and g don’t have access to each other’s data then the following can be executed in two threads even with mutation: f(); g() Side effects will appear nondeterministically though which may or may not be a problem. As always an algorithm needs to be designed for the semantics the language has not those the programmer wishes it does.

alexisread 4y ago
This makes a good case for effect systems in conjunction with FP, so they can be reasoned about as well. Something like https://koka-lang.github.io/koka/doc/index.html https://koka-lang.github.io/koka/doc/index.html Having said that, having something like Daedelus in there as well would give a handle on temporal-based determinism, and then some allowance for delimited continuations would top things off nicely.

worksonmine 4y ago

In his defense the title is "why" not "how". I guess you'll have to spend some sleepless nights waiting for the follow-up.

bslatkin 4y ago
I'm sorry to make you wait.

lolinder 4y ago

It's a four paragraph blog post answering the question "why?". I'm not sure why you expect him to delve into the how at this stage: he probably doesn't have anything fully formed yet.

iampims 4y ago
https://twitter.com/haxor/status/1582878447134572544?s=20 https://twitter.com/haxor/status/1582878447134572544?s=20 Looks like the syntax is taking shape at least.
- noelwelsh 4y ago
  No language syntax needs return in 2023.
  - bslatkin 4y ago
    How should an early return if statement work instead?
    - noelwelsh 4y ago
      When if is an expression early returns aren't really a problem.
      - bslatkin 4y ago
        I understand what you mean. But I expect most potential users want explicit returns because they're familiar and more approachable for beginners.
        noelwelsh 4y ago
        I disagree. You make two claims: familiarity, and beginner friendliness. For the first, I think it's a mistake to perpetuate the mistakes of the past. I don't think JS developers have had problems adjusting to the lack of return in arrow functions. Beginners have no preconceived notions of how a programming language should operate, and return makes the language model more complex. 1 + 1 evaluates to 2, but (in a language that requires return) def foo = 1 + 1 foo doesn't for no good reason. This breaks the simple substitution model of evaluation. These claims could be addressed emperically, but I guess neither of us are going to do the research. :-)

karmakaze 4y ago

Very disappointed by the non-announcement. If it were a corp, it would be FUD. I'm curious as to what these different trade-offs are. > My conclusion is that there are major, well-justified reasons for why people strongly dislike functional languages. My conclusion is because most everyone is taught to think empirically and 'play computer' that functional doesn't fit in their preconceived brains. I once had someone say SQL didn't make sense because it's SELECTing fields (i.e. vars) before they're defined/assigned later in the (binding) expressions. People having trouble with FP is like how people who learn databases using ORM's don't deal well with SQL as expressions of set operations. There are varying limits to how much people like and handle abstract constructs before applying the construction to the data at hand but you can do a whole lot of effective and unsurprising development before getting to such esoteric levels. Edit: I was super-excited to open the link, and now on re-reading expect this new FP language to be as much an advancement as Go was to 'systems' programming. I hope I'm mistaken. Also odd that only Haskell and Lisp were mentioned when there are so many others. On the plus-side if Google were to make F# and back it as well as they have Go, that would be a win-win.

karmakaze 4y ago
After reading their other post "The case for dynamic, functional programming", I would classify this as FUD, or rather NIH. Go got support by being touted as "Not Java". I can't say that this would gain much by being declared as "Not Elixir".
lolinder 4y ago
> it would be FUD I thought FUD stood for Fear Uncertainty Doubt—it's usually used to indicate that something is designed to sow fear for clicks or for some ulterior motive, not for insubstantial non-announcements. Did something in this post evoke fear?
- karmakaze 4y ago
  The point of FUD is usually to carve out a space where existing products/solutions can't compete with idealized vapourware. I updated my opinion to NIH (though could be both)--and still hope to be mistaken.