3 ms·

I always thought Nim would be a better systems language to invest time in, but when looking at the code-snippets side-by-side, the Nim code gets really confusin

I always thought Nim would be a better systems language to invest time in, but when looking at the code-snippets side-by-side, the Nim code gets really confusing whereas the Go code has nicer 'flow' and is more readable (ironic, considering that Nim claims to be Pythonic). I'm definitely not going to bash Nim against Go, but to me, code like this: proc det[M,N](a: Matrix[M,N]): float = let n = toSeq 0..a.high is unreadable. There's about as much (if not more) types of brackets in the Nim code compared to the Go code and I am moving towards an opinion that Nim is very unlike Python in readability (it may take things like indentation, no ";" and no " { } ", but Nim code is definitely not like Python in many other ways). Also, apart from the brackets, it has things like: "(a: Matrix[M,N]): float = " which would not be clear to an average programmer unless he/she actually went out to "learn" the ways of Nim (whereas Python code is very readable, even if you just know basic programming). Maybe this is due to the way the writer of each snippet writes their code, but as far as readability goes, Go wins on this one.

tuan5 12y ago
Obviously NIM author was trying to compare lines of code is shorter than Go. The readability issue is really scared me off NIM.
jeremyjh 12y ago
Any programmer who understands generics can easily understand that signature.
jaws- 12y ago
http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic Nim: proc det[M,N](a: Matrix[M,N]): float = let n = toSeq 0..a.high for sigma, sign in n.permutations: var x = sign.float for i in n: x *= a[i][sigma[i]] result += x Go: func determinant(m [][]float64) (d float64) { p := make([]int, len(m)) for i := range p { p[i] = i } it := permute.Iter(p) for s := it(); s != 0; s = it() { pr := 1. for i, σ := range p { pr *= m[i][σ] } d += float64(s) * pr } return } I don't know anything about Go or Nim, but the Nim version looks infinitely more readable to me.
15155 12y ago
These aren't exactly fair comparisons. That's a (simple, standard) generic implementation, Go's is limited to a single type. Is there anything else beyond the generic type signature that makes this less readable to you? Also, if you like, you could change that first sequence initialization to: (0..a.high).toSeq to keep it consistent with other 'method' calls.

tuan5 12y ago

Obviously NIM author was trying to compare lines of code is shorter than Go. The readability issue is really scared me off NIM.

jeremyjh 12y ago

Any programmer who understands generics can easily understand that signature.

jaws- 12y ago

http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic http://rosetta.alhur.es/compare/nim/go/#Matrix_arithmetic Nim: proc det[M,N](a: Matrix[M,N]): float = let n = toSeq 0..a.high for sigma, sign in n.permutations: var x = sign.float for i in n: x *= a[i][sigma[i]] result += x Go: func determinant(m [][]float64) (d float64) { p := make([]int, len(m)) for i := range p { p[i] = i } it := permute.Iter(p) for s := it(); s != 0; s = it() { pr := 1. for i, σ := range p { pr *= m[i][σ] } d += float64(s) * pr } return } I don't know anything about Go or Nim, but the Nim version looks infinitely more readable to me.

15155 12y ago

These aren't exactly fair comparisons. That's a (simple, standard) generic implementation, Go's is limited to a single type. Is there anything else beyond the generic type signature that makes this less readable to you? Also, if you like, you could change that first sequence initialization to: (0..a.high).toSeq to keep it consistent with other 'method' calls.