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.

[1] https://en.wikipedia.org/wiki/Heredity

[2] https://en.wikipedia.org/wiki/Refractive_error

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".

[1] https://en.wikipedia.org/wiki/Heritability

[2] https://en.wikipedia.org/wiki/Genetic_variance

[3] https://en.wikipedia.org/wiki/Gene%E2%80%93environment_inter...

[4] https://en.wikipedia.org/wiki/Gene%E2%80%93environment_corre...

[5] https://en.wikipedia.org/wiki/Genome-wide_association_study

[1] https://opencode.ai/docs/config/#precedence-order

[2] https://github.com/anomalyco/opencode/issues/10939

[1] https://www.europarl.europa.eu/legislative-train/

[2] https://www.europarl.europa.eu/legislative-train/theme-a-new...

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.

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?

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.

[1] https://en.wikisource.org/wiki/Consolidated_version_of_the_T...

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.

- 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.

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.

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.

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.

[2] https://kotlinlang.org/docs/scope-functions.html

  sequence { for (x in 0..<10) for (y in 0..<10) yield(x*y) }.toList()

On the other hand, you're not limited to for loops/ifs inside such a generator, but can use fairly arbitrary control flow.

Am I missing something here?

  $ cat fib.kts
  fun fib() = sequence {
    var a = 1; var b = 1
    while (true) {
      yield(a)
      a = b.also { b += a }
    }
  }

  println(fib().take(10).joinToString(" -> "))
  println(fib().first { it >= 50 })
  $ kotlin fib.kts
  1 -> 1 -> 2 -> 3 -> 5 -> 8 -> 13 -> 21 -> 34 -> 55
  55

I didn't assume you were. My note about it being a good paper was just a general "this is worth reading" recommendation.

> "Can handle" is quite the hedge. You "can" walk across the continent too, but at what cost?

It's not a hedge. You claimed that (tracing) GC can handle cycles, while RC was "the opposite", which I read to mean that you believe it cannot.

While we are at it, let's go through the basics of trial deletion.

Trial deletion first looks at possible candidates for objects involved in a cycle (in the original algorithm, those were objects whose RC got decremented without reaching zero). Then, you do a recursive decrement of their children's (and their children's children's, and so forth) reference counts.

Unlike with regular reference counting decrements, you visit children even if the reference count doesn't reach zero. The net result is that reference counts are reduced only along internal paths, but that objects that are still reachable from external paths have reference counts > 0 after that.

Thus, any object with a reference count of zero after this step must be part of an internal cycle and can be deleted. All other objects have their original reference counts restored.

Because trial deletion operates on reference counts differently, it's not something that you can easily implement as a library, which is why you don't see it much except when a language implementation chooses to go with reference counting over a tracing GC.

> You're saying Python uses RC to handle reference cycles, and doesn't need a GC for that? If so please ask them to update the documentation, because right now it specifically says "you can disable the collector if you are sure your program does not create reference cycles". https://docs.python.org/3/library/gc.html

This is a terminology thing. Python uses a variant (generational) trial deletion approach [1]. It's not a traditional tracing GC, and it's also not inaccurate, because GC can mean more than using a traditional tracing GC.

> Nobody said "real time". I just said "hard guarantee".

I was not sure what you meant, so I answered both, as you may have noticed.

[1] https://github.com/python/cpython/blob/796b3fb28057948ea5b98...

Second, what you seem to consider to be fundamental characteristics of tracing GC and RC is not in fact so fundamental.

For starters, RC absolutely can handle cycles (e.g. through trial deletion). Such implementations may be difficult or impossible to implement as pure library solutions, but there is nothing that says it can't be done. The most prominent example of a programming language that uses such an approach is probably Python.

Nor does the claim that tracing GC cannot provide hard performance guarantees in the general case (while RC does) hold up under closer examination. Leaving aside the problem that it's already non-trivial to provide hard real time performance guarantees for malloc()/free() and ignoring the issue of cascading deletions, it doesn't hold under the more relaxed assumptions discussed downthread.

For starters, we have such predictability only for the single-threaded case, not for arbitrary multi-threaded situations. And even in the single-threaded case, there are real use cases where predicting performance becomes functionally intractable. Examples are implementations of binary decision diagrams or certain persistent data structures, where the presence of shared subgraphs of arbitrary size make predicting performance of individual deallocations impractical.

In contrast, in the single-threaded case we can absolutely bound individual operations of a tracing GC by either a constant or (in the case of arbitrarily sized allocations) make them linear in the number of bytes allocated (e.g. Baker's treadmill).

What is true is that in the absence of cycles, (naive) reference counting will free memory at the earliest opportunity, which is not something we can say for tracing GC.

TANSTAAFL, as they say.

[1] https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...

No offense, but this strikes me as a strawman argument. What software design methodology leads to immutable types suddenly being made mutable? Outside of dynamic languages, where is support for immutability not there?

Note that any language with proper information hiding can expressly do immutability (literally going back to the days of Modula-2), plus of course several mainstream languages that have first-class language features to represent immutability for added convenience.

Finally, this is only one example. One underlying problem is that if all reference counts need to be capped at one, you have to either switch to full reference counting or to copy the underlying data.

You can see this play out in the std::collections::HashSet interface. Operations like intersection, union, difference, and symmetric difference return iterators rather than sets. While there are also operators that do return sets, such as bitor, that's implemented as follows.

    fn bitor(self, rhs: &HashSet) -> HashSet {
        self.union(rhs).cloned().collect()
    }
    

> Abstractions understood as „I can change only X without changing Y” (aka GoF OOP patterns or most Clean Code OOP patterns) are overrated anyways. Readability and understandability of code is more important than ability to add something without changing something else. If code is readable and constraints are enforced by the compiler, it is easy and safe to change.

So, you never work with third-party libraries where you do not control the API and have never written libraries to be consumed by other teams/third parties?