After reading this very informative (albeit somewhat argumentative) question I would like to know your experience with programming large projects with Python. Do things become un manageable as the project becomes larger? This concern is one thing that keeps me attached to Java. I would therefore be particularly interested in informed comparisons of maintainability and extensibility of Java and Python for large projects.
views:
205answers:
5
+9
Q:
How does Python's lack of static typing affect maintainability and extensibility in larger projects?
+4
A:
From my experience statically typed languages can be difficult to maintain. For instance lets say you have a utility function which accepts a custom class as a parameter. If down the road you adopt a new naming convention than this class's name will have to change, and then then all of your utility functions will have to change as well. In a language like python it doesn't matter as long at the class implements the same methods.
Personally I despise a language that gets in my way. Speed of expressing your ideas is value, and this is the advantage Python has over Java.
Rook
2010-09-08 21:11:16
I'm working on _the worse_ Java codebase ever created in the history of man kind at the moment. It is littered with unnecessary global state, do-nothing statements (including do nothing anonymous class instantiations), unnecessary custom class loaders, littering the filesystem with random garbage, race conditions, who knows what else, yet it is still relatively easy to work with... Why? because it's a simple language, although Python is too... The whole purpose of static typing is to make everything **static**; i.e: **easy to analyze**.
Longpoke
2010-09-08 22:43:48
Your naming convention example doesn't make any sense: 1. In both Python and Java, you _never_ pass the name of a class to a function unless you're asking for trouble, or have a _very_ specific use-case. 2. Contrary to reflection-free Java code, Python code _cannot_ be deterministically refactored to use new method names due to dynamic typing. 3. Pythonic code follows PEP8 naming conventions, most Java follows theConventionLikeThis, why would you ever use your own convention when you already have to intermix De facto libraries which all use the De facto conventions?
Longpoke
2010-09-08 22:50:54
Also, you might wanna try Haskell before you say static typing "gets in your way"... Perhaps your impression comes from the dumb (yet simple and sound) way Java implemented it.
Longpoke
2010-09-08 22:55:59
@Longpoke: His point about naming is that you need the typename in the function parameter. If you have a function `doStuff(CustomClass c)` and you decide you need to rename `CustomClass`, you just hosed all your methods that take that as a parameter. Although this is a very minimal problem since most IDEs allow you to just refactor it. And python doesn't get rid of this since you still have to instantiate objects and those calls will have to change too
Falmarri
2010-09-08 23:24:31
@Falmarri: Oops I misread, I thought he meant a function that takes a _name of a class_, rather than just a _class_. Agreed.
Longpoke
2010-09-09 00:07:47
@Longpoke I don't think there is a lower bound on bad logic, it doesn't matter what language it is expressed in.
Rook
2010-09-09 01:56:37
+1
A:
I've used Python for many projects, from a few hundred lines to several thousand lines. Dynamic typing is a great time saver and it makes OO concepts like polymorphism way easier to use. The type system does not make projects unmaintainable. If you have trouble imagining that, try writing a few things in Python and see how they go.
Nathon
2010-09-08 21:13:09
+4
A:
A large code base in python without good test coverage might be an issue. But thats just one part of the image. It's all about people and suitable approaches to do the job.
Without
- Source Control
- Bug Tracking
- Unit Tests
- Committed Team
you might fail with any kind of language.
zellus
2010-09-08 21:19:18
My experience has been that a Python codebase is less forgiving of new developers who've been tasked with maintaining the code after the original developers have already moved on. The particular codebase I encountered did not have any unit tests, which meant that all mistakes were only caught in integration tests or (as too often happened) in the field. Statically typed languages can catch some of the stupider mistakes you can make, but it's certainly not a magic bullet.
Dan Bryant
2010-09-09 00:59:20
+3
A:
I work on a large scale commercial product done in Python. I give a very rough estimate of 5000 files x 500 lines each. That's about 2.5 millions lines of Python. Mind you the complexity of this project is probably equivalent to 10 mil+ lines of code in other languages. I've not heard from a single engineer/architecture/manager who complain about Python code being unmaintainable. From what I've seen from our bug tracker, I do not see any systemic problem that could be avoided by static type checking. In fact there is very few bugs spawn from incorrect use of object type at all.
I think this is a very good academic subject to empirically study why static class based language does not seems to be as critical as one might think.
And about extensibility. We just added a database 2 on top of the database 1 in our product, both of them non-SQL. There is no issue related to type checking. First of all we have designed an API flexible enough to anticipate different underlying implementation. I think dynamic language is a helps rather than hindrance in this regard. When we went on to testing and bug fixing phrase, we were working on the kind of bugs people working on any language would have to face. For example, memory usage issues, consistence and referential integrity issues, error handling issues. I don't see static type checking have much help on any of these challenges. On the other hand we have benefited greatly from dynamic language by being able to inject code mid-flight or after simple patching. And we are able to test our hypothesis and demonstrate our fixes quickly.
It is safe to say most of our 100+ engineers are happy and productive using Python. It is probably unthinkable for us to build the same product using a static typed language in the same amount of time with the same quality.
Wai Yip Tung
2010-09-08 21:55:33
A:
I remember the days before and after the innovation of IntelliJ IDEA. There are huge differences. Before, static typing was only for compilation, development basically treats source code as text files. After, source code is structured information, many development tasks are must easier, thanks to static typing.
However, it's not like the old days were living hell. We took it as is, do whatever necessary, use the tools available to date, get the system built, satisfaction. There weren't too many unhappy memories. That's probably what dynamic typing programmers feel now. It's not that bad.
Of course, I'll never go back to the old days. If I'm forbidden to use such an IDE, I guess I'll give us programming all together.
irreputable
2010-09-08 23:46:20