Python vs C for a mail server

[Magnus Lycka]

Randall Parker wrote:
> Magnus Lycka wrote:
> 
>>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...
> 
> 
> Magnus,
> 
> I see a problem with your argument: On the one hand you say that
> Python's lack of type declarations can be compensated for by Test
> Driven Development. But then you say Python has a bigger advantage in
> situations where requirements are not well defined. Well, when
> requirements are in flux and being explored during development it is a
> waste of time to write tests to test against nebulous requirements. TDD
> and poor requirements don't mix very well.

Not at all. Agile development methods such as XP, where TDD is
fundamental, were developed with the purpose of making to easy
to handle changes late in the project. "Embrace change" as
Kent Beck put it.

Unit tests aren't really used to verify that a whole program system
fulfils all requirements. They're there to verify that a small piece
of code works as the programmer intended. To be effective when the
requirements change, unit tests need to be fairly isolated, so that
one requirements change usually don't affect more than a few tests.

For each change in requirements, most existing requirements hold,
and hopefully, the vast majority of tests would still run correctly.
With a large set of automated unit tests, you can confidently change
your code to fulfill the new requirements without breaking any
existing functionality without noticing.

> As for changing argument types: But this is exactly the sort of
> situation where I find myself getting into trouble in Python. I have to
> change some type and I forget everywhere I've passed it or returned it.

Strange. I very rarely have trouble with this. What happens when you
run your tests? Surely things break in the cases where the type change
cause trouble, and you get tracebacks that tell you exactly what and
where you need to change things. The only difference compared to the
compiler, is that it won't force you to change things in places where
things still work as intended even though a type was changed.

Or...don't you have automated tests? Ouch. If you (like me) feel a
little lazy to write a lot of test scripts, you can use a test tool
such as TextTest, that compares output between test runs, rather than
forcing you to write lots of scripts with plenty of assertions. The
effort required to get started is probably bigger there though. (I
don't really know, it was all set up for me at work.)

> In C++ if I make changes the compiler is going to keep complaining and
> pointing out type clashes I've introduced due to changing a variable's
> type. Granted, it is a pain to change type declarations. But visiting
> those places often makes me think thru the ramifications of changes.

It's also a pain to write unit tests, but it's much more rewarding
than writing type declarations. Not only does it force you to think
through the ramifications of changes, but you also document your
intentions through your tests.