Dynamically typed languages are selling snake oil

by

I truly believe they are

I hear the same statements and misunderstandings over and over again from people who like dynamically typed languages. Obliviously, that spikes a lot of endless conversations and fights between two camps.

Generally, I'm avoiding conversations about static vs dynamic typing but every once in the while I drifted into that and hear the same statements, all the time. Often both sides just aren't able to listen to each other and thus conversation end up in the dead end.

Let me lay out those statements

It's faster to start to code!

I'm sure it is. It's cool if it's possible to fit the "hello world" application into a tweet but how useful is that? If one really cares about it - helloworldcollection.de.

Normally we create applications for businesses and they're always slightly complex than "hello world". We as developers not only create apps, we work in the teams, we support our code - it has to be maintainable.

Dynamic languages are cool for MVP

I have to agree, at least partially. Whenever business wants to validate hypothesis we build a simple implementation using whatever we find around and glue altogether somehow. The biggest mistake I see that people take it as a base and continue to improve that. In most of the cases it has to be throw-away code. Unfortunately, it doesn't work this way. Weak foundation will fire back very soon and instead of developing product tech teams fights with legacy and building workarounds around crutches.

In other words it's very difficult to scale your project's codebase without aid from the compiler and IDE inherently.

Types make you busy thinking!

I don't have time to think!

It's easy to start working without thinking about how data is organised, business domain, and how it flows through components(especially if there is no implementation yet). It's uneasy to think about that ahead but we have to do so at some point. If all rules are known from the beginning it's way easier to organise the structure.

Types really help in this place. They allow to draw a bold line and add meaning to the data, specify contract.

Oh wait, did you just complained that your employer makes you think of what you're doing?

Contracts

What if you ask glass to bark?

What happens when you drop an apple? Or an Apple MacBook? Since the same rules apply to every object we know what to expect from our actions. The last thing you expect when you dropped banana is to become coffee and fly to the stratosphere.

On another hand, you can't drop the green colour. It simply doesn't make any sense. Why would you allow do to so? Without contracts with known types and strict checks developer can likely can make a mistake without intention and world can collapse. Types can help to prevent that without exposing the dangerous situation to the end customer who, you know, pays money. One can say that those corner-case situations can be covered by unit tests.

Unit testing

Necessary evil we deal with

I sincerely believe that unit-testing is evil. We should avoid it as much as we can. For most of us who aren't using something like Haskell, the reality is very different. Due nature of the complexity of the systems we design, lack of math education(probably PhD) we simply can't comprehend all variations and ways program works. On another side modern programming languages have very limited support due to the complexity of implementation or lack of demand, I suppose.

That all make us write unit tests. It's a good compromise between creating very complex programs and being confident that things work as expected.

One might have noticed that the world isn't black and while. While we still have to write unit tests it would be nice to have some aid from the compiler.

Say, we have a contract which takes a specific type of object and returns something nice. Why would we write a unit test which supplies array instead if it's simply can't be a case, like at all? Contract with types can significantly reduce the number of tests have to be written and brain power to be used since the compiler will check that for us

We are humans

sin((5452 * 3023) / 2342.23053)42

It's an interesting observation, isn't it? We do creative things, talk to the businesses, understand requirements and satisfy business, get paid for that.
Problem with humans that we don't really have much capacity to fit complex systems on different levels. We can easily make stupid mistakes while focusing on the high level, and that's okay.

Developers don't write code. Developers help businesses to solve problems. Focus on the result and deliverables are the most priority, implementation - is just a detail. I hope this fact doesn't hurt you much :)

In my understanding, we should focus on the business problem solving not on the low-level fights with code. Why do I even need to think what happens if string passed to the function which takes a number? I'd prefer a computer to check those things for me. That's a nature of automation.

So what?

¯\_(ツ)_/¯

I want to believe that everyone chooses the right tool for the task. But sometimes we simply can't see options as we didn't know about them. I appreciate that many people came to the industry recently not only without a CS degree but without high education at all. I think it's beautiful that nowadays it's possible! Also, my appreciation for ones who had the courage to change the industry - you're the best.

I hope this article can help to reconsider the use of tools which supports types - for better you!

Interesting fact.

For more than a decade, I was observing how the industry of dynamically typed languages changes their approach to handling big projects. Here is a list of popular projects gaining huge adoption for  type checks  in dynamically typed languages:

I'm not saying that every user of those languages is adopting type checkers but from my observation, it's getting huge traction especially last 3 years.

disclaimer: if you think that technology works for you and does what you expect it to do - you're doing the right thing.