Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing TypeScript 1.7

blogs.msdn.com

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Announcing TypeScript 1.7

#41

Post by mythz »

Arnavion wrote: post #4
lukasm wrote: post #3

Polymorphic this Typing seems like a major change with many possible corner cases. I think Dart .. operator is a better solution newModel.setupBase().setupAdvanced(); becomes newModel..setupBase()..setupAdvanced();

That assumes setupBase(), etc are either void-returning or return the this-instance (newModel). It won't work if each method returns a new instance, such as methods of immutable collections. Edit: Since this is hard to google for, this is called the "cascade operator". The given example is equivalent to: newModel.setupBase(); newModel.setupAdvanced(); That is, it ignores the result of the method and runs the remainin…

> That assumes setupBase(), etc are either void-returning or return the this-instance (newModel).

This is Incorrect, it doesn't assume anything. Dart's method cascades just returns the receiver, it doesn't matter what the method returns, it's value is ignored and receiver is returned instead.

http://news.dartlang.org/2012/02/method-cascades-in-dart-pos...

Since the return value is ignored, it's only useful for methods with side-effects.

Re: Announcing TypeScript 1.7

#42

Post by Sophistifunk »

ebbv wrote: post #24

I remember when MicroSoft tried to make it's own superscript of JS and people said "Hey this is a bad idea. Standards are a thing for a reason and we should all stick to them." That argument was correct then and it's correct now, IMHO. Where is the objection in 2015? Is it just people are so desensitized by other companies attempts to make JS replacements (that for now compile to JS) that another one just doesn't bug…

Having seen pervasive API arity changes that would take 2 hours in Java take a week in Javascript, I couldn't disagree more strongly. Sure, you can write 10x more unit tests to replicate a compile-time type checker, but you basically have to hold a gun to the head of every developer to enforce it. And unless you're the boss, you don't get to hold a gun to your teammates. The compiler does.

Re: Announcing TypeScript 1.7

#43

Post by mynameisvlad »

wtetzner wrote: post #34
ebbv wrote: post #24

I remember when MicroSoft tried to make it's own superscript of JS and people said "Hey this is a bad idea. Standards are a thing for a reason and we should all stick to them." That argument was correct then and it's correct now, IMHO. Where is the objection in 2015? Is it just people are so desensitized by other companies attempts to make JS replacements (that for now compile to JS) that another one just doesn't bug…

Can't you use TypeScript libraries from plain JS?

Of course, since TS compiles down to JS.

Re: Announcing TypeScript 1.7

#44

Post by [deleted] »

yesimahuman wrote: post #40
devsquid wrote: post #35

Earlier quoted context omitted.

No I understand, which is why I think type inference is a much better solution than dynamic typing. I use Python and JS often and I am constantly looking up types of arguments for functions and what their return types is. JSDoc helps, but its pretty tedious. I think dynamic typing is much slower to actually code in.

Personally, I agree with you that, once you know the type system, you're more productive with it. However, TypeScript is new, and can be difficult to transition to for some people. One example is dealing with some gotcha's like adding new properties to things like window: http://stackoverflow.com/questions/12709074/how-do-you-expli...

[deleted]

Re: Announcing TypeScript 1.7

#45

Post by msoad »

swax wrote: post #8
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

Can TypeScript do runtime enforcement at the boundaries between typed and untyped code, though?

No, and you wouldn't want the overhead. You can turn on warnings though if you want to make sure all your code is typed on compile. After compiling all type definitions are stripped and you're left with plain javascript.

How do you enable warnings?

Re: Announcing TypeScript 1.7

#46

Post by devsquid »

yesimahuman wrote: post #40
devsquid wrote: post #35

Earlier quoted context omitted.

No I understand, which is why I think type inference is a much better solution than dynamic typing. I use Python and JS often and I am constantly looking up types of arguments for functions and what their return types is. JSDoc helps, but its pretty tedious. I think dynamic typing is much slower to actually code in.

Personally, I agree with you that, once you know the type system, you're more productive with it. However, TypeScript is new, and can be difficult to transition to for some people. One example is dealing with some gotcha's like adding new properties to things like window: http://stackoverflow.com/questions/12709074/how-do-you-expli...

Is the type system that different from Javascript? I remember looking at it back around 1.0 days and it seemed like basically the same as Javascript, which was one of the reasons I decided not to pursue implementing it in my work.

Re: Announcing TypeScript 1.7

#47

Post by Nitramp »

We're super happy with TypeScript in Angular, it's working great for us, and having the option (!) to easily use it will be great for Angular users.

A note on all the praise for type inference: local type inference is super cool as it saves on a lot of boiler plate (`Foo foo = new Foo(); // foo` anyone?).

But global type inference, i.e. across function and module boundaries, has its drawbacks. Apart from performance cost, the most important is IMHO understandability. If you don't have explicit types across module boundaries, it can easily become hard to decide just what a type is supposed to be, e.g. if your code doesn't compile, but the compiler cannot tell you which part of it is wrong, because all the types are inferred. That can easily lead to "wall of text" C++ compiler style error messages. Same if some new library version changes type inference patterns, your code might suddenly break in surprising and hard to understand ways.

I think TypeScript's (& Go's) choice of local type inference is a good mix of less boilerplate and good understandability, together with gradual typing via `any`.

Re: Announcing TypeScript 1.7

#48

Post by DCoder »

msoad wrote: post #45
swax wrote: post #8

Earlier quoted context omitted.

No, and you wouldn't want the overhead. You can turn on warnings though if you want to make sure all your code is typed on compile. After compiling all type definitions are stripped and you're left with plain javascript.

How do you enable warnings?

swax is probably referring to the compiler option "noImplicitAny", which can literally turn variables whose type is not explicitly specified and cannot be inferred from their declaration as errors, instead of assuming they have the transparent `any` type.

Re: Announcing TypeScript 1.7

#49

Post by aikah »

haberman wrote: post #26
carterehsmith wrote: post #5

To me, this appears to be the way to go. Javascript + Typescript. Rather than deciding on weak (dynamic) typing vs strong typing, you pick both - incremental typing, as allowed by Typescript. Want to bang up a quick solution, as in MVP? Use bare-bones Javascript, it is all valid Typescript. So you get dynamic typing. And if you do not care about strong typing, you can just stop right there. But if you, some day, for…

How is this different from using Facebook Flow? I have been using Flow on a JavaScript project, along with Babel for ES6, and enjoying the experience quite a lot.

Flow doesn't run on Windows and isn't written in Javascript.

Re: Announcing TypeScript 1.7

#50

Post by aozgaa »

trevordev wrote: post #23

Typescript has became my favorite language. The option of having types when you need them is great and the addition of async/await make working with promises a lot nicer. Ever since I've been able to use experimental features and get es6 support with typescript I've never looked back. The only thing lacking now is the tooling. The atom-typescript plugin is the best I've found but I would love to see better integratio…

I can't speak to atom, but have you considered Visual Studio Code? That and VS2015 are tightly integrated with the TypeScript compiler and language service (provides autocomplete, type hinting, go-to definition, etc.).

For sublime, there is a plugin actively developed by Microsoft [1].

For vim, the plugin YouCompleteMe provide autocomplete [2].

Also, I haven't tried it, but there's an Emacs-mode, apparently [3].

There are also numerous other alternatives I'm unfamiliar with.

Hope this helps!

[1] https://github.com/Microsoft/TypeScript-Sublime-Plugin

[2] http://valloric.github.io/YouCompleteMe/#intro

[3] https://github.com/aki2o/emacs-tss

Post reply on HN