# Is Julia's way of OOP superior to C++/Python? Why Julia doesn't use class-based OOP?

**URL:** <https://discourse.julialang.org/t/is-julias-way-of-oop-superior-to-c-python-why-julia-doesnt-use-class-based-oop/52058>\
**Category:** Internals & Design\
**Created:** [December 18, 2020, 4:32pm UTC](https://discourse.julialang.org/t/is-julias-way-of-oop-superior-to-c-python-why-julia-doesnt-use-class-based-oop/52058 "2020-12-18T16:32:10Z")\
**Posts on this page:** 1\
**Showing post:** 84

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [December 23, 2020, 9:53pm UTC](https://discourse.julialang.org/t/is-julias-way-of-oop-superior-to-c-python-why-julia-doesnt-use-class-based-oop/52058/84 "2020-12-23T21:53:41Z")

</div>

> [@paulmelis](#):
>
> Would you say that multiple dispatch is particularly suited for more numerical code? Or put differently, is multiple dispatch less of an advantage when used for programming less “science-y” tasks, like business logic in a web server, system administration tools or (weird thing to come to mind 🙂) implementation of a cryptocurrency?

I try an keep a list of small clear cases where multiple dispatch is a undisputabled better solution

### 1. Structured Matrix Multiplication.

I have this written up full here, so can read that blog post (or watch the talk version which is at the top of the page)

> **[Are there real-world use cases for Multiple Dispatch ? - JuliaLang: The...](https://www.oxinabox.net/2020/02/09/whycompositionaljulia.html#are-there-real-world-use-cases-for-multiple-dispatch-)**

### 2. Arithmetic Type Promotion

Turns out this is really hard.  
A few years ago a [large proposal to overhaul Swift’s Integer type](https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md#non-goals) was written.  
Even in this large document, they explictly:

> DOES NOT solve the integer promotion problem, which would allow mixed-type arithmetic. However, we believe that it is an important step in the right direction.

To understand type promotion and why it needs multiple dispatch consider;

- `+(::Int32, ::Float64)::Float64`
- `+(::Float64, ::Int32)::Float64`
- `+(::Complex{Int32}, ::Float64)::Complex{Float64}`

The resulting type depends on both input types, and not in a trivial way either.

### 3. Contextual Formatting of Objects

IIRC @thautwarm said on twitter something like _“The quality of a language can be determined by how hard it is to access polymorpic printing methods”_  
Which I took to mean this.

This applies to julias whole `show(::IO, ::Mime, ::Object)`, but lets sep away from that to think about generating some document.

Lets consider that was have verious objects that need to be displayed:

- Number
- Text
- Equation

And variouis contexts with in the document to display them:

- FlowingContent
- Diagram
- Table

So consider the options:

- Number in general should be shown using [proportional figures](https://www.fonts.com/content/learning/fontology/level-3/numbers/proportional-vs-tabular-figures)
- Numbers inside Tables should be shown with [tabular figures](https://www.fonts.com/content/learning/fontology/level-3/numbers/proportional-vs-tabular-figures)
- Anything in FlowingContent should be shown in serifed font
- Anything in Diagrams should be shown in with a sanserifed font
- Except Equations in Diagrams should be shown in large sized serifed font

---

_[View the full topic](https://discourse.julialang.org/t/is-julias-way-of-oop-superior-to-c-python-why-julia-doesnt-use-class-based-oop/52058)._
