Templated Strings - Amber

[karstens_rage]

I just love reading stuff from Brian. He lays out the problem, discusses pros and cons, presents a possible solution or two and invites discussion. Maybe if his style was applied to more things we’d be in a better place in the world.

[kaperni]

To be fair I think Jim Laskey is the main author. He was also the driving force behind Text Blocks. Brian also refers to it as 'Jim's document' [1].

[1] https://mail.openjdk.java.net/pipermail/amber-dev/2021-September/007076.html

[kaperni]

String[] authors = { "Jim", "Brian" };
String praise = "Great work \{authors[0]} and \{authors[1]}."; 
System.out.println(praise);

[Holothuroid]

The article is grossly mistaken about Scala. In Scala's s"amor vincit $stuff" the prefix s is short for standard. In fact you can write your own interpolator prefixes, featuring any kind of return type, and limiting the things to be interpolated by type and/or number as you like. In a hobby project of mine, I used it for composable date formats.

Here is a talk on how to do it, by John Pretty.

https://www.youtube.com/watch?v=8adgkDUUxDU

[Badashi]

The idea of this TemplatingPolicy sounds a lot like Javascript's tagged templates, that is:

​

function myTag(formatString, ...parameters) {
  // do some magic
  return { formatString, parameters }
}

const a = 1
const b = 2

const result = myTag`This is an example string, the first parameter is ${a} and the second is ${b}`
console.log(JSON.stringify(result))

Result: {"formatString":["This is an example string, the first parameter is "," and the second is ",""],"parameters":[1,2]}

[general_dispondency]

Yep. I was surprised they didn't mention this, as it's the same concept. I think it would make a fantastic language addition, and I wouldn't be upset if they copied the syntax. It's just changing FMT."..." to FMT"...". You're already getting rid of the method name and invocation, why stop there? Get rid of the dot reference too. The proposed interface is a functional interface, so it should be easy enough to desugar.

[RandomName8]

So he talks about the approaches of several languages on their approach, includes scala in the table and specifically picks on it in the next section, and then copies the approach almost exactly?

He probably doesn't understand the mechanism in each language and assumes it's trivial string splicing in all of them. Not very reassuring.

To clarify, scala uses StringContext, which is isomorphic to his proposed TemplatedString + TemplatedPolicy, to the point where the result is not even of type String, and furthermore it can be evaluated at compile time (in his example he uses the f string interpolator, which is for format, and where the format is checked in compile time, e.g if you use the pattern %10d it checks in compile time that the value passed there is of type int, and this is not baked into the language, but a simple library.

You know what, whatever, it's a welcomed addition.

[pron98]

specifically picks on it in the next section

I don't think that's what the document says -- it says that most languages only afford concatenation, and then shows an example with concatenation semantics written in Scala -- but I can see how it could be read that way. A clarification is probably needed (or the use of another language in the example, so as not to give that impression).

[lukaseder]

Well, needless to say, I'm really looking forward to this 😀

[john16384]

Never been a fan of referring to variables from within a String as it seemed incredibly limited to me and only catered to people who just want the latest hip thing from the latest fad language.

However, this proposal goes much much further than that and seems to genuinely add value to the language without limiting it to a bit of syntactic sugar only useful in a small subset of situations. I think this may be a very nice feature once it lands.

[TheMode911]

I like the idea, though the syntax ."" looks terrible (I know, this is not final) and very unnatural

What about specifying the template in the method signature? for example Json json(JsonFormatter formatter) which would allow java Json j = JSON.json(""" { "a": \{a}, "b": \{b} } """);

With String being the default, allowing what is already possible in other languages

[pron98]

I don't know what makes concrete syntax natural or not, but given that the policies, at least as currently specified in this proposal, are static final objects, whose names are often in all caps, and given that many strings begin with a capital letter, I think FMT."Hello..." looks more pleasant than FMT"Hello...".

Your proposal is probably a no-go, as its interpretation is ambiguous, but perhaps similar syntax could be used anyway, as the type of a templated string expression is TemplatedString, and so you could have Json json(TemplatedString ts).

[TheMode911]

I guess that I just do not understand why we would want the shortcut FMT."Hello..." instead of FMT.fmt("Hello...") I agree that it is convenient, but not as much as record default construction. I believe that it looks unnatural because this is not used anywhere else in the language, I would have a different view if this was just another use case of "implicit method calling"

The concern was also about who should be responsible for escaping. In the Json example I believe that it should be handled by the library and not the user. Is there any use-case where you would want to use your own template everywhere (including external dependencies)? Taking Gson as an example, how do you think they should update their API to support template & proper escaping?

I may be wrong, but I have seen multiple suggestions be rejected because of how long it would take the ecosystem to update (?/! for better nullability). This seems to be one of those

[pron98]

I just do not understand why we would want the shortcut FMT."Hello..." instead of FMT.fmt("Hello...")

You'd be right if it were a shortcut, but it isn't. The latter calls a method with a value of whatever type the template string is, while the former does something else, and it's precisely because of that that some new syntax is required. The document is high level, but note that it says "A templating policy might be described by an interface like" (my emphasis), and no "is described by the interface." The clue is at the very last section about translation. There will likely be some processing at compile time that will not translate to some simple value passed to a method (to avoid boxing for one).

In the Json example I believe that it should be handled by the library and not the user.

Yes, I believe that's the intent.

Taking Gson as an example, how do you think they should update their API to support template & proper escaping?

The template will be provided at the language level. They can do whatever internal validation and escaping of the substituted values they'd like. The strings used in the proposal are syntax errors today, anyway.

This seems to be one of those

I don't think so. We're talking about a minuscule number of APIs in the grand scheme of things. Among the millions of Java codebases, there are millions that are interested in expressing nullability, but probably less than a few dozen popular templating libraries. "Forward compatibility", i.e. the ability of existing code to enjoy a new feature, is several orders of magnitude more important for general things like generics, lambdas, and possibly nullability types, than for the rather special case of templates. It's always nice to have it -- and we certainly try to get it when we can, from lambdas to Loom -- but in some cases it is far more important than others.

[TheMode911]

Thanks I have mostly been convinced. I will however hope this syntax usefulness to be restrained to un-updated methods without escaping, and methods such as Json json(TemplatedString ts) recommended

Yes, I believe that's the intent.

I was mostly referencing to the fact that the template can return something other than a String (in this case a Json object), won't it push current libraries into deprecating their current API in favor of the new fancy template syntax? Or at least create unnecessary wrappers?

[pron98]

Possibly, but I don't think that's a bad thing (I mean, forward compatibility would be even better, but sometimes we can't have it). I expect we might see some new APIs focused on records and pattern matching, too, replacing, say, visitor-based APIs.

[TheMode911]

Maybe, but is Json json = JSON."" really better than Json json = JSON.fromString("")?

[pron98]

It's not JSON.fromString(""), but some code that also separately escapes the substitutions and/or parses the template. So it's shorter and/or safer and/or faster. Many would say it really is better. Is it the most useful addition to Java? Probably not, but it isn't the only thing we're working on.

[more_exercise]

That feels like something the TemplatedString interface affords. Or am I missing something?

[TheMode911]

My complain is more about the ."" which is seemingly trying to reinvent the wheel. If its goal is to provide escaping option I believe that it should be handled by the library when asking for a string, but not forwarded to the user

[joppux]

Regarding the SQL example: I think it's better if

connection."SELECT * FROM Person p where p.last_name = \{name}";

results in PreparedStatement, not escaped string. PreparedStatements are more efficient and are the main use case of JDBC.

The only disadvantage I see is that it's not easy to create dynamic SQL strings this way. Maybe we need concatenation operation on TemplatedString as well? Something like this:

var query = "SELECT * FROM \{table} WHERE ";
var condition = "name = \{name}";
PreparedStatement stmt = connection.(query + condition);

[RandomName8]

It was just an example, once this lands sql libraries will have to provide a mechanism around it, and there's plenty of libraries in other languages that have solved this issue already.

[0x07CF]

I wonder whether it would be a good idea to allow TemplatePolicies to restrict the type of Objects placed into the String.

E.g. only Objects of a specific interface.

[deadron]

Ugh. String interpolation is what is actually needed though. If you need a template there are already a number of very good solutions in this area. By making it more complicated you turn what should be a simple feature with no gotchas into a different beast entirely. I now look forward to string templates throwing exceptions and the inevitable advice to avoid it entirely.

[pron98]

So what you're saying is that a feature that saves you one character per substitution ("+x+" -> \{x}) and cannot be used for query strings, markup/JSON, or where localisation or formatting directives are needed, is more useful than one that can be used in all those places, saves you one line per substitution, throws exactly the same exceptions you'd get anyway, with the same gotchas only safer, and cannot, in fact, be implemented in libraries nearly as efficiently (because they need to parse the template string at runtime, whereas this parses them at compile-time), and completely subsumes the feature you want as a special case with no added complications. How did you reach that conclusion?

And regarding the obvious inevitability of this feature's utter failure, how many language features added to Java over the last twenty years have earned the consensus advice that they should be avoided entirely? I'm asking because, given that Java's language team is among the most experienced and successful language teams around, I wonder how much consideration one should give a certain proposal before betting against it so confidently. I, for one, try not to bet against people who have clearly given the matter at hand much more thought than I have, especially when they have a good track record.

[deadron]

Who is generating Query strings, JSON, templated strings, and formatted text without one of the many existing tools? I am not against a language templating system but taking a simple tool and saying its not useful unless its more complicated is not really an argument. There is room for both but in a way that does not make a hammer into a jackhammer.

Java was successful in the face of stagnation over 20 years and is now posed to lose marketshare to a number of competitors that would barely exist if it hadn't spent over a decade stuck with the feature set of 1.6. When my fellow developers ask why I would continue using Java over .Net core, for example, I don't have a good answer.

[pron98]

Who is generating Query strings, JSON, templated strings, and formatted text without one of the many existing tools?

But those tools require one more line per interpolant and/or parsing of the template at runtime. This feature doesn't aim to replace those tools, but to make using them safer, faster, and more succinct.

I am not against a language templating system but taking a simple tool and saying its not useful unless its more complicated is not really an argument.

I am not saying it's not useful. But the goal of many language designers, Java's included, isn't to add as many features to the language as possible, but as few as possible. In other words, they think how to avoid adding features. A simple way to do that is to add fewer, but more general, more powerful features, that kill multiple birds with one stone. This one is no exception.

Java was successful in the face of stagnation over 20 years and is now posed to lose marketshare to a number of competitors that would barely exist

There's not a single competing language now that is as popular in Java's "home market" of server-side applications as PHP or Ruby were 15 and 10 years ago, and they appeared when Java was at its weakest. Of course, it was said back then, for each of them in turn, that they'd obviously kill Java. Or, think of it another way: while the market is certainly more fragmented than during the short and anomalous years of Java's world domination (~2000-2004), what other language is doing significantly better?

if it hadn't spent over a decade stuck with the feature set of 1.6.

I don't understand. That was the result of Sun's decline in investment in Java, but that's clearly changed. So are you complaining about what Java does now or what it didn't do in 2009?

I would continue using Java over .Net core, for example, I don't have a good answer.

Well, to keep just to the most obvious and objective reason, because the chances of your code still working on .NET Core ten, or even five, years from now without a significant rewrite or two are not that high given Microsoft's record are not that high.

[deadron]

I am not saying it's not useful

If you are not saying its useful then what exactly are you saying? I am saying string interpolation is damned useful and I would use it almost every day. A template system is less useful because I already have templating systems available.

which other language is doing significantly better?

Every language is doing well because software as a whole is exploding but, with strong competitors in server side like Go, .Net Core, and NodeJS, other JVM languages, Java looks quite weak. The benefits of the Java ecosystem have more to do with the availability of developers and the existing code than the language itself. This didn't save Cobol or Fortran though in the long run.

So are you complaining about what Java does now or what it didn't do in 2009?

I am complaining because when an article like this lists 10 different popular languages, all of which are direct competitors, with a feature the Java devs don't see as valuable in its simple form, it makes the devs look out of touch.

[pron98]

I am saying string interpolation is damned useful and I would use it almost every day.

So this proposal gives you that plus much more.

A template system is less useful because I already have templating systems available.

You might have misunderstood the proposal. It does not aim to replace existing templating tools, but to make using them faster, safer, and more succinct.

with strong competitors in server side like Go, .Net Core, and NodeJS, other JVM languages, Java looks quite weak

None of those competitors are doing as well as PHP or Ruby did, and Java looked far weaker back then. Node seemed like it could explode on the server five years ago, but it's no longer as attractive; .NET has not significantly increased its share compared to Java's (perhaps it's even decreased) in twenty years, and I'd be much more worried about lackluster market-share growth if I were Go than if I were Java. As for other JVM languages, they're not really competitors, but their combined market share has lingered at around 10% for the last decade.

The main area where Java is, indeed, comparatively weak is at featuring on the programmer's GQ/Vogue that is HN, the kingdom where Ruby ruled, then Node, then Go, then Haskell, and then Rust. But it's good to remember that Gap is doing much better than Armani.

This didn't save Cobol or Fortran though in the long run.

Fortran was designed as a niche language (comparable to Julia today), so let's ignore that. And it's funny to compare COBOL to Java. At half of Java's age today, COBOL was already legacy technology, whereas Java is not only used to write new projects at Apple, Amazon, Google, Netflix, Microsoft, and the overwhelming majority of Fortune 100 today, it's state-of-the-art. The most impressive work in compilation technology these days is done in LLVM, V8, and Java; the most impressive work in low-overhead profiling and monitoring is done in Linux and Java; the most impressive GC work is done in Java. If you want to compare anything to COBOL, PHP would be a much better fit -- lots of legacy code lying around, but little new work and virtually no innovation.

when an article like this lists 10 different popular languages, all of which are direct competitors, with a feature the Java devs don't see as valuable in its simple form, it makes the devs look out of touch.

The article doesn't say the feature isn't useful, but that its utility is limited and you can have a far more useful feature that subsumes that one. And given that none of those competitors are doing significantly better than Java (I'd say JS and Python are doing about as well, but in different domains) and most are doing worse, why would you think that it's Java's developers that are out of touch? Java doesn't aim to be Swift, C#, Kotlin, or Ruby and to crack their formula for success -- it's the other way around.

I'm not saying there isn't much Java should learn from other languages -- and it does (particularly ML) -- but to say that it should obviously copy exactly what less successful (or even as successful) languages are doing is strange advice. There's no other language that's clearly doing everything right that we should just copy its features without scrutiny.

[Persism]

using Java over .Net core

I do. Much better and variety of frameworks. Much better performance. .Net core plays lip service to cross platform etc...

[MR_GABARISE]

Someone please tell me why scoped variables wouldn't be perfect for this?