6 ms·

The fact that anyone at any point can monkey patch any built-in is a potential liability for large teams, with average programmers. It must be addressed by cul

• jshen 16y ago
  I've never bought the idea that the opposite is a better trade off because it comes with costs too. Have you ever worked with a bunch of mediocre java programers? Heaven forbid they make an interface that isn't well thought out and needs to be changed later!
  • rjurney 16y ago
    That extreme is also terrible. Python is somewhere in between.
    • jshen 16y ago
      if ruby is an extreme to the left, and java an extreme to the right, then python is also extreme to the left. The difference between python and ruby in dynamicity is really small. Python is not in the middle of ruby and java. Python is virtually on top of ruby.
      • andybak 16y ago
        A fair point. Maybe 'optimum' would be a more useful concept here than 'centre'... I see Python's position on the dynamicity (ugh) spectrum is in line with it's philosophy on readability. (On a side note - your definition of 'extreme' rather depends on what outliers you have. I do love it when the US media refers to the Democrats as 'left of center' ;)
        • jshen 16y ago
          yup, republican and java are in the same camp ;) On a serious note, I've been doing ruby as my job for about 5 years and I work at a giant corporation with a few hundred programmers. In those 5 years I've never been bitten by someone changing a core class that breaks my code. Maybe 3 times I've been bitten by someone changing a non core class, and it usually takes me about an hour or two to resolve it. So that's maybe 6 hours in 5 years where I've lost time due to this, but the amount of time it has saved me is far larger than this.
          • andybak 16y ago
            That sounds like an interesting big Ruby gig that would be a good story to tell the anti-dynamic languages FUD brigade. You should blog :)
• wmoxam 16y ago
  Are there many ruby app built by large teams? In my experience, teams building Ruby apps tend to be much smaller than teams building Java apps .. That said, this is a problem for any libraries that you might want to include, you have to trust that the authors followed conventions and didn't do any thing 'evil'. Ruby Rewrite (http://rewrite.rubyforge.org/ http://rewrite.rubyforge.org/) was conceived to specifically avoid this sort of problem.
  • sunkencity 16y ago
    The best software is built by small teams.
• derefr 16y ago
  In what situation is it actually a good idea to employ a large number of bad programmers, rather than a small number of good ones? We shouldn't be making trade-offs for the sake of bad ideas ;)
  • techiferous 16y ago
    ...and all it takes is one rogue or bad programmer to mess up the code base.
    • derefr 16y ago
      ...in either scenario. During code review, however, I'd expect that the good programmers would reach much more strongly to the rogue commits than the mediocre programmers would.
  • acdha 16y ago
    There's a distinction to be made between preventing risky behaviour and relying only on a programmer's good judgement to avoid mistakes. Even if your team is solely good programmers there's a lot to be said for discouraging unsafe behaviour by default since anyone can have a bad day, distraction, etc. I view this situation as somewhat analogous to having guards on power tools: even a highly skilled operator doesn't want to rely on always doing something perfectly.
    • derefr 16y ago
      The nice thing about code is that (when version controlled) all mistakes can be fixed retroactively. As long as two programmers aren't having a bad day at once, pairing will catch "all" errors. As long as all your programmers aren't having a bad day at once, code review will catch "all" errors again. ;)
      • wariola 16y ago
        This is why you need to automate peer review http://www.parasoft.com http://www.parasoft.com