modeler

I had a Sinclair QL which pioneered the keyboard. It wasn't great - it was far behind the Acorn BBCs and the Commodores) but it was quite usable.

There was significant vertical travel, and there was variation in the push the key gave back - increasing to a point of no return, then a quick downward movement to the thunk of the end of key travel.

I could type moderately fast on it.

I don't think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let's add encapsulation and implementation hiding to this list.

The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore

1. It is difficult to understand: the developer has to open two, three or more different classes to view the whole algorithm
2. It is inefficient: because the algorithm is distributed over many classes and instances, as the algorithm runs, there are a lot of unnecessary calls (eg one method on one instance has to iterate over many instances of its children, and each child has to iterate over its children) and data has to pass through these function calls.

Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it's the function that walks the object structure. The navigation is done using tools like apply or map rather than a loop in a method on the parent instance.

A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.

In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object's private members, or data processing for that object and its immediate children or peers.

I'm going to suggest food items that we still take from nature and eat with minimal preparation:

• Honey
• Fish like salmon, trout, grouper
• Shellfish (eg oysters)

We have evidence of shellfish and fish being eaten for a very long time - at least the middle stone age at 140kya - in middens which are 10s of thousands of years old.

Honey is likely to have been a food source - a treat even - even before humans left Africa (so before 100kya) but sadly this would be invisible in the archeological record

"DI frameworks" are Satan's farts. Classpath-scanning nonsense that turns compile-time errors into runtime errors. Not only is your Ctr still coupled to your Svc, but both are now coupled to Spring.

Let's qualify this: DI frameworks that use configuration files to specify the dependencies are Satan's farts. You can use the DI pattern but do the injection in source code to get full compile-time type checking and all the benefits of a fully packaged JAR or similar binary. The root of the evil is having text files as part of the packaging, and not having the tooling to treat those files as part of the source code at build time.

Surely that is reserved for QA!

Note the caveat:

With PYTHON_GIL=0 set, I spot-checked a few tests and small programs that don't use threads. They all seem to run fine, and very basic threaded programs work, sometimes. Trying to run the full test suite crashes pretty quickly, in test_asyncio

Their arguments included the size of the web page, and the time to display the first content, both of which were significantly better in Nue when compared to Tailwind.

By all means argue on what is important (because what is important for your projects may be significantly different from mine), but there were many points that the author was highlighting, not just the separation of concerns. And for my projects, all these concerns are important.

This is exactly the answer.

I'd just expand on one thing: many systems have multiple apps that need to run at the same time. Each app has its own dependencies, sometimes requiring a specific version of a library.

In this situation, it's very easy for one app to need v1 of MyCleverLibrary (and fails with v2) and another needs v2 (and fails with v1). And then at the next OS update, the distro updates to v2.5 and breaks everything.

In this situation, before containers, you will be stuck, or have some difficult workrounds including different LD_LIBRARY_PATH settings that then break at the next update.

Using containers, each app has its own libraries at the correct and tested versions. These subtle interdependencies are eliminated and packages 'just work'.

What have things come to that we are now gendering poor little Bobby Tables?

Exactly. And all the core internet encryption and signing algorithms are fully open source. Eg RSA, AES, DIffie Helman. And these are the algorithms the US (and most other western) governments require when sending data to or from or within there servers.

Which, will also hurt the call center manager, until they hire enough staff to answer the fucking phones in less than 30 minutes.

Have you seen his, ahem, retruth of the video 'and God created Trump' video? He's literally comparing himself to Jesus. And his followers went wild!