I've found some (arguably minor) things to be kinda messy. Maybe the result of a one-person language that grows too much before getting some feedback.
1) Everything is (strangely) called a procedure, and then there's syntax to differentiate arguments that will be modified in place (proc myproc(myarg : int, inplacearg : var int)). Kinda weird, and a lost opportunity to have checking for pure functions at compile time.
2) import vs. include. Why have include at all to shoot yourself in the foot if you have cheap namespacing?
3) If vs. When ?
4) varargs feels kinda unnecessary
5) Case-insensitive. Oh... why?
On the bright side, I like how OO was implemented.
I disagree that it's a middleground between C and Python though. I see it more like an evolution of Pascal, it has the same niceties (ALGOL-like, static types, builds executables) and some things added on top (no VM, but GC'ed, metaprogramming).
Oh, it does bring a lot to the table that C and Python don't have. You're totally right, it is not a middleground per se, it is just the language I was looking for.
If I try to answer your points:
-> 1) The procedure keyword comes from Pascal. I am not shocked by it, when I learned programming the teacher used to call them procedures also.
The 'var' in procedure arguments could be considered the opposite of the 'const' of C/C++. Everything is const by default in Nimrod, but if you want something modified in place you indicate it.
-> 2) Herm... I got nothing. I haven't used include, I didn't see the use for it yet.
-> 3) 'when' is compile-time, 'if' is at runtime.
-> 4) Unnecessary? varargs is quite useful. For example, if you use redis, you can do db.del("akey", "anotherone", "otherkey"), instead of having to fiddle with an array. Varargs makes some calls cleaner.
-> 5) "The idea behind this is that this allows programmers to use their own preferred spelling style and libraries written by different programmers cannot use incompatible conventions." from the Nimrod manual (http://nimrod-lang.org/manual.html). It forces you not to name functions and variables too closely. So you won't be able to have different things named myStuff and my_stuff because it will refer to the same variable or proc. You enforce your own writing style. That is debatable. You have others enforcing a style, like with gofmt. The case insensivity did not disturb me, though (but I admit it surprised me at first).
1) I'm not a fan of both the name `proc` and `var` because it allows you to mix inplace editing with return values and makes a mess of the (IMO, precise) meanings "function" and "procedure" have.
If I were starting a new language, I wouldn't pass the opportunity of disallowing mixing these concepts, so there's a way to reason about pure functions.
3) I get that, but it feels like something that could've been optimized away by the compiler, they didn't bothered and instead bloated the syntax. Not a fan of the naming too.
4) Just IMHO, but this kind of magic feels out of place on a static language. In something like Python, variable arguments aren't as opaque since there's an underlying object being passed around (a list or a dict), and your arguments can be of any type.
1) Conversely, while Ada used to not allow in out parameters for functions, it is allowed as of Ada 2012 [1]. There's certainly an argument to be made either way. For what it's worth, I'm not a big fan of functions with side effects myself.
3) You can't optimize it away. A compile-time conditional statement has to allow for undefined identifiers and such, but for a runtime conditional statement you want to have the compiler signal an error even if it can statically determine that the condition is always true or false.
3. If == runtime control structure. When == COMPILE time control structure...code in a failing when clause is not compiled. Basically the equivalent of something like an #ifdef pre-processor macro in C.
1) Everything is (strangely) called a procedure, and then there's syntax to differentiate arguments that will be modified in place (proc myproc(myarg : int, inplacearg : var int)). Kinda weird, and a lost opportunity to have checking for pure functions at compile time.
2) import vs. include. Why have include at all to shoot yourself in the foot if you have cheap namespacing?
3) If vs. When ?
4) varargs feels kinda unnecessary
5) Case-insensitive. Oh... why?
On the bright side, I like how OO was implemented.
I disagree that it's a middleground between C and Python though. I see it more like an evolution of Pascal, it has the same niceties (ALGOL-like, static types, builds executables) and some things added on top (no VM, but GC'ed, metaprogramming).