Working on TypeScript 0.9: Generics, Overload on Constants and Performance | Hacker News Reader

Working on TypeScript 0.9: Generics, Overload on Constants and Performance

blogs.msdn.com

39 pointsyread21 comments

I like strongly typed languages and generics, but I see generics as adding a complexity to a type system in order to get around the limitations of the type system.

Javascript, on the other hand, is duck-typed. Everything is the equivalent of generic already. Adding generics to the Javascript wrapper feels awkward and overcomplex and somehow suggests that a point has been missed. Perhaps you feel differently?

How do you guarantee that what is added to a list (for instance) is a Dog, and not a Cat?

If you want strongly typed language support (and I do), then generics make it vastly easier to write maintainable code.

A generic doesn't mean "anything goes" - it means "You will definitely get the thing that you specified".

In Javascript or any other duck-typed language, you don't have that guarantee.

You don't actually care that it's a Dog BTW, just that it has a method called Bark(), if that's what you call on it.

You make sure that your code only puts dog-like objects into the list, either by writing tests or by reading the code and praying. But the system of putting objects into lists is really, really simple.

I see the benefit of strong typing and I use it all the time. Generics are an epicycle that IMHO sits poorly with JavaScript.

Exactly. This is _not_ Javascript. It's Typescript, which compiles into Javascript, but adds in guarantees that, for instance, what I'm getting _is_ a dog.

Typescript is not JavaScript, but all JavaScript is TypeScript, including JavaScript that works as discussed above. It's just a bit funny that in Typescript are both a language that benefits from having generics and a language that doesn't need them.

> You don't actually care that it's a Dog BTW, just that it has a method called Bark(), if that's what you call on it.

This is exactly where TypeScript helps.

With the way TypeScript interfaces work, you can define an interface

  interface Barker {
      Bark();
  }

And have an array of Barkers where each object's class doesn't have to explicitly say that it implements Barker. Ex.

  class Dog {
      Bark() {console.log('woof');}
  }

  class Cat {
      Meow() {console.log('meow');}
  }
  var barkers: Barker[];  // array of Barkers

  barkers.push(new Dog()); // compiles
  barkers.push(new Cat()); // won't compile

Here Dog doesn't have to explicitly declare that it implements Barker. The TypeScript compiler automatically verifies that it does by the fact that it has a Bark() method.

In TypeScript, Arrays already support this level of type checking. With generics, the static type checking will be able to cover a lot more code so that you don't have to depend on writing tests.

I use interfaces all the time, and like generics, they are a way of getting around the limitations of a strict type system, at the cost of making the type system more complex.

I may as well say "Interfaces are an epicycle that IMHO sits poorly with JavaScript."

There are good things about strong typing, but it's astonishing how many language constructs can be thrown away if you don't have it.

Well, yes. You lose huge amounts if you don't have strong typing. After all, "naturally", nothing is strongly typed. Typing was added to languages so that you would have guarantees about what form your data would take.

I agree. I think this was added to make Intellisense work faster.

That has very little to do with it. Generics are helpful in cases where you desire type safety but still want to have reusable code. An example that we have run into is in data tables where we want to insert into and retrieve data from the table. Without generics, we have to write a class for every single different type of table because they each represent different data types. To do this generically now, without generics, we would have to sacrifice type safety. With generics, we will be able to write a generic base data table controller, without sacrificing type safety.

It would look something like this:

class DataTable<T> { Insert(element: T) : void { //insert code }

  Get(row: number) : T {
    //get code
  }

  //more code

}

Then I could subclass that like:

class ProductDataTable extends DataTable<Product> { //Done... No need to rewrite everything }

Or I could just instantiate the base class in an ad hoc fashion:

var productTable = new DataTable<Product>();

In summary, generics will help immensely with common coding tasks.

> I see generics as adding a complexity to a type system in order to get around the limitations of the type system.

that is a truism, so I assume you mean "needless complexity".

You can do without generics, as pre-generics java did. The problem is you end up with a lot of type casts (e.g. cause you can't get something out of a container method that isn't typed "Object"), more run time errors, worse tool support.

Generics aren't that hard or verbose for 90% of the cases, so it's a trade off worth making, imvho.

> I assume you mean "needless complexity".

It's useful, needed complexity, if your language is strongly typed to start off with. Which JavaScript is not.

Of course all complexity comes with cost, and the costs multiply, (a new feature of the type system interacts with all the existing features) even if the complexity is needed it becomes harder to use and understand the more features are added. JavaScript does away with all of that. It has loads of other flaws, but the basic design philosophy is not one that suggests the addition of generics to improve the language.

So if you don't want any static typing, don't use TypeScript. But if you are adopting TypeScript to retrofit some kind of static typing onto your code, and if you use any kind of functional programming helpers (map, reduce, filter, etc.) then generics are basically a necessity.

Otherwise you have two options: define separate methods for mapArrayOfNumbers, mapArrayOfStrings, etc. or have a lot of casts to the ground type and write a lot of code that isn't actually statically typed.

The overload on constants pattern matching is an interesting feature.

How are they planning on structuring the collections methods? Is map going to be on Arrays, and Maps and Lists etc? Or will they utilize some sort of typeclass approach and have them as modular as possible?

They aren't planning to add collection methods, just to provide a means for existing methods like Array#map and Array#filter to be typed. Right now there is no way to write a type signature that says, given an array of numbers and a function from numbers to strings, Array#map returns an array of strings. This allows that.

Looks like some great improvements. In some ways having to declare the generics may slow down coding but will improve quality greatly.

meh. While some constructs are great (class , modules , ...) some others dont make sense at all, unless you are using Visual Studio. Is typescript a javascript for Visual Studio or a language you can really use without MS tools ? Also the fact that you cant compile to 1 file automatically all your scripts and you need either AMD or Common JS defeats the purpose of having modules for client side scripting.

IntelliJ already provides decent support for it, including auto-completion. I assume with the new pull-based type checker similar things can be done for vim, emacs, etc.

It's possible to instruct tsc to compile into called-closure style modules, then concatenate them if you really want that.

That is exactly what we are doing with an in-house TypeScript framework that we have written. The compiler checks the dependencies recursively and then concatenates them in a single file. It is careful not to duplicate dependencies, too.

Reply on news.ycombinator.com