OK, I lied, I'm not a newbie. Inspired by Araq's NimConf video, I cracked open my copy of "Mastering Nim", and downloaded and compiled the latest Nim on my Pop!_OS, an Ubuntu Linux variant. The very first example has me install the pixels library with nimble install pixels, and I'm immediately greeted with
could not import: SSL_get_peer_certificate
Great, I google that, see the suggested fix of downloading and installing some old openssl variant, and think "No thanks!". I mean, who uses Ubuntu, right? Thankfully, I have a very old Mac around too, so I download and compile Nim again, run nimble install pixels, and while I don't have openssl issues, I get
/Users/bpr/.nimble/pkgs/sdl2-2.0.4/sdl2/ttf.nim(23, 24) Error: invalid indentation
At this point, I'm much less interested in continuing, but I think maybe it's an issue with the devel version, so I download choosenim, select a stable nim, try again, and have a new error.
I largely gave up on Nim a while ago, dropping by here every now and then to see what's changed. Maybe I'm just a !@#$ing idiot who doesn't know how to use computers, and it's all my fault. Sure, maybe, but I haven't had these kind of issues with any other languages, mainstream or not, that I've tried lately. Perhaps the Nim community needs to do a better job of idiot-proofing?
PS: Yeah I looked at that line in the ttf.nim and it looks fine; my point is that someone starting on Nim and running into all this crap would just quit with a very negative first impression of Nim, which is unfortunate.
Ouch. Yeah, these kinds of paper cuts are bad news in newbie-facing stuff.
I’m wondering why pixels, a “toy support library for primitive graphics programming”, ends up installing OpenSSL in the first place. Must be an unfortunate transitive dependency. I looked at pixels.nim and it just imports something called “sdl”; no idea what that is.
I mean, who uses Ubuntu, right?
This openSSL occurs on Ubuntu 22.04 as well. And yeah it's annoying. It's also worrying to ask the user to downgrade sytem security library.
This type of problem where things don't work out of the box and you need to tinker a bit are very common in many language & open source library.
Even Python's pip has had them over time (while being one of the most popular language out there).
But this isn't really a Nim as language / compiler problem; it's a nimble problem. And it's no secret that Nimble is sub-par as a package manager when compared to modern Package manager.
First, it is always hard to define our expectations in terms of newcomers. People that have never learned any programming language, but uses Linux ? Should we target children, that had barely CS/Mathematics lectures ? People also have different objectives in programming, so making tutorials that takes into account this diversity is hard.
I made this kind of comment on "Mastering Nim" by the past and I regret it. I thought that the cover was too bland. Actually, since it is colored, I have seen many people in public transport, trying to read the title on the cover. I also reproached to Araq the fact that the pixels were «too» small (aren't they pixels XD ?) or that it was missing the sdl dependency at first. Oh, it also did not specify that your font had to be in ttf format, and that some package manager might download your font in otf format (I had none other font installed and my program could not render text). Yes, it is maybe not easy for beginners. But I find it ironic to reproach the « Mastering Nim » to not be newbie friendly while it explicitly says in the preamble that it expects the reader to be already familiar with programming. It also explains the type and effect system, traits, metaprogramming, go in depth into procedure overloading resolution's algorithm, which are many things a newbie does not want.
I believe that any good tutorial for a programming language, unless it's meant for children, should start with console programs. That way you actually learn the language and not a specific library.
@xigoi Araq made a bet to propose for the first time a tutorial that is not CLI oriented, while giving an overview of the programming language as a whole. The library pixels is a toy library and it doesn't use much of it (barely two functions putPixels and textToDraw). Notice he avoids speaking of all SDL2 stuff (context initialisation, window events, etc...), and put the focus on the structural programming capabilities of the language and the design concepts.
I believe it is for a good reason that « Nim in Action » is still on the front page of nim-lang.org. It does not feel obsolete to me.
The main disincentive to me is the lack of internationalization. I wish there would be more tutorials in French, Spanish, German. When you are learning English as a foreign language, it makes learning a programming lang much slower, and, when progressing too slowly, we often give up.
Furthermore, (at least in French), Nim search queries are often concealed between queries for the Nim game, which is a mathematical/logic game.
Sure, maybe, but I haven't had these kind of issues with any other languages, mainstream or not, that I've tried lately.
I have tried rust. I downloaded rust, open the tutorial and learns that I would actually need rustup version instead. But rustup actually installs with cargo. They do have a CLI interactive exercise tutorial for beginners which is well made, but I would not recommend beginning with the borrow checking model of memory management as a first language.
We do have an Exercism track. The CLI interface of exercism is hard to install, it doesn't really help in fact, but one can do almost everything in the browser now. It helped me a lot, but I was not a newbie (having learned 3/4 programming languages before) and had to read the documentation in addition to Exercism.
C/C++ is not at all easy to begin with. You quickly have to learn how to write a Makefile in addition to the language. They are very unsafe, bloated languages.
Python3, pip search does not work anymore. Speak of an error message:
ERROR: XMLRPC request failed [code: -32500] RuntimeError: PyPI's XMLRPC API is currently disabled due to unmanageable load and will be deprecated in the near future. See https://status.python.org/ for more information.
You want to force install a package, and then realize you had to install it as a user so you remove it. sudo pip uninstall pytorch and you manage to break your whole distribution (the problem is both in the user and concerns any programming language that a distribution uses, more than in Python but ...).
So far, all the programming languages I tested had issues or did not look beginner friendly at least in some aspects.
You're right, the OpenSSL problem is with Nimble, not Nim the language. Unfortunately, the language, which I happen to like, will be judged by the ecosystem.
Someone said "Copying bad design is not good design", a rather obvious and unhelpful slogan IMO. How about copying good designs? For all of the complaints I hear about Rust hype, my experience with Cargo is the opposite of my experience with Nimble. Julia, the same. I haven't used Go that much, but package management seemed fine there too. Likewise opam for OCaml. It's a shame that a fine language has such a suboptimal (being kind here!) package manager.
You are critic, but you don't say in which way it is suboptimal.
What are precisely the good designs you want to add to Nimble ? Have you opened Issues in that sense ?
The openssl 3 issue is with the openssl wrapper in the standard library. It was fixed in the development version but it's opt in as shown above and it's kind of a messy fix, thus it hasn't been backported to the stable line yet. You're right that this should be resolved but it hasn't been done for the time being.
The sdl2 issue might have to do with spam accidentally being left in code in sdl2 in a recent PR and the version tag not being updated properly. Not sure though because I remember this being fixed. A nimble install sdl2@#HEAD should fix it in any case (meaning install the latest commit of the package).
Unfortunately there is not really a guarantee of consistency to issues getting fixed so encountering issues is possible. This can get attributed to laziness but it's not really that simple. You can at least count more on things like people giving information about issues on the forum.
Yes, for newbies it will be the true disaster - errors, dependencies hell, no example source code in gitlab/github, some unexplained words in examples and so on.
But the book is not for newbies - om page 5 it is explicitly stated "this book for people who can already program". I would add - "and who can handle OS and packages" Errors and dependencies? On Linux we face it very often (Linux sucks!) and know how to solve it (couple installations and both my arch linux and ubuntu works fine). No example code available? Yes, and it force you to write your code, think and guess how to make examples meaningful, adding lines of code from a book and your own lines of code. Pixels are small on your 4k/8k monitors? Yes, but you should know your HW, and it is intermediate steps for drawing lines anyway.
The name is "Mastering", not "For Dummies", not "in 24 hours". Mastering is a set of knowledge, abilities, skills. And this book provides a path for mastering - dry, demanding, igniting for "grokking"