Similar to the other commenters, I find this comparison to be a bit unfair since TS is not a completely new programming language.
Apart from that, Elm is a great language! I've been dabbling around with it in the past and I especially liked its great DX and that it's purely functional. Comparing it to ReasonML would be very interesting, too :)
Thanks for the link, I am currently doing something similar without knowing TS implicit behavior.
With 1st given example in the link, I forced on a style to such:
```
function doSomething(x: number | string) {
if (typeof x === 'string') {
doSomethingForString(x)
}
// Never do catch all to assume all non-strings are numbers
if (typeof x === 'number') {
doSomethingForNumber(x)
}
// Per transpiler rule, you not meant to be here, so error throwing is appropriate
throw new Error('Unexpected type')
}
function doSomethingForString(x: string) {
// Code
}
function doSomethingForNumber(x: number) {
// Code
}
I see why you're missing an explanation on why classes should be avoided.
In fact, your opinion is very similar to mine - I also think that, especially in the context of the FP-influenced React, data should be separated from behaviour - I mean how exactly are you going to preserve immutability using OOP? React just works a lot better when there's no self-mutating objects.
Could you elaborate on why you think that classes should be used when implementing controllers? I tend to think of controller classes as singletons, which kind of contradict using classes in the first place.
Then what do you do about the old version of the mutated object? There will still be references to it in other parts of your object model, which will now be out of date. I think that the concept of objects preserving identity is central to OOP, which simply contradicts immutability.
Why would you somehow pass objects around that are not "final"?
I mean the objects that get pinned here and there are specifically designed to serve as wrappers for some state, hence they encapsulate that state, and thus they are mutable. (For example a DB connection/manager object, a service registry, a cookie/localStorage repository.)
Where the immutability usually helps is with shuffling data around, parallel computing (concurrent access, no need to lock), etc.
Correct me if I'm mistaken: I think you can indeed cast from HashMap to Animal and it will happily compile:
```java
import java.util.HashMap;
class Main {
class Animal {
String sound = "roar";
}
public static void main(String[] args) {
HashMap<String, String> map = new HashMap<>();
Animal animal = (Animal) (Object) map;
System.out.println(animal.sound);
}
}
```
At runtime, this will crash with the following Exception: `Exception in thread "main" java.lang.ClassCastException: class java.util.HashMap cannot be cast to class Main$Animal`, but it will satisfy the type system.
That's a very good point! Although I find the example to be rather exaggerated, I see how these types of errors can happen when you're dealing with very complex types. In the post, I also talk about how wrongly-typed dependencies will compromise type safety, which can be another source of errors.
Nonetheless, I think that TS can catch a lot of errors and will help documenting your code - and that's a very good thing on its own.
I'm with you on this.
In my opinion, TypeScript can really get in your way when you develop in a way that's not TypeScript-friendly, but you'll benefit heavily once you start developing with types in mind.
