Does anybody know whether Typescript still filters comments?
Announcing TypeScript 0.9.1
61–70 of 116 posts
Re: Announcing TypeScript 0.9.1
#62Earlier quoted context omitted.
Saved a ton of time letting a compiler catch things instead of writing tests. Types should never mean writing less tests :/
Static typing means automatic language-integrated type-checking unit tests. I would bet a lot of dynamic language unit testing has to do with compensating for the lack of proper type checking. It's just like using patterns compensates for lacking language features.
I don't like to think about type checking as unit tests because they approach the problem from a fundamentally different direction, and I worry conflating them could lead to writing the sort of bad unit tests people are talking about here.
Type checking, or static analysis in general, checks for the presence of a particular class of errors.
Unit tests check for correct behaviour, and in doing so imply a lack of any errors, types or otherwise.
While it can be good to use unit tests to check for regressions in a specific error, the core of your tests should be specifying the behaviour of your system, not trying to catch out any specific class of errors.
If your tests are busy looking for specific errors, there will always be some that you miss (type checking, even in Haskell, misses a lot of classes of error). If your tests check for correct behaviour, there can be no errors.
Of course, writing tests with perfect coverage and specifying all the behaviour is impossible, even more so when you've got actual features to get out the door. So any static analysis you're comfortable with can be great for making up some of the slack, but let's not pretend that in most cases we shouldn't now need to be writing those tests to check it does what it's meant to.
The place where this approach sometimes falls short is on the public API boundary, as I mentioned in my other post. Types can be useful there, so maybe my original assertion was a little too strong, but still types should very rarely mean less tests.
(Apologies if the post is a bit all over the place, redrafting on a phone is hard)
Re: Announcing TypeScript 0.9.1
#63We need support for it in something like Monodevelop / Netbeans / Eclipse. A lot of the benefit I experience from strict(er) typing comes from the real-time help an IDE gives me - without a Windows/VS licence, I hardly feel compelled by Typescript at all.
Re: Announcing TypeScript 0.9.1
#64We need support for it in something like Monodevelop / Netbeans / Eclipse. A lot of the benefit I experience from strict(er) typing comes from the real-time help an IDE gives me - without a Windows/VS licence, I hardly feel compelled by Typescript at all.
works well with webstorm/phpstorm but i agree , useless without realtime help in a IDE.
Sometimes the compiler issues an error it is really hard to get what's wrong without visual clues , unless one likes to count lines and columns and switch between command line / text editor all the time.
Does the TS compiler even work with Syntastic(vim) by the way ?
I like TS , i use modules , classes and short hand functions declarations , but not the type system which doesnt make sense to me. It doesnt make sense with javascript and force back devs in all these java EE like patterns.
Re: Announcing TypeScript 0.9.1
#65Am justing waiting for them to implement "await".
I think you might be waiting for awhile unfortunately. Implementing await would result in a lot of autogenerated code. Typescript is largely meant to be almost 1:1 with the Javascript it produces. Anders talks about that problem in this video: http://channel9.msdn.com/Events/Build/2013/9-006
There's also a discussion[1] at Codeplex on some TypeScript compatible alternatives to async/await.
Re: Announcing TypeScript 0.9.1
#66I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a big fan of TypeScript's approach, which gives you the best of both worlds. Start with fully dynamic code to explore the problem space, then add more static guarantees as you firm up your design. I haven't had occasion to write a big web app recently, but I'm itch…
I was in the same position for literally years regarding static vs dynamic. I've concluded that C gets it spot on i.e. it's mostly static with associated guarantees but you can use a void* if you need it.
Re: Announcing TypeScript 0.9.1
#67I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a big fan of TypeScript's approach, which gives you the best of both worlds. Start with fully dynamic code to explore the problem space, then add more static guarantees as you firm up your design. I haven't had occasion to write a big web app recently, but I'm itch…
I was in the same position for literally years regarding static vs dynamic. I've concluded that C gets it spot on i.e. it's mostly static with associated guarantees but you can use a void* if you need it.
Probably the single worst conclusion someone can arrive at regarding typing.
Re: Announcing TypeScript 0.9.1
#68Earlier quoted context omitted.
I was in the same position for literally years regarding static vs dynamic. I've concluded that C gets it spot on i.e. it's mostly static with associated guarantees but you can use a void* if you need it.
Probably the single worst conclusion someone can arrive at regarding typing.
Rather than slate me, some constructive discussion would be nice. I'll go from my side:
1. Static type compiler verification saves tonnes of problems. Try managing a 2MLOC dynamically typed solution and you'll get what I mean.
2. Static typed languages are way easier to refactor as more metadata is available to the tooling.
3. Static typed code is easier to test. The type contract is available over the boundary between the implementation and the test cases.
4. Defined interfaces without leaky abstractions are easier to produce when you have static types.
5. Static types allow the compiler to infer more information about how to compiler your code resulting in faster, more efficient code and lower memory usage plus you don't have to compile an instance of a function with every possible type consideration at runtime.
6. Statically typed data serialises more reliably i.e. goes over the wire easier without behemoth contracts and parsers at each end.
7. Statically typed languages tend to have better numeric accuracy as differences between decimal, floats and integers are always deterministic and there are defined casts and conversions between each during operations.
I could go on...
Re: Announcing TypeScript 0.9.1
#69Does anyone have experience with using TypeScript with existing libraries like Angular.js? I know that there are definition files for it [1] (and many other popular libraries), but unfortunately I haven't had the time to check out their quality. [1] https://github.com/borisyankov/DefinitelyTyped/tree/master/a...
We are building a webapp using TypeScript and Angularjs and we are quite happy. It takes some time to set up everything, we even created our own yeoman generator, but at the end I think it's worth it.
That seems like pretty awesome, are you hiring?
Re: Announcing TypeScript 0.9.1
#70Earlier quoted context omitted.
Probably the single worst conclusion someone can arrive at regarding typing.
Rather than slate me, some constructive discussion would be nice. I'll go from my side: 1. Static type compiler verification saves tonnes of problems. Try managing a 2MLOC dynamically typed solution and you'll get what I mean. 2. Static typed languages are way easier to refactor as more metadata is available to the tooling. 3. Static typed code is easier to test. The type contract is available over the boundary betwe…
Your heart is in the right place, but you're stuck with a bad example still.
C is hardly a good representative for an statically typed language. Read Luca Cardelli's "Typeful Programming"[1] to get an overview of what typed programming is all about, and see for yourself how brain-dead C and C++ are in comparison. After that go to Benjamin Pierce's canon, "Types and Programming Languages".