The Nim programming language just released version 1.0. Since the Julia community has gone through that transition recently, I thought some might find it interesting. Congrats to the Nim team on the huge milestone.
As an outsider, Nim seems to be aimed at the same kind of niche as Go where it’s a faster high-level (garbage-collected) language that compiles to a single binary. But it doesn’t have Go’s peculiar aversion to abstraction, having things like generics and macros as a basic part of the language. Altogether, I find it quite neat although not as practical as Julia for the kind of work I do.
If it helps y’all to relate to the Nim community, every time Nim is mentioned on HN or similar, someone inevitably happens along to talk about how Nim’s case-insensitive identifiers absolutely ruin the language. Feels very reminiscent of the reaction to Julia’s 1-based indexing.
I am actually very surprised how those discussions died out (not that I miss them ). I would assume that prior to 1.0, people thought that the language was open to these kind of changes, and now they don’t.
Hum, I think I still see them in HN. Usually, criticisms towards Julia seem very unconsequential (“1-based indexing? Yeah, no thanks”). As if that were really what makes or breaks a language…
On the other hand, if those are major criticisms of the language, I guess the community is doing a thing or two right. I don’t think those people have bothered trying out Julia, though.
But also, to criticize a mature language like Julia in any meaningful way, one has to understand it in depth, eg write at least 50–100k LOC in it, and by that time it grows on you (except for the case-insensitive identifiers, which absolutely ruined the language).
hold up… I don’t think this is on the same level as 1-based index, like, at least MATLAB and R are 1-based index and are quite popular in Julia’s targeted field. I’ve never heard of case-insensitive modern language till today…
(now that I think more about it, how does Nim handle Unicode and emoji…(not that they’re that important))
Yeah, that sounds a bit weird. I mean, why would you put extra effort to e.g. convert everything to lowercase before parsing? I am sure there is a valid reason behind it.
Nonetheless, such things are usually irrelevant for me when I choose the tools for the job Congrats to the Nim-team!
As discussed recently on Slack, Nim had multiple dispatch and ditched it before 1.0: https://github.com/nim-lang/RFCs/issues/65
For us Julians this sure seems an odd thing to do.
Edit: turns out this statement was wrong. But as wrong comments often do, it did spark an interesting discussion with Nim users/devs.
Another very old case insensitive language is REDUCE for which I made Reduce.jl package, this language happens to also be the very 1st computer algebra system ever created, very old. From Introduction docs:
Another characteristic of the above example is the use of lower case on input and upper case on output. In fact, input may be in either mode, but output is usually in lower case. To make the difference between input and output more distinct in this manual, all expressions intended for input will be shown in lower case and output in upper case. However, for stylistic reasons, we represent all single identifiers in the text in upper case.
In the 1960’s, input devices only had capital letters, hence nearly all programs those days had upper-case names.
So it is a limitation that stems from the 1960s in this case… NIM is a new language though, weird.
julia> using Reduce # use `}` to enter reduce> mode
Reduce (Free CSL version, revision 5040), 14-Jul-19 ...
reduce> X + x;
2*x
Which is rather unfortunate, but hasn’t bothered me too much yet.
The REDUCE language uses ASCII to encode some unicode characters (in the CSL version, the PSL version is based on old pure lisp and does not support much unicode at all)
julia> Reduce.RSymReplace("x+!#03a9")
"x+Ω"
The Julia implementation of the package is designed so that they are automatically encoded if needed.
Indeed. They had a (basically not working) REPL as well which was removed. It’s a language a lot like Julia, but they pulled out the (hard) interactive pieces and the specialization features to make the language much simpler. FWIW, it’s really good at what it does and I can see this really appealing to some audiences. Not scientific computing, since it’s missing a lot of the things that I need for example, but it would be a good Julia alternative for embedded code (since it compiles to C).
The idea is that Nim is style-insensitive, so it’s not just case but also underscores that are ignored. An identifier that’s defined as foo_bar in a library could be used as fooBar in your application so that it matches the style of variable-naming in the rest of your application.
Hm, after thinking about it a little bit, I’m not sure it is so strange. Multiple dispatch is a much more natural fit in a dynamic language than a statically typed language. I wonder if Nim even allowed dynamic dispatch at all. What really juices the utility of multiple dispatch in Julia is the fact that functions default to generic (which is also much more natural in a dynamic language).
Additionally, I kinda feel as if the domain of scientific computing has more intrinsically “shared” verbs than general consumer/enterprise software. Julia couldn’t even think about removing multiple dispatch even if it were obscure in user code because so much of the standard library relies on it; apparently it was relatively pain-free to remove the feature from Nim, so not much of the standard library must have used the feature.
Another interesting idea is having a keyword for non multiple dispatch method. In that issue, it was suggested for example
If anything, multimethod dispatch could be enabled by a multimethod keyword instead of making method implicitly a multi method dispatch
Except, for julia multiple dispatch would be default. Then if you wanted to, you could also do single dispatch methods. Dont know if that’s feasible or not.
Just a brief mention for the IDL programming language which is reasonably modern and case insensitive (outside strings). It’s also an extremely good language for interactive mathematical programming (better than Matlab IMO). But IDL is increasingly limited and I am trying to make the switch to Julia…
um, notice that even though it’s younger than C, IDL is actually older than C++ by 3 years. While people can rightfully call that modern, it’s still amazingly old.
This feature was taken from Pascal and Ada, and I have always liked it very much! It prevents people from using variables like x and X in the same block of code. (Yes, I saw this many times in C/C++ codebase.)
When I have numbers assigned to a variable that I’d like to use for loop bounds (eg, N = size(A,2)), I like using the lower case letters as the loop indices (idea taken from the Stan manual):
for n in 1:N, m in 1:M
A[m, n] # probably doing something
end
I find this a little easier to parse and understand than traditional i, j[, k] because the lower case letters are naturally paired with their respective upper case counterparts, while with i,j,k and friends I’d have to keep track of which one is iterating over which range.
In Julia, multiple dispatch is one of the keys to performance.
Better performance was one of the reasons Nim folks took it out; seems like multiple dispatch was being used for dynamic dispatches.
Apparently Nim folks weren’t using multiple dispatch. A lot of my code would break without multiple dispatch, and I think Julia library maintainers would be up in arms over the suggestion…if they could even take such a suggestion seriously in the first place.
Case-insensitivity sounds like a terrible feature, and would break much of my code. N and n, A and a, i and I. Also, apparently you cannot use underscore to distinguish temporary and helper variables/functions.
Perhaps this means that Nim is not particularly geared toward physics and maths related computing? For code with lots of equations and abstract entities, case-insensitivity seems particularly unfortunate.
Fortunately, I think that “let’s change the fundamentals of how Julia works” (when compared to the original papers by Jeff Bezanson and others) suggestions are just ignored since 0.4-ish, unless they are exceptionally well reasoned.
). I would assume that prior to 1.0, people thought that the language was open to these kind of changes, and now they don’t.
I am sure there is a valid reason behind it.