Nordic countries have essentially exactly the same 1/3 two year recidivism rate as the US, the one exception being Norway at 1/5, and mostly not for rehabilitation policy reasons.
My memory is that ES6's template strings preceded f-strings. If that is correct, do you happen to know why python was saddled with f-strings, which seem like an obviously inferior design, in the first place? We are now at five largely redundant string interpolation systems (%, .format, string.Template, f-string, t-string).
PEP 501 when originally written (not by me) was intended to be the competing standard against f-strings, and to have been more inline with ES6's template strings. There was debate between the more simple f-string PEP (PEP 498) and PEP 501. Ultimately, it was decided to go with f-strings as a less confusing, more approachable version (and also easier to implement) and to "defer" PEP 501 to "see what happens". Since then, the python internal have also changed, allowing t-strings to be even easier to implement (See PEP 701). We have seen what happens, and now its introduced. f-strings and t-strings are not competing systems. They are different. Similar to ES6 templates and namedTaggedTemplates, they are used for different things while API feels similar intentionally.
f-strings are not inferior to t-strings, they are better for most use cases of string templating where what you really want, is just a string.
> they are better for most use cases of string templating where what you really want, is just a string.
I think use cases where you want to unconditionally bash a string together are rare. I'd bet that in > 80% of cases the "just a string" really is just a terrible representation for what really is either some tree (html, sql, python, ...) structure or at least requires lazy processing (logging, where you only want to pay for the expensive string formatting and generation if you run at the log level or higher that the relevant logging line is meant to operate).
If the "just a string" is html, sql, python, etc., the programmer is making a mistake as string interpolation shouldn't be used for those things in the first place, and I really hope < 80% cases of "just a string" are among those.
"just a string" where the string really is just a string is really, really common though. Python is the go-to language for a lot of people (including me) if they just want to bash together a one-time-use script that will never see input from other people, and f-strings are incredibly useful in such cases for generating filenames, debugging messages, etc.
I'm not familiar with ES6 template strings, but why are they better than f-strings? F-strings just work, and work well, in my experience so I'm wondering what I'm missing out on. Especially since the language I use the most is c++... So I guess I don't expect much out of string manipulation lol.
ES2015 template strings from the beginning supported "tagged template literals" where the tag is a function that gets the template itself and the objects passed to the "holes" in the template as separate arguments. From there that function can do things like turn the holes themselves into something like SQL Parameter syntax and wrap the things that go in those holes in properly escaped SQL Parameters.
`some template {someVar}` was f-strings and someFunction`some template {someVar}` was more like what these t-strings provide to Python. t-strings return an object (called Template) with the template and the things that go into the "holes", versus tagged templates are a function calling pattern, but t-strings are still basically the other, richer half of ES2015+ template strings.
The problem with f-strings is that they make an extremely limited use case convenient (bashing unstructured text) and thus people people invariably use them for the less limited use case for which no such covenient mechanism exists. Constructing ASTs (including html and SQL). Or logging (where you want to avoid unconditionally computing some expensive string represenation).
I do this myself. I basically always use the subtl wrong log.warning(f"Unexpected {response=} encountered") and not the correct, and depending on the loglevel cheaper log.warning("Unexpected respone=%s encountered", repsonse). The extra visual noise is typically not worth the extra correctness and performance (I'd obviously not do this in some publically exposed service receiving untrusted inputs).
I'd argue these use cases are in fact more prevalent then the bashing unstructured text use case.
Encouraging people to write injection vulnerabilities or performance and correcness bugs isn't great language design.
Dylan is simply a historical curio, so there are no situations in which anyone should use it apart to study programming language history and to take inspiration from roads not taken. It's basically Common Lisp, with Algol-like syntax, less historical baggage (everything is a class, no weird stuff like prog and so and so forth) and more emphasis on efficient implementation. Unfortunately, it didn't catch on, but it's IMO a nicer language than python (which modelled inheritance rules on Dylan), Java, Javascript or C++.
Here are some interesting things about it:
1. It has an simple but nice trick for avoiding ugly_underscores: a-b is a single symbol, a - b is subtraction.
2. IIRC it was the first non-sexp language with a sophisticated macro system.
3. Like Common Lisp it has multi-methods and resumable exceptions (but unlikely Common Lisp all exceptions are resumable). If you want to play around with either multi methods and resumable exceptions, Common Lisp or Dylan are probably your best bets and Dylan has the advantage of being probably simpler to pick up.
Great point – I should definitely have mentioned Julia as your best bet for playing around with multi-methods. I think it's basically the only language with any eco-system to speak of that has them. Julia also happens to be the only extant language I'm aware of that has a well designed shell interpolation syntax. For resumable exceptions, however, playing around with Dylan or CL remains your best bet, as far as I'm aware of (and Common Lisp at least also integrates them into the interactive development experience).
When you are prepared to die in a plane crash because of your decrepitude, how much risk to others is entailed in a case like this? If the plausible answer is “not that much” I am with you. But nonagenarian self-actualization at the cost of other people’s lives and limbs is a different story.
Personally, I think the butterfly keyboard is great. Assuming, of course, that you got one that does not suffer mechanical reliability issues. This opinion is hardly universal but seems to be shared by quite a few good typists. I'm typing this on a fancy mechanical keyboard, because I care quite a bit about keyboard quality (and consequently hate most laptop keyboards). So it's not that I just don't know better.
> I thought (and could be wrong) that all of these concerns are based on a very low probability of a very bad outcome.
Among knowledgeable people who have concerns in the first place, I'd say giving the probability of a very bad outcome of cumulative advances as "very low" is a fringe position. It seems to vary more between "significant" and "close to unity".
There are some knowledgeable people like Yann LeCun who have no concerns whatsoever but they seem singularly bad at communicating why this would be a rational position to take.
Given how dismissive LeCun is of the capabilities of SotA models, I think he thinks the state of the art is very far from human, and will never be human-like.
Myself, I think I count as a massive optimist, as my P(doom) is only about 15% — basically the same as Russian Roulette — half of which is humans using AI to do bad things directly.
What is bewildering is that you expect that the world has turn around in the blink of an eye to humor the Japanese, who are now suddenly having second thoughts after telling everyone else to use Firstname Lastname for Japanese names in an international context for most of the last 150 years or so (as the article correctly notes).
Given the amount of work and confusion entailed this is a completely unreasonable expectation.
