This change also fixes the Julia issue that bothered me the most personally: if in a comprehension with nested loops any of the non-outermost ones was over an empty sequence, you'd get an error.
I'm happily getting my work done ~50x faster than python/numpy could offer (cython would be a massive headache for the fiddly numerical work I'm doing). Don't get me wrong I often still use Python + numpy for prototyping and non-scientific work but I switch to Julia for bigger numerical projects.
Python was around for a long time before Scipy took off. MATLAB is expensive, proprietary and I do not enjoy coding in it. C, C++ and Fortran are all fantastic for some kinds of numerical work but for what I do, the speed of development and readability are far superior in Julia whilst still yielding excellent execution speed.
edit: Regarding API stability mentioned in other comments, I'm not sure I agree as we are only just coming up to v1.0. However, even if the criticism is valid I'll still be developing numerical code faster in Julia with API changes than in C/C++/Fortran.
Wouldn't hold my breath even then. They decided to split a lot of functionality in Julia into a standard library, which they will keep changing indefinitely. There goes my hope of Julia having any API stability.
Alternatively, you may see this as a sign that we've thought carefully about which APIs are stable enough to be part of the long term stability guarantees of 1.0, and which APIs are not, making it more likely that we'll able to maintain those guarantees longer.
Also, there nothing really special about code that used to be in base, but is now in stdlib other than historical accident. It so happened that we used to ship a git client as part of the language, but the HTTP client was a separate package, despite the latter probably being a lot more useful to users. Packages can and do have their own stability guarantees. With the language itself maturing, I imagine package authors will start taking advantage of this more.
Yes I get your viewpoint about long term stability guarantees and feel it's valid to a certain degree. But I waiting for so many years for Julia 1.0 while expecting the entire language (base + stdlib) to have API stability for at least a few years, and hopefully many many years, like Fortran or at least Matlab.
Also, I wish you guys would have some overarching philosophy w.r.t API stability in the stdlib. From looking at the github, it seems like the core developers are just delegating API change decisions in the standard library to new people who are not as familiar with the code base, without much discussion at all. I just don't think that is the way the stdlib should be managed.
With Pkg(3) you can lock library versions (including standard library). As the Julia API won't change in 1.x it won't break after upgrading. You should be fine.
On the other hand, as far as I understand, 1.0 means that the API is stable but not that all 'luxury' features (debugger, Atom/VSC code integration, etc) are perfectly working and/or even ready. This will come in future (it needs a stable API).
"proper package" in that it has a toml file and a uuid, but it can't be controlled by the package manager in terms of updating, handling installation, or pinning versions. The stdlib "packages" are an awkward in-between state that isn't usable the way a full package would be, the only thing it has forced people to do relative to being included in Base is now you need to do `using LinearAlgebra` to load it in downstream code. That might get fixed eventually so you can express that you depend on the LinearAlgebra 1.0 API to isolate yourself from stdlib breakage, but there's no way to do that today short of doing the work yourself to create a full versioned package with the same content.
Every language looks ugly to someone who doesn't need it ;)
I have learned to ignore the inconsistencies in the languages that I have to use, especially if it's for a paying gig. Otherwise I would go crazy! Every single language has them, I'm not kidding.
In case anyone doesn't know, the Julia convention is:
UpperCamelCase: modules & types
snake_case: variables and functions
This convention is shared, for example, with elixir (also FP Lang)
Also bang_functions! By convention, not enforced, indicate that the function may mutate one of its passed parameters. (Taken from Ruby's "be careful with this member function" idiom)
Ruby uses the same convention. (excluding macros, and adding question_mark_predicates?) I've seen C++ projects that adopt the same style. I don't see what's so objectionable about it.
Less so when you see strongly typed system which _you_ authored which is every bit as native as the 'Native' type system we sometimes wish other languages we use in practice had at all.
Well, in Julia it's an incomplete expression (Y is a variable, % is the infix operator for remainder, and # a line comment (the $ is used for string/command interpolation, but is commented out).
Given that some of the characters in the original were italicised, I think that there were probably some stars in there that Markdown ate. My question wasn't really what operation it performs or tries to perform, but rather what abakus (https://news.ycombinator.com/item?id=17473616) meant by comparison with lower_UPPER_CamelCase.
