This. Julia's combination of human-readable pseudocode-like code and speed makes it perfect for these applications, and seems to be driving adoption.

Also not seen before degree of code reuse.

I'm using Julia (because of the hype) to prototype out some numerical optimization stuff. There is a million functions for reshaping multidimensional arrays. The syntax is uncannily like Matlab: retrieving the last element of an array with `[end]`, indexing into a collection with an array of booleans, element-wise versions of operators prepended with dot, etc.

However, I keep running into niggling corner cases that kind of make Julia's promise of a powerful, extensible, yet intuitive type system less convincing.

ME: I want to write a custom getproperty() for Tuple!

JULIA: No.

ME: I want to broadcast over the fields of a NamedTuple!

JULIA: Not allowed.

ME: I want to get a view, not copy, with `@view M[m:n, r:s]`, but also get the ability to specify a default for out-of-range indices, like `get()` allows.

JULIA: I'm afraid I can't let you do that.

As sibling posts have pointed out, you can do all of those things:

1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it.

2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideration, but the language lets you do this easily as well.

3. The https://github.com/JuliaArrays/PaddedViews.jl package implements exactly what you're saying Julia won't let you do.

If anything, Julia errs on the side of allowing you to do too many things! There are very few things the language really won't let you do.

I meant literally this:

  julia> (x = 1, y = 2) .+ (x = 1, y = 2)

  ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved

This doesn't really seem like a legitimate complaint. You want some particular pet behaviour, and claim it is impossible to achieve. When someone points out that it is in fact possible, you are unhappy that someone else did not anticipate and implement it pre-emptively...

Do you also expect your 'custom getproperty' (whatever it might do) to have been predicted and pre-implemented by someone else? And do you also expect arrays to 'just know' what value or behaviour you are looking for whenever you index out of bounds?

Stefan's point was that you are free to commit type piracy and make this do whatever you want

  julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!"

  julia> (x=1, y=2) .+ (x=1, y=2)
  "my custom method!"

And as the phrase "reserved" in the error message indicates, it will likely be given a meaning once all the ramifications of doing so are worked out and the best choice of meaning is decided upon. If you're impatient and don't want to wait for that, define it to do what you want. Your code won't even break when it is given an official behavior since your method will overwrite the built-in one.

But this is exactly the kind of thing I called a bothersome corner case. Needing to redefine a global function in order to use fairly intuitive behavior is not great developer experience.

When things like this are left undefined, it's not to intentionally annoy you, as you seem to be taking it. It's generally because there are two or more reasonable possible behaviors and which one is correct hasn't yet been determined. In this particular case, there are subtleties because named tuples can be seen as ordered collections of values and as named associative structures. Deciding that kind of thing takes a lot of time and effort. If you feel that there is a preferred behavior that broadcasting over named tuples ought to have, it would be helpful to post that on GitHub.

It's not generally recommended but you can do a custom getproperty() for Tuple.

  julia> function Base.getproperty(x::Tuple, f::Symbol)
       if f == :a
         return x[1]
       elseif f == :b
         return x[2]
       else
         return x[3]
       end
       end

  julia> (3,4,5).a
  3

Edit: Okay, why am I getting randomly downvoted here?

For the last thing, is this what you want? https://github.com/JuliaArrays/PaddedViews.jl

There may be other packages or methods for doing the other things you want. I’d think that broadcasting over a NamedTuple would iterate over the key => value pairs, but I haven’t tried it.

Thanks for the good find!

Looks like vectorizing over NamedTuples is explicitly disallowed. Probably you can still vectorize things over the keys and values separately, along with some helper functions, but it is a bit annoying. Looks like the reason was due to questions on whether iteration should be over values or pairs.

Indeed, that is precisely the decision that must be made. Neither one is obviously correct. And once a decision is made and goes into a release, it cannot be unmade — we all have to live with it forever.

> Due to its conciseness, Julia has mostly replaced showing pseudo-code on my slides.

This benefit is really underappreciated IMO — for a lot of "science" applications, the core part of the program should be readable by people who don't program in the language. In research papers, by people who want to understand the fine details of your algorithm, for example.

Julia gets closer to "executable pseudocode" than I would have thought possible.

I would add,

Fourth, the ability to effortlessly drop down several layers of abstraction: Pointer types, all packages including Base are written in Julia and can easily be extended or patched on the fly, homoiconicity, seamless integration with BLAS and LAPACK.

Small aside. Do you use the beamer package for your slides?

Yes. Beamer LaTeX with the Metropolis theme and Fira Sans as the main font.

Those are beautiful slides.