51–60 of 88 posts
Could someone give a brief comparison between Clojure and Nim? Let's suppose that we implement Clojure in Nim is this a crazy idea?, What about implementing Shen in Nim?. Many people complain because sbcl is not easy to use with C++ libraries, could an implementation in Nim amilliorate those problems?. Many more questions arise but those mentioned are enough.
Earlier quoted context omitted.
Honestly, I thing a dozen Nim users should band together and register at Wikipedia to turn the vote the next time someone tries to delete the article. If the deletionists come with formalistic arguments, just synthesize a few articles on sites that fulfill their WP:RELIABLE criteria. There's got to be somebody working for a commercial (read: non-blog) website who doesn't like deletionism and would post a small articl…
Wikipedia is, for some things, severely broken. Your post will be seen by some wikipedians as a violation of some policy or other. (Off the top of my head there's sock puppeting http://en.wikipedia.org/wiki/Wikipedia:Sock_puppetry "Do not ask your friends to create accounts to support you.")
Earlier quoted context omitted.
I guess you could use fewer magic numbers if you want, for example instead of: proc createCRCTable(): array[256, CRC32] = for i in 0..255: You can write: proc createCRCTable(): array[256, CRC32] = for i in result.low .. result.high: Or: proc createCRCTable(): array[256, CRC32] = for i, v in result: # index, value Or define your own indices iterator: iterator indices(x) = for i in x.low .. x.high: yield i proc createC…
It isn't magic numbers as such, rather the smattering of sometimes zeroes and sometimes ones. If it was always zero or one it would be a lot less likely to have off by one errors. Python solves this by always starting from zero, and crucially not including the final number - ie range(0,3) gives 0, 1, 2 (no 3). You can also do negative indexing to count from the end - eg range(0, 3)[-1] gives the last element (2). The…
Earlier quoted context omitted.
As a pythonista one thing that struck me in the code fragments is zeroes and ones appearing everywhere. It looks very easy to have off by one errors. (It is very rare to have off by one errors in Python due to the way counting and ranges work.)
I don't program in Python, but I thought one of the contention points the community had was the syntax of slices and such (starting at one instead of zero, or one sire of the range being inclusive, I can't recall). If that's true, I would imagine that would encourage for some off by one errors. Then again, maybe it's not nearly as contentious as it sounded in a few comments.
What I don't like about Nim is that there is not a repl. In Lisp and Clojure you don't need to compile things. Could someone give a brief comparison between Clojure and Nim? Let's suppose that we implement Clojure in Nim is this a crazy idea?, What about implementing Shen in Nim?. Many people complain because sbcl is not easy to use with C++ libraries, could an implementation in Nim amilliorate those problems?. Many…
$ nim i
>>> for i in 0..10:
... echo "Hello World"[0..i]
...
H
He
Hel
Hell
Hello
Hello
Hello W
Hello Wo
Hello Wor
Hello Worl
Hello World
Edit: It's even buggier than I remembered, best avoid it and use "nim -r c file" instead.
Earlier quoted context omitted.
I don't program in Python, but I thought one of the contention points the community had was the syntax of slices and such (starting at one instead of zero, or one sire of the range being inclusive, I can't recall). If that's true, I would imagine that would encourage for some off by one errors. Then again, maybe it's not nearly as contentious as it sounded in a few comments.
Slices start at 0, not 1. However they are inclusive of both boundary items. This matches how ranges are specified in Nim.
The result is that C++ now just barely outperforms Nim: 1074ms for C++ vs 1165ms for Nim.
Earlier quoted context omitted.
Everything old is new again.
Care to flesh that out a bit?
Obviously, it doesn't matter whether those features are old or new. What matters is whether the language executes them in a compelling way. But almost every single one of those features has been a core aspect of programming languages which have been around since before most of us were born.
Also, the mods have strongly urged me to write shorter comments, and to write comments less frequently. And they've suggested that more than once. I try to oblige, and this is the result. So technically I can't flesh out my comments without going against their advice.
Of that list of nine features, I'm certain six are extremely old:
* Run regular code at compile time
* Extend the language (AST templates and macros);
this can be used to add a form of list comprehensions to the language!
* Add your own optimizations to the compiler!
* Bind (easily) to your favorite C functions and libraries
* Unified Call Syntax, so mystr.len() is equivalent to len(mystr)
* Good performance -- not placing too much emphasis on this,
but it's faster than C++ in his benchmark
Nim is great, and this article is great, except until now no article about nim managed to sell it to me like a simple Golang example including channel and go routine. Could any Nim advocate demonstrate a simple program that: less than 50 loc shows the greatest strength (1 killing selling point is enough)
It would probably be better if you explained what kind of problems you're dealing with in your work: we could then look at Nim features and tell you if there's something that would make your life easier and your work more enjoyable.
This was a helpful writeup. Nim has a lot of really nice features. Are there any problems or things you find lacking?
The idea that thisFunction and this_function are the same might be worse than the problem they're trying to solve. I cannot unfortunately have experience with larg-ish codebases in nim to tell if this would result in an actual problem or not, but the idea that I have to scan between two possible identifiers in the code can be a source of stupid bugs in the same vein as case-insensitive identifiers. On the other hand…