Some additions then:

Advantages of C++ over Ruby/Python
==================================

1. Variables are declared.
In Python, if a function begins with "a = 1", you don't know if this
modifies the value of an existing variable, or creates a new one.

2. Functions have signatures.
The declaration of each function tells you what kind of arguments it
takes and what kind of value it returns. In Ruby/Python, you either
need to read through the function definition to find this out, or rely
on comments, which may be missing or out of date.

3. Classes have interfaces.
The public interface of each class is grouped together in one place,
easy to find and read. In Ruby/Python, you need to read through the
whole class definition to find this out.

4. Compile-time error checking.
Many programming errors are caught by the compiler. In Ruby/Python,
syntax checking is much weaker, and you only find these errors when you
run that particular line of code. Result: buggier code, more crashes
for the user.

But most importantly:

5. We already have it.
MDLF spent a lot of money for the existing code. MDLF spent a lot of
money on me gaining expertise in C++ and Gtk+. You are proposing to
throw all this away, and start from scratch. It will take at least 2
months each to convert Studio and the Scheduler (probably more). During
this time, no new features will be implemented. Who is going to pay for
this? For at least another year, we will struggle to build up all the
development environment features (documentation generation, unit testing
framework, deb package building scripts etc) that you are about to throw
away.

You are saying this investment is worth it, because we will save so much
time later. Let me explain why I am skeptical. I spend about 40% of my
time planning (what objects to use, in which modules to put them, what
the interface will be, how the responsibilities are divided between
objects); 20% writing the code; and 40% debugging it. The planning
stage is language-independent; I don't see how any savings could be made
there. Debugging will become _more_ time-consuming, not less. That
leaves a 10% time savings, very optimistically. You have never properly
explained where your claim of a 67% to 80% savings ("maybe more") comes
from.

Comments about your points:

Paul Baranowski wrote on 03/01/2007 04:24 PM:
> Advantages of Python/Ruby over C++
> ==================================
> * Automatic memory management
Same in C++, with smart pointers. We never use delete in our existing code.
Rejected.

> * Automatic array bounds checking/missing array elements
Same in C++, using the standard library container types.
Rejected.

> * Automatically cross-platform
Not quite true; if you call outside functions like tar and curl, rely on
the location of the user's home directory, etc, Ruby/Python code can be
Linux-only, too. But yes, it is easier to write portable code.
Accepted with qualifications.

> * Huge standard libraries
Wow. You must be kidding. In C++, you can use any C library in
existence; that means most of the code ever written on this planet! No
standard library can touch that. Besides, I'm not sure even Glib or Qt
alone is smaller than the Python standard library.
Rejected; the opposite is true, by a wide margin.

> * Much less code to write the same thing because these languages have
> a more powerful syntax. Less code means less maintenance which mean
> less
> time.
Yes, it will save some time, see above. However, the main maintenance
problem we have is that the code is in 2 different languages. This
would not solve that; in fact, at least temporarily, and possibly
permanently, the project would be in 3 languages!
Accepted, as a source of at most a 10% savings.

> * Everything is an object, even the built-in types
That's nice, but not very relevant.
Rejected.

> * Built-in lists/arrays and hashes/dictionaries
Same in the C++ standard library.
Rejected.

> * No compiling
Accepted, but not significant. Buy a computer made in this century, please.

> * No makefiles
We do need some replacement for the automake system you are about to
junk, to automate various tasks (see above). These new makefile-like
scripts may be simpler than the C++ makefiles; but we need to learn how
to write them, how to use them, and write them from scratch.
Rejected as written;
Accepted with qualifications if changed to "simpler makefiles".

> * No header files
This is a disadvantage; see points 1, 2 and 3 above.
Rejected.

> * Introspection
> * Metaprogramming - for example, you can dynamically change the
> methods of a class at run time. An example of this is creating
> a wrapper for another object automatically at runtime.
Maybe nice, surely very dangerous, not relevant.
Rejected.

> * Lower barrier to entry: its easier for others to help the project
> because
> Python and Ruby are easier to learn.
My experience is that it takes a week to learn a language, and a year to
become reasonably good at programming in it. Any language. Of course,
this is a subjective thing, you may be right about some other people.
Accepted, as a subjective impression.

> There is also no build system
> to learn.
There ought to be; if you meant to say "simpler build system", then OK.
See the "no makefiles" point above.

> * Better debuggability: there is a stack trace and line number every
> time you
> crash, and even end users can send you this information.
Not clearly an advantage. I don't want users to send me a stack trace;
I want them to tell me how to reproduce the bug. Besides, if they are
running the app from the menu, they don't get the crash message. Might
be useful in some rare cases, though.
Accepted as a small advantage.

> All of this means that developing in Ruby or Python is somewhere around
> 3x-5x faster (maybe more) than developing in C++. This means that in
> one year with Ruby or Python what would take 3-5 years in C++. This
> gives us a huge competitive advantage. Or, looked at another way, if a
> competitor decides to go with one of these languages, we will be left in
> the dust.
See above.

Ferenc

First, please note that my arguments apply for only application programming. If
you are writing an OS or system library, C/C++ are good languages to use.

Ferenc Gerlits wrote:
> Advantages of C++ over Ruby/Python
> ==================================
> 1. Variables are declared.
> In Python, if a function begins with "a = 1", you don't know if this
> modifies the value of an existing variable, or creates a new one.

For application level programming, this is actually a disadvantage of C/C++.
PHP is an interpreted language without variable declarations, it is used for all
of Campsite and as you know, lots of modules in Campcaster. Somehow it survives
with pretty much the same bug count as the C++ code. Now imagine the same code
written in C++ (e.g. write the HTML UI in C++), how much more code it would take
and how much longer it would have been to build? The reason that variable type
declarations dont matter so much is that most of the time the scope of variables
are limited. Much of the time you are using variables and then just throwing
them away. The times that I have run into problems with typeless variables is
when they were poorly named, such as "x" or "t".


> 2. Functions have signatures.
> The declaration of each function tells you what kind of arguments it
> takes and what kind of value it returns. In Ruby/Python, you either
> need to read through the function definition to find this out, or rely
> on comments, which may be missing or out of date.

Function do have signatures in Python/Ruby/PHP. If they didnt, it would very
hard to call functions if you didnt know what the parameters were. There is
automatic documentation generation for these languages as well, and just because
function parameters arent typed doesnt mean you dont document them and use good
variable names. Its also nice to be able to say that "parameter 1 can be a
string or an integer". A very simple example of why you wouldnt care about the
type is when you are printing something out: you dont care whether they have
given you the integer 5 or the string "5" when you say "you have PARAMETER1
points".

Most of the time functions in scripting languages are no different than C/C++:
functions take certain arguments of certain types. The types are documented,
just as they are in C++. For the cases where types really matter (surprisingly
rare), you can put in checks to make sure variables are a certain type.


> 3. Classes have interfaces.
> The public interface of each class is grouped together in one place,
> easy to find and read. In Ruby/Python, you need to read through the
> whole class definition to find this out.

There are also interfaces in Python/Ruby/PHP. If they didnt have these, it
would be really hard to use classes. I dont know of any languages besides C/C++
that require header files, and for good reason: its a bad idea to have mandatory
duplication of your work. If you want to know the interface of a class, why not
look at the generated documentation or use an IDE that will show you the
interface to a class? There are multiple ways IDE's can show this, one of which
is "code folding" which basically makes the file look like a header file (it
hides the content of the functions which you can expand using little "+" signs
next to the function signature).


> 4. Compile-time error checking.
> Many programming errors are caught by the compiler. In Ruby/Python,
> syntax checking is much weaker, and you only find these errors when you
> run that particular line of code. Result: buggier code, more crashes
> for the user.

Once you start using these languages you will find that this isnt true. PHP
does not have compile-time error checking and yet these kinds of bugs almost
never show up in our PHP code. C/C++ is not immune to these types of bugs
either, as any function that takes a variable number of arguments will have this
same problem. Basically compile-time checking is just one form of testing, and
it is a test you dont need 99% of the time. So you end up wasting all that time
writing these mandatory compile-time tests for your code. I encourage you to
take up Python and/or Ruby and find this out for yourself.


> But most importantly:
>
> 5. We already have it.
> MDLF spent a lot of money for the existing code. MDLF spent a lot of
> money on me gaining expertise in C++ and Gtk+. You are proposing to
> throw all this away, and start from scratch. It will take at least 2
> months each to convert Studio and the Scheduler (probably more). During
> this time, no new features will be implemented. Who is going to pay for
> this? For at least another year, we will struggle to build up all the
> development environment features (documentation generation, unit testing
> framework, deb package building scripts etc) that you are about to throw
> away.

You will find that it will take you about 1 week at most to learn python or ruby
(PHP takes longer actually). Getting more proficient in them wont take long
either, as any libraries you now know will have the same API as they did before.
All of our previous code is not thrown away as we would base the new code on
the old code. So we arent starting from scratch, and we arent re-architecting
anything.

Regardless, we dont really have a choice whether we want to go this route or
not. If we dont, we will never get the features we need with our limited staff.
If we dont, someone else will come along, build a similar product using one of
these languages, completely pass us by and make us obsolete. On top of that,
these languages make programming fun again! It is a real joy to use them.


> You are saying this investment is worth it, because we will save so much
> time later. Let me explain why I am skeptical. I spend about 40% of my
> time planning (what objects to use, in which modules to put them, what
> the interface will be, how the responsibilities are divided between
> objects); 20% writing the code; and 40% debugging it. The planning
> stage is language-independent; I don't see how any savings could be made
> there. Debugging will become _more_ time-consuming, not less. That
> leaves a 10% time savings, very optimistically. You have never properly
> explained where your claim of a 67% to 80% savings ("maybe more") comes
> from.

I understand your skepticism, I felt it even more so than you before I tried out
Python. It took me a while to break down and finally give it a try, and when I
did, I was so sad about how much time I had wasted with C++ because someone had
told me about Python a few years before and I didnt try it then. C++ is great
for writing OS's and libraries, but very poor for writing applications. As one
conference speaker I saw put it, "C++ is a great high-level assembly language."


>> * Automatic memory management
> Same in C++, with smart pointers. We never use delete in our existing code.
> Rejected.

Wouldnt it be so much nicer if you didnt have to use smart pointers and your
variables Just Worked(tm)?


>> * Automatic array bounds checking/missing array elements
> Same in C++, using the standard library container types.
> Rejected.

Which standard library do you refer to? Are you referring to the STL?


>> * Automatically cross-platform
> Not quite true; if you call outside functions like tar and curl, rely on
> the location of the user's home directory, etc, Ruby/Python code can be
> Linux-only, too. But yes, it is easier to write portable code.
> Accepted with qualifications.

Tar and curl have libraries built into these languages, so there is no outside
library to call. Users home directory will be given to you with a system call.
The main non-cross-platform item for us would be how to specify the audio
devices.


>> * Huge standard libraries
> Wow. You must be kidding. In C++, you can use any C library in
> existence; that means most of the code ever written on this planet! No
> standard library can touch that. Besides, I'm not sure even Glib or Qt
> alone is smaller than the Python standard library.
> Rejected; the opposite is true, by a wide margin.

You may be able to use any library in existence, but do they work together? Do
they compile on your system? Certainly the answer is "no" to the first. As far
as compiling on your system...the answer would be "most of the time", but its
not a rare occurrence when one doesnt as we have seen with PowerPC and even
different flavors of Linux.


>> * Much less code to write the same thing because these languages have
>> a more powerful syntax. Less code means less maintenance which mean
>> less
>> time.
> Yes, it will save some time, see above. However, the main maintenance
> problem we have is that the code is in 2 different languages. This
> would not solve that; in fact, at least temporarily, and possibly
> permanently, the project would be in 3 languages!
> Accepted, as a source of at most a 10% savings.

In practice, the time saved is much larger than your estimate. How can you make
a guess like that without any experience with it?


>> * Everything is an object, even the built-in types
> That's nice, but not very relevant.
> Rejected.

This is very important. It allows you to figure out the type of something at
runtime. Java also has this property. It makes for much more powerful object
oriented systems, and even better design patterns. Once you use these languages
you will see that C++ actually isnt very object-oriented.


>> * Built-in lists/arrays and hashes/dictionaries
> Same in the C++ standard library.
> Rejected.

I never heard of a C++ array that lets you store any kind of object at any
location using both numerical and string indexes at the same time. It could be
partly done with a bunch of void* pointers but you still wouldnt know what kind
of values you are pulling out of the array once you got them. Are you able to
index an array based on anything? No. Simply put: there are arrays and hashes
in C++, but they are inflexible and have drastically reduced functionality
compared to Python/Ruby.


>> * No compiling
> Accepted, but not significant. Buy a computer made in this century, please.

Please remember that we arent talking about single programmers, but a team of
them. I have seen all of us waste many hours on this task. Not only compiling,
but the infrastructure around compiling things. Makefiles, documentation,
support in IRC and on the mailing list...this is significant. And my experience
developing in both languages shows me clearly that compiling time is not
insignificant. Instead of Write -> Compile -> Run, you only have Write -> Run.


>> * No makefiles
> We do need some replacement for the automake system you are about to
> junk, to automate various tasks (see above). These new makefile-like
> scripts may be simpler than the C++ makefiles; but we need to learn how
> to write them, how to use them, and write them from scratch.
> Rejected as written;
> Accepted with qualifications if changed to "simpler makefiles".

Since they are interpreted languages, you dont need makefiles. Maybe you are
referring to installation scripts?


>> * No header files
> This is a disadvantage; see points 1, 2 and 3 above.
> Rejected.

More code is a disadvantage. This is also the same in Java, where there are no
header files, and for good reason: having to replicate code in two places is a
bad idea.


>> * Introspection
>> * Metaprogramming - for example, you can dynamically change the
>> methods of a class at run time. An example of this is creating
>> a wrapper for another object automatically at runtime.
> Maybe nice, surely very dangerous, not relevant.
> Rejected.

It's not dangerous at all, its just scary coming from the C++ world that you can
do this sort of thing. It's very relevant because you can do very powerful
things that are simply impossible in C++. For example, say you wanted to add a
layer of security to a class so that you check some authentication before a
method is accessed. Proxying an entire class is a few lines of code in Python.
In C++, you would have to override the class and write a wrapper function for
every function. Imagine doing this for those classes that have hundreds of
functions. First: why is this dangerous? Second: why is it not relevant? More
powerful programming concepts like this allow for less code, less time spent
developing, and much easier maintainability (from the example above, a handful
of dynamic lines compared to hundreds of static and inflexible lines of code).
There are many other powerful programming techniques such as this in Python as
well, this isnt the only one.


>> * Lower barrier to entry: its easier for others to help the project
>> because
>> Python and Ruby are easier to learn.
> My experience is that it takes a week to learn a language, and a year to
> become reasonably good at programming in it. Any language. Of course,
> this is a subjective thing, you may be right about some other people.
> Accepted, as a subjective impression.

Would you rather try to teach a child C++ or Python/Ruby? It takes years to
truly understand how to use C++ properly, never mind there are so many styles
and ways to do the same thing. And the STL is impossible for a newbie to
comprehend.


>> There is also no build system
>> to learn.
> There ought to be; if you meant to say "simpler build system", then OK.
> See the "no makefiles" point above.

Why should we have more work?


>> * Better debuggability: there is a stack trace and line number every
>> time you
>> crash, and even end users can send you this information.
> Not clearly an advantage. I don't want users to send me a stack trace;
> I want them to tell me how to reproduce the bug. Besides, if they are
> running the app from the menu, they don't get the crash message. Might
> be useful in some rare cases, though.
> Accepted as a small advantage.

You can easily make this automatic so that we(the developers) are automatically
sent crash messages. This is actually what Campsite does; every time a crash
happens it is submitted to Trac directly. We even have a little box that comes
up when this happens asking the user to type in what they were trying to do when
the crash occurred. We've managed to fix many bugs because of this, many of
which were cases where the user did not type in any info about what they were
doing. Most of the time the stack trace is enough to know what happened.
Getting automated bug reports means we know about every bug that anyone has ever
encountered, we know how often they happen, we know about them sooner, and the
user has minimal work to report them to us - just click a button.


In general, if you take the above points one by one, it may not seem to add up.
However, when all of the effects combine together, they add up to more than
the sum of the parts. I cannot give you the experience of using these
languages, you will have to try them yourself. However, please note that Mugur
and I (and I believe Mark as well) have started out using C++, thinking it was
The One True Programming Language, and then tried out Python/Ruby and we have
found that there /is/ a significant difference. I have yet to hear about anyone
who has actually started to use these languages and then argue against using
them (it is usually the other way around).

- Paul

Hi Paul,

I don't think I can change your mind; I failed at that in much more
clear-cut cases. But I do believe you are about to do great harm to the
project, and I want my conscience to be clear: I tried to prevent it.

(Parentethical remark: this discussion may be completely moot, as the
project may be dead already -- do we have funding for March? Are there
any good prospects for funding?)

A few comments, though, because I find it hard to let go, too.

Paul Baranowski wrote on 03/02/2007 02:16 PM:
> throwing them away. The times that I have run into problems with
> typeless variables is when they were poorly named, such as "x" or "t".

Let me translate: you can compensate for the lack of enforced scope and
type declaration in the language by using comments (which variable names
really are). True -- but comments can be missing (as you note above)
and can become out of date.

> Its also nice to be able to
> say that "parameter 1 can be a string or an integer".

Does some automatic documentation tool extract this information directly
from the code? If yes, I'm really happy about it, and it invalidates
some of my argument. But if it depends on hand-written comments, it
suffers from the same problems I just mentioned.

> the interface of a class, why not look at the generated documentation or

This argument would be more convincing if one of your first acts on the
Campcaster team had not been to remove the doxygen documentation for the
PHP modules. You still have not replaced it with anything else; the PHP
modules have no generated documentation at the moment.

>>> * Built-in lists/arrays and hashes/dictionaries
>> Same in the C++ standard library.
>> Rejected.
>
> I never heard of a C++ array that lets you store any kind of object at
> any location using both numerical and string indexes at the same time.

Let's just stop here for a second. There are two major things wrong
with this. First, your debating style. I paraphrase:
P: Python and Ruby have built-in lists/arrays and hashes/dictionaries;
C++ does not.
F: Not true: the STL has bound-checked arrays, lists and hashes, too.
P: You are wrong, because there is no STL data type that can be
accessed using both numerical and string indexes at the same time.

This is not a fair argument. You can say "You are wrong: STL does not
have these data types." or you can say "You are wrong: the STL is not
part of C++." or you can say "Okay, I was wrong. However, what
about..." You can't change your original statement.

Second, what is a data type which is both an array (indexed by numbers)
and a hash (indexed by keys)? An array is laid out in memory linearly,
so its nth value can be found quickly. A hash is some kind of a linked
search tree, where you can find the first element with (key >= "abc")
quickly, but finding the nth element is slow. Of course, I can write
code to access an array object by a key, or a hash object by an index,
but this should be done in very rare cases only. If a language
encourages this sort of bad coding, that is a big minus, not a plus.
Does Python?

> Since they are interpreted languages, you dont need makefiles. Maybe
> you are referring to installation scripts?

Installation scripts, documentation generating scripts, unit test
running scripts, dependency checking scripts. (You do want our code to
check that the required Ruby/Python version and add-on modules are
present, right? It's not just going to crash if they aren't?) If we
switch to Qt, there are lots of intermediate files generated by qmake;
these should be handled by some sort of makefile, too. We can call it
something else, like "project file", or "script file", if you prefer.

> please note that Mugur and I (and I believe Mark as well) have started
> out using C++, thinking it was The One True Programming Language, and

I really don't. My order of preference right now (based on just having
read one tutorial in the case of Ruby and Python, it's true) is Ruby >
Java > C++ > Python > BASIC. If we were starting out with the project
now, many of your arguments would make sense. But we have a large
amount of code already, and rewriting it will take a lot of time, which
does not seem like time well spent to me.

Ferenc

Hi everybody,

I always knew this would be a hit topic. Almost as good as the renaming
debate/flames. Thanks everybody for chipping in (that means, you too Akos,
please feel free to contribute -- it is an open project).

I'll try to summarize the debate so far from a layman's point of view
(please correct me if I am wrong, but in equally simplistic terms):
1. Everybody seems to agree that *IF* time and money were not an issue,
migration to a VHLL (very high level language) would be a good idea.
2. Everybody seems to like Ruby well enough (see Ferenc's list of prefs).
Ruby is apparently beautiful, a joy to program in, etc.(Even Akos doesn't
hate it.)
3. Ferenc hates Python. Markey doesn't mind Python, but prefers Ruby. Mugur
likes Python. Paul loves Python.
4. Ruby thus seems as the VHLL that everybody could see themselves
programming in.
5. Ruby is, however, not yet as mature and fast as Python.
6. If we were to move to a VHLL, the mid-run optimum would be Python (fast,
mature right now), the longer-run optimum would be Ruby (pretty, will get
faster).

Am I correct in my interpretation?

Sava










Ferenc Gerlits
To: "The Campcaster Developers' Mailing List"
Sent by:
campcaster-dev-bounces@netfinity cc:
-4.mdlf.org Subject: Re: [campcaster-dev] Very high level languages


03/02/07 04:26 PM
Please respond to "The
Campcaster Developers' Mailing
List"






Hi Paul,

I don't think I can change your mind; I failed at that in much more
clear-cut cases. But I do believe you are about to do great harm to the
project, and I want my conscience to be clear: I tried to prevent it.

(Parentethical remark: this discussion may be completely moot, as the
project may be dead already -- do we have funding for March? Are there
any good prospects for funding?)

A few comments, though, because I find it hard to let go, too.

Paul Baranowski wrote on 03/02/2007 02:16 PM:
> throwing them away. The times that I have run into problems with
> typeless variables is when they were poorly named, such as "x" or "t".

Let me translate: you can compensate for the lack of enforced scope and
type declaration in the language by using comments (which variable names
really are). True -- but comments can be missing (as you note above)
and can become out of date.

> Its also nice to be able to
> say that "parameter 1 can be a string or an integer".

Does some automatic documentation tool extract this information directly
from the code? If yes, I'm really happy about it, and it invalidates
some of my argument. But if it depends on hand-written comments, it
suffers from the same problems I just mentioned.

> the interface of a class, why not look at the generated documentation or

This argument would be more convincing if one of your first acts on the
Campcaster team had not been to remove the doxygen documentation for the
PHP modules. You still have not replaced it with anything else; the PHP
modules have no generated documentation at the moment.

>>> * Built-in lists/arrays and hashes/dictionaries
>> Same in the C++ standard library.
>> Rejected.
>
> I never heard of a C++ array that lets you store any kind of object at
> any location using both numerical and string indexes at the same time.

Let's just stop here for a second. There are two major things wrong
with this. First, your debating style. I paraphrase:
P: Python and Ruby have built-in lists/arrays and hashes/dictionaries;
C++ does not.
F: Not true: the STL has bound-checked arrays, lists and hashes, too.
P: You are wrong, because there is no STL data type that can be
accessed using both numerical and string indexes at the same time.

This is not a fair argument. You can say "You are wrong: STL does not
have these data types." or you can say "You are wrong: the STL is not
part of C++." or you can say "Okay, I was wrong. However, what
about..." You can't change your original statement.

Second, what is a data type which is both an array (indexed by numbers)
and a hash (indexed by keys)? An array is laid out in memory linearly,
so its nth value can be found quickly. A hash is some kind of a linked
search tree, where you can find the first element with (key >= "abc")
quickly, but finding the nth element is slow. Of course, I can write
code to access an array object by a key, or a hash object by an index,
but this should be done in very rare cases only. If a language
encourages this sort of bad coding, that is a big minus, not a plus.
Does Python?

> Since they are interpreted languages, you dont need makefiles. Maybe
> you are referring to installation scripts?

Installation scripts, documentation generating scripts, unit test
running scripts, dependency checking scripts. (You do want our code to
check that the required Ruby/Python version and add-on modules are
present, right? It's not just going to crash if they aren't?) If we
switch to Qt, there are lots of intermediate files generated by qmake;
these should be handled by some sort of makefile, too. We can call it
something else, like "project file", or "script file", if you prefer.

> please note that Mugur and I (and I believe Mark as well) have started
> out using C++, thinking it was The One True Programming Language, and

I really don't. My order of preference right now (based on just having
read one tutorial in the case of Ruby and Python, it's true) is Ruby >
Java > C++ > Python > BASIC. If we were starting out with the project
now, many of your arguments would make sense. But we have a large
amount of code already, and rewriting it will take a lot of time, which
does not seem like time well spent to me.

Ferenc





Invest in Press Freedom: Visit http://www.mdlf.org/support-free-press

> PS: Paul & Ferenc.... do u need a referee?? (this is a real bad joke)

Yes, it looks like we do, and Sava did a good job at refereeing.

I don't hate Python, but I'd much prefer to program in some other
language; its syntax seems to me as a step back from C++, more like
GObject, a C library for OO programming.

About switching: many of the claims are clearly exaggerated (10x faster
development?) or false (features listed by Paul as advantages of Python
which are also present in C++ [1]). Some of the other arguments are
better, but the main one is still "this can't be explained, you will
just see". That doesn't mean switching can not be right [2], but it's
not being sold very well.

Ferenc


[1] For example, I just read up on hashes: C++'s std::map is
automatically sorted by key, Python's dict and Ruby's Hash is in random
order. So if you really want to access the 5th element in a hash for
some strange reason, you are better off with C++.

[2] Analog: if I decide I don't want to believe that stars are the same
kind of objects as the Sun, you won't be able to convince me, for lack
of equipment and specialized knowledge; that doesn't mean they aren't.

My philosophy in building applications is "short release cycles" and "use the
right language for the job". The right language for the job might be:

Desktop app: Python
Web apps: PHP/Python/Ruby
AI: LISP/Prolog
OS: C/C++
Libraries: C/C++
Game engine: C/C++
Drivers: C/Assembler
(and i wish there was an alternative to javascript...)

So I am not in the camp that "Python/Ruby are the ultimate languages". They
are, however, the right languages for our product space.