Live data from Hacker News

TypeScript and the Road to 1.0

blogs.msdn.com

41–50 of 93 posts

Re: TypeScript and the Road to 1.0

#41

To me the fundamental shortcoming for javascript is not its typelessness, it's the lack of language syntax support for asynchronous programming, which is the butter and bread for most javascript applications (server or client side). I really hope I can do something like for ( ra ).run()

So if you used Q or a similar library: Q.async(function*() { var ra = yield opA(); var rb = yield opB(ra); yield opC(ra, rb); })().done(); Are you wishing for the other syntax or something that you can't achieve with generators/promises today?

Fortunately, with a bit of hacking, this style of syntax is possible without generators :) (I'm hoping to open source a library I wrote that works all the way back to IE6)

Here's your example rewritten in the 'monads' library (I probably need a better name):

monads(function() { var ra = opA.defer(); var rb = opB.defer(); var result = opC(ra(), rb()); });

Re: TypeScript and the Road to 1.0

#42
post #21

Earlier quoted context omitted.

This. TypeScript is a tool to sell Visual Studio, nothing more. If people are leaving VS because it can't do the magic things to JavaScript that it can to C# that's a big thread to Microsoft. TypeScript is about protecting the thing that makes them money.

Some people see a conspiracy everywhere. Get help! The more likely conclusion is Microsoft is open-sourcing a tool the found useful internally when building large JavaScript apps.

Who said anything about a conspiracy? Conversation probably went something like:

Suit: People aren't using Visual Studio for JavaScript, why not?

VS PM: We can't do Intellisense properly, so people are using Sublime.

Suit: What can we do about that?

Anders: Let's create our own language that works better with VS.

Re: TypeScript and the Road to 1.0

#43
post #36
post #11

Earlier quoted context omitted.

Are TypeSscript and CoffeeScript really that much different? From what I understood, they both basically solve the same problems, one just does it in a Ruby-esque style while the other does it in a C#-esque style.

I use CoffeeScript in my day job for the last 2 years. I've been using TypeScript in my startup the last 6 months. They are definitely not the same. TypeScript is JavaScript + types, whereas CoffeeScript is a new language, a mashup of Ruby and JS. (For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. But you absolutely cannot do this in CoffeeScript.) CoffeeScript tries to…

I guess I should have phrased it better -- that both are basically trying to "improve" upon perceived faults in vanilla JS, as well as adding perceived useful functionality. It's just that "improve" and "useful" is an implementation-specific definition that's defined by the particular project owners.

Thanks for the thorough info though, I've only used TS a little and CS none at all, though from what I've seen I'd side with you in that CS tries to be too clever and/or is too foreign for my non-Ruby brain, whereas TS more closely melds with my skillset.

Re: TypeScript and the Road to 1.0

#44
post #21

Earlier quoted context omitted.

This. TypeScript is a tool to sell Visual Studio, nothing more. If people are leaving VS because it can't do the magic things to JavaScript that it can to C# that's a big thread to Microsoft. TypeScript is about protecting the thing that makes them money.

Rubbish. TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively, hence its rather quick adoption internally. Channel 9 has quite a lot of information about who is using it. It does help Visual Studio and other tooling, but to say it is only "to sell Visual Studio, nothing more" is ridiculous.

> TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively,

This implies that you can't develop large scale apps without type checking, which obviously isn't true.

What's more likely is that Microsoft hires a lot of developers that know the "VS way" of coding, which is using intellisense and type checking, and they made a language that conformed to that. Which is the same thing as I originally said.

Re: TypeScript and the Road to 1.0

#45
post #11

I couldn't be more underwhelmed by what TypeScript has to offer vs vanilla JavaScript or CoffeeScript. Reading through the marketing material from MS it seems like the entire value proposition is "statically typed languages make it easier to think about your program, also we added the class keyword so you don't feel lost" I suppose if you believe those claims or are really interested in using MS development tools, Ty…

Are TypeSscript and CoffeeScript really that much different? From what I understood, they both basically solve the same problems, one just does it in a Ruby-esque style while the other does it in a C#-esque style.

>[TS and CS] both basically solve the same problems

TS (or Dart) makes JS more toolable and thus more scalable. CS, on the other hand, just offers a keystroke reduction by dropping the "function" keyword, semicolons, and other punctuation.

TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything.

Re: TypeScript and the Road to 1.0

#46

To me the fundamental shortcoming for javascript is not its typelessness, it's the lack of language syntax support for asynchronous programming, which is the butter and bread for most javascript applications (server or client side). I really hope I can do something like for ( ra ).run()

> it's the lack of language syntax support for asynchronous programming

    spawn(function*() {
        var ra = yield async_opA();
        var rb = yield async_opB(ra);
        yield async_opC(ra, rb);
    });
This works right now in Gecko: http://taskjs.org/. Something very close ought work in ES6/Harmony.

Re: TypeScript and the Road to 1.0

#47
post #44

Earlier quoted context omitted.

Rubbish. TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively, hence its rather quick adoption internally. Channel 9 has quite a lot of information about who is using it. It does help Visual Studio and other tooling, but to say it is only "to sell Visual Studio, nothing more" is ridiculous.

> TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively, This implies that you can't develop large scale apps without type checking, which obviously isn't true. What's more likely is that Microsoft hires a lot of developers that know the "VS way" of coding, which is using intellisense and type checking, and they made a language that conformed to that. Which is the same thing as…

Nope, and incidentally its not the same thing you originally said at all

productively

You missed the most important word.

As someone who has spent quite some time on Javascript codebases its amazing how quickly things break down when you get developers of different levels working on the same codebase. Optional typing allows a whole batch of problems to be caught way before weird errors/exceptions client-side. Productivity goes way up when the tooling can check basic errors.

(Part of me still wishes Haskell was an option for web scripting but I can dream)

Re: TypeScript and the Road to 1.0

#48
post #44

Earlier quoted context omitted.

> TypeScript is more of a way for Microsoft to develop large scale JavaScript apps productively, This implies that you can't develop large scale apps without type checking, which obviously isn't true. What's more likely is that Microsoft hires a lot of developers that know the "VS way" of coding, which is using intellisense and type checking, and they made a language that conformed to that. Which is the same thing as…

Nope, and incidentally its not the same thing you originally said at all productively You missed the most important word. As someone who has spent quite some time on Javascript codebases its amazing how quickly things break down when you get developers of different levels working on the same codebase. Optional typing allows a whole batch of problems to be caught way before weird errors/exceptions client-side. Product…

You're wrong, it can be done productively, the evidence is the thousands (tens of thousands?) of such apps that exist on the web, most of which were written in regular JavaScript.

Re: TypeScript and the Road to 1.0

#49
post #36
post #11

Earlier quoted context omitted.

Are TypeSscript and CoffeeScript really that much different? From what I understood, they both basically solve the same problems, one just does it in a Ruby-esque style while the other does it in a C#-esque style.

I use CoffeeScript in my day job for the last 2 years. I've been using TypeScript in my startup the last 6 months. They are definitely not the same. TypeScript is JavaScript + types, whereas CoffeeScript is a new language, a mashup of Ruby and JS. (For example, you can take any JS on the web, paste it in a TypeScript file, and it will compile. But you absolutely cannot do this in CoffeeScript.) CoffeeScript tries to…

> For example, say you've got a function that ends with a for loop. CoffeeScript will actually convert that into an array allocation and return the result of the array.

Simple, just return anything else, or nothing at all:

    myFn = () ->
      for el of array
         # loop body
      return
> CoffeeScript also can't make up its mind about whether parens are necessary.

Well, in some cases they're optional, but it's predictable and hardly "can't make up its mind". I've never run into a problem with this. Implicit parens wrap to the end of a line or block expression, and it feels pretty natural:

    f g h obj ->  f(g(h(obj)))
    f g, h, obj -> f(g, h, obj)
    f().g().h obj -> f().g().h(obj)
Every time there's a space, you're introducing a new fn call. Every time there's a comma, it's adding a parameter to the fn call. So yeah, you will have to use parens for any chaining style (a la jQ and many others), and to disambiguate complex nested fn calls, but that's expected.

I prefer to think of parens as sometimes optional.

Re: TypeScript and the Road to 1.0

#50

To me the fundamental shortcoming for javascript is not its typelessness, it's the lack of language syntax support for asynchronous programming, which is the butter and bread for most javascript applications (server or client side). I really hope I can do something like for ( ra ).run()

[deleted]
Post reply on HN