Feedback is welcome.
'bnot' won't be a keyword, but an ordinary identifier. Note that 'f x' is valid syntax now (I think it was introduced with 0.9.4) and so 'bnot x' doesn't require ().
People take 1.0 as a hint of finished product and may be disapointed if it is not polished. The documentation does not need to be a novel, lots and lots of small examples usually do better.
Ability to write unit tests may partially offset lack of the debugger. I know there's an undocumented library but when I looked at it I didn't understand (nothing unusual) and, worse, had no idea how to use it.
The ideal for me would be this form:
proc foo = ...
TEST()
assert(...) # if fails testing stops right now, no other fancy here
...
TEST()
...
TEST(optional_test_name)
...
proc bar = ...
TEST(another_name)
...
...
and when compiled with relevant command line option all tests will be compiled in and executed on application startup. The is_main_module is not realy good tool for test heavy coding.
•A named tuple will be compatible to a tuple with different names.
-- what will distinct tuple mean then?
documentation (more, better etc)
People always complain about this, but the facts are:
Please continue to make bug reports about insufficient documentation!
Ability to write unit tests may partially offset lack of the debugger
Nim has 2 debuggers, GDB and ENDB and Visual Studio is used successfully as well. GDB is not perfect, but perfectly usable. Use it with --lineDir:on --debugInfo.
The is_main_module is not realy good tool for test heavy coding.
I disagree. I think it's perfectly fine.
what will distinct tuple mean then?
The same as now: It's not particularly useful, if you want a nominal type, use an object instead.
The bitwise 'not' operator will be renamed to 'bnot'
I can understand that we use and/or/not for logical operations (in Ruby where and/or/not and &&/||/! exists both, but with different precedence, I tend to use the later.)
But for bitwise operations, I really would prefer something like ~ ^ or ! but bnot. Bitwise operations is some sort of low level operation, so people doing that should know the relevant operator symbols (guessing the meaning of bnot is not easy.). And for bitwise operations brevity is an important advantage. In mathematics we generally do not write "1 plus 2 times 3".
This is my current feeling, my opinions may change later...
People do not read what is documented anyway.
Programmers are often not very good in writing (and reading) essay like texts.
However, they are highly skilled to grok small pieces of code. I have 20 years of training in this art. To me the ideal would be nimrod-by-example expanded 100x.
> The is_main_module is not realy good tool for test heavy coding.
I disagree. I think it's perfectly fine.
It allows to test only one module in the simplest case (when you just start the app).
For C I did my own infrastructure to support unit tests. It looks like:
#ifdef TESTS
TEST(my_test1)
{
...
}
TEST(my_test2)
{
...
}
#endif
Adding a new test take second or two, at any place in any source file. The tests all run automatically whenever the application starts. Every test does leak checking. I have about 1 : 5 - 10 ratio of lines of code to test lines and this helped to keep code coverage at almost 100%. (I know coverage is not a fire-sure indicator of quality.) Visually the tests are easily distinguishable, I do not feel like being drown in them.
(Potentially Unreasonable) Suggestion:
(Related to the first bullet point above.) The language might be more user-friendly if iterators and procedure pointers were at some point made {.closure.} by default. In my experience, the use-cases for context-pointer-free procedure pointers are
The main use-cases for inline iterators are
Not having to think about calling conventions when writing everyday code would let users simplify their mental model of Nim, and ease the transition from languages like Python and JavaScript.
@araq:
So what is it that you suggest?
Either to wait with 1.0 until type classes are not experimental or to mention them visibly on first page as one of major future features of the language. Or both.
I fully understand Araq's wish to release Nim 1.0 as quick as possible. Rust is going towards a 1.0 release at the beginning of next year, and a lot of people desperately seeking for alternatives to C/C++/Java and willing to try something new and modern (Nim's main target, afaiu) are eager to adopt either one or the other solution. But I must sympatize with dom96's fears: if those people will try Nim and find some bug, they'll likely dismiss it and land on other shores. Given the number of language changes that are going to be included in 1.0, I fear that the risk of failure is high. (Araq often cites KDE 4.0 as an example of a not-so-perfect delivery that improved with successive bugfix-releases, but in that case KDE stood on the huge credit that previous versions had gained among users. For Nim, the situation would be much more uncertain.)
In one of my previous posts I asked about the idea of a set of "release candidates". I think that having them would be able to satisfy several needs.
First, a "1.0RC1" release sounds more impressive than a "0.10.0" one, because it gives the idea that things are going towards a clear direction. This should encourage hackers to have a look at Nim, thus increasing the number of testers (if Araq releases a 0.10.0 release, I do not think so much new people will try to run it, even if it is advertised as a "pre-1.0 release"). More prudent potential adopters would still stay away, but their interest would nevertheless be raisen ("Hey, the 1.0 release is likely to be ready pretty soon! I'll definitely give it a look once it's ready"). On the other side, the fact that this is a RC should grant that early adopters will not be pissed off too much if something does not work.
Nim's versioning has a serious flaw right now: Since the "major" version is stuck at 0 forever, the minor version reflects the major version and the bugfix version the minor version and so there is no bugfix version number left.
Hence people request 0.9.6.1 (https://github.com/Araq/Nimrod/issues/1701) even though that doesn't fit our versioning scheme. Releasing 1.0 finally makes our version system work, 0.10.x keeps this problem for another couple of months.
And Jeff Atwood agrees with me: http://blog.codinghorror.com/version-1-sucks-but-ship-it-anyway/
Will the remaining T/P type prefix names be 'fixed' by 1.0? I was fine with the old convention, but I don't like conventions partially or inconsistently applied.
What would be the difference between a 0.10.2 and a 1.0 release? Some are arguing for holding up 1.0 until user defined typeclasses are much more stable. I'm anxious to see that feature too, but there are always more features to add or fix.
In terms of the psychological/sociological effects of a buggy 1.0 on Nim popularity from that first Reddit entry; no one knows how that will turn out. Don't use a forecast of its effect to make a decision on the release.
Voicing my support of keeping using in the language, putting it behind a switch is fine but it is a nice feature. JavaScript's with statement has problems because name conflicts are handled silently, and as long as using fails to compile if it would be ambiguous it is fine. In my experience generic and using are much less buggy than static[T].
Oh! and for debugging I have found that standard C debuggers work but it would be really nice to have some way of getting the real symbol names and scopes. Not sure if debug info formats support this, and even if they do it is probably not a great idea to have the nim compiler mess with the debug info, preferable to put annotations in the C source. Not to mention that the PDB format is pretty closed. I find myself using {.emit: "__debugbreak();".} quite a lot when debugging.
On {.inline.} iterators and procs. Proc types default to {.closure.} and {.closure.} iterators do not work quite the same way that {.inline.} ones do. Besides it is absolutely CRITICAL that iterators do not have overhead, because if they do than nobody will use them. Also, I think that inline iterators are just much more intuitive than closure ones, you can explain them to someone by just saying "yield represents the loop body". One thing that would maybe be reasonable is an easy way to wrap an inline iterator in a closure iterator, so you can pass it around, but at that point you loose the speed benefits anyways. In fact I would say that closure iterators are not very useful for iterating at all, and it is strange to call them iterators.
Also someone who understands it should write up a blog post or make a library for doing variadic generics, just implementing something like the following c++ code:
template <class T>
struct special_decay
{
using type = typename std::decay<T>::type;
};
template <class T>
struct special_decay<std::reference_wrapper<T>>
{
using type = T&;
};
template <class T>
using special_decay_t = typename special_decay<T>::type;
template <class... Types>
auto make_tuple(Types&&... args)
{
return std::tuple<special_decay_t<Types>...>(std::forward<Types>(args)...);
}
@araq
I disagree with dom96 on that part, we promised to deliver 1.0 this year and any further delays are unacceptable. Perfection is the enemy of the good.
As much as I like the type classes feature, I couldn't agree more with Araq here. It's high time we saw 1.0 - that's the beginning, not the end of the language design. Language evolution can continue, perhaps better informed by many real use cases. Look at Go - some say it still doesn't have all essential features but it's going strong at 1.4.
Yesterday this article about the imminent release of Rust 1.0 appeared on Hacker News:
http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html
Apparently, this generated a lot of attention, despite the fact that no new release has been published yet (it's just a time table with the expected dates of the alpha, beta and final 1.0 version).
Wouldn't be worthwhile to publish something similar in the News section of Nim's website? I see two advantages and one drawback in this:
The major drawback is that, once the dates are published, missing them would potentially damage the reputation of the project. I am part of a big scientific project (> 1000 people involved) that has always published its (irrealistic) deadlines… and has nearly always missed them. But since I feel Nim 1.0 is really close, I think that such a move would be justified here.