Because my mind works serially, and Julia doesn’t force me to vectorise. One of the reasons I like it.
1 Like
You don’t need to vectorize to use foreach styles.
3 Likes
Actually, it’s quite unfair to compare traditional OO languages to Julia, since people in C++/Python community are much, much more experienced programmers than those in Julia. They receive professional CS education, so they already have deep understanding in OO world (I think most CS students have taken a course called “C++ Object-oriented programming”). Many C++ programmers know single dispatch by method table, memory allocation (constructor/destructor,smart pointer) and other underlying implementation details, to achieve the best performance. Python/Ruby are OO languages which are quite easy to use, but the native performance of these languages is bad. People don’t pay much attention to optimizing these OO things, since this is not the main bottlenleck (dynamic typing is). Also, I think Python developers need to know some advanced things like metaclass and decorator. These things are also not quite well-documented and require deep understanding of Python’s OO hierarchy.
What I want to say here is that, writing high performance code is actually hard in every language. If performance (and safety) are not a concern, multiple dispatch is strictly better and easier than single dispatch. Since single dispatch is a restricted form of multiple dispatch, there is no difficulty to migrate from an OO language to Julia. Recent tendency in programming language design also reflects that OO techniques are slowing fading out. More and more language prefers interfaces (typeclass) + generics + specialization, instead of class+overload. And many C++ numerical codes nowaday looks more like Julia than like other traditional OO languages (for example,C#) due to the massive use of templates.
Only when performance is demanded, these OO things get complicated. In the ray tracing example quoted by you, runtime dynamic dispatch is the bottlenleck and unavoidable. To avoided unnecessary allocation caused by abstract types, we have to do union splitting or mimic single dispatch. While the former is automatically done by the compiler, the latter one is not quite easy. In C++ this is done by playing pointers (both function pointers and object pointers), so we basically need to do the same thing in Julia, which is ugly and unsafe. In C++ manipulating pointers and references is also ugly, but is at least safer than in Julia because compiler has some static checks for that.
While it’s undoubtedly that single dispatch is harder in Julia than in OO languages, we have to keep in mind that modern OO languages are not pure OO languages, they are actually muti-paradigm. Before the widespread of generics, how to implement Iterator interface and container type in an static OO language without abstraction cost is a problem. OO people at that time really sucks at implementing such things. It’s not just "by writing your class hierarchy and (virtual) methods per class ". Nowadays it’s possible to achieve the same things in OO languages, but requiring more concepts besides OO.
3 Likes
Yes, but that and similar threads discuss the problem of dispatch when dealing with containers with abstract types, and there is no simple and easy solution to that. Yet, I still miss the demonstration that faster solutions can be implemented in other languages. The only attempt on one of such threads, in Java using OOP, resulted to be much slower than the alternative in Julia that avoided runtime dispatch. In Julia the run-time dispatch and the allocations become transparent and we get obsessed in solving them, but it is not completely clear that they do not happen (or what are the trade-offs) in other languages.
1 Like
This may hold for other programming languages too. Generally, in order to read a book, it is helpful to know about its existence, and then somehow obtain it (the library may be an alternative to buying a copy).
Julia is hardly an outlier in this context.
What I like most about multiple dispatch is that 90% of said OO techniques can be just forgotten because solutions flow naturally from the language. You hardly see any Julia code defining an AbstractFactoryVisitorBridgeCompositeDecorator.
19 Likes
Sorry, I don’t get your point here. Of course having more experience and training will make you a better programmer. If your argument is that on average Julia users are less experienced (due to a younger language and less training in e.g. unis) and therefore write less optimized code then of course you’re right. But my point was that it seems to take more knowledge to write optimized code in Julia than in C++, as even some form of “baby-C++” can give you reasonable performance, where it seems easier (don’t have numbers) to fall off the fast paths with Julia due to, say, type-instabilities or other causes for unexpected allocation. But then again, C++ is more strict type-wise so you are forced to deal with typing-related challenges earlier in the process, before your code even compiles.
Decorators indeed come in quite handy, but mostly you just end up using them and don’t have to write them yourselves (but the latter isn’t that hard). Meta-classes are probably written and used (or even understood) by a very small group of Python programmers, certainly the vast minority.
But that focuses only on dispatch, which is just part of what OO provides. As the thread you participated in shows the issue of code structure (which is fairly straightforward in OO) is harder to migrate, when taking into account performance consequences.
Exactly, yet it isn’t a major performance bottleneck in C++. Pretty much all raytracers/renderers I know follow the same style of class hierarchy, with a class per shader/material type and do run-time single-dispatch for a common set of methods, plus use a shared set of class attributes.
Fine, C++ is not a pure OO language, but you can use it and the STL with only minimal knowledge of generics and iterator protocols.
I’ll add a C++ port of the test code used in that thread, for comparison.
1 Like
The point here is that the people who write C/C++ have already much more knowledge than people in Julia community. Even when facing the same problem, C/ C++er will find out the solution (or work around) more easily than the average Julian. But it doesn’t mean working in Julia and writing optimized code is harder or requires more knowledge C++er doesn’t have.
Using iterator and STL is easy in C++, but adding your own one is not easy…I think the whole point is that developing new library in Julia is much easier than C++ without too much loss of performance. Sometimes to retain the lost performance, we need to write ugly codes that interact with the internal of Julia. Raytracer is one good example that require playing pointers in Julia to perform single dispatch and eliminate allocation. Still, I think this is much more pleasure than programming in C++…
1 Like
Those are just weird claims without any underlying proof or numbers.
For me, I came to Julia after 30 years of programming experience (even more, but lets say professional experience). I did it all. Just because Julia is young it doesnt mean the Julia community is only about young beginner programmers.
Just stick to your point and don’t claim something you can’t proof.
This python-julia- which-d…-is-longer makes people crazy and I find it just boring.
12 Likes
This could actually be an interesting study. Have two groups of students, both without C++ and Julia experience, introduced to one of the two and let them program a certain task that requires performance. See what comes out and how they experience it.
I really wish at this point I enjoy programming in Julia as much as I do with C++. It just will take more effort to get into the more complex pieces of Julia in order to become more fluent. Ah well…
But it doesn’t mean that Julia community is only about young beginner programmers.
C++ and Julia have different audiences. Of course you can find experienced Fortran/C++ programmers and even PL experts and compiler designer in Julia community (I already came across some of them). For me I know type theory and have programmed in multiple programming language. What I mean here is that many scientists know less than those CS people for some professional problems, for example, they might have no idea what is memory allocation and why it’s critical for performance. But it’s hard to imagine that a C++ programmer doesn’t know such things. One example is that I came across a people in the thread quoted by paulmelis who has programed in Fortran but has no idea what is single dispatch in C++.
I do the claim because I have observed many quite negative responses in Chinese Julia community and on Zhihu (a Chinese forum like quora), though things do become better now. This is quite different from what I see in the discourse here and Hacker News. It has quite some threshold for those people who only know R or Matlab or have limited CS knowledge, many people try, fail and finally give up, and complains on the forum. For example, people sometimes come across performance regression caused by closure, but have no idea what happen and then blindly optimize their program. This kinds of thing really need some deep understanding of Julia, but we really don’t have so many Julia experts there.
Of course this is my personal observation, not a complete survey. To avoid further misleading, I will edit my previous answer.
4 Likes
I think you said that there are a lot of people trying Julia, and somehow failing, and then complaining about that in Chinese forums. Was this about correct?
Of course I can’t know what actually happens in forums I’m not a member of, but it sounds they’re stressed that they didn’t get Julia as fast as they believed they would. The reality was harder than their expectation. I do get that. I have a lot of CS knowledge, many languages, many years. Julia is not trivial to learn if you want to learn it well.
Maybe attending more mainstream Julia forums would be a good idea for them? Google translate will probably produce good enough translations that communication is possible if English language is a problem.
I have a similar background and similar experience with Julia. Can you pinpoint what in your estimation makes Julia harder to learn than other languages, say C++?
In my estimation Julia is a lot easier to learn than C++. My first serious C++ project (eventually growing to more than 20,000 locs) was really painful. I spent days in the debugger. Not fun.
In Julia, I haven’t needed a debugger yet, and I am a lot happier with the extensibility and legibillity of the Julia source.
Edit: It was actually 50000 locs. What resources (esp. time) could have been saved by employing Julia instead!
9 Likes
If Discourse can be access without a VPN in China , certainly a good idea. (I don’t know the situation)
If you are interested in knowing what kind of Julia topics appears on Zhizhu, here is a link
It will appears to me that most of the questions are “How is Julia compared to other languages ?” or “What is the future of Julia ?”. (I don’t use Zhizhu for Q&A search, maybe someone can correct me)
Serious question: would you say that your prior experience with C++ helped or hindered learning Julia?
Oh, interesting: I would say that it definitely stood in the way. My first Julia projects were quite afffected by my C++ biases.
1 Like
I have a similar feeling for myself, but I can’t quite pinpoint what it is that’s hindering (apart from the obvious tendency to think in OO terms).
I think that because Julia users mostly come from imperative languages, Julia’s code is often written in an imperative style. This results in messy interfaces that mix up semantics, mutate internal state, and are generally harder to understand.
I wonder if Julia can somehow do more to encourage programs to be more functional and less “OO”.
In my opinion the way that C++ shoehorns its users into particular ways of thinking about data and its structure so that it fits C++ implementation models.
1 Like
What you observe is not a difference between young/unexperienced and experienced. What we see here is the difference between software developers/engineers and users.
It happens a lot here on discourse.
There is the data analyst, the bioinformatician, financial analysts, particle physicist and so on, I would say, those are the users, who need a tool to fit their purpose. They have used python, R, Matlab and other tools, with great success. But they are not interested in memory allocation as long as it isn’t needed for something to achieve. Those users don’t use C++ or Java. If they have performance problems they use Fortran or C to build a small library to implement critical tasks.
And there are the software engineers. They know all details about OO and memory leaks to avoid, and so on. They have used C++, Java, C#, UML, C, Agile Development and so on, to build enterprise applications and mobile apps and whatever you like.
Software engineer and Data analyst, programmer and user, those are the two poles, we encounter here a lot. Of course with the complete spectrum in between and one person can be all of this at once more or less.
Julia fits into both with a good part more to the data analyst/user side for now
Julia still misses some parts to be more attractive for the pure software engineer. Hopefully those gaps can be closed sooner than later. Python will not achieve this in my opinion. Python clearly is the tool for the data analyst and the system administrator (on linux like systems). Some exceptions do exist, of course, but a medium to large, perhaps commercial, system will not be build in python. Julia currently tries to be the new tool for the data analysts, which I think, it does well, very well, yet in a juvenile state. But the real power of Julia is much broader and deeper. All these details about performance, how to achieve it, avoid memory allocations, 0/1 based indices, difference to python or C++, how to do OO (why should I?) and whatever, are just in the way of the bigger picture, which is: Julia is can be more productive by order of magnitude compared to C++/C/Java and on the same time compete in performance with C/Fortran. Productivity and Performance! That’s what everyone needs, the programmer and the user, and it’s what is meant, when we say, Julia solves the two language problem.
It’s 2021 and we are still discussing 0-based and 1-based indices? No, that’s not what is important, it never was.
10 Likes