Re: Adventures in Quest for GUI RAD

Alex Turner wrote:

> No.1 Python does not scale well.
> map<int,char*> x=new map<int,char*>();

Whatever that may mean. Reminds me why I deliberately forgot all of C
right after the final test of that class at university.

> vs
> self.d={};

Beep.

Go back to my initial article and read what I wrote. And try to
understand the word "to scale" in its context _there_.

> Python is 10x slower than C++ or Java.

Thanks for this "extremely differentiated" statement, as it makes clear
there is no point to discuss subjects like this with you any further.

Then for example the Ironport mailservers must really be aFata morgana,
or are there many mailservers out there that can handle 1 Mio messages
per hour on a moderately equipped desktop computer im plemented in
"Java" or C++...?

> If you do any kind of OO
> programming, python is very slow.

Well, if Python's too slow for you, then C or C++ are as well.

Because one can get compiled C speed simply by doing an "import pyrex",
adding some static declarations and feeding the Python code through
distutils - without having to touch C even with rubber gloves.

And don't get me into talking about "Java" applications - I've seen
quite a few of them, tried to use them for actual work and they all
failed miserably. There wasn't one among them which had a
"responsiveness" which actually deserved to be named as such and they
all leaked memory in such ridiculous amounts that after at most 30
minutes of usage the only way to get the computer out of its totally
frozen state was to physically pull the power plug. And this, no matter
how much physical RAM was installed.

> No. 2. Python does not inteface with everything by a long shot
> Case in point - no good native MS SQL Server Driver.

Well, if there's one in C or C++, there's also one in Python. And you
don't have to touch C(++) syntax even with rubber gloves to use it from
within Python.

The fact that no Python developer has met the requirement to wrap it in
a static DB-API-compliant module so far, just says a lot about the
usefulness of MS SQL Server for Python developers. Most of which are
people who tend to choose very carefully the tools they use.

And for those who don't mind paying a ridiculous amount of money for a
db server that does less than what Postgres does for free, there's
always mxodbc.

>  No good PDF reading libraries.

Statement above applies. Plus any kind of COM component or scriptable
****x application, as they're all usable from within Python.

Anyway, I seriously doubt that, as I know of at least one excellent
"native Python" DB->PDF _creation_ module.

> I love python alot, heck I wrote a whole web platform in it, but I'm
> under no illusions that it's much heavier that C++/Java or PHP.

None of those will be an option for the original poster, as he has
explicitly mentioned.

And none of those is able to "scale" across an application range as
wide as the one that Python does - by far.

> No offence of anything, but I've seen what non-professional
> programmers do in any language they get their hands on (Python, Java,
> Access/VBA), and for the most part, they should stick to their day
> job, and leave application development to people with good CS degrees
> who understand what they are doing (not that all CS graduates know
> what they are doing, they just have a better shot).

Sure.

According to you basically all of the applications that I know of as
being the "best of their breed" from personal experience through using
them on a daily basis to earn my living simply wouldn't exist - as they
have all been implemented by people who don't have a CS degree.

And I'm not talking about trendy webcrap, but things which are used
daily by _lots_ of people to get _actual work_ done.

Things like Framemaker, Catia, Simpack etc...

And, btw: http://learn.to/quote

End of flameware, subthread filtered.

Sincerely

Wolfgang Keller