you are viewing a single comment's thread
view the rest of the comments
[–] 9 points 1 year ago* (3 children)
  1. <> is hard to read for humans

Not really. <> is unusually pointy among the brackets and comparisons / bitshifts are used in different places than generics are so I've never confused them.

  1. <> is hard to parse for compilers

I guess? Does this meaningfully increase compilation times?

  1. It makes the uses of brackets confusing and inconsistent

No. A language that uses () for parameter lists, literals and indexing is much more mentally taxing to parse

  • source
  • hideshow 3 child comments
  • [–] 5 points 1 year ago*

    Also dropping here the list of contrarian views op listed in the next article:

    Language Design: Popular, but Wrong

    1. static members
    2. properties
    3. <> for generics
    4. [] for arrays
    5. Type ident instead of ident: Type
    6. having if-then-else and switch/case and a ternary operator
    7. having both modifiers and annotations
    8. async/await
    9. separate namespaces for methods and fields
    10. method overloading
    11. namespace declarations doubling as imports
    12. special syntax for casting
    13. using cast syntax for things that are not casts
    14. requiring () for methods without parameters
  • source
  • parent
  • [–] [S] 1 point 1 year ago (1 child)

    If you read more than just the headings, you'd find out that your objections have been addressed in the article. ;-)

  • source
  • parent
  • hideshow 1 child comment
  • [–] 4 points 1 year ago*

    I have and they are not addressed, that's why I commented as such. How would I know that one of the reasons you think <> are hard to read is because they are used as comparison and bitshift or that you intend () as indexing syntactic sugar if I hadn't read them? As for the second, I didn't think how different languages managed to parse them matters as long as it doesn't impact compilation times significantly, hence my comment.

  • source
  • parent