I’m not sure what you meant by 8 / 9 months being faster than MATLAB as MATLAB version is released each 6 months (March and September).
I think you make sense in your writing and the efforts of the team is admirable, really.
But I think your response doesn’t touch the essence of what @bjarthur said.
If I understood him correctly, his saying is, don’t make backward compatibility a sacred thing.
Keep moving forward in a fast pace which makes each iteration, even if not backward compatible, to be easy to digest.
Namely, nothing is special in version 1.0, 1.x or 10.x.
Only keep moving forward in a constant pace of releases.
I’m not sure how I feel about it (Moreover, I have no cases to feel anything as I’m not a developer of the language) but it is worth considering.
Maybe a mild voice of dissent, but I find the breaking changes are starting to burn me out. I like regular releases like matlab, but I think Base vision for having less breaking changes is essential not loose more “casual” users that don’t want to have multiple versions of julia around, or have to constantly change older code.
I’ve just been through the process of updating a few things (notably DataFrames) to 0.7 and I have to say the process was much more painful than it was for 0.6. Some really fundamental things, in particular Array constructors, have changed. Of course I appreciate these changes because the Julia devs are definitely doing the right thing by trying very hard to make sure they have everything right in 0.7 so as not to freeze any undesirables into 1.0, so I’m not complaining.
It’s also worth noting that it tends to be much harder to create code that supports 2 different versions than it is to create code that supports just the latest version, and due to the special nature of 0.7 I expect most packages to neglect 0.6 completely, so in many cases it shouldn’t be as bad.
That said, I don’t think it’s realistic to expect changes of this magnitude to go smoothly in 2.0. After 1.0 I think serious compromises will have to be made for the sake of stability or it may harm the user community. As someone who has only ever done scientific programming and is usually happy to break things I don’t like this, but that’s just how it is.
I think your position is not uncommon. We’re trying to split the difference here and if we do it right everyone will be somewhat unhappy, with half of the people thinking that we’re breaking too many things too fast and half of the people thinking the opposite.
Waiting as long as Python (for example) between making breaking changes seems rather too long. We should probably do major releases every couple of years with tooling to help ease the process (and making sure it’s possible to support each pair of adjacent major versions at the same time).
Stefan, I agree with your description of the Python 2/3 transition. This is still a pain in the a55… In our collaboration we still depend on older software which requires Python 2 and even recent changes regarding the 2/3-compat can not make things work in our case. I am maintaining a core analysis framework and still need to take care of the Python 2 world since I need to wrap that old stuff.
Yes, Python has such a package too, called six and to be honest, it caused a lot of headache in the last years. Although they try to do their best to keep up with the glue code to attach to Python 2 and Python 3, they (have to) do some fancy stuff in the background which might be irrelevant for a small rot13-project but can be crucial in high performance computing. A small update/addition in six and suddenly your performance tests drop by 90%, halleluja.
I hope w.r.t Julia that Compat does not really affect the performance of the code, since I still have this six-trauma and to be honest, I have not used Compat yet in any of my packages. Of course, most of my code is not yet relevant for the public (as it is quite project specific for now), so I simply try to keep up with the bleeding edge. I also have not looked into the Compat source yet to see how things are implemented…
So all in all, I just wanted to say that the HPC Python community has definitely this six-thing in mind and they may be sceptical about using Compat
I find the experience very smooth, and did not experience any performance drop from Compat. Actually, I got performance gains when using it for the v0.5->v0.6 transition, since deprecation warnings are costly, but that was just gaining back what I lost
Python is a very different language — there can be a huge penalty to taking C library code and routing it through a pure-Python compatibility layer. Compat’s job is a lot easier.
I’m working productively in julia without a debugger. However, based on my experience with tools like PyCharm, which has a great debugger, I am working less efficiently than I would with an equivalently good debugger. This is particularly true given that julia stack traces don’t include variable values; they show only types.
Inserting print statements like I did when programming in C in the early 1980s is not efficient. The “real programmers don’t need debuggers” argument that has surfaced in these discussions from time to time strikes me as silly. Lots of people find debuggers very useful.
Grace Murray Hopper also gave us COBOL. By the “good enough for Grace” argument, that should be the end of language development, right? ;~)
I am not sure about this, but if you mean the contrast between the advice above (use Compat) and the recommendation to drop support for v0.6, I was wondering about that too.
I think both approaches are viable: if package authors want to support v0.6 for new features, and avoid backporting, then Compat is the right solution. OTOH if they don’t, then the version resolution system should take care of it.
