Discussion on: No, TypeScript is not a waste of time.

[Cubicle Buddha]

Yea I think people forget that in Java and C# you can’t equate instances that have all the same things. Look at this gross C# code:

Class User {
   public string name;
}

Class Person {
   public string name;
}

function saveName(Person: person){
    log(person.name)
}

saveName(new User()) // won’t work

^{^} now that’s verbose. In TypeScript anything that has the same data shape fits the interface, due to structural subtyping. So I can cut that code in half.

[Alex Sarafian]

You "can" (maybe more quotes are necessary) with type converters which you need to declare and implement in code hence the quotes.

I'm of C++ and C# background and when I read about such features in javascript I get the chills. Maybe I'm old school and I feel that structure similarities don't mean much. When I need them, I just interface them or implement the extra glue code. I'm all for strictness and clarity even if some extra coding is required. Extra coding for me means, that I implicitly enable the same option/functionality. I like scripting languages that are more flexible but I believe that each has its place and purpose.

[Cubicle Buddha]

Yea structural subtyping is really convenient but it is not as strict as nominal type system (like that of Java/C#). The TypeScript language devs are looking into adding opt-in for nominal types. I think it would be cool to have the option. I guess that’s one of the pros of TypeScript is that it gives your strictness but also some escape hatches. Kinda like C# will let you do crazy dynamic things via reflection.

[Alex Sarafian]

I'm not sure that reflection falls under the same category but I would agree with you about the spirit of TypeScript you mention. This is also a big difference, like generation differences, between C, C#/Java, JavaScript. Each addressed problems based on that periods concerns, let them be software or hardware.

[saint4eva]

Are you sure the above code is C#?

[Nick Holmes]

I'm certain it is neither literally C#, nor idiomatic of the features the language provides.

[Nick Holmes]

I think its very weak to compare to languages by trying to force the approach taken by one into another. You need to compare idiomatic solutions to the same problem to really understand them.

In strongly-typed object oriented languages, you need to be specific about polymorphisms. In general, I would like the compiler to stop me trying to pass (e.g.) an Order object to an User related process. To take your example, if I notice that a User is also a Person, I can write this;

class Person {
    public string Name;

    public void SaveName() {
        Logger.Log(Name);
    }
}

class User : Person { }

Now, User inherits the SameName method and more generally, I can use a User as a replacement for a Person. I could have also used an "IName" interface if I wanted naming to be distinct from class hierarchy.

So, there is no code to "cut in half", and no chance that anything I didn't expect to be passed to the SaveName method will even compile. Also, if I ever change SaveName, no chance that code will break (at runtime).