theemptiness

Small semantics nit: it is not overengineered, it is engineered. You wanted more throughput, the collection of coreutils tools was not designed for throughput but flexibility.

It is not difficult to construct scenarios where throughput matters but that IMHO that does not determine engineering vs overengineering. What matters is whether there are requirements that need to be met. Debating the requirements is possible but doesn't take away from whether a solution obtained with reasonable effort meets the spec. Overengineering is about unreasonable effort, which could lead to overshoot the requirements, not about unreasonable requirements.

At some points, a company (any company) has to assume a legal system. When the legal system does not work well - be it, because the laws require censorship, or be it because not everyone can effectively fight for their rights in the courts - this will lead to problems and injustice.

It seems, Turkey is not the only place where it's tough to get copyright claims sorted out in court, but the claim is that the (assumed) legal means are leveraged for going after political opponents.

The EU will have to understand that freedom of speech and the legal framework of copyright claims can be at odds and can be abused in this way. This isn't going to be easy, but leaving it to private companies to come up with something will likely not produce the desired outcome as they will all eventually go the path of least resistance and profitability (it's in general not a private company's job to defend values and reform the legal situation).

As long as its GDPR compliant...

Seriously though, "vaccination is not mandatory but we keep a registry and we share it with partners, and it will have awesome data protection" sounds problematic - even if it were true that data protection is awesome, and even if there was a legal basis - what is shared, what is the data used for? Who is going to be considered a legitimate "partner"?

I doubt politicians' capacity - worldwide - to ask the right questions and find good agreements.

I was fortunate enough to encounter this book in a first-year programming course (Informatik, RWTH Aachen). The years before, they had used Modula-3 and in the years afterwards they switched to Java.

While it certainly changed my life - first encounter with functional programming - and I will always appreciate it, it is now 23 years later and I think it is time to acknowledge some shortcomings.

The thing that comes to my mind first is the lack of any discussion pertaining to coding against interfaces, with components (and their interfaces) evolving over time.

Data abstraction gets discussed very early on, but the evolution of interfaces, its twin sister topic, does not get much air time. This is a pity since the goal of data abstraction (avoiding making assumptions on data representation) is pretty much the same, being able to change things later when the need arises.

I'll suggest Goleman's Emotional Intelligence (for empathy) and Pirsig's Art of Motorcycle Maintenance (for quality and values).