Hacker News new | past | comments | ask | show | jobs | submit login

Yeah, my impression is that B happened earlier in Haskell.

1. Let's create a super advanced type inference system so that you can write Haskell like a dynamic language but have it be static.

2. Oops, now when you make a mistake, it propagates through your program and causes a type error somewhere completely different.

3. New code style rule: you may omit type signatures on local functions, but always place them on top-level functions so that they serve as a barrier to incorrect type inferences.




What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors.

Trying to write untyped dynamic code in a statically typed language thus just results in frustration, those languages were made to work statically and to throw a lot of type errors, they are horrible as dynamic languages.


> What those people miss is that the productive part about dynamically typed languages isn't that you don't have to write the types, but that the types used by dynamically types languages are extremely ergonomic and can fit in many different contexts so you rarely get type errors.

This isn't true at all. I write a lot of python and I don't think I've ever had a duck-typing happy coincidence that wasn't an error. No it's exactly that I'm only depending on the aspect of the type that I need at the call/use site (so I can update types while maintaining those contracts and I don't need to update any signatures anywhere).


Could not display comment. Typerror: undefined is not a function


Lol




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: