If we are to compare Julia with natural languages, Latin is an interesting example. While word ordering was mostly subject-object-verb in spoken language, the order doesn’t really matter, what’s most important is the case of nouns (thus effectively making Latin a free word order language). In this regard, Julia is similar to Latin: what is important is the type of the arguments, with the caveat that in Julia the order does matter, so the correspondence isn’t complete.
Some modern languages, like German, have cases, so speakers of these languages may find it familiar to pay attention to this feature.
In addition, there do be a few languages with verb-subject-object ordering, like in Julia (and many other imperative languages, actually).
I don’t really buy the “subject comes first” claim, not even in English.
If I look at the sort of code I write, and what I am actually telling the computer to do, it is more along the lines of “sum the columns of this matrix”, “plot this function” or “print this statement”. Verb coming first is certainly not unnatural when you are speaking in the imperative. “I love Julia” is the most natural in English, but that’s not the kind of thing you say to a computer, except perhaps in the source code comments…
Just as an extra data point, it has been statistically shown that starting with the verb is the least common order across natural languages (which doesn’t mean PLs should necessarily follow suit). From an analysis using WALS data (emphasis mine):
There are 1,377 languages that are coded for word order in WALS and 35.5% of them have SVO word order. Meanwhile only 8.7% of languages start with a verb—like Welsh, Hawaiian and Majang—so cross-linguistically, starting with a verb is unusual. For what it’s worth, 41.0% of the world’s languages are actually SOV order.
But do those numbers apply when considering only sentences that are instructions, or which are otherwise imperative in nature? I would think that verb-first should be much more common in cases like that.
Actually, Julia doesn’t disallow that notation at all (it may be looked down upon though!)
You can accomplish that by making a type that has fields of type Function, creating an instance of that type called I,
and then call the function in field love.
julia> immutable MyObject ; love::Function ; end
julia> I = MyObject((x)->string("I ❤ " , x))
MyObject(#1)
julia> I.love("Julia")
"I ❤ Julia"
If this is a major factor for someone, I am not sure that they need to pick Julia. The language has so many great features, which combine to an extremely powerful toolkit. Surface syntax is not where the interesting things happen.
For someone coming from another language, trying to recreate familiar features is all too natural. Surface syntax is what our eyes and fingers are used to, so that’s the first thing on the list for many people. IMO it is more productive to accept the this part of the language and start using it as it is, and focus on features that really distinguish it from other ones.
Oh, I hadn’t seen that, I particularly love @jeff.bezanson’s response.
However, truth be told, using what the rest of the world considers “Object Oriented” (classes with single dispatch) anymore, feels like programming with one hand tied behind my back, compared to using Julia “as intended”.
I agree heartily! In fact, I think Julia being a bit “weird” or “different” for programmers coming from Python should be seen as a Good Thing™. All too often I’ve seen converts from one language to another write the first in the second. That is, for example, I’ve seen C coders move to Ruby and never use classes except as glorified structs. Their code ends up being an imperative “bag of functions”, and as a consequence they end up missing out on Ruby’s best features.
There’s the same risk in migrating from Julia to Python Python to Julia. Yes, the transition is a bit uncomfortable, but instead of seeing each hurdle to overcome as an annoyance, I think programmers would be better served seeing these hurdles as opportunities to re-evaluate their assumptions about how code should be structured.
On the other hand, when moving from one language to another, if there are features lacking in the new language that you had in the old language(s), that can be a spur to try to recreate them in the new language, and that can be very positive (like Julia not supporting anything but 1-based arrays originally, but now with Tim Holy’s OffsetArray type, you have the same capability that Fortran 90 has [which is much more flexible than just having either 1-based or 0-based])
(I had to do similar things when I moved from Scheme & CLU to having to write in (pre-ANSI) C for a living, I ended up making a way of having the equivalent of try/catch/finally, which then helped me make the core of the database code a lot more reliable).
I actually learnt Julia, and then had to pick up Python for a project at work. Needed some couch time after that… (oh, actually it went more-or-less ok.)
Yep, after I wrote that, I realized that many people might get forced into it (just like I had to start programming in C instead of Scheme & CLU) I should have said, people who voluntarily migrate need their head examined (although people who are forced to may need a shrink afterwards, for PTSD! )
Guess somebody should call my shrink. I find both Julia and Python to be very nice languages, and that the richness of Python’s ecosystem often makes it a good option.
You don’t find the access that Julia provides to that ecosystem via PyCall sufficient?
But, that isn’t really the case I was talking about, which was migrating from Julia to Python, whether voluntarily or forced, which is a quite different kettle of fish from picking and choosing which tool is best for whatever task is at hand (which I believe to be a mark of a good programmer)
)