davidalayachew

Thanks, you are right. Wish I could edit it.

Isn't the entire point of "reinventing the wheel" to address this exact problem?

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.

But then it is no longer an apples to apples comparison. This is Spotify. Spotify is the embodiment of the top radio stations idea.

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

Is it fine? How would we determine that? What's the metric?

I strongly disagree.

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.

> Instead of relying on Javadoc, the built-in doc generator, I created the engine from scratch to give the documentations a modern look, build fast search indexes, and enable link resolution to other packages.

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

It absolutely does. Here is a (modified) snippet of my Java code from yesterday.

    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;
               
       };

It's ABSOLUTELY by design.

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

Very helpful, ty vm.

Complete distraction of a question -- for that video clip, what is the song playing at the time stamp you selected? Is that in-game music? I figure not.

Excellent. I love Checked Exceptions, and this just made them that more useful. Can't wait for it to land.

That's fair. Though, my point stands. Once that number starts to grow, that's when inheritance starts to shine. Again, only in Java as is.

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.