5 ms·

hence why every recent programming languages are type after name (go included).

gf000 2y ago
I think a proper type system that doesn't special-cases arrays are better, e.g. Array<String>. Pointers may also be part of this uniform structure, e.g. Array<Ref<String>>, and there is zero question on how to parse it even if you are not familiar.
- unrealhoang 2y ago
  that's the beauty of type after name, it's all left to right, even in special-cases of array, references, and the most confusing-contributor to cdecl: functions `func(int)[5]*string`: perfectly clear, just read left to right.
  - gf000 2y ago
    What about a Map<int, String>? You can't really encode a tree structure with only linear semantics (without at least something like s-expressions).
    - unrealhoang 2y ago
      And type declarations are s-exprs. The advantage of type after name is that it keeps the traversing order consistently pre-order (node, left, right), instead of either: - the notoriously ridiculous spiral cdecl: reading stuff right (output), node (func name) and left (input) - create a new name to describe the function in pre-order: Func<Input, Output>
      - gf000 2y ago
        But you can't know how many parameters do a user-defined "node" have. I don't see how it can work for generic data structures without a specific syntax for "the children of this node". Go also uses [] for generics, doesn't it? At that point I find a uniform system (without special-casing arrays and pointers - they are also just types) would be simpler.
atiedebee 2y ago
I like the way Dlang does it. It keeps the types on the left like C, but are actually readable.
tpoacher 2y ago
even better, they should have it above or below! or, declare the type separately, like in fortran or haskell (or in fact, pre-C99 c)
- unrealhoang 2y ago
  declare the type separately didn't solve the of hard-to-read cdecl problem.
  - tpoacher 2y ago
    true; but at the same time, any sufficiently complex type is begging to be type-aliased into something more legible/sensible in the first place ... and this is also true for "right-typed" systems. I've seen julia types unnecessarily fill a whole terminal for otherwise simple operations before, and I have to say I wasn't too impressed...

I think a proper type system that doesn't special-cases arrays are better, e.g. Array<String>. Pointers may also be part of this uniform structure, e.g. Array<Ref<String>>, and there is zero question on how to parse it even if you are not familiar.

unrealhoang 2y ago
that's the beauty of type after name, it's all left to right, even in special-cases of array, references, and the most confusing-contributor to cdecl: functions `func(int)[5]*string`: perfectly clear, just read left to right.
- gf000 2y ago
  What about a Map<int, String>? You can't really encode a tree structure with only linear semantics (without at least something like s-expressions).
  - unrealhoang 2y ago
    And type declarations are s-exprs. The advantage of type after name is that it keeps the traversing order consistently pre-order (node, left, right), instead of either: - the notoriously ridiculous spiral cdecl: reading stuff right (output), node (func name) and left (input) - create a new name to describe the function in pre-order: Func<Input, Output>
    - gf000 2y ago
      But you can't know how many parameters do a user-defined "node" have. I don't see how it can work for generic data structures without a specific syntax for "the children of this node". Go also uses [] for generics, doesn't it? At that point I find a uniform system (without special-casing arrays and pointers - they are also just types) would be simpler.

atiedebee 2y ago

I like the way Dlang does it. It keeps the types on the left like C, but are actually readable.

tpoacher 2y ago

even better, they should have it above or below! or, declare the type separately, like in fortran or haskell (or in fact, pre-C99 c)

unrealhoang 2y ago
declare the type separately didn't solve the of hard-to-read cdecl problem.
- tpoacher 2y ago
  true; but at the same time, any sufficiently complex type is begging to be type-aliased into something more legible/sensible in the first place ... and this is also true for "right-typed" systems. I've seen julia types unnecessarily fill a whole terminal for otherwise simple operations before, and I have to say I wasn't too impressed...