You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came here, first, to gratulate and thank you for this project, it's awesome!
So, now to my proposal. 😃
Multiple dispatch solves the expression problem.
It does so in the way, that Douglas Crockford mentioned in his famous book "JavaScript: The good parts"
If there is a feature of a language that is sometimes problematic, and if it can be replaced with another feature that is more reliable, then always use the more reliable feature.
Multiple dispatch solves the guidance problem of polymorphism.
It also solves the problem of extending and changing code written with a single inheritance in mind. I consider this to be a very nice side-effect.
The traditional methods of polymorphism (traditional in the popular sense) often have disadvantages, and C++ is famous for misunderstanding Alan Kay's initial intention of the term "object orientation."
The community adopted a 'composition over inheritance' mindset quite a while ago.
The team around Julia found unease with the typical forms of polymorphism as it had already existed in popular languages that they used before; including C++.
As they were considering certain forms of it for their language, they found that it didn't work well with the kind of data and computation scientific data was represented, and they wanted to try something new.
And on the research about that, they found that the solution to that topic has been discovered already decades ago.
As it happens. 😅
This dispatch method's cleanness and semantic elegance are easily demonstrated, and programmers often see the benefits quite quickly.
The issue with its implementations was, that it had been always a sloth in the past. It was simply never fast enough to compete with other ways of polymorphism.
And so, other means of abstracting the polymorphistic way gained more traction.
Julia set out to change that.
There are also other implementations, one in C++, and the native ones in CL and Clojure as examples.
I am today here to introduce this idea to your project and encourage you to see this little presentation of Julia's Stefan Karpinski.
Recognize that the key factor is, that code sharing only improves dramatically when used as a primary language feature.
This is of importance when thinking about the synergy of solving the guidance problem.
Julia has no way of abstracting behavior beyond functions and multiple dispatch.
So, I think it's clear that this replaces all forms of polymorphism as the default choice (and it's important to communicate this as a cultural good, as otherwise some of the benefits are lost).
Happily, existing codebases can be adjusted.
There is still a small performance penalty in the C++ library that I shared.
Depending on the number of methods implemented, it drops in performance by around 15% - 30%, when compared to virtual calls.
Considering that virtual calls take around 1-2 cycles, and that some use cases like rendering and simulations call these open multi methods frequently, we would transpile to single dispatch, as is implemented today, with one unified syntax for all dispatches.
Also, optimizing the dispatch table by type erasure and lazily dispatching (and initializing) does make some difference.
Julias' implementation of monomorphic and bimorphic dispatch is comparable in cost to virtual calls in C++, although they are closed multi methods, as said (who are inherently a bit more performant, due to the dynamic lookup.
The proposed yomm2 solution can be extended at runtime.
The lookup cost for dynamic additions to the runtime table will always add a small overhead.
I think that it is worth, implementing a system, that allows to extension of the program with a plugin system. A science-oriented language like Julia does not need so much as a more general-purpose language like Cpp.
Julia does manage to use these techniques with numerical and scientific computation in high-performance scenarios.
The text was updated successfully, but these errors were encountered:
I have just heard of multiple dispatch the first time and watched the talk. (It is very good.)
As I understand it, multiple dispatch is a runtime functionality of Julia. Since, cppfront is just a transpiler for C++ this functionality would need to be available in C++. There are probably ways to implement this in cppfront, e.g. by adding special functionality to every class that is declared and by wrapping each function call. One problem would be that classes defined in C++ (and not in cppfront) would not be compatible with this approach.
Because of this, I do not think that adding multiple dispatch to cppfront is a valid option. Although the idea of it is very nice.
I do not doubt that there is an implementation. But I presume, that my original statement still stands: In order to make it work with functions and classes outside of cppfront the appropriate declarations for the library need to be made. So it would not work out of the box.
Please correct me if I am wrong, I do not have the time for a closer look at the library.
Hi there :)
I came here, first, to gratulate and thank you for this project, it's awesome!
So, now to my proposal. 😃
Multiple dispatch solves the expression problem.
It does so in the way, that Douglas Crockford mentioned in his famous book "JavaScript: The good parts"
Multiple dispatch solves the guidance problem of polymorphism.
It also solves the problem of extending and changing code written with a single inheritance in mind. I consider this to be a very nice side-effect.
The traditional methods of polymorphism (traditional in the popular sense) often have disadvantages, and C++ is famous for misunderstanding Alan Kay's initial intention of the term "object orientation."
The community adopted a 'composition over inheritance' mindset quite a while ago.
The team around Julia found unease with the typical forms of polymorphism as it had already existed in popular languages that they used before; including C++.
As they were considering certain forms of it for their language, they found that it didn't work well with the kind of data and computation scientific data was represented, and they wanted to try something new.
And on the research about that, they found that the solution to that topic has been discovered already decades ago.
As it happens. 😅
This dispatch method's cleanness and semantic elegance are easily demonstrated, and programmers often see the benefits quite quickly.
The issue with its implementations was, that it had been always a sloth in the past. It was simply never fast enough to compete with other ways of polymorphism.
And so, other means of abstracting the polymorphistic way gained more traction.
Julia set out to change that.
There are also other implementations, one in C++, and the native ones in CL and Clojure as examples.
I am today here to introduce this idea to your project and encourage you to see this little presentation of Julia's Stefan Karpinski.
Recognize that the key factor is, that code sharing only improves dramatically when used as a primary language feature.
This is of importance when thinking about the synergy of solving the guidance problem.
Julia has no way of abstracting behavior beyond functions and multiple dispatch.
So, I think it's clear that this replaces all forms of polymorphism as the default choice (and it's important to communicate this as a cultural good, as otherwise some of the benefits are lost).
Happily, existing codebases can be adjusted.
There is still a small performance penalty in the C++ library that I shared.
Depending on the number of methods implemented, it drops in performance by around 15% - 30%, when compared to virtual calls.
Considering that virtual calls take around 1-2 cycles, and that some use cases like rendering and simulations call these open multi methods frequently, we would transpile to single dispatch, as is implemented today, with one unified syntax for all dispatches.
Also, optimizing the dispatch table by type erasure and lazily dispatching (and initializing) does make some difference.
Julias' implementation of monomorphic and bimorphic dispatch is comparable in cost to virtual calls in C++, although they are closed multi methods, as said (who are inherently a bit more performant, due to the dynamic lookup.
The proposed yomm2 solution can be extended at runtime.
The lookup cost for dynamic additions to the runtime table will always add a small overhead.
I think that it is worth, implementing a system, that allows to extension of the program with a plugin system. A science-oriented language like Julia does not need so much as a more general-purpose language like Cpp.
Julia does manage to use these techniques with numerical and scientific computation in high-performance scenarios.
The text was updated successfully, but these errors were encountered: