5 ms·
My theory: As a dynamic language, Ruby doesn't scale, but not in terms of performance--it doesn't scale in terms of developers. Projects written in dynamic lang
by ericb 16y ago
My theory: As a dynamic language, Ruby doesn't scale, but not in terms of performance--it doesn't scale in terms of developers. Projects written in dynamic languages have a development edge at smaller scales--more functionality can be produced faster by fewer developers.
If a project expands to a large number of number of developers, eventually the power to do virtually anything becomes a liability when a lone bad developer can wreak havoc on a project-wide scale by redefining standard functions, or relying on scary monkey patches.
- cageface 16y agoHuge applications have been built in dynamic languages. It just requires good architecture and code discipline. But that's true of development in any language.
- viggity 16y agoI'm not saying that there haven't been gigantic applications written in dynamic languages. But the number of gigantic apps built on Ruby pales in comparison to .Net or Java. Having static typing helps prevent these massive apps from becoming an even larger cluster.
- cageface 16y agoI've heard a lot of hand waving arguments on both sides of this issue and at this point I'm not going to be persuaded by anything other than hard numbers. We need some way of quantifying the size and complexity of an application and then we need a statistically significant sampling of apps in both static and dynamic languages. At this point anything less than that is just conjecture. We can do the "ruby doesn't scale" dance back and forth all day but we're not really learning anything.
- LargeWu 16y agoIn practice, this doesn't happen nearly as often as you might like to believe. Where I work, we monkey patch occasionally, but never the standard functions. It's usually a 3rd party library that we're editing that we need to bend to suit our use case.
- ericb 16y agoIs your shop 20+ developers? Monkey patching isn't dangerous in and of itself, to my mind, but the prospect of code-surprises is ever present. When I read code, I may not realize it has been overwritten elsewhere. I'm not sure at what number of hires that guy makes his way into the group, but debugging becomes an increasing part of development costs.