Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types.
When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.
When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.
Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming.
Generally speaking, if doing something with a proof of type-safety feels complex, you probably ignored many corner cases before.
If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer.
Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds.
I'll take a map, spec, and select-keys over this all day long.
I view it as a good case for a well-designed gradual type system for dynamic languages.
All valid Javascript is Typescript, in a profound rather than trivial way.
Although, in theory, one could write a parser to inject what form elements are available into the type system... :)
How is it way more effort? In any of the nicer languages, there's type inference.
Dubious gains? Strong static typing makes entire classes of runtime bugs impossible (null pointer exceptions, for example).
No, it's not. Initially it's not any more effort and in the long term it's significantly less effort. Having spent equal amounts of decades in static and dynamic typing (and strong/weak) I would absolutely take the former any day for both ease of development and correctness.
I hear this, as well as "eliminates whole classes of run time errors" (as if Ruby and other such codebases are just ablaze everywhere on account of this...), but I wonder if people dabbled in this and think they have it all figured out, or if they've used a modern dynamic language like Clojure that has default immutability or been in a modern Ruby codebase that wasn't cowboy-coded.
For me, the idea of dynamically modifying code at runtime is like the first circle of hell. But I've programmed in enough languages to understand the appeal even if it doesn't fit with the way I like to work.
But I will take issue with blanket statements that static typing is more effort than dynamic typing with all things being equal. In my own personal experience, that is just not the case. But I wonder if many people have been so damaged by Java that anything seems better by comparison.
They literally are, I think? Ruby is a notoriously unreliable language, in large part due to its dynamic type system... (also all of the unsafe idioms it promotes, a separate discussion)
Show me an untyped program and I'll show you a program missing tests and containing bugs. Static typing saves time and money.
If you don't mean just HTML but some server side processing, yes, I would. This is still PHP's bread and butter and being able to bind a form to static types is really convenient.
In fact I use original Bill Joy vi.
I suspect for most of the people we're talking to 'I<tab>' will say Int and 'S<tab>' will sat String and that's going to make our experiences very different.