9 ms·

Static typing (in any language) is just like training wheels on a bike. It's great to learn with them but eventually, as your skill increases, the training whee

Static typing (in any language) is just like training wheels on a bike. It's great to learn with them but eventually, as your skill increases, the training wheels become a problem and then they must come off. Most things in the real world don't have a fixed set of attributes, attributes can change over time and as software developers we need to model that. There is a reason why the largest package managers (with the most packages published) are for dynamically typed languages. It's simply more flexible; these packages can work with anything; no need to import type definitions that don't fit within your type system. They are unopinionated, they return only simple objects and therefore they are highly composable.

continuational 7y ago
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.)
  - 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.
choeger 7y ago
> Static typing (in any language) is just like training wheels on a bike. Well, no. It is more like a ABS once you switched from a bike to a car that can go way more than 100kph. In theory, you can take all corners without, but it will be dangerous, you have to do more, and you cannot go quite as fast. And while everyone thinks they understand how it works, its inner mechanism is only understood by specialists.
sicromoft 7y ago
This is nonsense. Static types can represent things with a non-fixed set of attributes just fine. Also, note that the article isn't implying what you are: "Where stronger types are naturally present in the program, taking advantage of them to get better testing is certainly worth doing..."
esotericn 7y ago
YMMV. I've found precisely the opposite. Early in my career, dynamically typed languages allowed me to push hard and fast and learn a lot in a short space of time via rapid prototyping. If you don't care about error handling then you can wrangle hard with a dynamic language and it won't catch up with you for a long time. But eventually... Now? I generally write even Python scripts over a few tens of lines with mypy running, because otherwise it becomes necessary to adopt some form of Hungarian notation anyway, and then you're just doing typing badly. For the most part static typing prevents you from doing things you know you shouldn't anyway. Like tacking arbitrary attributes onto objects that get passed around. APIs change indeed; and you want to know whether a type has changed, not simply be surprised.
- zaphirplane 7y ago
  Do the lisp / Clojure people find the dynamic types a problem? I guess I’m curious if dynamic typed languages share the similar problem around refactoring or does Clojure have features that mitigate them
  - simongray 7y ago
    The thing that makes dynamic types quite easy to work with in Clojure is the fact that there's really not a whole lot of them there. In Clojure, pure data is king and creating your own types is strongly discouraged. It's possible to create types, mainly to allow for interop with Java and JS, but Clojure programmers really don't do it if it can be avoided. The flip side here is that ALL of the core functions work on ALL of the core data types, so no matter what type of data you're working on (sets, maps, lists/stacks, vectors, even strings) you run in to the same handful of data manipulation functions. All of the persistent data structures are immutable, memory-efficient, and allow for easy value-to-value comparisons. The Clojure data structures can also be applied as functions themselves so e.g. a map is both a data structure and a mapping function from one set of values to another. Everything fits neatly together like Lego bricks, you NEVER write any adapter code in Clojure. You do sometimes miss type information, especially when working with devs that aren't consistent in function parameter naming, but the trade-off is that you get a remarkably succinct and flexible language that really seems purpose-built to avoid the Lisp curse.
coldtea 7y ago
> Static typing (in any language) is just like training wheels on a bike. It's great to learn with them but eventually, as your skill increases, the training wheels become a problem and then they must come off. LOL, what? If anything, it's the opposite. Dynamic typing is the lesser easy-to-start with machine (say, a toy bike), and as the needs grow (for both safety, performance, and guarantees for working with larger codebases/teams) you add types... >Most things in the real world don't have a fixed set of attributes, attributes can change over time and as software developers we need to model that. Which is irrelevant. Our programs (functions, custom types, etc) have a fixed set of attributes at any given time -- as the code must know about them to use them in the first place. For things that we model and don't have fixed attributes, we can and do build ADTs and data structures to accommodate them.

continuational 7y ago

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.)
- 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.

choeger 7y ago

> Static typing (in any language) is just like training wheels on a bike. Well, no. It is more like a ABS once you switched from a bike to a car that can go way more than 100kph. In theory, you can take all corners without, but it will be dangerous, you have to do more, and you cannot go quite as fast. And while everyone thinks they understand how it works, its inner mechanism is only understood by specialists.

sicromoft 7y ago

This is nonsense. Static types can represent things with a non-fixed set of attributes just fine. Also, note that the article isn't implying what you are: "Where stronger types are naturally present in the program, taking advantage of them to get better testing is certainly worth doing..."

esotericn 7y ago

YMMV. I've found precisely the opposite. Early in my career, dynamically typed languages allowed me to push hard and fast and learn a lot in a short space of time via rapid prototyping. If you don't care about error handling then you can wrangle hard with a dynamic language and it won't catch up with you for a long time. But eventually... Now? I generally write even Python scripts over a few tens of lines with mypy running, because otherwise it becomes necessary to adopt some form of Hungarian notation anyway, and then you're just doing typing badly. For the most part static typing prevents you from doing things you know you shouldn't anyway. Like tacking arbitrary attributes onto objects that get passed around. APIs change indeed; and you want to know whether a type has changed, not simply be surprised.

zaphirplane 7y ago
Do the lisp / Clojure people find the dynamic types a problem? I guess I’m curious if dynamic typed languages share the similar problem around refactoring or does Clojure have features that mitigate them
- simongray 7y ago
  The thing that makes dynamic types quite easy to work with in Clojure is the fact that there's really not a whole lot of them there. In Clojure, pure data is king and creating your own types is strongly discouraged. It's possible to create types, mainly to allow for interop with Java and JS, but Clojure programmers really don't do it if it can be avoided. The flip side here is that ALL of the core functions work on ALL of the core data types, so no matter what type of data you're working on (sets, maps, lists/stacks, vectors, even strings) you run in to the same handful of data manipulation functions. All of the persistent data structures are immutable, memory-efficient, and allow for easy value-to-value comparisons. The Clojure data structures can also be applied as functions themselves so e.g. a map is both a data structure and a mapping function from one set of values to another. Everything fits neatly together like Lego bricks, you NEVER write any adapter code in Clojure. You do sometimes miss type information, especially when working with devs that aren't consistent in function parameter naming, but the trade-off is that you get a remarkably succinct and flexible language that really seems purpose-built to avoid the Lisp curse.

coldtea 7y ago

> Static typing (in any language) is just like training wheels on a bike. It's great to learn with them but eventually, as your skill increases, the training wheels become a problem and then they must come off. LOL, what? If anything, it's the opposite. Dynamic typing is the lesser easy-to-start with machine (say, a toy bike), and as the needs grow (for both safety, performance, and guarantees for working with larger codebases/teams) you add types... >Most things in the real world don't have a fixed set of attributes, attributes can change over time and as software developers we need to model that. Which is irrelevant. Our programs (functions, custom types, etc) have a fixed set of attributes at any given time -- as the code must know about them to use them in the first place. For things that we model and don't have fixed attributes, we can and do build ADTs and data structures to accommodate them.