4 ms·

Does optional typing really work? I've always felt (or presumed) that once you start putting types in, it kinda starts spreading everywhere and eventually will

by jeswin 13y ago

Does optional typing really work? I've always felt (or presumed) that once you start putting types in, it kinda starts spreading everywhere and eventually will look like full static typing. I'd rather have tests than types. It is good to see people try different things though, so congrats on release.

sanxiyn 13y ago
Optional typing works. Why wouldn't it?
gregwebs 13y ago
If it spreads everywhere then that is because it is valuable everywhere. With optional typing you decide where types have the most value, so there really isn't a downside. You are probably going to end up using types a lot if you are using projects that already have type declaration files available (from the DefinitelyTyped project).
- awj 13y ago
  > If it spreads everywhere then that is because it is valuable everywhere. Well, there is a downside in that you're now having to choose between adding type annotations where you don't particularly want them or ignoring compiler errors (warnings?). The former puts types everywhere, the latter partially defeats the purpose of static typing and adds "sort out the errors I care about" as another work duty. My understanding is that with typescript you can use .js/.ts files as a relatively coarse mechanism of segregating out your untyped code, but it isn't entirely roses.
  - gregwebs 13y ago
    > ... choose between adding type annotations where you don't particularly want them or ignoring compiler errors ... That is just not the case. Types get inferred. If the inference isn't making it all the way through that means you have dynamic types, not a compilation error. And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly just errors that can't be ignored.
rictic 13y ago
I've used typescript on a few projects now. What I've seen is that when first hacking on some code I use almost no types. Maybe some are inferred, and that's nice, but if not whatevs. As I'm playing with the code though, like when I'm re-reading a function or if I'm trying to debug something, I'll often add in types to see if the compiler can point anything out. In practice this has meant that code that doesn't change much but is called frequently is fully typed, while code that's under more active development is less typed, unless it's tricky. I've only just started playing with the noImplicitAny setting, where the compiler complains loudly about any identifier that it can't figure out a type for. Not sure what I think of it yet. I'd kinda like something that lets me do a targeted noImplicitAny, but it might be enough to just do it at the file level (i.e. these files should be fully typed, these files shouldn't).
tomlu 13y ago
Depends on what you mean. It doesn't spread in the same way that const correctness spreads in C++, i.e. once you add const somewhere you are forced to add it to a bunch of other places as well.
laureny 13y ago
> I'd rather have tests than types. False dichotomy. You want both and you need both.
10098 13y ago
> I'd rather have tests than types. Why? Let the compiler do the testing for you.
ahoge 13y ago
>Does optional typing really work? From my experience with Dart, I'd say it can work really well. Basically, if you just put type annotations at the API boundaries, you already get most of the type related benefits you would get with something like Java or C#. Inside your functions, you can generally omit types. For the tools, there is enough type information floating around to make sense of everything. If you use a literal, the type is known. If you use some annotated function, the type of the return value will be known. If you assign any of these things to "var", the actual type will be remembered. This means you get sanity checks, call-tips, and auto-complete without having to annotate the types there. Putting types at the API boundaries also acts as documentation. It's so much better than writing JSDoc comments. Plus, you get all the benefits right away. It's a very sweet deal.

by jeswin 13y ago

sanxiyn 13y ago

Optional typing works. Why wouldn't it?

gregwebs 13y ago

If it spreads everywhere then that is because it is valuable everywhere. With optional typing you decide where types have the most value, so there really isn't a downside. You are probably going to end up using types a lot if you are using projects that already have type declaration files available (from the DefinitelyTyped project).

awj 13y ago
> If it spreads everywhere then that is because it is valuable everywhere. Well, there is a downside in that you're now having to choose between adding type annotations where you don't particularly want them or ignoring compiler errors (warnings?). The former puts types everywhere, the latter partially defeats the purpose of static typing and adds "sort out the errors I care about" as another work duty. My understanding is that with typescript you can use .js/.ts files as a relatively coarse mechanism of segregating out your untyped code, but it isn't entirely roses.
- gregwebs 13y ago
  > ... choose between adding type annotations where you don't particularly want them or ignoring compiler errors ... That is just not the case. Types get inferred. If the inference isn't making it all the way through that means you have dynamic types, not a compilation error. And yes, ignoring warnings is crazy. TypeScript has very few warnings, mostly just errors that can't be ignored.

rictic 13y ago

I've used typescript on a few projects now. What I've seen is that when first hacking on some code I use almost no types. Maybe some are inferred, and that's nice, but if not whatevs. As I'm playing with the code though, like when I'm re-reading a function or if I'm trying to debug something, I'll often add in types to see if the compiler can point anything out. In practice this has meant that code that doesn't change much but is called frequently is fully typed, while code that's under more active development is less typed, unless it's tricky. I've only just started playing with the noImplicitAny setting, where the compiler complains loudly about any identifier that it can't figure out a type for. Not sure what I think of it yet. I'd kinda like something that lets me do a targeted noImplicitAny, but it might be enough to just do it at the file level (i.e. these files should be fully typed, these files shouldn't).

tomlu 13y ago

Depends on what you mean. It doesn't spread in the same way that const correctness spreads in C++, i.e. once you add const somewhere you are forced to add it to a bunch of other places as well.

laureny 13y ago

> I'd rather have tests than types. False dichotomy. You want both and you need both.

10098 13y ago

> I'd rather have tests than types. Why? Let the compiler do the testing for you.

ahoge 13y ago

>Does optional typing really work? From my experience with Dart, I'd say it can work really well. Basically, if you just put type annotations at the API boundaries, you already get most of the type related benefits you would get with something like Java or C#. Inside your functions, you can generally omit types. For the tools, there is enough type information floating around to make sense of everything. If you use a literal, the type is known. If you use some annotated function, the type of the return value will be known. If you assign any of these things to "var", the actual type will be remembered. This means you get sanity checks, call-tips, and auto-complete without having to annotate the types there. Putting types at the API boundaries also acts as documentation. It's so much better than writing JSDoc comments. Plus, you get all the benefits right away. It's a very sweet deal.