> maybe Python XML support is that good …

actually, yes it is. ElementTree is a very nice simple, “pythonic” xml library for most of what normal folks need to do on an everyday basis. In its cElementTree version it’s well fast, and it’s part of the standard libraries from python 2.5 onwards. If you need to get more down’n'dirty there are perfectly decent libxml2 bindings available.

I know you were really making up a hypothetical example and random, and whether python actually happens to be good at that particular thing wasn’t the point you were making – but python does in fact happen to be good at that particular thing

So, it is matter of personal choice. Personally, I would recommend Python for a number of reasons. Keeping in mind that I have actively written Python code since at least 1993 or so, this list is not entirely without bias. However, I have learned Ruby and do occasionally write Ruby code. So far, I haven’t found anything about Ruby that is compelling enough for me to choose Ruby over Python when given a choice. Without history, it really would be a toss up for all but a handful of reasons.

- Python is easier to learn. The whole point of the language was simplistic readability. Python is often used as a teaching language for non comp-sci folks because of this. And there are some awesome tutorials out there — http://diveintopython.org/. On the flip side, Ruby often makes comp-sci types jiggle with glee. Blocks! Whee! (Seriously — Ruby seems to be a more “serious” language… and, yes, I’m mocking it for being more “serious” because, frankly, I find all the damned punctuation and side effects to be just plain bloody annoying).

- Python has Twisted. If you are ever going to do network app development or do any kind of network communications stuff, nothing beats Twisted. A bit of an iniital learning curve, but just flat out amazing after that.

- While RubyCocoa has evolved significantly in the last year, PyObjC is more mature and provides better support for distributing production applications at this time. RubyCocoa is making great strides in this area and I suspect it will catch up sometime in the near future. Mostly. Ruby 1.x has an unfortunate threading model that causes hell, but it isn’t a total showstopper and it will be fixed in 2.0.

- if you want to write a web app, Ruby On Rails is the crack of web programming. Very very easy to get a site up and running and you can do some impressive stuff with it. But RoR isn’t really designed to produce large scale modular or maintainable sites.

For really small, tight, fast code written against what is typically a C layer on the system, C is still the tool of choice.

But, yes, certainly, C++ can be very very fast, too. Much faster than Objective-C, certainly, but at a significant potential cost simply from the sheer volume of code that might have to be written to get the same thing done, depending on architecture.

Do you really think so? I’m wondering why anyone would do that. Theoretically, C++ should always be faster than C. Bjarne Stroustrup originally said that he wrote “C with classes” to eek more performance out of a C compiler by using inline functions and effectively making it easier (and faster) to write more efficient code.

Ken

I have yet to find an app with a user interface where being able to open the NIBs or reverse engineer the bindings reveals anything that could be considered Super Top Secret Intellectual Property By Which Your Competitors Could Eat Your Lunch.

Having the source code for some subset of the app, or even the whole app, really isn’t that much different beyond giving pirates the ability to kill off your licensing code (which could be left in compiled code and be as secure as it is today).

Sure, someone could reskin your business logic and try to sell your work, but I’d be surprised if they weren’t busted in seconds in this modern Internet police state.