4 ms·

Obviously this is still an early proposal that might not go anywhere, but I find it interesting to see how more and more functional programming constructs are c

by hencq 3y ago

Obviously this is still an early proposal that might not go anywhere, but I find it interesting to see how more and more functional programming constructs are creeping into Java. Who knows if this makes it in, next they make exceptions resumable and they go all the way to typed effects.

halfmatthalfcat 3y ago
Java becoming Scala gets more real everyday.
- 082349872349872 3y ago
  It's the language Hilbert Hotel: when Java becomes Scala, Scala can become ScalaZ, and ScalaZ becomes... (idk, some sort of theorem prover language?)
- vips7L 3y ago
  Scala but with way less foot-guns.
  - kelnos 3y ago
    True, but also a weaker type system, which is a shame.
- funcDropShadow 3y ago
  Java is not becoming Scala and that is good. I am saying that as someone earning his bread with mostly writing Scala and SQL nowadays. Scala's underlying type theory is quite different from Java and that lead to many of its pitfalls. I really admire Brian Goetz's slow and steady hand to extend Java piece by piece with those language constructs, that are understood well enough. Scala started as an experiment to unify a functional language with an object-oriented language. Thereby, they created this monstrosity of a type systems which fails to give the guarantees of Haskell 98 types, but provides all the bells and whistles of Haskell 2010 + GADT + UndecidableInstances. And at the same time the type systems is shoehorned into the type system of the JVM. All that is quite an engineering achievement. And it was/is an extremely valuable research experiment. But it is far from simple. I hope Java continues to walk the path well trodden. Then it can continue to be the boring technology, the safe choice, the reliable tool it is. Although it is evolving faster than ever.
pdpi 3y ago
Python has been getting a bunch of similar features too. ADTs+Pattern Matching form an incredibly powerful pair of features that leads to code that is both concise and easy to read, so it doesn't surprise me that it's getting retrofitted into all sorts of languages.
trealira 3y ago
This doesn't necessarily seem like functional programming (although there's nothing wrong with functional programming). It makes sense to unify switch and try-catch statements, because they're both meant for selecting a path based on the outcome of the selector expression (as the proposal says). It would make sense for other languages with exceptions, like C++, to adopt something like this, IMO. > Who knows if this makes it in, next they make exceptions resumable and they go all the way to typed effects. You don't necessarily need that for resumable exceptions. Common Lisp and PL/I got it a long time ago, although PL/I isn't really in use anymore AFAIK. Apparently, resumable exceptions used to be more commonly accepted, and then they were rejected in the 1980s[1]: > Originally, software exception handling included both resumable exceptions (resumption semantics), like most hardware exceptions, and non-resumable exceptions (termination semantics). However, resumption semantics were considered ineffective in practice in the 1970s and 1980s (see C++ standardization discussion, quoted below) and are no longer in common use, though provided by programming languages like Common Lisp, Dylan and PL/I. I wasn't around then, which is why I say "apparently." [1]: https://learn.saylor.org/mod/page/view.php?id=33094 https://learn.saylor.org/mod/page/view.php?id=33094

by hencq 3y ago

halfmatthalfcat 3y ago

Java becoming Scala gets more real everyday.

082349872349872 3y ago
It's the language Hilbert Hotel: when Java becomes Scala, Scala can become ScalaZ, and ScalaZ becomes... (idk, some sort of theorem prover language?)
vips7L 3y ago
Scala but with way less foot-guns.
- kelnos 3y ago
  True, but also a weaker type system, which is a shame.
funcDropShadow 3y ago
Java is not becoming Scala and that is good. I am saying that as someone earning his bread with mostly writing Scala and SQL nowadays. Scala's underlying type theory is quite different from Java and that lead to many of its pitfalls. I really admire Brian Goetz's slow and steady hand to extend Java piece by piece with those language constructs, that are understood well enough. Scala started as an experiment to unify a functional language with an object-oriented language. Thereby, they created this monstrosity of a type systems which fails to give the guarantees of Haskell 98 types, but provides all the bells and whistles of Haskell 2010 + GADT + UndecidableInstances. And at the same time the type systems is shoehorned into the type system of the JVM. All that is quite an engineering achievement. And it was/is an extremely valuable research experiment. But it is far from simple. I hope Java continues to walk the path well trodden. Then it can continue to be the boring technology, the safe choice, the reliable tool it is. Although it is evolving faster than ever.

pdpi 3y ago

Python has been getting a bunch of similar features too. ADTs+Pattern Matching form an incredibly powerful pair of features that leads to code that is both concise and easy to read, so it doesn't surprise me that it's getting retrofitted into all sorts of languages.

trealira 3y ago

This doesn't necessarily seem like functional programming (although there's nothing wrong with functional programming). It makes sense to unify switch and try-catch statements, because they're both meant for selecting a path based on the outcome of the selector expression (as the proposal says). It would make sense for other languages with exceptions, like C++, to adopt something like this, IMO. > Who knows if this makes it in, next they make exceptions resumable and they go all the way to typed effects. You don't necessarily need that for resumable exceptions. Common Lisp and PL/I got it a long time ago, although PL/I isn't really in use anymore AFAIK. Apparently, resumable exceptions used to be more commonly accepted, and then they were rejected in the 1980s[1]: > Originally, software exception handling included both resumable exceptions (resumption semantics), like most hardware exceptions, and non-resumable exceptions (termination semantics). However, resumption semantics were considered ineffective in practice in the 1970s and 1980s (see C++ standardization discussion, quoted below) and are no longer in common use, though provided by programming languages like Common Lisp, Dylan and PL/I. I wasn't around then, which is why I say "apparently." [1]: https://learn.saylor.org/mod/page/view.php?id=33094 https://learn.saylor.org/mod/page/view.php?id=33094