I 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 itching to find one so I can put TypeScript through its paces.
I think the greatest advantage to static typing is the IDE support. Compile-time error checking is overrated, and in my several years of writing JavaScript, I've never seen a bug in production that could have been prevented with static analysis. That might be because I know the language well, but it's not a feature I need.
"What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey
Your point is well taken, but I think it has value. Compile-time error checking is useful because it gives you flexibility to make changes in a big program. It's kind of like a big suite of automatic tests that make sure all the parts of your program talk to each other correctly.
Does it catch everything? Can you stop thinking critically? No, but it's still nice to have.
This sort of goes hand in hand with IDE tools (e.g. "change method name" sorts of things), so I don't think we necessarily disagree.
> I've never seen a bug in production that could have been prevented with static analysis.
That seems unlikely to me.
I do application penetration testing for a living, and I'll often use static analysis tools in my work. (Both robust, established tools and ad hoc scripts.) For example, check out Brakeman for Rails apps. These tools find actual bugs in actual production software.
Do they find everything? No, you can't rely on them completely. But they're still nice to have.
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.
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.
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".
I don't think it's fair to call C++s type system 'brain-dead' when it was developed pragmatically to be largely source compatible with C.
It introduced stronger array types, eliminated Cs automatic void* -> T* conversion and, most importantly, put higher-order functions and types on the table.
It might be a warty syntactical abomination, but it can still hold its own against some of the languages of type extremism.
C has very simple types and allows for untyped operations very easily. Say you cast some ptr of type void* to Foo*: at least in Python you would get a dynamic type error if the cast was incorrect; in C you are lucky if your program immediately crashes.
C has some static type safety, and virtually no run-time type safety. Java on the other hand, has a lot of static type safety, is completely memory safe (barring bugs in the implementation), and checks all coercions dynamically. Python has what Java has dynamically, and nothing statically, but it is still 10 times better than what C has!
That's what we have valgrind, test cases and decent software engineers for.
Java don't forget suffers as do other languages from lots of nasty things related to types including invalid casts, null reference exceptions etc. When these go phut in production, you're usually in the same situation.
Java is not a good example of a statically typed language. Null pointer exceptions just don't happen in idiomatic Scala. For example, let's say I have 3 functions a,b and c, each with signature Int => Option[Int]. Any one of these can return Some[Int] or None.
Options, like all collections, can be chained together as such:
for {
x <- a(1)
y <- b(x)
z <- c(y)
} yield z
this expression is of type Option[Int], and will never throw a null pointer exception. (Futures can be chained together with identical syntax)
5 is not entirely correct.
6 is not true, serialisation in dynamic languages is correctly done with type definitions.
7 is not true at all, mainstream statically typed languages (like C) much more commonly overflow silently. Look at Python, there's no way to lose precision through arithmetic, as types get promoted on overflow correctly.
In general, C's type system is so weak as to be both useless and a hindrance.
6. It's still necessary (or at least a good idea) to write serialisation models for most statically typed languages as well. the difference is minor
7. It's a float, unless you made it a Decimal explicitly. Arguably that's the wrong default, but almost no languages default to arbitrary precision/size everything.
No, C's type system is totally unsound. It fails to catch very bad errors (pointer-related issues, null-related issues, etc.) and is perfectly happy to implicitly cast left and right. It's little more than a hindrance.
void* is used rarely in practice, apart from perhaps kernel mode or language VM's. I have a 150kloc program in front of me which doesn't have a single void*.
You have a typed pointer to a function but that's not a void pointer and the "New C Standard" 6.3.2.3 states that you can't cast a function pointer to a void*.
int sqlite3_exec(
sqlite3*, /* An open database */
const char *sql, /* SQL to be evaluated */
int (*callback)(void*,int,char**,char**), /* Callback function */
void *, /* 1st argument to callback */
char **errmsg /* Error msg written here */
);
Here the void * is an argument that is passed in the callback as well so that you can update your own struct with the result, for example. Singe the library cannot know anything about your types, void * is the only option.
Does 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.
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.
i do, i built up an infrastructure around angular with typescript, and requirejs honestly it was a pain in the butt to figure out all the stuff required, but that could be because my company is new at webdev so we are learning webdev techniques at the same time.
I haven't heard much about TypeScript since its original announce. Are any big projects using it? Does anybody have some commentary on their experience using it and where they think the project is going?
My project isn't huge, but larger than it could have been using idiomatic javascript.
The scoping with modules and the typing really helped since I'm familiar with C# and having "everything light up" in the IDE. Saved a ton of time letting a compiler catch things instead of writing tests.
I tried coffee script, but found the copy/paste option for javascript that I have already written won me over.
Exactly my feelings about it. Being able to specify types, and having the compiler warn me of mistakes is a godsend when comparing it to just writing javascript.
And when valid javascript is valid typescript, it seems odd to not opt to use it when the only addition is a compile step to ensure sanity.
Transparent integration with native Javascript is a huge advantage for Typescript over things like Dart, I think. The ability to gradually introduce typing into an existing codebase is going to make adoption so much easier.
That's exactly what I've found. We ported all of our JavaScript code to TypeScript because of this, and are on a hunt to remove 'any' types.
We found a bunch of real and potential bugs due to JavaScript's dynamic nature, particularly with regards to the number of function arguments (JavaScript being happy to ignore extra parameters or replace missing parameters with undefined).
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)
Did not mean dynamic languages are bad. They are awesome for scripting on the static type language core. Unless you like writing _lots_ of basic unit tests.
That suggests to me they're missing tests that check the data held in the objects.
There might be some worth in checking the structure of an object (including attached functions) as it leaves a public api, especially in a language like Javascript that plays it so fast and loose with object construction.
That's one of the nice thing about typescript - you can use it where it's most helpful and leave it where it's not.
he's right, you can cover more code using integration tests with a static typed language, unit test are then testing the functionality of individual classes.
especially for testing return types as C for example you assign those.
In C it's more popular to write example code which uses the library, and the errors are spotted at compile time.
I was writing a biggish weekend project. It was mostly client-side logic with a FireBase backend.
I developed the first prototype in pure JS and there were some bugs (due to me being new to this FireBase model, and some hastily developed code).
I then converted the whole thing to TypeScript, because I prefer static typing. It took some time to setup: upgrading to the latest nodejs, collecting all type definitions for popular libraries, etc. The DefinitelyTyped[1] library is a great resource. But there were some warts in it. I had to make some PRs to this library for some missing methods in jQuery.
But right after finishing the setup, I was able to find and fix a complicated sequencing bug. That alone was worth the trouble of the setup cost.
I then tried using TypeScript for another project (this one had a licensed IDEA available). Here the setup cost was even lower. There are plugins available for Typescript in IDEA. Though I couldn't convince everyone in the team to switch to TypeScript.
This was back before they added generics support. Now that generics is added, I think there is hardly any excuse left to not use TypeScript (or a similar alternative).
What would make TypeScript awesome is support from more IDEs (Eclipse especially).
Using it on some new functionality at http://rplan.co.uk, pretty pleased so far. The language is great, with some really neat features such as using interfaces for structural typing (http://en.wikipedia.org/wiki/Structural_typing) and declaring properties in the constructor definition. The ability to progressively type code is obviously quite nice too. Coding speed is typically quicker than JS because the compiler catches bugs that might take longer to surface (especially when integrating components.) Refactoring is also easier thanks to both the type system and tool support.
The compiler speed is OK (well, 0.9.0 wasn't, but 0.9.1 should be back to where it was before.) The main pain point is that we usually want to type any 3rd party JS we interface with (e.g. Angular, Backbone, Highcharts etc.) though https://github.com/borisyankov/DefinitelyTyped is helpful with this. No major complaints as of yet.
It's still perhaps too early to tell how long MS will be supporting it. Windows 8 has a JS interface which is comforting, but they could turn around and decide to stop development on it. That would be a great shame, but the code is open source, the compiler works well as of today, and the generated JS is readable enough that it can be edited.
The largest project I know using it from what anders has mentioned is xbox music, which is about half a million lines of typescript. In addition the IE11 debugger also is written in typescript.
I'm just starting with some hobby project (as usual nothing special to show yet) and picked up typescript as it supports me when I am forgetful (as the project time is scattered in small bits) or just plain lazy. I see this as big win for big projects where no-one (or at least no-one) can see all the details in the project, it saves a lot of jumping around in codebase
I started using it just to see what the experience was like. My conclusion is that it's brilliant. It makes refactoring a much speedier experience which you can now do without the fear that you might with a straight JS codebase.
A real aid to productivity in my opinion. And I love how you can turn up and down the typing as you see fit.
We built Kangaroom (http://kangaroom.co.uk/) entirely using TypeScript. There are tens of thousands of lines of code.
The optional typing ability is a life saver when your code base grows. We've used the integrated tooling with Visual Studio which also helped a lot.
Microsoft is promising it will be kept in sync with ECMAScript 6, so we don't really think there is much risk in using it. It's definitely helped with productivity, and the learning curve isn't high for JavaScript developers.
The benefits of inferred typing is great. Mostly you just need to explicitly declare the types of your class properties, and then code that uses the properties or modifies them (like .map() or .forEach) doesn't need explicit types defined - so it still looks like JavaScript.
Refactoring is no longer a search and replace in files (and pray tests pass) affair.
Dealing with other programmer's code is no longer as mentally taxing.
The problem with TypeScript is its requirement for definition files which are most of the time outdated. That makes it unusable in a real project where many JS libs live together. (not saying that's the case all the time)
Love how folks here love to discuss the merits/demerits of a language (not the version of the language) EVERY TIME a new version is announced. This works for every language.
Me too. But I don't agree that it works for every language.
Often the stuff that "just works" doesn't end up producing a lot of chatter on the intertubes, at least not nearly as much as something that looks seductively simple but turns out to be much harder in practice.
Another example I like is Lua: elegant, mature, and used in some very very big applications. If there was ever evidence that a codebase was high quality and nearly bug free, it's that. But when was the last time we had a good flamewar (with namecalling) over Lua?
"...you can develop TypeScript code using the online playground tool or Visual Studio 2012. But this is not it! You can also use Sublime Text, Vim or eMacs as the team has kicked off work on syntax files for these popular editors JavaScript developers love to use. And as the specification is public, anyone can create their own syntax files for other editors as well."
It's open source and they've had a node.js package for some time. The VS integration is just icing on the cake, if you like that sort of cake. As a side benefit, there are interface definitions for many popular libraries, like jQuery. So you get IDE support for those, with types, where applicable.
EDIT: to add, I like the idea of typescript (it's a much smaller step than compared to something like Dart). But their tooling is all around Visual Studio, which ties you to Windows. I don't dislike Windows, but I want my development tools to be cross platform (which is why I like Sublime Text, Eclipse, and similar tools).
This seems a little disingenuous. I bet Intellij already has great support, but the top link you give there for Sublime Text, emacs and vim doesn't really give anywhere near the level of support you get in Visual Studio. Literally just syntax highlighting! In Visual Studio you get at least error highlighting/completions/code generation/navigation/refactoring.
There are definitely attempts to bring the language service to other editors but when I tried them last (just before the 0.9 release) they seemed either featureless or very slow. If someone can recommend one for sublime/emacs/vim that they actually use I'd be very appreciative!
EDIT: related thing that annoyed me: the language service is part of the TypeScript repo but as far as I can see from there is no official documentation on how to go about leveraging it for other editors! I admit I can kind of understand this until the language is less of a moving target. The best way to get started for now seems to be looking at third party efforts like https://github.com/clausreinke/typescript-tools.
> This seems a little disingenuous. I bet Intellij already has great support, but the top link you give there for Sublime Text, emacs and vim doesn't really give anywhere near the level of support you get in Visual Studio. Literally just syntax highlighting! In Visual Studio you get at least error highlighting/completions/code generation/navigation/refactoring.
It's a little disingenuous to expect environments that are typically more text editor than IDE and much more lightweight (Sublime, Vim, Emacs) to have all the features of an IDE with as new as TypeScript is. Much of those features require much more work than they would to implement in Intellij or Visual Studio, which have great APIs for building plugins with those sort of features[1] even for the community[2].
Sorry for the poor choice of word on my part, I admit I was using "disingenuous" incorrectly there. I just thought the description of sublime/emacs/vim having "great" support for TypeScript might give someone the impression that something beyond syntax highlighting was supported.
I don't doubt that it's more work to support more than syntax highlighting, but that doesn't change the fact that the support in those editors is sub-par when compared with lots of other languages. For example I can install SublimeLinter and have basic error reporting for python code, or SublimeJEDI and have code completion and go to definition.
I work at Microsoft (unrelated to TypeScript) and I think it's an entirely reasonable question to raise any time a generally useful technology escapes from the lab of a company that is also a platform provider.
To answer your question: Yes! TypeScript is quite portable indeed. I have run it with Visual Studio, I have run it with Node.js, and even a JScript interpreter.
I think he was asking "why are you concerned about this" because there is absolutely no indication that they intend to force Visual Studio with TypeScript.
It is just a general concern, not derived from this particular announcement. As marshray says the company has commercial interests in making people pay for their tool chain, so it's only healthy to be a bit sceptical when they free a standalone tool.
I hope to be able to use TypeScript for years to come, it solves the problem of opt-in types in JavaScript.
They'll keep making VS the best environment for it but all the tools are open source and written in typescript itself so unlikely it will be Windows only anytime soon.
We 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.
It doesn't look like GorillaScript has static typing, which I thought was the point of TypeScript. I think a great alternative in that space is Roy http://roy.brianmckenna.org/
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.
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 itching to find one so I can put TypeScript through its paces.