Those are some great results, but I still think that Python and Numpy are more readable once you get to use them than the implicit looping Nim suggests. While it may be shocking at first, vector operations and broadcasting usually results (IMHO) in incredibly concise code.
There’s a notion in the programming circles (especially functional?) that conciseness is a good thing. I guess it’s a reaction to some “anti-conciseness” styles in languages like Java and C++, but I think we have went too far in a few places.
“Concision” is a broad term. Concise semantics, concise syntax, concise tokens, and concise programs in terms of character counts are all very different and have different trade offs. The fact that they are lumped together during discussion is a shame.
It’s quite interesting that the non-optimized version of the Nim program takes 3 seconds on my computer. The size difference is also 56K (release) vs 308K (debug) .
Those are some great results, but I still think that Python and Numpy are more readable once you get to use them than the implicit looping Nim suggests. While it may be shocking at first, vector operations and broadcasting usually results (IMHO) in incredibly concise code.
Also known as APL.
There’s a notion in the programming circles (especially functional?) that conciseness is a good thing. I guess it’s a reaction to some “anti-conciseness” styles in languages like Java and C++, but I think we have went too far in a few places.
Brevity usually helps readability, other things being equal, though.
“Concision” is a broad term. Concise semantics, concise syntax, concise tokens, and concise programs in terms of character counts are all very different and have different trade offs. The fact that they are lumped together during discussion is a shame.
It’s quite interesting that the non-optimized version of the Nim program takes 3 seconds on my computer. The size difference is also 56K (release) vs 308K (debug) .