# Can large scale projects be successful implemented around a dynamic programming language? **URL:** \ **Category:** Development\ **Created:** [January 24, 2008, 4:07am UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008 "2008-01-24T04:07:46Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 24, 2008, 4:07am UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/1 "2008-01-24T04:07:46Z")
A good article I have found (may have been linked by slashdot, don’t know) [http://www.manageability.org/blog/stuff/chandler-failure](http://www.manageability.org/blog/stuff/chandler-failure) In fact, thinking about it, I remember my C++ university times, when several friends put together some program and the whole thing crashed badly at compilation time. Being the dynamic nature of Ruby, it will not crash at compilation (just no compilation!), it will just work till the given function is called (or tried to) and the problem is found, that may not happen to you but someone else… It is much harder to audit or make test for all the code than the compiler checking types, interfaces, etc. (Of course integrating is not only about making it compile together) I am just arguing that the author may have reason and dynamic language have some flaws. Knowing them is the first step to improve Ruby (please don’t think I’m trying to troll) ---
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 24, 2008, 5:24am UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/2 "2008-01-24T05:24:26Z")
> I am just arguing that the author may have reason and dynamic language > have some flaws. A dynamic language + test driven development is considered, in some circles, to be incredibly more productive than a static language with both static type checking and unit tests. Productivity means robustness, and the more code you can _remove_, the more robust you generally get. Dynamic languages and TDD both make removing code - refactoring to remove duplication - super easy. Block closures are a major help, too, because they solve the ‘finally’ and ‘RAII’ issues that plague other languages. Then, all the static languages tend to bend over backwards to provide dynamic features. The closer to the metal you run, the more static you must be. The farther you are (such as the web), the more dynamic you should be. ---
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 24, 2008, 3:18pm UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/3 "2008-01-24T15:18:23Z")
On Jan 23, 2008, at 9:07 PM, Jordi wrote: > A good article I have found (may have been linked by slashdot, don’t > know) > [http://www.manageability.org/blog/stuff/chandler-failure](http://www.manageability.org/blog/stuff/chandler-failure) Well, I didn’t find it to be a good article at all. I felt it was just some guy speculating wildly about something he knows very little about. He pretty much admits that, multiple times. After reading the post, I followed a couple of the links. I read a little and watched a podcast. In just doing that much research (I’ve never heard of Chandler before), I felt like it was quite possible the project had trouble defining their scope and establishing their financial viability. Perhaps it failed for those reasons. Perhaps it failed because the entire development team converted to a religion that tries to minimize their computer usage. I’m totally making that up and I mean no disrespect to the developers, but that’s really my point. If you watch the video podcast, it’s interesting to see how many of the interviewer’s, a self proclaimed Outlook fan, questions these “Outlook killer” developers don’t really have a good answer to. I feel that was much more likely to be damaging in the long term than their choice of language. James Edward G. II ---
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 25, 2008, 8:11pm UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/4 "2008-01-25T20:11:57Z")
Jay L. wrote: > exemplary virtue. > If you build a mail system that relies on a database, someone will > inevitably decide that a mail system, with its built-in queueing, routing > and simplicity, is a great transport for asynchronous replication, which in > turn, can be used to create a distributed file system. And once you’ve got > a file system, well, wouldn’t it be great to get a database running on it? What does any of this have to do with Ruby core? Naively small-scale question that demands a large-scale answer the size of a book. On the other hand, because of my current experience with a _very_ “large-scale” Ruby on Rails system, my answer is “YES!” 🙂 “Large-scale” projects have many axes of “largeness” and solutions thereof. In the big picture, most of those axes have no correlation with an implementation language’s ability to do eval() or introspection, etc. That is not to say that the choice of language does not have an impact on the feasibility (time-to-market, maintenance cost, deployment cost, etc.) of a large system. But at some point, you need to push those details down into other layers of design and live with what you have. [http://kurtstephens.com](http://kurtstephens.com) ---
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 25, 2008, 9:10pm UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/5 "2008-01-25T21:10:52Z")
Kurt Stephens wrote: > What does any of this have to do with Ruby core? > > Naively small-scale question that demands a large-scale answer the size > of a book. On the other hand, because of my current experience with a > _very_ “large-scale” Ruby on Rails system, my answer is “YES!” 🙂 Way to answer your own question! ---
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 26, 2008, 5:53pm UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/6 "2008-01-26T17:53:00Z")
The point I think is that being the dynamic nature of languages as Ruby where you can for instance open a class anytime anywhere, is virtually impossible to create a tool to verify the code without actually running a unit test or similar on it. (correct me if I am wrong) In fact, static language needs that also (to verify semantic correctness), but having a static tool called compiler 😛 that can catch some common errors and being more strict languages (they have types and a mismatch of types will be caught) they can say for instance that method will only admits integers. But the point is that there is a lot of information out of the specification of any language. For instance if you return an integer, -1 means error? That information is documented not defined and checked by the compiler. So both times of languages have the same “problem”, test are needed to verify them. The only difference is that dynamic languages don’t have the “simple” static verification of the compiler. So that need is made more accurate. Knowing this and improving Ruby in this area can only make the language even better. I still think that it is a good article. ---
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 24, 2008, 8:33pm UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/7 "2008-01-24T20:33:09Z")
On Thu, 24 Jan 2008 23:17:34 +0900, James G. wrote: > > A good article I have found (may have been linked by slashdot, don’t > > know) > > [http://www.manageability.org/blog/stuff/chandler-failure](http://www.manageability.org/blog/stuff/chandler-failure) > > Well, I didn’t find it to be a good article at all. I felt it was > just some guy speculating wildly about something he knows very little > about. He pretty much admits that, multiple times. I find it telling that the article begins by citing Eclipse as a paragon of exemplary virtue. Eclipse, while I find it useful as an IDE sometimes, is sluggish, incredibly complex, and about as far from agility as one can get. It’s only just starting to break free of its own gravitational field - and that was accomplished only by _doubling_ the codebase from 7 to 17 million LOC. Eclipse (and Java in general) is a great example of what I call “stratification” - the re-implementation of lower layers in ever-higher layers, because nobody even remembers the lower layer is there anymore. If you build a mail system that relies on a database, someone will inevitably decide that a mail system, with its built-in queueing, routing and simplicity, is a great transport for asynchronous replication, which in turn, can be used to create a distributed file system. And once you’ve got a file system, well, wouldn’t it be great to get a database running on it? ---
**Author:** ![jordi](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/53a042/32.png) [@jordi](https://www.ruby-forum.com/u/jordi)\ **Post date:** [January 27, 2008, 10:06am UTC](https://www.ruby-forum.com/t/can-large-scale-projects-be-successful-implemented-around-a-dynamic-programming-language/127008/8 "2008-01-27T10:06:26Z")
On Jan 26, 2008 9:51 AM, Jordi [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > accurate. Knowing this and improving Ruby in this area can only make the language even better. Sorry if this comes across as rude (it’s definitely not the intention), but this subject is really off-topic on ruby-core. Moreover, it has been discussed (on ruby-talk) at least 1000 times by now. The article you cite is the same line of reasoning 995 out of those 1000 earlier conversations started with. At this point, I would be hugely amazed by anyone adding anything interesting to the “Ruby should have type checking” idea.