5 ms·

Destructuring (/pattern matching) itself is supported by several languages (although more in general, its flexibility depends on the language). It makes sense t

Destructuring (/pattern matching) itself is supported by several languages (although more in general, its flexibility depends on the language). It makes sense to support it in modern languages, as it's practical and intuitive. IMO it's a significant syntactical improvement, as it considerably reduces boilerplate assignments.

riku_iki 3y ago
> It makes sense to support it in modern languages the problem is that Java not modern language, but carrying all legacy features from last 20 years, so having all legacy features + new modern creative ideas make Java very complex.
- unlikelytomato 3y ago
  What are some examples of these legacy features? Overwhelmingly, I see complaints that java has been too simple compared to virtually all other languages. I agree that cognitive load is important. However, it feels really strange to me to suggest that java has reached the complexity of other similar languages. What am I missing?
  - riku_iki 3y ago
    for example Java went through several generations of IO evolution, so some simple task like reading text file line by line can be done in many different way in current standard library: - using DataInputStream - using Scanner - using Reader - using Files.readLines and they all suck.
    - unlikelytomato 3y ago
      I see. Is it fair to say that most of the issues area related to jdk included libraries vs language features itself? I also find a lot of the included libraries to be cumbersome, but I see these syntax improvements to be a welcome change in contrast.
      - riku_iki 3y ago
        > Is it fair to say that most of the issues area related to jdk included libraries vs language features itself? I think they all connected, for example with added lambdas they also added streams, so collections library now allows to do the same thing using old iterators or new streams APIs, and somehow those APIs are not compatible, it is not easy to produce stream from iterator.
        erik_seaberg 3y ago
        Iterator is a very narrow API that needs to remain compatible with a lot of third party code, but streams rely on spliterators for concurrency. You can sort of get a stream from any collection (or a spliterator from any iterable and make a stream), but it will probably do all work sequentially.
        riku_iki 3y ago
        > but streams rely on spliterators for concurrency which I never seen anyone uses and it makes everything more complicated they probably should've have some ParallelStream interface
    - kaba0 3y ago
      That’s not language, but ecosystem. And I much prefer this to randomly breaking previously working code.
      - riku_iki 3y ago
        its standard library. core ecosystem, e.g. apache commons will add several more ways.
        kaba0 3y ago
        IO has so many usecases that frankly, it makes sense. In a way a language with only one way of doing it is missing out on some another use case.
        riku_iki 3y ago
        python and c++ both have the same API for 20-30 years I think, and they are both more robust than Java's APIs imo for 95% of cases.
        kaba0 3y ago
        Agree to disagree on that one. Java’s standard library is one of the best stdlibs out there.
        riku_iki 3y ago
        Evidence of opposite in that example: programmers in 95% cases want something like following to read lines from text file: for s in open('file.txt'): print(s) Java has 5 different io APIs and no one provides such construct, you need to stack various verbose abstractions to just read text file. How it is the best? Ergonomics and brain load is very bad.
        Gibbon1 3y ago
        I'm mostly write embedded code. But when I have to deal with files and associated API's I'm always like why does anyone tolerate this stuff. string[] lines = ReadFile("path", "filename"); Why is the above somehow hard?
The_Colonel 3y ago
Destructuring is nice, but this here seems to work only in conjunction with instanceof which is a quite rare (and somewhat smelly) operator. I mean, how are you going to use it? Something like this? Point p = getPoint(); if (p instanceof Point(int x, int y)) { System.out.println(x+y); } ... that seems pretty bad. Or am I missing something?
- the-smug-one 3y ago
  You'd do if (getPoint() instanceof ...) if you know it's a Point. But then, you probably don't need to deconstruct it anyway. You can just do p.x+p.y. This type of pattern matching is mostly useful when you have some T and a few cases, there is also a switch/case equivalent for when you've got a lot of them. Maybe we'll see some syntax for deconstructing values directly into variables, a la Python in the future.
- heavyset_go 3y ago
  You can have a parent class/interface with many subclasses/implementations. You can then use pattern matching to switch on instances of those subclasses while destructuring objects to access attributes at the same time. Kind of like enums and pattern matching in Rust. In your example there is no reason to use `instanceof` with `p`, you already know what it is.
  - The_Colonel 3y ago
    > You can have a parent class/interface with many subclasses/implementations. Sure, but in Java the standard handling of that is polymorphism. instanceof has been so far a bit of an antipattern, breaking out of the OOP model. > In your example there is no reason to use `instanceof` with `p`, you already know what it is. That's my point. This seems like a very limited version of destructuring if you can use it only when you don't know the type. Like in JavaScript you'd routinely write something like: const {x, y} = getPoint();
    - kaba0 3y ago
      There is subtyping. A more practical (though not necessarily realistic) example might be: sealed interface List<T> permits Cons<T>, None<T> { record Cons<T>(T head, List<T> tail) {} record None<T>() {} } // some function only wanting the first elem of a list switch (List<T> list) { case Cons<>(T head, var tail) -> // do something default -> {} } If you have used Haskell or similarly strongly typed FP language, you can see how great pattern matching can be.

riku_iki 3y ago

> It makes sense to support it in modern languages the problem is that Java not modern language, but carrying all legacy features from last 20 years, so having all legacy features + new modern creative ideas make Java very complex.

unlikelytomato 3y ago
What are some examples of these legacy features? Overwhelmingly, I see complaints that java has been too simple compared to virtually all other languages. I agree that cognitive load is important. However, it feels really strange to me to suggest that java has reached the complexity of other similar languages. What am I missing?
- riku_iki 3y ago
  for example Java went through several generations of IO evolution, so some simple task like reading text file line by line can be done in many different way in current standard library: - using DataInputStream - using Scanner - using Reader - using Files.readLines and they all suck.
  - unlikelytomato 3y ago
    I see. Is it fair to say that most of the issues area related to jdk included libraries vs language features itself? I also find a lot of the included libraries to be cumbersome, but I see these syntax improvements to be a welcome change in contrast.
    - riku_iki 3y ago
      > Is it fair to say that most of the issues area related to jdk included libraries vs language features itself? I think they all connected, for example with added lambdas they also added streams, so collections library now allows to do the same thing using old iterators or new streams APIs, and somehow those APIs are not compatible, it is not easy to produce stream from iterator.
      - erik_seaberg 3y ago
        Iterator is a very narrow API that needs to remain compatible with a lot of third party code, but streams rely on spliterators for concurrency. You can sort of get a stream from any collection (or a spliterator from any iterable and make a stream), but it will probably do all work sequentially.
        riku_iki 3y ago
        > but streams rely on spliterators for concurrency which I never seen anyone uses and it makes everything more complicated they probably should've have some ParallelStream interface
  - kaba0 3y ago
    That’s not language, but ecosystem. And I much prefer this to randomly breaking previously working code.
    - riku_iki 3y ago
      its standard library. core ecosystem, e.g. apache commons will add several more ways.
      - kaba0 3y ago
        IO has so many usecases that frankly, it makes sense. In a way a language with only one way of doing it is missing out on some another use case.
        riku_iki 3y ago
        python and c++ both have the same API for 20-30 years I think, and they are both more robust than Java's APIs imo for 95% of cases.
        kaba0 3y ago
        Agree to disagree on that one. Java’s standard library is one of the best stdlibs out there.
        riku_iki 3y ago
        Evidence of opposite in that example: programmers in 95% cases want something like following to read lines from text file: for s in open('file.txt'): print(s) Java has 5 different io APIs and no one provides such construct, you need to stack various verbose abstractions to just read text file. How it is the best? Ergonomics and brain load is very bad.
        Gibbon1 3y ago
        I'm mostly write embedded code. But when I have to deal with files and associated API's I'm always like why does anyone tolerate this stuff. string[] lines = ReadFile("path", "filename"); Why is the above somehow hard?

The_Colonel 3y ago

Destructuring is nice, but this here seems to work only in conjunction with instanceof which is a quite rare (and somewhat smelly) operator. I mean, how are you going to use it? Something like this? Point p = getPoint(); if (p instanceof Point(int x, int y)) { System.out.println(x+y); } ... that seems pretty bad. Or am I missing something?

the-smug-one 3y ago
You'd do if (getPoint() instanceof ...) if you know it's a Point. But then, you probably don't need to deconstruct it anyway. You can just do p.x+p.y. This type of pattern matching is mostly useful when you have some T and a few cases, there is also a switch/case equivalent for when you've got a lot of them. Maybe we'll see some syntax for deconstructing values directly into variables, a la Python in the future.
heavyset_go 3y ago
You can have a parent class/interface with many subclasses/implementations. You can then use pattern matching to switch on instances of those subclasses while destructuring objects to access attributes at the same time. Kind of like enums and pattern matching in Rust. In your example there is no reason to use `instanceof` with `p`, you already know what it is.
- The_Colonel 3y ago
  > You can have a parent class/interface with many subclasses/implementations. Sure, but in Java the standard handling of that is polymorphism. instanceof has been so far a bit of an antipattern, breaking out of the OOP model. > In your example there is no reason to use `instanceof` with `p`, you already know what it is. That's my point. This seems like a very limited version of destructuring if you can use it only when you don't know the type. Like in JavaScript you'd routinely write something like: const {x, y} = getPoint();
  - kaba0 3y ago
    There is subtyping. A more practical (though not necessarily realistic) example might be: sealed interface List<T> permits Cons<T>, None<T> { record Cons<T>(T head, List<T> tail) {} record None<T>() {} } // some function only wanting the first elem of a list switch (List<T> list) { case Cons<>(T head, var tail) -> // do something default -> {} } If you have used Haskell or similarly strongly typed FP language, you can see how great pattern matching can be.