As an example, swiss cantons are considerably more independent from the Swiss Confederacy (i.e. what most people know and call 'Switserland' the entity) than the states of the USA are.

As an example of how far that goes: Switzerland essentially does not have a capital. The cantons usually do, though. Bern is the seat of the Federal Assembly and is usually considered the capital, more because social norms and systems are based on the notion that all countries must have one.

Swiss cantons can work together and often do, but evidently, not on this.

Running AI inference increases the power draw, and requires certain hardware.

Mining bitcoin increases the power draw, and requires certain hardware.

OP's point thus stands: Bad players will find places to get far cheaper power than the intended audience, and will buy dedicated hardware, at which point the money you can earn to do this will soon drop below the costs for power (for folks like you and me).

Maybe that won't happen, but why won't that happen?

However, jargon words are just jargon words. There really are only two options:

1. Police them ruthlessly. Even if the word would only cause confusion in the amateur / casual observer, they must be eliminated anyway. I venture that this means almost all jargon words must be turned into words totally devoid of meaning. Jargon is useful - nobody wants to spend the same 3 paragraphs to convey a complex but very common concept - they invent a word for it. So, are we ready for the 'floobargle' and the 'glorpnitz'?

2. Just let them be, and instead police the idea that words that are jargon imply anything at all. Police the idea that their plain english dictionary definition holds any relevance beyond being a memento for what the jargon word is truly meant to convey.

In other words: The problem lies with those who realise 'chrome' is a jargon term and then kneejerk into '... it is frippery' anyway. That's stupid. Those who do that should be ridiculed.

I think that's the only way partly because that feels right and because I think it would lead to eliminated of jargon (bad endresult) or always ending up with jargon that is just a random word that has no meaning at all and wasn't in any dictionary.

No, it's the only feasible way, because of pragmatic reasons: Changing existing jargon? Hoo boy. That is extremely difficult.

As per [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html):

> the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.

You're not allowed to do that. The email address `foo@bar.com` is identical to `foo@BAR.com`, but not necessarily identical to `FOO@bar.com`. If we're going to talk about 'commonly applied normalisations at most email providers', where do you draw that line? Should `foo+whatever@bar.com` be considered equal to `foo@bar.com`? That souds weird, except - that is exactly how gmail works, a couple of other mail providers have taken up that particular torch, and if your aim is to uniquely identify a 'recipient', you can hardcode that `a@gmail.com` and `a+whatever@gmail.com` definitely, guaranteed, end up at the same mailbox.

In practice, yes, users _expect_ that email addresses are case insensitive. Not just users, even - various intermediate systems apply the same incorrect logic.

This gets to an intriguing aspect of hardcoding types: You lose the flex, mostly. types are still better - the alternative is that you reliably attempt to write the same logic (or at least a call to some logic) to disentangle this mess every time you do anything with a string you happen to know is an email address which is terrible but gives you the option of intentionally not doing that if you don't want to apply the usual logic.

That's no way to program, and thus actual types and the general trend that comes with it (namely: We do this right, we write that once, and there is no flexibility left). Programming is too hard to leave room for exotic cases that programmers aren't going to think about when dealing with this concept. And if you do need to deal with it, it can still be encoded in the type, but that then makes visible things that in untyped systems are invisible (if my email type only has a '.compare(boolean caseSensitive)' style method, and is not itself inherently comparable because of the case sensitivity thing, that makes it _seem_ much more complicated than plain old strings. This is a lie - emails in strings *IS* complicated. They just are. You can't make that go away. But you can hide it, and shoving all data in overly generic data types (numbers and strings) tends to do that.

The number of places in the north american continent that retain their street focused infrastructure is pretty much countable on one hand, and most of that is being terribly managed.

They made money with it. More and more, spending significant amounts on hosters to run their bots more often and on more markets.

It was an interesting presentation even if only for the technical details on how they implemented it all.

It took one whole hour. Somewhere near the end, about 5 seconds was spent on 'anyway I lost it all due to the fall of FTX', and then another 5 minutes on how they want to get back into it and what they're looking at, because an individual can no longer play the arbitrage game today.

I had to ask some fairly blunt questions to disillusion the audience. At the end of all that, and with all that effort, *they lost quite a bit of money in the endeavour*. And they wanted to get back into it.

What. the. heck.

Which makes it more interesting. Apparently reddit was a particularly hefty source for most LLMs; your average reddit conversation is absolutely nothing like this.

Separate observation: That kind of semi-slimey obsequious behaviour annoys me. Significantly so. It raises my hackles; I get the feeling I'm being sold something on the sly. Even if I know the content in between all the sycophancy is objectively decent, my instant emotional response is negative and I have to use my rational self to dismiss that part of the ego.

But I notice plenty of people around me that respond positively to it. Some will even flat out ignore any advice if it is not couched in multiple layers of obsequious deference.

Thus, that raises a question for me: Is it innate? Are all people placed on a presumably bell-curve shaped chart of 'emotional response to such things', with the bell curve quite smeared out?

Because if so, that would explain why some folks have turned into absolute zealots for the AI thing, on both sides of it. If you respond negatively to it, any serious attempt to play with it should leave you feeling like it sucks to high heavens. And if you respond positively to it - the reverse.

Idle musings.

I find the fact that this painting has been hung crooked by 0.00001º: down

I find torture and mass murder: down

Clearly this is a ridiculous state of affairs. There's more gradations available than this.

Possibly coloured by my dutch culture: I think this rewrite is terrible. The original sentence was vastly superior, though I think the first rewrite (newbies to rookies) was an improvement.

The zig team is alarmed, and finds this state of affairs highly noteworthy and would like to communicate this more emotional, gut instincty sense in their words.

There's a reason humans invent colourful language and epithets. They always do, in all languages. Because it's useful!

And this rewrite takes it out. That's not actually a good thing. The fact that evidently the internet is so culturally USA-ised that any slightly colourful language is instantly taken as a personal affront and that in turn completely derails the entire debate into a pointless fight over etiquitte and whether something is 'appropriate' is fucking childish. I wish it wasn't so.

In human communication, the US is somewhat notorious in how flattened its emotional range is of interaction amongst friendly folk. One can bring anthropology into it if one must: Loads of folks from vastly different backgrounds all moving to a vast expanse of land? Given that cultural misunderstanding is extremely likely and the cost of such a misunderstanding is disastrously high, best plaster a massive smile on your face and be as diplomatic as you can be!

Consider as a practical example: Linus Torvalds' many famed communications. "NVidia? Fuck you!" was good. It made clear, in a very, very pithy way, that Linus wasn't just holding a negative opinion about the quality and behaviour of the nvidia gfx driver team at the time, but that this negative opinion was universal across a broad range of concerns and extremely so. It caused a shakeup where one was needed. All in 3 little words.

(Possibly the fact that the internet in general is even more incapable of dealing with colourful language is not necessarily the fault of USification of the internet: The internet is a lot like early US, at least in the sense that the risk of cultural misunderstanding is far higher than in face to face communications on most places on the planet).

Right now essentially none have 'failed' in the sense of 'bankrupt with no recovery' (Chapter 7). They haven't run out of runway yet, and the equity markets are still so eager, even a bad proposition that includes the word 'AI!' is likely to be able to cut some sort of deal for more funds.

But that won't last. Some companies will fail. Probably sufficient failures that the companies that are successful won't be able to meaningfully counteract the bursts of sudden supply of AI related gear.

That's all the comment you are replying to is implying.

I wonder if that's true; I'm not in the US myself so I can't exactly just go have a drink in a place with lots of devs to try to find out.

The reasons are somewhat obvious:

* World economy in general and the US in particular is a rollercoaster, with the current administration being apparently dead set on flip flopping on every decision it makes, and always making extreme decisions. That's not a good time to invest. Hiring juniors is investing.

* AI not necessarily replacing the jobs, but that's not actually relevant: AI has already torpedoed the general notion that 'if you have investor money you gotta spend just hire a bunch of folks; # of employees is the primary yardstick to check company size / success', whether AI works or not. If the boss tells a VP to 'use more AI to get a handle on hiring practices', then they're going to stop hiring juniors because it looks like you're outright refusing a direct order if you hire a bunch. Even if AI 'employees' are useless, you are strongly incentivized not to hire juniors in such an environment. Juniors both lost the job opportunities stemming from companies just hiring folks because they have enough cash to do it and no good idea on where to spend it, and the downside of looking like you aren't on the AI hypetrain, if you hire juniors.

* There's evidently been a rather massive push in particular during the previous administration to get folks from dead end jobs into IT, so there's now an overwhelming amount of junior devs, and many of them didn't naturally get drawn to the profession; they were told it's an easy way to get a steady job.

* Even though there's some downturn/uncertainty, seniors/mediors aren't being fired because companies still remember how expensive and difficult it was to (re)hire dev teams post COVID. But that just makes the market for juniors even worse and makes it harder to hold out hope. When everybody is getting fired, then once the economy is in better shape you stand a good chance. But that's not happening; those mediors and seniors are continuing to get job experience whilst the juniors aren't.

Those 4 combined: Sure, yeah, I can imagine your average junior dev's odds to get hired are at this point well into the single digits. But is that actually true?

The reason there is no linux version of Affinity is thus simple: Because there aren't enough linux users to warrant spending the relatively tiny cost it takes to do that. It won't cost much and it won't significantly change Affinity as a product to have a linux release. They just don't bother; not enough paying users.

And why aren't there enough linux users? Because Affinity, for one, doesn't run on it.

That is the self reinforcing cycle that so far kept Windows around as default choice.

But that cycle can be broken. If not through a sudden burst based on some serious hype, then perhaps simply with slow and steady change.

Trying to dissect why it comes across, I think it's just me kneejerking to the 'pattern' of specifically "I am sorry you feel that way". I think my kneejerk disdain of that turn of phrase is correct, though.

Being blunt here: Because that's a terrible apology! You are sorry that I feel this way? We're barely using the same dictionary here; how I feel about a thing is textbook 'stuff you cannot change or barely even fathom', so what is there to be sorry about? You might as well say "I'm sorry for the fact that 2 + 2 is 4". It's not apologetic in any way. It says sorry without taking even a millimeter of responsibility.

A minimal apology that is slightly less condescending might be "I am sorry how our choices led to you feeling this way" because at least now you're sorry about your choices instead of being sorry about how I feel.

I wouldn't want to be buoyed by false hope either, so taking as axiomatic that the moz team wants to hear how to improve matters but are not willing to completely 180º on their sumobot policies, something like: "I apologise for how we've kinda steamrolled y'all with rolling out sumobot. We were trying to improve the state of translations of our knowledge base articles and might have gone too far. We shouldn't have done it without keeping you out of the loop either. Is it possible to have a video call, apologise in person, and try to work out if there's a way sumobot can be helpful for all japanese language users of firefox in a way that works with your excellent work maintaining the KB so far?"

I get that it's just american corpospeak, "hop on a call". But the number of times something that's perfectly normal in dutch culture (a bit brash, but not at all intended to be rude) gets jumped on by americans as being ridiculously rude... well, trying to write a way to be culturally aware of the recipient has to be a two-way street, right?

I dont think this 'apology' is rude, not at all. But it's not apologetic. If you're peeved off at mozilla for foisting sumobot on you, you've already decided to cut ties, and then team mozilla tries to mend the relationship, this is a very poor attempt. In the context of an attempt to mend the relationship this is condescending. Or at least bad diplomacy.

Because it's so trivially unsolvable, I had a quick look at the posted solution.

We're reading it wrong.

Take the first regex on the top row, one you included in your example:

[^X]*(DN|TE|NI)

You're supposed to fill that in from the bottom to the top.

In other words, the first letter goes immediately to the right of [^c]*[^R]*III.* - that square has to be a 'not X'. The hex immediately below it has to be an E, I, or N.

Specifically, the link says two things:

1. That 2 parties want to add *limburgish* to the list, not frisian. That's the bottom-right part of The Netherlands, about as far removed from Friesland as you can get (which is the top part of the Netherlands).

2. That one party wants to add Frisian, but, that is a one-day fly party that will cease to exist in a few hours as they will get 0 seats in this election and will presumably call it a day right after. It was a party founded to support one person and that person has quit due to workstress, and is highly unlikely to return as this _was_ his return. Their opinion used to be relevant as they had 13.3% of the seats this past session (and didn't exist before it). But, it isn't here.

Even there I don't really see it. I agree that it was intended as an easy land grab (and I guess, after Hostomel failed, they should have pulled the plug on the SMO then and there and accept the consequences). But the reasons don't make sense.

In particular, that gas thing:

Gas is on the way out. Clearly so. Even during the cuban missile crisis, with everything that was going on, the flow through the pipelines of russian gas to west germany never stopped. It wasn't even considered.

The west totally distrusted russia for good reason. They spent 20 years being a reliable supplier to build up that trust and they finally managed to get it.

And then they toss it out the window like it was nothing even before the 2022 Ukraine invasion.

I think the reason is clear: EU keeps saying it wants to wean itself off of gas in the next 15 years or so. What possible value does this trust relation have if the EU is no longer interested in buying gas at all?

Then either way Russia's grab is nonsensical:

* Either they understand gas's future (as in, 10 to 30 years from now) is highly limited, and this land grab never made any sense; it won't come online in time and the SMO further incentivises EU to divest. Even if the SMO worked out, there'd be some incentive (it did not work and the EU massively divested. They still buy russian gas but are going at an astronomical pace compared to 1970-2010 reliance on russian gas which increased even in the middle of a cold war and crises!)

* Or they do not believe it'll end, in which case that trust relationship is very important, in which case they screwed up the plan when they used their relationship with the EU as supplier-of-gas a bargaining chip even before the failed SMO.

Either way Russia messed this up badly.

Add to that: The ones essentially paying the bill for this war are the oligarchs. The relative rates of richness between the russian plebs and the oligarchs has swung massively towards the plebians. The government is printing rubles nonstop and the average salary of russians has skyrocketed. That, obviously, 'costs' the oligarchs. Their rubles are worth far, far less. Already today and that won't change anytime soon.

Possibly the oligarchs were assuming the SMO would work out, but, "the russian elites dont care and wanted this" - okay, but that means they are idiots then, as this did not at all work out in their favour.

I think it's a lot simpler: Putin is in control, not the oligarchs. Haven't been for a while. As he ages he wants to leave a mark and thinks his reign was best summarized as "carefully shepherding Russia through its terminal decline, down from the days of the USSR" and didn't like the look of that epitaph... and massively underestimated the difficulty of the SMO.

There's nothing more to it.

Yes, exactly - now you're getting it. Or rather I get the feeling I failed to explain it well.

ArrayList predates generics.

However, ArrayList does have generics.

That's because generics were added to the language in a 'culturally backwards compatible' way: Existing libraries (i.e. libraries that predate the introduction of generics, such as ArrayList) could modify themselves to add support for generics in a way that is backwards compatible for the library: Code written before they added it continues to work and compile fine even against the new release that added generics.

The same principle applied to records would mean that LocalDate could have been updated to turn into a record in a way that is backwards compatible.

And it really works that way.. almost. You really can take an existing class (defined with `class`) and change it into a record (defined with `record`) and all existing code continues to work just fine. However, this means all your properties now neccessarily get an accessor function that is named after the property. And that is a problem for LocalDate specifically: It already has accessors and they are named e.g. `getYear()`. Not `year()`. That means if LocalDate were to be rewritten as a record, one of two very nasty options must be chosen:

* Break backwards compatibility: As part of upgrading code you must change all calls to `.getYear()` into calls to `.year()`. It's a total ecosystem split: Every dependency you use comes in 2 flavours, one with calls to getYear and one with year, and you must use the right ones. This is truly catastrophic.

* Have both methods. There's year() and also getYear() and they do the same thing. Which is the lesser evil by far, but it makes very clear that LocalDate predates `record`. Contrast to ArrayList: It is not all that obvious that ArrayList predates generics. It does, but if you were to design ArrayList from scratch after generics are introduced you'd probably make the same code. Maybe the signature of `remove` would have been `remove(T)` instead of the current `remove(Object)`.

Instead, obviously then, the best choice is to not make it a record. And that's my point: The best possible (possibly here perfection is the enemy of good, but, I'd have done it differently) way to deploy records would have included some way for localdate to turn into a record without the above dilemma.

Perhaps simply a way to explicitly write your accessors with some marker to indicate 'dont generate the default `year()` - THIS is the accessor for it'.

Had that feature been part of record, then LocalDate could have turned into one in a way that you can't really tell.

Those are from java 1.0 and thus don't appear to be relevant to the part of the discussion I think this part of the thread is about (namely: "Why doesn't java crib well designed features from other languages?").

> Java went with checked exceptions and nowadays they are almost universally ignored by developers.

They aren't.

Note that other languages invented for example 'Either' which is a different take on the same principle, namely: Explicit mention of all somewhat expectable alternative exit conditions + enforcing callers to deal with them, though also offering a relatively easy way to just throw that responsibility up the call chain.

The general tenet (lets lift plausible alternate exit conditions into the type system) is being done left and right.

The true explanation, at least the way OpenJDK says it, is that designing language features is more complex than a casual glancer can fathom, and there's 30 years of "Java is in the top 5 most used languages on the planet, probably #1 especially if focussing on stuff that was meant to be supported for a long time" to think about.

From personal experience, essentially every single last "Just do X to add (some lang feature) to java; languages A and B do it and it works great!" would have been bad for java. Usually because it would cause a 'cultural split' - where you can tell some highly used library in the ecosystem was clearly designed before the feature's introduction.

Even if you introduce a new feature in a way that doesn't break existing code, it's still going to cause maintainability headaches if you've cornered the pillars of the ecosystem into total rewrites if they want to remain up to date with the language. Because they will (or somebody will write an alternative that will) and you've _still_ 'python 2 v python 3'd the language and split the baby in the half.

For what its worth, I think the OpenJDK team doesn't take this seriously enough, and a number of recently introduced features have been deployed too hastily without thinking this through. For example, `LocalDate`, which has 'this should be a record' written all over it, is not a record. Or how the securitymanager is being ditched without replacements for what it is most commonly used for here in the 2020s. (To be clear: Ditching it is a good idea, but having no in-process replacement for "let me stop attempts to access files and shut down the JVM, not for security purposes but simply for 'plan B' style fallback purposes" - that's a bit regrettable).

I'm nitpicking on those points because on the whole OpenJDK is doing a far better job than most languages on trying to keep its ecosystem and sizable existing codebase on board _without_ resorting to the crutch of: "Well, users of this language, get to work refactoring everything or embrace obsoletion".

For example, java is somewhat unique in having lambda syntax where the lambda *must* be compile-time interpretable as some sort of 'functional type' (a functional type being any interface that defines precisely 1 unimplemented method). The vast, vast majority of languages out there, including scala which runs on the JVM, instead create a type hierarchy that describe lambdas as functions, and may (in the case of scala for example) compile-time automatically 'box'/'cast' any expression of some functional type to a functional interface type that matches.

Java's approach is, in other words, unique (as far as I know).

There was an alternate proposal available at the time that would have done things more like other languages does them, completely worked out with proof of concept builds readily available (the 'BGGA proposal'). The JVM would autogenerate types such as `java.lang.function.Function2` (representing a function that takes 2 arguments, first of type A second of type B, and returns a value of type R), would then treat e.g. the expression:

`(String a, List b) -> 2.0;`

As a `Function2, Double>`, and would also 'auto-box' this if needed, e.g. if passing that as the sole argument to a function:

``` void foo(MyOperation o) {}

interface MyOperation { Double whatever(String arg1, List arg2); } ```

This proposal was seriously considered but rejected.

The core problem with your comment is this:

Define the terms "polished" and "elegant". It sounds so simple, but language features are trying to dance to quite a few extremely different tunes, and one person's 'elegance' is another person's 'frankensteinian monster'.

The same mostly goes for your terms "beauty" and "charm", but, if I may take a wild stab in the dark and assume that most folks have a very rough meeting of the minds as to whatever might be a "charming" language: I know of no mainstream long-term popular languages that qualify for those terms. And I think that's inherent. You can't be a mainstream language unless your language is extremely stable. When you're not just writing some cool new toy stuff in language X - you're writing production code that lots of euros and eyeballs are involved in, and there's real dependence on that software continuing to run, then you __must__ have stability or it becomes extremely pricey to actually maintain it.

With stability comes the handcuffs: You need to use the 'deprecation' hammer extremely sparingly, essentially never. And that has downstream effects: You can't really test new features either. So far I have not seen a language that truly flourishes on the crutches of some `from future import ...` system. That makes some sense: Either the entire ecosystem adopts the future feature and then breaking _that_ brings the same headaches, or folks don't use these features / only for toy stuff, and you don't get nearly the same amount of experience from its deployment.

Said differently: If java is a frankenstein, so is Javascript, C#, Python, Ruby, Scala, and so on. They have to be.

I'd love to see a language whose core design principles are 100% focussed on preventing specifically that. Some sort of extreme take on versioning of a language itself that we haven't seen before. I don't really know what it looks like, but I can't recall any language that put in the kind of effort I'd want to see here. This is just a tiny sliver of what it'd take:

* The language itself is versioned, and all previous versions continue to be part of the lang spec and continue to be maintained by future compilers. At least for a long time, if not forever.

* ALL sources files MUST start with an indication about which version of the language itself they use.

* The core libraries are also versioned, and separately. Newer versions are written against old language versions, or can be used by source on old language versions.

* The system's compilers and tools are fundamentally operating on a 'project' level granularity. You can't compile individual source files. Or if you can, it's because the spec explains how a temporary nameless project is implied by such an act.

* All versions ship with a migrator tool, which automatically 'updates' sources written for lang ver X to lang ver X+1, automatically applying anything that has a near-zero chance of causing issues, and guiding the programmer to explicitly fixing all deprecated usages of things where an automated update is not available.

* The language inherently supports 'facades'; a way for a library at version Y to expose the API it had at version X (X is older than Y), but using the data structures of Y, thus allowing interop between 2 codebases that both use this library, one at version X and one at version Y.

That language might manage the otherwise impossible job of being 'elegant', 'simple', 'mainstream', 'suitable for serious projects', and 'actually good'.