61–70 of 136 posts
Earlier quoted context omitted.
Oooh that's a good idea. Does that already exist in other languages? I've not seen it before.
Ocaml, F#, Rust, Kotlin (I believe), Haskell, etc It is a common feature in languages derives from the ML family[0]. [0]: https://en.wikipedia.org/wiki/ML_(programming_language)
Earlier quoted context omitted.
Ocaml, F#, Rust, Kotlin (I believe), Haskell, etc It is a common feature in languages derives from the ML family[0]. [0]: https://en.wikipedia.org/wiki/ML_(programming_language)
Kotlin doesn't have real pattern matching.
Earlier quoted context omitted.
Method chaining becomes complicated if you have multiple return values. In Go, you can't return error values if you want to do method chaining. Error handling then becomes even more complicated.
I would like to have the result type for this, like in Rust: enum Result { Ok(T), Err(E), }
I have no idea why the Kotlin std lib has a Result type but limits it to exceptions - such a missed opportunity.
Pattern matching in switch statements (calling them match statements would then be more fitting), a nice way to deal with nulls, and proper sum types (aka tagged unions, like enums in Rust) and Java would be pretty up-to-date.
I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative la…
We used to joke about APL (the "beautiful diamond") and Lisp (the "ball of mud"). Lisp was big, at the time, but most of it is what we'd call the standard library today. The actual core was quite small, and everything was remarkably coherent for a system of its size. Today, many core languages are as big as all of Common Lisp.
When I see a language add new syntax for a trivial transformation, in the compiler because the language isn't extensible, using ASCII art because they've run out of symbols on the keyboard, it just looks like the worst of APL combined with the worst of Lisp.
Pattern matching in switch statements (calling them match statements would then be more fitting), a nice way to deal with nulls, and proper sum types (aka tagged unions, like enums in Rust) and Java would be pretty up-to-date.
I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative la…
It seems that most languages these days are on a path to adding as much syntax as possible. Is there no limit? The mainstream languages are already too complex for me to understand fully, let alone use effectively. We used to joke about APL (the "beautiful diamond") and Lisp (the "ball of mud"). Lisp was big, at the time, but most of it is what we'd call the standard library today. The actual core was quite small, an…
Will we ever get to see golang-style multiple return values/results?
Pattern matching in switch statements (calling them match statements would then be more fitting), a nice way to deal with nulls, and proper sum types (aka tagged unions, like enums in Rust) and Java would be pretty up-to-date.
I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative la…
Not only that it makes every possible event explicit and stand-out on its own, which is good for inline optimization and documentation (think about the catastrophic event handling in JS world), it also provides a standard, much more intuitive syntax using formal function delegate declaration (think type-safe function pointers), vastly different than what we do in JVM.
Before having lambdas in Java, we need to add an EventListener as a variable and adding an extra interface, so event handlers are insidious to write, that you have to write a new class, implement the specific interface, write some shim properties to store externally-living variables explicitly, and finally "new" that class as an instance, and add it to a specific event listener, which is not only verbose, and also costly, in terms of memory use (it has to be backed by vtables rather than simple functions) and time taken to implement it.
Well after the long-awaited introduction, Java finally have limited lambda support that just generates a class and it have some odd issues with, for example, enforced effectively final variable reference [0], but in C#, you have delegates and events almost from day 1 -- and it handles all that event mess nice and clean where nobody can still beat that simplicity and elegancy even till today.
[0]: https://stackoverflow.com/questions/34865383/variable-used-i...
Earlier quoted context omitted.
I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative la…
Its coming to java: https://cr.openjdk.java.net/~briangoetz/amber/pattern-match....