[Tutor] Const on Python

[Andreas Kostyrka]

Yes, the problem is, that these guys are anyway forced to have
Python/Erlang developers on board, because of external opensource
components they need to maintain.

Am Donnerstag, den 06.03.2008, 23:54 +0000 schrieb Alan Gauld:
> Actually I'm with the lead here.
> 
> The cost of developing a new feature is a tiny proportion of total
> life cost of code - often only 5-10%. If Erlang is already being
> used that might make some sense, but of the developers all know
> Java/C++ then one of those makers more sense. If every
> modification needs to wait for a Python/Erlang developer to
> come free that would push the lifetime costs up dramatically.
> 
> Its not a matter of politics but of business and TCO.
> 
> I routinely build prototypes in Python, a few of which have been
> "good enough" for the users, but nonetheless we have had
> them rewritten in Java because thats what we use in house.
> Nobody upgrades the Python version on the servers, only a
> handfull of developers know Python. So it makes commecial
> sense to rewrite the app in Java where anyone can fix/modify
> it than have an app in Python than only a select few can
> work on and costs a fortune in upgrades over the 10 years
> or more the app may exist for.

The problem here is that C++ is a strong mismatch for the job at hand.

With strong mismatch I mean hear at least a magnitude more costs. During
initial development and during maintenance.

Combined with the fact that the group cannot avoid learning Python and
Erlang, because external OSS projects used by them that they need to
maintain and customize are written in Python & Erlang.

So there is no point in avoiding using languages that they are forced to
support anyway. (Even if they should decide to redo the OSS components
from scratch and even if they decide to do it in the official languages
that are not really a good match to the problem domain, they still need
to support the current component for at least a year till such
replacement could be developed. So they need to do Python and Erlang.)

But basically, your argument misses one important aspect:

While most languages are equivalent in a theoretical sense (Turing
complete), not all languages are created equal. Some languages can and
do provide at least a magnitude of improvement compared to other
languages.

Now add to the fact that software developement does not scale linearly,
and the developer efficiency point becomes even more important.

If, by using some higher language a problem becomes so "easy" to solve
that a single developer can deal with it, instead of say a 4 man team,
than this is a critical aspect.

It's kind like having a policy that all invoices must be in USD and are
payed only in USD. Now two companies bid. Both companies offerings are
more than good enough to meet your demands. Company A asks for USD
100000, and Company B asks for EUR10000. Both a track record of
delivering, and both are good enough. In theory, product A might have
some benefits, but that's not sure, for the moment it's mostly a
theorized minor improvement over product B.

To paraphrase now your argument, it makes sense to buy product A, it's
not just buying the product, you know, it's also all the other stuff
like accounting, exchange rates, and so on.

(Philosophically, that's not even that bad a comparison, as learning
Python is a rather minor thing for a reasonable good developer.
Unlearning bad design habits takes some time, but Python programs do run
even if you add some kilobytes of superflous get_ and set_ to the source
code :-P)

So no, I do not concur with you. I understand why it has some value, but
you wouldn't argue that your company should use passenger cars to
transport 100 tons of goods, just because all employee have a license to
drive such, while truck drivers are slightly harder to come by, would
you?

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.python.org/pipermail/tutor/attachments/20080307/64e835f9/attachment-0001.pgp