Julia learning materials, how to make code work?

Maybe I’m too picky and pedantic, but when I work thorough learning materials on any programming language and some code doesn’t work due to some breaking changes I feel frustrated or worse. I believe that I’m not the only one. I also feel quite intimidated by Julia manual, not because it is hard to read, it isn’t, but because it is quite long and has so many additional resources mentioned along the way.

After some thinking I decided to make some experiment, to try to work through some learning materials and find how much code is now broken. Maybe we can learn something from this, about how long learning materials remain up to date? I hope so, but we will see how this will end.

I now try to work through Computational Thinking | MIT 18.S191 Fall 2020 and first problem arrived at 14:26 in video Working with images in Julia | Week 1, lecture 3, when we should use function decimate to produce new picture of Philip the Corgi with part of the pixel removed. At this moment (January 2024) calling this function throw an error, saying that it is undefined. Pluto Live Docs can’t find any object whose name starts with dec.

At 15:07 in the same video we have colvolve(poor_phil, blur(2)), blur is now undefined variable.

At this moment I still didn’t find which functions should be used. Outside writing your own, that do the same work.

1 Like

That is a course from 2020, so there’s no inherent expectation that the material would stay relevant for long after. If the course has been repeated since, there likely is updated material that is likely less available on the internet for people who don’t pay for a degree. Minor revisions to v0 packages like Images.jl are allowed to make breaking changes, so if you really want to follow an outdated course, you’ll have to at least find out the major.minor versions of all v0 packages and major versions of the other packages and Julia at that time. This would be easy if a Project.toml with strict versions and perhaps Manifest.toml were provided, but I don’t immediately see them in the Github page linked by that video, so they didn’t seem concerned with posterity.


Just to make it even more clear:

Jan 2020 we had Julia 1.4, Jan 2024 we have Julia 1.10, this is not a problem of Julia making a breaking version (only when/if 2.0 arrives that Julia may break old code). The problem here is you not being able to replicate the exact package versions used in the course. If you were able to do so, then most probably the code would run with Julia 1.10.


Hello, as others have said, the issue is likely in some packages that had breaking releases.
Let me just comment that I believe by now most of the most used packages (on top of course of Julia itself) are now stable, so while unstability was a recent problem in the Julia ecosystem, it is much less by now…

1 Like

Well, if the course author would have provided a Project.toml file with the versions he used the problem would not exist. So if you publish learning materials, please do that.

Shameless advertisement: Try the freeze() command of PkgHelpers.jl.


If a package is gonna stop providing a function, it’s helpful if they

  • give a deprecation warning that says what to do instead
  • put the change in the changelog (NEWS.md)

Not all packages are in the habit of doing this, unfortunately.


It maybe me griping, but since griping can be a good thing, I allow myself to do it, at least for a bit.

I should stated explicitly what you have said, that problem is not with Julia per se, but with external packages. But at the same time, we shouldn’t miss that currently concept of “external packages” in Julia is taking peculiar turn. At JuliaCon 2023 it was announced that Julia standard library will be detached from core Julia, so you will be allowed to use Julia 1.10, with standard library from version 1.12. Currently, I don’t know any other language that turn it standard library to “package as any else”, just “coming bundled with Julia”.

On the other hand, in contrast to other languages that I know, like C, C++, Python or Go, it is quite hard to find learning materials that DOESN’T use external packages. It is no brainier that learning materials for C use only it standard library, but from my expirience it is quite typical case.

I see all of these as consequences of core Julia ideas: extensible and composability. Both detaching standard library and “I need external package X so much” seems to steam from this two great features. It just have some side backs when it comes to learning materials.

1 Like

My another grip. Basics of Arrays in Julia, 1:33 line A3 = string.(rand("🧼❓😉🦅🍚🍵", 3, 4)) |> pretty. It does not work out of the box now, maybe it never was.

Function pretty is defined in the next Pluto cell as

	max_length = maximum(length.(M))

	dv = "<div style='display:flex:flex-direction:row'>"
	HTML(dv * join([join("<div style='width:40px; text-align:center'>".*M[i, :].*"
	</div>", " ") for i in 1:size(M, 1)],
			"</div>$dv") * "</div>")
After few tries I cannot make it work properly. Maybe I just make a typo.

I cannot said it better. I hope that PkgHelpers.jl will succeed in it aims and gain popularity.

1 Like

That isn’t remotely true. There are materials that use the base language and standard library to teach the language itself, and there are materials for teaching particular packages or sets of packages for real-world applications. It really does not surprise me that third-party libraries show up in a course covering a bit of CUDA-accelerated image processing and data-driven climate modeling. If you study these topics in any other language, you’ll use third-party libraries too.

You should find other learning materials. Now you know an absence of a project and manifest file or a frozen project is a good indication that the code was never intended to be shared outside a particular audience and a particular timeframe (in this case, MIT students in 2020 when there was a large need for remote learning). This isn’t unique to Julia, there are plenty of outdated content in other languages that didn’t share all the required versions, sometimes not even for the base language, because they only cared about demonstration, not reproducibility. That’s not always a bad thing, threads asking for help in code at a particular time don’t really need to be reproduced long after. However, one of the hard parts of teaching or self-learning is filtering out all the outdated junk to get to the reproducible or most current materials. Updated documentation is easy to find, but it’s actually fairly rare that documentation can serve as an introductory tutorial, just as handing someone a dictionary is a poor way to teach them a natural language.

I think that these packages cannot have breaking changes either. Am I wrong?

In parallel, I think learning material could start using explicit package versions (using Images@v1), such that most copy/paste would be working longer.

FWIW, subsequent to the materials being developed for the course, Pluto added the functionality to store the Manifest.toml and Project.toml in the notebook file itself. This feature was added to Pluto in 2021 IIRC. It’s a key goal of Pluto to ensure reproducibility.

Also, the more recent iterations of the course do have full dependency information stored in them (example notebook).


If you search in the course material on Github, you will find the decimate() function defined in one of the homework exercises (hw4.jl) as:

function decimate(img, n)
	img[1:n:end, 1:n:end]