31–40 of 93 posts
I really hope I can do something like
for (
ra I hope they'll integrate a JavaScript debugger to TypeScript and Visual Studio, possibly with source mapping. (I would specifically need Node.js debugging). I also hope that they make a better module system.. currently it's pretty confusing and I don't really know how to differentiate between TypeScript and Node.js modules.
I think that's the point, there is no difference between TypeScript and Node.js Modules.
I hope they'll integrate a JavaScript debugger to TypeScript and Visual Studio, possibly with source mapping. (I would specifically need Node.js debugging). I also hope that they make a better module system.. currently it's pretty confusing and I don't really know how to differentiate between TypeScript and Node.js modules.
Visual Studio allows you to debug TypeScript directly with source maps if you install the free plugin: http://www.microsoft.com/en-us/download/details.aspx?id=3479...
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.
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()
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.
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 do clever things for you, which often results in inefficient code. 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. (Looping over 1000 elements at the end of a function? CS just allocated a new array which will be dynamically resized at runtime multiple times, allocated 1000 buckets for the elements.)
CoffeeScript also can't make up its mind about whether parens are necessary. Function with multiple params? Not necessary. Chained function, like jQuery? Necessary. Most of the time. Function with no params? Necessary, unless you use the 'do' syntax.
It's a mess.
TypeScript, on the other hand, is designed by respected, experienced language designer Anders Heijlsberg. His language wisdom and overall vision for the language shines through.
Bottom line: Both are better than vanilla JS, I'd say. But I work with CoffeeScript when I have to. I work with TypeScript because I choose to.
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()
Q.async(function*() {
var ra = yield opA();
var rb = yield opB(ra);
yield opC(ra, rb);
})().done();
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.
Why? Let the compiler do the testing for you.
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.
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.
Earlier quoted context omitted.
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).
> 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 understand…
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.