Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SUGGESTION] Implement multiple dispatch #1356

Open
ShalokShalom opened this issue Jan 22, 2025 · 0 comments
Open

[SUGGESTION] Implement multiple dispatch #1356

ShalokShalom opened this issue Jan 22, 2025 · 0 comments

Comments

@ShalokShalom
Copy link

ShalokShalom commented Jan 22, 2025

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"

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant