Welcome to Python Matthias. I hope you will enjoy it! Matthias Kaeppler wrote: > Another thing which is really bugging me about this whole dynamically > typing thing is that it seems very error prone to me: > > foo = "some string!" > > # ... > > if (something_fubar): > fo = "another string" > > Oops, the last 'o' slipped, now we have a different object and the > interpreter will happily continue executing the flawed program.
As an old hardware designer from the space industry, I'm well aquainted with the idea of adding redundancy to make things more reliable. I also know that this doesn't come without a prize. All this stuff you add to detect possible errors might also introduce new errors, and it takes a lot of time and effort to implement--time that could be spent on better things. In fact, the typical solutions that are used to increase the odds that hardware doesn't fail before its Mean Time To Failure (MTTF), will significantly lower the chance that it works much longer than its MTTF! More isn't always better. While not the same thing, software development is similar. All that redundancy in typical C++ programs has a high development cost. Most of the stuff in C++ include files are repeated in the source code, and the splitting of code between include and source files mean that a lot of declarations are far from the definitions. We know that this is a problem: That's why C++ departed from C's concept of putting all local declarations in the beginning of functions. Things that are closely related should be as close as possible in the code! The static typing means that you either have to make several implementations of many algorithms, or you need to work with those convoluted templates that were added to the language as an afterthought. Generally, the more you type, the more you will mistype. I even suspect that the bug rate grows faster than the size of the code. If you have to type five times as much, you will probably make typos five times as many times, but you also have the problem that the larger amount of code is more difficult to grasp. It's less likely that all relevant things are visible on the screen at the same time etc. You'll make more errors that aren't typos. Python is designed to allow you to easily write short and clear programs. Its dynamic typing is a very important part of that. The important thing isn't that we are relieved from the boring task of typing type declarations, but rather that the code we write can be much more generic, and the coupling between function definitions and function callers can be looser. This means that we get faster development and easier maintenace if we learn to use this right. Sure, a C++ or Java compiler will discover some mistakes that would pass through the Python compiler. This is not a design flaw in Python, it's a direct consequence of its dynamic nature. Compile time type limitations goes against the very nature of Python. It's not the checks we try to avoid--it's the premature restrictions in functionality. Anyway, I'm sure you know that a successful build with C++ or Java doesn't imply correct behaviour of your program. All software needs to be tested, and if we want to work effectively and be confident that we don't break things as we add features or tidy up our code, we need to make automated tests. There are good tools, such as unittest, doctest, py.test and TextTest that can help us with that. If you have proper automated tests, those tests will capture your mistypings, whether they would have been caught by a C++ or Java compiler or not. (Well, not if they are in dead code, but C++/Java won't give you any intelligent help with that either...) I've certainly lost time due to mistyped variables now and then. It's not uncommon that I've actually mistyped in a way that Java/C++ would never notice (e.g. typed i instead of j in some nested for loop etc) but sometimes compile time type checking would have saved time for me. On the other hand, I'm sure that type declarations on variables would bring a rigidity to Python that would cost me much more than I would gain, and with typeless declarations as in Perl (local x) I would probably waste more time on adding forgotten declarations (or removing redundant ones) than I would save time on noticing the variable mistypings a few seconds before my unittests catch them. Besides, there are a number of lint-like tools for Python if you want static code checks. As I wrote, the lack of type checking in Python is a consequence of the very dynamic nature of the language. A function should assume as little as possible about its parameters, to be able to function in the broadest possible scope. Don't add complexity to make you code support things you don't know of a need for, but take the chance Python gives you of assuming as little as possible about your callers and the code you call. This leads to more flexible and maintainable software. A design change in your software will probably lead to much more code changes if you write in C++ than if you write in Python. While feature-by-feature comparisions of different programming languages might have some merit, the only thing that counts in the end is how the total package works... I think you'll find that Python is a useful package, and a good tool in a bigger tool chest. -- http://mail.python.org/mailman/listinfo/python-list
