From: "M. Edward (Ed) Borasky" Date: 2006-06-07T15:44:31+09:00 Subject: Re: I love Ruby - But how bright is Ruby's Future? Francis Cianfrocca wrote: > Large problems: you're playing word games with me. "Large" has many > meanings. Two that are germane to my point are: information systems > with an > extremely long anticipated lifetime (meaning that it's unwise to > expect the > original developers to stay committed to it), and systems that cut > across a > large number of knowledge domains in a single organization (meaning you > can't leverage the expertise of a world full of developers). A lot of > resources go into solving problems that are understood along these lines, > and a lot of those resources get wasted. THAT is a problem that's worth > solving. Ruby could be part of the solution, if more of the community > were > interested in the problem. As in "Enterprise Integration With Ruby?" Yeah ... I probably write what you'd call "enterprise integration" but what I call "glue logic" in Perl. That's mostly because I learned Perl 4 about ten years ago and haven't needed anything better, except for math, where I have R. But I'm a "domain expert" in performance engineering, monitoring, analysis, etc. -- at least that's my role at present. Nobody would ask me to write a web application. If they did, it would undoubtedly be in either .NET or PHP, not Ruby. Long lifetimes ... is that air traffic control system from the late 1960s still up and running? :) The one that was written in System\360 Assembler, PL/I and probably some other languages? Is Chuck Moore's Kitt Peak Forth code still driving that telescope? Has NASTRAN been ported from Fortran to some more "modern" language? Resources wasted? That's a "fundamental law of nature" having to do with large teams starting to exhibit behavior reminiscent of gas dynamics. I don't see how Ruby changes the realities of large teams, any more than any other "magic bullet" has in the 44 years I've been programming. If the "Ruby community" isn't interested in *that* problem, more power to them! :) > > Advocacy: you make a compelling point that the advocacy around Ruby is > part > of the more general enthusiasm for agile development and dynamic > languages. > Well and good, so long as your focus is on computer programs as > beautifully-crafted artifacts. But this advocacy is largely meaningless > several steps higher, where decisions are made about which computer > programs > to fund the development of. A different kind of advocacy is required > there, > and it's becoming clear to me that Ruby advocacy probably doesn't > belong at > that level. The original topic of this thread was Ruby's future. It > may be > that Ruby's future is all about projects that are undertaken for love, > not > money. And there's nothing wrong with that. Yeah ... Ruby is certainly a beautifully-crafted artifact. It's perhaps more complicated than it needs to be, especially when you compare it with the stark simplicity of Lisp, Forth or LIW microcode. Any language with "lambda" is OK in my book. :) > > On 6/7/06, M. Edward (Ed) Borasky wrote: >> >> >> >> Francis Cianfrocca wrote: >> > Ruby is the only programming language I know that (for specific >> reasons >> > inherent in the design of the language) has some potential to >> > challenge the >> > prevailing wisdom among businesspeople who manage IT projects. >> Which, to >> > oversimplify, is that a large problem requires something at least >> > resembling >> > a large team. I'm eliding some of the logical steps, but this entrains >> > much >> > of what you and others (with some justification) criticize as >> > backside-covering. >> Well ... I suppose it depends on how you define "large problem". Let's >> assume, for example, that you have a well-behaved business problem whose >> natural solution algorithm uses resources that grow no faster than N log >> N, where N is the size of the inputs. A prototypical such problem is >> sorting. >> >> That may be a large problem, given, say, trillions of records to sort >> through. But it does not require a wide variety of domain expertises, >> and as far as I can tell is no easier in Ruby than in any other >> language, including some very old ones. >> >> In the scientific realm, consider the problem of hurricane forecasting. >> Again, there isn't a wide variety of domain expertises required, >> although just about everybody understands sorting and not just about >> everybody understands partial differential equations and atmospheric >> physics. This is also a problem for which it is highly unlikely that a >> Ruby solution would be proposed. >> >> So there are two examples of large problems which would not necessarily >> require a large team. I'm sure there are numerous others -- Google has a >> solution to one of them at its core. >> >> I think perhaps you're mistaking "large team required" with "non-agile >> process required" and unconsciously linking agile processes with Ruby. >> I've seen a lot of programming languages, both general purpose and >> special purpose, and I guess I'm not convinced that Ruby is the "best" >> general purpose language, or even significantly "better" than, say, >> Java, Ada, or even Common Lisp. >> > >> > But this goes directly against the ethos that software production is a >> > fine >> > art, and that the choice of tools matters less than the quality of the >> > artifact. This feeling has been a recognizable characteristic of >> software >> > practitioners long before Ruby was invented, as has the concomitant >> > criticism of IT managers. As one of those managers, I wouldn't >> dream of >> > attempting to build a large one-off enterprise application in Java >> > with one >> > or three top-quality programmers and five assistants. But someday I >> might >> > actually consider doing it in Ruby. >> Pure Ruby, or Ruby plus Rails plus all of the other tools that have >> sprung up from Ruby? And what about .NET? >> > >> > The best Ruby programs are small ones. This is wired into the >> > genetics, and >> > the aesthetics, of the language. But small Ruby programs can be >> > remarkably >> > powerful, in ways that can fundamentally change the dynamics of >> software >> > production. If this point can be made by powerful and eloquent >> advocates >> > then Ruby may become a much more widely used language. >> I don't think this is true only of Ruby. Small, elegant solutions to >> problems can be powerful in quite a few other languages. The ones that >> spring to my mind right now are Lisp, Forth, APL, R and SmallTalk. And >> one other that probably doesn't spring to many minds except my own these >> days -- macro assembly language. :) >> >> And I can think of languages where it isn't true -- Fortran, C, COBOL >> are the obvious ones. And then there are "borderline cases" -- Perl and >> Java are the two that I know of. I don't know enough Python or PHP to >> classify them. >> >> > But so much depends >> > on the goals one chooses to pursue. Many committed Rubyists have >> > stated many >> > times that Ruby should not have widespread adoption by business as a >> > goal. >> > (Perhaps underneath this, there is fear that success would corrupt >> Ruby's >> > essential character. If so, that's a topic for another thread.) But >> this >> > does explain why the Ruby community has so few powerful and eloquent >> > advocates. >> I wonder if a language can "have a goal". Ruby, like some other >> languages, is a community that sprung up around a creative force, in >> this case Matz. Perl sprung up around Larry Wall, Lisp around John >> McCarthy, APL around Ken Iverson and Forth around Chuck Moore. >> >> John McCarthy's goal was to create a computer that could take advice. >> Chuck Moore's goal was to write a lot of programs in a compact way. Ken >> Iverson's goal was to bring the tools of mathematical formalism to >> programming. As far as I know, none of them -- Larry Wall and Matz >> included -- had as a goal getting rich, or world domination, or creating >> the "best" computer language. >> >> I think Ruby *does* have powerful and eloquent advocates. I'm just not >> sure they are advocating Ruby so much as they are advocating agile >> processes, metaprogramming, domain-specific languages, "duck typing", >> dynamic languages, and, of course, Rails. :) >> >> -- >> M. Edward (Ed) Borasky >> >> http://linuxcapacityplanning.com >> >> >> > -- M. Edward (Ed) Borasky http://linuxcapacityplanning.com