String Interpolation

[Imperatorn]

On Thursday, 26 October 2023 at 10:12:49 UTC, Imperatorn wrote:
> On Thursday, 26 October 2023 at 09:42:27 UTC, Arafel wrote:
>> On 26/10/23 3:47, Adam D Ruppe wrote:
>>> [...]
>>
>> You are not mentioning this part:
>>
>>> [...]
>>
>> I would find it perfect if there were an option to define 
>> arbitrary prefixes to strings (other than the ones already 
>> used by the language), like `i"Hello, ${name}` or `sql"SELECT 
>> * FROM ${table};"`. Notice how the string itself doesn't need 
>> any marker in Java:
>>
>>> [...]
>>
>> It's needing both what I don't like and find confusing: 
>> `string s = i"Hello, ${world}".format` (or `.text`).
>>
>> We can do like Java, and assume that as soon as a template 
>> expression is found, it will be automatically considered an 
>> interpolated string, so actually strings literals will be 
>> interpolated by default, and only if there are no expressions 
>> the result would be a `string`.
>
> Yes, if D doesn't provide that. It would be the only language 
> (created by man at least) that does not give the user a string 
> if desired.

Any DIP that doesn't provide a way to get a string from an 
interpolated string is almost useless to the users. And the 
language exists for the users. It doesn't exists for library 
writers.

At some point in life you would want at least 1 user to actually 
use some of the language or libraries. Otherwise it's just a 
hobby project, nothing wrong with that, but it's not professional.

I don't see how there would be even more than 0 users that would 
find not being able to get a string useful. And if they do, it's 
very likely they just don't care at all or simple don't use 
strings, which would make them very poor judges of the 
consequences.

In various branches or psychology there are terms for this. Where 
you agrue for something just because you don't want to face the 
consequences of the alternative.

This is where we are right now. Since it takes energy to provide 
the user (who in the end is who matters) a clean interface, you 
instead begin to argue that the user never needs it, not because 
it is true, but because you don't want to face the consequences 
of implementing it for the user, because it is a big task.

That is not good design, and has been proven over the centuries, 
that if you do something the main users don't find reasonable, it 
doesn't matter what you think of the design, the users will make 
it change.

Just because you are creating something, doesn't automatically 
imply that it's good, ergonomic, logical or useful.

In the end, something is only useful if it's used. And a solution 
pushing all the work to the user is not only unintuitive and 
unergonomic, it also barely passes the laugh test.

It's like arguing that it would be totally acceptable that from 
now on, if uses want an int, they can't just do "int x", they 
must now write "int.asint x".

You could of course argue for that it would be good. It's easy:

If you write int.asint you can more clearly see that's in an int 
than before, it's 100% more visible = great for the user. int 
should not implicitly give you an int, who would want that 
anyway, to miss the advantages of int.asint readability and 
clarity of mind.

Also, why would you want an int by default? Just because it's 
intuitive doesn't mean the language should provide it.

It's just a few more keystrokes, no big deal, the users can 
handle it.

And it would be great for library writers because now they can 
work with int and make the decision to get an int a user 
decision, it's great.

etc

Now go watch your language fade into oblivion like Malbolge, 
INTERCAL or <insert your favorite language here>.


There's a clear difference between languages that exist for the 
users and languages that just exist for the language creators and 
library writers. The latter category fades into oblivion very 
quickly.