Also not having used Java for decades I’ll not comment on the state of their abstractions, but

IMO at the extreme being unable to shed the past means negatively hindering progress. I think modern Java versions show a budding shift in mentality

both reminds me of similar complaints against C++ (and with a sizeable amount of users wishing for an ABI break), and how weird it is to get both complaints like that and over the fact that so many shops are on ancient versions. They’ve moved slowly, but it doesn’t seem like anything was slow enough for a lot of shops, which indicates they likely could’ve moved faster without changing which versions users would be at today.

This sounds like the antithesis to parse, don’t validate. It is possible to use just maps and strings and get a “stringly typed” program, but there’ a bunch of downsides to it too:

• your typechecker can’t help you if you used the wrong dict[str, Any]; most of us want the typechecker to help us write correct code
• there’s no public/private
• everything you .get from a map is Optional; you need to be constantly checking and handling that rather than being able to have methods that return T, or even direct field access
• you can derive or hand-implement a bunch of operations on (data)classes that you can’t on maps: Comparison, ordering, hashing so you can use the blob of information as a map key, …

Ultimately while Hickey has a good point in the distinction between easy and simple, his ideals don’t seem particularly aligned with the programming world at large: For one thing, Clojure remains pretty small, but even other dynamic programming languages like Javascript and Python have been moving towards typechecking through Typescript and typing in Python.

Doing a json.load into some dict[str, Any] is simple, but actually programming like that isn’t easy. Apparently a lot of programmers find value in doing the extra work to get some stdlib or pydantic dataclasses. Most of us get a confidence boost from using parsed data, and feel uneasy shuffling around stuff that’s just strings and maps.

Yes I’m being sarcastic, but I also think utf-8 is plaintext these days. I really can’t spell my name in US ASCII. Like the other commenter here went into more detail on, it has its history, but isn’t suited for today’s international computer users.

It’s also some surprise internal representation as utf-16; that’s at least still in the realm of Unicode. Would also expect there’s utf-32 still floating around somewhere, but I couldn’t tell you where.

And is mysql still doing that thing with utf8 as a noob trap and utf8_for_real_we_mean_it_this_time_honest or whatever they called it as normal utf8?

Yes, I am joking. We probably could do something like the old iso-646 or whatever it was that swapped letters depending on locale (or equivalent), but it’s not something we want to return to.

It’s also not something we’re entirely free of: Even though it’s mostly gone, apparently Bulgarian locales do something interesting with Cyrillic characters. cf https://tonsky.me/blog/unicode/

To unjerk, as it were, it was a thing. So on old systems they’d do stuff like represent æøå with the same code points as {|}. Curly brace languages must have looked pretty weird back then:)

Jess. Ai’m still lukking får the ekvivalent åv /r/JuropijenSpelling her ån lemmi. Fæntæstikk søbreddit vitsj æbsolutli nids lemmi representeysjen.

No, I’m pretty sure the weird o with the leg is in basic ASCII. It’s also missing Latin characters like Æ. It’s a very weird standard.

Q. P is a common character across languages. But Q is mostly unused, at least outside the romance languages who appear to spell K that way. But that can be solved by letting the characters have the same code point, and rendering it as K in most regions, and Q in France. I can’t imagine any problems arising from that. :)

I’m not entirely sure here, but you are aware you’re in a humour community, yeah?

Neovim developer got sidetracked configuring their reply plugin

It’s a joke because it includes useless letters nobody needs, like that weird o with the leg, and a rich set of field and record separating characters that are almost completely forgotten, etc, but not normal letters used in everyday language >:(

With ASCII æs the åriginal sin. Can’t even spell my name with that joke of an encoding >:(

Isn’t that sort of just the cost of doing business in C? It’s a sparse language, so it falls to the programmer to cobble together more.

I do also think the concrete example of emails should be taken as a stand-in. Errors like swapping a parameter for an email application is likely not very harmful and detected early given the volume of email that exists. But in other, less fault-tolerant applications it becomes a lot more valuable.

It is pretty funny that C’s type system can be described pretty differently based on the speaker’s experience. The parable of the Blub language comes to mind.

Parsing is a way of “validating early”. You either get a successful parse and the program continues working on known-good data with that knowledge encoded in the type system, or you handle incorrect data as soon as it’s encountered.

I feel I gotta point out it’s a pretty funny example—email comes up so frequently as a thing that you’re recommended to neither parse nor validate, just try to send an email to the address and see if it works. If you need to know that it was received successfully, a link to click is the general method.

But “parse, don’t validate” is still a generally good idea, no matter the example used. :)

Yeah, you generally just want the same auto-stuff done as would be enforced in CI anyway.

… all the other stuff you could fix but wind up just ignoring because your team ignores it will just glare at you until you sneak it in somehow

It’s just a monoid object in a category of endofunctors, no biggie

Afaik they’re hoping to land it on nightly in 2025H1.

Between that, work on the next-generation trait solver and promoting parallel frontend, there’s some stuff to look forward in the compiler this year.