5 ms·

Quite a few poor and superficial answers in that link. The usual argument that dynamic typing does not scale for large projects is largely unfounded. There are

by cdavid 14y ago

Quite a few poor and superficial answers in that link. The usual argument that dynamic typing does not scale for large projects is largely unfounded. There are large projects in Lisp, I don't get why people don't use the dynamic card as often there. What I have seen happened on badly engineered large projects is people blaming it on dynamic typing because there is no documentation and no structural integrity in the project. But the people behind those projects would not be able to do much in any language IMO. In a sense, it allows for poor programmers to do more. The speed issue is a significant one, but not usually for the reasons given. The big drawback of being slow means a lots of its implementation is not written in python. IDE/debugger is another issue, although some of it is a matter of people not knowing the tool. Especially on bad codebases, even something as simple as pyflakes running in the background is invaluable, and many people don't use this.

theorique 14y ago
In a sense, it allows for poor programmers to do more. Exactly. Dynamic typing can provide a temporary fig leaf for bad design in ways where static type checking would be less forgiving. Doesn't make dynamic typing wrong, it just means that bad programmers can get in over their heads more completely and more quickly.
dkarl 14y ago
What I have seen happened on badly engineered large projects is people blaming it on dynamic typing because there is no documentation and no structural integrity in the project. This can be a problem in static languages with good type inference, too. When reading code in older static languages like C++, you'll find a bunch of variables and types declared, but powerful and concise languages such as Scala have much less use for intermediate variables, and type inference means that intermediate variables are almost never declared with a type. Field types and method return types often aren't declared either. I don't know if this is a good thing because it forces you to read a lot of code, or if it's a bad thing because it forces you to read many unrelated bits of code when you're trying to get something simple done.
- eru 14y ago
  In theory, your IDE/editor should cooperate with the compiler and display the inferred types for you, if you choose so.
  - dkarl 14y ago
    Yeah... in theory. When it comes to Scala, Intellij is still getting there, and I haven't tried other options recently.
- spitfire 14y ago
  That's because C and C++ are not static languages. Only people who leaned C and C++ first think they are.
  - josephlord 14y ago
    They are statically typed but only weakly typed (casts, void etc.) as is Java. Python is dynamically typed but again weakly. ML is strongly and dynamically typed. Anything that treats anything as a string or automatically casts from strings fills me with terror for general programming.
    - abdulhaq 14y ago
      No, python is strongly typed.
      - masklinn 14y ago
        You should avoid using those words, it merely marks you as somebody without a clue. I'm guessing your grandparent is already lost so there's no point in warning him.
        prodigal_erik 14y ago
        C and C++ are weakly typed because you can do things like int x = 42; printf("%c\n", *(char *) &x); that is, access the underlying bits which represent a value as if they were of some completely different type. The results are deliberately not standardized and vary with your machine. Python doesn't provide any way to do this; at worst you get a TypeError for a conversion that isn't implemented, or AttributeError for a slot that an object doesn't have. Implicitly parsing strings to produce numbers isn't weak typing, merely reckless and prone to mistakes. Weak typing can corrupt the state of your program so severely that even correct code begins to malfunction.
wonderzombie 14y ago
I've been digging into Clojure and reading Paul Graham's On Lisp. So I've been wondering about Python vs. Lisp lately, esp. on the topic of dynamism. I wish I knew more about Lisp to delve into this further, but your first para caught my eye. Is it not the case that in Lisp people tend to use values — lists of (probably immutable) data — rather than objects? Objects are in and of themselves their own flavor of custom, specialized language for interacting with a data structure. In Lisp, the language for interacting with lists of lists or what have you is, well, Lisp. IME duck typing is not a real answer in this situation; that helps when you are programming to an interface in the standard library, or in an API you are using. Otherwise I end up hunting down information about a data type through N layers of method and function calls. Not a good time. :( This actually drove me towards Go as a language with comparable productivity but with a type checker, et al. I'm not sure where Lisp macros fit into this, if they do. I expect they have a tendency to boil down frequently repeated patterns into something very compact and less error-prone. As for IDE support, Rob Pike suggested (not in so many words) that if you need an IDE for your programming language, it suggests that something's probably wrong with that language. He's not disputing that people genuinely need them, because yes, jesus h, I really do need Eclipse when you're programming against a reasonably large API. I think I find this line of reasoning more convincing than I would have, say, a year or two ago. Anyway, for my part, ST2 was enough of a Python IDE for me. And thanks for the tip about Pyflakes, by the way. There's guard[1], which I figured you could rig up with python -c or whatever the flag is to compile. Pyflakes looks easier. [1]: https://github.com/guard/guard https://github.com/guard/guard
- masklinn 14y ago
  > Pyflakes looks easier. Look up flake8, it runs both pyflakes and pep8, and can optionally warn about cyclomatic complexity as well.
- cdavid 14y ago
  I would say that idiomatic python code often does not overuse objects. Lack of immutable data is indeed something I miss (especially COW dict/list/set). One thing that is clearly overused in python code is dictionaries to pass data where the set of keys is fixed and known, or worse passing dict with different set of keys instead of proper 'modelling'. Things like traits (http://code.enthought.com/projects/traits http://code.enthought.com/projects/traits - disclaimer, I work for Enthought ), or even simple libraries like remoteobjects (https://github.com/saymedia/remoteobjects https://github.com/saymedia/remoteobjects) can be helpful in those cases. I myself don't use IDE much: I am too entrenched with vim to gain enough from an IDE, although pycharm is quite nice. I would much rather see libraries around things IDE do ('live' 'AST' of a whole project, good refactoring, debugging) so that one can integrate them in whatever environment people use. I think we are going there (https://groups.google.com/forum/?fromgroups#!forum/python-static-type-checking https://groups.google.com/forum/?fromgroups#!forum/python-st...). Go does look nice, but it misses two killer features for me: NumPy and the whole scipy ecosystem, and C integration (in both directions). I think the python community itself does not realize how big and significant the scipy ecosystem is (nothing comes anywhere near in any common language AFAIK).

by cdavid 14y ago

theorique 14y ago

In a sense, it allows for poor programmers to do more. Exactly. Dynamic typing can provide a temporary fig leaf for bad design in ways where static type checking would be less forgiving. Doesn't make dynamic typing wrong, it just means that bad programmers can get in over their heads more completely and more quickly.

dkarl 14y ago

What I have seen happened on badly engineered large projects is people blaming it on dynamic typing because there is no documentation and no structural integrity in the project. This can be a problem in static languages with good type inference, too. When reading code in older static languages like C++, you'll find a bunch of variables and types declared, but powerful and concise languages such as Scala have much less use for intermediate variables, and type inference means that intermediate variables are almost never declared with a type. Field types and method return types often aren't declared either. I don't know if this is a good thing because it forces you to read a lot of code, or if it's a bad thing because it forces you to read many unrelated bits of code when you're trying to get something simple done.

eru 14y ago
In theory, your IDE/editor should cooperate with the compiler and display the inferred types for you, if you choose so.
- dkarl 14y ago
  Yeah... in theory. When it comes to Scala, Intellij is still getting there, and I haven't tried other options recently.
spitfire 14y ago
That's because C and C++ are not static languages. Only people who leaned C and C++ first think they are.
- josephlord 14y ago
  They are statically typed but only weakly typed (casts, void etc.) as is Java. Python is dynamically typed but again weakly. ML is strongly and dynamically typed. Anything that treats anything as a string or automatically casts from strings fills me with terror for general programming.
  - abdulhaq 14y ago
    No, python is strongly typed.
    - masklinn 14y ago
      You should avoid using those words, it merely marks you as somebody without a clue. I'm guessing your grandparent is already lost so there's no point in warning him.
      - prodigal_erik 14y ago
        C and C++ are weakly typed because you can do things like int x = 42; printf("%c\n", *(char *) &x); that is, access the underlying bits which represent a value as if they were of some completely different type. The results are deliberately not standardized and vary with your machine. Python doesn't provide any way to do this; at worst you get a TypeError for a conversion that isn't implemented, or AttributeError for a slot that an object doesn't have. Implicitly parsing strings to produce numbers isn't weak typing, merely reckless and prone to mistakes. Weak typing can corrupt the state of your program so severely that even correct code begins to malfunction.

wonderzombie 14y ago

I've been digging into Clojure and reading Paul Graham's On Lisp. So I've been wondering about Python vs. Lisp lately, esp. on the topic of dynamism. I wish I knew more about Lisp to delve into this further, but your first para caught my eye. Is it not the case that in Lisp people tend to use values — lists of (probably immutable) data — rather than objects? Objects are in and of themselves their own flavor of custom, specialized language for interacting with a data structure. In Lisp, the language for interacting with lists of lists or what have you is, well, Lisp. IME duck typing is not a real answer in this situation; that helps when you are programming to an interface in the standard library, or in an API you are using. Otherwise I end up hunting down information about a data type through N layers of method and function calls. Not a good time. :( This actually drove me towards Go as a language with comparable productivity but with a type checker, et al. I'm not sure where Lisp macros fit into this, if they do. I expect they have a tendency to boil down frequently repeated patterns into something very compact and less error-prone. As for IDE support, Rob Pike suggested (not in so many words) that if you need an IDE for your programming language, it suggests that something's probably wrong with that language. He's not disputing that people genuinely need them, because yes, jesus h, I really do need Eclipse when you're programming against a reasonably large API. I think I find this line of reasoning more convincing than I would have, say, a year or two ago. Anyway, for my part, ST2 was enough of a Python IDE for me. And thanks for the tip about Pyflakes, by the way. There's guard[1], which I figured you could rig up with python -c or whatever the flag is to compile. Pyflakes looks easier. [1]: https://github.com/guard/guard https://github.com/guard/guard

masklinn 14y ago
> Pyflakes looks easier. Look up flake8, it runs both pyflakes and pep8, and can optionally warn about cyclomatic complexity as well.
cdavid 14y ago
I would say that idiomatic python code often does not overuse objects. Lack of immutable data is indeed something I miss (especially COW dict/list/set). One thing that is clearly overused in python code is dictionaries to pass data where the set of keys is fixed and known, or worse passing dict with different set of keys instead of proper 'modelling'. Things like traits (http://code.enthought.com/projects/traits http://code.enthought.com/projects/traits - disclaimer, I work for Enthought ), or even simple libraries like remoteobjects (https://github.com/saymedia/remoteobjects https://github.com/saymedia/remoteobjects) can be helpful in those cases. I myself don't use IDE much: I am too entrenched with vim to gain enough from an IDE, although pycharm is quite nice. I would much rather see libraries around things IDE do ('live' 'AST' of a whole project, good refactoring, debugging) so that one can integrate them in whatever environment people use. I think we are going there (https://groups.google.com/forum/?fromgroups#!forum/python-static-type-checking https://groups.google.com/forum/?fromgroups#!forum/python-st...). Go does look nice, but it misses two killer features for me: NumPy and the whole scipy ecosystem, and C integration (in both directions). I think the python community itself does not realize how big and significant the scipy ecosystem is (nothing comes anywhere near in any common language AFAIK).