Hacker News Reader

Comment by randomhunt | Hacker News Reader

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)

View on HN

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

You're not the only one: http://www.di.unipi.it/didadoc/lfc/OtherPapers/Iteroperabili...

(n.b, this is from 1999)

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.

You don't know how productive those developers were on those projects, nor do you know if TS would have made those developers more productive. Granted, the original claim wasn't comparative, but that's the point I'll make anyway.

Interesting theory, let's see how it plays out in the marketplace. If typed languages are indeed more productive we should see them start to win out in, say NPM, right? Today the overwhelming majority of NPM modules are JavaScript, but if the same modules can be written more productively in TypeScript or Dart or another typed alternative, you should start to see those modules win out. Fewer bugs, more able to concentrate on features.

Indeed over the long term modules isn't a bad idea as the interface requirements and discoverability would benefit massively from better tooling, a la optional typing.

Out of how many of the big ones are using scripting tools/language-to-language translation though? Hint: much more than you seem to be aware of/think.

Whether its Google Web Toolkit/Java/C#-to-Javascript generators, Closure templating, Haskell/Clojure/etc. mini-languages, TypeScript, etc. (Job Ad Requirements are one of the great ways to see all this stuff)

When you start working on big applications (e.g. I worked for 5 years on a huge electronic HR application covering everything from timesheets to recruitment to content management to CRM with multi-country, multi-language, multi-regulatory, multi-company, multi-site, multi-thousand users requirements) you realise JavaScript has serious shortcomings...although I still really like the language the tooling and knowledge advances have really, really helped.

Reply on news.ycombinator.com