Comment by RussianCow | Hacker News Reader

Comment by RussianCow | Hacker News Reader

Parent Full thread

> I honestly can’t think of anybody in my career who’s been comfortable with dynamic languages that had a desire to move to static. It’s such an impediment to the entire programming style that it doesn’t naturally happen.

Really? Anecdotally, I have the exact opposite experience: I know many devs (myself included) who had always used dynamically typed languages but got "hooked" on static typing after trying it in a decent language (Swift in my case), but I can't name a single person who went the other way.

In my experience, if you use a modern statically typed language with a solid type system, after the initial learning curve, the type system stops being an impediment to probably 95% of the code you write. In return, you get some really nice guarantees about your code, and what would be large and tedious refactors in a dynamically typed language now become a breeze. And if you bolt static typing onto a dynamically typed language, you get the best of both worlds: safety guarantees by default, and the full expressiveness of the underlying language when you need it.

Personally, I'm excited for these tools because I write code in dynamically typed languages every day, but I strongly value the benefits of static typing. This way, I can have my cake and eat it, too.

I really think a lot of it depends on your stack. On the web application side, I find static typing to be entirely an impediment - usually because the types that I really care about are already defined at the database level.

Every statically typed language I've worked with on the web just ends up forcing you to duplicate the same already defined structure in multiple places, writing a ton of extra code that provides marginal benefit but creates a major negative impact on productivity.

For many other areas, especially on phones, embedded devices or desktop software static types will make a lot more sense.

I think languages where the primary focus is data exchange the benefits are less pronounced. That's just my experience though.

But it's still incredibly beneficial to annotate the edges of your API. Not only does that quickly catch mistakes where you break the API contract, but it also serves as built-in documentation on the shape of the data you are serving, especially if you are using a dynamic format like JSON. And that's the beauty of having static types in a language like Python: you don't have to annotate everything, and can be selective about where you apply static typing to get the most bang for your buck.

I can appreciate that. I like the add where helpful approach. It’s having to do it everywhere that’s such a problem.

> On the web application side, I find static typing to be entirely an impediment - usually because the types that I really care about are already defined at the database level.

I disagree here. Take one example, Slack. They publish "types" for their API that they don't adhere to, since every endpoint of their API that is supposed to return that "type" is returning something else. That could've been solved with a type system or schema validation which in itself is a weak form of a type system.

Types make sense if you're not using OO, so for pure functional python I can see how they would be useful.

In my projects I have dozen of classes that are nearly strings but add functionality not present in strings. Trying to type check those would turn into insanity pretty quickly.

I would argue that keeping track of dozens of similar-but-different types without type checking is insanity, but to each either own. :)

I went from ocaml to scheme, so there is always me. I prefer gradual typing, but would use scheme over any ML-language every day of the week.

Reply on news.ycombinator.com