Python vs C for a mail server

[Magnus Lycka]

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.