What happened to Base.colon?

Publishing 0.7 (nearly) parallel to 1.0 was ugly hack which ignore meaning of deprecation period (period is about time, right?).

Telling somebody (who we don’t know) to use 0.7 when trying some code (for example from blog) could be felt as strange behavior.


PS. I was trying to checkout 0.7 and grep @deprecate macro to find list of deprecations which could help to answer similar questions. Unfortunately it is not easy.

Maybe it would be better to collect deprecations in toml (or json something similar) files in the future? It could be used by code-generator, News.md generator, help-generator, linters etc.

Sorry, of course you’re right, that’s always been expression syntax—so the depwarn is a little confusing. You just need parens, (:)(3,5).

And if the OP was about overriding it, then it’s:

julia> import Base: :

julia> nothing:nothing
ERROR: MethodError: no method matching -(::Nothing, ::Nothing)
Stacktrace:
 [1] (::Colon)(::Nothing, ::Nothing) at ./range.jl:7
 [2] top-level scope at none:0

julia> (:)(::Nothing, ::Nothing) = "hello"
(::Colon) (generic function with 14 methods)

julia> nothing:nothing
"hello"

Telling somebody (who we don’t know) to use 0.7 when trying some code (for example from blog) could be felt as strange behavior.

I don’t understand this at all. The point of 0.7 was to help people change their code, but not everyone got the message. If someone comes to you with a problem, how does providing them with the systematic way to figure things out on their own constitute a problem? What, exactly, are you proposing as an alternative?

5 Likes

They are written up for every release in the NEWS.md. You can just search that for deprecate.

1 Like

This is an argument that you can make, ok.

This makes no sense at all.

1 Like

Publishing 0.7 (nearly) parallel to 1.0 was ugly hack which ignore meaning of deprecation period (period is about time, right?).

Publishing 0.7 nearly parallel to 1.0 was amazing. This is the best kind of deprecation I have ever seen. The deprecation period is from publication of 0.7 until there is some critical 1.0.x or 1.x bugfix or feature you need that fails to get backported to 0.7.

My main minor gripe is the naming of versions, because obviously a lot of people did not get the memo (this question pops up a lot). Also, a lot of new people started on 1.0 before the ecosystem transitioned (you get the publicity for “1.0” only once).

Second, linux distribution support is lacking; for example archlinux used to ship 0.6 only, and now ships 1.0 only. I’d have prefered a similar story to python, where it is clear that different versions are completely different languages and you get all relevant versions you want to install to cooperate (there want to be julia10 and julia06 and julia07 binaries and a symlink /usr/bin/julia to whatever version I want as default). pacman -Syu breaking my code was not nice. I don’t know how other distributions (julia pro? conda? debian? cygwin?) deal with that. I don’t know whether julialang influenced that or provides guidance for distribution, but that could have been handled better (and yes, sure, building it myself and placing symlinks works, but this defies the point of having a distro at all).

There was intention not to copy python’s path here. :slight_smile:

And Arch is doing it right in standard way.

First of all I would change wording. Instead of Use julia-0.7 when you have questions like this it would rather say something like it could be useful to use julia-0.7 when you have **more** questions like this.

We could also tell people that useful info they could find in History.md on github.

But if you really want (*) that people have test it in 0.7 maybe we could bundle both version into current install binaries. (or add choice to install both in single step)

(*) - BTW I think it is not a good idea…

Although I agree that many people seem to have missed the v0.7 memo, I think it is important to realize that v0.7 is really only relevant for people who have already used Julia before v0.7, that is in a phase where it was common knowledge that new Julia versions will certainly break things.

Those people aren’t new Julia users. I think it’s ok to treat them like rather established Julia users and just point them to the relevant information without too many words. I don’t think that’s rude in any way but rather efficient.

2 Likes

I don’t really see the point of telling people that they can read more about a project’s history in (surprise!) HISTORY.md.

All these things are obvious/standard, or can be found with negligible effort. Simply restating them leads to infinite regress: from then on, you have to think about the possibility of people not finding the meta-documentation where you pointed them to the documentation.

I think it would be best for future discussion about similar topics if people who had a hard time finding some information despite making a reasonable effort came forward and talked about their experience. This would allow us to improve the documentation where needed.

Sometimes Captain Obvious is helpful, and RTFM Section x.y can be the reply people need.

But the julia 0.7 hint, HISTORY.md hint and the “global scope loops” hint should probably all go into the “think about code formatting” default box on discourse.

If people ask similar question do you think that they read that file? (I don’t)

There are people who starts to learn language by trying examples. And you really could find some in older version.

For example chess board from @jonathanBieler where newbie has to “fix” linspace… (I don’t think that installing 0.7 in that case is best idea)

I agree.

I only partially agree with this argument that has been raised several times. Other than old users, new users that come from a Matlab background will have (bad) surprises that v0.7 warns about but v1.0 just erros (linspace and repmat come to my mind but I have crossed with other situations).

AFAIK there was no explicit intent to warn Matlab users specifically. This is just accidental and covers a subset of Matlab idioms that were used in Julia initially. Matlab users should benefit from the writeup of differences.

3 Likes

@Tamas_Papp is right. Python also doesn’t warn you in a nice way about either of those functions. Different languages have different function names and syntax.

It’s more the group of MATLAB users that used Julia before v0.7 and saw “oh all my functions are there” who is now complaining about the straight errors.

Mind you that I’m talking about things that have worked for > 5/6 of the language age (quite a bit more than initially).

But they were never part of Python. They were part of Julia, and new users get confused when they try to run example code found online.

There might not exist a quick fix, and it will fix itself in time. Or maybe there just needs to be some clearer instructions on the Downloads page. Right now there is, in fact, some text explaining when using v0.7 might be useful. Perhaps that text should just be moved up and highlighted.

I don’t think developers of a language are responsible for external tutorials and example code (except that provided in the documentation). It’s on the authors of those tutorials to specify the version used during the tutorial.

I agree - this would probably solve most questions of “why doesn’t this example from place y work anymore”, but as far as I can tell those are not the majority of questions about this (at least here on Discourse). As far as I can tell, the number of people updating older code and asking about why it doesn’t work anymore far outweigh those just newly learning julia (there might a be a large hidden figure here though). Those would certainly also be served well with a more direct message of “hey, use 0.7” on the download page. Maybe even something like

Updating code from before Julia 1.0? Use Julia 0.7 for deprecation warnings!

directly below the “Download Julia 1.0” button would be a nice addition.

2 Likes

And I don’t see how ‘responsibility’ is relevant. I’m just pointing out why version 0.7 might also be of interest to new users.

Well, asymptotically they have worked for a fraction of the language age that will converge to 0 :wink:

I have a somewhat pragmatic approach: given that developer time is scarce, I would rather see it focused on things other than keeping an implicit history of the language in Base just to be able to guide users about an upgrade path after the deprecation period has expired. Especially since we have amazing tools to update code.

Of course, if someone wants to maintain a parallel version of Julia with nice deprecation messages going back to ancient versions, they are welcome to do so (it is conceptually trivial, just a lot of tedious work). This could of course live in a package. Ultimately all of the discussions about what the language should do in these cases boils down to someone putting in the work.