6 ms·

> Gosling: For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random De

> Gosling: For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up.[0] So we can have this super powerful, extensible string interpolation system using never-before-seen syntax as a language feature, not a standard library extension, but not unsigned integers? I'll echo what other commenters have said: This looks powerful but ugly. I'll add to it by pointing out that "powerful but ugly" is what we've already got. So we gain the ability to move format arguments inline with the string contents if we're willing to use the `STR."\{}"` syntax? That seems like a lateral move. 0. http://www.gotw.ca/publications/c_family_interview.htm http://www.gotw.ca/publications/c_family_interview.htm

pron 4y ago
We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. The extensibility and power of string templates were a requirement; security experts quite simply vetoed adding string interpolation as it's just too dangerous, especially in server-side software, where Java is mostly used. As to `STR.` -- which you won't need to use most of the time -- see my other comment: https://news.ycombinator.com/item?id=35013470 https://news.ycombinator.com/item?id=35013470
- Kwpolska 4y ago
  Python is also widely used server-side, and they introduced f-strings with simple and friendly syntax a few years ago. JS added template literals in 2015’s ES6, when Node.js was very much a thing. Why is Java special here?
  - pron 4y ago
    Java's syntax is just as friendly and simple -- see my other comments on the subject -- it just requires the receiver to define a policy, which is essential for security. You only need to use STR when the receiver does not define a template processor and works with strings. I have no idea what Python's or JS's security experts advised, but that code injection is one of the most common vulnerabilities in memory-safe languages is a fact reported by all security advisories. String interpolation is one of the most dangerous features a language can have.
    - optician_owl 4y ago
      I would argue that jdbc API is far more dangerous than string interpolation :) But I wholeheartedly support the idea of JEP. Scala got several good UX benefits based on the string interpolation (sql and logging).
    - Kwpolska 4y ago
      I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might end up reading old tutorials, and will then notice the “inefficiency” of the prepared statement syntax and will just do a STR."" format. Or they might consider the database.executeQuery."SELECT \{x}"; syntax “invalid” and try to fix it.
      - pron 4y ago
        Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature. Just remember that you can't pass a string to an API that doesn't take strings, and even with existing APIs, methods that take strings can be deprecated to cause compiler warnings. So sometimes there are stronger ways than just documentation to discourage dangerous code.
- rcoveson 4y ago
  > We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. You (collectively) have this wrong; C, C++, C#, Rust, Go, et al. have it right. As long as we're just stating our beliefs outright instead of justifying them, that is. (That's not a request to justify your opinion; I'm sure it's been argued to death already.) > security experts quite simply vetoed adding string interpolation as it's just too dangerous Laughable. In an alternate universe where it didn't already exist, this could have been a JEP for StringBuilder and they would have vetoed that too. > As to `STR.` -- which you won't need to use most of the time Except for when you're trying to... make a String? Which is what ~everybody who ever asked for string interpolation in Java wanted to do? What year would you estimate it will be when, at the average Java job, I can expect that most of the library APIs available to me which were often invoked with the form `func(String.format(...))` will have similar APIs that behave as JEP 430 template processors? Maybe after it's been full release for 3 years? 2, optimistically? Because during those years, in order to use this thing at all, people will be using `STR."\{}"`
  - pron 4y ago
    Maybe you're right, but I think it's not so much a matter of what's right or wrong, but what's appropriate for languages with different audience size. Our experience is at evolving a language for a certain audience size, and perhaps if Java's popularity declines to the more modest market shares of the languages you mentioned, their choices may become appropriate for Java, too. As to your other points, like I explained to someone else here, even three decades of experience evolving a language that's achieved a measure of success is still no guarantee that every feature will work well, which is why most big new features, string templates included, are first released as preview (i.e. a feature that may change). That allows us to test our hypotheses against the problems people actually encounter rather than those we or others may speculate they'd encounter, and adjust the feature accordingly before it is finalised. To the best of my knowledge, all preview features have undergone some adjustment before becoming permanent, but usually the changes required were relatively small. Also, we try to think more long-term, because in ten years no one is going to care or even remember if a feature arrived five or seven years prior.
  - 4y ago
- chlorion 4y ago
  > We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. What disadvantages do unsigned ints have?
  - kaba0 4y ago
    https://news.ycombinator.com/item?id=35018974 https://news.ycombinator.com/item?id=35018974
  - pron 4y ago
    Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfields -- but Java doesn't have those, and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware, that not many do and for which we have other solutions. So some very dangerous disadvantages and not many advantages for a language like Java. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...
    - gergo_barany 4y ago
      > E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Overflowing your unsigned integer is almost certainly wrong, but overflowing your signed integer is almost certainly wrong as well. > not many advantages for a language like Java. Agreed.
      - 4y ago

pron 4y ago

We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. The extensibility and power of string templates were a requirement; security experts quite simply vetoed adding string interpolation as it's just too dangerous, especially in server-side software, where Java is mostly used. As to `STR.` -- which you won't need to use most of the time -- see my other comment: https://news.ycombinator.com/item?id=35013470 https://news.ycombinator.com/item?id=35013470

Kwpolska 4y ago
Python is also widely used server-side, and they introduced f-strings with simple and friendly syntax a few years ago. JS added template literals in 2015’s ES6, when Node.js was very much a thing. Why is Java special here?
- pron 4y ago
  Java's syntax is just as friendly and simple -- see my other comments on the subject -- it just requires the receiver to define a policy, which is essential for security. You only need to use STR when the receiver does not define a template processor and works with strings. I have no idea what Python's or JS's security experts advised, but that code injection is one of the most common vulnerabilities in memory-safe languages is a fact reported by all security advisories. String interpolation is one of the most dangerous features a language can have.
  - optician_owl 4y ago
    I would argue that jdbc API is far more dangerous than string interpolation :) But I wholeheartedly support the idea of JEP. Scala got several good UX benefits based on the string interpolation (sql and logging).
  - Kwpolska 4y ago
    I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might end up reading old tutorials, and will then notice the “inefficiency” of the prepared statement syntax and will just do a STR."" format. Or they might consider the database.executeQuery."SELECT \{x}"; syntax “invalid” and try to fix it.
    - pron 4y ago
      Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature. Just remember that you can't pass a string to an API that doesn't take strings, and even with existing APIs, methods that take strings can be deprecated to cause compiler warnings. So sometimes there are stronger ways than just documentation to discourage dangerous code.
rcoveson 4y ago
> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. You (collectively) have this wrong; C, C++, C#, Rust, Go, et al. have it right. As long as we're just stating our beliefs outright instead of justifying them, that is. (That's not a request to justify your opinion; I'm sure it's been argued to death already.) > security experts quite simply vetoed adding string interpolation as it's just too dangerous Laughable. In an alternate universe where it didn't already exist, this could have been a JEP for StringBuilder and they would have vetoed that too. > As to `STR.` -- which you won't need to use most of the time Except for when you're trying to... make a String? Which is what ~everybody who ever asked for string interpolation in Java wanted to do? What year would you estimate it will be when, at the average Java job, I can expect that most of the library APIs available to me which were often invoked with the form `func(String.format(...))` will have similar APIs that behave as JEP 430 template processors? Maybe after it's been full release for 3 years? 2, optimistically? Because during those years, in order to use this thing at all, people will be using `STR."\{}"`
- pron 4y ago
  Maybe you're right, but I think it's not so much a matter of what's right or wrong, but what's appropriate for languages with different audience size. Our experience is at evolving a language for a certain audience size, and perhaps if Java's popularity declines to the more modest market shares of the languages you mentioned, their choices may become appropriate for Java, too. As to your other points, like I explained to someone else here, even three decades of experience evolving a language that's achieved a measure of success is still no guarantee that every feature will work well, which is why most big new features, string templates included, are first released as preview (i.e. a feature that may change). That allows us to test our hypotheses against the problems people actually encounter rather than those we or others may speculate they'd encounter, and adjust the feature accordingly before it is finalised. To the best of my knowledge, all preview features have undergone some adjustment before becoming permanent, but usually the changes required were relatively small. Also, we try to think more long-term, because in ten years no one is going to care or even remember if a feature arrived five or seven years prior.
- 4y ago
chlorion 4y ago
> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. What disadvantages do unsigned ints have?
- kaba0 4y ago
  https://news.ycombinator.com/item?id=35018974 https://news.ycombinator.com/item?id=35018974
- pron 4y ago
  Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfields -- but Java doesn't have those, and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware, that not many do and for which we have other solutions. So some very dangerous disadvantages and not many advantages for a language like Java. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...
  - gergo_barany 4y ago
    > E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Overflowing your unsigned integer is almost certainly wrong, but overflowing your signed integer is almost certainly wrong as well. > not many advantages for a language like Java. Agreed.
    - 4y ago