Unfortunately I spend a lot of time defending the merits of static typing to my co-workers. At the same time they're going on about how unit tests are important, while static typing eliminates entire classes of errors and they don't get it for some reason. Unit tests while important don't prevent type errors, and if you tried using them for that you'd have orders of magnitude more tests to write.

I feel like I'm taking crazy pills having to defend static typing while every dynamic language I've used for any project of any considerable size has been a complete nightmare to manage. At this point I feel like a lot of new coders coming out of school just haven't written anything large enough yet and maybe that's why they don't see the point.

Unit testing is great, but it doesn't provide autocompletion, or help you analyze your codebase before a refactoring.

When third party libs have dts files, it's a joy to use them.

    declare module "some-module"

0: https://blogs.msdn.microsoft.com/typescript/2016/07/11/annou...

> In the coming weeks, a more stable release candidate will be coming out, with the final product landing not too far after.

-- https://blogs.msdn.microsoft.com/typescript/2016/07/11/annou...

I have the complete opposite feeling, when looking into the TS2 repo.

If you're using a library and can't find bindings then I've found it's worth the time creating them yourself for any reasonably sized project. This is annoying and time consuming up front, but the benefits you get down-stream easily repay this initial investment.

Although TypeScript 2 is catching up, the fact that flow works with babel to support many ES6/ES7 features e.g. object spread.

Coming most recently from F# I would have gone insane without some kind of static typing extension in Javascript.

`var aLibrary: any = require('aLibrary');`

I mean Objective-C is something like 97% a superset of C... doesn't make the transition any easier.

As I said - it's a silly marketing point that isn't convincing anyone already not convinced by TypeScript and they'd do better to drop it as a talking point.

I ask because after looking (admittedly very briefly) at writing an Ember app in TypeScript, it looked like because Ember assumes all of it's webapps will be JavaScript, there ends up being a lot of dynamic-/string-based idioms, e.g. model.set("property").

(There is a good SO post about turning this into a typed model.property.set(...) in TypeScript, but that solves just this one instance, and not the entire Ember experience.)

So, this left me with the feeling that for a TypeScript webapp to have a truly great/first-class/typed interaction with it's framework (Angular, Ember, whatever), that the framework itself would have to: a) be written in TypeScript, and b) have the founding assumption that most (all?) apps written for it would also be TypeScript.

So, per this post, Angular 2 is a), it's written in TypeScript. What about b)?

The one caveat is that templates have no type checking or refactoring support. This is fairly standard in html templates in any statically typed language framework, but it is still frustrating and unfortunate. You can safely rename a symbol in TypeScript files, and yet not be able to catch the references in templates without find and replace.

You can use TS for part of your app, once the environment is setup... iirc, there's a couple options for bringing in typings for existing libraries, and if you enjoy that, I'd say go for it. That said, I don't think it adds as much value as others seem to feel it brings.

Edit: Thanks, I had a feeling there was a bug... it was just strange to see files from the top-level folder appear afterward, made it less obvious.

    There are a lot of options available to frontend devs 
    today: ES5, ES6 (Babel), TypeScript, Dart, PureScript, 
    Elm, etc.. So why TypeScript?'

    Elm and PureScript are elegant languages with powerful 
    type systems that can prove a lot more about your program
    than TypeScript can...

And really, Dart is more like Java, it's nowhere near the elegance of the ML/Haskell pedigree of Elm and Purescript

The older I get, the more the whole "everything moves in cycles" thing appears to be true -- almost regardless of what particular subject matter is under consideration.

http://games.greggman.com/game/dynamic-typing-static-typing/

When a language imposes static types, it also imposes a development cost, possibly negating all the value it brings.

Typescript is a little in the middle in that static typing is optional, but then you also don't reap the supposed benefits wherever you don't use it. Any "tool-based" refactoring is now less reliable than a simple text search.

As for catching type errors, those are usually caught very early. If they aren't, that points to a lack of test coverage.

As for the "documenting" aspect: The article claims that by static typing, the documentation need not be consulted, which is rather irresponsible. If you use a function, you had better read the documentation. I know that's a bit much to ask from actual developers, but it's true.

Here's the thing: test coverage is crucial on any large project, and we (hopefully) all agree that they're worth it, but tests can be very hard to write and impose a huge development cost. Static typing helps reduce that cost by reducing the number of tests you need to write. Generally, the more powerful the type system, the more the number of tests you need to write is reduced.

It's been my experience that the development cost of static typing is infinitesimal compared to the savings of having to write and maintain fewer tests. YMMV.

Those type annotations are the tests, they're just run by the compiler. And once you realize that, you can start to ask: are these the most valuable tests to write? If I have a fixed amount of time to write & maintain tests, would that time be better spent testing things more likely to be incorrect?

Disagree slightly. Type annotations are logical propositions and the compiler proves them for you.

That is to say: Tests can only prove the presence of bugs, not absence. Types prove the absence of (type-related) bugs. They essentially give you theoretically perfect test coverage (modulo bugs in the compiler).

Theoretically perfect test coverage, for a particular class of bugs. But that class of bugs isn't the most prevalent class, nor are they the hardest class to fix. So it still is a question of, is that the best place to put development time? And beyond that—are all type annotations equally relevant, or are there some that are very valuable, and some that are less so, and so an optionally typed language would be ideal in that regard?

Well, except maybe is is? They're certainly extremely severe when they occur. (Especially if your language is weakly typed like C/C++.)

Without the proper research, who knows? (I'm only talking about my own experience, so YMMV. I'm not even sure a proper metric for a 'fair' comparison can be constructed, even in theory, so again YMMV.)

EDIT: Just curious as a point of interest: What statically typed languages do you have non-trivial experience in? This is not a gotcha, or a haha-look-a-the-noob type question. I find that the quality of the $ST_LANG has a huuuuuuuge impact on how people perceive the value of $ST_IN_GENERAL... if that makes sense.

Maybe is is? In general that hasn't been my experience (they happen, but not that often, and are usually easy to figure out).

I agree that research is needed to decide, but the research I've seen references doesn't seem to hold that up. But it's not something I've looked closely into; too much discussion about it ends up getting into holy war arguments, and I stay away.

> I'm only talking about my own experience, so YMMV.

Me as well :-)

> What statically typed languages do you have non-trivial experience in?

Java (which has a garbage type system) and Objective-C. I'm in the process of learning Swift and Scala, but I don't have much experience in either yet. More languages back when I was in college, but that was a while ago, and you don't really get non-trivial experience in college.

> I find that the quality of the $ST_LANG has a huuuuuuuge impact on how people perceive the value of $ST_IN_GENERAL...

I agree 100%. And it's not that I think ST is worthless—although Java's type system really tries its damnedest to make it worthless—but spending most of my time in Ruby, one of the wildest-west languages out there, I still don't find type errors cropping up very often, or being a major issue when they do. On occasion, sure, one can be hard to find. But they're really not a major source of error in my day-to-day life; and if ever a language were susceptible to them, it's Ruby.

Still, if the language used matters that much, then it's not just ST that's the solution, it's ST with a certain level of sophistication.

I disagree with the idea that you need to write more tests because of dynamic typing, my claim is that the tests you have to write anyway also cover type errors. Just running your code yourself covers most type errors.

TypeScript is so much better to work with. Most of the time it feels like ES2015.

Chances are however, your type error will already occur the first time you run your code.

It's also a bit of a pain that it's just a summary of a video, and there's no citation to any text anyway.

From what I can tell, the first bit of evidence is from a researcher's toy language.

The second was a scan of GitHub for issues that included type errors. There's no mention of actual methodology, but I'm imagining that means 3% of Python issues in GitHub have a copy-and-pasted stacktrace that contains a type error? This is clearly not a great indicator, since it won't count issues with less description, or any bugs related to, say, a bad type coercion.

On the other hand, you're right, I've not read any research that points to static typing being a net-gain. Every static-type advocate probably remembers being burned by a dynamic-type issue, but that doesn't mean the advantages might not outweigh disadvantages - experience and intuition don't cut it here.

I'm not actually making a claim one way or the other, I'm rather questioning one argument in favor of static typing.

There are other arguments for static typing which I agree with, but which are too domain-specific.

Edit: https://youtu.be/lT07c3OREL8?t=713

> He was the original author of Turbo Pascal and the chief architect of Delphi... the lead architect of C# and core developer on TypeScript.

(from wikipedia)

Today's automatic refactoring IDE's are light years ahead what the Smalltalk Refactoring browser ever did.

Very very small cost.

I've gone back and forth a few times in my career (currently preferring dynamic languages) and would say that the cost is considerable, even with type inference. The trouble is, we don't notice the costs of approaches we're habituated to or prefer, so it feels like they're much smaller than they are. And we don't account for the costs we don't notice, so our cost/benefit analyses (on both sides of the question) are skewed. We all unconsciously put a finger on the scale.

This doesn't stop everyone from making grand, confident claims about static vs. dynamic typing. Such studies as there are don't support these claims, but the studies are weak in so many ways that it's easy to dismiss the ones you don't like and stick to your previous opinion, so that's what we all do.

For these reasons, the debate is pure tribalism and cargo cult. We should stop pretending that our views have any objective support and just talk about them in terms of taste. That's unsatisfying to the technical mind, though, so none of us will!

> For these reasons, the debate is pure tribalism and cargo cult. We should stop pretending that our views have any objective support and just talk about them in terms of taste. That's unsatisfying to the technical mind, though, so none of us will!

Excellent points[1] and I think I'm mostly justified in saying that I personally have begun prefacing any discussion of these things by a disclaimer to the effect of "well, the evidence is very sparse and it's a woefully understudied area...". I think of it as a kind of 'professional maturity' these days. Or maybe it's just 'old man syndrome' :).

Of course it's not like actually doing these types of studies is easy or cheap, so... here we are, I guess :)

[1] Even though I disagree with your position on type checking. Static FOREVER, baby! :p

For example, some portion of your program may be half-baked because you haven't worked out its types yet, or maybe you've changed a type but haven't yet updated the rest of the program. If you want to play with your program interactively to find something out about the work in progress, now you can't, because your program isn't currently 'correct', i.e. it isn't self-consistent.

This adds drag to the development process. First, you have more work to do. Second, it breaks flow: you must switch your attention to something extraneous, breaking your concentration on what you were doing. Third, it gets you in the habit of satisfying the machine rather than thinking about the problem you're trying to solve.

It's only fairly recently that mainstream languages had type inferencing. Before it could be quite costly (and affect code legibility too)

I maintain a medium-sized (50k lines) codebase with frequent requirement changes that uses a functional style, and the closest we've come to ever needing a type-check is null checks. Type errors are maybe 2% of total errors when developing, and because our code doesn't have too many layers of indirection, they've all been trivial to fix way before production. I'd much rather spend 30 seconds every week fixing a type error than spend hundreds of hours writing type files and code in a dialect of Javascript that doesn't provide 100% coverage.

If you embrace functional programming with mostly immutable data structures and avoid mutation, side-effects, and gross mixins/polymorphism, you reduce the size of your codebase significantly, which makes it much easier to keep documentation terse and up-to-date.

On the other hand, if your team is so undisciplined and untrustworthy that you need to throw errors on compilation because you don't trust them to update comments and docs or name variables descriptively and your entire team knows Java but not Javascript, I could see the huge amount of boilerplate involved in Typescript being well worth it.

As someone who's primarily a Javascript developer who does Clojure on the side, I feel that the Java approach is fundamentally impoverished. I've never met anyone who chose to develop in Typescript whose background wasn't enterprise Java, just like I've never met anyone using Ramda (before lodash replicated it) whose background wasn't in FP.

I'll take "unrealistic estimates" for $500, Alex.

So we've got data plus my experience plus my team's experience in a large, very successful enterprise on one side, and we've got snark and defense of existing habits on the other? I'll take the risk, I think.

Btw do you care about John Carmack's opinion on the subject?

Neither did you. That link you posted is laughable. Like there isn't a single agreeable thing about the research it presents and the methodology by which they arrive at the conclusions it makes.

> to an irrelevant authority

Is that kind of like appealing to "experience" and "team experience"?

> John Carmack doesn't do web apps, he does high-end 3D engines

Is this an admission of the possibility that types work in one subfield of programming? If so, how is that subfield different from another subfield.

Well, neither do you.

I mean, if I have to spell it out for you (but the summary is that they take languages that aren't good examples of typed languages and make conclusions based on those). But more detailed breakdown:

First slide. They make their own languages (first issue) snd have people solve small problems (second issue). Advantages of static typing really kick in for larger projects. Also, different type systems have different advantages so this comparison holds little informational value

Second point, they are talking about code that has already been written, it doesn't say how much time was spent making the code correct. I really don't know what to conclude from their data though.

> His point there is that all that static boilerplate you write to make a statically typed language happy,

He's ignoring statically typed languages with type inference. They have been around since the 70's.

> Some other study compared reliability across languages and found no significant differences. In other words neither static nor dynamic languages did better at reliability.

How do you measure readability (notice that good research would indicate this).

> Part of that was reflected in size of code. Dynamic languages need less code.

They are comparing python vs C/C++/Java. Code terseness is orthogonal to type systems. Why do they not include say, Haskell?

> Another point he made is that writing static types is often gross and unmaintainable whereas writing unit tests not.

Hahahaha, what? Unit tests are more maintainable than types? And he gives a C++ example?

If we're both just throwing around opinions this is no different than arguing tabs vs spaces. I've noticed that Typescript tends to be embraced by teams with lots of subpar enterprise Java developers with limited knowledge of Javascript. The same is also true of Angular, so it's a good fit here, but it's more for mitigating a lack of personal knowledge and organization standards than a general benefit.

Look into programming language research.

> I've noticed that Typescript tends to be embraced by teams with lots of subpar enterprise Java developers with limited knowledge of Javascript.

Holy fuck are you full of yourself. You are writing JS, it's not rocket science.

Thanks for helping my argument, I'm glad we agree that you're a bad engineer.

It doesn't seem too long ago when Java Developers rushed to Ruby because it wasn't statically typed.

Now, TypeScript is better than JavaScript because of the opposite reason...

I've seen this sort of pendulum swing a few times in my career.

IMO they were rushing away from:

1) Java's verbose syntax (not the type system itself; static typing and verbose syntax are technically orthogonal), 2) The J2EE + FooFactoryFactory mess that infected the Java ecosystem at the time, and 3) Enterprise software in general (a lot of Ruby was in startups, so fun greenfield development, away from the J2EE/enterprise mess).

For Java itself, the syntax is finally getting better (Sun really screwed that up, and let C# get way ahead in innovation), and J2EE is finally over AFAIU, so Java development is generally/in theory not as bad as it was when everyone left. </Stockholm syndrome>

Java has a particularly bad type system.

The simple truth is that today, statically typed languages have all the advantages that once used to be the exclusivity of dynamically typed languages, while the reverse is still not true.

In 2016, there is really very little reason to pick a dynamically typed language for any serious project.

Javascript is going to be around for a while because of inertia, but it's pretty much the last mainstream dynamically typed language we'll see.

Python's still pretty popular too

I partially agree. I think as type inferencing gets smarter, we're going to end up with languages that are statically typed by the compiler or interpreter, but that there will be few-to-no type annotations in the code. So yes, I think the future is static typing, but I think it's going to end up a compiler feature and not part of the language at all.

I wish this were true. I wholeheartedly agree that, all other things being equal, static typing is better than dynamic typing. If there were no other factors, I would choose static typing without a second thought. But there are other factors, and all other things are not equal.

I write ClojureScript every day. Its lack of static typing is a genuine source of pain. Every day. But when I compare it to Elm, which I'm quite interested in:

- JS interop. Maybe I suck at google, but it looks like it's not a first-class concern of the language or the community.

- Macros. Defining language features is great. It's the reason that a lisp can be small in terms of core language constructs (even if its standard library is enormous cough Clojure). In 2016, there is really very little reason to design a language without metaprogramming in mind.

- Community, which admittedly could and should and will grow in size and sophistication for Elm.

When I compare it to TypeScript?

- State. Welp.

- No seriously, why is everything mutable? It's 2016 and a language that was designed with concurrency and functional programming in mind from the start still hasn't caught on to mutability by default as a serious problem, and TypeScript inherits all this baggage.

- There's no simple clear path to even set up a TypeScript project. There's a million different ways with different tooling choices, and that fractured environment is evident whenever searching for answers. The world of JavaScript constantly bleeds through. If I want to know how to use TS, I need to know WebPack and NPM and Bower and who knows how many other things that are not even for TS.

- Forget metaprogramming.

- What is the TS community? Microsoft and a weird has-been cult team at Google? (Sorry guys, I did the Angular thing, and I watched it become a circus from the time Angular 2 was announced to the time your weird conference was more like a dance club than a tech conference.)

I could simplify this by calling out your last line. JavaScript rules the roost. You better play nicely with it, if you want to build a web app.

Honestly the web is going to be an increasingly fractured thing for many years. There's just too many ways to do things and they're all compromised in awful ways.

Postscript: I'm sorry this is so ranty. I mean no harm and I mean none of my criticisms to be taken as attacks. I want very much to do good work as a web dev and I'm just heartbroken that it's such a pain.

http://www.draconianoverlord.com/2010/11/24/why-im-a-static-...

I really like the OP's point about "types make abstractions explicit". That is a great articulation that I'm going to add to my post as well, with attribution.

- Lots of languages used static typing for implementation ease/ no need for VM (probably not as much for safety issues, given the many failures of C's type system). Also, lack of GC meant that memory management is a big deal, and types and memory management are pretty linked.

- It's verbose though, and you can still easily make mistakes, so dynamic languages offer both cleaner code and the safety checks weren't that useful anyways (again, this is from C/Java land. Null pointer exceptions!).

- Newer static languages offer even better type systems that catch an order of magnitude more bugs. And type inference means that it doesn't affect legibility nearly as much.

So we're basically progressing on all axes at once. Language design isn't zero-sum, luckily.

I think with both class-based OO, and static type checking, they can offer some benefits, mostly in IDE integration. Beyond that, they don't stop developers from being sloppy and/or using object patterns that are crushingly slow.

Now with type inference and intelligent autocomplete, these features add back efficiency to the point of making them as fast, if not faster to develop non-enterprise sized programs.