31 ms·

My biggest problem with Python is that projects larger than a given size tend to become unmaintainable rather quickly. This is in large part because of the lac

My biggest problem with Python is that projects larger than a given size tend to become unmaintainable rather quickly. This is in large part because of the lack of strong typing and type annotations; if you aren't the only author or can't keep the codebase in your head, it takes real effort to figure out what a function does. Even the type annotations provided in a language like Java or C++ make this task much easier, not to mention languages with real strong type systems like Haskell. That's not to say that building large systems in Python is impossible, but it takes a lot more effort and documentation that it would in other languages.

agentgt 15y ago
I agree and I was worried I was the only who would say it :)
mef 15y ago
Yup. This is also the case with Ruby, and is one of the challenges when trying to dive in to a large unfamiliar project. For example, when something in Rails doesn't behave correctly and you flip deep into a source file, it's not always easy to track down exactly what kind of arguments a method expects. Often you'll have to breakpoint inside the method just to inspect what's around.
niels 15y ago
Just to be clear, Python is strongly typed but not statically typed. But I definitively agree with your comment. The startup I'm working for is Python based, but I'm currently learning Haskell, because I'd like to take advantage of a good type system for my larger efforts.
- lelele 15y ago
  Aren't you concerned about unpredictable memory requirements?
  - niels 15y ago
    To be honest I don't have enough experience with lazily evaluated languages to be concerned about it yet.
scott_w 15y ago
I must respectfully disagree. I work with web-based systems and find the dynamic typing of Python to be its biggest strength. The ability to just throw another property onto an object before sending it to the template-engine saves so much engineering work, it totally overcomes the downsides of not annotating required types. I can see where it may be an issue, but I think the documentation should focus on what function calls need to be supported, as opposed to type-checking i.e. "This function takes an object with the read() and update() methods."
- softbuilder 15y ago
  "I must respectfully disagree. I work with web-based systems" Web-based systems tend toward smallness and/or flatness, with fairly straight execution paths through the system. You're not going to run into the limitations being discussed.
  - njharman 15y ago
    Yeah and big systems architects should really learn from that. A bunch of small services connected by well defined interfaces is the flipping bomb!
    - softbuilder 15y ago
      When possible, I totally agree. It's great when you can get it. Most of the work I do is just like what you describe. Sometimes it's not, and that's when I really feel the utility of types.
- skymt 15y ago
  That's essentially how Go handles polymorphism. http://golang.org/doc/go_spec.html#Interface_types http://golang.org/doc/go_spec.html#Interface_types
- pranjalv123 15y ago
  I think the proper way to do this is through the use of interfaces (Java), abstract superclasses (C++), or typeclasses (Haskell, etc.). These give you the benefits of polymorphism, e.g. you can pass anything that implements "read" to a function that processes input in a given way, but also gives you the compile time typechecking that helps you avoid bugs.
anthonyb 15y ago
I find that it's a problem with most languages. Beyond a certain point a project will start to need infrastructure, documentation, code style guidelines and tests - especially when there's more than one developer. My personal preference is for building a large project as multiple smaller ones, or else leaning on other libraries as much as possible (eg. Numpy, Scipy, pygame)
evincarofautumn 15y ago
This is a significant problem for me as well, coming from C++ and Haskell. Even just going through and making a few changes here and there, there’s no way for me to know without extensive testing whether my edit was even remotely correct beyond a cursory syntax check. I’ve never had to deal with testing all that heavily in statically typed languages, because I can rely on the type system to do a lot of very helpful static analysis. The lack of basic static knowledge about a Python program is frustrating and discomfiting, and ultimately discourages me from using the language for anything serious.
- aangjie 15y ago
  +1 on the static type checking problem.. i am beginning to feel very annoyed by the same... have found that writing and maintaining unit test cases help.. but are a PITA nevertheless...
  - evincarofautumn 15y ago
    Well, as I see it, more or less every error should be expressible as a type error. In order to actually do that, you’d need full dependent types, and that’s a huge language-design “now you have two problems” feature—compiler authors are understandably uncomfortable with undecidable, non-inferable type systems. Anyway, Haskell and even C++ used intelligently can tell you a lot about your program at the outset, so ultimately your tests can be more focused.
    - aangjie 15y ago
      > more or less every error should be expressible as a type error. Am not sure i agree.. i would like to believe it's true though.... >Haskell have just begun to poke around, like the currying + function composition.. will keep poking...
    - pranjalv123 15y ago
      Yep, I agree with you - although every error should be expressible as a type error, languages like Coq where this is actually possible make writing usable code pretty difficult. I think there's a pretty wide range of middle ground, ranging from C++ to Haskell, where you get the benefit of static types without making it really difficult to write working code.
TylerE 15y ago
An alternative viewpoint is that Python makes it so you GET to that point a lot quicker, since your iterative development cycle is so much faster, No compiles, no need to refactor a bunch of stuff to accommodate minor data structure changes...
overgard 15y ago
Python 3 actually does let you annotate function arguments, although it's with an arbitrary expression rather than explicitly being a type. So this is valid: def haul(item: Haulable, *vargs: PackAnimal) -> Distance: As is this: def thing(something: "A string!") -> "does stuff": It's also not explicitly checked, although if you felt like it you could probably write a metaclass to enforce type checking. (Though I imagine to do so would be rather un-pythonic)
gbog 15y ago
Working on big legacy code base without proper unit testing and strong style checks is probably hard in any case. With Python the idea is that e are grownups. If someone accesses private methods or changes the type of an argument without proper checking, it's his problem.

agentgt 15y ago

I agree and I was worried I was the only who would say it :)

mef 15y ago

Yup. This is also the case with Ruby, and is one of the challenges when trying to dive in to a large unfamiliar project. For example, when something in Rails doesn't behave correctly and you flip deep into a source file, it's not always easy to track down exactly what kind of arguments a method expects. Often you'll have to breakpoint inside the method just to inspect what's around.

niels 15y ago

Just to be clear, Python is strongly typed but not statically typed. But I definitively agree with your comment. The startup I'm working for is Python based, but I'm currently learning Haskell, because I'd like to take advantage of a good type system for my larger efforts.

lelele 15y ago
Aren't you concerned about unpredictable memory requirements?
- niels 15y ago
  To be honest I don't have enough experience with lazily evaluated languages to be concerned about it yet.

scott_w 15y ago

I must respectfully disagree. I work with web-based systems and find the dynamic typing of Python to be its biggest strength. The ability to just throw another property onto an object before sending it to the template-engine saves so much engineering work, it totally overcomes the downsides of not annotating required types. I can see where it may be an issue, but I think the documentation should focus on what function calls need to be supported, as opposed to type-checking i.e. "This function takes an object with the read() and update() methods."

softbuilder 15y ago
"I must respectfully disagree. I work with web-based systems" Web-based systems tend toward smallness and/or flatness, with fairly straight execution paths through the system. You're not going to run into the limitations being discussed.
- njharman 15y ago
  Yeah and big systems architects should really learn from that. A bunch of small services connected by well defined interfaces is the flipping bomb!
  - softbuilder 15y ago
    When possible, I totally agree. It's great when you can get it. Most of the work I do is just like what you describe. Sometimes it's not, and that's when I really feel the utility of types.
skymt 15y ago
That's essentially how Go handles polymorphism. http://golang.org/doc/go_spec.html#Interface_types http://golang.org/doc/go_spec.html#Interface_types
pranjalv123 15y ago
I think the proper way to do this is through the use of interfaces (Java), abstract superclasses (C++), or typeclasses (Haskell, etc.). These give you the benefits of polymorphism, e.g. you can pass anything that implements "read" to a function that processes input in a given way, but also gives you the compile time typechecking that helps you avoid bugs.

anthonyb 15y ago

I find that it's a problem with most languages. Beyond a certain point a project will start to need infrastructure, documentation, code style guidelines and tests - especially when there's more than one developer. My personal preference is for building a large project as multiple smaller ones, or else leaning on other libraries as much as possible (eg. Numpy, Scipy, pygame)

evincarofautumn 15y ago

This is a significant problem for me as well, coming from C++ and Haskell. Even just going through and making a few changes here and there, there’s no way for me to know without extensive testing whether my edit was even remotely correct beyond a cursory syntax check. I’ve never had to deal with testing all that heavily in statically typed languages, because I can rely on the type system to do a lot of very helpful static analysis. The lack of basic static knowledge about a Python program is frustrating and discomfiting, and ultimately discourages me from using the language for anything serious.

aangjie 15y ago
+1 on the static type checking problem.. i am beginning to feel very annoyed by the same... have found that writing and maintaining unit test cases help.. but are a PITA nevertheless...
- evincarofautumn 15y ago
  Well, as I see it, more or less every error should be expressible as a type error. In order to actually do that, you’d need full dependent types, and that’s a huge language-design “now you have two problems” feature—compiler authors are understandably uncomfortable with undecidable, non-inferable type systems. Anyway, Haskell and even C++ used intelligently can tell you a lot about your program at the outset, so ultimately your tests can be more focused.
  - aangjie 15y ago
    > more or less every error should be expressible as a type error. Am not sure i agree.. i would like to believe it's true though.... >Haskell have just begun to poke around, like the currying + function composition.. will keep poking...
  - pranjalv123 15y ago
    Yep, I agree with you - although every error should be expressible as a type error, languages like Coq where this is actually possible make writing usable code pretty difficult. I think there's a pretty wide range of middle ground, ranging from C++ to Haskell, where you get the benefit of static types without making it really difficult to write working code.

TylerE 15y ago

An alternative viewpoint is that Python makes it so you GET to that point a lot quicker, since your iterative development cycle is so much faster, No compiles, no need to refactor a bunch of stuff to accommodate minor data structure changes...

overgard 15y ago

Python 3 actually does let you annotate function arguments, although it's with an arbitrary expression rather than explicitly being a type. So this is valid: def haul(item: Haulable, *vargs: PackAnimal) -> Distance: As is this: def thing(something: "A string!") -> "does stuff": It's also not explicitly checked, although if you felt like it you could probably write a metaclass to enforce type checking. (Though I imagine to do so would be rather un-pythonic)

gbog 15y ago

Working on big legacy code base without proper unit testing and strong style checks is probably hard in any case. With Python the idea is that e are grownups. If someone accesses private methods or changes the type of an argument without proper checking, it's his problem.