First of all, yes, labor is taxed much higher in Germany than in the US (PPP adjustment already takes VAT on prices into account, so that doesn't matter in this case). In fact, Germany has one of the highest taxations of labor in the world.
What makes this analysis tricky is disposable vs. discretionary income. The US clearly comes out on top when it comes to disposable income (labour is taxed too much in Germany compared to capital income and wealth).
The picture gets more complicated when you look at discretionary income, which also accounts for regular bills, such as rent, college tuition, out of pocket expenses for health care, childcare, and such. All the taxes you pay in Germany do also pay for something, after all. There is unfortunately very little data for this type of comparison.
> American workers still get higher salaries than elsewhere in the OECD and growth in such industries isn't out competing those same industries in other OECD countries.
I used to think that also, probably because FAANG salaries had skewed my perception, but after looking at the data, this does not seem to be actually true, at least not in general.
For example, Germany has a somewhat higher annual median gross salary for full-time employees than the US (PPP-adjusted, BLS/DESTATIS salary data, OECD PPP values).
Of course, this is the median salary. America absolutely offers higher salaries at the top end (and I mean much higher, often by a factor of 2-3 for highly qualified professionals, such as software engineers and doctors). But that also means correspondingly lower salaries at the low end. And of course, labor is taxed heavily in Germany, so discretionary/disposable income may look different in the end on a case-by-case basis.
It means that this is a cabinet decision, not (yet) legislation. It still has to go through the Bundestag. Given the opposition within the SPD and the idea being very unpopular among voters, it is not yet clear whether this will actually become law.
It is still very worrying and the unfortunate result of a lot of things going wrong at the cabinet level.
I am not sure I'm buying this. The raison d'être for our existing software engineering methods is that humans make mistakes and we needed to contain the effects of these mistakes; and without an appropriate methodology to do that, software defects will just accumulate over time. Worse, once they show up, nobody understands the code well enough to do anything about them, or at least not without considerable time investment.
This does not change with agents doing the coding. Coding agents make mistakes also. Not very often nowadays, but neither do competent human programmers. And without a methodology to keep problems in check your agentic code will also accumulate software defects over time and result in code that becomes less and less maintainable, because you have no mental model of the software.
Antirez is correct in pointing out that slop existed before we started to use LLMs for programming; I've worked with my share of really ugly legacy code myself. But the problems do not magically disappear in the LLM age, no matter how good your model is. They remain, as every model is ultimately a heuristic (albeit a very powerful one), and no heuristic is 100% accurate.
This does not mean that coding agents are useless; used correctly, they can be enormously powerful accelerators for the software development (and validation!) process, because combining your strengths with those of a modern LLM is generally a substantial net gain. But that must still happen as a part of an approach that results in maintainable software with minimal defects.
Personally, I primarily use agents as virtual pair programmers these days, which I find very useful. This is an iterative process with relatively small and contained changes, where "looking at the code" is just part and parcel of following along and building a mental model of the resulting piece of software.
My concern with most of these visual benchmarks, popular as they are, is that they are likely more indicative of knowledge (i.e. how comprehensive the training data is and how well it can be retrieved from the model) than of reasoning ability. I don't see in particular how a model would construct a CoT that mapped somehow to a representation of the cube geometry and its animations in latent space without a large chunk of that being pre-existing information.
I mean, Western providers such as Fireworks AI/Microsoft Foundry (US) or Tensorix (EU) already are offering many of these models on their own hardware with all the typical compliance boxes ticked through a standard API. Either as open weight models or through partnerships with Chinese firms, or both. DeepSeek etc. do not have to do anything here other than making their models available to Western partners (either as open weights or through a licensing agreement).
> For instance, OP's definition H = Var[G] / Var[P] seems to bypass the issues you mentioned:
No, this is exactly the definition I am talking about. The problem is that while theoretically you could work with Var(G)/Var(P) even if Cov(G, E) ≠ 0, studies are not designed to capture that.
In fact, the standard ACE model [1] used in twin studies explicitly assumes among other things that there is no gene-environment correlation. This means that it gets silently added to one or more of the ACE components; not because of any ill intentions, but simply because if you included covariance, the resulting system of equations would be underdetermined and could not be solved [2].
But to make matters worse, gene-environment correlation/interaction itself is disproportionately absorbed by the A and C components rather than E. All this can lead to inflated heritability estimates.
And to clarify, I am not making any pronunciations about how much relevance or magnitude that effect has; for all I know, this could in the end be a minor effect. My point here is that there is a lot of mathematical handwaving going on with very limited testability of the modeling.
[2] If you want to be precise, you need to actually distinguish between gene-environment correlation and interaction and use P = G + E + (G x E), but that makes the system even more underdetermined, because now we have both Cov(G, E) and Var(G x E) to worry about.
> That matches what I assumed it meant, and it seems like OP and the post are arguing that that is some kind of surprising interpretation.
The unintuitive part is that in quantitative genetics, heritability is defined in terms of variance in traits at the population level, not as the passing of traits from parents to offspring (that would be heredity [1]). Of course, I may have misinterpreted what you said in your OP when you cited the wiktionary definition of "[g]enetically transmissible from parent to offspring", and if so, I apologize, but at the time it seemed to me that you were talking about heredity.
> Uhm, no. That is exactly what I (and I think most people) would expect the answer to be.
What the article is talking about is that if you fix Var(E) = 0, then Var(P) = Var(G) in the standard heritability model, i.e. all phenotypic variance is explained entirely by genotypic variance (because in that model, Var(P) = Var(G) + Var(E)).
Fun fact (even if only tangentially unrelated): In Western countries, wearing glasses is a highly heritable trait, because wearing glasses is a strong proxy variable for refractive error [2], such as nearsightedness, which is highly heritable. It is often brought up as another example of how the quantitative genetics definition does not match conventional use of the word.
Heritability has a very specific meaning in quantitative genetics [1], which in many ways is not what your intuition would suggest [2]. It is this usage that the article talks about that.
That said, there are plenty of critiques of this definition of heritability, and not just because it is different from what a layperson would expect it to mean.
For example, the way it is used also usually has a big problem in that the standard formula assumes that Cov(G, E) = 0 (or at least is negligible), whereas in practice that is not actually true [3, 4].
This definition of heritability is also mathematically flawed in that it assumes (without evidence) that P = G + E, or at least can be reasonably approximated this way. Given that human development is the result of a feedback loop involving genetic and environmental factors, one would expect a model closer to something like a Markov chain. Proposed justifications of a simple additive model as an approximation (e.g. via the central limit theorem for highly polygenic traits) have to my knowledge never been tested.
More recent genome-wide association studies [5] have actually shown a considerable gap between heritability estimates from genotype data and heritability estimates from twin studies, known as the "missing heritability problem".
No, the problem is that when logging in, the provider's website can provide an authentication shell command that OpenCode will send to the shell sight unseen, even if it is "rm -rf /home". This "feature" is completely unnecessary for the agent to function as an agent, or even for authentication. It's not about it being the default, it's about it being there at all and being designed that way.
I am more concerned about their, umm, gallant approach to security. Not only that OpenCode is permissive by default in what it is allowed to do, but that it apparently tries to pull its config from the web (provider-based URL) by default [1]. There is also this open GitHub issue [2], which I find quite concerning (worst case, it's an RCE vulnerability).
There is the Parliament's legislative train website [1]. However, it only tracks actual legislative steps, not the intra-Council negotiations, so the proposal's page appears to be have been largely inactive since 2024 [2].
> The shell, perl and python are likely for scripting and not used during runtime.
Some git subcommands are implemented in these. git filter-branch is a shell script, git cvsimport is a Perl script, and git p4 (perforce interop) is a Python script. There are not too many left these days (git add -p/-i also used to call a Perl script), but they exist.
> Of course the member states drafted and agreed to those and that's why pressure should be on governments to stop hand over the keys to Brussels.
What specific example are you thinking of where additional power was handed to Brussels through an amendment of the treaties?
> That's in addition to the constant Commission push for more power...
If you are worried about the executive trying to expand its power (and something that should be kept in check), may I suggest that the US is not actually a great example right now for how to avoid that?
> The EU does not so as time passes the EU's power keeps creeping up.
Actually, the EU has the same concept of enumerated powers (called "competences" in the case of the EU). They are listed in articles 2-6 TFEU [1]. You may argue over whether the EU has too many competences or (in some areas) too little, but it's the same principle. The EU cannot legislate outside areas where power has been expressly conferred to it by the treaties.
This is in fact one point of contention over the "chat control" legislation. It is supposed to be enacted under the "internal market" competence, but similar to the US commerce clause, there is a legal debate over whether that competence is actually sufficient to enable such legislation or whether it is legal cover for encroachment on competences reserved to the member states.
This would of course be up to the ECJ to decide, just as the US Suprement Court would have to decide if any given US federal legislation is covered by the commerce clause.
In addition, there is the Charter of Fundamental Rights, and the ECJ could also strike down EU legislation (as it has done before) if it violates the rights protected by the Charter.
What you are proposing would amount replacing the current bicameral legislature (with the European Parliament as the lower house and the Council of the EU as the upper house) with a unicameral legislature. That would actually make it easier for bad laws to be passed, especially as the supermajority required in the Council is currently the biggest obstacle for this kind of legislation.
I'll also note that nothing here is per se undemocratic. Both the Parliament and the Council are made up of elected members. The members of the Council (as members of the national governments) are indirectly elected, but elected all the same. Direct election is not a requirement for a democracy (see election of the US president or the US Senate prior to the 17th amendment or the Senate of Canada right now).
That does not mean that there isn't plenty of valid criticism of the EU's current structure, but claiming that it is not "actually democratic" falls far short of a meaningful critique.
Aside from the often cited nullability issue, here is an (incomplete) list of important things that Kotlin still does better than Java:
- First class, fully functional closures.
- Non-abstract classes and methods are final by default.
- Named parameters.
- Easy to write iterators via sequence { ... }
- First class support for unsigned types.
The same argument would apply to any non-compacting allocator, because the worst case memory blowup due to external fragmentation is huge. But such cases are extremely rarely observed in practice, so people use e.g. standard malloc()/free() implementations or non-compacting garbage collectors without being concerned about that.
In addition, there are plenty of cases where memory usage is unbounded or excessive, not because of allocator behavior, but because of programming mistakes. In fact, memory can sometimes blow up just because of large user inputs and very few systems are prepared for properly handling OOM conditions that happen legitimately.
Case in point: Both CRuby and Apple's JavaScriptCore have garbage collectors that use conservative stack scanning and are widely used in production systems without the world ending.
That said, you're probably not going to use conservative stack scanning because of collection speed alone. There are other trade-offs between conservative stack scanning and precise stack scanning that weigh more heavily.
I'll add the caveat that I would be very cautious about using a conservative GC on 32-bit systems, but on 64-bit systems this is about as much of a concern as memory fragmentation.
What happens under the hood is that a `sequence {}` call creates an instance of `SequenceScope`, which has `yield()` and `yieldAll()` methods. When executing the block, `this` will reference that particular instance and `yield()` is essentially `this.yield()` and will call the method on the scope instance.
The actual functionality is then provided by the coroutine system, though a lot of the heavy lifting is done by the optimizer to eliminate all or most of the runtime overhead.
As somebody who uses and likes both Kotlin and Python (and quite a few other languages), I'd be cautious with using a subjective term such as "more expressive", too, but I can possibly shed some light on where such feelings come from.
Personally, I see Kotlin as the closest thing to a statically typed Smalltalk that we have among major languages, and that's a major draw.
A key part here is that Kotlin closures are fully-featured equivalents of Smalltalk blocks (up to and including even non-local returns [1]), whereas in many other languages that falls short. Java does not allow mutation of local variables and Python restricts lambdas to normal expressions.
I find code whose behavior can be parameterized by code to be an essential feature of modern-day programming and this should be as frictionless as possible.
This is also a situation where syntax matters, and while it isn't quite as nice as Smalltalk, Kotlin's syntax (esp. with trailing closures) make such code as readable as possible in a brace-style language with minimal additional syntactic noise.
In a similar vein, the functionality of Smalltalk's cascades is offered through scope functions [2], especially `.run {}`.
But ultimately, fully-featured closures (and the fact that they are widely used in the standard library) power a lot of the things that people seem to like about Kotlin.
That does not mean that there aren't downsides. The limitations of running on the JVM are one (e.g. while Kotlin has workarounds for the JVM's type erasure, they're still workarounds), and then Gradle is arguably Kotlin's weakest point (which apparently even JetBrains are seeing, given their investment in Amper).
That said, personally I'd say Kotlin's static typing and performance would be the primary reasons for me to reach for Kotlin over Python, not necessarily expressiveness. Type annotations in Python + mypy etc. just aren't the same experience, and writing performance-sensitive code in Python can be very tricky/hacky when you can't delegate the hot paths to numpy or other existing C/C++/Rust libraries.
Conversely, Python often has a leg up when it comes to fast prototyping and scripting, even with Kotlin Worksheets in IntelliJ IDEA and with kscript.
[1] Which, to be clear, are a nice-to-have thing, not essential, but still impressive that even that was covered, when previously Ruby was the only major language I know of that did it.
What makes this analysis tricky is disposable vs. discretionary income. The US clearly comes out on top when it comes to disposable income (labour is taxed too much in Germany compared to capital income and wealth).
The picture gets more complicated when you look at discretionary income, which also accounts for regular bills, such as rent, college tuition, out of pocket expenses for health care, childcare, and such. All the taxes you pay in Germany do also pay for something, after all. There is unfortunately very little data for this type of comparison.