From: Jim Freeze Date: 2005-06-04T06:20:43+09:00 Subject: Re: Building a business case for Ruby * Joe Van Dyk [2005-06-04 05:33:07 +0900]: > I asked this question a little bit ago, but wanted to bring it back up. > > I work for here>. We have "computing standards" that define what's allowable for > usage internally and externally. Technology evaluation boards, etc. > > Here's an evaluation of Ruby: > > "XXXX already has Product Standards for Python and Perl as > Scripting/Dynamic languages. And for Java as a full programming > language. > > Ruby offer nothing significant not found in these XXXXX Standard > languages, and an addition language just adds variation." So, you're saying they are making judgements about Ruby without actually even investigating it yet? ;) > We've got mountains of unmaintainable perl stuff here, and I haven't > really seen much in Python. I'm in charge of developing some new > software and would like to use Ruby. Actually, the software is > finished (very quickly) and I just need to get Ruby on the allowed > list. :( > I don't need arguments about Perl vs Python vs Ruby. I would like to > see a discussion of: > > 1) Why one additional language isn't a bad thing > 2) Examples of existing Ruby usages in large scale applications > 3) How Ruby can benefit this place This language stuff reminds me of religious conversion activities. If you aren't the king and can't make declarations like: "Ala or die!" (read "Ruby or your fired!") then you are forced to play the part of the humble wizard who has develops a method for alchemy and uses it to build up his portion of the kingdom along with anyone else who will join in. But, in the case of Perl, you probably feel more like Noah, knowing that Perl usage is going to bring (financial) destruction to the company and using the direct approach you will probably be as successful as Noah. ;) I just wrote a long message to a friend about this issue. I quote here what I can: > Why would I want to switch from PERL to Ruby? Short Answer: Because Ruby is better and Perl is harmful. Or better yet, because Perl cannot match what Ruby has to offer. But, this needs more explanation. Long Answer: No amount of physical evidence (or particular attribute of the language) is going to make or break the decision. You make the decision by your gut and then find evidence to support that decision. The only trick is to get others to make that same 'gut' decision. :) Most everyone I know using Ruby is doing so because they were looking for a good scripting language or one better than Perl. If a person is happy with Perl, then it would be interesting to know why, but I would not try to convince them to use Ruby, they have much bigger problems. ;) However, because an organization uses Perl, that doesn't mean that the organization is happy with the outcome. It usually is because that is all it knows. However, there are definite reasons why Ruby is an optimal language for the type of scripting work that is done in the XYZ industry. But, I don't think that just listing these here is going to help you make a case of why to switch. At YYYY, I have been asking myself questions similar to your original question[1]: "If I were my boss (or anyone at YYYY), why would I use Ruby (over Perl)." and "Why should I listen/believe this Jim Freeze guy about Ruby being better than Perl or Python?" Well, my current belief is that I can only answer this question by action. Words alone won't do it. So, in an effort to do this, I have been translating some existing code from perl to Ruby. My experiences, I believe, are equivalent to what you will find. Let me itemize a few: 1) Perl scripts (PS) are not centralized in their location 2) PS are not uniform in handling command line arguments 3) The PS use one primary data structure, the Hash (the array is second) 4) Converting the Perl code to Ruby without thinking reduces code size by about 30% 5) Refactoring the converted code usually yields a 50-60% reduction in file size with an increase in readability. 6) The PS's have no unit tests 7) It is difficult to debug the PS's, even with printfs. (Perl doesn't have the Ruby's equivalent of inspect) 8) The Object Oriented system of Perl is primitive - all methods are class methods. 9) The concept of IP library as we had at YYY has never occurred to anyone I have talked to at ZZZZ. 10) Code sharing has never occured to anyone at YYYY. This is a direct result of using Perl. Yes you can share packages with perl, but it is not usually done in a corp environment. The language does not encourage it. For some reason, pointing this out is not a strong convincing point. For most, the response seems to be, well we can do better and we should. But, they never do. 11) Only one Perl package was being used that did not exist in Ruby, the GDS parser. I am in the process of porting it to Ruby now. In the process of converting the Perl code and adding unit tests, I have found bugs (some innocuous, some not) and design flaws and weaknesses. The design flaws and weaknesses are mainly related to the Hash centric nature of the Perl code and the lack of a true OO system in Perl. The logic bugs are mainly due to lack of tests. The scary part is that some of these apps have been around for a while and are considered to be working bug free. The best way to convince someone (to at least listen to you) is to port some code and look at the results. Before the port I can say: Your Perl code most likely has bugs, you should switch to Ruby which is easier to debug and maintain. (not very convincing) After the port: Your perl code has bugs. The Ruby port has fixed those bugs and has unit tests to ensure the correctness of the application. Which would you rather use and maintain? (more motivation now to listen and see the benefits of Ruby with a testing and IP sharing framework.) > We have a large base of PERL code already. > I need good reason to overcome the inertia. The important thing to realize is that a large amount of Perl code does not mean there is any inertia in the corporate development or runtime environemnt. We have a lot of perl code at YYYY, but it is scattered and often teeters between being broken and running without any issues. I personally would not describe this as having inertia, more like a house of cards. :) Stepping up to a better language and phasing in a better way of doing things does not take away existing value.[2] So, even if some inertia exists, the only inefficiency is in not adopting the better method. So, possibly, the better question to pose is, Can Perl meet what Ruby offers? For a number of issues important in a corporate setting, the answer is clearly no. - support for unit testing and unit-test framework exists - code is easy to read - code is easy to maintain - code is readily sharable - code is scalable to multiple developers - code is scalable in speed - easy to drop down to C code BTW, I have created OptionParser, Application and project_config and am releasing them open source. These will definitetly help you in your deployment efforts. Footnotes: [1] At YYYY, I was told they had a recent experience with Python where they tried to get it installed throughout the company and replace Perl, and that effort failed. I was asked how is Ruby different than Python and why would it succeed. The question at the time was mostly rhetorical, but the point here is that successful deployment is more based on user support than language features. You just need to make sure that you have a language that does not irritate the users (both Perl and Python have proven themselves capable of irritating the majority). But the reason Python failed at YYYY was not because of the language but because of the deployment strategy and user support. Consider that John Doe and others tried for a total of three times to get a scripting repository deployed at ZZZZ and failed, whereas Ruby and the IP library has succeeded. I knew we would succeed because we gave the engineers what they wanted. [2] Only a few organizations understand the imperfection of humanity. There is probably not a single line of text in this email that I have not had to use the backspace key to correct a mistake. The same goes for code. It is unlikely that there exists a single script greater than 100 lines of code that does not have an undiscovered logic bug. > Off the top of my head: > > 1) C extensions allow us to easily integrate with external existing > software, but I don't know how Perl or Python does in that respect. Perl is difficult. I have heard the same for Python, maybe more so. > > 2) Built-in support for unit testing. > > 3) Extendability / maintainability, but I can't think of anything > objective to say here Depends upon the hostility of the person you are talking to. Take two programs - one in Perl and one in Ruby - create a five question quiz of various aspects of each program and have non-programmers take the quiz. This will give you some numbers of readability. > 4) DRb is very useful in developing distributed applications. I'd > imagine Perl and Python have similar features, but don't know anything > about them. Good luck. Let me know if I can be of more help. -- Jim Freeze Theory and practice are the same, in theory. -- Ryan Davis