Suitability of Python for a Big Application?

[Bruce Dodson]

Python is a good tool for this type of situation.  It allows you to
compartmentalize your functionality and do collaborative development.  But
it is not a magic bullet.  If your development process is flawed, Python
will not solve any of your woes, much less all of them.  Take a close look
at the VB attempt, and evaluate whether that failed because of VB, or
whether VB is just the scapegoat.  Sometimes this is a difficult thing to
do, but you must do it; if you don't, a year from now I could very well find
a message in the Perl newsgroup saying "we tried VB and Python with
miserable results."

I suggest delaying the decision of language(s) until after the requirements
phase.  And I suggest in the requirements phase, you think about what is
really important.  For example, does the front end really need to be
cross-platform, or is it all (~99%) Win32.  Also think about, of the things
that will need to be in the final system, which need to be in the final
system.

If you go with a mixed-language system, it is important that there be a
"master language" which drives things, and that you implement things in that
language unless there is a strong justification to use something else.
Otherwise you get the "code smear" effect where no one knows where exactly a
given piece of functionality is implemented, or worse, it _isn't_
implemented in any one place but is an emergent property of the system.
This kind of thing happens all the time with Intranet development, because
there are so many languages and protocols involved.

That is my sermon for today,
Bruce


bobyu5 at mailcity.com wrote in message <830vic$r2t$1 at nnrp1.deja.com>...
>I have a project to build a multi-user database intensive application.
>The 1st phase of the project will be the proof of concept to hammer out
>all the technology requirements as well as the user requirements.
>
>This application should be built using traditional programming languages
>such as C++ or Java, but development time is limited to 1 year maximum
>and frankly the time is not sufficient for anything but a quick
>prototyping language.
>>
>And the most important of all, it has already been tried to be built
>using VB 5.0 with a miserable result. (2 years of effort has still not
>produced a usable application) All the issues that I have mentionned
>above are more or less critical.
>