What is this article? There is no author, and it is written as if it were an objective truth when it is clearly subjective.
There is no conclusion, it’s just an introduction paragraph that says “do this, this is good design”, followed by a pro-con analysis, and then the article just ends. Given that it has real drawbacks, you would think it would be more nuanced than “do this, this is good design”.
Furthermore the analysis is not even complete. The only 2 drawbacks mentioned only affecting the developer of the language. And ignoring more obvious drawbacks that would affect the users of the language:
Aesthetics. Annotations are just uglier than modifiers. Due to their special syntax instead of just a naked keyword.
Annotations take up more space. Screen space is valuable, annotations usually are stacked vertically, which takes up a lot of vertical screen space. This is in order to mitigate their use of horizontal screen space by their syntax.
Disorder. Annotations are not ordered, which means they are harder to parse by a human. And if there is a wall of annotations, a human might miss an important one because it is surrounded by others that are just boilerplate.
“Downgrading” modifiers to annotations removes their perceived importance. Modifiers modify the class/function/whatever, annotations add to it. Usually, you can ignore annotations and just look at the modifiers. If modifiers are annotations, you have to read the annotations to filter which ones are important to you and which aren’t. Which is harder to do due to the previous point “Disorder”.
If annotations were objectively better than modifiers, the logical conclusion would be “your language should not have modifiers, do annotations instead” instead of “if your language has both, remove modifiers”.
Namespacing is not objectively better. I don’t want to import “public” in every single file. It’s just useless boilerplate at that point. And some dependency might export their own “public”. Or even worse, a non-annotation (function, class) named “public”. If reserving keywords for modifiers is a concern, you can just prepend the uncommon ones with “__”. Nobody is going to complain that they can’t use the name “__readonly” because it’s reserved.
Variable declarations do have modifiers too (for example “const” in C). Annotations are awful for variable declarations. See the point about screen space. Same for closures or code blocks.
You do not have to agree with every blog post found on the internet.
I think you make a few good arguments, but you are way too angry for me to engage.
Aesthetics. Annotations are just uglier than modifiers. Due to their special syntax instead of just a naked keyword.
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” andmore than 200 keywords.)
Annotations take up more space
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.
Disorder
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.
Downgrading
Let the IDE/editor pick a different color for you “more important” annotations, if you like.
“your language should not have modifiers, do annotations instead” instead of “if your language has both, remove modifiers”
That’s just nitpicking the wording. Ok.
Namespacing … is not objectively better. I don’t want to import “public” in every single file.
Then don’t? Most languages don’t make you import String either.
Namespacing … Or even worse, a non-annotation (function, class) named “public”.
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”.
Variable declarations do have modifiers too (for example “const” in C).
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:
Java
Rust
Python
*Javascript
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 publicstaticintmain() for java. But making them annotations would not fix that, only rearrange the issue vertically.
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.
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.
Many of the most popular languages have both modifiers and annotations:
I have a separate blog post in which I consider when “popularity” or “familiarity” should be considered when it comes to language design.
People genuinely don’t believe this to be an issue.
The closest is publicstaticintmain() for java.
If you look at Java-inspired languages like Scala or Kotlin, neither of them have public (made the default) nor static (replaced by companion objects).
What is this article? There is no author, and it is written as if it were an objective truth when it is clearly subjective.
There is no conclusion, it’s just an introduction paragraph that says “do this, this is good design”, followed by a pro-con analysis, and then the article just ends. Given that it has real drawbacks, you would think it would be more nuanced than “do this, this is good design”.
Furthermore the analysis is not even complete. The only 2 drawbacks mentioned only affecting the developer of the language. And ignoring more obvious drawbacks that would affect the users of the language:
You do not have to agree with every blog post found on the internet.
I think you make a few good arguments, but you are way too angry for me to engage.
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 …
const foo: Foo = ...… with …
@constantValue let foo: Foo = ...… 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).