4 ms·

20 years later. What does Guy Steele thing about how Java ended up? We still have no operator overloading, no value types. There are plans, sure, but Java grows

by cntlzw 9y ago

20 years later. What does Guy Steele thing about how Java ended up? We still have no operator overloading, no value types. There are plans, sure, but Java grows very slowly. Good thing? Bad thing? Does anyone know if there is a follow up on this?

exitcode__0 9y ago
There is, Ada continues to evolve and grow - it can even directly interface with Java...
Cthulhu_ 9y ago
I think it's less relevant today, because we now have multiple languages running on the JVM - and I think that was always the most powerful feature of the Java program, the write once, run anywhere idea. Not so much the language itself, although at the time it was pretty good too.
- truncate 9y ago
  IIRC Steele talks about languages which are extensible by users not just compiler writers. Although, JVM allows you to have multiple language implementation on top of JVM, it still doesn't make it easy to extend a language the way lets say Lisp can. He speaks of having primitives in language which allow programmers to extend language (macros?).
  - gizmo385 9y ago
    If macros and LISP on the JVM are what you're looking for, that already exists: https://clojure.org/ https://clojure.org/
    - truncate 9y ago
      Yes I know. I'm not talking about JVM specifically, but extensible languages. I'm a Racket programmer myself, which has much more powerful macro system. I didn't make my point clear. What I was trying to say was these languages are still not mainstream and understood by wider audience, and the argument Steele makes is still relevant. All this lisp and macro goodness existed back then as well.
kochthesecond 9y ago
Thank goodness there is no operator overloading. I maintain 15 year old java codebases and am very happy they did not add user defined operators...
- jVinc 9y ago
  I always find this an odd reason to be against usable features. I have inherited codebases in extremely confined languages as have I inherited codebases in very permitting high-level languages Python, and never have I though "Thank good this language decided to restrict its reach in order to confine the programmer to a smaller subset which made it harder for him to mess up." Often have I though "My good, if only the language had better supported what the programmer is trying to implement himself through horrible hacks, then I wouldn't be sitting here trying to wonder exactly what mistakes he made that casuses everything to crash inexplicably."
  - sharpercoder 9y ago
    I guess the culture around a language matters significantly. For instance, there is quite a specific culture around the Rust community/language. The focus on the language ergonomics is also reflected in many packages. Same goes for the mutability/immutability aspect of code. A second example of this culture is the go language. I read a few repo's, and the same style of programming is seemingly applied throughout. For the Java case, I can actually see operator overloading going haywaire over many codebases. The same as overengineering is a typical trait associated with Java.
- willtim 9y ago
  Arithmetic expressions on BigInteger and BigDecimal currently look like an OOP parody. I cannot believe there are folks willing to defend this decision. Even Sun couldn't resist overloading '+'.

by cntlzw 9y ago

exitcode__0 9y ago

There is, Ada continues to evolve and grow - it can even directly interface with Java...

Cthulhu_ 9y ago

I think it's less relevant today, because we now have multiple languages running on the JVM - and I think that was always the most powerful feature of the Java program, the write once, run anywhere idea. Not so much the language itself, although at the time it was pretty good too.

truncate 9y ago
IIRC Steele talks about languages which are extensible by users not just compiler writers. Although, JVM allows you to have multiple language implementation on top of JVM, it still doesn't make it easy to extend a language the way lets say Lisp can. He speaks of having primitives in language which allow programmers to extend language (macros?).
- gizmo385 9y ago
  If macros and LISP on the JVM are what you're looking for, that already exists: https://clojure.org/ https://clojure.org/
  - truncate 9y ago
    Yes I know. I'm not talking about JVM specifically, but extensible languages. I'm a Racket programmer myself, which has much more powerful macro system. I didn't make my point clear. What I was trying to say was these languages are still not mainstream and understood by wider audience, and the argument Steele makes is still relevant. All this lisp and macro goodness existed back then as well.

kochthesecond 9y ago

Thank goodness there is no operator overloading. I maintain 15 year old java codebases and am very happy they did not add user defined operators...

jVinc 9y ago
I always find this an odd reason to be against usable features. I have inherited codebases in extremely confined languages as have I inherited codebases in very permitting high-level languages Python, and never have I though "Thank good this language decided to restrict its reach in order to confine the programmer to a smaller subset which made it harder for him to mess up." Often have I though "My good, if only the language had better supported what the programmer is trying to implement himself through horrible hacks, then I wouldn't be sitting here trying to wonder exactly what mistakes he made that casuses everything to crash inexplicably."
- sharpercoder 9y ago
  I guess the culture around a language matters significantly. For instance, there is quite a specific culture around the Rust community/language. The focus on the language ergonomics is also reflected in many packages. Same goes for the mutability/immutability aspect of code. A second example of this culture is the go language. I read a few repo's, and the same style of programming is seemingly applied throughout. For the Java case, I can actually see operator overloading going haywaire over many codebases. The same as overengineering is a typical trait associated with Java.
willtim 9y ago
Arithmetic expressions on BigInteger and BigDecimal currently look like an OOP parody. I cannot believe there are folks willing to defend this decision. Even Sun couldn't resist overloading '+'.