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.
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.
Author here. Yes, the search bar is nice already, and the performance is good enough for most use cases. Fun fact, javadoc's search is O(n), Docland uses binary search so it's O(log2n). That's why the search bar in the official java.base documentation is noticeably laggy.
The real benefit of customizing search is custom ranking and filtering logic. Docland sorts the search results by relevance (matching prefix length and casing) and dedupes overloads. In my (possibly biased) opinion it's easier to use.
> Author here. Yes, the search bar is nice already, and the performance is good enough for most use cases.
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.
I don't see a search bar, and as long as they might be looking at this thread, something strange is going on, everything is sized absurdly small, as if its rendering my HiDPI* display at 1x
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;
};
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
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.
Don't know the song but that is the ingame music for that specific map, and gets triggered each time certain enemy buildings are destroyed. Different music for each type of building
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.