Stewardship: the Sobering Parts


#1

I watched Brian Goetz, Java Language Architect at Oracle, talk about Stewardship: the Sobering Parts
You may have seen this already because it was published on Nov 22, 2014

But it helped me to temper my wild expections for new features in Julia.

It reminded me of the joke “Why was God able to create the world in just 7 days”. Answer: “He didn’t have to worry about legacy.”


#2

I did not watch the video, but my expectations remain untempered :wink:

I think that five factors may make it easier keep Julia evolving:

  1. language constructs like @deprecate for phasing out old features/semantics,
  2. tooling like FemtoCleaner.jl that can make upgrading much less work,
  3. packaging a lot of the standard library functionality out of Base,
  4. a more or less implicit social contract that you get a great language, but it is very much alive and keeps moving, with the implied benefits and costs; and the benefits are always so great that you keep upgrading,
  5. zero or low-cost abstractions allow writing programs which are much easier to update.

Also, when you think about it, quite a few drastic changes already trickled through the language without a major problem (arraypocalypse, taking various transposes seriously, iteration protocol redesign, various iterations of broadcasting, the rise and fall of Nullable, or just renaming the keyword for composite types to struct. Any of these would have quickly generated an angry crowd of programmers with pitchforks in some languages, but the Julia community was mostly welcoming these as each was an improvement.


#3

While this might look to you like this (in retrospective), keep in mind, that that was in a version 0.X language where breaking legacy was assumed to be happening. And having Compat update and FemtoCleaner running didn’t look like to be a non-effort solution.


#4

Love this phrase :joy:


#5

I mean on the part of the user (who, in this case, was a package developer). Of course I recognize and respect the work people have put into these tools, with the result of making everything so easy for their users.


#6

The only reason for that is it was a pre 1.0 language. I still haven’t caught up to 1.0 from 0.6 yet for my code and I know more than a few people who had high hopes for the language but lost interest after all of the 0.4 to 0.6 changes. Nobody wants to constantly update their code. Lack of backwards compatibility is a terrible thing, especially in the scientific community where people’s main job is not coding.


#7

So is lack of ability to evolve.


#8

No one has to. Older versions of Julia are always available, and keeping a Manifest.toml should allow reproducing the exact same environment.

Also, freezing the language core or imposing excessive backward compatibilty is does not mean that updating will not be necessary if one wants to keep up with recent development, as libraries will typically move on. So the key part of the puzzle is not to avoid updating, but to make it easy.