skn0tt

awesome to see a Blitz.js-built app on the front page :)

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.

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 :)

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.

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.