From: Mike Nelson Date: 2006-05-05T00:04:55+09:00 Subject: Re: Sharp knives and glue David Pollak wrote: > The consquences of this is I can't recommend Ruby to my enterprise > clients > because they can't predictably deploy applications unless they have a > freeze-dried perfectly versioned system that will never change because > of > the unpredictability and instability of changing library versions. > Isn't this the case with any language? As I see it this is not a language specific problem. You want this kind of control for any production system in any language. You don't want the throw in new libraries, or any piece of software for that matter, into a production system without testing in on a test system first. > Oh... BTW -- Instiki passes its unit tests because the load sequence is > correct for the unit tests... but it's not correct when Instiki is > launched > as a CGI or FastCGI. So... the consquences of this is that you can't > trust > unit tests in Ruby because they can be impacted by Module/Class load > sequences. It sounds like they need to add a test case for this then and then fix it (if they support that configuration, I don't know). This sounds like an Instiki issue, I wouldn't apply this generally to Ruby. I think we've all had problems like this before in systems (whether or not they use Ruby). I know I've had my share. Generally, I believe a language or system is considered not ready for enterprise apps until many people think that it is, and that usually comes from many people using it for enterprise apps. I know, it's a catch-22 and it's just based on people's perception which is not based on reality. Once people believe that it's suitable for this type of app, people will just start to solve problems like you have found rather than point to the language as the problem. Candidly, I personally believe that any language or tool can work in enterprise, mission critical systems. I also believe that any language or tool can fail in the enterprise. The only true test is the empirical test, to test it for what you are going to do with it. In my mind that is the only proof that matters for whatever problem domain that it applies too. Going all the way back to the original question, talk about whether something is ready for this or that, while very interesting discussion, is sort of in the clouds intellectually, so to speak. While this can lead to interesting and very useful ideas it seems impossible to prove this point one way or another, without actually seriously trying it for whatever your needs are. I think what really matters is the comfort level with the people on the team with the tools that they use. Ruby might work for the system, but if the developers involved don't think that it is a good tool or doubt that they know how to use it properly then they are bound to have a miserable time building the thing. I'd tend to say just use what the team has the highest confidence with. -- Posted via http://www.ruby-forum.com/.