I think using dynamically typed languages is a mistake today, but that it probably made more sense a few years ago. What changed:

- More developer familiarity with type systems that aren't Java and C++. Type inference.

- Better languages in general, which give more flexibility and power without writing a bunch of hard-to-type code.

- Moore's law is dead, so the poor performance of your dynamically typed language actually hurts. Not to mention how atrocious many dynamically typed languages are at threading in a multicore world.

- Projects are much more complicated, so it's even more important that things glue together well.

No, the problem is not dynamic typing, the problem is enforcing contracts.

With type hinting on function parameters like in PHP you can get the best of two worlds, flexibility & enforcing contracts.

Dynamic types weren't a mistake, but they were overused IMO. It's technically scripting, not programming, but can you imagine if Bash files were type hinted? For small scripts, solo projects or quick fixes, dynamic typing is great because it's fast! On the flip side, large codebases should (on the whole) not use dynamic types because of all the safety they fail to provide! As you said, most dynamically typed languages are moving towards some sort of type hinting and that's because high quality developers demand it when working on medium to large projects.

> It's technically scripting, not programming

Nope. Dynamic types have nothing to do with scripting vs programming. What a nonsense!

Sorry I had to:).

You misunderstood me. I agree that scripting and programming have nothing to do with dynamic types.

> It's technically scripting, not programming, but can you imagine if Bash files were type hinted?

I was clarifying that writing Bash files was scripting and not programming.

How is writing bash files not programming though?

I understand it's historically been called 'scripting' instead, but 'technically' it's as much of a programming language as Python is, don't you think?

"Technically" of course it's just as much of a programming language, but "practically" it's normally used to kick off other programs, and is just glue meant to pass input and output between programs. FWIW, when people use Python for small automation tasks, I usually hear them referred to as scripts instead of programs. Program seems to imply that it's useful on its own, script implies that it doesn't serve a purpose besides running other programs that are generally useful.

I might be being a bit "old hat", but I thought a programming language was one that you had to to compile (such as C) whereas a scripting language was one that was interperated (such as Python). I could be wrong but there appears to be some similar lines of thought on this.

https://stackoverflow.com/questions/17253545/scripting-langu...

Type hinting usually matters a lot more as you scale up engineering organizations.

I've worked with C++, assembly, PHP, Ruby, Javascript, MATLAB, Scheme, SQL.. the list goes on.

Honestly when it's all said and done, static typing is very low on my list of worries. Type hinting and contracts and all that stuff is nice, but the main problems in most real-world, large-scale projects are:

* mutability

* object-oriented business logic (rather than functional/declarative)

* friction

* build systems

* async

* drowning in inconsistencies

Some languages like Ruby have conceptual errors - for example its try/catch mechanism (rescue) defaults to using StandardError instead of the base Exception class. Which means that even though it implemented one-liners like:

  load 'my_file.txt' rescue puts 'file not found!'

In practice these are rarely used because they may throw LoadError (which is lower in the class hierarchy than StandardError so is not caught by rescue, and we can't say rescue Exception puts 'file not found!') so the script crashes. Each time I look deeper into Ruby, I find more and more of these idiosyncrasies that don't build from first principles, so I can't tell what problems they're trying to solve (some of its errata seems to have been inherited from Perl). So I would advise against using Ruby for new development until it has a sister language like Hack that attempts to solve these longstanding inconsistencies and move Ruby forward.

In contrast, PHP has implementation errors where some methods in its standard libraries are camel case and some are snake case, or they decided to use backslash when declaring namespaces. Since these decisions have no bearing on business logic, I can largely overlook them. When people say that PHP is a fractal of bad design, I tend to agree, but do NOT agree that it's a fractal of bad engineering. In fact PHP is by far the most productive language I've ever used (at least an order of magnitude more than the next closes contender, say Javascript in Node). The only language that comes close is MATLAB, which comes from a completely different paradigm of matrix operations so simply provides more leverage per line of code.

Static typing mainly becomes important when you're working with other developers, or have large/legacy codebases. If we're strictly talking about our ability to write business logic as effortlessly as possible, then the conceptual problems I've illustrated above (which pop up repeatedly across frameworks/languages) have much higher priority IMHO.

Also on a personal note, I find that dynamic types tend towards rapid application development (RAD) because I often work at a high/abstract level. I find that the friction of assigning types steals brainpower from the task at hand - generally composing logical units that pass around hierarchical data like JSON or tabular data like CSV. If we stick to RAD, then building out strictly-typed/over-architected class hierarchies is generally a waste of time and expensive to maintain.

javascript has no type hinting, there's typescript but tons of people use plain javascript. Same for python (tons of code was and is being written without hints). The same goes for ruby.