Why specify argument types and return types

[oxinabox]

@pixel27

Maybe I’m reading too much feeling into people’s responses when they rail against defining types or return values to methods.

I think you are.

If you are reading my aformentioned blog post, then do be aware that:

1. As i quote in the introduction from Press, Teukolsky, Vetting and Flannery’s “Numerical Recipes”:

We do, therefore, offer you our practical judgements wherever we can. As you gain experience, you will form your own opinion of how reliable our advice is. Be assured that it is not perfect!

2. It is written in a intentionally direct and strongly stated way. For clarity of reading of the blog post, i find it better not to hedge statements too much.
   In practice I do on occation “over-constrain” things, mostly to match existing conventions. Generally at the level of Real or Number rather than AbstractFloat or Flaot64.

@pixel27

Well that feels like an attack at me, thanks for that.

I really don’t think it was.
Tone is hard in text.
I would recommend assuming charitably.

---

From my experience there are 3 killer use cases for Multiple Dispatch.

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

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) 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 Int…

And the most significant of them is for linear algebra.

---

I would not try and program julia like you would type-script.
Type-script added types to the language for safety (as i understand it).
To be more like a language where errors can be caught at compile time.
Julia added types to the language for expressivity.
To allow things to be extended.
They are conceptually different things.

If you try and use types for safety in julia you will still be disappointed.
Since even with everything strictly type constraint the compiler won’t prevent you from calling a method that doesn’t exist, it will just error at run time.
There are some tools like JET.jl GitHub - aviatesk/JET.jl: An experimental code analyzer for Julia. No need for additional type annotations. that can help with this.

But its not going to be an on par experience as type-script’s type-checker.
Let alone Haskell’s.
Its just not the focus of the language.
And that is ok.

@pixel27

Really that’s your answer? Go use something else if you want to define your parameters when not strictly required? Ouch. This as a great example of the fury/vehemence toward people who want to define their parameters.

C’mon.
That’s not fury, or at least my statement above that is similar isn’t fury.
We (well at least I) just want you go into this with the right expectations, so you don’t have a bad time.
There is nothing wrong with wanting a statically typed language.
But julia isn’t one; and your just going to be disappointed if you hope it is.
You can constrain your type-parameters if you want, but its not going to be anywhere near as rewarding as it will in other languages.

I love me a statically typed language, prefer it even.
I am for example really enjoying DexLang right now.
I put up with Julia not being a statically typed language, because it has other strong points.
And I want to take advantage of those strong points; rather than try and force it to be something it isn’t.

Go ahead and write things heavily constrained if you want.
If you do, do try out JET.jl and see if it is catching bugs and stuff that it wouldn’t if you didn’t constrain things.
and then come tell us all about how good it is. (or if it all sucks)