Julia: Request for not deprecating `isimmutable`

[stefan-m-lenz]

I would like to request that isimmutable is not deprecated in Julia 1.5.
It makes of course much more sense to have a function ismutable than isimmutable. But since the function is already there and people are using it (including me) it would just be nice to still have it for backwards compatibility. Would it be so bad to keep the function isimmutable in addition to ismutable?
In my opinion, it is not a good practice to deprecate so fast as Julia does it at the moment.
With the rapid release cycle of Julia, it just costs much work to update everything.
I would request that backwards compatibility is valued more, especially if it costs almost nothing as in this case.

[Keno]

The function will stick around throughout the 1.x cycle for backwards compatibility reasons and depwarns are disabled by default. You shouldn't have to do anything until 2.0

[StefanKarpinski]

Out of curiosity, where did you get the idea that isimmutable would stop working in a 1.x release? I feel like the compatibility guarantees have been pretty clearly communicated, but perhaps there's something misleading somewhere?

[oscardssmith]

I think it's probably worth noting that things that are deprecated now won't be removed until 2.0. the point of deprecating now is to it so new development doesn't use it, so there is less churn when it is removed.

[StefanKarpinski]

Moreover, deprecation warnings are now off by default, so the new policy is to deprecate things that we want to remove in the future since it will not affect people unless they explicitly ask for deprecation warnings.

[stefan-m-lenz]

Thanks for clarifying this.
I did not read it anywhere that immutable would stop working in 1.x. I just read the 1.5 release notes. There it says that isimmutable will be deprecated in 1.5. I haven't read anywhere the guarantee that all deprecated features continue to work in all 1.x releases. So I just assumed it could be gone earlier.

Another point is: As a package developer, I don't want my users to be bothered with deprecation warnings. So already this is a reason for me to update.

It is new to me that deprecation warnings aren't shown any more.
May I ask: If they are disabled now, where is it documented how I can switch them on again?
For development this would be useful, since I don't want to use deprecated stuff in new code.

I have already filed an issue for another thing that was deprecated, which looked totally unnecessary to me and it was not clear how to upgrade: https://github.com/JuliaLang/Pkg.jl/issues/1724

In my opinion, backwards compatibility is very important (also 1.x vs 2.x) and it should only be broken if really necessary. Are there any guidelines when you deprecate stuff? I don't see the benefit in these two deprecations that justify losing the backwards compatibility.

[JeffBezanson]

It is new to me that deprecation warnings aren't shown any more.
May I ask: If they are disabled now, where is it documented how I can switch them on again?

This is mentioned in the release notes. the --depwarn command line option will do it.

[JeffBezanson]

I don't see the benefit in these two deprecations that justify losing the backwards compatibility.

Presumably 2.0 will be different enough that such changes will pale in comparison. Plus such minor changes are easy to fix automatically (https://github.com/apps/femtocleaner).

[stefan-m-lenz]

OK, thanks, that clarified your view on deprecations for me.

Presumably 2.0 will be different enough that such changes will pale in comparison.

Anyway I wanted to express that I personally think that it is not a good idea to change Julia too much on the language/API level. I think most users care about speed and working packages. The latter has become increasingly better since 1.0 but I would say it is still not really good. The release of 2.0 will be certainly another blow back with respect to working packages. If users aren't warned about deprecations and they accumulate over several versions, this is likely going to exacerbate this problem.

[StefanKarpinski]

I feel like I’m getting mixed messages here about whether you want us to deprecate things before 2.0 or not.

In any case, here’s what we’re going to keep doing: everything that what works without warnings (using official APIs) on 1.x will continue to do so in 1.(x+1). We will, however, “soft deprecate” things like this in the sense that they will be deprecated but they will keep working and people will only get warnings about them if they ask for them.

There will be a 2.0 release at some point. It will not fundamentally change how people write Julia code and most things will keep working, but it will include breaking changes that are necessary and worthwhile. There will be a transition plan.

There doesn’t seem to be anything concrete to address for this issue, or am I missing something?

[elextr]

There are traditionally two communities for a programming language, the developers who write software using the language and that development is their goal, and the users who just want to "do stuff" with that software.

Developers have been the traditional customers of programming languages, and they care about deprecations and want to know about them as soon as the alternative is available, so they can plan a smooth transition without huge spikes of work at major version changes.

For Julia those two communities overlap significantly, AFAICT a large proportion of the community develop in Julia solely for the purpose of doing stuff, and this may be the source of the mixed messages.

For the overlap part of the community, deprecations are not exciting signals to move to newer, better features, they are annoying interruptions to the end goal of "doing stuff". And so they want deprecations to be silent and new features and performance improvements to cause minimal disruptions to backward compatibility, although of course to greatly improve performance and ease of use :)

But of course there will be changes that are not backward compatible and old features need to be removed. The practice of gathering them all into major version changes is a practical mechanism to limit the number of times that major changes are forced on developers. But it does also cause maximum disruption because of that.

A practical step is to maximise the overlap between deprecated features and their new replacements to allow time for transitions to be effected, and perhaps reverse the default depwarn setting to be on at some reasonable time before the major version so the issue is raised to users and/or add a mechanism to provide "deprecated function removed" errors for removed functions for a version or two after the major release.

This isn't prefect, user/developers may skip versions, and so may not see the deprecation warnings or errors, which IIRC happened at the 1.0 change where the previous version with lots of deprecations was skipped and the warnings missed.

That only leaves new features that _cannot_ co-exist with existing features to be block modified at major version changes, and these should be minimised, for example functions with incompatible semantics should always change name.

Summary:

1. overlap deprecated features/functions with their replacements as long as possible
2. add an easy way to provide "deprecated function removed" errors after the major version
3. minimise changes that cannot overlap with their predecessors
4. be prepared for complaints anyway because their is this conflict between evolving the language and just "doing stuff" with it

[end thesis]

[stefan-m-lenz]

Thank you for your elaborate comment, @elextr
My initial point was point 3 from above: "minimise changes that cannot overlap with their predecessors".
I wanted to raise this issue because I think this point should be taken more seriously into consideration. (In this particular case and in general in Julia development.)
Of course it is an urge to clean up stuff that isn't as nice as it could have been in the first place. ismutable makes more sense as isimmutable, I totally agree. But it makes the language experience worse if stuff is removed that just worked fine. I can't see why both functions can't coexist.
It is one sign of maturity (in a language or in life in general) to be able to live with some decisions you made instead of running away if they don't look as nice any more.
In this sense, I would like that the spirit of Julia development gets more mature. I am also concerned about the future of Julia if there is not more focus on the people who just want to "do stuff". Even if R syntax is rather creepy, R is very popular just because the language and most packages are stable and simply do what they're supposed to do, even if you don't marvel at their sofware architecture. It's not the way to get more users if you remove features and make packages less reliable with this.

[oscardssmith]

To me this is a really clear one to deprecate. Note that this doesn't fall under condition 3 since any code since 1.0 can use ismutable. Furthermore, this is a type of deprecation who's impact is very minimal. If you see a deprecation error that says to use ismutable instead of isimutable, it is really obvious which lines you have to fix in your code. As such it is at most a 5 minute distraction even in a massive code base.

[StefanKarpinski]

I can see both sides. On the one hand, it doesn't really matter if we have both ismutable and isimmutable. Who cares that there both the positive and negative forms of this predicate. On other hand, adding one more name that's completely redundant is pretty pointless and this is very easy to fix automatically or manually. I also don't expect much normal Julia code to use this function. Doing something different for mutable and immutable values is definitely a code smell.

[mbauman]

ismutable is also already available in Compat.jl so you can be living in the future — even on 1.0. It's quite clear that we'll need very good tooling and support around the 2.0 transition, but this is one of the easiest cases to catch.

One way in which this is actionable now is in the wording of deprecations like this in NEWS.md:

https://github.com/JuliaLang/julia/blob/6443f6c95a0e62d5c58f70176c7a4da03fb21107/NEWS.md#L111

Do we want to make this not quite as scary? Or more obvious that it's a hint about what will happen in 2.0?