Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracing PyPy) and staying single threaded than removing the GIL. At least if you're choosing threads for performance gains.

Think of it this way: A single threaded C++ or Rust program can do more work per second than a hypothetical GIL-free CPython with 64 cores...

This is not correct. Pypy is actively developed.

Numerical code is always written in numpy which can drop the GIL.

Seems like it would be better to call Julia from python.

There's pretty big differences in usage between multimethods in Clojure and Julia. I've used both a decent amount. All functions in Julia are multimethods by default. If you don't use type annotations, a new method will be generated whenever you call the function with new argument types. This explicit type specialization is a very important part of why Julia can have such a consistently fast JIT despite its dynamicity.

Errors from missing or conflicting methods tend to not happen much in practice.

https://docs.julialang.org/en/v0.7.0/manual/methods/

You seem to be suggesting it’s not fair to make superior comparisons to python until Julia has mainstream popularity. That’s rubbish. Python is much less expressive.

Python does have excellent libraries and it fits many people's mental model of programming, but not mine. I still use it often. However, for a dynamic language, it is simply not very expressive. It has no multi-line lambdas, OO syntax that I find a bit awkward, and some other limitations. These can be seen as advantages, since they enforce the "there's only one way to do it" philosophy, but that doesn't work for me.

Wish advocates of all new languages stuck with this principle.

Criticisms of languages should not be taken as criticisms of their creators or users. I don't see anything wrong with saying "Language X does Y better than language Z in my use cases."

Languages are toolsets and programmers are always looking for appropriate tools for a given task. It seems crazy to demand that people not be able to talk honestly about their experiences using a given tool. Python doesn't have feelings, it won't be sad if you don't like it.

Hmm ... I remember when Perl was king and Python was the shiny new thing. I watched Python supporters belittle Perl as "line noise" and other quite silly descriptions. They were all proud of "there is only one way do to it" versus the linguistic Perl way of "there is more than one way to do it."

I am experiencing something of a sense of schadenfreude over defense of Python against a newcomer. 20 years on, Perl is still in widespread use, still unbeatable for its growing use cases. I don't wish to speculate where Python will be 20 years from now. I do know that Fortran will still be around. That's about the only sure thing.

That's a good point that it doesn't have the direct homoiconicity of Lisp, but it is not buried deep, since we have full access to the underlying AST as just an Expression type. In practice, this makes macros much less painful than in other non-lisp languages. This means that macros are used all the time, and idiomatically. The most proiminent non-lispy language with a macro system that I can think of is Scala. Macros there are a nightmare, and so tend to be only used in library code that really, really needs them.

This is why the language creators usually avoid using the word 'homoiconic' because every time one uses that word there's a finite probability of being bogged down in an incredibly uninteresting semantic argument.

Instead, people prefer to say that julia code is just another (tree-like) data-structure in the language and it can be manipulated at runtime with functions or compile time with macros or at parse time with string macros and now with Cassette.jl[1] we can even manipulate the form of code that has already been written and shipped by other packages all with first class metaprogamming tools. It seems to me that even if Julia is not 'truly homoiconic', that we seem to get the touted benefits of homoiconicity to the point that it seems like an unimportant distinction.

[1] https://github.com/jrevels/Cassette.jl

"Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps?"

Yes, sure. Julia is an interesting language, CS-wise. My only point, inasmuch as I had one, was that there are other languages out there that have those same features.

"If I want to get things done, I'd stick to Python for now though due to sheer momentum."

I tried python, because you're right, it has the momentum and is the obvious first choice for numerical computing after you've had your fill of Matlab. Unfortunately, for a lot of the code I write, speed matters. In large part I'm prototyping my own numerical methods, not totally relying on numpy/scipy. The last time I tried python for numerical code development I ended up with a routine that was two orders of magnitude slower than it needed to be. I rewrote the entire thing in Julia, with little to no effort towards optimizing it, and it was immediately 50x faster than python and within a factor of two of what I needed. I put a couple of days of effort into optimization and I got it down to 2-3x faster than required.

You could argue that I should have gotten better at optimizing python, and maybe you'd be right. I'm no python expert. But in my limited interaction with the python community, the answer to faster python seems to be, at the end of the day, to write the parts of the code you really need to be fast in C and call them with the python FFI. Which is what numpy does, if I understand correctly. Whereas I can write that same code directly in Julia and it's generally fast enough.

For a lot of use cases speed doesn't really matter. But for robotics (my field) or self driving cars or machine vision or a lot of other embedded applications, it does matter.

this was interesting to me:

https://www.youtube.com/watch?v=Gh578e98qAk&t=567s

Does magma compile down to highly efficient code?

Sure!

But why should you have to care, why not just sum(range)? Or

    @threads for i in eachindex(object) 

and let the details about how many cores be written once, correctly, elsewhere?

Your rant comes down to a distaste of +1s in certain situations. My point is that Julia's emphasis on arrays allows you to compose ranges with mathy operations in very powerful ways. You're concerned about composing APIs that take endpoints as arguments — I say you should just accept a range in the first place!

Say I have an index `idx` into a very large array and I want to select a symmetric window of `N` indices before and after that index. In Julia:

    A[idx .+ (-N:N)]

In Python:

    A[idx-N:idx+N+1]

Python cannot even index lists by ranges (or other lists). And if I go out of bounds, well, it'll happily just give me back a list of a size I didn't expect.

Heck, in Julia I can even easily determine what the OOB behavior should be. It's an error above, but I can easily change it. This, for example, will ensure no indices go out of bounds by repeating the final endpoint as necessary.

    A[clamp.(idx .+ (-N:N), 1, end)]

Sometimes you want to work in terms of the fenceposts, and sometimes by the length of the fence. There certainly are cases where 0-based offsets are nice — or even arbitrary offsets. In those cases we have OffsetArrays.

Holy Traits are used extensively in the standard library (for iteration and collections among other things).

Not many folks use the macros that those macro-trait packages define, but the technique itself is in widespread use throughout the core language and standard library. That's where it was first posited and implemented, in fact: https://github.com/JuliaLang/julia/pull/8432 (and see the link to the "trait trick")

Truth. See http://www.stochasticlifestyle.com/the-nonlinear-effect-of-c...

Instance methods are bound to a specific object definition, thus they can only be applied to instances of that specific object or its descendants.

Also in static languages, the set of available instance is closed and extending it requires approaches like extension methods now available in a couple of OOP languages.

Whereas multi-methods are dynamically dispatched taking into consideration the whole set of parameters, and can be defined after the fact. Meaning that they aren't necessarily written in the same module that defines the respective data structures, which opens the door to more extensible designs.

Taking the Alan Perlis' quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." to the next level.

Because not only can you define all those functions that operate on one data structure, they actually apply to the tuple made by the dynamic type of all parameters at call site.

Naturally it also might make it harder to follow what actually happens with a given method dispatch.

This is my insight from having gone through "The Art of the Metaobject Protocol" and dabbling with multi-methods in Clojure, so I might not be 100% correct here.

That OO concept is pretty much Simula specific, Lisp languages got influenced by the work done in LOOP and Flavours which lead to the design of CLOS, the origin of multi-methods idea.

Building on top of your remark, Julia's approach is more "call the visible implementation of this function that better matches the types of all given parameters".

And these are only two possible ways of doing OOP, there are a few other ways of approaching the ideas of writing extensible modular code with polyphormism.

Wouldn't it be easier to just use Jupyter and not use the Python-supporting stuff?

Just because Visual Studio supports Visual Basic doesn't mean I can't use it when I'm only interested in writing things in C#.

Given the historical precedent of Pascal, Ruby, Matlab and others, using `end` to close blocks is not exactly controversial or uncommon. 5 of the current top 20 languages on the Tiobe Index use `end` to close blocks versus 11/20 for curly braces and 1/20 for indentation. Most of the `{}` languages are C descendants: using `{}` for blocks is popular because C has been wildly successful, not the other way around. Using `{}` for blocks wasn't some brilliant language design choice that caused the success of C—it was a fairly mundane choice that happened to be made by a language that succeeded for entirely unrelated reasons and the syntax spread from there.

As to the benefits of not using `{}` for blocks, pairs of ASCII brackets are one of the most precious commodities in programming language syntax design. Wasting them on blocks is not ideal. For example, C++ was out of brackets to use for template parameters, and had to use `<>` instead—despite the syntactic clash with their meaning as less than and greater than operators. This has caused no end of parsing problems and irregularities in C++ and related languages and has only been made to work because they're all static languages with separate "expression context" and "type context" and inequality operators don't make sense in type contexts. In a dynamic language, there's only one context and you can't distinguish the use of `<>` as brackets from its use as inequality operators based on that. Julia uses `()` for function calls (pretty important), `[]` for array indexing (also pretty crucial), and `{}` for type parameters.

Using indentation is a fairly clever choice but not without its drawbacks. It causes lots of problems with cutting and pasting code. It means that your IDE cannot generally autoformat or autoindent your code for you. There are also many people who find the "trailing off into space" visual appearance of Python code unsettling and prefer the symmetry and closure provided by `end` or other block delimiters.

it's easier to read.

Because 'end' has a specific meaning in English, and that meaning translates well to ending a block. If you decide you want a programming language geared toward Spanish speakers, 'end' would indeed be gibberish (unless they also speak English), but 'fin' would not be.

You can certainly argue that '}' is language-agnostic and therefore a better choice, and I wouldn't disagree with you. But 'end' is by no means an arbitrary choice for a character sequence that ends a block.

Autogenerated code is very easy in Julia — there is no string processing at all. You can splice things directly into quoted code (working at the literal syntax level) or manually modify the `Expr` representation in a lispy manner (in which case there aren't any `end`s at all). Code generation is _really_ easy, thanks to its lispy inspiration.

Block delineation in Julia doesn't require the newline. You can just throw a ` end` at the end of the line. Often you'll see folks put the `;` line delimiter there, too, to make things super-clear (as that's generally how you delineate multiple expressions on the same line), but it's not required for an `end`.

And while it is indeed a little sad that you can't use `end` as a variable name, we make the most of it by using it to also represent the last index in an indexing expression like `A[end]`.

So, yeah, not a big deal at all, but very few of your detractions even apply in the first place. :)

You could reshape it (https://docs.julialang.org/en/v1/base/arrays/#Base.reshape). But if you're interfacing with libraries written with C interface you'd still have to subtract for both offset1 and offset2.

Historically 0 based is for low level languages. 0 based makes sense for C.

My issue is higher level languages Python, Java, C# there is plenty of things that just are complicated and doing arrays off 0 is one of them. Doing data science or statistics just makes it obvious that you have two different sets on numbers. 1 doesn't mean the same thing in every instance in your programming and the functional programming side of me hates that.

“Objectively preferred for me” sounds an awful lot like it’s subjective

A ton more people do high level programming, than low level programming. You guys build the tools and many more people use them.

that may be your impression, because you dont know julia's powerful, no overhead indexing abstractions yet ;) i also write lots of graphics low level code, and i couldn't be more glad that i don't need to do those error ridden indexing calculations anymore, since they're simply not needed... note, that you can also seamlessly create new array types that store 0 indices into other arrays - and because of julia's great composability, i can make them work with my indexing agnostic algorithms while being 0 overhead compatible with opengl's memory layout :)

>It's the difference between numbering the contents of the list (1 indexing), and measuring the distance from the beginning of the list to the start of the item (0 indexing).

The problem is that one is indeed an indexing (numbering the contents 1...X...N and asking for item X, customers[X]), whereas the other is not, but is used as an indexing (e.g. customers[5] is not getting the 5th item but the sixth).

>> I really do with the 1 indexing had stayed around, since I feel like it's more natural to say the 1st element, instead of the 0th.

It's not the 0th element. It is the 1st element and has an offset of 0 from the beginning of the array.

Not saying it's better or worse, but that if you change the words you use to describe it, you may find it easier to use.

To my surprise, I just learned that ranges in Rust don't include the end number which felt incredibly stupid from a conceptual point of view (python too). But is syntactically useful when doing:

for x in 0..len(my_array) {

My preference would be that a range include the end number and the language provide more python-like iterators and list comprehensions. I am aware that there is a library that provides more python-like syntax, but that doesn't change the oddness of ranges in either language. I guess I just need to remember that the interval is open on one end. Which brings to mind the notion of using [0..n] or [0..n) in a language...

The issue is 1 will mean different things. That should be a bigger issue than anything else. When you are doing math

1 + 1 = 2 always means two. When you are getting the 1 column we are getting the second column. This while makes sense when doing certain lower level programming this makes no sense with functional or higher level programming.

VBA actually lets you decide at the top of each module whether to use 0 or 1 based indexing. The default value is 0, but you can specify "Option Base 1" to change that.

There is an interesting note in the Wikipedia page for "Dartmouth BASIC" which says the second edition "also allowed arrays to begin as subscript 0 instead of 1. This was especially useful for representing polynomials."

Are they, though? The relevant functions in Enum all seem to be zero-based, for example:

    iex> [:foo, :bar, :baz] |> Enum.at(1)
    :bar

Not that it really matters anyway. Like with Erlang, in the vast majority of cases where I'd normally reach for querying a list element by index, pattern matching is the better / more idiomatic option. Compare:

    foo = list |> Enum.at(0)
    bar = list |> Enum.at(1)
    baz = list |> Enum.at(2)
    rem = list |> Enum.slice(3..-1)

with:

    [foo, bar, baz | rem] = list

Both give you the exact same values of foo/bar/baz/rem, but the latter is arguably more readable and concise, and entirely avoids the 0 v. 1 debate.

Interesting. Doesn't this solve the problem then for people who can't get into 1-indexed arrays?

Tabstops are really old concept and were never really a set number of spaces wide. Used to, you had physical stops on the typewriter that a tab would advance to.

So, that world was and is a long time ago. We just don't typically give a way for people to set tabstops in most environments, therefore it was chosen that tabs would advance a certain number of spaces.

Ok, but why should that influence a managed language with no pointers?

GOTO is logical when you look at machine code - that does not mean it is the best possible abstraction. There is a reason we use higher level languages.