Hello all,
As title say, I'm new to Nim, so I'm gonna introduced me a little and just give a few of my first feelings. I'm French, I work in electronic and mechanic conception, not doing much programming recently, except some for microcontrollers. used assembler, Basic, Forth, C, C# in the past and since a few years take a little part of my small spare time to learn new programming language. Ruby, Python and a little Javascript recently. was about to look at Julia, but found Nim and needed something able to do native compilation for an eventual project, so looked at it and was really impressed and interested by Nim. so a big thank you for your work..!!
I read rapidly a big part of the doc (will have to go over it several times again more slowly) and all the recent posts on the forum. now my feelings about Nim are really great, but more uncertain about it's environment and it's eventual rapid evolution. I saw several indications in the forum about an eventual soon v1.0, but it's really not so clear and the roadmap I found is not really a roadmap, but just an indication of a few things we could expect in v1 and some others that will come later. actually the stable release is 0.10.2. is there already something planned about when it will be called v1 ? (just to be curious)
I saw a big discussion about Aporia IDE and auto-completion. for me an IDE for a "new" language should have a debugger and a project explorer before auto-completion. I see someone telling that it's not possible to code big project without good auto-completion, I'm ok, but it's even more necessary to have a debugger for me. and even more as I also read that the compiler doesn't always return much explicit errors..! I'm working on Windows, so GTK is not really what I tend to use, but since Aporia was included in the Windows Nim installation, why not for now. (would probably have been smaller with IUP than with GTK library). now, since Aporia is included in the Windows install, why Nimble is not ? should be more logical than Aporia for me.. about Nimble, it would have been nice to include Git API support directly in it, so - on Windows - there would have been nothing more to install and a simple installation could contain all that is needed to go with Nim.
Aporia could become a real IDE one day, but it seems to me that it would have been better at first to start with existing editors and IDEs. less work and more visibility for Nim. would be better if the most used editors/IDEs on each platform already have a simple Nim support to help people try Nim, with their usual tools. and it would help setting Nim in the "standard" programming language for people who never heard about it before.
I also read that the forum was made with Nim. great again, nice to have real exemple to help learning how to code with Nim, but once again, there are already many good existing forums available and I wouldn't have invested time in something that is not directly useful for the Nim language. Of course the forum is nice, but Araq said on the forum that the actual debugger is to and end and that the compiler doesn't give explicit errors, so those points should have been the number one priority for me.
there's no real information about the team working on Nim. is it just Araq on Nim and a few around in the community for libraries and support or is there a bigger team working on Nim core..? I saw conversations about Nim evolution, but it's not clear if there's much people on it.
so, sorry, it's not well organized, and if it looks rude or something like that, it's a mistake due to my bad English. I'm really impressed by Nim and I just tried to express my first feelings about it. will take some time to learn it my way now (don't have much time those days, big project at work..). thanks a lot for your big work on Nim !
Fred
there are already many good existing forums available and I wouldn't have invested time in something that is not directly useful for the Nim language
But how could a language evolve without being used? A programmer needs to use his programs in real applications just to get to know what features it misses and in what it needs to be improved.
Nim already has a debugger.
Very few languages have a GUI debugger compared to those with autocomplete. A file explorer is practically the same as a project explorer. If you are talking about an outline of the file containing all the functions and types, yes that is nice to have but not as essential. So I disagree that auto complete should be made after those 2 features.
If you are really in the electronics business you should be used to trial and error/print debugging.
in fact I'm more used to work without debugger on PC recently (with Ruby and then Python for example, but only did a few simple personal projects) than on MCUs where nearlly most of them offer live debugging now. worked with STM32 (ARM Cortex-M0) recently and got debugger and memory watch even with several free softwares.
but since there was an official Nim debugger, would have been nice to make it work from Aporia. of course if it's really to an end, the subject is closed...
about the code explorer, I think it's easier to have than a good and fast auto-completion, and could be of great help also.
I would also love to have 20 different new features in Nim including a GUI debugger and the broken user type classes, but the truth is that we only have 1 developer (Andreas) who is familiar and invested enough with Nim to be adding huge features like this.
If features are not prioritized adoption of Nim will be slow because it is focusing on non-essential features. GDB should be good enough for now.
@Thordin that wasnt very constructive. I know I am not a senior Nim dev but we all know how much Araq puts into this and we are all happy with the lang or we wouldnt be hanging around here now would we. But expressing what we feel is important for us is really important. That way the powers that be (Araq and Co.) get a feeling for what not only the senior know-it-alls want but maybe what a low level coder from france likes or a game indie coder finds interesting or maybe what you find interesting.
And since you know what will be prioritized in Nim and what is good for adoption and not I hope you also tell you opinion. GDB is probably awesome, but tell that to anyone used to doing their C debugging in VS and maybe it wont all be roses in all cases. Then on the other hand I have no illusions that the nim devs all sit about with tons of paid free time and just no ideas as what to do with this language.
Most people programming in C/C++ don't use VS. Not only does it require Windows, it cost a huge amount per user. Many people use GDB as their main debugger.
Being able to enable breakpoints in your GUI is nice, but is it necessary? Absolutely not. There is not much difference between clicking a line and typing "b 123" in gdb.
In fact, you could probably code that into your favorite editor right now without needing Araq's expertise.
I am not saying a GUI debugger isn't useful, but Nim has very limited developer time and needs all the focus it can get to become a popular language.
Being able to enable breakpoints in your GUI is nice, but is it necessary? Absolutely not. There is not much difference between clicking a line and typing "b 123" in gdb.
There are UI frontends for GDB available. Lots of. And they work with Nim, why wouldn't they? Apart from that debugging with GDB has serious drawbacks as has VS's debugger so that I'm usually faster with 'echo', 'writeStackTrace', 'if' and {.watchPoint.} or {.injectStmt.}, but I should write a blog post about it.
Print debugging is tedious and only gets you so far.
On the contrary, it's debugging with a debugger that doesn't scale. YMMV.
> but Nim has very limited developer time and needs all the focus it can get to become a popular language.
I'm ok with that. it was why I asked about the team behind Nim.. wasn't sure how many people was working on Nim core. so maybe a little more information about what are the priorities and then we won't come asking for something witch is planned later. but it also good to see from time to time what people are waiting for and maybe is not already planned...