Thanks you guys for the responses. My personal opinion of Julia is that it is great and the main benefit over Python for the kind of work I do is “static types”, the wonderful language built-in capabilities and the unified package distribution, Project.toml is a great idea. My curiosity about OO is that I’ve seen large code bases in C and Fortran essentially creating their own OO dialects as they grow in size and complexity. My 2 cents is that it would be nice to have it in the language.
Sorry, I don’t see the connection between OO and programming in the large. Maybe you can elaborate?
IMO what matters for large codebases is compartmentalization of functionality into smaller units that one can reason about. It is true that some languages use OO (in combination with other things, like namespaces) to achieve this. Julia doesn’t, which is an intentional design choice. Multiple dispatch is more expressive than single-dispatch OO.
A concrete example could be helpful to focus this discussion.
3 Likes
My impression is that many people with an OO background seeing Julia for the first time think that the missing OO features are a show-stopper. However, I don’t think we see any such complaints from long term users. That could either mean that the OO-background-people left again or that the programming paradigm of Julia is good after all and there is nothing to complain. I’m pretty sure it is the latter.
Edit: So, my recommendation is to embrace Julia’s model (e.g. look at good packages) and see what you think instead of trying to port your OO habits to Julia.
6 Likes
Sorry, I don’t see the connection between OO and programming in the large. Maybe you can elaborate?
No problem. I was referring to the legacy of large extensible code bases scientific data interacts with (which Julia targets). Think of VTK, OpenFoam, MFEM, MOOSE, ParaView, Slate, the next generation of Scalapack, I can go on and on with this list. Their choice is to organize using OO architecture. Julia essentially implements the Fortran model that frameworks are moving away for better organization and due to the demands for new capabilities in a timely manner.
Multiple dispatch is more expressive than single-dispatch OO.
Yes, this is why I consider them complimentary/orthogonal concepts wrt inheritance. Inheritance allows reusability that multiple dispatch doesn’t. These are just different hammers for different nails.
A concrete example could be helpful to focus this discussion.
I provided an example in my first entry for get_type(curve::BaseType) , the mentioned alternatives mean that get_type must be implemented in all derived types, while with inheritance a single function is sufficient as every derived class is-a (inheritance) rather than has-a (composition).
Personally, I’m not a OO advocate myself just curious about the Julia roadmap on the topic (programming languages are tools at the end of the day). I’ve just seen over the years how many scientific frameworks chose OO as an organizational model (list above). If this is coming to Julia, it would be an easier sell, that’s all.
Thanks, good conversation.
@mauro3 It’s not my “OO” habits or my “OO”-background (people can have multiple paradigm backgrounds). I’d say I’m comfortable with Julia’s paradigm (reminds me of Fortran), but I also see the value of OO which many framework do see as well. Just providing my feedback based on what I see. You’re welcome to take it or not. Julia is a relatively young language, I think feedback from community users and good relations is key to its success in the long-run.
As much as I like Fortran (95), I think Julia is pretty far from it. I like the Julian way of writing code, much more so than OO, but I certainly took a bit of time to get used to it. Also, Julia is at v1 now, so large changes to the language are probably not going to happen.
Last, note that the examples you state above, except Slate, are all “old” (10+ years), when OO was still en-vouge. I think this has now changed quite bit. And it seems that in Julia it is much easier to write composable software than in many other languages, thanks to multiple dispatch: JuliaCon 2019 | The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski - YouTube
Anyway, I think you just need to develop a few 1k locs of code to see if you like it.
2 Likes
I am not sure I understand what “the Fortran model” is in this context.
Again, I don’t understand the what the issue is. It is possible to provide idiomatic interfaces in Julia to external libraries that are organized using OO. There are many examples.
1 Like
Well, yes and no. While well-reasoned suggestions are always helpful, the language is pretty well-developed at this point, so it takes a lot of investment in the language to make practical changes. Just suggesting that “OO would be useful” is difficult to do anything about since changing something seemingly small about the language has a lot of ramifications.
Because of this, the bar for changes is rather high. I realize that this can be frustrating to well-meaning people who make such suggestions.
Personally I consider it unlikely that Julia will ever go in the OO direction in the style of C++ & co, and consider that the right choice.
Note that this has been discussed multiple times before, you may find those topics interesting. Also,
1 Like
You’re right. My mistake, the scalability problem arises from the fact that each subtype must have the field. With inheritance this duplication could be avoided exploiting the is-a relationship.
I am not sure I understand what “the Fortran model” is in this context.
I was referring to modules, types and generic functions.
Again, I don’t understand the what the issue is. It is possible to provide idiomatic interfaces in Julia to external libraries that are organized using OO.
No issue at all. Just providing the reasoning that OO can be more productive in particular applications as it could avoid boilerplate to mimic OO that scales up quickly. Productivity is key in different industries that would like to give Julia a shot.
I am not sure I understand why one would want to mimic OO boilerplate at all in Julia. It is not idiomatic style, so of course it will be difficult. This difficulty is best avoided by programming Julia as intended.
I am wondering if you read eg
https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1
1 Like
Just suggesting that “OO would be useful” is difficult to do anything about since changing something seemingly small about the language has a lot of ramifications.
I think we are not reading each other. I wasn’t “just suggesting” I listed several frameworks in scientific computing that take advantage of OO, given that Julia wants to solve the two-language problem it could offer what those languages offer. I hope my feedback is well-reasoned.
Because of this, the bar for changes is rather high. I realize that this can be frustrating to well-meaning people who make such suggestions.
Thanks for your words, you are absolutely correct. I think people asking for OO (or other features) are well-intentioned and it is more of a business need (for productivity) when trying to introduce Julia (which is also an investment for users) in their own environments. While I don’t find it frustrating, I think OO would add value to many people advocating for Julia’s adoption in production environments.
Good question to add in the next Julia users and developer Survey, to see if that’s one of the characteristics that users like or dislike most. (Unfortunately, it’ll be harder to measure the opinion of people who left.)
3 Likes
Sorry, I still don’t understand this line of reasoning. In particular,
-
A lot of frameworks indeed take advantage of OOP. It is unclear whether this happened for historical reasons (eg the software was started when OOP was considered the best solution), practical considerations (they wanted to use C++, which means buying into this kind of OOP).
-
Even if C++-style OOP is the right idiom in C++, this does not mean that it is the right choice in Julia, which is a fundamentally different language with other features that allow you to organize code equally or more efficienly, but using a different approach.
-
The “two-language problem” is having to use another language to write fast code. I don’t understand what it has to do with OOP.
To put it mildly, the link between OOP and productivity is yet to be demonstrated across languages. It is of course true that to be productive in an OOP-based language, you use OOP. But people have been skeptical about this since the enthusiasm about OOP peaked. This lead to the design of a lot of new languages in the past two decades which don’t do C++-style OOP on purpose. Julia is one of them.
5 Likes
I think the central point is that the absence of class-based OOP and structural inheritance are not instances of missing features, but examples of deliberate design choices. They are actively and intentionally avoided.
Whether these decisions are sound is of course open for debate, but the feeling of many Julia users is that Julia offers more compelling patterns, and that introducing classic OOP would be detrimental to the composability which is typical of Julia packages, and not so typical for OOP-based packages.
5 Likes
To put it mildly, the link between OOP and productivity is yet to be demonstrated across languages .
I’d take a step back a claim that C++ doesn’t force you to use OOP, it’s optional. Productivity doesn’t come from OOP itself, but from the options the user has to address a problem, C++ is mutil-paradigm, so it is the projects using C++ that decide what’s more productive to them, not the language itself. Many (listed previously) happen to use OOP/templates/functional programming as it is the combination that makes sense to them.
What I am getting at is essentially “we don’t allow and discourage OO, we give you better options in our view”. My 2 cents is to look at success stories (C++ evolves rapidly these days, being version 1 doesn’t mean we stopped evolving) and perhaps reconsider so several others can become active participants in Julia’s growth.
I believe that some of the softwares you mentioned would perhaps evolve differently if they had the choice. C++ was all the rage 20 years ago, and OO was good. These days the view of OO is much more moderated. The reasons are not that hard to demonstrate: consider for instance The delightful conciseness of Julia. With Julia we can accomplish anything we could produce with C++, and with more legible and grokkable code.
1 Like
That statement does not represent correctly the answers given, in my opinion. There are various links to packages and documents that tell how to make that Julia objects work more in an “OO-fashion”, if you feel like doing it.
1 Like
The other way of looking at it is that the whole of C++ is so complicated that most people select a subset and use that. I don’t see this as an advantage; you will still encounter code from people who used some other part of the language.
Sorry to be repetitive, but at this point in Julia’s lifecycle, it may take a lot more than generic statements like this for most people to even consider the possibility of taking this seriously.
You can’t “just add” C++-style OOP to Julia: the details of the semantics has to be worked out, then the issues with the compiler and optimization. And it has to be a large improvement in Julia’s usability, because it is a seriously breaking change. This is a lot of work, compared to the fuzzyness of the benefits that you are proposing — most Julia users are perfectly happy with this part of the language and would prefer to focus on other things.
Also, it is unclear that having some form of OOP would make more people contribute to Julia. Personally I would hope that if C++-style OOP is ever considered, someone would fork the language and continue without it (as you may have gathered, not all people are enthusiastic about C++ or OOP).
2 Likes
I just took a course in modern C++. What a pile of complexity! That is not good. No wonder tools trying to cope with this complexity are all the rage. In Julia reading the code is in most cases good enough for me. Looking at deal.ii, I need all the help I can get.
4 Likes
Sorry to be repetitive, but at this point in Julia’s lifecycle, it may take a lot more than generic statements like this for most people to even consider the possibility of taking this seriously.
Likewise, apologies if I sound repetitive, my point is that this is how languages evolved. C++ has the commitment to evolve rapidly post C++11 (not much was done between 98 and 11). Python 2 and Python 3 is another example. They look back and reconsider, the result is that those two languages dominate in many industries as their complexity allows for solving complex problems. They built large communities around.
You can’t “just add” C+±style OOP to Julia:
Also, it is unclear that having some form of OOP would make more people contribute to Julia.
Of course, I am not “demanding” OO to be available in the next release. I am just suggesting that perhaps the discussion is worth having and get different perspectives to answer those questions as many frameworks in scientific computing (hence their communities around) are familiar with OO and they see it as the proper way of doing things (even if some don’t, goes both ways). Perhaps Julia Con or surveys are a better place than discourse.
most Julia users are perfectly happy with this part of the language and would prefer to focus on other things.
I guess it largely depends on the long term vision for Julia on either keeping current users perfectly happy or expand the base. Again, it is open to discussion.
In any case, I think Julia has a lot of great ideas put in practice I’d be happy to see the language grow. Part of it is taking feedback and being cool about it.