5 ms·

I'm glad Java is being conservative and not doing that. JS/Python f-strings have not proven themselves long-term. It also bloats the language with yet another m

by zelly 6y ago

I'm glad Java is being conservative and not doing that. JS/Python f-strings have not proven themselves long-term. It also bloats the language with yet another mini-DSL. You can always add a proper templating engine on top.

bad_user 6y ago
Java relies on String + Object for composing strings, thus unsafely converting any object into string. An implicit conversion, akin to what JavaScript is doing. String interpolation would be safer, as it would make the intent clearer, and you wouldn't risk bumping in corner cases. It would be even safer if the protocol could be overrided such that you wouldn't have to use Object#toString, but for Java that's too much already. Java has been a very conservative language. And I understand why. But it's funny how, for many features that were added later, people were rationalizing their absence with such lines too. E.g. we don't need anonymous functions / lambdas, as anonymous classes are enough. Well, turned out that Microsoft was right all along when they released those in J#. Also adding a template engine is overkill for doing string concatenation.
- zelly 6y ago
  > But it's funny how, for many features that were added later, people were rationalizing their absence with such lines too There's nothing wrong with that. If string interpolation is really useful, then Java will add it some years down the line. It's cheap to add features but literally impossible to remove them. There's no way to undo a mistake in language design. That's an asymmetry. I'd rather err on the side of caution than kitchen-sinking it.
  - bad_user 6y ago
    Oh, I don't know about that. I wouldn't call it impossible. I like how Java binaries still work on the latest Java, however, if distribution happens via binaries, why should the language keep source compatibility anyway? Or, you know, the latest compiler could allow you to select the source code version you want. And automated code migration tools can work too. --- Err'ing on the side of not getting features is why Java has lost a lot of mindshare. Java is still super popular, but that's basically in spite of the language itself, because the language is awful.
  - fomine3 6y ago
    > If string interpolation is really useful, then Java will add it some years down the line. Now is the year. String interpolation is really harmless feature.
- pjmlp 6y ago
  J++, J# was as transition into .NET.
  - bad_user 6y ago
    Indeed, you're correct.
- 60secz 6y ago
  It deeply pains me that String is only a concrete type and that Object.toString() does not implement an interface.
oblio 6y ago
Conservative? We've had "f-strings" since 1979, at least.
- CydeWeys 6y ago
  The ones in Python work significantly differently though; they have inline code execution (rather than using a varargs list after the f-string itself).
  - mixmastamyk 6y ago
    So does shell script and several modern programming langs. The sky hasn't yet fallen.
  - oblio 6y ago
    I've just executed: echo "$(ls)" in my zsh, so I'm not sure what to say, to be honest.
    - danudey 6y ago
      Closer to: echo "Username is ${USER}" As I recall (and Wikipedia seems to confirm), parameter substitutions were in the original bourne shell in 1979, so... Yeah, I'm not sure what's going on there.
  - danudey 6y ago
    The Bourne shell had parameter expansion in strings in 1979, just FYI.
Drdrdrq 6y ago
> JS/Python f-strings have not proven themselves long-term. Are you saying that they haven't been around for long or that they failed? If latter, then I respectfully disagree. Any recent JS and Python code I have seen uses them extensively. They are also a joy to use, and imho improve readability immensely. Ergonomics matter. This is one aspect of Python3 I would miss the most if I had to go back to 2.

by zelly 6y ago

bad_user 6y ago

Java relies on String + Object for composing strings, thus unsafely converting any object into string. An implicit conversion, akin to what JavaScript is doing. String interpolation would be safer, as it would make the intent clearer, and you wouldn't risk bumping in corner cases. It would be even safer if the protocol could be overrided such that you wouldn't have to use Object#toString, but for Java that's too much already. Java has been a very conservative language. And I understand why. But it's funny how, for many features that were added later, people were rationalizing their absence with such lines too. E.g. we don't need anonymous functions / lambdas, as anonymous classes are enough. Well, turned out that Microsoft was right all along when they released those in J#. Also adding a template engine is overkill for doing string concatenation.

zelly 6y ago
> But it's funny how, for many features that were added later, people were rationalizing their absence with such lines too There's nothing wrong with that. If string interpolation is really useful, then Java will add it some years down the line. It's cheap to add features but literally impossible to remove them. There's no way to undo a mistake in language design. That's an asymmetry. I'd rather err on the side of caution than kitchen-sinking it.
- bad_user 6y ago
  Oh, I don't know about that. I wouldn't call it impossible. I like how Java binaries still work on the latest Java, however, if distribution happens via binaries, why should the language keep source compatibility anyway? Or, you know, the latest compiler could allow you to select the source code version you want. And automated code migration tools can work too. --- Err'ing on the side of not getting features is why Java has lost a lot of mindshare. Java is still super popular, but that's basically in spite of the language itself, because the language is awful.
- fomine3 6y ago
  > If string interpolation is really useful, then Java will add it some years down the line. Now is the year. String interpolation is really harmless feature.
pjmlp 6y ago
J++, J# was as transition into .NET.
- bad_user 6y ago
  Indeed, you're correct.
60secz 6y ago
It deeply pains me that String is only a concrete type and that Object.toString() does not implement an interface.

oblio 6y ago

Conservative? We've had "f-strings" since 1979, at least.

CydeWeys 6y ago
The ones in Python work significantly differently though; they have inline code execution (rather than using a varargs list after the f-string itself).
- mixmastamyk 6y ago
  So does shell script and several modern programming langs. The sky hasn't yet fallen.
- oblio 6y ago
  I've just executed: echo "$(ls)" in my zsh, so I'm not sure what to say, to be honest.
  - danudey 6y ago
    Closer to: echo "Username is ${USER}" As I recall (and Wikipedia seems to confirm), parameter substitutions were in the original bourne shell in 1979, so... Yeah, I'm not sure what's going on there.
- danudey 6y ago
  The Bourne shell had parameter expansion in strings in 1979, just FYI.

Drdrdrq 6y ago

> JS/Python f-strings have not proven themselves long-term. Are you saying that they haven't been around for long or that they failed? If latter, then I respectfully disagree. Any recent JS and Python code I have seen uses them extensively. They are also a joy to use, and imho improve readability immensely. Ergonomics matter. This is one aspect of Python3 I would miss the most if I had to go back to 2.