Comment
Above in this comment thread:
Is Chandler's Demise Evidence that Dynamic Languages Can't Scale? » I'm not sure that Python was the problem ...
visitors
reading
This site conforms to the following standards:
Thanks for the long informative response. The IETF draft looks to be some interesting reading.
That is precisely my point, a Python based organization may consist of personnel with expectations that their language can do more than what's possible. After all, Python has never been mainstream and possibly it's ardent supporters have developed unreasonable expectations as to what it's truly capable of.
Just take a look at Erlang. Their proponents have been preaching that it's the next best thing since slice bread. However, when you really take a look a it, you realize how antiquated it truly is.
This is my exact problem with all the hoopla about the new languages (i.e. Ruby, Groovy, Scala etc.) . Certainly, a lot of language constructs makes the individual developer more productive however can it substitute for the comprehensive component models that were developed to address large scale development (i.e. Eclipse Plugins, OSGI)? Annotations and Aspects are two examples of language constructs that aid in this. IOC is a consequence of dynamic loading and introspection.
Do the languages introduce new features that scale develoment? Or are they just interesting language constructs like Generics that for what is worth adds more code with little gain.
Carlos
- Paddy3118.
But hold on! Various commentaries on the OSAF indicate that despite using Python extensively, most of the people involved were apparently Java programmers writing idiomatic Java-style code in Python. So, the OSAF's product may have been Python-based, but their organisation apparently wasn't. As you say in the main article:
"I'm curious as to how the decision was arrived at to not develop the server side code in Python."
I imagine that a bunch of people had their "suspicions confirmed" (recognise anything?) and stamped their feet about not using Java. Management presumably let them crank up Eclipse and start building the server components... for a project which was originally supposed to provide a peer-to-peer personal organiser.
"After all, Python has never been mainstream and possibly it's ardent supporters have developed unreasonable expectations as to what it's truly capable of."
http://www.python.org/about/quotes
Notice any big names there?
Really, the "dynamic languages encourage bad habits" attitude was already considered tired some time ago. If you want to look for causes of failure (or rather lack of existing success) then take a look at the organisation, the development practices, and the strategic decisions. There has been some good stuff done at OSAF - PyLucene springs to mind - but their apparent unawareness of the personal information management scene and the capabilities of existing technologies and applications quite probably led to way too much "not invented here" and the inevitably doomed monolithic, multi-year software project.
However, if you really want to point the finger at unproven technologies, you'd be better off waving it at wxWidgets, not Python. They didn't want to use Qt because they wanted full unfettered proprietary control over everything, and they brushed aside Gtk+ because it didn't have the Windows and Mac track-record (presumably to a chorus of "we use native widgets" by the wxWidgets people). Presumably, stuff like KDE and GNOME weren't on the radar of a bunch of the participants (probably being mainly Mac and Windows types), despite those projects having large software catalogues that show the readiness of the underlying GUI frameworks, and so they end up hiring someone to make wxWidgets bearable - yet another strategic diversion.
So, after a surprising amount of pontification, you managed to make the cheap shot with "suspicions confirmed" written all over it: it's the language! Converting the lengthy pontification into actual analysis might have given a deeper appreciation of what an oversimplification that particular conclusion is, however.