This is one of the tradeoffs of maintaining backwards compatibility and stewardship -- you are required to keep track of each "cause" of that backwards compatibility. And since the number of "causes" can quickly become enumerable, that's usually what prompts people to reinvent the wheel.

And when I say reinvent the wheel, I am NOT describing what is effectively a software port. I am talking about going back to ground zero, and building the framework from the ground up, considering ONLY the needs of the task at hand. It's the most effective way to prune these needless requirements.

Here is an example.

https://www.youtube.com/watch?v=D-zrayZQj6w

By that metric, Spotify is actually doing better than they did, if memory serves.

Haskell is great in a pure world, but it has an undue amount of friction when in the IO world. It does work in the IO world just fine, but languages like Java handle the actual concerns of the IO world better than Haskell. And for that reason, I say that no, Haskell is not the one true way to write correct code.

It definitely is the One True Way to write happy path code though.

Agreed. If you do have performance improvements in mind, I would recommend you bring them up to the Javadoc jdk team. They would definitely take a look if you can point out a faster solution.

https://openjdk.org/projects/javadoc-next/

> That's why the search bar in the official java.base documentation is noticeably laggy.

On my $400 laptop from 2020, I have a response time of <= 0.25 seconds. Are you seeing something different?

Javadoc already gives you an extremely fast search index and search bar. Granted, it's only in the newest versions of Java.

    final boolean hasUncollectedSecret =
       switch (each)
       {
               
          case Wall()    -> false;
          case Goal()    -> false;
          case Player p  -> false;
          case BasicCell(Underneath(_, var collectible), _)
             ->
                switch (collectible)
                {
                        
                   case NONE, KEY -> false;
                   case SECRET -> true;
                        
                };
          case Lock()    -> false;
               
       };

On the Java Mailing Lists, the creators/stewards of Java are constantly fighting back so many feature requests BECAUSE those features would threaten backwards compatibility. And that mailing list has been going on for a long time now. You can see feature requests (and their subsequent rejections) going as far back as the late 90's lol

And yes, excellent wording with the idea of "Should not even know about the concept". I think that is another good place where inheritance shines.

https://github.com/davidalayachew/ReverseTheListOfIntegers

https://github.com/davidalayachew/ReverseTheListOfIntegers

Definitely one of the better ones though, very impressive. AI really is great at making some very impressive things. But since AI doesn't "get it", a lot of what it produces just feels off or misses the point.

Imagine that I have a class that has 15 methods -- 14 are a perfect fit as is, but 1 of them needs to be completely overwritten.

If I were to do inheritance, I would do `extends` on the class, and then `@Override` the offending method. Problem solved.

If I were to do composition, I could use the Delegation Pattern from the Gang of Four, but that would require me to write 14 do-nothing methods just to be able to override the one.

In general, composition has more use than inheritance. However, inheritance has a non-zero number of use cases where it is a better choice than composition.