I don't think dynamic typing has any benefit.

I've written large complex 10,000-file sized programs in dynamically typed languages and I agree with you. Static type prevents entire classes of bugs, makes refactoring easier, makes reading and understanding code easier, etc.

But some languages have incredibly weak and verbose static type systems that are frustrating to work with. But if you are working with a statically typed language with great generics and type inference, then it's actually very comfortable.

I'd like to see more languages have optional dynamic typing or optional static typing. Then you could choose how explicit you want to be and use the same language for small scripts and large projects.

I find dynamic typing to be a time-saver for small codebases (sometimes even subcomponents of larger codebases) but shouldn't be the core language for a large monolithic software component. For example, I think it's great for 100-line "glue code" Python scripts to bind XYZ to a web service (or some stupid thing) but it's not good for the core infrastructure of a large mothatfuckin ABC

The venerable Jon Skeet tackles the same question in this blog post. Although people give examples of cases where dynamic typing would be useful, he is not convinced that there is benefit to making an entire language dynamically typed.

One note about Ruby - Ruby's not quite as dynamically typed as Python, and the examples you give can't happen in Ruby. In Ruby...

myvar = myfunc()
myvar = myfunc # Completely identical.

In Ruby all functions return something. It might be nil, but the last statement of a function (All Ruby statements are expressions) is also its return value. This means something like:

def myfunc
  if true
    "Truthy!"
  end
end

Returns "Truthy!" as a string. Ruby will not type coerce variables (Except in the case of arithmetic, which will convert numbers between int/float as necessary). So mystring + mynumber will fail. In most ways that count, things are actually statically typed; most objects just implement to_s, to_i methods and so on which are only rarely invoked implicitly (If I recall correctly, only during string interpolation). So Ruby is far from being as dynamically typed as, say, JavaScript.

On the other end of the spectrum, we have Perl, which I believe is a language with loose typing done right. Perl has scalars, arrays, and hashes, and the three don't really mix - though functions expecting an array will treat a scalar as a one-item array, and functions expecting a hash will treat an even-numbered array as a hash. It has three types of scalar values - numbers, strings, and references. Though references have to be kept separate from other values, it's usually extremely obvious when a scalar reference is being used as a different kind of value (References to scalar values are very rare in Perl). As for numbers and strings, each has their own set of operators; functions and operators define context, not the variables themselves, so it is immediately obvious how a variable is being treated. Problems 1 and 2 also don't exist in Perl.

The third problem you mentioned - clobbering variable names - sounds to me like a bad habit people form in statically typed languages. In fact, I'm a little at a loss as to how any reasonably written application in an OO language, can have variable name clobbering issues, unless it's written in a language with really primitive scoping rules... like JavaScript, which is awful, but not because of dynamic typing so much as the badwrong way in which JS implements dynamic typing.

I would tend to agree with the gist of what you say, but I think that dynamic checking has a lot of value once you go to advanced type systems like dependent types or refinement types. There you can use the type system to prove a lot of properties about your programs, but the downside is that you have to write those proofs explicitly. In many cases, that's not worth the trouble. But it would still be great if you could use the same types to specify your specification, and if a proof is missing the compiler would insert run time checks. Then later if you decide it's worth to prove the thing, you add the proof and the run time checks go away. For example if you have a function foo that only accepts prime numbers, if you pass it some number n that is not known to be prime, the compiler does this:

assert(isPrime(n));
foo(n);

If you later add a proof that n is always prime, then the compiler no longer needs to add the assert.

I would add though that in many cases I'd rather program in a language with no static type system than a weak type system like Java. That gets in the way more than it helps.

There is a research paper about this from Microsoft (link) that identifies some some use cases and how to work around them.

The thing to keep in mind is that static typing does come at a cost too. If your program does indeed need to exhibit dynamic behavior (e.g. multi-purpose servers), or is working with non-strict types to begin with (e.g. JavaScript operating on literals embedded in the html, generated by server side code), then static typing doesn't buy you much, other then a false sense of security .. but you're still paying the cost.

Forgetting to add '()' after a function name

Every language has its beginner's gotchas. Long ago, when I was learning C, I remember being bitten more than once with this:

for (i=0; i<10; ++i);
  {
   f (i);
  }

Forgetting what functions actually do

I completely agree with your paragraph.

There is, however, a case where you won't forget: if the program is short and/or short-lived enough.

Let's say I want to create eight files: blob2.txt, blob3.txt, ..., blob9.txt. I can write:

for ((i=2; i<=9; ++i))
do
   touch blob$i.txt
done

Would you say that this Bash program would have been better with static typing?

[deleted]