all 15 comments

sorted by: hot top controversial new old
[–] 1 point 1 year ago (8 children)

It's a bit of a change but certainly the right thing to do.

My only disagreement with the article is the get/set stuff. I still want to keep something like the old container[index] syntax, maybe container.[index] to indicate that it's a form of access. As long as generics go after names, this would not cause ambiguity.

  • source
  • hideshow 8 child comments
  • [–] [S] 1 point 1 year ago (7 children)

    What's a form of access but a function from some index type to some element type?

  • source
  • parent
  • hideshow 7 child comments
  • [–] 1 point 1 year ago (6 children)

    What's a struct, but a tuple with some names?
    What's computation but state and a transition function between states?
    What's computation but a set of functions transformed by simple term rewriting?
    Let people enjoy their syntax sugar.

  • source
  • parent
  • hideshow 6 child comments
  • [–] [S] 1 point 1 year ago (5 children)

    Wasting a perfectly good pair of brackets on some random function call and then suffering for it in many other places sounds more like syntactic salt.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 0 points 1 year ago (4 children)

    What? I agree with function[T] style generics, and would be willing to change the access syntax to something like container.[index], as the dot makes the difference quite clear. Or do you mean the approach to implementing a container or the way the compiler has to transform it into the set operation/mutable access? I didn't think that was such a problem, and I quite like the way it is done in rust, but that approach may be unavailable to many languages.

  • source
  • parent
  • hideshow 4 child comments
  • [–] [S] 1 point 1 year ago (3 children)

    That's still a workaround to try and keep a completely artificial distinction alive.

    Even if I didn't need [] for types, I still wouldn't want "some functions use (), some functions use []" as a language rule.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 1 year ago (2 children)

    Some functions also don't have any parentheses, like field access or infix operators.
    Who wants to write

    sqrt(p.x*p.x+p.y*p.y)
    

    when they could write

    sqrt(p.getX().square().add(p.getY().square()))
    

    or even

    sqrt(add(square(getX(p)), square(getX(p))))
    

    We could follow this line of thinking further and arrive at an ugly haskell-like language without pattern matching (because that is an artificial distinction between data in a record and data that can be derived from a record) or operators and barely more enjoyable to write that lambda calculus.

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 1 point 1 year ago (1 child)

    Some functions also don’t have any parentheses, like field access or infix operators.

    You call things the way they were defined. Problem solved.

    I'm kinda confused, because this is the second time now where your attempt at making a counter argument is actively supporting my point. Is this intentional at your part?

    We could follow this line of thinking further ...

    No we don't. If your point relies on Turing-tarpitting the whole discussion ... then you have no point.

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

    You call things the way they were defined. Problem solved.

    What?

    I’m kinda confused, because this is the second time now where your attempt at making a counter argument is actively supporting my point. Is this intentional at your part?

    We are ultimately arguing about subjective preferences. I favor of certain syntactic sugar because I believe it improves readability while you seem to be arguing for strict consistency above all else.
    So by what metric are we measuring our points?

    No we don’t. If your point relies on Turing-tarpitting the whole discussion … then you have no point.

    I admit, that was hyperbolic, but I don't see what syntax for data manipulation other than functions would be left in your ideal language.

  • source
  • parent
  • [–] 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
  • [–] 1 point 1 year ago
    [–] -1 points 1 year ago

    Stop using types for variables

  • source