Rethinking how we talk about types

I once told my fiance about type systems.

She is a math nerd who considered studying AI as a dedicated course.

As someone with almost no programming background, she was curious about what that part of her study would look like.

So, I told her all I thought I knew about programming languages.

As we came to talk about type systems, I went into the different benefits of both systems.

Boldly expecting, I had convinced her that type systems are important, that dynamic types are for lazy people, and that static typing is super necessary.

She dared to point out the obvious.

"Why wouldn't you use both?"

I mumbled something together, not having an answer to it.

Most people could say, you need your entire code to be typed, to benefit from it. And I can agree to a certain degree, although I think the answer is more nuanced than this.

Not any architecture needs types. And spreading types around at anything that could be typed, is just no different than the primitive action hero, that shoots with his Gatling gun at anything that moves like a lunatic.

We call ourselves computer scientists.
Artists. Craftsman.

But, more often than not, we ignore science.
I did ignore science.

I did not even consider consulting it.
Type systems are just a requirement.

We have to deal with it.
Thankfully, somebody destroyed my worldview.

They have conducted the studies, that I didn't bother to look up. ¹

And the results were, as scientific studies tend to do, surprising to me.

Dynamic typing is not more prone to typing errors in production code.

I add that types are still awesome. They help us to shape an architecture, and they help us with refactoring code.

But they do not prevent type errors.

So how did I fall for this fallacy?

Since everybody around me claimed, that dynamic typing is lame.

Classic mouth-to-mouth propaganda.

So why I am writing this blog post?

I come from a background of functional programming languages.

Elm, as an example, is such a language, and it has inspired me in more than one way.

One aspect, that has initially surprised me first, and then convinced me ultimately, is that they avoid using the term 'functional programming' at all.

Stunning. Isn't that one of the main benefits of the language?

Well, it turns out, only from my perspective.

Classic case of organizational blindness.
Within the small niche of functional programmers, sure.
That would be a benefit.

But the average programmer?
Is turned off by it.

And the average newbie?
Doesn't even know, what it is.

So the association with that term does not interact well with the people that we look out to get on board.

I propose, that we do the same thing with our type system.

Language does exist to express oneself - and to communicate.

In this case, with a human.

One of the core accusations that people bring up against common object oriented languages, is that they can't allow them to adapt smoothly to changing business requirements.

Things change quickly, and the code that represents that isn't capable of doing so as well.

Are we the same, just on a social level?
Do we talk, without considering the refreshing context?

I am talking about dynamic typing.

Julia is not a typical dynamically typed language.
It has some of the most advanced type systems that I know.

And the current way of communication is underselling that.

Not only does multiple dispatch characterize the nature of Julia, but also the architecture of Julia code is defined by it.

From a certain level of complexity onward, multiple dispatch is the way we abstract code.

Basically everything above simple functions.

And since types come hand-in-hand with multiple dispatch, does that level of complexity never lack types.

The design of Julia and its multiple dispatch system marries complexity and types in a seamless, almost magical way.

The definition of types feels substantial and it comes with associated intent.

So simple code will always be simple, and complex code will always be maintainable.

The type inference helps with the transition, from one world to the other. It's almost seamless, and types become just like any other language feature.

It is anyway my conviction, that we talk about types system of languages as if they were some sort of overarching characteristic because we failed to implement them properly.

For decades.

I think Julia is the first language, that did this right.
Raku is close and does miss the global type inference.

Still, looking at the Julia homepage, I see that Julia is only a dynamically typed language.

I think that's selling the language under its value.
It takes one of the most exciting aspects of the language and hides it behind a word, that is widely regarded as a absurdity.

Why would we choose a word, that lets the people shut down in their head, once they hear it?

A lot of people immediately shove it internally into the category of toy languages.

Dynamic typing is not for serious developers.
No matter how true that may be, or not:

*It's a PR disaster.
*
So what do we call it?

Other languages, like Ruby and Python, call themselves now gradually typed.

As we know, Julia has a far more advanced type system than that. Implemented from the ground up. Impacting performance.
Providing very good inference. Used very widely in common code.

So the term 'gradually typed' is misleading as well.

We look for a descriptive name, one that is reflective of the properties of our system, and one that is associated with positive affirmations.

The reason why Elm stopped talking about functional programming was because it hid the essential idea that Elm embodied.

And instead of changing the perception of dynamic typing (much fun with that), I would just suggest talking about it in some fashion, that truthfully expresses the core identity.

I would suggest rethinking, how we talk about features, and take Elm and others as an example.

Let's talk about our awesome type system.

Let's hear your suggestions ;)

¹ https://www.infoq.com/presentations/dynamic-static-typing/