[–] [S] 0 points 6 months ago* (last edited 6 months ago) (1 child)

I spent the necessary effort to experiment/work with the various approaches to form an opinion, and your main counter argument is largely ... being sarcastic, trying the hardest to misunderstand things to ridicule them and being generally offended?

Let's end this here, your comments are a poor use of my time.

  • source
  • parent
  • context
  • [–] [S] 0 points 6 months ago* (last edited 6 months ago)

    Ok, then here's a short answer to your points:

    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" and more 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 replaced ...

    const foo: Foo = ...
    

    ... with ...

    @constantValue
    let foo: Foo = ...
    

    ... in my language a short while ago. It's fine.

  • source
  • parent
  • context
  • [–] [S] -1 points 6 months ago* (last edited 6 months ago) (3 children)

    I believe that if you start from an annotation-only stance, then you will look at the language, its defaults and possible extensions differently, because annotations are "visually" more expensive than slapping yet-another keyword on something.

    I. e.:

    • "no visibility modifier" should probably mean "public"
    • defining the external API should move to the module-level altogether
    • we should probably use var instead of let mut
    • #[cfg(target_os = "windows")] is just bad design overall
      instead put different targets into different folders: much easier, works better
    • async should not exist at all
      (though not related to annotations vs. modifiers, but because the whole idea is a language design dead-end)


    So the code from your example would literally be ...

    fun some_func: Unit = {
        var my_var = 3u2
        // ...
    

    ... in my design.

    Rust's syntax with #[...] is not that great in this regard, as it triples the amount of symbol involved for simple annotations compared to something using @....

  • source
  • parent
  • context
  • [–] 1 point 6 months ago (2 children)

    Then put the tabs on the right? ;-)

    The core thing that makes horizontal tabs not very useful to me is that having the top of the vertical tabs area used for bookmarks is superior to anything that can be done with horizontal tabs.

  • source
  • parent
  • context
  • view more: ‹ prev next ›