this post was submitted on 19 Apr 2026
1 points (57.1% liked)
Programming
26579 readers
103 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I did not intend to sound angry. I was trying to do an honest review of this article. Since I did not consider it good at all.
Ok, then here's a short answer to your points:
If the language has annotations already, then you have paid the tax of having "special syntax" in your language in any case.
(Except Swift maybe, which has "attributes" and more than 200 keywords.)
I don't consider this a drawback. In fact, many languages with modifiers have the same rules about modifier placement.
I actually want annotations on their own line, such that all my actual keywords start at the same column.
Many languages with modifiers have the exact same issue, and address the issue the same way I'd address it for annotations:
Define a desired order of annotations and let the compiler/linter/IDE/formatter deal with it.
Let the IDE/editor pick a different color for you "more important" annotations, if you like.
That's just nitpicking the wording. Ok.
Then don't? Most languages don't make you import
Stringeither.Have a separate namespace for for annotations, or treat
@as part of the name.Though it's not something I would spend effort on – sometimes the best answer to "X does not work" is "then don't".
I replaced ...
... with ...
... in my language a short while ago. It's fine.
I'm not looking to argue about the importance of my points. I wouldn't have listed so many in that case.
The point I'm trying to make is that this is a very incomplete article, as it doesn't seem that much thought was put on the downsides.
A good article would've considered every angle. And so would probably conclude (if it had a conclusion) that the premise is incorrect, and the world of language design is more nuanced than "having both modifiers and annotations is bad language design".
And at that point, the article would've probably ended up being: when should annotations be used instead of modifiers?
Many of the most popular languages have both modifiers and annotations:
C doesn't have both because it doesn't even have annotations. Idk about C++, but it either doesn't have annotations (like C) or it should be in the list above
All of those have been heavily criticized from a language design PoV. And I've never seen anyone complain about this. People genuinely don't believe this to be an issue.
The closest is
public static int main()for java. But making them annotations would not fix that, only rearrange the issue vertically.I could mentioned additional points in favor for the same reason you mentioned your points against, but at some point one has to stop and decide whether any minor, additional points made would sway the overall verdict.
I have a separate blog post in which I consider when "popularity" or "familiarity" should be considered when it comes to language design.
If you look at Java-inspired languages like Scala or Kotlin, neither of them have
public(made the default) norstatic(replaced by companion objects).