3 ms·

I also have never understood the argument “In dynamic typed language X you can just start prototyping, but in static typed language Y you have to fight the type

I also have never understood the argument “In dynamic typed language X you can just start prototyping, but in static typed language Y you have to fight the type system just to get it to compile” If your types aren’t lined up but it compiles, even in a dynamic typed language, you’re program won’t behave as expected, i.e. you are likely to have a bug. e.g. object + int, and it compiles. How does one really save time by not worrying about these things? I almost always start coding from the core data structures up, even when prototyping. A seemingly opposite approach as OPs post, not saying my method is THE correct method :)

gizmo686 10y ago
I a big fan of strong type systems; but can see where the concept of fighting the type system comes up with people who are used to dynamically typed languages. For example, consider the Haskell Maybe datatype. If you are used to a dynamically typed language, then it may feel like you are fighting the type system to cast between `Maybe x` and `x`. Indeed, in some cases these casts serve no purpose other than satisfying the type system because you, as the programmer, knows that the value cannot be nothing; so not having a cast "ought" to be the same as omitting a null pointer check. However, once you get used to strong typing, you realize that the only way you would get a Maybe type is if (to a first approximation) some programmer thought that there was a chance that the value would be nothing. In this case, it is probably a bug to not deal with the possibility anywhere, and the type system is warning you of this. If you happen to be sure that the value can never be Nothing, then you can use an unsafe cast and make it clear to future developers that you did not forget about the case, but rather were confident that it could never happen. Also, when you are prototyping, you might want to run code even if it has some bugs.
- KennyCason 10y ago
  I definitely see your point about "too much" enforcement, specifically with the case of error handling. In Java, I could just bubble everything up, default exit-early, and worry about proper handling later. I'm sure a similar argument could be stated for having to create simple data classes vs tuples or dynamic objects, or even number types. So I do agree there is a middle ground here. For example, Java will be friendly towards number casting whereas Haskell is very exacting.
dguaraglia 10y ago
Yeah, that's kind of misguided. The biggest advantages of dynamic languages when doing "exploratory" programming are late binding, built-in syntax for commonly used data structures and duck typing. Those allow you to scaffold a lot of stuff pretty quickly, try the bit of code that you care actually care about, and then decide from there whether you want to do a full implementation or just use the snippet you wrote. Compare that to a language like older Java, where you need to build a class no matter what, most likely you need to implement a few interfaces and add a lot of exception handling just to get the scaffolding in place, and if you want to initialize something as simple as a hash map you have to do it the painstakingly, line by line way. Sure, your prototype may (or may not, depending on how serious you were about handling those exceptions) be more solid, but it took you double the time to get there, which is basically the opposite of what prototyping should be. With all that said, and being a huge Python fan, I still feel like strongly typed languages should be a requirement for bigger projects that you plan to maintain for years. Python, as great as it is, starts hurting a lot at a larger scale. I'm really looking forward to using something like MyPy once my projects start being Python 3+ by default.
- KennyCason 10y ago
  Agreed. I have had to run vardumps on some large Python/JS code bases trying to figure out what the behavior was because it was unclear what the variables being passed in was. Definitely a pain as the project grows larger. I used to not understand why people who use Ruby/JS/Python were not fans of massive refactoring, until I owned a large PHP code base and saw first hand how hard it was to refactor. Search/Replace only gets you so far. Compared to of course, the powerful refactoring tools you get in a Java language via IDE.
cuddlybacon 10y ago
I am someone who mostly works with dynamic languages. When I find myself "fighting the type system" and having a hard time prototyping, I am specifically trying to figure out what my data types need to be. In some situations I find myself in a situation where in order to define my data type I need to know what the data is, but to know what the data is I need to define it's type. With a dynamic language you generally have an ability to get the data, pretty print it, then crash. Then you can go and define proper data types for the data you're working with.
- KennyCason 10y ago
  "get the data, pretty print it, then crash." That's the most common method for debugging types in dynamic languages haha. I am all too familiar with it. :) Though I enjoy simply never having to do this in Java/Kotlin for example. My method for verifying, even my prototypes, is unit tests.

gizmo686 10y ago

I a big fan of strong type systems; but can see where the concept of fighting the type system comes up with people who are used to dynamically typed languages. For example, consider the Haskell Maybe datatype. If you are used to a dynamically typed language, then it may feel like you are fighting the type system to cast between `Maybe x` and `x`. Indeed, in some cases these casts serve no purpose other than satisfying the type system because you, as the programmer, knows that the value cannot be nothing; so not having a cast "ought" to be the same as omitting a null pointer check. However, once you get used to strong typing, you realize that the only way you would get a Maybe type is if (to a first approximation) some programmer thought that there was a chance that the value would be nothing. In this case, it is probably a bug to not deal with the possibility anywhere, and the type system is warning you of this. If you happen to be sure that the value can never be Nothing, then you can use an unsafe cast and make it clear to future developers that you did not forget about the case, but rather were confident that it could never happen. Also, when you are prototyping, you might want to run code even if it has some bugs.

KennyCason 10y ago
I definitely see your point about "too much" enforcement, specifically with the case of error handling. In Java, I could just bubble everything up, default exit-early, and worry about proper handling later. I'm sure a similar argument could be stated for having to create simple data classes vs tuples or dynamic objects, or even number types. So I do agree there is a middle ground here. For example, Java will be friendly towards number casting whereas Haskell is very exacting.

dguaraglia 10y ago

Yeah, that's kind of misguided. The biggest advantages of dynamic languages when doing "exploratory" programming are late binding, built-in syntax for commonly used data structures and duck typing. Those allow you to scaffold a lot of stuff pretty quickly, try the bit of code that you care actually care about, and then decide from there whether you want to do a full implementation or just use the snippet you wrote. Compare that to a language like older Java, where you need to build a class no matter what, most likely you need to implement a few interfaces and add a lot of exception handling just to get the scaffolding in place, and if you want to initialize something as simple as a hash map you have to do it the painstakingly, line by line way. Sure, your prototype may (or may not, depending on how serious you were about handling those exceptions) be more solid, but it took you double the time to get there, which is basically the opposite of what prototyping should be. With all that said, and being a huge Python fan, I still feel like strongly typed languages should be a requirement for bigger projects that you plan to maintain for years. Python, as great as it is, starts hurting a lot at a larger scale. I'm really looking forward to using something like MyPy once my projects start being Python 3+ by default.

KennyCason 10y ago
Agreed. I have had to run vardumps on some large Python/JS code bases trying to figure out what the behavior was because it was unclear what the variables being passed in was. Definitely a pain as the project grows larger. I used to not understand why people who use Ruby/JS/Python were not fans of massive refactoring, until I owned a large PHP code base and saw first hand how hard it was to refactor. Search/Replace only gets you so far. Compared to of course, the powerful refactoring tools you get in a Java language via IDE.

cuddlybacon 10y ago

I am someone who mostly works with dynamic languages. When I find myself "fighting the type system" and having a hard time prototyping, I am specifically trying to figure out what my data types need to be. In some situations I find myself in a situation where in order to define my data type I need to know what the data is, but to know what the data is I need to define it's type. With a dynamic language you generally have an ability to get the data, pretty print it, then crash. Then you can go and define proper data types for the data you're working with.

KennyCason 10y ago
"get the data, pretty print it, then crash." That's the most common method for debugging types in dynamic languages haha. I am all too familiar with it. :) Though I enjoy simply never having to do this in Java/Kotlin for example. My method for verifying, even my prototypes, is unit tests.