Randall Parker wrote: > Also, compile time errors get caught sooner. They get caught before > tests even get written.
Not if you do Test Driven Tevelopment. Then you write the tests before you compile your target code! It's also my experience that the write test - write code - run test cycle in TDD with Python is often faster than the plain edit - compile cycle in C++. More extensive tests take longer, but so does linking of C++ code... There is obviously not one way of development which is optimal in all situations. I've done development for space equipment as well as business software. In my experience, software requirements in e.g. aerospace industry are much more stable. The people responsible for requirements and specifications are engineers, not accountants, and they understand systems development. In typical application development, I'd say that the effort required to get a finished, reasonably reliable product is much smaller with Python than with C++. You might need more tests, but the effort spent on that is easily outweighed by the time saved by coding in Python instead of C++, Java etc. If the requirements are very stable, there is less need for the kind of flexibility and agility that Python provides. One of the big advantages with the dynamic typing in Python is that you get less tight coupling. For instance, if you have some kind of layered approach in e.g. C++, and a number of parameters are passed from one layer to the next in several steps, changing the type of one parameter will cause changes everywhere in the communication chain. In Python on the other hand, it's typically only in the end-points that type changes will have an impact. In many development projects, the appropriate requirements aren't clear from the outset of the project. The problem in the project is not to implement a number of well defined protocols in an optimal way, but to provide a solution that will support the business in an efficient way. Initially, the problem domain experts and the software developers are probably far away from each other in their view of the system, and while the customer knows the business purpose of the system, it's not at all clear how this will be achieved. With tools and methods that are rigid and don't support a flexible and experimental approach, discovering problems with requirements or analysis in the middle of the project, might lead to costly and disruptive rewrites or that the project sticks with a clearly bad solution to avoid the risks that a rewrite leads to in terms of cost, time and reliability. Sure, big requirements changes late in a software project will hamper the development whatever tools you use, but how much these changes costs can probably vary tenfold depending on tools and methods. With Python and an agile approach, a late change is usually much cheaper, so it's not as unreasonable to make this late change that makes the product much better. -- http://mail.python.org/mailman/listinfo/python-list
