4 ms·

"In dynamically typed languages, you keep the types in your mind" That's one way, or you could write clear unambiguous code such that the types are reasonably

"In dynamically typed languages, you keep the types in your mind" That's one way, or you could write clear unambiguous code such that the types are reasonably self evident.

jrockway 16y ago
In that case, why not let the computer tell you whether or not the types are reasonably self-evident? That's what static typing is. (Remember, don't mash up "Java and C++" with "static typing". Java and C++ are not worth mentioning when discussing type systems; they have type systems that get in the way and make it harder to code.)
- edanm 16y ago
  I've only every programmed in Java/C++, and dynamic languages, so I don't know what you mean. Do you know of any good resource to read up about a better type system and its benefits, but without having to learn a whole new language? (I don't have time to learn a new language, but this sounds important enough to read up on).
  - Periodic 16y ago
    A lot of the fun-to-program statically typed languages use type inference to determine types automatically. In these languages, as long as you make your types reasonably clear the compiler can go through and do type checking for you without you ever having to explicitly type a single expression. http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference
    - edanm 16y ago
      The big problem with statically typed languages isn't having to say "int" constantly. It's having to decide on a type hierarchy. What I mean is, when I write a function to do something with files, I don't want to have to decide whether I'm going to accept a "FILE" class or not. This isn't laziness: it's realizing that I will one day want to use a different class which looks like a file, but isn't part of the "file" hierarchy. This situation comes up far more often than one might think, and it saves a lot of headaches up-front (designing complicated hierarchies to prevent future use-cases you'll want). From what I've read, Type inference doesn't help with that. (But I haven't read much, so I could be wrong).
      - dlsspy 16y ago
        You can't learn this stuff by reading about it, you have to experience it. Some of your counter-arguments are outright confusing to those who have programmed in languages with type inference (hint: they don't necessarily have classes). Experience may help you change your mind. Reading papers and advocacy from people who've used it should provide limited influence. As an aside, there are solutions to programming problems I would've never come up with if it weren't for experience in other programming languages, so I read "don't have time to learn a new programming language" as "don't have time because I haven't learned a new programming language."

"In dynamically typed languages, you keep the types in your mind" That's one way, or you could write clear unambiguous code such that the types are reasonably self evident.

jrockway 16y ago

In that case, why not let the computer tell you whether or not the types are reasonably self-evident? That's what static typing is. (Remember, don't mash up "Java and C++" with "static typing". Java and C++ are not worth mentioning when discussing type systems; they have type systems that get in the way and make it harder to code.)

edanm 16y ago
I've only every programmed in Java/C++, and dynamic languages, so I don't know what you mean. Do you know of any good resource to read up about a better type system and its benefits, but without having to learn a whole new language? (I don't have time to learn a new language, but this sounds important enough to read up on).
- Periodic 16y ago
  A lot of the fun-to-program statically typed languages use type inference to determine types automatically. In these languages, as long as you make your types reasonably clear the compiler can go through and do type checking for you without you ever having to explicitly type a single expression. http://en.wikipedia.org/wiki/Type_inference http://en.wikipedia.org/wiki/Type_inference
  - edanm 16y ago
    The big problem with statically typed languages isn't having to say "int" constantly. It's having to decide on a type hierarchy. What I mean is, when I write a function to do something with files, I don't want to have to decide whether I'm going to accept a "FILE" class or not. This isn't laziness: it's realizing that I will one day want to use a different class which looks like a file, but isn't part of the "file" hierarchy. This situation comes up far more often than one might think, and it saves a lot of headaches up-front (designing complicated hierarchies to prevent future use-cases you'll want). From what I've read, Type inference doesn't help with that. (But I haven't read much, so I could be wrong).
    - dlsspy 16y ago
      You can't learn this stuff by reading about it, you have to experience it. Some of your counter-arguments are outright confusing to those who have programmed in languages with type inference (hint: they don't necessarily have classes). Experience may help you change your mind. Reading papers and advocacy from people who've used it should provide limited influence. As an aside, there are solutions to programming problems I would've never come up with if it weren't for experience in other programming languages, so I read "don't have time to learn a new programming language" as "don't have time because I haven't learned a new programming language."