Hacker News Reader

Comment by riku_iki | Hacker News Reader

Its not substantial improvement, but another invariant which need to be learned and adds more brain load.

I hope someone will design some jvm SimpleLang eventually, which will have very few syntactic constructions but cover all/most of use cases.

View on HN

I disagree. One of the major critiques of Java is how verbose and full of boilerplate it is. And sure, you can hand wave that as devs being picky, but this is a real reason people avoid picking up new projects in Java. The verbosity serves no purpose, and less code is generally better.

As for there now being multiple ways to write the same thing, this seems like something that could be easily linted into consistency. So you would really only have to learn the less verbose way for any newer Java projects.

> of Java is how verbose and full of boilerplate it is.

yes, new SimpleLang can have lessons learned during last 20 years implemented, as in example from another commenter: https://news.ycombinator.com/item?id=37068380

Currently, for a given task, Java usually have 5 legacy deprecated ways to solve, and two more in newish Java versions, and dev needs to keep all of them in memory to be able to read and understand other's code.

> As for there now being multiple ways to write the same thing, this seems like something that could be easily linted into consistency.

that's if you don't work with any legacy systems and 3p libraries and never switch projects/jobs

Sounds like Kotlin is exactly such SimpleLang.

Ya, I'm not sure why people would use Java anymore given that the SimpleLang is pretty good.

Kotlin is even worse; it's younger than Java but also has 5 legacy ways to solve the problem and two more in the newer version, it's just that the legacy ways have been removed so any examples you find online won't work any more.

Are there any examples for this?

Kotlin sure moves faster than Java, but except for features that were experimental or unstable to begin with (coroutines, -X flags), I can't think of a case where more than 1 deprecated version exists (and the "deprecated" versions are not nearly as crufty as Java).

Those "experimental or unstable" features tend to be the advertised selling points of Kotlin. Particularly for async, the previous "experimental" APIs were the only ones available at the time and the recommended way of using Kotlin.

Kotlin is anything but simple

You way over exaggerate the number of different ways a given thing can practically be done in Java. Pattern matching for example only has the visitor pattern as a counterpart and you ain’t going around spewing visitor patterns, it not as simple.

Sure there are a few warts, e.g. arrays work a bit differently than Lists, and primitive-object discrepancy, but every language will pick up similar issues over time.

My comparison with c++ shows java is not more verbose if you take into account headers.

I think people are very aware that c++ is a lot more verbose than Java. What's the advantage of making this particular comparison?

I actually think c++ is not necessary more verbose than java as a language.

But memory management/safety, weaker IDE support and ecosystem make it less productive than Java for business dev.

Wait until you see this new, hyped language called Go! That is even more verbose than both!

I actually appreciate the simplicity of bare Java. It can be verbose on one hand but on the other there are no surprises because everything is just a method call on an object with no operator overloading etc. Seems like they're kind of ruining that with bizarre things like "obj instanceof Point(int x, int y))". That doesn't connotate at all that it's calling x() on the point to get x, it looks like a field. Compare with C# which has a ton of convenience features and syntactic sugar but it's all intuitive and self-explanatory. Really I wish Java would go away and .NET would take over but it's too entrenched.

Point is a record type here. Record types seem to be like Scala's case classes.

The distinction between fields and getters is intentionally blurred because these are immutable value classes.

Yes. Any language which requires an IDE to append get, set and toString for every damned variable is a language in trouble. Here we are at Java 21 and Java must be the only language in modern use which requires regex metacharacters to be escaped. This even after the introduction of raw string literals.

You missed out on Java’s records that solve your gripe with get/set.

Records are not the same as classes.

They are not, but if you need strictly a class for strictly storing data, records are superior in every way. Unfortunately some tools still want POJOs, but most (eg. Converting to json) do work with records.

Disagree with that, but please provide a counterpoint. I've using Java 17 for a large project and I was really excited to use records. I have not found any practical use case for them outside of one or two instances in a project with 2 years of development.

Storing data is also where I thought records would be a good use case. But in the real world data is not Point(x,y). If you have more than 3 or 4 fields in your record, that's simply not going to work. I thought the rest of the industry decided over a decade ago that using positional properties (e.g. new MyRecord(a,b,c,d,e,f,g)) to initialize an object was a bad idea. I think Rich Hickey gave a whole talk on that subject. If there's a future plan to be able to create records using named props, e.g. new MyRecord([firstName: "Bob"]), then I would reconsider my opinion.

Have you seen the whole plan? https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Thanks for sharing. It looks interesting.

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.

> 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.

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?

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.

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.

> 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.

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.

> 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

That’s not language, but ecosystem. And I much prefer this to randomly breaking previously working code.

its standard library.

core ecosystem, e.g. apache commons will add several more ways.

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.

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.

Agree to disagree on that one.

Java’s standard library is one of the best stdlibs out there.

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.

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?

actually your code is not well designed too:

- it will produce OOM if file is very large

- iterating array is usually verbose in many of languages (at least in Java)

- not sure why you would want to have path and filename as separate params

In Java, it would be more ergonomical if they add something like following:

Iterable<String> Files.readAllLines(String fileName);

How is OOM not a concern in case of C++, python? Java’s List is much more ergonomic that arrays.

Also, I really don’t understand your last example - that’s literally available in java returning a List of lines. If you add a .stream().collect(joining(“\n”)), you get the whole string in one go.

> How is OOM not a concern in case of C++, python?

I think in python it will lazely iterate through the file, and not load everything at once

> Java’s List is much more ergonomic that arrays.

right, but commenter above proposed array..

> that’s literally available in java returning a List of lines.

current API has two issues:

- OOM if file is large

- it takes Path instance which you need to construct and not "String file" parameter, thus hit on ergonomics

Path.of(yourString)

I know, but why it is necessary?

  - it will produce OOM if file is very large

A well designed API won't give you an OOM it'll throw a 'this file is too big'

  - not sure why you would want to have path and filename as separate params

Throws path not found. Throws file not found. Why does the programmer need to deal with twee-fiddly path magic for say each file in a directory of config files?

  Iterable<String> Files.readAllLines(String fileName);

Oh sure that's totally more readable.

  I think in python it will lazely iterate through the file,

I wrote a program to suck in a list of log files and generate a bunch of metrics and display them. Users liked to select a dozen 100MB log files. Lazy iteration was way way too slow. Fastest was suck each one into memory and call split.

> A well designed API won't give you an OOM it'll throw a 'this file is too big'

this is possible solution, still it doesn't allow to iterate lines one by one and handle large files

> Throws path not found. Throws file not found.

I think it is some very niche use cases when you need to distinguish between these cases. From another hand there are many places in the code which operate absolute file paths already, and you force them to split path, which is cumbersome. At least two alternative APIs probably are justified to have.

> Fastest was suck each one into memory and call split.

I really don't think pre-splitting is any kind of performance bottleneck, it is likely 1% of performance compared to all IO stack and subsequent string/objects memory management.

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?

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.

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.

> 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();

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.

> 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.

I think that's deliberate, Java is moving towards the modern programming zeitgeist that doesn't really care about strict adherence to the OOP model. This is a feature that comes from languages that don't adhere to Java's OOP principles.

I didn't downvote you, by the way. Don't know why that happened.

The idea is that you deconstruct when a method returns a sum type: An interface with a defined set of implementers that doesn't change. A very common pattern in, say, Haskell or Scala. In Scala you'd also get a warning if you forgot to check one possible type to deconstruct. If you aren't defining your data types like that, yeas, it's a bit weird.

This, along with the underscore, and even the sequence type, shows that the language designers are well aware of what Scala does, and are picking and choosing which things to bring in without risking exposing Java devs to the traditional monad salads that you see in many a Scala codebase.

You also get compile-time error in Java switch expressions if you are not exhaustive in your cases.

But yeah, of course the design team knows about features from Scala, they are probably one of the most competent people on the Earth when it comes to PLs, and are literal CS giants.

Isn't that Clojure?

(let [p obj]

  (if (instance? Point p)

    (let [x (.x p)

          y (.y p)]

      (println (+ x y))))

I think Clojure is not statically typed? which is a big disadvantage, and also syntax is very different from current mainstream languages, so even more effort to learn is required.

When type checking is needed, I find the Truss library* does the trick quite well.

As for the syntax, there is very little, which can make it a harder lift but once you have the hang of it you won't deal with the issues identified in the parent comment.

* https://github.com/taoensso/truss

I don't know what Truss is, but I know that I inherited a few smaller Clojure projects / services, and it's untyped hell. Having optional typing means most people are not going to use it.

JS and Python are not statically typed, or PHP for that matter, but it hasn't stopped JS and Python topping the popularity list year on year nor did PHP stop Facebook from world domination.

I think in all cases it was realized that static types are adding significant benefits, so they were added to python, typescript and hack have been developed.

JS and Python have gradual, not static typing. Same for PHP 8 but Hack is a different language.

> JS and Python have gradual, not static typing.

that's because of all legacy dynamicaly typed codebases

For values of "legacy" referring to "new code written this afternoon, and tomorrow morning".

Or Kawa:

    (if (? p::Point obj)
      (... p:x p:y))

This succeeds if obj matches the pattern p::Point, declaring p to be the value of obj coerced to a Point. This is integrated with Kawa's static type-checking/inference.

https://www.gnu.org/software/kawa/Conditionals.html

Clojure to the rescue ... again. Honestly, I can't fathom why Clojure isn't up there with the most popular languages. Paul Graham was right when he described it, well Lisp, as a secret weapon.

i would imagine the idiomatic clojure to do this is to convert the `p` into a bean using `clojure.core/bean`

but if it is a java record class, then there's currently no standard library way, since it's not a bean (getter/setter naming of properties). You'd have to write custom code for it, which sucks.

TXR Lisp:

Using quasiquote-style pattern:

   (if-match ^#S(point x ,x y ,y) obj
     (prinl (+ x y))

Or using @(struct ...) pattern operator:

   (if-match @(struct point x @x y @y) obj
     (prinl (+ x y))

All done with macros. Expansion, compilation, disassembly:

  4> (flow '(if-match @(struct point x @x y @y) (new (point 1 2))
              (prinl (+ x y)))
       expand
       prinl
       compile-toplevel
       disassemble)
  (let ((#:g0062 (struct-from-args 'point 1 2)))
    (let* (#:result-0065
           x y)
      (if (if (subtypep (typeof #:g0062)
                        'point)
            (let ((#:x0063 (slot #:g0062 'x))
                  (#:y0064 (slot #:g0062 'y)))
              (sys:setq x #:x0063)
              (sys:setq y #:y0064)
              (sys:setq #:result-0065
                (prinl (+ x y)))
              t))
        #:result-0065
        ())))
  data:
      0: point
      1: 1
      2: 2
      3: x
      4: y
  syms:
      0: struct-from-args
      1: subtypep
      2: typeof
      3: slot
      4: prinl
      5: sys:b+
  code:
      0: 2003000E gcall t14 0 d0 d1 d2
      1: 04000000
      2: 04020401
      3: 20010005 gcall t5 2 t14
      4: 000E0002
      5: 20020002 gcall t2 1 t5 d0
      6: 00050001
      7: 00000400
      8: 38000016 if t2 22
      9: 00000002
     10: 2002000A gcall t10 3 t14 d3
     11: 000E0003
     12: 00000403
     13: 20020009 gcall t9 3 t14 d4
     14: 000E0003
     15: 00000404
     16: 20020006 gcall t6 5 t10 t9
     17: 000A0005
     18: 00000009
     19: 2001000D gcall t13 4 t6
     20: 00060004
     21: 1000000D end t13
     22: 10000000 end nil
  instruction count:
     10
  #<sys:vm-desc: 9966330>

I see this is doing something silly: (subtypep (typeof x) y) is just (typep x y), but costs an extra gcall instruction.

Either the pattern matcher should do this, or the compiler should have that as an algebraic reduction, or both.

Let's do the compiler for fun:

  $ git diff stdlib
  diff --git a/stdlib/compiler.tl b/stdlib/compiler.tl
  index 58685741..a837571e 100644
  --- a/stdlib/compiler.tl
  +++ b/stdlib/compiler.tl
  @@ -1411,6 +1411,8 @@ (defmeth compiler comp-fun-form (me oreg env form)
              (set form (rlcp ^(,bin ,a ,b) form)))
             ((- @a)
              (set form (rlcp ^(neg ,a) form)))
  +          ((subtypep (typeof @a) @b)
  +           (set form (rlcp ^(typep ,a ,b) form)))
             ((@(or ignore nilf) . @args)
              (if (eql sym 'ignore)
                (each ((a args))

Note that we are using pattern matching here to recognize and rewrite this case. In return we will obtain better code from pattern matching:

  $ make
  TXR stdlib/compiler.tl -> stdlib/compiler.tlo
  $ ./txr
  This is the TXR Lisp interactive listener of TXR 291.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  TXR is not a toy, but should be kept within easy reach of children.
  1> (flow '(if-match @(struct point x @x y @y) (new (point 1 2))
              (prinl (+ x y)))
       expand
       prinl
       compile-toplevel
       disassemble)
  (let ((#:g0024 (struct-from-args 'point 1 2)))
    (let* (#:result-0028
           x y)
      (if (if (subtypep (typeof #:g0024)  ;; this hasn't changed, of course
                        'point)
          (let ((#:x0026 (slot #:g0024 'x))
                (#:y0027 (slot #:g0024 'y)))
            (sys:setq x #:x0026)
            (sys:setq y #:y0027)
            (sys:setq #:result-0028
              (prinl (+ x y)))
              t))
        #:result-0028
        ())))
  ** expr-1:1: warning: if-match: no such struct type: point
  ** expr-1:1: warning: new: point does not name a struct type
  data:
      0: point
      1: 1
      2: 2
      3: x
      4: y
  syms:
      0: struct-from-args
      1: typep              ;;; no mention of subtypep here any more!
      2: slot
      3: prinl
      4: sys:b+
  code:
      0: 2003000E gcall t14 0 d0 d1 d2
      1: 04000000
      2: 04020401
      3: 20020002 gcall t2 1 t14 d0
      4: 000E0001
      5: 00000400
      6: 38000014 if t2 20
      7: 00000002
      8: 2002000A gcall t10 2 t14 d3
      9: 000E0002
     10: 00000403
     11: 20020009 gcall t9 2 t14 d4
     12: 000E0002
     13: 00000404
     14: 20020006 gcall t6 4 t10 t9
     15: 000A0004
     16: 00000009
     17: 2001000D gcall t13 3 t6
     18: 00060003
     19: 1000000D end t13
     20: 10000000 end nil
  instruction count:
      9                              ;; down by one
  #<sys:vm-desc: 92c94d0>

Ship it!

That was literally the point of Java, to be syntactically and semantically simple, in contrast to the extreme complexity of C++. But just like with Lisp, that only moves necessary complexity to another layer. True wisdom in language design is understanding the line between necessary and unnecessary complexity, and perfectly incorporating necessary complexity into the language so users don't have to reinvent the wheel at the library or precompiler level.

Beyond the other posts, I wonder whether some of the reactions are due to the fact that destructuring here is purely syntactic sugar – there's no "fear of missing out" on new semantics that offer a drastic new improvement in programming style, to the extent that they feel obligatory to incorporate in your mental model of Java (e.g the introduction of anonymous functions.)

Java is quite a lean language, especially considering its age, and the design team does consider every new feature for a long time before adding, being an exception among languages with regards to feature churn (with all its negatives and positives).

Just look at C# or C++, both have at least an order of magnitude larger language “surface area”.

Someone (I think pg?) said that patterns are just insufficient language features, but the flip side applies too: you can apply a pattern in any language, but a feature is limited to what the language designers provide. Patterns you can learn once and write anywhere (for better or worse).

Peter Norvig: http://norvig.com/design-patterns/ (slide 4)

PN, so I was half right. :-P

Oh yes, without the .stream()….collect(toList()) cruft! Just lists with .map() on them!

Also without the :: operator, it’s uglier than the arrow equivalent and it’s yet-another-construct to parse.

Sounds like Kotlin to me

in my non-expert opinion, kotlin also added bunch of creative, unobvious and opinionated constructs to not be qualified as "simple lang"

Their implementation of closures is ass-backwards. Just a bare pair of braces with no arrow to disambiguate from block parens. Kotlin also added to Java's verbosity with extra modifiers like 'internal', 'open' and 'by lazy' which isn't even grammatical English. And don't get me started on multiple constructors.

We're programmers. It's our job to know these things. There really aren't that many to learn. It's a much simpler task than various engineering fields.

the job is to produce software and make this process reliable and efficient.

> There really aren't that many to learn.

I think there are a lot to learn in java ecosystem.

The job is to communicate effectively while producing software more reliably and with less time than someone else that might get hired.

There are many of us who think Java has very little to learn - asking us to go slower - while probably good for society in general, is a losing strategy in a Capitalist economy.

You can keep up, or be left behind. Meanwhile, fortunately the “communicate effectively” is 100x more valuable as “produce software more reliably and faster” ie learning all of these new languages and language improvements.

Kotlin is pretty close to this?

this was discussed here in comment several times, and opposite opinion is that kotlin added enough creatives and opinionated constructs which make it more innovative and less simple.

I think the closest thing is if someone would create linter for java which would allow only essential structures and library API. Java has very good foundational core.

Reply on news.ycombinator.com