Programming

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.

Hmm, I mean I totally understand the overlap in functionality. Especially when you get into the Java Lombok situation where annotations are as structural as the modifiers themselves. But there are clear cases in things like Python and Rust where the modifiers are a clear meta-programming that are mostly outside the scope of the language itself.

Granted, Rust is a weird example where annotations tend to "graduate" to the language itself, like in the form of #[async], but that clear delineation of what's in the language itself and what's defined as post-processing still leaves it more readable than if we heaped a chunk of similar-looking-but-willdy-different-effect-wise tokens on top of our function/type definition. E.g.,

#[cfg(target_os = "windows")]
#[pub] #[async] fn some_func() {
    #[mut] let my_var = 3u2;
    // ...

Vs.

#[cfg(target_os = "windows")]
pub async fn some_func() {
    let mut my_var = 3u2;
    // ...

Like, I do get the similarity in function, but it's almost like why we have capitalization in our natural languages. Making language-defined features "louder" and more ingrained in the language itself makes sense, even if the border is fuzzy.

Edit: even going the other direction, and we do:

pub cfg(target_os = "windows") async fn some_func() {
    let mut my_var = 3u2;
    // ...

That homogenization is still a bit of a bitch to read