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
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
}
Any programmer who understands generics can easily understand that signature.
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.
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.