Proceeds to give zero indication how to achieve this.
f(g(), h())
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()
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.
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.
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?
I'm sure there are a multitude of different reason and likely require different conflicting tradeoffs to address
Looks like the syntax is taking shape at least.
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. :-)
For example, which of these is more clear to people who don't know Lisp? I'd argue the second one because of the early return if guard.
---- THIS ----
(defun sum-helper (items total)
(cond
(items
(sum-helper
(cdr items)
(+ total (car items))))
(t total)))
(defun sum (&rest items)
(sum-helper items 0))
(print (sum 1 2 3 4))
----- OR -----
(defun sum-helper2 (items total)
(if (not items)
(return-from sum-helper2 total))
(sum-helper2
(cdr items)
(+ total (car items))))
(defun sum2 (&rest items)
(sum-helper2 items 0))
(print (sum2 5 6 7 8))(It should be readable but hasn't had a final editing pass.)
Look at us salivating for his big unveil -- we've probably already written more than he did