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

Why does TypeScript have be the answer to anything?

hanselman.com

Post reply on HN
Print view View original

51–60 of 82 posts

Re: Why does TypeScript have be the answer to anything?

#51

Post by scott_s »

lindenr wrote: post #36
scott_s wrote: post #24

Earlier quoted context omitted.

He means that the semantics of Dart - including the data types provided by Dart - are different from JavaScript. This is in opposition to TypeScript, which is a superset of JavaScript, which means that it necessarily shares JavaScrips semantics. If your example bothers you, consider that JavaScript just happens to be a target language for the Dart compiler. That is, it takes a program with Dart's semantics, and figur…

Really? Wow, that's cool. Can I have a reference?

I'm really just describing how a compiler works. Are you looking for references on the compilation process? There's a classic series called "Let's Build a Compiler" (http://news.ycombinator.com/item?id=1727004) available online that walks through building a simple compiler. Then there's also actual textbooks, but I was not impressed with either of the two textbooks I've had on the topic. Many people recommend "Compilers: Principles, Techniques, and Tools" (http://dragonbook.stanford.edu/) also referred to as just the dragon book. If you're not averse to textbooks, you may also want to check out Michael Scott's "Programming Language Pragmatics" (http://www.cs.rochester.edu/~scott/pragmatics/).

Re: Why does TypeScript have be the answer to anything?

#52

Post by JackC »

jmmcd wrote: post #38

This isn't exactly the right place, but I don't know where else to ask this. When people argue for static types (whether optional as in TypeScript or mandatory), one of the main reasons is "tooling". Why? I know that writing a "go to definition" function for your IDE is impossible to do 100% correctly, when types are dynamic. But I would've thought it'd be pretty easy to do a 99% implementation, which rarely fails if…

I came to ask a similar question -- how much better is IDE support for statically typed languages than, for example, JetBrains' IDE support for Python, Javascript, CoffeeScript, etc? They offer code-completion, live error highlighting, go-to-declaration, refactoring (with a confirmation step if it's ambiguous), all that good stuff.[1] The interface asks for clarification when it's not sure what something refers to. It seems to work pretty well. I don't really use typed languages, though, so I don't know how much I'm missing. Can anyone comment based on experience with both?

(I actually also came to say, damn, y'all, IDE support is awesome, and it's here for dynamic languages. Go-to-declaration alone is lifechanging, since it's usually faster to jump into a library call with ctrl-B than to check the docs. Live error highlighting alone is worth it. Just give JetBrains whatever they ask for.)

[1] http://www.jetbrains.com/pycharm/features/index.html

Re: Why does TypeScript have be the answer to anything?

#53

Post by jmmcd »

JohnBooty wrote: post #50
jmmcd wrote: post #41

Earlier quoted context omitted.

I'm not saying that tooling isn't nice. On the contrary. I'm asking why can't we have tooling even with dynamic types.

Think about this pseudocode; imagine it's The Hot New Dynamic Language Of The Week. print "Which do you like better: cars or trees? let a = AskUserForInput() var b if a=="cars" then b = new Car() elseif a=="trees" then b = new Tree() endif b.DriveOnExpressway() Clearly, that's not going to work out too well if the user picks "trees" but it's tough to spot before run time. While that's a contrived and simplistic examp…

Ok, if I understand you right, your point is that a tool like a linter will fail to warn about this error. I'm not sure what current (say) Python linters do in situations like that.

But a tool like "go to definition" would work fine, wouldn't it? Maybe you would need a heuristic that guesses what are the possible types b could have, and detects that Tree doesn't have DriveOnExpressway, so it takes you straight to the definition in Car. Certainly, there are more complicated cases where guessing b's type is harder or impossible. I'm not denying that.

Re: Why does TypeScript have be the answer to anything?

#54

Post by JackC »

JohnBooty wrote: post #50
jmmcd wrote: post #41

Earlier quoted context omitted.

I'm not saying that tooling isn't nice. On the contrary. I'm asking why can't we have tooling even with dynamic types.

Think about this pseudocode; imagine it's The Hot New Dynamic Language Of The Week. print "Which do you like better: cars or trees? let a = AskUserForInput() var b if a=="cars" then b = new Car() elseif a=="trees" then b = new Tree() endif b.DriveOnExpressway() Clearly, that's not going to work out too well if the user picks "trees" but it's tough to spot before run time. While that's a contrived and simplistic examp…

I was curious what PyCharm would handle that. Here's a screenshot: http://imgur.com/IvwG5

Basically it will complain if neither Car or Tree have a DriveOnExpressway method, but it's fine if one of them does -- the warning goes away if I uncomment the method. So there's ways to fall through the safety net, but lots of things it will catch.

(In Javascript, it's looser -- it only flags a potential problem if "DriveOnExpressway" isn't defined at all in the file.)

Re: Why does TypeScript have be the answer to anything?

#56

Post by aaronblohowiak »

jconley wrote: post #55

The Typescript syntax looks shockingly like Adobe's ActionScript. Next up, Adobe releases an ActionScript to Javascript cross compiler?

Do you know the history of ES4? http://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Ed...

Re: Why does TypeScript have be the answer to anything?

#57

Post by dodyg »

jmmcd wrote: post #38

This isn't exactly the right place, but I don't know where else to ask this. When people argue for static types (whether optional as in TypeScript or mandatory), one of the main reasons is "tooling". Why? I know that writing a "go to definition" function for your IDE is impossible to do 100% correctly, when types are dynamic. But I would've thought it'd be pretty easy to do a 99% implementation, which rarely fails if…

Try the TypeScript playground http://www.typescriptlang.org/Playground/ . You can do rename, intellisense, find reference, etc directly from your browser.

TypeScript language service is developed in TypeScript. This is how they can host these type of function on the browser. It's all just JavaScript

Check out this screenshot from the playground http://i.imgur.com/H2rqD.png

Re: Why does TypeScript have be the answer to anything?

#58

Post by disordinary »

oinksoft wrote: post #20
dreamdu5t wrote: post #14

Earlier quoted context omitted.

Poor state of JavaScript development? By what measure? I've been doing "application-scale" development using JavaScript for 5 years... Not once did I think "gee my development process would be better if I had rigid typing." The notion is laughable. The lack of rigid typing and classes is by design. This is a feature not a bug. I honestly wonder about a programmer's understanding of JavaScript if they say things like…

Types are not classes! Why do people feel the need to constantly drag out this scarecrow? Having tools to perform static analysis is nothing but a good thing, and you need type data to do a great deal of this. Perhaps your project requirements are such that you never require type checking for your JS, but I can say that it's saved my ass a number of times when working on very large code-bases, and definitely has sped…

The JSDoc system gets in the way too much, how for instance do you type variables which is something like:

  /** @type {myType} */ var thing = new myType( );
It gets way to verbose when compared to typescript which is something like:

  var thing : myType = new myType( );

Re: Why does TypeScript have be the answer to anything?

#59

Post by oinksoft »

disordinary wrote: post #58
oinksoft wrote: post #20

Earlier quoted context omitted.

Types are not classes! Why do people feel the need to constantly drag out this scarecrow? Having tools to perform static analysis is nothing but a good thing, and you need type data to do a great deal of this. Perhaps your project requirements are such that you never require type checking for your JS, but I can say that it's saved my ass a number of times when working on very large code-bases, and definitely has sped…

The JSDoc system gets in the way too much, how for instance do you type variables which is something like: /** @type {myType} */ var thing = new myType( ); It gets way to verbose when compared to typescript which is something like: var thing : myType = new myType( );

Actually that's not quite accurate. The Closure Compiler doesn't need you to tell it that `thing` is a myType, it knows that, asuming myType is defined in your compiled code, or you provide an extern specifying what myType means. And I might be wrong about that last bit even; the compiler may always know that `new Foo` returns a {Foo} regardless of context ... I would have to check the compiler source to be certain.

Also, I think that the first example is more likely to be written as follows (in the case where type data cannot be inferred):

  /**
   * Description of the variable.
   *
   * @type {my.UnionType}
   */
  var foo = { ... };
Whatever "..." may be. It's common to document the meaning of variables where explicit typing like this is important, just like in well-documented Java and PHP code.

Re: Why does TypeScript have be the answer to anything?

#60

Post by jmmcd »

dodyg wrote: post #57
jmmcd wrote: post #38

This isn't exactly the right place, but I don't know where else to ask this. When people argue for static types (whether optional as in TypeScript or mandatory), one of the main reasons is "tooling". Why? I know that writing a "go to definition" function for your IDE is impossible to do 100% correctly, when types are dynamic. But I would've thought it'd be pretty easy to do a 99% implementation, which rarely fails if…

Try the TypeScript playground http://www.typescriptlang.org/Playground/ . You can do rename, intellisense, find reference, etc directly from your browser. TypeScript language service is developed in TypeScript. This is how they can host these type of function on the browser. It's all just JavaScript Check out this screenshot from the playground http://i.imgur.com/H2rqD.png

Typescript has static type annotations. All those things are already easy in that context.
Post reply on HN