I would note that this “lack of privacy” allows Julia to solve the “expression problem” — you can add new methods to existing types, and new types to existing methods, in a composable way (seamlessly extending existing code).
Adding new Base.print methods for a new datatype (although normally you should extend Base.show, not print!) is not type piracy and does not create composability problems.
Note that σ² is not a good example of Unicode support in Python, because super/subscript numbers are not allowed in Python 3 identifiers:
>>> σ² = 3
File "<stdin>", line 1
σ² = 3
^
SyntaxError: invalid character in identifier
Julia allows a much wider range of Unicode identifiers than most other languages, because most other languages with Unicode identifiers follow the much more restrictive UAX#11 guidelines on what characters are allowed and how they are normalized.
Note that the best stuff is just being introduced to Julia with 1.3: being able to compose and nest parallel constructs is a major development that should make it easier to write pervasively parallel algorithms with much less effort.
I agree that the tools in the R ecosystem are mature and rather polished, and work just fine for their advertised purpose — R is very user-friendly for “embarrassingly parallel” applications like MCMC.
[self plug] In case you’re looking for a less technical or instructional talk, and one that is more geared for people with less CS background, check out this one:
Yes, my presentation was centered around how Julia solves the Expression Problem, reusing material from Stephan’s “Unreasonable effectiveness of multiple-dispatch” talk. I’m pretty sure those concepts reached home with my audience. Nonetheless, some were uncomfortable with the possibility of type piracy.
I think this fear of type piracy is not really rational, but it does seem pervasive with software engineers, right up there with people having strong feelings about static type checking and types being attached to variables not values. That’s probably why Java has so many and such refined mechanisms for denoting and enforcing privacy. And why if you google for people ranting about Python, these kinds of things bubble up to the top.
There are many many different ways to shoot yourself in the foot while writing code, and the less obvious ways can be the worst. Encroaching on type privacy is something that people are clearly viscerally aware of, and so they tend to do the right thing without the language disallowing it; in other words you really need to go out of your way to engage in type piracy. On the other hand, failing to solve the Expression Problem produces an insidious, long-term tech debt situation where people’s code cannot be reused as much as it could, so package ecosystems tend towards large monolithic code-bases, whereas in Julia what grows organically are smaller packages that capture well-known mathematical and programming abstractions, that users and downstream package authors can mix and match.
I bet the tradeoff is clear for most julians, and I agree that it’s not really an issue in practice, but I wonder if forbidding type piracy would help with adoption by appeasing those who It scares.
Generally, I don’t think that changing a programming language targeting the preferences of those who don’t actually use it is a good idea.
Unless one uses a language, it is very hard to assess the importance of various trade-offs. Avoiding type piracy is a good practice that Julia users just internalize early on and don’t violate unless there is a good reason do to so. In practice, this is not something that causes problems.
I agree, it’s generally good product design process to first focus on getting it really right for your core constituency and then circle out.
I think going forward, this is the answer I’ll give software engineer types asking about features that would help them feel warm and fuzzy about using the language: PackageCompiler and type checking /linting and possibly forbidding type piracy and adding a formal-ish interfaces are on the compiler team’s TODO list; they are just not at the top of the list right now. In the mean time, it’s still a hell of a language.
The compiler work priorities are very well thought out, and generally hit everything I could personally hope for, in the right order. Might as well point people to it.
which has been around since the dawn of time and I am not sure it is going anywhere — I imagine people realized that formal interfaces would not add that much value, compared to other neat features which are the focus of current attention.
For type piracy, there is
which would make sense but I guess it doesn’t address the concerns of a C++ programmer, since it is just a warning, and would not show up in non-interactive use.
Even though software engineers used to C++ & friends may find some parts of Julia puzzling or inadequate, I think it would be misleading to say that implementing these things is a priority in any sense.
I think that it would be fair to say that Julia programmers just rely on other tools (CI, TDD) to deliver quality software, and people interested in Julia should just explore it as it is. Julia is not like some half-constructed building with random things falling on your head all the time, but a comfortable place for productive work.
@kolia, great article
I’d love to link it in my talk, but at the moment, there are quite a few cells not runnable (e.g. julia code in a python runtime)… Do you plan to go over it, fix those and publish it again?
They’re on the radar although I’d say those are not compiler issues so much as language design issues. We’re kind of on a pause from language design work because there’s so much other stuff to do without adding features to the language for a while. But there surely will come a time when compile times are snappy and you can easily compile entire applications and we can start to think about new language features again.
Note that there are 2 python cells containing python code, in order to compare for loop speed between a naive julia loop, a naive python loop, and the numpy equivalent.
There are also 2 cells that error by design, to show what errors Julia throws when method lookup is ambiguous or finds no match.
If you are still have issues, can you specify which cells so I can fix them?
The main other thing I could add is a section on multi-threading, though this is already too much material for 1h.
I was just looking at the notebook cell runtime, which was correct and hadn’t noticed the ‘Python in Julia’ name. That explains why the syntax highlighting was off, thanks for pointing that out.
(Btw, you probably know, is there a faster way to change the syntax highlighting mode? Only way I found to do it was to copy-and-paste into a fresh Julia cell and delete the old one.)
I cleaned the presentation up a bit (changed a couple of cells that shouldn’t be run into julia Code listings) and added a subsection on multi-threading.
@sdanisch is forking other people’s nextjournal notebooks supported/encouraged?
(Since this should bump the thread to the top of Discourse: if anyone else has any materials to suggest for a why-Julia talk given to software engineers, I’d be most appreciative!)
