How is Julia Like Python?

New to Julia
1

I’ve been spending quite a bit of time learning Julia at a high level and have to say I’m excited and the prospect of what it is and what it can do. The benchmarks are impressive and the stated goals are hugely impressive.

But I draw a huge issue with the part where they say they “…want something as usable for general programming as Python…”.

I started my big data analytics life in R and while it is a robust, proven language with a strong following, it’s not for me. In short, the language has limited scope and the API is unreadable to an untrained eye.

Enter Python. I fell in love immediately. It’s beautiful, succinct, has a very broad, extensible scope, and easily readable to anyone that doesn’t know Python. They may not understand how to write the code but generally speaking can follow what it’s doing.

But when I see what the code base looks like for all packages I’ve seen, including base Juila (I had lots of links but new users are restricted to two in a post) my soul dies. At the end of the day, it’s R. How is Julia anything like Python? I may be missing something and hope I am (which is why I’m here, looking for constructive feedback.) I care very much what my code looks like and there’s definitely no accounting for taste. Does Julia offer a clean kind of code base like Python that I just haven’t seen yet?*

The point is, I want to love Julia. But if it’s got a gross syntax like R and Matlab, then there’s no way I can.

And where is the name spacing!? I’ve had multiple collisions already in just a few example I’ve run.

I do really appreciate the feedback.

*Yes, I understand you can run Python modules straight from Julia. But if that’s all I’m doing, then I’m just going to stay in Python.

3 Likes
2

It is unclear what you dislike about it, but since the syntax is unlikely to change in major ways in the foreseeable future, it’s pretty much take it or leave it.

https://docs.julialang.org/en/v1/manual/modules/

If you are interested in learning Julia, I would suggest that you read the manual, then ask specific questions on this forum. But if you want to keep programming in Python, that is fine too, it’s your choice.

12 Likes
3

Note, that you can solve more complex problems at higher performance in Julia, meaning, that high performance code can start looking pretty ugly in Julia - which is mainly just because there isn’t really any way around it. What stays beautiful in that case is, that in Julia, you at least have the choice to program very close to the hardware!
I think for code in Base and some packages, it would make more sense to compare them to the C/C++ code that most Python packages drive on, and then decide which one looks more maintainable :wink: You will never see any Python code that is doing the kind of high performance work that Julia is doing.

I also find it a bit odd, that you say I fell in love immediately. It’s beautiful, succinct, has a very broad, extensible scope, and easily readable to anyone that doesn’t know Python but then judge it by some packages… Of course, there will always be situations were people will produce ugly code in any language.

Btw, I have exactly the same impression when looking at 100% of the python packages I interact with - haven’t seen a single one so far, where I walked away with a good impression of the code :wink: I’m always surprised, how anyone can write ugly python code like that and call python beautiful at the end of the day :smiley: But I think this is getting very subjective at this point!

15 Likes
4

I generally find that Julia code is simple and elegant compared to python, which I don’t find elegant at all, particularly the lack of end and the excessive namespacing.

Matlab code is, despite the many weaknesses of the language, far more elegant than Python. Have you ever used numpy and compared the code to Julia or Matlab? Numpy is incredibly awkward-looking.

Generic Julia code is just incredibly elegant, and you never need any of that ugly input parsing.

Multiple dispatch facilitates much cleaner and nicer code, no more “if this class do this, else do that”.

14 Likes
5

I would suggest having a specific use case in mind and just try solving the problem with Julia. When trying to solve your specific problem you could post specific questions in this forum to get some help and make your code more performant/idiomatic. You will probably have to spend some time using and getting to know the language if you want to seriously evaluate it.

This might allow you to better evaluate whether Julia is a good fit for the type of projects you are interested in and for you personally, as opposed to just comparing syntax. At that point you could also compare it to Python in the specific context relevant for you.

5 Likes
6

FWIW, I started out with python, and loved it. I started using Julia because I needed to do more data analysis and everyone in my field uses R for that, but I absolutely detest R syntax.

Now, 4 years later, julia seems more elegant than python in every way. There were a couple of things I liked about python that were different in julia (a key example is checking for empty stings/lists with if my_list:), but in every case, I’ve come and to realize the julia designers made the better choice. Now, when I absolutely have to code in python, I pine for julia.

Can you give examples of code where the same thing, expressed in Julia and python, looks better in python?

That said, I think @Tamas_Papp and @sdanisch are spot-on. If you like python, and are productive in it, that’s great! Stick with it. If you’re challenged getting the performance you need, and that’s why you’re looking at Julia, the better comparison is with C. Or if you want to do stats/data and are comparing to R, well, sounds like you and I agree there :grinning:

9 Likes
7

Okay. So really I should

  1. Take a deep breath,
  2. Spend some more time understanding the basics of Julia and
  3. Spend more time focusing on the advantages instead of the disadvantages.

I do scientific computing for a Fortune 10 company and lead the initiative to simplify/streamline and onboard existing associates that have a skill in Excel and that’s about it.

In an effort to skate to where the puck is going, I’m exploring enhancing what our organization uses and Julia seems like the answer due to all the wondrous praise it’s been receiving.

I’ve had much success getting people on boarded with Python because they can just look at it, read it and pretty much know what’s going on.

When I started exploring and learning Julia myself and after running into all the different notational conventions (e.g. function bang, macros, .+, ./, the piping notation for chaining operations, and the extended use of Unicode characters), I got very frustrated because I guarantee no one is going to go for that.

4 Likes
8

I think a concret example where Julia complexity is useful is this multivariate Normal code in scipy :

You can see it’s full of condition to handle the different cases (the covariance matrix can be provided as a full matrix, a vector of variances, etc).

The same code in Julia looks better in my opinion, because of the more powerful type system, you can just list the different cases :

e.g the line

MvNormal(μ::AbstractVector{<:Real}, σ::AbstractVector{<:Real}) = MvNormal(μ, PDiagMat(abs2.(σ)))

is equivalent to Python’s :

elif cov.ndim == 1:
    cov = np.diag(cov)

Yes the Julia one looks more scary, but it actually simplify the logic because you don’t need all the if’s. And it’s only superficially scary, once you’ve understood the type annotation syntax it’s pretty easy to read.

9 Likes
9

Take the code from this issue I just looked at:

https://github.com/SciML/diffeqpy/issues/59

Here’s the solution in Python:

m1,m2,a,V=1.,1.,1.,1.
mu=m1*m2/(m1+m2)
param = [a,V,mu,m2]
tspan = (0., 1000.)
jul_H = Main.eval("""
function H(q,p,param)
    p1, p2 = p
    q1, q2 = q
    a, V, mu, m2 = param
    (p1^2+p2^2)/(2*mu)+V*(exp(-a*q1)-1)^2+V*(exp(-a*q2)-1)^2-p1*p2/m2
    end""")
q1,p1,q2,p2,=0.5,0.,0.,0.    
p0=[p1,p2]    
q0=[q1,q2]
prob=de.HamiltonianProblem(jul_H,p0,q0,tspan,param)
sol = de.solve(prob,de.VelocityVerlet(),dt=0.01)

Now just get rid of the string eval for Julia:

using DifferentialEquations
const de = DifferentialEquations
m1,m2,a,V=1.,1.,1.,1.
mu=m1*m2/(m1+m2)
param = [a,V,mu,m2]
tspan = (0., 1000.)
function jul_H (p,q,param)
    p1, p2 = p
    q1, q2 = q
    a, V, mu, m2 = param
    (p1^2+p2^2)/(2*mu)+V*(exp(-a*q1)-1)^2+V*(exp(-a*q2)-1)^2-p1*p2/m2
end
q1,p1,q2,p2,=0.5,0.,0.,0.    
p0=[p1,p2]    
q0=[q1,q2]
prob=de.HamiltonianProblem(jul_H,p0,q0,tspan,param)
sol = de.solve(prob,de.VelocityVerlet(),dt=0.01)

and hey look now it’s working Julia code. Seems like a pretty straightforward change to me. That function body could’ve been written the exact same way in Python as well, it was just evaling to Julia to speed it up.

6 Likes
10

OP I think that if someone is coming from excel, they can still definitely learn Julia. Perhaps I am too far removed from learning to code, but I think the things you describe actually make julia more easy for beginners than python.

  • Function bang, i.e. select!(df). This tells the user that the function is modifying its argument. The user doesn’t have to experiment with the function to realize it does this or read through documentation or source code.
  • Broadcasting, i.e. y = x .* z. This is also explicit, as it tells the reader that the function is being applied to every element of an array. You don’t have to wonder a function is being applied to a whole array or not.
  • Piping notation. Python’s version of piping is x.foo().bar(), so it’s hard to argue that that’s better than other alternatives. If you are referring to syntax like foo ∘ bar, note that this isn’t really standard syntax and you don’t have to use it. Plus dplyr %>% piping in R is very common and seems to be popular for people coming from excel.

Additionally, note that you don’t have to teach the entire ecosystem at once. If people are coming from excel you might just want to teach them the basics and how to work with dataframes. Then they can import excel (or preferably .csv) files and stay entirely within the DataFrames ecosystem.

3 Likes
11
  • function bang - actually pretty simple convention, but you are not obliged to use it
  • macros - there are some quite practical and easy to use macros like @show . Those who come from Excel don’t need to write macros of their own, as they are unlikely to write decorators in Python, too
  • piping notation - actually easy to understand and to use, but you don’t necessarily need it
  • Unicode isn’t π better than np.pi math.pi scipy.pi ?
2 Likes
12

For those who want to learn Julia as their first programming language, the book ThinkJulia could be a good starting point.

4 Likes
13

Enter Python. I fell in love immediately. It’s beautiful, succinct, has a very broad, extensible scope, and easily readable to anyone that doesn’t know Python. They may not understand how to write the code but generally speaking can follow what it’s doing.

I disagree. My first programming language was JavaScript and when I started searching for a language for my data analytics needs, I settled on Julia. As a result, I’ve never coded anything in Python and I was recently sent some Python code by a colleague who asked me to review/validate it and I found that I couldn’t make sense of what was going on. I had to have him walk through the code with me line-by-line before I could understand what it was doing.

IMHO, it’s really about what you’re used to. If your native spoken/written language is one that is based on a Latin alphabet, then looking at something written in Cyrillic script may seem very strange and foreign. The same thing happens with programming languages - if you are used to looking at Python code, Julia code may seem very foreign and strange (although in many cases I’ve found that it actually looks quite similar).

5 Likes
14

I’ll also make a stab at addressing these:

  • Function bang: not really syntax, just a convention, like using underscores i python for private fields, or special methods, or using CamelCase for type names, and snake_case for functions. It’s just a nice and informative convention.
  • Broadcast dots, .+ etc: This is maybe my favourite thing about Julia. A super-easy, explicit, universally general way to vectorize (in the Matlab sense) all functions and operators. You see a dot, you know it’s broadcasting over a container. If you see numpy.cos(x) in Python, can you tell what’s going on? Or having to wonder what happens when you throw an array at a function? In Julia, put a dot on it, and it works! This feature I will actually officially label ‘genius’.
  • Macros: you don’t need them, write all your code with no macros!
  • Piping, do you mean |>? I’ve almost never used that, so I have no opinion, but I don’t see anything particularly bad about it.
  • Unicode characters: You don’t have to use them at all. You can write all your code without them, and Base code doesn’t use it much. Most uses I’ve seen are like π for pi, cosθ instead of cos_theta, things like that. It is just fantastically nice for mathematical code, but you can ignore it completely, if you prefer, you wouldn’t be the only one. There is absolutely nothing in the language that requires unicode symbols.
4 Likes
15

@jasheldo, I came to Julia via R, but I didn’t decide against R. I make my decision which language to use problem-oriented.

How is Julia anything like Python?

I have never understood the intention of Julia to be an R or a python either. But in the end, based on Logan’s post, I hope that Julia will continue to be a programming language and community for everyone, which for me means that it will become even more user-friendly.

3 Likes
16

The beauty about Julia for me is that when I started I had little to no understanding of what happens “under the hood”. I, like you, basically only used R and Python and thought that while some packages are fast, vectorization is cool etc., I had no idea of why some pieces of code ran faster than others. It was largely a hit-and-miss with accumulated wisdom and tricks from stackoverflow and hours of experimenting.

With Julia, the guide is as clear as can be about why something works well and something doesn’t. Only about 10 months into Julia, I understand (largely) what happens under the hood (in fact, you can even see it with specific Julia macros), parametric types, multiple dispatch etc. If you had asked me these things with my R and Python background, I would have said “too advanced for me to know, I’ll ask my friend who did CS”. With Julia, I have felt that I have been able to cross those boundaries without much hesitation about what’s “too advanced” or what’s not. It’s a really cool feeling to see the interaction between your code and what’s going on “under the hood” – Julia is a beautiful language that allows you to do that!

23 Likes
17

@Gunter_Faes Just a small off-topic post to say that the community standards explicitly ask not to play on the name Julia to imply it is a person you could date - you might want to consider editing your post.

And on topic: clearly Julia is like Python because everyone’s favourite Python feature is comprehensions, and Julia’s comprehensions are pretty good, too!

6 Likes
18

Julia is like Python in that it’s high-level, dynamic and easy to write simple scripts with. In terms of syntax and linear algebra, I always found it much closer to Matlab, which is the language I’d compare it with. But I guess Python is just more popular, so that’s the comparison that’s more likely to be made.

2 Likes
19

@nilshg, thanks for the hint, have I removed…!

And on topic: clearly Julia is like Python because everyone’s favourite Python feature is comprehensions, and Julia’s comprehensions are pretty good, too!

… Interesting statement! :thinking:

2 Likes
20

Clearly this is a matter of taste. Python syntax is adequate in most cases, but I can’t stand numpy and pandas. I much prefer doing vector and data frame manipulations in R (and Julia) than in Python. R may have a steeper learning curve than Python, but the effort required to learn the language pays off. Similarly, Julia probably has a steeper learning curve than Python, but the payoff is a language that is, in my opinion, both more powerful and more expressive than Python.

2 Likes