3 ms·

I just don't buy the "dynamic types" lets you iterate faster argument. You are implicitly using types, and how often does that type change such that all the cod

I just don't buy the "dynamic types" lets you iterate faster argument. You are implicitly using types, and how often does that type change such that all the code you've written doesn't need to be updated anyways? And without the benefit of a compiler to tell you what you need to fix. A language like Go is fast to iterate, trivial to parse and serialize JSON, and simple enough that the tools let me make sweeping changes quite easily. For a while now I have felt that the reason for the creation of languages like Python and Ruby is simply a response to the pain of one such as C++. Now that we have modern languages like Rust and Go, what is there to be gained from sacrificing a type system?

phamilton 10y ago
Iterate faster != Rapid prototyping. The type system definitely helps with long term maintainability (and therefore fast iteration) but when your goal is to whip out a Proof of Concept for a greenfield project Ruby wins for me hands down. (Provided it isn't overly complex, defined as "can be completed in an hour or two").
- peteretep 10y ago
  Can you explain how types slow you down for whipping up a proof of concept?
  - phamilton 10y ago
    Hitting an API endpoint, pulling data out of a database. Areas that already have an implicit schema require you to explicitly redefine that schema within your application. I say this not just from personal preference, but I've proctored many timed coding challenges that were language agnostic. The challenge involved consuming data from a handful of API endpoints and compiling a response. Most statically typed solutions took twice the time of a dynamically typed one. We catered the time limit to the static case and it was a simple pass fail so no bonus points for doing it faster, but there was a strong advantage to the dynamic languages. Note: This is very much alleviated with typed interchange formats like protobuf.
    - hesdeadjim 10y ago
      That coding challenge sounds like a far cry from developing even a prototype application. What was the skill level of the people doing it? Had they had experience in both dynamic and static types languages? What were the languages, Java or something modern? Edit: I don't mean this to be snarky, I just feel that it is not a very good experiment to draw conclusions from.
      - phamilton 10y ago
        We prepped them ahead of time telling them that they would need to produce an HTTP API that accepted requests and returned a response compiled from multiple HTTP endpoints. It's basically an orchestration layer, and I've done similar things in production many times. ("If we exposed X to the clients, we could allow action Y. Would action Y contribute to our goal of Z?" Instead of building a highly performant correct solution, we would do an on the fly derivation of the data needed, launch it for 5% and see the experiment results.) It was for all candidates, meant to test ability to understand a problem and prototype a solution quickly. Edit: most candidates did Java/Scala/Python/Ruby.
  - caconym_ 10y ago
    I think it's not so much a fundamental issue with "strongly typed" languages as it is the way "dynamic" languages are typically designed. For instance, Ruby doesn't care if you add an integral type to a floating point type; it'll give you something back. A strongly typed language will typically complain about this (the alternative is e.g. an onerously huge constellation of custom typeclasses/traits/whatever to support the full range of numeric intermingling), and Ruby could too, but its designers have made the decision that arithmetic operations should silently convert one argument to the type of the other, and return the answer as an instance of that type. If I'm hacking together a quick and dirty prototype, I might not even care what type I get back from that operation as long as it's in the ballpark. Using Ruby means I just don't have to worry about it for longer than it takes me to type `a + b`. If I used Haskell, or Rust, or whatever, I have to be explicit. That's additional work, however minimal, and in my experience it really does add up. Of course, if I'm writing code that's going to be in production, this sort of thing is highly irresponsible and using a strongly typed language will help me to avoid numerical errors that would not even be runtime errors in e.g. Ruby; they'd be silently swallowed instead. That's extremely valuable. And if development of my prototype is going to span multiple days or more, strong types and compile-time type checking are going to reduce my mental workload since I don't have to remember how everything fits together; it's explictly annotated throughout the code and checked every time I build.

phamilton 10y ago

Iterate faster != Rapid prototyping. The type system definitely helps with long term maintainability (and therefore fast iteration) but when your goal is to whip out a Proof of Concept for a greenfield project Ruby wins for me hands down. (Provided it isn't overly complex, defined as "can be completed in an hour or two").

peteretep 10y ago
Can you explain how types slow you down for whipping up a proof of concept?
- phamilton 10y ago
  Hitting an API endpoint, pulling data out of a database. Areas that already have an implicit schema require you to explicitly redefine that schema within your application. I say this not just from personal preference, but I've proctored many timed coding challenges that were language agnostic. The challenge involved consuming data from a handful of API endpoints and compiling a response. Most statically typed solutions took twice the time of a dynamically typed one. We catered the time limit to the static case and it was a simple pass fail so no bonus points for doing it faster, but there was a strong advantage to the dynamic languages. Note: This is very much alleviated with typed interchange formats like protobuf.
  - hesdeadjim 10y ago
    That coding challenge sounds like a far cry from developing even a prototype application. What was the skill level of the people doing it? Had they had experience in both dynamic and static types languages? What were the languages, Java or something modern? Edit: I don't mean this to be snarky, I just feel that it is not a very good experiment to draw conclusions from.
    - phamilton 10y ago
      We prepped them ahead of time telling them that they would need to produce an HTTP API that accepted requests and returned a response compiled from multiple HTTP endpoints. It's basically an orchestration layer, and I've done similar things in production many times. ("If we exposed X to the clients, we could allow action Y. Would action Y contribute to our goal of Z?" Instead of building a highly performant correct solution, we would do an on the fly derivation of the data needed, launch it for 5% and see the experiment results.) It was for all candidates, meant to test ability to understand a problem and prototype a solution quickly. Edit: most candidates did Java/Scala/Python/Ruby.
- caconym_ 10y ago
  I think it's not so much a fundamental issue with "strongly typed" languages as it is the way "dynamic" languages are typically designed. For instance, Ruby doesn't care if you add an integral type to a floating point type; it'll give you something back. A strongly typed language will typically complain about this (the alternative is e.g. an onerously huge constellation of custom typeclasses/traits/whatever to support the full range of numeric intermingling), and Ruby could too, but its designers have made the decision that arithmetic operations should silently convert one argument to the type of the other, and return the answer as an instance of that type. If I'm hacking together a quick and dirty prototype, I might not even care what type I get back from that operation as long as it's in the ballpark. Using Ruby means I just don't have to worry about it for longer than it takes me to type `a + b`. If I used Haskell, or Rust, or whatever, I have to be explicit. That's additional work, however minimal, and in my experience it really does add up. Of course, if I'm writing code that's going to be in production, this sort of thing is highly irresponsible and using a strongly typed language will help me to avoid numerical errors that would not even be runtime errors in e.g. Ruby; they'd be silently swallowed instead. That's extremely valuable. And if development of my prototype is going to span multiple days or more, strong types and compile-time type checking are going to reduce my mental workload since I don't have to remember how everything fits together; it's explictly annotated throughout the code and checked every time I build.