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

141–150 of 246 posts

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

#141

Post by hibbelig »

nezirus wrote: post #17

That database stuff looks horrible. Why do they feel the need to introduce DB query templating into string templates? No matter what you do on the client side, the database engine itself should escape/validate the data. Didn't we learn that lesson with PHP? In addition to that, not every database needs prepared statements for safe queries e.g. "Parametrized queries" in PostgreSQL (available in libpq as PQExecParams a…

You have to escape the things before they reach the database engine. Prepared statements do this via ? Placeholders but they are hard to read. With this you get named placeholders, much nicer to read.

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

#142

Post by Too »

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.

I don’t mind the typing ergonomy. More that it is visually ugly and counter-intuitive. Because in every other language a backslash would mean you want to keep the braces instead of interpolating the variable inside. They even have a comparison table at the top of the document, where they didn’t dare to put the Java option next to the others because it would stand out as being too different. Why not just follow the established conventions?

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

#143

Post by saagarjha »

tialaramex wrote: post #83
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.

Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. Imagine if some other common types had unrelated features like this baked into them. Want a string? Sorry in my new language all the strings need their own separate thread for some reason. Actually sorry, I forgot, we're in a Java topic, Java actually did have features baked into t…

> Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types.

There’s nothing wrong with implied control flow.

> All of Java's user defined types insisted on living on the heap. Just want to make a pair of integers? Sorry, that's an Object now and so it lives on the heap, whereas just one integer is fine, those are just local stack variables.

That’s not how Java works. The runtime is free to store things wherever it likes, with whatever representation it likes. It needs to follow the semantics of the standard, but whatever gets executed is what the JIT felt like emitting.

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

#144

Post by saagarjha »

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 the “escape” character.

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

#145

Post by saagarjha »

kaba0 wrote: post #133
rcoveson wrote: post #93

Earlier quoted context omitted.

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

Java still sits very close to JVM byte code, which is typed - adding unsigned ints would duplicate a huge deal of instructions. So this feature has to wait for primitive classes, where it can be as simple as primitive class unsigned { int value; } (Though it would need operator overloading to be used as a+b, which is not really liked in Java designer niches (with many good reasons against it) :D )

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.

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

#146

Post by kaba0 »

saagarjha wrote: post #145
kaba0 wrote: post #133

Earlier quoted context omitted.

Java still sits very close to JVM byte code, which is typed - adding unsigned ints would duplicate a huge deal of instructions. So this feature has to wait for primitive classes, where it can be as simple as primitive class unsigned { int value; } (Though it would need operator overloading to be used as a+b, which is not really liked in Java designer niches (with many good reasons against it) :D )

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).

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

#147

Post by qw »

lenkite wrote: post #77
qw wrote: post #48

Earlier quoted context omitted.

I agree. On my keyboard I need to press ⌥ + ⌘ + 7 It's actually made worse because { and } also need special combinations. To type \{X} I need to press (⌥ + ⌘ + 7) (SHIFT + ⌥ + 8) X (SHIFT + ⌥ + 9) I know this is something we need to live with due to historical reasons, but I would prefer that new syntax is made simpler.

What about parenthesis () and square brackets [] ? (writing a lisp DSL that might have users from non-US layouts)

They are ok to use

I press ⌥ + 8 for square brackets and SHIFT + 8 for parentheses.

It's probably not possible to find better alternatives for Mac keyboards that could be used for a language based on Lisp syntax.

The Mac keyboard simply doesn't have any dedicated keys that are not used for normal text, except for "@". For some unknown reason, they have a dedicated key for umlauts ("¨") that we don't use in our language. I guess I could map it to brackets, but SHIFT + UMLAUT returns a "^" that is often used in regexps and I don't want to lose that.

Windows keyboards has a different layout that is slightly more programmer friendly if you have a full sized keyboard. They do have a backslash key but lack the dedicated "@" key. Windows needs a dedicated backslash due to the file paths, unlike Mac. It is an acceptable tradeoff for Mac users, as non-developers are more likely to use "@" than "\".

Let's just say that there is a reason why I love my IDE that will automatically add closing curly brackets when it detects a block.

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

#148

Post by v-erne »

qw wrote: post #48
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.

I agree. On my keyboard I need to press ⌥ + ⌘ + 7 It's actually made worse because { and } also need special combinations. To type \{X} I need to press (⌥ + ⌘ + 7) (SHIFT + ⌥ + 8) X (SHIFT + ⌥ + 9) I know this is something we need to live with due to historical reasons, but I would prefer that new syntax is made simpler.

You just made me to get my MacBook out of closet :) (I stopped using it two months ago and moved to X1 carbon right before pandemic)

The ergonomic of \{X} is exactly the same on it as on my carbon x1, my keychron tls and four other keyboards I happen to have in my drawer.

Are You using modified Apple II like Rebecca Heineman or some kind of super small keyboard that looks like someone forgot to put all the keys in :) ?

Either way its on you not Java.

(Dont take this wrong way - this is an honest question - here in Poland almost all keyboard are backslash friendly and I would live to knowe where this is not the case)

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

#149

Post by sirsinsalot »

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…

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

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

#150

Post by sirsinsalot »

dmitriid wrote: post #91
kothar wrote: post #28

Earlier quoted context omitted.

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.

This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.

if you ever had the misfortune of seeing the code for the parser and lexer of earlier versions of PHP youd see that it wasnt due to parsing simplicity but rather the author making poor syntax decisions due to a lack of understanding.

Then being walled in by backwards compatibility

Post reply on HN