------art_5495_5618895.1149566877801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Entirely valid and thought-provoking point of view, and one that I'm finding
is quite characteristic of the Ruby community, perhaps indeed the defining
characteristic.

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.

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.

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. 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.

On 6/5/06, Matthew Smillie <M.B.Smillie / sms.ed.ac.uk> wrote:
>
>
> On Jun 6, 2006, at 2:42, James Britt wrote:
>
> > > Because I'm a businessperson, I'm always struck that people would
> > > question the value of achieving greater acceptance for anything.
> >
> > Interesting.  I'm always stuck by people who don't get think that
> > everything is fair game for questioning.
>
>
> It's worth questioning, because what does "acceptance in industry"
> mean for a language?
>
> In my view, it means "average".
>
> It means "Nobody ever got fired for picking X" (canonically, of
> course, XM).
>
> It means crunch-time, late nights, and all of the Mythical Man-Month
> traps which are also accepted by industry.
>
>
>
> Being accepted by industry doesn't actually provide me with anything
> other than a few extra buzzword points on my CV.
>
> More importantly, it wouldn't provide my hypothetical manager with
> anything other than a false sense of security, and a small dose of
> backside-covering warm fuzzy feelings, because the vast majority of
> the time it isn't a question of whether or not Ruby/Python/Lisp/Java/
> Smalltalk can do it, it's a question of whether or not *I* can do it,
> and no amount of industry acceptance will change that.
>
> I think it's pretty much agreed that good programmers don't need
> industry acceptance of their tools to do their job.
>
> What we ought to realise is that good managers shouldn't need it either.
>
> matthew smillie.
>
>

------art_5495_5618895.1149566877801--