I'm inherently weary of anyone who claims that dynamic languages with loose types are the end all be all.
I can only speak from experience with PHP, but at some point your app+framework is just so big that I've almost wanted to sacrifice some development time for a little type safety. It really sucks not having a guarantee that somefunction() will always return an array of some object.
Or even worse, taking 5-10 mins to wade through library code to figure out what to call obscure_helper_function() with.
Wouldn't unit tests help with this? I realize they are not the same as type checking, but, at least in the case of what arguments something takes, seems some decent tests would explain how to use it.
No, unit tests will not help with parts of this. Take today for me as an example: I need to update some python code which calls the database through SQLAlchemy. I can't remember half of SQLAlchemy in my head, so I begin digging for what I want in the documentation. No Carrot in 5 minutes. Around 10 minutes in, I find it, just to realize that I am poking at the low-level framework of SA. I hack up the code as I think it works. Application explodes somewhere deep inside SA with a missing cursor.
Then I spend about one hour trying to narrow down how I call the thing incorrectly. I also search for the error message, which prompts an upgrade of psycopg2 for a bug. Doesn't help. In the end, I realize that the calling convention I use is wrong and I should have called the thing differently.
This kind of problem is trivially mitigated with any static type system which is just a little stronger than what Java or C buys you (ocaml, Haskell).
Comments
I'm inherently weary of anyone who claims that dynamic languages with loose types are the end all be all.
I can only speak from experience with PHP, but at some point your app+framework is just so big that I've almost wanted to sacrifice some development time for a little type safety. It really sucks not having a guarantee that somefunction() will always return an array of some object.
Or even worse, taking 5-10 mins to wade through library code to figure out what to call obscure_helper_function() with.
Wouldn't unit tests help with this? I realize they are not the same as type checking, but, at least in the case of what arguments something takes, seems some decent tests would explain how to use it.
No, unit tests will not help with parts of this. Take today for me as an example: I need to update some python code which calls the database through SQLAlchemy. I can't remember half of SQLAlchemy in my head, so I begin digging for what I want in the documentation. No Carrot in 5 minutes. Around 10 minutes in, I find it, just to realize that I am poking at the low-level framework of SA. I hack up the code as I think it works. Application explodes somewhere deep inside SA with a missing cursor.
Then I spend about one hour trying to narrow down how I call the thing incorrectly. I also search for the error message, which prompts an upgrade of psycopg2 for a bug. Doesn't help. In the end, I realize that the calling convention I use is wrong and I should have called the thing differently.
This kind of problem is trivially mitigated with any static type system which is just a little stronger than what Java or C buys you (ocaml, Haskell).