And when called out on it reply that the comments are often more interesting than the article which is a) trivially true when you don't read the article and b) probably because bickering in comments is more emotionally satisfying and requires a shorter attention span than reading a rather long article (I'm not immune, seeing as I'm now bickering about the bickering).
Apart from the fact that this was pure self-promotion, it was also spamming the Wikipedias of small language communities with low-effort autotranslated garbage, which I think is rather insulting.
The UK left the EU and is pushing very similar sorts of dangerous nonsense legislation when it comes to the internet, so this is clearly not just a EU thing.
As someone who leans more towards the side of LLM-sceptiscism, I find Sonnet 4 quite useful for generating tests, provided I describe in enough detail how I want the tests to be structured and which cases should be tested. There's a lot of boilerplate code in tests and IMO because of that many developers make the mistake of DRYing out their test code so much that you can barely understand what is being tested anymore. With LLM test generation, I feel that this is no longer necessary.
Isn’t tests supposed to be premises (ensure initial state is correct), compute (run the code), and assertions (verify the result state and output). If your test code is complex, most of it should be moved into harness and helpers functions. Writing more complex code isn’t particularly useful.
There have been so many "advances" in software development in the last decades - powerful type systems, null safety, sane error handling, Erlang-style fault tolerance, property testing, model checking, etc. - and yet people continue to write garbage code in unsafe languages with underpowered IDEs.
I think many in the industry have absolutely no clue what they're doing and are bad at evaluating productivity, often prioritising short term delivery over longterm maintenance.
LLMs can absolutely be useful but I'm very concerned that some people just use them to churn out code instead of thinking more carefully about what and how to build things. I wish we had at least the same amount of discussions about those things I mentioned above as we have about whether Opus, Sonnet, GPT5 or Gemini is the best model.
> I wish we had at least the same amount of discussions about those things I mentioned above as we have about whether Opus, Sonnet, GPT5 or Gemini is the best model.
I mean we do. I think programmers are more interested in long term maintainable software than its users are. Generally that makes sense, a user doesn't really care how much effort it takes to add features or fix bugs, these are things that programmers care about. Moreover the cost of mistakes of most software is so low that most people don't seem interested in paying extra for more reliable software. The few areas of software that require high reliability are the ones regulated or are sold by companies that offer SLAs or other such reliability agreements.
My observation over the years is that maintainability and reliability are much more important to programmers who comment in online forums than they are to users. It usually comes with the pride of work that programmers have but my observation is that this has little market demand.
Users definitely care about things like reliability when they're using actually important software (which probably excludes a lot of startup junk). They may not be able to point to what causes issues, but they obviously do complain when things are buggy as hell.
If you search for "indogermanisch" you're going to get the Wikipedia article canonically named "indogermanische Sprachen" first. The second result I see is the English Wikipedia article called "Indo-European languages" and the rest of the articles also appear to be very scientific.
Maybe the term has some weird connotations in English, but that's certainly not true everywhere and it's also not necessarily true in linguistic discourse because English only became relevant as a scientific language relatively recently (German and French used to be much more common) and there's still to this date a lot of linguistic research being published in languages other than English (e.g. why would somebody who researches the German language publish in English?).
> Maybe the term has some weird connotations in English, but that's certainly not true everywhere and it's also not necessarily true in linguistic discourse because English only became relevant as a scientific language relatively recently (German and French used to be much more common).
This discussion is in English though, not German or French.
In a statically-typed language like Java, every class is a type - though not vice-versa, since things like interfaces and records (in Java) are also types.
Non-OOP statically typed languages are basically just saying "ok that's fine, but there's no need to attach state or behaviour to types".
Historically, the term Indo-Germanic was used first, and it's still used prominently used e.g. in German.
From Wikipedia :
> Thomas Young first used the term Indo-European in 1813, deriving it from the geographical extremes of the language family: from Western Europe to North India.[10][11] A synonym is Indo-Germanic (Idg. or IdG.), specifying the family's southeasternmost and northwesternmost branches. This first appeared in French (indo-germanique) in 1810 in the work of Conrad Malte-Brun; in most languages this term is now dated or less common than Indo-European, although in German indogermanisch remains the standard scientific term.
I have no problem saying that Indo-European is a preferable term nowadays, but to claim that the term "indo-germanic" is ethno-nationalist is just absurd. Using two extreme branches of a family to describe the family is a very common practice in linguistics.
> I have no problem saying that Indo-European is a preferable term nowadays, but to claim that the term "indo-germanic" is ethno-nationalist is just absurd.
It's not absurd because it was used ethno-nationalistically, by both Indians and Germans in the past. I've certainly heard it used in English exactly that way. In English, and especially in linguistics contexts, its nationalist associations are clear.
Furthermore, it's also patently incorrect: there is no higher affinity between the Indic and Germanic branches of Indo-European.
"Indo-European" is a term derived from the geographic span of the language family, not a particular language at either end (there is no "Indian" or "European" language). In contrast, the latter half of Indo-Germanic specifically refers to the Germanic sub-branch, to the exclusion of the many other Indo European sub-branches.
The fabrication of that supposed affinity to the exclusion of the other branches was a specifically nationalist exercise, different only in degree to more egregious things like the appropriation of the swastika (whose name and most prominent use is Indic). We know this because the Indo-European family was uncovered by William Jones when he observed the affinities of Ancient Greek, Latin, and Sanskrit, not the Germanic languages (those connections then quickly followed). So its identity was always broader than Germanic from the moment of its discovery.
Therefore, Indo-Germanic doesn't make sense for the same reason Indo-Hellenic or Indo-Celtic don't make sense.
The oldest sub-branch affinity we can deduce in the Indo-European language family is the centum/satem split, which Indic and Germanic languages are on opposite sides of, and even that split is difficult to track down to single branch point, it could be an independent development in different sub-branches.
If it had been initially called Indo-Celtic or Indo-Romance and those names had stuck, it would be equally fine, but that's not what happened historically.
You're fighting against windmills, there are no perfect names for huge language families, this gets even worse when we look at certain language families in other continents. It's very common to just pick two subbranches (or geographic regions), combine them and call it a day (e.g. Sino-Tibetan).
> If it had been initially called Indo-Celtic or Indo-Romance and those names had stuck, it would be equally fine, but that's not what happened historically.
Yes, and in English, the language of this discussion, Indo-European is the term that is used, not Indo-Germanic.
Maven artifacts are immutable, so the whole resolution is deterministic (even if hard to understand), unless you're using snapshot versions (which are mutable) or you use version ranges (which is rare in the Maven world).
Maven artifacts are not immutable. Some maven repositories may prevent overwriting an already published version, but this is not guaranteed. I've personally seen this cause problems where a misconfigured CI job overwrote already published versions.
npm used to allow you to unpublish (and may be overwrite?) published artifacts, but they removed that feature after a few notable events.
Edit: I was not quite correct. It looks like you can still unpublish, but with specific criteria. However, you cannot ever publish a different package using the same version as an already published package.
> Maven artifacts are immutable, so the whole resolution is deterministic
Nope, Maven will grab anything which happens to have a particular filename from `~/.m2`, or failing that it will accept whatever a HTTP server gives it for a particular URL. It can compare downloaded artifacts against a hash; but that's misleading, since those hashes are provided by the same HTTP server as the artifact! (Useful for detecting a corrupt download; useless for knowing anything about the artifact or its provenance, etc.)
> I think most people in the reproducible build space would consider Maven an external uncontrolled input
In an academic sense, you're probably right.
In practice it turns out that this isn't an issue in 99% of cases. Yes, I have once run into a weird issue where Nexus was corrupted and it took some debugging, so it's not like it can't happen, but assuming you don't do anything weird, the assumption that Maven artifacts are immutable is fairly safe.
I'm not saying that lockfiles aren't technically superior or anything, but the failure modes are so rare that people usually don't bother (even in Gradle where lockfiles are technically supported).
I never understood this. I can delete anything from Nexus and reupload something else in its place. Is this supposed immutability just a convention that's followed?
Yes, you can, if you manually interact with it. Most people don't do that because why would you? You generally use it as a proxy for maven central and similar and to upload your own internal artifacts through maven-publish. I'm not sure if it's the standard setting, but Nexus should typically be configured to prevent you from overwriting non-snapshot versions.
