Yes - I understand why some people are keen on static types, but type inference is a powerful way to create funcetionality and I believe that the separation of concerns between the dispatcher and the programming code (removing the logic of decisioning from the code and using type inference instead) leads to clearer programs. I can't think how you can have that and have static checking as well (although I know that there are some compilers for some Julia code as mentioned in this thread)
Lots of languages with static typing use type inference. Haskell, OCaml, Go, Rust, Nim, etc. Even C++ has auto these days which I think when combined with templates gives you what you're talking about though it is a bit clunky.
EDIT. For instance in Haskell I can just declar a function to sum the things in a container by saying
summer a = folder (+) 0 a
And the compiler will figure out that the function accepts a Foldable container of some sort full of things that are Nums without ever having to tell the compiler that (though it's a good idea for maintainability. And then I can just pass in a list of floats and the compiler will Do The Right Thing. And if I pass in a list of booleans instead the compiler will yell at me at compile time because there's no (+) operation for booleans.
I think he possibly phrased it wrong. Dynamic languages don't do type inference, they carry type with each value at runtime.
Dynamic and statically typed languages each have their own wonderful advantages. There is just no way of replicating all the advantages of dynamic typing in a statically typed language.
It is hard to sum up why in a short sentence but I have tried to articulate it in a longer article here:
Keep in mind this focuses only on advantages of dynamic languages. It does not mean I don't consider that static languages don't have their own unique advantages, but that was not the topic of my article.
The primary problem with static typing as I see it is the complexity and mental overhead it adds. It is not just the complexity in the type system and the language itself, but also in the tooling surrounding it: build system, dependency management, binary interface definitions, debuggers, REPL etc.
The complexity makes meta programming very hard to do for a software developer of average intelligence.
Where I see a use for advance static languages is for very specialized systems which need a high level of correctness and where a company is able to do the job with a small team of very bright people.
For me static typing removes mental overhead. I have fewer things to keep in my head, I can trust the tools to have my back and point me to where I did stupid mistakes. It makes reasoning about the code more local.
Also you can have static typing in an interpreted, interactive setting, with any language that has a REPL. That's even how the ML family started.
Peace of mind is not quite the same as what I meant with mental overhead. What I am referring to is that static type systems have far more complex type systems and semantics, which occupy more brain real estate.
And complexity tends to explode because it carries over to the tools. Static languages require far more complex tools to work with.
I did not mean static languages cannot have REPLs but my experience with them have not been great. They seem hamstrung in a way I cannot articulate well.
Reading through that Medium post makes me think that maybe the author has never worked with a large code base written in a dynamic language and is attributing the difficulties of large projects to them being written in static languages? My day job involves a large amount of Python and we certainly use CMake to bundle it up for deployment, use YAML configuration files, worry about library version compatibility, and all of the other problems the author ascribes to static typing.
Yes... but I feel that is more like an implementation detail. Semantically speaking you don't think of Julia as doing type inference.
Semantically speaking expressions don't have types and the type of expressions are never inferred (however they are inferred at compile time as an implementation thing for the JIT).
My point is that you can make an alternative Julia implementation that did absolutely no type inference and everything would work just fine apart from possibly bad performance.
However you could not make a compiler for a statically typed language such as Haskell which did not do type inference. If you did programs would no longer compile.
At least that is how I interpret the difference. I could be wrong. You probably know this better than me.
