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.
And it also solves, how to extend and change code that is written with single inheritance in mind, and that is also a very good thing.
The traditional methods of polymorphism (traditional in the popular sense) often come with their disadvantages, and C++ is famous for misunderstanding the initial intention of the term "object-orientation" from Alan Kay.
The community has adopted a 'composition over inheritance' mindset a while ago.
The team around Julia had an issue with polymorphism, as it existed in already present languages that they used, 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. 😅
The cleanness, and semantic elegance of this dispatch method can be demonstrated easy, 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 one's in CL and Clojure as examples.
I am today here to introduce this idea to your project, and encourage you to see the this little presentation of Julia's Stefan Karpinski.
Recognize that the key factor is, that code sharing only improves dramatically, when used as primary language feature.
This is of importance, when thinking about the synergy of solving the guidance problem.
Julia has no way of abstracting behaviour beyond functions, and multiple dispatch.
So I think its clear, that this replaces all forms of polymorphism as the default choice (and its important to communicate this as culture good, as otherwise some of the benefits are lost.)
Happily, existing codebases can adjust.
There is still a small performance penality in the C++ library that I shared.
Depending on the numbers 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, caching is important.
Also optimizing the dispatch table by type erasure, and lazily dispatching (and initializing) it does make some difference obviously.
Julias implementation of monomorphic and bimorphic dispatch is comparable in cost to virtual calls in C++.
These calls are the majority of typical programs.
One difference is, that Julia uses a closed multi method system, and the proposed yomm2 solution can be extended at runtime.
The lookup cost for dynamic additions to the runtime table will always be adding a small overhead.
I think that is worth it to extend the program with a plugin system (which the science oriented Julia does not need so much as a more general programming language like C++)
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:
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.
And it also solves, how to extend and change code that is written with single inheritance in mind, and that is also a very good thing.
The traditional methods of polymorphism (traditional in the popular sense) often come with their disadvantages, and C++ is famous for misunderstanding the initial intention of the term "object-orientation" from Alan Kay.
The community has adopted a 'composition over inheritance' mindset a while ago.
The team around Julia had an issue with polymorphism, as it existed in already present languages that they used, 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. 😅
The cleanness, and semantic elegance of this dispatch method can be demonstrated easy, 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 one's in CL and Clojure as examples.
I am today here to introduce this idea to your project, and encourage you to see the this little presentation of Julia's Stefan Karpinski.
Recognize that the key factor is, that code sharing only improves dramatically, when used as primary language feature.
This is of importance, when thinking about the synergy of solving the guidance problem.
Julia has no way of abstracting behaviour beyond functions, and multiple dispatch.
So I think its clear, that this replaces all forms of polymorphism as the default choice (and its important to communicate this as culture good, as otherwise some of the benefits are lost.)
Happily, existing codebases can adjust.
There is still a small performance penality in the C++ library that I shared.
Depending on the numbers 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, caching is important.
Also optimizing the dispatch table by type erasure, and lazily dispatching (and initializing) it does make some difference obviously.
Julias implementation of monomorphic and bimorphic dispatch is comparable in cost to virtual calls in C++.
These calls are the majority of typical programs.
One difference is, that Julia uses a closed multi method system, and the proposed yomm2 solution can be extended at runtime.
The lookup cost for dynamic additions to the runtime table will always be adding a small overhead.
I think that is worth it to extend the program with a plugin system (which the science oriented Julia does not need so much as a more general programming language like C++)
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: