Comment by madmax96 | Hacker News Reader

Comment by madmax96 | Hacker News Reader

Parent Full thread

There is no limit on the number of problems easier to solve using dynamically typed languages. For an individual hacker, dynamically typed languages make a lot of sense. I don't forget what types my functions accept as I am writing a program. All static typing can accomplish is slow me down when I'm trying to bang out something. This is why Python (for instance) is loved by data scientists, researchers, and startups. And they're right to love it! Purely anecdotal, but I can accomplish more faster (from a clean slate) with a dynamic language like Python than I can with Haskell, Go, or Rust. The difference is small, but non-negligible.

But static typing has a few key benefits:

* No searching through comments for type constraints.

* Better autocompletion.

* Better compilation.

* Better serialization/deserialization.

I do think static typing pays for itself in the long term. Sometimes, we shouldn't care about that. Engineering means managing tradeoffs: short-term velocity vs long-term performance and maintainability?

The auto-completion is purely Python's dynamic-dispatch problem though. Lisp has symbol-based auto-completion which doesn't suffer from the same issue (search is a different story!).

This sounds terribly controversial, but I would love to know /when/ the static-typing pays off compared to a looser approach like sound-gradual typing (where you basically export types at a boundary and make sure that you don't violate those).

I do wonder whether a better approach is to prove your code in some other language (say Z3, Agda, Coq) - then implement it in something else, making sure you can prove isomorphism. This has quite a few benefits; you're not tied to a constructive proof on the type-level ala Haskell, Rust, Go etc... and you can automate a large part of trivial proofs.

The fascinating thing about Python is the ability to write functions where the parameter can intake multiple data types.

I haven’t quite seen another language handle it this elegantly as Python does.

Then, inside the function, you can check the parameter’s data type, and handle it appropriately. And error out immediately if the wrong type is passed in.

This allows you to operate on the data at a more logical level (what it implies), as opposed to just at the technical level (what data type it is).

For example, you can pass in a single string, or a list of strings. And your function can check the type and handle it appropriately.

In C++ and Java, because of the rigidity of the function declaration, in order to do something like this, then you would need to create multiple functions to handle each of the different types that you want to allow. Then you’d need to create a wrapper function to dispatch it to its appropriate sub function. That becomes a complete mess after a while.

C# has an is operator as well. I found it useful with generics.

> I would love to know /when/ the static-typing pays off compared to a looser approach like sound-gradual typing (where you basically export types at a boundary and make sure that you don't violate those).

When you are in a codebase where you don't know which modules have been soundly typed, and which ones are still in the 'gradual' phase.

> There is no limit on the number of problems easier to solve using dynamically typed languages

40+ years of programming experience here + a language geek. I have for years programmed in both dynamic and static languages to find out what works best for me. My conclusion is that problems are easier to solve with statically typed languages. So clearly different languages works for different personalities.

Clojure gives you tools like spec https://clojure.org/guides/spec or Mali https://github.com/metosin/malli for schemas on data. Beats static typing IMHO.

>There is no limit on the number of problems easier to solve using dynamically typed languages.

So, some examples? Also examples where "easier" is not just "you don't need to write types". That goes without saying...

One more that people easily forget. An IDE or LSP can detect much more errors as you type, saving quite a lot of context switch of mind.

how about using something like clojure.spec where you need it most to help make that long term payment?

It's an interesting take. e.g. provide specs/types across module boundaries only. Gradual typing is certainly becoming popular. Meanwhile, statically typed languages are adopting type inference. Some people only write the types for the exports in their modules. The two worlds are coming closer. More statically typed languages are adding dynamic type information (like Go). More dynamically typed languages are supporting static type markup (like Python).

Coming back to even your own ~+1KLOC project after 3 months of working on other things, compiler enforced types can help you jump right in

Reply on news.ycombinator.com