I spent much of a week tracking down a bug in a Clojure program where primitive false was being sent through a network, and read back in as boxed false. It looked right when printed out, yet somehow the wrong branch of an if-statement was being taken. This was in a program under 2000 lines, in my first semester of college, before I had ever held a full-time programming job.
Most people are not trained to notice these kinds of problems, or the simple checks that can stop them from confusing a list of lists and a list of lists of lists. But if you take a step back and think hard about what's happening to your time, you'll find that many hours are sunk chasing problems that are, in many ways, simple. Having static checks is like always having someone to read code over your shoulder.
Sure my case is anecdotal at best, and maybe I have just been lucky, but my experience has been that implementing UI's with JavaScript is as fast of a development cycle as doing it in Java or C#. In fact the UI space is dominated by languages such as JavaScript and Objective-C where type safety is loose. I don't believe that fact means that they are superior, but they are as productive as strong typing for UI development in my experience. That being said, I do prefer strong typed languages for middleware and server development, some will differ on that, but it is what I am comfortable with and it works for me.
I think a lot of the hate against statically-typed languages is because people associate them with languages like C# and Java (as opposed to e.g.: OCaml), which lack not only many of the higher-order functional features that we've come to expect in both static and dynamic languages, but also the soundness guarantees that come from actual type-safety.
If you're more productive in JavaScript, it's probably not because you can write a function that converts either an string or an integer to an array2. More likely, it's because you don't need to manufacture a new class every time you want a one-line handler.
If you're more productive in JavaScript, it's probably not because you can write a function that converts either an string or an integer to an array2.
Right which was my point in my other post where I said I just don't run into it that much. It is rare that we run into situations where we have to do tricky stuff with the type system. If we do we usually hide it behind a well tested API so that it is isolated and reusable. It's just not the problem domain that we solve for (most of the time) in web and mobile development. As such for my work flow the type safety of a languadge, does not factor in all that much. At least until I hit the middleware layer then I tend to use Java, but much of that decision is out of comfort and volume of libraries available.
Type systems aren't there to help you do tricky stuff. They're there to protect you from the silly mistakes we all make when doing normal stuff.
Maybe you've created a button that puts some text in an element, but, in some rare cases, due to other events on the page, that element doesn't exist. The user clicks the button, document.getElementById returns null, and a nice error message pops out.
In JavaScript, you might discover this after a lot of testing. In DynXML, you would never be able to make that bug in the first place -- you'd get a type error.
(JavaScript has the advantage, though, of not being vaporware. As the low-paid undergraduate doing the implementation work on DynXML, this is my fault.)
Remember, being able to write a function that converts either a string or an integer to an array is exactly the kind of thing that dynamically typed languages let you do that statically-typed languages don't. If you're not doing that kind of thing, you're better off with a statically-typed language (when available).
Most people are not trained to notice these kinds of problems, or the simple checks that can stop them from confusing a list of lists and a list of lists of lists. But if you take a step back and think hard about what's happening to your time, you'll find that many hours are sunk chasing problems that are, in many ways, simple. Having static checks is like always having someone to read code over your shoulder.