4 ms·

I've had this discussion with co-workers before about scripting languages, and in particular Python, as that is what I am working with currently. I feel that on

by mickeyp 14y ago

I've had this discussion with co-workers before about scripting languages, and in particular Python, as that is what I am working with currently. I feel that once Python -- or indeed any loosey-goosey language that lack strong types -- programs grow beyond a certain size you easily fall into the "inconsistency trap", especially if you have many programmers working on the same code base. You have to be extra diligent with docstrings; unit tests and variable naming, or invent your own poor, ad hoc type checking with isinstance, or liberal use of exception handling if you insist on ensuring that Python's duck typing continues to work in your program. Invariably you'll end up with two camps: those who feel <dynamic lang> scales to large codebases, and those who do not; those in the former camp have (almost never) had to maintain a millions of lines of code before so they do not know just how helpful having a strict compiler is, and just how hard it is to refactor or infer the meaning of code due to the dynamic nature of the language. Linting will only get you so far. It's perfectly possible to write maintainable, large programs in dynamic languages, but it is infinitely harder than it should be.

reycharles 14y ago
Python is actually strongly typed. For example, 1+"1" will fail in python. Type errors will (usually) make the program crash. I believe this is a major plus over javascript when writing and maintaining large programs.
- mickeyp 14y ago
  Yes, crash at runtime. That's no good in a production environment when you can have hundreds of code paths and no real way of ensuring they are all correct. Mistakes happen, and code coverage tools are in my experience pretty useless at ensuring all code paths have been exercised (a theoretically futile task as well.) As for strongly typed- yes, that is true, but it is also dynamically typed, and combined with duck typing you're left with a philosophy that encourages interchangeable types provided the interface is similar. Strong typing come in many forms, and you can have strong types and still have a compiler there to help you out. But of course, no system is perfect. That's all well and good when you still have a complete, mental overview of the code and how it interacts at a macroscopic level. That's much harder to do when you go from 1 to many developers -- especially if you're developing code to be consumed by other developers.
  - reycharles 14y ago
    > Yes, crash at runtime. That's no good in a production environments My point is that it's a lot better than trying to continue in an inconsistent state. I'm not saying dynamic typed languages are better than static typed languages. Right now I use coq. I write programs and their correctness proofs so I definitely get why you would want some static guarantees.
    - mickeyp 14y ago
      Oh, I know you weren't. It wasn't a criticism of your observation at all, but one of those "sigh, why can't I have my cake and eat it" moments :)
  - illumen 14y ago
    Python has Abstract Base Classes, and also widely used zope.interfaces. These, along with simplicity, convention(pep8, frameworks), a stable base(stdlib), packages, a standard unittest framework, and a strong internet community help python code bases scale. JavaScript is missing a stable base, packages, ABCs and interfaces, and a shared testing framework. However many of these are available within separate communities like for example the jQuery community. jQuery provides a stable base, plugins, a good community to share code, a standard testing framework, a way to extend code (plugins) to make it reusable, and now it has a module system which can be shared with other JavaScript frameworks. I've been on 10+ JavaScript developer projects with 100+ developers over all. I've seen JavaScript code reused by one million+ developers. I've seen open source JavaScript projects with 100+ developers. So I have experienced myself that it can scale up to a certain point. As long as the team has the best practice skills to do it that is. JavaScript is the ultimate spaghetti making machine in the hands of newbies without direction.
    - mickeyp 14y ago
      They can scale, but not every code base is well written. Operating from the assumption that best practices is always implemented isn't necessarily true. Sometimes you work with sub-par code or code that was written by someone skilled but due to time pressure; misunderstanding the requirements; or a poorly planned architecture means that it does not lend itself to scalability. That's the problem. You can refactor it, but refactoring code in Python can be a nightmare compared with tools like Visual Studio that make it a breeze -- plus you get the benefit of having a compiler catch errors for you. Well-thought-out code will always trump bad code; but that's a truism.
- darkestkhan 14y ago
  You call that strong typing ? IMHO it is natural that it fails - what did you want as a result? But 1 + 1.0 works in Python - and I just added float to integer (integer was implicitly converted to float (given sufficiently large integer such behavior will result in erroneous calculation)), which is contrary to what strong typing is about.
  - crazyowl 14y ago
    This is true, but if that means python isn't strongly typed, then neither is Java or c++, since they too will convert for you. So, what widely used language is strongly typed then?
    - darkestkhan 14y ago
      Ada and Haskell from top of my head.
  - reycharles 14y ago
    Yes I do. ()+[] fails too. In javascript: 1+"1" --> "11", []+1 --> "1", null+[] --> "null" etc.
berntb 14y ago
Otoh, the scripting languages generate so much less code that many systems just aren't "large" in them... If I understand your position, the only thing really needed should be optional typing of parameters (and possibly variables) that are expanded to assert statements on compiling? And editor support for that typing, of course, to get popups with calling profiles? There is something in Perl [1], I don't know about Python. Write a PEP. :-) [1] Method::Signatures@CPAN, et al http://search.cpan.org/~barefoot/Method-Signatures/lib/Method/Signatures.pm http://search.cpan.org/~barefoot/Method-Signatures/lib/Metho... Edit: Basic English grammar, sigh.
- mickeyp 14y ago
  True, but large systems are just, well, large. I'm not thinking startup land here, but entrenched applications in bigger businesses that grow organically to meet the need of the business. Python 3 does have type annotations for use by linting tools, but it'll be another 5-6 years before we'll see that filter down into the current Python ecosystem. And even then, it's only as good as the weakest (non-annotated) piece of code. Retrofitting libraries and existing code will bring about its own issues: how do you accurately hint to linters, in a language that encourages duck typing, the type a method parameter is likely to take?
  - berntb 14y ago
    >>how do you accurately hint to linters, in a language that encourages duck typing, the type a method parameter is likely to take? You didn't check the Method::Signatures link or do I misunderstand your position? Also check Moose@CPAN, which have typing of object attributes. It isn't like a fully typed language, but it should help a lot. Edit: Link discussing type checking of attributes in Perl. Should be possible to have something similar in other dynamic languages? http://search.cpan.org/~doy/Moose-2.0602/lib/Moose/Util/TypeConstraints.pm http://search.cpan.org/~doy/Moose-2.0602/lib/Moose/Util/Type... Edit: Please check the links and see if Perl solves your problems? I am curious. (-: Writing a PEP to get something similar into Python is optional. :-)
    - mickeyp 14y ago

by mickeyp 14y ago

reycharles 14y ago

Python is actually strongly typed. For example, 1+"1" will fail in python. Type errors will (usually) make the program crash. I believe this is a major plus over javascript when writing and maintaining large programs.

mickeyp 14y ago
Yes, crash at runtime. That's no good in a production environment when you can have hundreds of code paths and no real way of ensuring they are all correct. Mistakes happen, and code coverage tools are in my experience pretty useless at ensuring all code paths have been exercised (a theoretically futile task as well.) As for strongly typed- yes, that is true, but it is also dynamically typed, and combined with duck typing you're left with a philosophy that encourages interchangeable types provided the interface is similar. Strong typing come in many forms, and you can have strong types and still have a compiler there to help you out. But of course, no system is perfect. That's all well and good when you still have a complete, mental overview of the code and how it interacts at a macroscopic level. That's much harder to do when you go from 1 to many developers -- especially if you're developing code to be consumed by other developers.
- reycharles 14y ago
  > Yes, crash at runtime. That's no good in a production environments My point is that it's a lot better than trying to continue in an inconsistent state. I'm not saying dynamic typed languages are better than static typed languages. Right now I use coq. I write programs and their correctness proofs so I definitely get why you would want some static guarantees.
  - mickeyp 14y ago
    Oh, I know you weren't. It wasn't a criticism of your observation at all, but one of those "sigh, why can't I have my cake and eat it" moments :)
- illumen 14y ago
  Python has Abstract Base Classes, and also widely used zope.interfaces. These, along with simplicity, convention(pep8, frameworks), a stable base(stdlib), packages, a standard unittest framework, and a strong internet community help python code bases scale. JavaScript is missing a stable base, packages, ABCs and interfaces, and a shared testing framework. However many of these are available within separate communities like for example the jQuery community. jQuery provides a stable base, plugins, a good community to share code, a standard testing framework, a way to extend code (plugins) to make it reusable, and now it has a module system which can be shared with other JavaScript frameworks. I've been on 10+ JavaScript developer projects with 100+ developers over all. I've seen JavaScript code reused by one million+ developers. I've seen open source JavaScript projects with 100+ developers. So I have experienced myself that it can scale up to a certain point. As long as the team has the best practice skills to do it that is. JavaScript is the ultimate spaghetti making machine in the hands of newbies without direction.
  - mickeyp 14y ago
    They can scale, but not every code base is well written. Operating from the assumption that best practices is always implemented isn't necessarily true. Sometimes you work with sub-par code or code that was written by someone skilled but due to time pressure; misunderstanding the requirements; or a poorly planned architecture means that it does not lend itself to scalability. That's the problem. You can refactor it, but refactoring code in Python can be a nightmare compared with tools like Visual Studio that make it a breeze -- plus you get the benefit of having a compiler catch errors for you. Well-thought-out code will always trump bad code; but that's a truism.
darkestkhan 14y ago
You call that strong typing ? IMHO it is natural that it fails - what did you want as a result? But 1 + 1.0 works in Python - and I just added float to integer (integer was implicitly converted to float (given sufficiently large integer such behavior will result in erroneous calculation)), which is contrary to what strong typing is about.
- crazyowl 14y ago
  This is true, but if that means python isn't strongly typed, then neither is Java or c++, since they too will convert for you. So, what widely used language is strongly typed then?
  - darkestkhan 14y ago
    Ada and Haskell from top of my head.
- reycharles 14y ago
  Yes I do. ()+[] fails too. In javascript: 1+"1" --> "11", []+1 --> "1", null+[] --> "null" etc.

berntb 14y ago

Otoh, the scripting languages generate so much less code that many systems just aren't "large" in them... If I understand your position, the only thing really needed should be optional typing of parameters (and possibly variables) that are expanded to assert statements on compiling? And editor support for that typing, of course, to get popups with calling profiles? There is something in Perl [1], I don't know about Python. Write a PEP. :-) [1] Method::Signatures@CPAN, et al http://search.cpan.org/~barefoot/Method-Signatures/lib/Method/Signatures.pm http://search.cpan.org/~barefoot/Method-Signatures/lib/Metho... Edit: Basic English grammar, sigh.

mickeyp 14y ago
True, but large systems are just, well, large. I'm not thinking startup land here, but entrenched applications in bigger businesses that grow organically to meet the need of the business. Python 3 does have type annotations for use by linting tools, but it'll be another 5-6 years before we'll see that filter down into the current Python ecosystem. And even then, it's only as good as the weakest (non-annotated) piece of code. Retrofitting libraries and existing code will bring about its own issues: how do you accurately hint to linters, in a language that encourages duck typing, the type a method parameter is likely to take?
- berntb 14y ago
  >>how do you accurately hint to linters, in a language that encourages duck typing, the type a method parameter is likely to take? You didn't check the Method::Signatures link or do I misunderstand your position? Also check Moose@CPAN, which have typing of object attributes. It isn't like a fully typed language, but it should help a lot. Edit: Link discussing type checking of attributes in Perl. Should be possible to have something similar in other dynamic languages? http://search.cpan.org/~doy/Moose-2.0602/lib/Moose/Util/TypeConstraints.pm http://search.cpan.org/~doy/Moose-2.0602/lib/Moose/Util/Type... Edit: Please check the links and see if Perl solves your problems? I am curious. (-: Writing a PEP to get something similar into Python is optional. :-)
  - mickeyp 14y ago