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

41–50 of 82 posts

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

#41

Post by jmmcd »

winteriscomming wrote: post #40
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…

Go to function definition, refacor/rename, find references, view object / class hierarchy, and so on. Why not have all this work 100% of the time? Tooling makes your life so much easier. I don't understand why people would resist optional typing.

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.

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

#42

Post by winteriscomming »

dreamdu5t wrote: post #14
ivanjovanovic wrote: post #2

The way I see it: 1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain. 2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain.…

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…

You are entitled to your opinion but many developers disagree and want some more structure in the programming model. The very fact that many people are trying so hard to come up with some solution to JS means that there are significant problems worth fixing. If you don't see these problems or have them then that's great for you.

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

#43

Post by jes5199 »

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…

Yeah, I think it might be a programming-language cultural thing. Most refactoring tools are written for Java and C#, so the people with experience writing refactoring tools have worked out how to solve the problems when they have certain assurances. But it really should be possible to write usable refactoring tools for ruby and python and javascript - you'll have to do a little more work to figure out name collisions between variables and methods and there's going to be ambiguous metaprogramming stuff like using strings to lookup instance variables, but having good tooling in the cases where you weren't using metaprogramming might encourage programmers to use a more concrete coding style, and that's probably a good thing. (Java has the same problems when you use a lot of reflection. So people don't use much reflection!)

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

#44

Post by winteriscomming »

jmmcd wrote: post #41
winteriscomming wrote: post #40

Earlier quoted context omitted.

Go to function definition, refacor/rename, find references, view object / class hierarchy, and so on. Why not have all this work 100% of the time? Tooling makes your life so much easier. I don't understand why people would resist optional typing.

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.

It is just much more difficult to have tooling since the tools cannot know for sure what the program is doing (and neither can another human looking at it).

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

#45

Post by seanmcdirmid »

winteriscomming wrote: post #44
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.

It is just much more difficult to have tooling since the tools cannot know for sure what the program is doing (and neither can another human looking at it).

To be more specific you have to use some crazy static analysis technology (global interprocedural analysis) that is intractable unless you sacrifice accuracy. Human have similar problems as compilers/tooling, though they are a bit better at understanding nuanced conventions to make better judgements about what dynamic code is doing.

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

#46

Post by seanmcdirmid »

TazeTSchnitzel wrote: post #32
benatkin wrote: post #12

The author ignores the fact that TypeScript is being heavily promoted by Microsoft. TypeScript isn't an experiment, but something Microsoft is trying to sell, along with their IDE. He starts it with a quote from a colleague rather than citing examples of people attacking TypeScript, as if it's a forgone conclusion that people have gone overboard on attacking it. I hate to see an argument for a programming language st…

>Microsoft is trying to sell Do you mean sell as in for money? Or sell as in get people to adopt? Under an Apache license, I doubt it's the former. Although they could sell the Visual Studio tooling.

Use the tooling to sell the platform? It might be in Microsoft's interest to have some mindshare I this space; JavaScript is a significant part of the windows 8 story from what I can tell.

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

#47

Post by jmmcd »

seanmcdirmid wrote: post #45
winteriscomming wrote: post #44

Earlier quoted context omitted.

It is just much more difficult to have tooling since the tools cannot know for sure what the program is doing (and neither can another human looking at it).

To be more specific you have to use some crazy static analysis technology (global interprocedural analysis) that is intractable unless you sacrifice accuracy. Human have similar problems as compilers/tooling, though they are a bit better at understanding nuanced conventions to make better judgements about what dynamic code is doing.

Yes, of course, we sacrifice accuracy. I said so at the very start. But imagine a "go to definition" tool that works correctly for 99% of cases and barfs or goes to the wrong place on the others. If the alternative is no tool at all, that still sounds pretty useful!

I admit there are cases (refactoring is an example) where if you don't trust the tool 100% you won't use it. But many tools are not like that.

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

#48

Post by jmmcd »

jes5199 wrote: post #43
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…

Yeah, I think it might be a programming-language cultural thing. Most refactoring tools are written for Java and C#, so the people with experience writing refactoring tools have worked out how to solve the problems when they have certain assurances. But it really should be possible to write usable refactoring tools for ruby and python and javascript - you'll have to do a little more work to figure out name collisions…

YES! And I bet that a little bit of heuristics, a little bit of machine learning, and/or a little bit of user feedback (say, a button that tells the tool it went to the wrong function definition) would help such a tool cover a few more of the difficult cases.

This ought to be a classic case of "worse is better", which is why I'm surprised to see that people seem to shy away from it.

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

#49

Post by rmrfrmrf »

ivanjovanovic wrote: post #2

The way I see it: 1. TypeScript is an answer to the poor state of JavaScript development today and an attempt to get more structure into it. There are other answers as well, and it can be discussed on properties of each of them, but they are competing in the same domain. 2. Since state of JavaScript is as it is, it is obvious that there is a lot of potential benefit in being a leader of the technology in that domain.…

To me, TypeScript is the answer to 1) the perceived quirkiness of JavaScript to those who are unfamiliar with it and 2) an increasing number of developers coming out of college with heavy Java backgrounds. I see TypeScript taking off mainly because of the latter point--strict typing and well-defined OO practices will act as a decent safety net for new developers.

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

#50

Post by JohnBooty »

jmmcd wrote: post #41
winteriscomming wrote: post #40

Earlier quoted context omitted.

Go to function definition, refacor/rename, find references, view object / class hierarchy, and so on. Why not have all this work 100% of the time? Tooling makes your life so much easier. I don't understand why people would resist optional typing.

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 example (that you probably could somewhat easily detect with tooling/analysis) think about a language like Javascript where there are no classes and you may be adding or modifying a bunch of an object's methods at runtime. At coding time, the tooling doesn't even know if foo has a .bar() function, much less which .bar() function, much less if the particular .bar() function that foo may have is being called with acceptable parameters.

edit: even my pseudocode is buggy ;-)

Post reply on HN