Ask HN: How do you work with dynamic type programming language | Hacker News Reader

Ask HN: How do you work with dynamic type programming language

10 pointsaabbcc12415 comments

How do you make the codebase written in dynamic type programming language maintainable over time?

By written a lot of tests that are more strict than the type system?

I know statically type-safe along is not enough because it doesn't prevent logical error but isn't having it better than not?

View on HN

I am not even close to being among the better software developers on here, so my opinion may not count for much, but I agree, having static typing is simply better than not, full stop.

I really don't see much appeal in dynamic typing beyond simple scripts and solving Leetcode style problems.

My current default language is unfortunately still Python lol, but I want to make that Haskell or OCaml soon if possible (and if I have time to devote to learning them!)

I hear that OCaml, at least, is fairly adaptable to multiple use-cases.

It's simple, I don't work with dynamically typed languages. But if I had to, for work or some other purpose, I'd try to leverage as much type hinting ad possible, such as with Python and Ruby which both have type hinting systems. Barring that, yes, I'd write lots of tests.

Just because a language is dynamically typed doesn't mean that you should do things like dynamically modify objects in your code, assign int to strings, and so on, even if you can do it. Contrary to popular belief, you can write clean Python code that is easily debugabble and testable.

Likewise, most any static typing language out there allows you to ride shitty code should you so chose. In fact, it seems to be that the more strict a language is, the more people try to get around the strictness for their particular use case, and consequently, you get a bunch of standardized syntax or libraries for this that create more complexity than is needed.

The only real value of having static typing is having ULTRA strict real static typing where you define what data is, what operations can you do on that data, and what are all the possible outcomes on that data. Then, if you program compiles, by definition, it is correct. I think Coq comes pretty close to this, considering its designed as a theorem prover.

Ironically, dynamic works better for situations where you don't want to be using tests. i.e. prototypes/proof of concept. For long term scenarios, or if you're writing tests from the start, static might be best. If you have a hacky culture, static would be even more vital.

When I used to write code in dynamically typed languages, I would fill the gap with testing. But when I started using typescript instead of JavaScript, I found myself needing to write far fewer tests. Now I typically only write tests for code that I know is more likely to have bugs.

Reply on news.ycombinator.com