8 ms·

They all started with dynamically typed languages because that was what the founders knew best when they started working on their project. Yes, you can build su

They all started with dynamically typed languages because that was what the founders knew best when they started working on their project. Yes, you can build successful projects with dynamically typed languages but it is a pain to refactor when you grow. You even introduce a class of bugs doesn’t exist for statically typed languages. You don’t see them redo everything only because the cost would be to big. Some developed their custom tooling to handle the language they are stuck with, see Facebook.

dragonwriter 9y ago
> You even introduce a class of bugs doesn’t exist for statically typed languages. As type systems vary, almost every statically-typed language allows some errors of the class statically-typed languages, in general, can prevent, so this is not really true. What is true is that on the continuum from no static validation to something like Idris or Agda, you accept more statically-avoidable type errors the closer you are to the former rather than the latter.
joshuamorton 9y ago
A rudimentary end2end test should catch most type related bugs. A type system aids in refactoring, not so much actually catching bugs.
- raquo 9y ago
  Static types are better and cheaper at catching type related bugs than a myriad of end-to-end tests that check dynamic types.
- dom0 9y ago
  Type systems can enforce so much more, depending on the language. They make reasoning about the code far easier for both human and machine. They enable efficient optimization. They allow far superior static analysis. They allow superior IDE assistance. They improve code navigability (ag/grep). There are countless advantages to static typing, and most of the disadvantages simply don't exist in modern languages any more. Meanwhile, dynamic languages haven't evolved significantly, except to add type annotations, which are like types, just almost always less powerful and not enforced by default. Dynamic languages excel at fast initial development and "gimmicky" code (wildfire monkey patching, introspection, dynamic code generation etc.), and to get there you pay dearly. Practically all other properties suffer; stability, maintainability, performance, memory usage, ease of deployment, distribution and so on and so forth. That doesn't mean that dynamic languages have no place, or applications developed using them are somehow generally inferior to those written in statically typed languages; choice of language is only one mosaic stone of many. But it is also a foundation stone, and dictates many constraints, both technical, and social.
  - rocky1138 9y ago
    Since most of the stuff I work on are prototypes that might never see the light of day, I love dynamic languages like JS. I always find it confusing why more implicit casts aren't allowed when I have to use things like Python or C#. If print() in Python includes a string and an int, I think the interpreter should be able to implicitly cast my int to string in order to make it all work. As it stands, I have to go back in and cast it myself, which kills productivity. Any idea as to why implicit casts aren't more supported in strictly typed languages? I'd prefer a warning on runtime than having to go back to the code.
    - dom0 9y ago
      > Any idea as to why implicit casts aren't more supported in strictly typed languages? That's the difference between weakly and strongly typed. If you take a strongly typed language, and add implicit casting, you get a weakly typed language. How this is resolved (or if at all) depends a lot on the language. For example, in C++ it is straightforward to define implicit conversions (which can become confusing). In Python on the other hand, it is generally up to the receiver to call some kind of conversion function, like str(), which will use an object protocol (like __str__) on the instance. This is what print("foo", 1) does, or "foo %s" % 1.
  - bayesian_horse 9y ago
    And still there is no proof, that ease of deployment and maintainability is enhanced through static typing.
gnaritas 9y ago
> You even introduce a class of bugs doesn’t exist for statically typed languages. Conversely, you're also able to write equivalent functionality with less code and with idioms you can't use in statically typed languages. It's an engineering trade off, the static typed handcuffs prevent you from making a certain kind of mistake but they also prevent you from writing certain kinds of code that are extremely powerful; many prefer the power over the handcuffs. Type bugs just aren't that painful.
- sjwright 9y ago
  > you're also able to write equivalent functionality with less code The amount of code one writes says more about the language than whether or not it's statically typed. To me, adding "bigint" or "bool" to the occasional variable and function declaration isn't "more code", it's an extremely terse way of avoiding different code (e.g. type assertions).
  - gnaritas 9y ago
    That's not what I mean by more code, by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function. You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done. This is typical of static languages, they forbid perfectly good code because it "might" be used inappropriately or because the type system can't guarantee it won't.
    - sjwright 9y ago
      Nothing is stopping languages from allowing both. For example, it could have some form of compound type declaration. Meanwhile, how often is code made worse because you have to write multiple Max implementations? And I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.
      - 9y ago

dragonwriter 9y ago

> You even introduce a class of bugs doesn’t exist for statically typed languages. As type systems vary, almost every statically-typed language allows some errors of the class statically-typed languages, in general, can prevent, so this is not really true. What is true is that on the continuum from no static validation to something like Idris or Agda, you accept more statically-avoidable type errors the closer you are to the former rather than the latter.

joshuamorton 9y ago

A rudimentary end2end test should catch most type related bugs. A type system aids in refactoring, not so much actually catching bugs.

raquo 9y ago
Static types are better and cheaper at catching type related bugs than a myriad of end-to-end tests that check dynamic types.
dom0 9y ago
Type systems can enforce so much more, depending on the language. They make reasoning about the code far easier for both human and machine. They enable efficient optimization. They allow far superior static analysis. They allow superior IDE assistance. They improve code navigability (ag/grep). There are countless advantages to static typing, and most of the disadvantages simply don't exist in modern languages any more. Meanwhile, dynamic languages haven't evolved significantly, except to add type annotations, which are like types, just almost always less powerful and not enforced by default. Dynamic languages excel at fast initial development and "gimmicky" code (wildfire monkey patching, introspection, dynamic code generation etc.), and to get there you pay dearly. Practically all other properties suffer; stability, maintainability, performance, memory usage, ease of deployment, distribution and so on and so forth. That doesn't mean that dynamic languages have no place, or applications developed using them are somehow generally inferior to those written in statically typed languages; choice of language is only one mosaic stone of many. But it is also a foundation stone, and dictates many constraints, both technical, and social.
- rocky1138 9y ago
  Since most of the stuff I work on are prototypes that might never see the light of day, I love dynamic languages like JS. I always find it confusing why more implicit casts aren't allowed when I have to use things like Python or C#. If print() in Python includes a string and an int, I think the interpreter should be able to implicitly cast my int to string in order to make it all work. As it stands, I have to go back in and cast it myself, which kills productivity. Any idea as to why implicit casts aren't more supported in strictly typed languages? I'd prefer a warning on runtime than having to go back to the code.
  - dom0 9y ago
    > Any idea as to why implicit casts aren't more supported in strictly typed languages? That's the difference between weakly and strongly typed. If you take a strongly typed language, and add implicit casting, you get a weakly typed language. How this is resolved (or if at all) depends a lot on the language. For example, in C++ it is straightforward to define implicit conversions (which can become confusing). In Python on the other hand, it is generally up to the receiver to call some kind of conversion function, like str(), which will use an object protocol (like __str__) on the instance. This is what print("foo", 1) does, or "foo %s" % 1.
- bayesian_horse 9y ago
  And still there is no proof, that ease of deployment and maintainability is enhanced through static typing.

gnaritas 9y ago

> You even introduce a class of bugs doesn’t exist for statically typed languages. Conversely, you're also able to write equivalent functionality with less code and with idioms you can't use in statically typed languages. It's an engineering trade off, the static typed handcuffs prevent you from making a certain kind of mistake but they also prevent you from writing certain kinds of code that are extremely powerful; many prefer the power over the handcuffs. Type bugs just aren't that painful.

sjwright 9y ago
> you're also able to write equivalent functionality with less code The amount of code one writes says more about the language than whether or not it's statically typed. To me, adding "bigint" or "bool" to the occasional variable and function declaration isn't "more code", it's an extremely terse way of avoiding different code (e.g. type assertions).
- gnaritas 9y ago
  That's not what I mean by more code, by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function. You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done. This is typical of static languages, they forbid perfectly good code because it "might" be used inappropriately or because the type system can't guarantee it won't.
  - sjwright 9y ago
    Nothing is stopping languages from allowing both. For example, it could have some form of compound type declaration. Meanwhile, how often is code made worse because you have to write multiple Max implementations? And I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.
    - 9y ago