# Does Julia Create a "1.5" Language Problem?

**URL:** https://discourse.julialang.org/t/does-julia-create-a-1-5-language-problem/107984
**Category:** Teaching & Outreach
**Tags:** question, discussion
**Created:** [December 23, 2023, 6:44pm UTC](https://discourse.julialang.org/t/does-julia-create-a-1-5-language-problem/107984 "2023-12-23T18:44:23Z")
**Posts on this page:** 1
**Showing post:** 76

<div class="post-metadata">

### Author: ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [December 29, 2023, 3:15am UTC](https://discourse.julialang.org/t/does-julia-create-a-1-5-language-problem/107984/76 "2023-12-29T03:15:42Z")

</div>

> [@anon56330260](#):
>
> I think this case is specially handled in compiler (because lower of for loop immediately places a case split after iterate) so it’s not automatic union splitting.

No, the only special handling is the lowering of the for loop. The union splitting is visible in `@code_warntype` and shows up the same if you replaced a looped `iterate` with any other method.

> [@anon56330260](#):
>
> Maybe we can have OOP as a separate mechnism, but people may not want to accept this.

That’s possible, Python has a multipledispatch package and some OOP languages _kind of_ have the syntax with function overloading. The problem is putting classes in real argument annotations (not the type hints Python has at most); I summed up the attempts I’ve seen in [this comment](https://discourse.julialang.org/t/why-there-is-no-oop-object-oriented-programming-in-julia/86723/26). And those attempts were emulating Python, an OOP language with no formal type stability, and it’ll only get more awkward and brittle when considering that crucial feature. It becomes clearer why Lisp is the way it is.

I don’t remember where I read this, but someone speculated mimicking virtual method tables by fixing the specializations (and perhaps their return type) a runtime dispatch could do and throwing an error otherwise, even if the table was derived empirically from a running program. No syntax concept was provided, it was very speculative.

> [@anon56330260](#):
>
> Also, untyped Python runs much faster than untyped Julia.

I think runtime dispatch is faster in Python than Julia, the type checking is less complicated at least, but in my experience this doesn’t bear out in practice because slower code only hurts the program’s performance if it occupies a significant portion of the runtime. Julia has some type inference recovery practices for the critical portions, Python has C-based libraries, it just evens out.

---

_[View the full topic](https://discourse.julialang.org/t/does-julia-create-a-1-5-language-problem/107984)._