Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 430: String Templates (Preview) Proposed to Target Java 21

openjdk.org

Post reply on HN
Print view View original

161–170 of 246 posts

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#161

Post by pron »

chlorion wrote: post #116
pron wrote: post #26

Earlier quoted context omitted.

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, especi…

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

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

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#162

Post by pron »

ko27 wrote: post #42

It's interesting how C# is always far ahead of Java, they introduced it way earlier, the syntax is simpler, and you can make is safe by using FormattableString as the param type, for example in EF you can do this without worrying about SQL injection: FromSql($"EXECUTE dbo.GetMostPopularBlogsForUser {user}") https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

Whether or not a hoarder is "ahead" of you at having stuff is a matter of perspective. C# strives to be a very feature-rich language, while Java strives to be minimalistic. So it's pretty certain that any feature Java does end up adding will have been in C# first (although this one is not quite the same), but Java certainly doesn't want to go in the same direction.

On the other hand, Java's GCs, JIT compilers, and observability features are more sophisticated than .NET's. We like adding stuff to our runtime, while C# likes adding stuff to the language.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#163

Post by zelphirkalt »

kaba0 wrote: post #127
zelphirkalt wrote: post #97

Earlier quoted context omitted.

It is not really innovating, if it has been battle-tested by other languages, is it? While modern Java sometimes makes me think about reviving and modernizing an old project of mine, if Java is simply always behind by design of its evolution process, that makes it less likely, that I want to spend time with it.

Your mileage may vary, but I went from liking simple languages like Java, to very expressive, complex ones (Scala, Haskell, Rust) back to Java. I mean, I like all those languages (and many more), but the thing is, most programs really don’t need all that many language features — an okayish type system, OOP for encapsulating private vs public state, and preferring immutable public APIs have served me well in almost ev…

Smalltalk should be a no-brainer then. Arguably one of the simplest languages with merely 6 keywords and immense power. The ecosystem is of course a question.

I think I can understand the journey from Java -> other -> Java, because as you learn more about programming, you become more capable of solving problems properly in a simpler language. But there might be a point, when you get fed up again with writing the same old stuff over and over again, and journey on into languages, which allow you to abstract from syntax, making programming more pleasant. And then maybe back again, for type safety or another reason. It is very understandable to move between those preferences over time, or even have an inner conflict about what one wants to use for ones next project.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#164

Post by zelphirkalt »

kaba0 wrote: post #151
sirsinsalot wrote: post #149

Earlier quoted context omitted.

It isn't often I see Java described as simple.

It has quite a few keywords, you have primitives and objects and you call methods on those. Compare it to C#, Swift or C++, and it is insanely tiny compared to those.

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k... lists 50 keywords for Java.

https://en.cppreference.com/w/cpp/keyword lists 97 keywords for C++.

https://realpython.com/python-keywords/ lists 35 keywords for Python 3.8.

https://en.wikipedia.org/wiki/Smalltalk#Syntax lists 6 keywords for Smalltalk.

Neither one of them I would consider small or simple, but you are correct, that Java has much fewer than C++ and I would definitely agree, that it is the simpler language.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#165

Post by pron »

sonicgear1 wrote: post #152
mabbo wrote: post #3

String name = "Joan"; String info = STR."My name is \{name}"; I don't love it, to be honest. `STR` is a bit much. Requiring the \ for the first but not second brace. I want string templates in Java, but this feels ugly.

Agree. Java can't even get the simplest things right. This stuff makes me want to cry.

I tell you, if the longest lasting super popularity of any programming language in the history of computing (with the possible exception of C) is what failure to get anything right looks like, I hope we keep getting things wrong just like that for decades to come.

But to those who ever wish to have another language that's as successful as Java, I would suggest studying what it is that Java values, which might explain why is it that almost twenty years after having died at the hands PHP, and some years later being finished off again for good measure by Ruby, and then had its coffin nailed shut by Node, Java is still more lively than its supposed heirs.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#166

Post by sirsinsalot »

zelphirkalt wrote: post #164
kaba0 wrote: post #151

Earlier quoted context omitted.

It has quite a few keywords, you have primitives and objects and you call methods on those. Compare it to C#, Swift or C++, and it is insanely tiny compared to those.

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k... lists 50 keywords for Java. https://en.cppreference.com/w/cpp/keyword lists 97 keywords for C++. https://realpython.com/python-keywords/ lists 35 keywords for Python 3.8. https://en.wikipedia.org/wiki/Smalltalk#Syntax lists 6 keywords for Smalltalk. Neither one of them I would consider small or simple, but you are correct, that Java has much fewer than C…

Simpler syntax != simpler semantics. Also syntactic sugar can simplify language comprehension but adds tokens.

Keywords is a poor metric for complexity in any sense other than choice of keywords.

That IMHO doesn't make a language complex in any meaningful way engineering wise.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#167

Post by vips7L »

kaba0 wrote: post #146
saagarjha wrote: post #145

Earlier quoted context omitted.

There is exactly one good reason against operator overloading, and that’s operator<<. People are mostly sane otherwise and it’s a good thing to have.

Arbitrary overloading can be problematic, like !#< or whatever is quite hard to look up (scala, haskell), but I agree that implementing an interface/trait that will give you that syntactic sugar is mostly okay (like Rust, e.g. implements Add would give you + operator).

I remember working in some scala that used akka actors and seeing ! for the first time. Something like:

  actor ! someData
It was just an operator to send the data to the actor. A named function would have been so much better.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#168

Post by agumonkey »

Noe2097 wrote: post #22

Why oh why is that a backslash!? Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`. `\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice. This really makes me sad. It looks like the choice was made on purpose to be different.

It's horrible but I can't get over it. The value of string template is also aesthetic.. and these are like staples. Java once again.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#169

Post by sitta »

pron wrote: post #165
sonicgear1 wrote: post #152

Earlier quoted context omitted.

Agree. Java can't even get the simplest things right. This stuff makes me want to cry.

I tell you, if the longest lasting super popularity of any programming language in the history of computing (with the possible exception of C) is what failure to get anything right looks like, I hope we keep getting things wrong just like that for decades to come. But to those who ever wish to have another language that's as successful as Java, I would suggest studying what it is that Java values, which might explain…

My fear is that Java is now only popular in a professional setting, and is no longer of interest in the broader community. This is sad to me because I personally love the features that you all have been delivering in recent releases, and am very excited about the ones coming down the pike.

A few circumstantial examples. If you look at the Matrix SDKs and implementations (https://matrix.org/docs/projects/try-matrix-now/), Java's presence is sorely lacking. The initial server implementation was written in Python of all things and the rewrite in Go. This is baffling as a Java implementation seems like a no-brainer to me.

In addition to working for a variety of corporations, I have also done some work for academic institutions, specifically in the library space. They have a lot of old tools from the 2000-2010ish range that are predominantly in Java. However, now, these institutions are primarily using Python and Javascript, and are even struggling to find Java developers to maintain their old infrastructure.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#170

Post by Quekid5 »

lenkite wrote: post #75
kaba0 wrote: post #56

Earlier quoted context omitted.

Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.

Pity that the Streams functions don't support checked exceptions.

It's the only sane way.

Checked exceptions were a fundamental mistake which basically makes it impossible to actually use (non-RuntimeException derived) exceptions reliably for their intended purpose. As soon as you introduce any higher-order programming (e.g. functions that take other functions as parameters) you start to have to wrap e.g. IOException... but that means that calling code can no longer catch that wrapped IOException via a simple "catch (IOException e) { ... }"... it instead has to catch whatever you wrapped that exception in... and manually look inside that Throwable's suppressedExceptions list. And so you end up with stuff like Guava's Throwables utility methods.

Of course, this probably happened because Java basically didn't have much in the way of higher-order constructs at the start, so they didn't notice that they were painting themselves into a corner... If they had a more powerful type system something usable might be possible, but as of Java right now, it just hopelessly broken.

I'd suggest that a fix to the langauge would be to simply change all exceptions to unchecked, but unfortunately that might break a lot of code where the above workaround has already been implemented once consumed libraries switch away from wrapping. (Note that it's only Java-the-language which has checked exceptions. The JVM doesn't and Scala/Kotlin are much the better for it.)

EDIT: The JVM is a marvel of engineering. Java... not so much.

Post reply on HN