4 ms·

The number of packages is correlated with number of users. Popular untyped languages tend to be designed for beginners, and thus have more users.

cryptica 7y ago
They're more popular with beginners because they're more expressive and simpler to reason about. I find naming types to be a major pain. In complex projects, you often end up with multiple types that are almost the same but have a few attributes different. In reality these are the same type, it's just not supposed to have a single fixed schema. For example, how would you model a tadpole which develops into a frog with a statically typed language? Do you need two different types for this? What about all the awkward intermediate states between tadpole and frog? How do you model those? Do you really need to create multiple different instances in the code to represent that one entity?
- nemo 7y ago
  I've programmed dynamically typed langs (Perl, PHP, Python, Ruby, JS) and statically typed langs (C, Java, Dart). I've worked on teams for projects that grew and matured, and my experience has been that strong typing and static analysis help prevent code defects that are common in dynamic langs. The tradeoffs can be well worth it for some kinds of larger team based projects.
- seanparsons 7y ago
  In a dynamic language it's entirely likely you still have those types, but they're just not defined anywhere. You the developer have to validate them in your head.
  - cryptica 7y ago
    In dynamically typed languages, you never check or think about the types, instead you only think about the features. Does this object have a run() method? Does it have a color property? It doesn't matter what type it is... Maybe it's a new kind of type that you could not have imagined when you first wrote the code, but if it supports the necessary method, it's going to work and you don't need to change or recompile your code to account for it.
    - cjfd 7y ago
      Asking the question 'what are the features of this thing' is a potentially very complicated question in a dynamic language. Each and every line of code could have added or removed a feature. Dynamic language make for very messy and unreliable computing.
      - gcthomas 7y ago
        But the choice between static and dynamic typing (or duck typing add described here) is not cost neutral. Dynamically typed languages can be much quicker and cheaper to write, making for more rapid business product cycles. The lack of type safety can largely be made up by adding to the already necessary unit tests. Isn't that how the YouTube startup out-manoeuvred Google's much larger dev team working with static types?
        AnimalMuppet 7y ago
        > Dynamically typed languages can be much quicker and cheaper to write... Code isn't just written, though. It's read, modified, and maintained. Sure, you can write it faster. But are you building that program for this week, or for the next two decades? (Yes, I know, you can be in a situation where writing it faster now is life-or-death for the company. Most of us won't spend most of our careers in that situation, though.)
    - coldtea 7y ago
      >Does this object have a run() method? Does it have a color property? It doesn't matter what type it is.. Only it very much matters... And to track it you have an ad-hoc, incomplete, custom, buggy, implementation of type checking in your head -- as opposed to in the program, and statically checked. >Maybe it's a new kind of type that you could not have imagined when you first wrote the code, but if it supports the necessary method, it's going to work and you don't need to change or recompile your code to account for it. You obviously need to change your code to have objects of that "new kind of type" (even if they are dynamic and untyped). Where would the new objects come from without changing the code in some place, the ether? Supporting the necessary method is a very poor check for "it's going to work". A "bomb" and a "lock" object might both have an "activate" method. You wouldn't want to call the former when you meant the latter. You're still doing the same checks, only know you do only half of them, in your head, and whatever goes...
- 0xFACEFEED 7y ago
  You model every state that your program is expected to handle. How else will the computer know what to do? If the state is modeled in numeric terms then you can represent the intermediate state as a range of integers. You need to do this whether or not your program is typed. Without types you're allowing the program to fall into a state that it doesn't know how to handle. This works because the program doesn't try to handle these intermediate invalid states. What happens when it eventually does try to handle that state? That's when bugs happen. Static type systems are a brute force way to eliminate a certain class of bug. A dynamic language appears simpler because it doesn't even attempt to capture those errors. It's like saying your payment validation is "simpler" because it doesn't do CCV checks.
- tom_mellior 7y ago
  I think if you gave an example implementation of your tadpole model in a dynamically typed language, people would be happy to sketch their version in a statically typed one. The question is much too vague so far.
  - cryptica 7y ago
    function createFrog() { // Tadpole state, can swim but cannot walk. return { color: 'black', size: 10, speed: 5, direction: 3.14, swim: function () { // ... } }; } function allowFrogToWalk(frog) { frog.walk = function () { // ... }; } function allowFrogToJump(frog) { frog.jump = function () { // ... }; } function makeFrogToxic(frog) { frog.intoxicate = function (animal) { // ... }; } let frog = createFrog(); // ... // Then when the frog reaches a certain size: allowFrogToWalk(frog); // After the frog spends a certain amount of time on land. allowFrogToJump(frog); // If frog eats a certain toxic plant. makeFrogToxic(frog); // ... // Let's say our game has many different kinds of animals and we manage them // from a single place in the code (and they can interact with each other). // When an animal tries to go on land: if (animal.walk) { // ... } // If animal enounters an obstacle: if (animal.jump) { // ... } // When an animal tries to go on water: if (animal.swim) { // ... } // When two animals touch each other if (touches(animalA, animalB)) { if (animalA.intoxicate) { animalA.intoxicate(animalB); } // ... } Doing this with a statically typed language would add a lot of unnecessary complexity. You'd need to create a lot of types/interfaces: - Animal (which has all the generic properties of an animal) - WaterAnimal (which inherits from Animal and can swim but not walk) - LandAnimal (which inherits from Animal and can walk but not swim) - Tadpole (inherits from WaterAnimal) - ToxicTadpole (inherits from tadpole but adds intoxicate method) - YoungFrog (inherits from WaterAnimal and LandAnimal and is constructed from a Tadpole instance, cannot jump) - ToxicYoungFrog (inherits from YoungFrog but adds intoxicate method) - MatureFrog (inherits from WaterAnimal and LandAnimal and is constructed from a YoungFrog instance, has the ability to Jump) - ToxicMatureFrog (inherits from MatureFrog but adds intoxicate method) As you add more complex functionality, you either have to support more permutations of different types or you have come up with some kind of complex decorator pattern which subverts the whole purpose of having static types to begin with.
msla 7y ago
Dynamic languages aren't untyped. BCPL was untyped. Python will complain loudly about type errors.

cryptica 7y ago

They're more popular with beginners because they're more expressive and simpler to reason about. I find naming types to be a major pain. In complex projects, you often end up with multiple types that are almost the same but have a few attributes different. In reality these are the same type, it's just not supposed to have a single fixed schema. For example, how would you model a tadpole which develops into a frog with a statically typed language? Do you need two different types for this? What about all the awkward intermediate states between tadpole and frog? How do you model those? Do you really need to create multiple different instances in the code to represent that one entity?

nemo 7y ago
I've programmed dynamically typed langs (Perl, PHP, Python, Ruby, JS) and statically typed langs (C, Java, Dart). I've worked on teams for projects that grew and matured, and my experience has been that strong typing and static analysis help prevent code defects that are common in dynamic langs. The tradeoffs can be well worth it for some kinds of larger team based projects.
seanparsons 7y ago
In a dynamic language it's entirely likely you still have those types, but they're just not defined anywhere. You the developer have to validate them in your head.
- cryptica 7y ago
  In dynamically typed languages, you never check or think about the types, instead you only think about the features. Does this object have a run() method? Does it have a color property? It doesn't matter what type it is... Maybe it's a new kind of type that you could not have imagined when you first wrote the code, but if it supports the necessary method, it's going to work and you don't need to change or recompile your code to account for it.
  - cjfd 7y ago
    Asking the question 'what are the features of this thing' is a potentially very complicated question in a dynamic language. Each and every line of code could have added or removed a feature. Dynamic language make for very messy and unreliable computing.
    - gcthomas 7y ago
      But the choice between static and dynamic typing (or duck typing add described here) is not cost neutral. Dynamically typed languages can be much quicker and cheaper to write, making for more rapid business product cycles. The lack of type safety can largely be made up by adding to the already necessary unit tests. Isn't that how the YouTube startup out-manoeuvred Google's much larger dev team working with static types?
      - AnimalMuppet 7y ago
        > Dynamically typed languages can be much quicker and cheaper to write... Code isn't just written, though. It's read, modified, and maintained. Sure, you can write it faster. But are you building that program for this week, or for the next two decades? (Yes, I know, you can be in a situation where writing it faster now is life-or-death for the company. Most of us won't spend most of our careers in that situation, though.)
  - coldtea 7y ago
    >Does this object have a run() method? Does it have a color property? It doesn't matter what type it is.. Only it very much matters... And to track it you have an ad-hoc, incomplete, custom, buggy, implementation of type checking in your head -- as opposed to in the program, and statically checked. >Maybe it's a new kind of type that you could not have imagined when you first wrote the code, but if it supports the necessary method, it's going to work and you don't need to change or recompile your code to account for it. You obviously need to change your code to have objects of that "new kind of type" (even if they are dynamic and untyped). Where would the new objects come from without changing the code in some place, the ether? Supporting the necessary method is a very poor check for "it's going to work". A "bomb" and a "lock" object might both have an "activate" method. You wouldn't want to call the former when you meant the latter. You're still doing the same checks, only know you do only half of them, in your head, and whatever goes...
0xFACEFEED 7y ago
You model every state that your program is expected to handle. How else will the computer know what to do? If the state is modeled in numeric terms then you can represent the intermediate state as a range of integers. You need to do this whether or not your program is typed. Without types you're allowing the program to fall into a state that it doesn't know how to handle. This works because the program doesn't try to handle these intermediate invalid states. What happens when it eventually does try to handle that state? That's when bugs happen. Static type systems are a brute force way to eliminate a certain class of bug. A dynamic language appears simpler because it doesn't even attempt to capture those errors. It's like saying your payment validation is "simpler" because it doesn't do CCV checks.
tom_mellior 7y ago
I think if you gave an example implementation of your tadpole model in a dynamically typed language, people would be happy to sketch their version in a statically typed one. The question is much too vague so far.
- cryptica 7y ago
  function createFrog() { // Tadpole state, can swim but cannot walk. return { color: 'black', size: 10, speed: 5, direction: 3.14, swim: function () { // ... } }; } function allowFrogToWalk(frog) { frog.walk = function () { // ... }; } function allowFrogToJump(frog) { frog.jump = function () { // ... }; } function makeFrogToxic(frog) { frog.intoxicate = function (animal) { // ... }; } let frog = createFrog(); // ... // Then when the frog reaches a certain size: allowFrogToWalk(frog); // After the frog spends a certain amount of time on land. allowFrogToJump(frog); // If frog eats a certain toxic plant. makeFrogToxic(frog); // ... // Let's say our game has many different kinds of animals and we manage them // from a single place in the code (and they can interact with each other). // When an animal tries to go on land: if (animal.walk) { // ... } // If animal enounters an obstacle: if (animal.jump) { // ... } // When an animal tries to go on water: if (animal.swim) { // ... } // When two animals touch each other if (touches(animalA, animalB)) { if (animalA.intoxicate) { animalA.intoxicate(animalB); } // ... } Doing this with a statically typed language would add a lot of unnecessary complexity. You'd need to create a lot of types/interfaces: - Animal (which has all the generic properties of an animal) - WaterAnimal (which inherits from Animal and can swim but not walk) - LandAnimal (which inherits from Animal and can walk but not swim) - Tadpole (inherits from WaterAnimal) - ToxicTadpole (inherits from tadpole but adds intoxicate method) - YoungFrog (inherits from WaterAnimal and LandAnimal and is constructed from a Tadpole instance, cannot jump) - ToxicYoungFrog (inherits from YoungFrog but adds intoxicate method) - MatureFrog (inherits from WaterAnimal and LandAnimal and is constructed from a YoungFrog instance, has the ability to Jump) - ToxicMatureFrog (inherits from MatureFrog but adds intoxicate method) As you add more complex functionality, you either have to support more permutations of different types or you have come up with some kind of complex decorator pattern which subverts the whole purpose of having static types to begin with.

msla 7y ago

Dynamic languages aren't untyped. BCPL was untyped. Python will complain loudly about type errors.