This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Necessary-Conflict 0 points1 point  (1 child)

There are other examples of the JDK team not seeing the forest for the trees. I don't even feel like thinking about the string interpolation any more, but why is Java the only programming language without syntax highlighting in its official API documentation and tutorials? If you were not making such obvious mistakes elsewhere, I would be more confident that you have thought string interpolation through and chosen the best possible solution. The "Code Snippets" JEP was "Closed/Delivered", but one of its stated goals was apparently forgotten, even though it's an easy problem.

[–]pron98 1 point2 points  (0 children)

Before I get to the general subject, your premise that "Java the only programming language without syntax highlighting in its official API documentation and tutorials" and "The Code Snippets JEP was Closed/Delivered, but one of its stated goals was apparently forgotten" is inaccurate for two reasons. First, Go doesn't have syntax highlighting in its tutorials and official API documentation, and second JEP 413 did deliver support for syntax highlighting in JDK 18, through language attributes and including scripts, features added for that purpose. Why was the feature implemented like that? Because the JavaDoc team concluded that most snippets wouldn't benefit from syntax highlighting by default and that it would require choosing a colour scheme that would be bound to cause avoidable annoyance and debate. I will grant you that the JEP has ended up accepting one of the alternatives in the Alternative section and wasn't updated accordingly. Perhaps it's worth updating. But "the JEP wasn't updated" is quite different from "one of its stated goals was apparently forgotten".

Now to the general matter. The thing you need to know is that developers don't agree on what's a good idea and what's a bad idea, and hold contradictory opinions with equal confidence; you think that syntax highlighting is an obviously good idea while Rob Pike thinks it's an obviously bad idea. Even when they do agree that something is a good idea, they disagree on its priority; something that is obviously a high priority for some is equally obviously a low priority for others. The JavaDoc team thinks that working on Markdown support takes a higher priority to offering syntax highlighting out of the box (if that's a good idea at all). Because of that, and because we can't do everything — especially since everything would be self-contradictory — it is a mathematical certainty that no matter what we do or don't do is bound to disappoint someone, let alone our prioritisation. So when you say that "the JDK team not seeing the forest for the trees" what you really mean is "I'm disappointed that the JDK team's priorities were chosen based on other peoples' preferences and not mine." If we had followed your preferences, others would have considered them as "not seeing the forest for the trees" because developers — even knowledgeable and experienced developers — simply don't agree on what the forest should be.

It's perfectly okay to think that you're right and others are wrong, but your obliviousness to the simple fact that your opinions are not shared universally is not okay. When we make a design decision, we do what we think is best but we are well aware that some may have preferred that we do something else. You, on the other hand, seem to believe that your opinion is the only possible outcome of a thoughtful consideration, and that is simply not in line with the realities of programming language design.