Re: Nim and Project Euler
Here is my story from a slightly different angle. I really like code-challenges sites. I've used them a lot (and: a lot of them ;)) when I was learning Python, and some of them when I started with Nim, here is the list from the top of my head: * Checkio * Codewars * Hackerrank * Exercism * Empire of code * Advent of Code Probably some more, but I forgot. What I'm sure of is: Project Euler is not on that list. I had a look at it several times, but it never really attracted me. I've read some of the tasks and they felt so boring. So the small number of Nim users of Project Euler is really no surprise to me.
Re: Associating data to types
If you want to set them at the type definition you can use custom annotations: [https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-custom-annotations](https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-custom-annotations)
Re: Nim and Project Euler
I've been solving each of the Project Euler problems with 3 languages (C11, Python, and Haskell) as an exercise. I've done the first five or six. I haven't tried to use Nim in this context but actually it's as suitable as Python.
Re: Nim and Project Euler
> Any ideas how to make it more popular? :-) In the Project Euler community, this is not easy. Members are mostly mathematicians and either they use main languages such as C, C++, Java, Python, or they use languages such as Haskell (6863 users!) or more logically Mathematica or Matlab. For those members which are computer scientists or engineers, they use whatever language they like (and there are a lot of them) and they don’t care a lot about other languages, I guess. Nevertheless, when they have solved a problem, they probably look at other people solutions and this is the reason why I try to publish my solutions with a strong emphasis on the readability, elegance and performance of Nim. And so, I can always imagine I have convinced some programmer to try Nim :-). One good thing to note is that we can solve any problem of Project Euler, provided of course that we find a good algorithm. This has not always been the case as without modules to deal with big numbers ( _bignum_ or _bigint_ ), it would be really difficult. I know how I could have managed to do this, but, probably, I would have rather chosen to use Python. Or I would have built some crude binding to GMP, who knows? Outside of Euler Project, I know that there is much brainstorming to find some way to improve the popularity of Nim. I would like to hope that, as with Python, the qualities of the language will be acknowledged at last, but it could take a while. Python has gained a lot of popularity among scientists, in biology, language analysis, statistics (concurrently with R – 1220 users in Project Euler), etc. But, in the reverse, I personally encountered a lot of resistance in my company to simply use it. So, I think that we cannot expect gain popularity with private companies. They are too conservative, too timid, except for sponsors of course. Nim has probably a place to find as a language for numerical computations. For instance, _arraymancer_ is really impressive. Taking a place as a language for efficient computations (and scientists need performances) would be a great achievement, I think. It would be difficult as Python with _numpy_ , _scipy_ and others is well installed. But it remains slow compared to what can be done with a compiled language as Nim. There are other competitors such as Julia, but I will not bet on their success. After that, Nim must gain popularity in the open source community. When Linux distributions have replaced their Perl scripts by Python scripts, it was terminated: Python has gained its battle to become a main language. Of course, Nim has to find its place. For instance, I think it would be the best language to write photographic software such as _RawTherapee_ or _darktable_ , provided it offers good bindings to the graphical toolkits (GTK for _darktable_ ). And modules such as _arraymancer_ would really shine here.
Re: FOSDEM 2019
One more reminder for you guys, if you haven't bought tickets/hotel then you **really** need to do so now. **The best way for all of us to coordinate will probably be via Telegram** ([join here](https://t.me/nim_lang)). Events to be keep in mind: * Beer event: [https://fosdem.org/2019/beerevent](https://fosdem.org/2019/beerevent)/ * @PMunch's lightning talk: [https://fosdem.org/2019/schedule/event/nim_metaprogramming](https://fosdem.org/2019/schedule/event/nim_metaprogramming)/ I'll most likely be wearing a Nim t-shirt, so if you see that feel free to come and say hi :)
Re: Python Modules & why Python is better
Please keep in mind that many people only read the title and this week's topic is "are we popular now? No? why?!" So "Python Modules & why Python is better" is a suboptimal headline. ;-) (This forum really needs an "edit title" feature...)
Re: "Nim needs better documentation" - share your thoughts
Interesting, I've never seen Doxygen/Javadoc based docs that I enjoyed reading/navigating.
Re: "Nim needs better documentation" - share your thoughts
Hi, it's been a while since I posted here in the community (or done much with Nim), but here at least is my $0.02: I'm not a big fan right now of how inline documentation comments/strings work. 1. This may be more of a personal preference, but I don't like putting the documentation right in the body of the function. It looks like this was influenced from Python. Java, C#, C/C++ doc systems (e.g. Doxygen), Rust, Swift, PHP; only to name a few of the major languages out there, put their doc-strings right above function, not in it. 2. I would rather see a tool like Doxygen be used to generate the documentation for Nim. It's very mature, flexible, and generates easy to use docs. One other thing is that Doxygen generated docs typically are quite navigable. I find it a little hard to search through Nim's documentation a the moment. I'm not sure about the difficulty integrating the Nim language into Doxygen though
Python Modules & why Python is better
**... with Nim.** 浪 So some people chating about Python, and coming from Python to Nim, and etc. I will show you some stuff I done with Nim, on Python, and maybe works as an example implementation for people wanting to do the same. I wanted to speed up Python, everybody know is slow, and taking some functions that often slows down your scripts, they result on 4 ~ 20 times faster. `pip install faster_than_requests` [https://github.com/juancarlospaco/faster-than-requests#faster-than-requests](https://github.com/juancarlospaco/faster-than-requests#faster-than-requests) * Faster simple alternative to `urllib.requests`. `pip install faster_than_csv` [https://github.com/juancarlospaco/faster-than-csv#faster-than-csv](https://github.com/juancarlospaco/faster-than-csv#faster-than-csv) * Faster simple alternative to `csv`, some people doing data science seems to love this one. `pip install faster_than_walk` [https://github.com/juancarlospaco/faster-than-walk#faster-than-walk](https://github.com/juancarlospaco/faster-than-walk#faster-than-walk) * Faster simple alternative to `os.walk()`. All code is there, so feel free to check how its done if you want to do the same. Uploaded to PyPI with the `setup.py` on that repo, with `python setup.py sdist --formats=zip upload`. The repo also provides a `Dockerfile` for people wanting to try it without installing it. Packages dont have any dependency at all, they are faster than Cython, while syntax still more readable. The real work is done by [https://github.com/yglukhov/nimpy](https://github.com/yglukhov/nimpy)
Re: Nim and Project Euler
> What does it means? Firstly, that Nim is not popular at all. > Secondly, it > shows that Nim has not found an audience with people fond of mathematical and > programming challenges. Ok. Any ideas how to make it more popular? :-)
Re: Some nim builtin libs not doing enough error checking?
Well it's an edge case that I don't have a strong opinion on but I want my `removeFile "doesnt exist"` to remain silent.
Re: Some nim builtin libs not doing enough error checking?
Same here, I prefer checked it first with [dirExists](https://nim-lang.org/docs/os.html#dirExists%2Cstring) than immediately walk it.
Re: Nim and Project Euler
That is really an interesting report, thanks. So there are at least 13 Nim users -- well maybe some may have already retired :-) If I remember correctly, we had more than 100 users participating in 2018 Advent of Code using Nim, so this seems to be a more upto date lower bound. When we assume that number of Nim users is not decreasing, and only a fraction of whole community participates is last AoC, maybe ten %, then we have at least 1k users. This seems resonable for me and and is supported by Dom's polls from 2017 and 2018 with about 700 participants, with a larger fraction that has never used Nim and did not intent to use it. So yes, community is still small, and I think it has not grown much in last 5 years. Monthly a few people come, try Nim for a few weeks, and vanish. Unfortunately I saw some bright ones vanishing also.
Re: Nim and Project Euler
Secondly, it shows that Nim has not found an audience with people fond of mathematical and programming challenges. Run There may be people interested in mathematics (and its applications) but not in programming challenges that are generally more attractive for students. When I was a student I implemented some of the Euler's challenges in Haskell and I think Ocaml (it's been along time), but today with a limited time I'm more interested at implementing things that are more useful and related to my work. I'm my self a "mathematician" (now converted to an ML and CV engineer) and I noticed that multiple members of the community are in fact scientists or work in domains related to ML. For the little story I followed rust for years looking at it as a replacement for C++, but was quiet disappointed with the lake of interest in scientific computing from the rust team (the language make it VERY hard and very ugly to work on generic numeric types + problems with the borrow checker). What interest me in Nim is precisely its potential for scientific computing. So I think this numbers should be taken with a grain of salt (but I agree with you that Nim is less popular than the languages you mentioned, lets hope this will change after v1.0)
Nim and Project Euler
Hi all, In another thread, someone ( _mratsim_ ) has spoken of a lot of users using Nim for Project Euler. Maybe members of this “project” have done a lot of noise to make illusion, but I want to give some more precise data regarding Nim and Project Euler. For those who do not know about this “project”, this is a set of mathematical and programming challenges. In some cases, they can be solved by hand, but generally, at least starting from problem 100, you have to find a clever algorithm to solve them with a computer and brute force is seldom the way to go. The most used language is now Python with 52323 members (it was not the case, several years ago). One of the most successful language to solve the problems is PARI/GP, a specialized mathematical language, which has only 117 users. Python is well suited to solve the problems, but PARI/GP is probably better for some problems. I tried it, but was not very efficient and didn’t persevere. Nim was unknown of Project Euler until I asked the team to add it to the list of registered languages. It was done on 2016 October 17 and since then, Nim has got 13 members. Yes, only 13 members! And only two of them have reached level 1 (with 26 and 32 problems solved), one has reached level 2 (with 64 problems solved) and one has reached level 8 (with 215 problems solved). What does it means? Firstly, that Nim is not popular at all. Compared to its direct competitors, it is far behind. For instance, Rust has 697 users, D has 237 users (which is not very good for a pretty old language). Even Cobol has 36 users. To be fair, there exist certainly users whose main language is another one and who use Nim. And this is more likely to happen for Nim than for Python. But there is no statistics on the actual use of language and, anyway, you have not to publish your solution, even if it can be done (I have done it each time I found that my solution was worth it and could give a good image of Nim elegance). Secondly, it shows that Nim has not found an audience with people fond of mathematical and programming challenges. In fact, these are not a target for Nim, but Python has been very successful here and it’s not due to mathematical modules as _numpy_ as they are never needed to solve the problems. Actually, Nim is very well suited to these kind of problems, with only two difficulties. First, there is no big integers and you have to use _bignum_. Second, the copy semantic needs some care. And, as performance matters a lot, it is more comfortable to use Nim than Python (I know, I used Python before using Nim), even if _pypy_ may give an impressive performance boost. Of course, Nim popularity on Project Euler has not any importance. This is only an indicator and a biased one as I have said. But I wanted to give some precise data to remove some false hopes: no, there is not a large deposit of Nim users which are members of Project Euler .
Re: Best practices of meta-programming
> Write the macro transformation carefully. Ensure that the lineinfo in the > nodes remains useful. Where can I find any examples of this?
Re: Nim Advocacy & Promotion Strategies
For Python users, the syntax of Nim is not disturbing whereas this may be an obstacle for those using another language. But, this is a trap. Despite their syntax similarities, Python and Nim are very different languages and those who are not aware of the constraints of a statically typed and non interpreted language may be disappointed if they try to use Nim as they use Python. OOP is indeed one of the difficulty they will encounter even if Python is more flexible that Ruby for which OOP is mandatory. In Python, OOP is one way to do things, but it exists and is heavily used. Nevertheless, I think that this is not the main difficulty. I have tried to convert a complicated library (named _pdfminer_ ) from Python to Nim and I have given up for now. OOP is used everywhere, of course, and I encountered some difficulties with inheritance and dynamic dispatch, mixing procs nd methods. But the true difficulties were: – forward references; I was constrained to change some proc interfaces, to split some modules and join others; this was a laborious task; Python users don’t care much about that; in some cases, they encounter a problem, but most of the time (especially, if they don’t use global variables) it simply works as the binding of names is done at run time; – dynamic typing; in Python, a field may contain anything; when converting to Nim, you have first to find all the locations where it is “assigned” a value (the term is not right, but it doesn’t matter); then you have either to use some form of inheritance, which will raise other difficulties, or you have to use variants; in fact, I used both approaches, but the restructuring is complex. I have never encountered such difficulties when converting my own programs from Python to Nim, because, for me, and even in Python, a field must have a type. I seldom use extreme dynamic typing in Python as it hurts readability. But other Python users have not this shyness. So, users of Python and other scripting languages such as Ruby or Lua, may have unpleasant surprises when trying to use Nim. At least, if they don’t know what is a statically typed language which compiles to native code. Moreover, I doubt that Python users will find in Nim a lot of things they don’t find in Python. More checks at compile time which they often find more as an inconvenience than an advantage. Better performance, yes, even if _pypy_ does a great job compared to _cpython_. Will this make up for the lost of flexibility? I’m not sure. I cannot say for sure what could attract Python users to Nim. I’m not the typical Python user, even if I have used the language since its version 1.6 and was quite a fan of this language. Indeed, before using Python, I mostly used statically typed and non interpreted languages which is the reason I fill comfortable with Nim. I think that users of statically typed languages which compile to native code could be a better target as they can see what are the advantages of Nim compared to other languages in the same category. Unfortunately, Nim syntax will repel a lot of potential users which are accustomed to languages using a C-like syntax. This may seem a minor aspect, but it is very important. Nevertheless, I don’t preconize for Nim to switch to a C-like syntax: I would hate that. But this is a point to be aware of. As regards macros, they add a lot of flexibility to the language and, so, are often the way to make up for Nim lack of flexibility when dealing with types. So, some people are trying to do in Nim things which would be better done in another language. Again, Nim has limitations due to its nature and even macros will not allow to deal with types at run time (except, in a certain way, when using objects and inheritance, but this has a cost). The distinction between what is done at compile time and what is done at run time is certainly one thing which may cause misunderstanding and disappointment for new users.
Re: Some nim builtin libs not doing enough error checking?
I'd open an issue reporting this bug. And as you have already debugged the issue, you might as well then provide a PR to fix that issue too. :)
Re: New "Learn Nim" page
Thank you very much @rect0x51, and @miran, thanks for the help and for the careful advises. I love the simplicity and power of Nim.
Re: Some nim builtin libs not doing enough error checking?
An empty directory is something else then a non-existing directory, IMHO. I would expect a exception in this case.
Re: Some nim builtin libs not doing enough error checking?
Well, if there is no directory, then there are no files inside it to iterate on. Makes sense to me, I would not want an exception there
Re: "Nim needs better documentation" - share your thoughts
And one thing Rust is very focused on is documentation, especially since Rust has both ergonomic and conceptual barriers for beginners that are quite often immediate turn-offs.
Re: Some nim builtin libs not doing enough error checking?
Well, yeah, I dunno, docs can be improved but it usually does exactly the amount of checking that I like.
Some nim builtin libs not doing enough error checking?
eg, this code:
import os
for p in walkDir("/tmpX"):
echo p
echo "Hello"
Run
If the directory /tmpX does not exist, then control flow just passes on to
after the loop, rather than raising an exception about "directory not found".
In the nim code os.nim, for 0.19.2, around line 866, there's a call to opendir,
and then logic proceeds if the returned pointer is not nil (ie, there wasn't an
error.
But there's no branch in that code that handles the nil condition, gets the C
error, raises, etc.
It's possible to eg, make a PR which adds the C error check, and then raises an
exception. But that would break existing systems that depend on walkDir's
current permissiveness. Also, with Nim 1.0 being just around the corner.
I'm picking on walkDir here, but I have seen this in some other places.
Would it be more correct to eg, update documentation for walkDir to state that
by design it's not intended to? Similar to how eg, removeDir is documented as
not raising an exception if the directory never existed originally?
Re: Associating data to types
@deansher: Well, I was also looking for a way that would make the definition of messages nice-looking and trivial. The drum-roll-overloaded-procs are so simple I didn't even think of this, although I do not like the syntax for defining messages like this. But this is Nim: macro -> DSL to the rescue, all solved. Thanks!
Re: Nim Advocacy & Promotion Strategies
> There have been lots of proposals to push Nim's syntax closer to Python Indeed, many Nim users seems to have a Python background, and Python has grown a lot in the last years, see [http://pypl.github.io/PYPL.html](http://pypl.github.io/PYPL.html) But when you want to make Nim very similar to Python, as Crystal did it with Ruby some years ago, then traditional OOP is the largest obstacle. Some syntax differences really do not matter. But most Python code uses OOP style, which is not recommended by most Nim devs. So Python people would have to learn this new non OOP style, and would have to redesign legacy Python code. I tried to convert 8k lines of Ruby code to Nim last year. Converting syntax was no real problem. Problems are: Ruby OOP design with inheritance, Ruby containers with heterogeneous types and the absence of explicit data types, which has to be recovered for the Nim code. (Another problem, which is more a result of small Nim ecosystem, was missing libs like great GUI (so I wrote GTK bindings), RTree (I wrote one) and "Constrained Delaunay triangulation" (I started working on it). Finally, do you really recommend your Python using friends to try Nim? Why should they? Python users often have no CS background, not much demand for performance and no interest in language design. They enjoy the large Python ecosystem and are happy. Of course there are exceptions, so I indeed advertised Nim to some of my smart friends. But as these are smart, they generally know more than one language, generally the know at least C and Python. PS: I think what most scares off users is macros. When new users comes to Nim and ask something non trivial, answers is often "well, that may be possible with a macro". I know very well how deterrent this is from my LaTeX days. Got sometimes similar answer in comp.lang.tex, but at least often some kind tex experts gave me the desired macro for free.
Re: Associating data to types
:-) For this example as written, you could use (drum roll) overloaded procs: type MsgAlpha = object id: int x, y: int url: string MsgBeta = object id: int resource: string proc msgId(m: MsgAlpha): int = 1 proc msgId(m: MsgBeta): int = 2 proc serialize[T](msg: T) = var msgcopy = msg msgcopy.id = msg.msgId echo msgcopy serialize MsgAlpha(x: 10, y: 30, url: "http://foo.bar;) serialize MsgBeta(resource: "GLES2") Run I suspect you may be trying to do something more elaborate that isn't captured by your opening example here?
Re: Nim Advocacy & Promotion Strategies
> The number of people who like the freedom points I'm making is several orders > of magnitude greater. There aren't many things Nim can be Number One Best at, > but it is on this issue. So this is a valid niche for Nim to embrace! Which _niche_? It 's only you and so far your contributions consist of rumblings on this forum which are more harmful than helpful for Nim's perception. > Recommended reading: Theo de Raadt's rejection of "safe languages". I've read it, it's FUD.
