4 ms·
> but i do like how nim programs consistently have few lines of code than the same program in really most other languages which seems like a good thing Interes
by bilekas 4y ago
> but i do like how nim programs consistently have few lines of code than the same program in really most other languages which seems like a good thing
Interesting take.. I could share some codeGolf languages that you might like to play with in that case!
That said there are a few fallacies in the comments also that bother me a bit. Specifically the assumption that 'once its closer to C its automatically more performant.'
Wild comments too like : `Nim runs on many more platforms than C#`
Without being specific this claim is just weird..
> beware though that usually the people who wrote the benchmarks might not be experts on Nim
So you need to be an expert to benchmark it.. Red flag.
- jb1991 4y agoYou can write fast or slow code in any language, typically people who understand the language very well are the ones who can write performant code, regardless of language. All those benchmark games out there for dozens of languages are proof of that.
- kitd 4y agoNot an expert, but your comparisons need to be apples-to-apples. An expert-tuned C# impl v a naive Nim impl isn't a good benchmark.
- bilekas 4y agoIf I'm benchmarking (not perf testing) a language with some nuances I'm not too familiar with, I would stick some simple implementations of core workings. If those simple tasks are `supposed` to be done a `special` way, then I'm already not interested. Why should I need to learn semi-workarounds just to achieve the basics.
- WithinReason 4y agoHow many algorithms don't benefit from optimisations you think?
- bilekas 4y agoOf course, but this is not the point of a benchmark test though - Mainly because as above you want that Apples to Apples comparison. I think I might not have explained my position too well.
- shaunsingh0207 4y agoI didn't get why fewer lines of code is better. I don't choose rust because its "shorter", far from it, if anything I choose rust because its very verbose with its syntax, but that syntax conveys a lot of information. Another comment in the above thread mentioned that "c-like performance is easily reachable with c2nim, or inline assembly" well then thats not really the performance of nim is it, thats the performance of assembly ...
- dmitriid 4y ago> I didn't get why fewer lines of code is better. There have been a few studies showing that bugs-per-line-of-code is pretty consistent from language to language. So, if you can reduce the number of lines needed, you reduce the number of bugs. There are also surely diminishing returns
- shaunsingh0207 4y agoI'd bet rust is an outlier in that, a lot of languages require more code to do the same things, as a result of being simpler langs (lua). a lot of langs are very easy to shoot yourself with, more lines means more oppurtinity to shoot yourself. In rust though, that 30 line python script probably takes 45 lines to write now. But those 15 lines aren't wasted or because of longer logic, rather those lines are used to convey type information its not "more lines = more bugs" as it is "most languages don't put more lines to good use"
- planetis 4y agoI would find it easier to believe if 1. there was a sample, 2. you claimed that the extra 15 lines are just {} indentation. Btw here is the same build script in nim https://github.com/planetis-m/raylib-game-template/blob/master/build_android.nims https://github.com/planetis-m/raylib-game-template/blob/mast... and in python https://gist.github.com/planetis-m/a437db724185215910a59c3b31d1cdf4 https://gist.github.com/planetis-m/a437db724185215910a59c3b3... Which is shorter/more readable? Note I could have used f-strings for both, I just don't like how they are rendered in my editor.