Introduction
Below is my personal perspective :)
If I write a one-page program, I don't mind having no types, zero types, -1 types, and I'm happy with it.
If I write a bigger app, handled by multiple team programmers, which is expected to be maintained, I consider types to be a must! I'm still happy with it!
When I like types
Today modern languages have type inference, so the typed code looks very much concise as non-typed code, Scala, Haskell, OCaml, Kotlin, ELM, concise typed code pretty much is both pretty and rules!
When I don't like types
We still need to compile it, it takes time, but I'm willing to pay this price, the maintenance time and code understanding time, is also time. Time is time, a second is a second, I would rather pay seconds or even minutes of compile time for hours of unusual bugs and code readability time.
Type Inference + Types => Concise readable code!
But still sometimes you find yourself waiting for the compiler, I tend to grab a coffee :) but this is like the less enjoyable type time.
Performance penalty for type inference
You pay the price at compile time. As mentioned earlier, I prefer to pay someone to compile than to pay someone to read and not understand the code.
Programs that are hard to understand are also compiling slower.
So if you write readable code it will compile faster ;)
Parametric polymorphism
Parametric Polymorphism: Same subtype [A] for the container which we defined.
Array[A] So you can have a single implementation that does something with the array and uses it for the different type - polymorphism.
Subtype Polymorphism
You inherit in order to have multiple implementations. But you end up with one big giant object (the class hierarchy) for me that is like a global ball of mud-code.
Subtype Polymorphism - a big ball of mud-code, there are multiple types when you traverse the array.
Simple Type System
Like in java we still go so much benefit of tooling, what our functions are doing, how the program is constructed.
Simple type systems give us great tooling!
Simple type systems give us great documentation checked by the compiler!
You need to explain to the compiler what you mean with those non-type inference languages.
Rich Type System
(like scala, ocaml, haskell).
Rich Type Systems allows us to have the clean simpler code!
This sounds unnatural but takes for example generics to express a single code which can be used polymorphically over types, code reuse. I return Int, Double don't care I return A but I do return A.
Rich Type Systems Catch Bugs
Lie: If it compiles it works!
I don't treat this as a truth. But many bugs just vanish:
- Null Pointer Exception, I don't remember having one since using Scala.
- Undefined is not a function forget about it with ELM.
- A misleading variable name: it was phone number but I got an email.
- Forget to change a name of a caller after a mini refactor.
Summary
My summary is very simple, for code which would require maintenance by new developers and is not a single page project, I use typed languages, for simple scripts and short code snippets, no types.
Top comments (5)
Types, if available, every time.
That one-page program, short snippet, or script? It's going to bloat and one day become a full-fledged text editor or something equally ridiculous. That's why I don't like using shortcuts even for short programs.
I strongly disagree. A lot of my personal projects are, for example, written as single HTML pages, with inline styles and javascript, and rarely extend beyond ~300 lines total.
Adding a build just isn't a worthwhile upfront cost when I can just write code and have it run with zero setup.
Assuming it'll bloat or expand is something I save for professional projects. In both cases my experience backs up that decision.
Scala's compiler is notoriously slow :-) Check out OCaml for an example of a powerful type system and lightning-fast compiles. You won't feel like going back to Scala ;-)
Thanks, I'll check it out the next time I wait for the scala compiler to complete it's compilation ;) very soon, I heard from one of my best friends (the internet ;) that multicore programming is one of the cons of OCaml vs Haskell, which is a thing to take in the list of consideration. I mean the way in which is supports parallelism.
Multicore is not a problem unless you're doing 'embarassingly parallelisable' computations like counting, summing, etc. :-) Even then OCaml libraries like Async Parallel offer multicore options.
For pretty much everything else, OCaml's single-threaded performance outstrips pretty much everything short of C/C++.