7 ms·

As a C programmer, declarations in Go appeared "backwards" to me when I first saw them. IMO the Go syntax is a vast improvement as it's much simpler and avoids

by LysPJ 2y ago

As a C programmer, declarations in Go appeared "backwards" to me when I first saw them. IMO the Go syntax is a vast improvement as it's much simpler and avoids the clockwise/spiral issue: https://appliedgo.com/blog/go-declaration-syntax https://appliedgo.com/blog/go-declaration-syntax

unrealhoang 2y ago
hence why every recent programming languages are type after name (go included).
- 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...
- atiedebee 2y ago
  I like the way Dlang does it. It keeps the types on the left like C, but are actually readable.
- 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.
rollcat 2y ago
It's worth to remember that C "happened" to stick around because of UNIX, but it's been just another iteration of what started as BCPL; with Go coming from the same people who made Plan 9 (the spiritual successor to Research UNIX) and Alef/Limbo. These guys are equally interested in pushing both PL/OS research and practice. (I also have no doubt that just like Go fixed C's type declarations, in another 20-30 years, Go's successor will finally fix error handling.)

by LysPJ 2y ago

unrealhoang 2y ago

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

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...
atiedebee 2y ago
I like the way Dlang does it. It keeps the types on the left like C, but are actually readable.
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.

rollcat 2y ago

It's worth to remember that C "happened" to stick around because of UNIX, but it's been just another iteration of what started as BCPL; with Go coming from the same people who made Plan 9 (the spiritual successor to Research UNIX) and Alef/Limbo. These guys are equally interested in pushing both PL/OS research and practice. (I also have no doubt that just like Go fixed C's type declarations, in another 20-30 years, Go's successor will finally fix error handling.)