Can someone give like the 5 best Tutorials, whitepapers, or books that clearly describe how to map classic C++ (or Java) object orientation (inheritance, virtual constructor/destructors, polymorphism, and templates) into Julia’s Multiple Dispatch methodology - including when and what macro/metaprogramming, closure, subtyping system rules, etc that are needed to transform OO thinking on any old C++/Java project into the new paradigm? I want to understand the whole design process and answer questions like: When do macro’s come into play with moving from OO and design patterns to MD, when should functions generate other functions, when and how to use variables inside of functions to retain state, what becomes of virtual constructors/destructors in the new methodology? Basically a complete mapping of the old way of programming (and old code) into the new paradigm of MD and closure. I’m looking for a systematic and thorough reference document. Oh, and please let it be current to 1.8+ at least, not something based on pre 1.0 language.
There’s no need to templates, Julia is generic by default.
A better starting point is maybe to think of it like C (without
case rather multiple dispatch) and what is added, e.g. supertypes, but all of those are abstract. There are no destructors because of GC (there are finalizers rarely used, I’ve never made one).
Julia is radically simpler than C++, almost as simple as C, is some ways simpler e.g. no preprocesor or header files needed. You don’t need to type your functions (only structs, with concrete types usually). You can type all your functions, but it make no difference speed-wise, and then Julia is like a simpler C with GC. But it’s not advised to to that, or not with concrete types usually, more likely abstract types. And read the performance section of the manual.
There is no inheritance, composition is better, try to get the Julia mindset, multiple dispatch. You don’t need, but can consider (for inheritance and traditional Python-like OOP):
We recommend you to read How to Translate OOP into Idiomatic Julia before using this package.
Multiple dispatch used by Julia gives a novel solution to the expression problem, while […]
Although we’d admit that there are some essential differences between OOP and multiple dispatch under the hood, they are not that different. In fact, Julia’s multiple dispatch definitely steps further and can fully express OOP, although […]
This article aims at telling people how to translate serious OOP code into idiomatic Julia. The translation is divided into the following sections:
- Julia representation of constructors
- Julia representation of methods
- Julia representation of inheritance
- Julia representation of interfaces
No macro is ever needed, at least not for multiple dispatch, but many are common. Just learn them as you go, e.g.
@simd, look up those you see others using. Probably just skip using
@inbounds rather use e.g.
You can never define macros (I’ve never), and defer learning (let alone generated functions), but it’s useful to learn to apply and use some. Or none… most I use are for optimization, e.g.
@view. Besides multiple dispatch, broadcasting was new to me and then
@. helpful but not needed, I’ve never had to, nor used
@kwdef though I understand helpful, nor
In general there won’t be a complete mapping of concepts from one paradigm to replace concepts in another. You’ll likely find more holes than overlap, and this is why reference documents relating all aspects of 2 independently designed languages don’t exist. It might be easier to learn a language on its own, and only draw parallels to another language when you have a grasp of both.
I’ve seen this kind of thinking in other comments on Julia boards but it doesn’t help. I’m looking for a well thought out road map.
When I mean a mapping, that would include things like. If you are mapping C++ to Julia and have all these virtual destructors, you just delete those bits of functionality from the Julia because of A or B rule, but in scenarios X and Y you would do THIS instead. Things like, if you have a Decorator pattern in C++, then you replace it with this macro code to create these functions… I’m just guessing here.
Basically, I’m looking for something that has figured out these general engineering rules instead of me AND EVERYONE ELSE just having to guess and make up the rules as we go along and result in a TON of coding chaos out in the world. When a world paradigm is beaten into you throughout college, grad school, and various corporations and then your told… oh, just throw that all away and here are a few pointers… now figure the rest on your own. Well, I can see a lot of developers out there will say “screw that”, we’ll just keep on with our well laid out OO paradigm and ignore Julia. I want to see all these folks get a good ROADMAP for the new paradigm and transition to Julia since I think it has a serious opportunity to replace a majority of business, engineering, and web code out there.
Thank you for the “How to Translate…”. That should start to help.
Basically, there needs to be a recognition in the Julia community about just how PERVASIVE the OO paradigm, including Design Patterns, is in the programming world, and how much a comprehensive mapping of how to think and what to code when you find yourself conditioned to write a chunk of code that would fit to some aspect of that OO/DP world. Having a framework for how to think about all these scenarios would be a HUGE accelerator of Julia adoption. People like to have some training wheels while they are getting used to doing things in a VERY different way.
You may find this talk useful. It compares Julia multiple dispatch with C++ OOP.
A language that doesn’t affect the way you think about programming, is not worth knowing.
– Alan Perlis
I mean I’m not sure it’s good to start with thinking I have good design patterns, and how to they map, some are redundant in Julia I believe, and some OO thinking.
I haven’t read the book, but Tom Kwong (Author) should be solid, Stefan Karpinski (Foreword) means stamp-of-approval for me. Also gets high ratings.
Design and develop high-performance, reusable, and maintainable applications using traditional and modern Julia patterns with this comprehensive guide
- Explore useful design patterns along with object-oriented programming in Julia 1.0
[note means 1.x, see cover of the book, should be good for 1.9.x.]
- Implement macros and metaprogramming techniques to make your code faster, concise, and efficient
- Develop the skills necessary to implement design patterns for creating robust and maintainable applications
What you will learn
- Explore methods for transitioning from object-oriented programming to using equivalent or more advanced Julia techniques
Who this book is for
This book is for beginner to intermediate-level Julia programmers who want to enhance their skills in designing and developing large-scale applications.
Table of Contents
- Design Patterns and Related Principles
- Macros and Meta Programming Techniques
- Object Oriented Traditional Patterns
- Inheritance and Variance
I still think the free advice I gave, and free I pointed to should be useful.
OOP wasn’t historically, but ok I can agree it too over, in C++ and/or Java form. Still there’s OOP of C++, very different from OOP of Smalltalk (the original, what Alan Key meant when he coined the term OOP). Erlang is considered functional, but is actually OO, in the Smalltalk sense, I understand.
This may be helpful (I didn’t read):
I was thinking what is DP, then realized Desing Paterns (I should know, I own the GoF book), but I first thought you meant OOD[esign] and OOP.
I converted a program to Julia where I had the choice of using a Python or a C program to convert from. The C-program was far more natural. When I started I didn’t know which I should use as my basis, so yes there were wrong turns before I sorted things out.
Note: I have read about OOP but never programmed in it. I am also not a programmer by training.
This was important to point out, OOP isn’t done the same way in every language because of other important facets. The initial division into old OO concepts and new multiple dispatch concepts was wrong, even by the given examples: destructors do not exist in Java because a garbage collector frees memory, and macros and metaprogramming already exist in C++, though there are not clean parallels to Julia’s. Python is OO but it’s dynamic, and Peter Norvig demonstrated that dynamic languages like Dylan and Lisp (which has multiple dispatch, so not “new”) made 16/23 of the Gang of Four design patterns invisible or vastly simplified, in other words you’ll lose familiar concepts even from one OO language to another. Worth mentioning that he has also said “design patterns are bug reports in your language”, not rules to preserve across languages; link to an interesting debate on how true that is (note the list of pattern replacements there deviates from Norvig’s). I imagine that will ring really true going from OO to Julia; for example, the decorator pattern was mentioned, and that obviously won’t work the same when abstract supertypes lack fields.
To be honest, the resource you seek may not exist in a comprehensive fashion, yet. It probably would make for a good book. In lieu of that, the best way to get a concrete answer is to ask a specific question.
What would be helpful is if someone could point to a specific OOP pattern and then ask how to idiomatically implement a similar concept in Julia.
For example, one could ask “How do I implement a singleton?”.
Better abandon OO thinking, if you can.
The pursuit is not about reimplementing OO thinking, it is about how to take code that WAS thought in an OO paradigm and reinterpreting those business needs into an MD + closure approach for the same business need. I.e., even for simple things like singletons, how to best re-express the need of a SOMETHING that maintiains a global variable that is controlled by code (be it a closure function, or some kind of macro/closure construct or something totally different. Think of it as… this is how you migrate C++ or Java code to pure Julia. Rewriting everything from scratch and a clean slate makes it likely that you will MISS business rules that will bite you down the road. This concept would be really good for a book, expecially as people start to think of Julia as not just a language used by data scientist for brand new projects, but as a platform for general software development and maintenance. …Otherwise, Julia will only stay as a niche language and MD will be disrespected because it got tied to a language that never entered “the BIG LEAGUES”.
Thanks for the link! This looks pretty good concerning singletons.
I will definitely investigate the Hands On Design Pattern book as soon as I complete the Julia 1.0 Programming Complete Reference. This book looks to be the best thing available concerning the translation of OOD/OOP/DP code to a Julia/MD/closure paradigm.