5 ms·

That's basically what is happening in Java, too. I have been programming Java for the past 20 years and I do enjoy new features. And I would like couple more f

That's basically what is happening in Java, too. I have been programming Java for the past 20 years and I do enjoy new features. And I would like couple more features myself. But I am also tech lead for a lot of new developers which I see they struggle finding sense in what is going on with Java. Not just the language, but the multitude of frameworks and other paraphernalia supposedly needed to make a working modern application. Rather than trying to understand it they are giving up and revert to copying and pasting code that works. And wait for somebody with experience to catch obvious problems on code review. I think this is not sustainable.

WalterBright 5y ago
We have an informal rule that every feature that starts with the words "Why not ..." gets rejected. New features need a justification for them. :-) Often, though, I just feel like Doctor No.
- lmilcin 5y ago
  Haha:) That's how I feel, too. I got new appreciation when it became my responsibility to care for productivity of a lot of people. Often people bring in new toys just to have some change in their work environment. I select for people who like to learn new things so why would I fault them for it? But I also see people don't understand how disruptive it is to productivity. People mostly see only gain side without seeing the outsize cost side of the problem. Even management doesn't seem to understand it. One time they brought me into large project that had trouble delivering and huge reliability problems and they told me my first priority problem is going to figure out how to upgrade Java from 1.6 to 11. My first question was "Why do you guys think it wasn't possible to deliver reliable applications with Java 1.6?"
- memling 5y ago
  > We have an informal rule that every feature that starts with the words "Why not ..." gets rejected. I wonder how much language inertia can be overcome by surveying what's been implemented multiple times and ranking them. One imagines a very minimal language with multiple implementations, say, of asynchronous I/O or common data structures. Frequently-implemented features would be good candidates for thoughtful inclusion.
  - lmilcin 5y ago
    That language already exists and it is called *Lisp. In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library.
    - fouric 5y ago
      I'm a Common Lisp user, and I would like to refine your claim. I don't think that many true "language features", like borrow checking and a static type system, can be implemented in a Lisp (without writing an entirely new language on top - Lisps are generally Turing complete, so you can always write an interpreter for another language on top, but I would claim that at that point you're not "extending your Lisp" so much as making a new one). Instead, what Lisps seem to excel at is allowing you to implement syntactic sugar. For instance, you can easily write CL macros that give you JSON/hashtable literal syntax, list comprehensions (pretend LOOP didn't exist), foo.bar to access struct elements, and infix notation - those things that people think of as being "part of the language" but don't give you any new capabilities (e.g. closures, a MOP, multiple-value returns, conditions).
    - memling 5y ago
      > In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library. I should have been perhaps a bit more clear, though T9 makes that hard. I mean more in the sense of standardization. In some ways, LISP makes a better case for what I've suggested simply because you can modify the syntax with such relative ease. If you see patterns emerge, it makes it easier to standardize a syntactic construction to make it less idiosyncratic.
codeflo 5y ago
With a bit of outside perspective, the Java ecosystem “solved” a lot of things with frameworks that are language features elsewhere (e.g., modules). So unfortunately, keeping the language simple can sometimes even increase the overall complexity. I think that’s a tricky thing to balance.
nivenkos 5y ago
What I find hard in modern Java (well more Scala in my case) is not so much that the language is big but that so many similar features means it's hard to see where things come in scope from. Like in Scala it could be from a trait (and traits can define variables), or inheritance, or implicit values. Compared to Rust or Go for example where I can read the docs for a struct, and easily see where the different parts come from (and follow those up if I want).
- lmilcin 5y ago
  That's what happens when the language has "history". Of course when they design a new language they try to incorporate all the features that developers demand at the moment in a way that makes sense. But once the language is developed it is difficult to add new features seamlessly. The new features are necessarily impaired in some way by having to be compatible with existing environment. Rest assured, wait couple decades and the same will happen to Rust.
pjmlp 5y ago
Similar experience, what I learned with Java and I see Go going through exactly the same mistakes, is that when the language is too small, the complexity lands on the eco-system. That is how you get AOP frameworks, code generators based on EMF, XML driven frameworks,....
jimbokun 5y ago
The current nightmare of Java programming is Annotation Driven Development. Especially with things like Spring Boot, most of the behavior is driven by sprinkling annotations, but you can not use your understanding of the syntax and semantics of the Java language to understand what they do. It's just thrashing around trying different combinations of annotations and configuration until something works. And God help you if you need to debug what's going on if it stops working on some corner case.
- lmilcin 5y ago
  This can be stated more generically by saying, that in the past it was possible to tell what a line of code does in Java. This is what you pay for when you bear costs of strong typing -- being able to say what is that thing holding. But that very important valuable feature was squandered over time with the biggest offender being Spring.
  - jimbokun 5y ago
    Now we have the flexibility and conciseness of explicit static typing with none of the run time guarantees!
- jamesfinlayson 5y ago
  Agreed - I don't mind Spring but just blindly copy+pasting a bunch of annotations to make things work doesn't feel good.

WalterBright 5y ago

We have an informal rule that every feature that starts with the words "Why not ..." gets rejected. New features need a justification for them. :-) Often, though, I just feel like Doctor No.

lmilcin 5y ago
Haha:) That's how I feel, too. I got new appreciation when it became my responsibility to care for productivity of a lot of people. Often people bring in new toys just to have some change in their work environment. I select for people who like to learn new things so why would I fault them for it? But I also see people don't understand how disruptive it is to productivity. People mostly see only gain side without seeing the outsize cost side of the problem. Even management doesn't seem to understand it. One time they brought me into large project that had trouble delivering and huge reliability problems and they told me my first priority problem is going to figure out how to upgrade Java from 1.6 to 11. My first question was "Why do you guys think it wasn't possible to deliver reliable applications with Java 1.6?"
memling 5y ago
> We have an informal rule that every feature that starts with the words "Why not ..." gets rejected. I wonder how much language inertia can be overcome by surveying what's been implemented multiple times and ranking them. One imagines a very minimal language with multiple implementations, say, of asynchronous I/O or common data structures. Frequently-implemented features would be good candidates for thoughtful inclusion.
- lmilcin 5y ago
  That language already exists and it is called *Lisp. In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library.
  - fouric 5y ago
    I'm a Common Lisp user, and I would like to refine your claim. I don't think that many true "language features", like borrow checking and a static type system, can be implemented in a Lisp (without writing an entirely new language on top - Lisps are generally Turing complete, so you can always write an interpreter for another language on top, but I would claim that at that point you're not "extending your Lisp" so much as making a new one). Instead, what Lisps seem to excel at is allowing you to implement syntactic sugar. For instance, you can easily write CL macros that give you JSON/hashtable literal syntax, list comprehensions (pretend LOOP didn't exist), foo.bar to access struct elements, and infix notation - those things that people think of as being "part of the language" but don't give you any new capabilities (e.g. closures, a MOP, multiple-value returns, conditions).
  - memling 5y ago
    > In a proper Lisp you can take anything that in a regular language would be a language feature and implement it as a library. I should have been perhaps a bit more clear, though T9 makes that hard. I mean more in the sense of standardization. In some ways, LISP makes a better case for what I've suggested simply because you can modify the syntax with such relative ease. If you see patterns emerge, it makes it easier to standardize a syntactic construction to make it less idiosyncratic.

codeflo 5y ago

With a bit of outside perspective, the Java ecosystem “solved” a lot of things with frameworks that are language features elsewhere (e.g., modules). So unfortunately, keeping the language simple can sometimes even increase the overall complexity. I think that’s a tricky thing to balance.

nivenkos 5y ago

What I find hard in modern Java (well more Scala in my case) is not so much that the language is big but that so many similar features means it's hard to see where things come in scope from. Like in Scala it could be from a trait (and traits can define variables), or inheritance, or implicit values. Compared to Rust or Go for example where I can read the docs for a struct, and easily see where the different parts come from (and follow those up if I want).

lmilcin 5y ago
That's what happens when the language has "history". Of course when they design a new language they try to incorporate all the features that developers demand at the moment in a way that makes sense. But once the language is developed it is difficult to add new features seamlessly. The new features are necessarily impaired in some way by having to be compatible with existing environment. Rest assured, wait couple decades and the same will happen to Rust.

pjmlp 5y ago

Similar experience, what I learned with Java and I see Go going through exactly the same mistakes, is that when the language is too small, the complexity lands on the eco-system. That is how you get AOP frameworks, code generators based on EMF, XML driven frameworks,....

jimbokun 5y ago

The current nightmare of Java programming is Annotation Driven Development. Especially with things like Spring Boot, most of the behavior is driven by sprinkling annotations, but you can not use your understanding of the syntax and semantics of the Java language to understand what they do. It's just thrashing around trying different combinations of annotations and configuration until something works. And God help you if you need to debug what's going on if it stops working on some corner case.

lmilcin 5y ago
This can be stated more generically by saying, that in the past it was possible to tell what a line of code does in Java. This is what you pay for when you bear costs of strong typing -- being able to say what is that thing holding. But that very important valuable feature was squandered over time with the biggest offender being Spring.
- jimbokun 5y ago
  Now we have the flexibility and conciseness of explicit static typing with none of the run time guarantees!
jamesfinlayson 5y ago
Agreed - I don't mind Spring but just blindly copy+pasting a bunch of annotations to make things work doesn't feel good.