I've written a lot of JavaScript, including large-scale projects, and never once have thought, "Gee, I wish I had type checking."
Haven't we come to a consensus that types are more trouble than they're worth? They hurt clarity and catch few bugs.
Haven't we come to a consensus that types are more trouble than they're worth? They hurt clarity and catch few bugs.
Pretty sure we haven't. That shitty languages with shitty type systems are mor trouble than they're worth yes, but types?
Same with Objective-C and my iOS and Cocoa development (since the OpenStep days).
I do use Scala on the server side though, and it helps there. But application development is, IMO, hindered by static typing. It's a lot more work to set up, and provides essentially zero benefit.
And I love static type analysis (I use it with C stuff all the time). +1
I would also argue that static typing provides a self-documenting benefit that is easy to forget, making it easier for someone unfamiliar with the codebase to understand what is going on. When I'm doing maintenance work I often start at the point of failure and work backwards, and it is very helpful when I can immediately identify what a variable is supposed to be representing.
Ditto. For me that's by some way the biggest advantage of typing, with refactoring/navigation being the next biggest.
I do wonder if some of these newer languages are going to make the self-documenting aspect even stronger though. I'm speaking here of optional typing and/or implicit implementation (Greeter implements IGreeter if it has the correct methods). For me this will let me put type information and abstractions (interfaces etc) only where they make sense.
Compare that with what you get in current static languages, where projects I've worked on that also use IoC have so many interface-implementation pairs that it becomes difficult to spot the important abstractions.
Interesting times ahead I think.
I'm just really happy with Scala. Highly recommended, and the Akka library (Erlang for Scala, essentially) is fantastic.
Common things such as access an undefined variable or property or trying to call a method of a null object would be detected by most static type checking algorithms.
That does not require static typing, unless you're developing in elisp maybe.
> trying to call a method of a null object
Unless there's support from the type system, that one only works on very short code spans within the same scope, which is the least useful it can be (as opposed to type inference which is most useful locally).
If you see the compiler as your friend then you tend to like type checking because it blocks certain bugs and typos. It won't let you run your code until they're fixed. If you see the compiler as your enemy, as a barricade that you need to get past, then you tend to not like static types. The compiler prevents you from seeing your code running immediately.
Obviously there's other benefits to each system but I feel like this is the more "gut reaction."
An alternative explanation is a dislike of overly verbose languages with terrible type systems (the poster child for this category being Java), and as a result of low exposure to better statically typed languages painting all of the category with a Java brush.