Comment
Above in this comment thread:
Is Chandler's Demise Evidence that Dynamic Languages Can't Scale? » Wha? » re:
visitors
reading
This site conforms to the following standards:
Too vague to be meaningful. Sure, but how does the code get written? I don't think anybody would claim that Chandler would be technically impossible in a less dynamic language. Only social problems held it back.
"Certainly, Chandler had its own internal social and political issues, but what project does not?"
Look at any successful project. You'll see that, while they may have had some issues, they did not *consist entirely* of internal issues and mistakes we thought the industry learned 20 years ago.
"It's the nature of software to have fluid requirements and efforts that lead to dead ends. The question is then, can the development environment that was is in compensate for this?"
These are social questions, not technical ones. They certainly don't sound like anything which would be harder in Python or any other "dynamic language".
"Apparently, the magic wand of Python was not enough."
Nobody claimed Python was a "magic wand", or that a programming language can compensate for making every mistake possible. Building blindingly obvious straw men ("Python is a magic wand" -> "here's a failed Python project" -> "dynamic languages are unsuitable") is not useful to anybody.
"But that’s hardly how it looked in 2002. It attracted people with considerable renown in the field, like Andy Hertzfeld and Lou Montulli, as well as other, equally smart and talented developers whose names are not as widely known. Nor, even at this late date, do I consider Chandler in any way to be definitively “doomed” — though certainly it has failed to live up to its initial dreams."
The project began with a lot of promise and was loaded with the requisite talent. It was in fact at the time to be a showcase of what Python was capable of doing. To mis-characterize it as just another Python project that failed is an attempt to deflect blame.
The book 'Dreaming in Code' describes events up to 2005. That was 2 years ago and is plenty of time to fix the projects mistakes. So, what happened since then isn't public knowledge and it's reasonable to question Python as a probable reason for failure. That's why my title ends is a question and not a statement.
Just to be clear, the project did NOT fail because of:
(1) lack of talent
(2) lack of resources
(3) lack of time
From what I've read from other sources, the project may have failed due to:
(1) Poor project management
(2) Poor team development
(3) Poor software practices
Claims that selecting Python was one of the few correct decisions would also be a stretch.
That's unless you provide some good arguments to back it up.
The fallacy can be stated thus: "If there exists a project which has adopted a dynamic language and has failed, then all projects which adopt dynamic languages will fail."
Of course, this is not to say that the adoption of Python wasn't a symptom of this project's failure, or even a contributing factor, but it would take a lot more argumentative foundation to get away from the fallacy. However, even with the flawed opening paragraph, I'm not convinced that the author didn't salvage the argument by focusing more on the selection of dynamic (read: languages without good refactoring tools) languages as symptoms of a project's inability to focus on what's really important.
After all, there is no real silver bullet (the reference to Brooks' Law at the top of the article is unmistakable). One of the most important statements in the entire paper is: "The ease of employing meta-object protocols add an additional burden to understandability by making behaviors less traceable." If this argument could have been linked less to "dynamic languages," and more to "some of the people that use dynamic languages," then I would have been more convinced.
If there's anything we've learned from Fred Brooks and those after him, it's that, "It's the people, stupid."