From: David Pollak Date: 2006-05-04T06:58:27+09:00 Subject: Re: Sharp knives and glue ------=_Part_53464_26271506.1146693503146 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Kate, I'm sorry, but please, go back and read my posts. I love Ruby. I think Ruby is awesome. There are parts of Ruby that need improvement. Some of these things need to be improved/fixed before Ruby is ready to compete with J2EE or .Net for enterprise systems. The reason I am spending a lot of tim= e hammering on this issue is that I believe Ruby should be the next language/system that captures developer mindshare like Java did 10 years ago. One of the things that needs improvement is protection against meta-code breaking applications. This is not an issue of a programmer calling one se= t of APIs vs. another set. This is an issue of the order in which the classe= s were loaded impacting the execution of the code. In Java (unless the developers have used AOP), I know that no matter the order that my classes are loaded, the code will execute the same way. In Ruby this is not the case. Because classes patch other classes, the order in which the patches happen impact the code path. In the case of running Instiki under WEBrick vs. FastCGI, the EXACT SAME LIBRARIES are used. However, they are loaded in a different order and that load order is causing some methods to behave differently. The analogie to running an app under Tomcat vs. Jetty doesn't hold. This is not about making calls to different implementations of the same interface. This is an issue that the order in which the classes are loaded impacts the way the classes work. That level of unpredictability is very, very bad. Once again, please read all my posts rather than branding me a Ruby hater o= r mischaracterising the Instiki instance of the problem as a "you're using 2 different libraries" issue. I am a Ruby lover and as a Ruby lover, I am working to make Ruby a better environment for more people. There are problems with Ruby that make is not ready for enterprise systems. These problems have fixes. Admitting there are problems and admitting that Ruby needs to make it into the enterprise will help to address things rathe= r than having Ruby wind up in the heap of "coulda-been" systems like Lisp, SmallTalk, Objective-C/NextStep/Interface Builder, OS/2 (okay, I hated OS/2= , but many thought it was great), etc. VB, Java, C++, and maybe PHP made the grade. Let's figure out how to get Ruby into that club rather than the SmallTalk club. On 5/3/06, kate rhodes wrote: > > I have to disagree David. In my opinion this is just a case where a > programmer did something a little funky (metaprogramming) and didn't writ= e > sufficient code to check that his funkyness was always inserted correctly= . > > A great example is servlet code in java.. some things are completely > different in Jetty than they are in Tomcat. Put a webapp written with one > in > mind and there's a decent chance it's going to break in the other because > the programmer made assumptions about the environment. This is just like > instiki's developer making the assumption that it would be run under > Webrick. Does this mean that you can't recommend Java either? If so you'v= e > got some problems because we can bring up very similar examples from > pretty > much any language. If not, i think you should rethink your decision > against > Ruby. It may still not be appropriate for you clients but... > > -Kate > > On 5/3/06, David Pollak wrote: > > > > Kate, > > > > I don't think you understand the underlying issue in the post. It's no= t > > that Instiki doesn't work... you're right... that's not uncommon. > > It's WHYit does not work. > > > > The reason that Instiki doesn't work under FastCGI because the class > load > > sequence running under FastCGI is a different sequence than the class > > loading sequence under WEBrick. Because the classes are loaded in a > > different order, some of the metaprogramming stuff that's happening don= e > > "wrong" and thus Instiki doesn't work. If a pretty uncomplex system > > (Instiki is not very complex) is so very fragile and subject to problem= s > > because of the order classes are loaded into the environment, this > problem > > will just get worse in complex systems. > > > > Put another way, Ruby programs can break each other because they can > > change > > behaviors of the system and/or my classes. This makes Ruby programs > > unpredictable, especially in moderately complex systems. Unpredictable > > are > > not testable. Programs that are not testable cannot be put into > > production > > in environments such as insurance, financial services, etc. > > > > Thanks, > > > > > > -- -------- David Pollak's Ruby Playground http://dppruby.com ------=_Part_53464_26271506.1146693503146--