I love Ruby - But how bright is Ruby's Future?

ruby-talk
41

Apologies for the rant, but...

I'd like to see a serious enterprise-grade SOA framework that is either
written in an agile language or supports them well. Doesn't matter if it's
Ruby or Python. Python's Twisted has PB, but it's several steps short of
what is really needed. Ruby has nothing close yet.

Having worked with a number of "enterprise-grade SOA frameworks" I think the best available one, by a long shot, is HTTP and and a good glue language (Perl is the most common, Ruby is moving way faster though). (2)

A realistic SOA framework is a set of state transfer idioms and protocols which will be adhered to as best as possible across languages, platforms, and applications. The most useful set of guidelines for this which I have seen as an implementor (NOT as a vendor) is Roy Fielding's thesis. (1) I believe that a push model is also important, but for that we have no good solution yet, in any language, for any platform.

This is all completely language independent. In my experience the tools and systems which have tried to create a super-high level language for integration/SOA have pretty much been abysmal failures, and the folks embracing protocol based and idiomatic integration at a lower level have met with lots of success. This is, of course a generality, but the correlation is very high based on the data available to me.

One big problem seems to be that, by and large, when people are shopping for an SOA framework they are looking for way to make non-programmers (in which category I include incompetent programmers) into useful programmers. This is all well and good, but training and protocol understanding, not tooling to abstract the solution away form the problem, is a much more fruitful path.

This is not to say the building these systems is simple with protocols and glue, and that sophisticated tools are not useful, but that the sophisticated tools which are useful are generally the ones which embrace the wire protocols and data idioms rather than hide them. Point of reference, mod_rewrite has done more good for distributed systems than all of WS-* in its entirety or any of its parts.

My 2p =)

-Brian

1. Architectural Styles and the Design of Network-based Software Architectures

2. For the enterprisey folks out there, JBI based tooling, and its competitors in the programming standards space (SCA, Indigo, ???), when the API's are used directly, is HTTP with a set of idioms glued on top and a mediocre to poor glue language. When drag and drop is used to generate Java/C# by folks who don't know what an idempotent method is, it is generally borkage.

···

On Jun 6, 2006, at 9:52 AM, Francis Cianfrocca wrote:

42

Peter Ertl wrote:

It's similar to the complaint that Ruby does not have an IDE such as Eclipse; some Rubyists argue that there isn't one because there is no compelling need for it, as there is in Java.

www.radrails.org

I thought that was focused on Rails, and did not do automatic refactoring or code completion.

But if it works for general Ruby the same way as Eclipse works for Java, then that's quite slick.

···

--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

43

RadRails is for Rails, but it uses RDT which is the ruby toolkit that can be downloaded separately:

Both RDT and RadRails rock. I use them daily.
-Mat

···

On Jun 6, 2006, at 1:01 PM, Peter Ertl wrote:

It's similar to the complaint that Ruby does not have an IDE such as
Eclipse; some Rubyists argue that there isn't one because there is no
compelling need for it, as there is in Java.

www.radrails.org

44

^
(Maybe so, but you're missing an opening parenthesis... :wink:

···

On Monday 05 June 2006 11:42, Elliot Temple wrote:

On Jun 5, 2006, at 10:30 AM, Giles Bowkett wrote:
> Two of the best languages to learn are Smalltalk and Lisp. Neither one
> of these languages has virtually ANY future

Lisp is *the* future :slight_smile:

--
Wesley J. Landaker <wjl@icecavern.net> <xmpp:wjl@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2

45

And always will be.... :slight_smile:

···

On Jun 5, 2006, at 1:42 PM, Elliot Temple wrote:

On Jun 5, 2006, at 10:30 AM, Giles Bowkett wrote:

Two of the best languages to learn are Smalltalk and Lisp. Neither one
of these languages has virtually ANY future

Lisp is *the* future :slight_smile:

46

Austin Ziegler wrote:

It wasn't the tool that failed, but the framework (and of course
Borland had a lot to do with that).

Um. Has the framework failed, or is it now just that the vendor support
for the tool and framework gone away?

What's the difference. Once you have coded to a framework, your code
will only work with that framework.

So once the support for the framework goes away, you are now stuck in a
never progressing environment.

That's is why you can't just "jump" into any language just because you
like it.
Unless you are only doing it as a hobby or working for yourself.

This could be resolved with a out-of-the-box ODBC/JDBC driver as part
of the different type of databases supported.

No, it can't. Why can't it? Because if people don't *need* such a
driver, they're not going to *develop* such a driver. I'm sure that the
Rails team would be happy to add other drivers (if there aren't plugin-
hooks for use with RubyGems for such drivers, which is even more
sensible), but it has to be developed first. That's why you talk to the
database vendor and say "You should really look at this Rails thing."
Maybe get *them* to develop the driver for you.

Here is a list of Drivers that people *need* for Rails...
http://wiki.rubyonrails.com/rails/pages/DatabaseDrivers

Approx. 90% of these would go away if they implemented ODBC.

···

On 6/5/06, ReggW <me@yourhome.com> wrote:

--
Posted via http://www.ruby-forum.com/\.

47

Francis Cianfrocca wrote:

An individual who
really understands software development doesn't pick a programming language
to concentrate on. He's productive in anything you tell him to use, and he
doesn't particularly care either.

Wow. That's surreal.

I have a hard time imagining someone who really understands software development and yet doesn't care if someone dictates what language is used. And yet can be (equally, one hopes) productive whether working with VB, Lisp, Cobol, or Brainfuck.

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

···

--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine

48

Francis Cianfrocca wrote:

Because I'm a businessperson, I'm always struck that people would
question
the value of achieving greater acceptance for anything. Different
strokes
for different folks, of course. But at some level, I have to think about
protecting the investment that I make in people who learn Ruby while
working
on my projects, which I've done several times in the three-plus years
I've
been shipping commercial software written in Ruby. Although I personally
love programming in Ruby and do it whenever I can, your points really
throw
the larger business questions into relief.

Well said...I totally agree !!

···

--
Posted via http://www.ruby-forum.com/\.

49

What I meant was that Python has achieved a degree of respectability in
corporate environments that Ruby hasn't yet.

It all depends on where you're looking. I'm in a very big corporate
environment (though, admitedly we're kind of an isolated group that
has some independence) - It's a well known, household-word type tech
company. I'm seeing that Ruby has lots of respectability in our
group. Even more than Python seems to have.

And this doesn't happen by
itself, and it certainly doesn't happen just because a language is
particularly well-done or particularly nice for programmers to use. I think
you may be underestimating the degree to which technology choices in large
organizations are driven by the need to reduce the perception of risk. It's
not universally true that a programmer who "delivers the goods" will get to
pick his technology.

If you're in a reasonable group then the emphasis is on delivery. If
you can deliver product X twice as fast by using technology Z then
after a while nobody (including management) is going to care that
technology Z hasn't been blessed by corporate. At some point it will
be blessed by corporate because it increases productivity. It can
take a while to get there sometimes, but I think Ruby has pretty much
arrived at the point where it's being 'blessed by corporate' in enough
shops that it's really just about mainstream.

But the question gets asked here time and again: who cares if people in
corporations don't use Ruby, as long as I can use it on my own projects?
Entirely valid. But if you really like using a language, wouldn't you want
to use at work as well as at play? And to get that kind of acceptance for
Ruby will take some serious advocacy. With the rise of Rails, that may be
starting to happen, but it's too soon to tell.

Compared to 2001 it _has_ happened; back then it was an uphill battle
getting companies to use Ruby. Rails has helped tremendously, but
looking back I notice that I've had several paying jobs that involved
writing Ruby code (even back in 2001). The change now is that I
don't have to educate people about what Ruby is, they already know
about it and either they've been learning it or they want to.

Because I'm a businessperson, I'm always struck that people would question
the value of achieving greater acceptance for anything. Different strokes
for different folks, of course. But at some level, I have to think about
protecting the investment that I make in people who learn Ruby while working
on my projects, which I've done several times in the three-plus years I've
been shipping commercial software written in Ruby. Although I personally
love programming in Ruby and do it whenever I can, your points really throw
the larger business questions into relief.

(For the little that it's worth, we shipped a pair of apps in Rails, and
coudn't get past the performance issues, so we now ship web apps in
handwritten Ruby with our own handwritten web servers.)

And to your point about programmers who deliver the goods: I've been
privileged at several times to have some of those magical crazy people
working for me who can deliver almost anything on almost any schedule. And
although the sample set is small, those I have known all share this key
characteristic: the programming language DOESN'T MATTER. An individual who
really understands software development doesn't pick a programming language
to concentrate on. He's productive in anything you tell him to use, and he
doesn't particularly care either.

But the language choice _does_ often matter especially when schedules
are tight and manpower is short. If you want product Z done and you
give me the choice of implementing in either C++ or Ruby and you want
a schedule I'm going to tell you that in Ruby I could get it done in x
weeks while in C++ it'll take 4x weeks. If runtime performance isn't
an issue then using Ruby for the project is an easy choice. Even if
runtime performance is an issue, Ruby and some C code might still be a
very good choice.

I suspect that these magical people you're referring to would balk if
you suggested that you want your next project done in COBOL or Basic,
so programming language choice does matter to some extent even for
them. If it weren't for the adventurous programmers who decided they
weren't satisfied with the status quo we'd likely still be using COBOL
and FORTRAN.

Phil

···

On 6/5/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:

50

I used to make my living selling my
programming skills but now I'm mostly a buyer of the programming skills of
others. I guess that makes me a crappy business person.)

Well, I would have no way to assess that as either true or false, but
certainly that wasn't what I meant.

It does sound, however, as if you have some crappy business people for
customers. (No offense, so do I!)

What I meant was that Python has achieved a degree of respectability in
corporate environments that Ruby hasn't yet. And this doesn't happen by
itself, and it certainly doesn't happen just because a language is
particularly well-done or particularly nice for programmers to use. I think
you may be underestimating the degree to which technology choices in large
organizations are driven by the need to reduce the perception of risk.

No, I am completely aware of that, I'm just firmly of the opinion that
working for large corporations is detrimental for the sharpness of
programming skills.

It's
not universally true that a programmer who "delivers the goods" will get to
pick his technology.

True, but although it isn't **universally** true, it is true for a
number of excellent programmers who also make very good business and
marketing decisions. Other things are true for other programmers, but
I don't care, because those other programmers aren't my role models.
I'm firmly of the opinion that the answers you find are much less
significant than the questions you ask. Consequently I'm only willing
to ask the questions that will make me an excellent programmer.

But the question gets asked here time and again: who cares if people in
corporations don't use Ruby, as long as I can use it on my own projects?

Hold on -- I have herad that question, but you're assuming everybody
only works on large corporate projects. In my case, I don't want to
work for large corporations, but I do want to be paid to use Ruby.

Entirely valid. But if you really like using a language, wouldn't you want
to use at work as well as at play? And to get that kind of acceptance for
Ruby will take some serious advocacy. With the rise of Rails, that may be
starting to happen, but it's too soon to tell.

The ability to use Rails is a major priority for selecting my next
job. But it only takes serious advocacy if you're choosing customers
who have prioritized minimizing risk over maximizing results. If
you're only even willing to consider customers who prioritize
maximizing results over minimizing risks, the advocacy effort becomes
nonexistent.

Because I'm a businessperson, I'm always struck that people would question
the value of achieving greater acceptance for anything.

Fair enough, you're thinking of marketing, obviously increased demand
can be a good thing. But you have to realize the dangers of a
commodity-oriented model when you're running a service business. You
don't want to compete on price. (Chad Fowler's book "My Job Went To
India" explains why.)

Different strokes
for different folks, of course. But at some level, I have to think about
protecting the investment that I make in people who learn Ruby while working
on my projects, which I've done several times in the three-plus years I've
been shipping commercial software written in Ruby. Although I personally
love programming in Ruby and do it whenever I can, your points really throw
the larger business questions into relief.

(For the little that it's worth, we shipped a pair of apps in Rails, and
coudn't get past the performance issues, so we now ship web apps in
handwritten Ruby with our own handwritten web servers.)

Using parts of Rails, or entirely handwritten?

Are the web servers in Ruby?

And to your point about programmers who deliver the goods: I've been
privileged at several times to have some of those magical crazy people
working for me who can deliver almost anything on almost any schedule. And
although the sample set is small, those I have known all share this key
characteristic: the programming language DOESN'T MATTER. An individual who
really understands software development doesn't pick a programming language
to concentrate on. He's productive in anything you tell him to use, and he
doesn't particularly care either.

I think on this point at least you and I are totally in agreement.
It's good to understand Language X but it's much better to understand
programming.

···

On 6/5/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:

--
Giles Bowkett
http://www.gilesgoatboy.org

51

To clarify, code completion is a bit limited, but works. Refactoring appears to be non-existent in the current release, the I get by pretty well with Eclipse's search and replace features.
-Mat

···

On Jun 6, 2006, at 1:54 PM, James Britt wrote:

Peter Ertl wrote:

It's similar to the complaint that Ruby does not have an IDE such as Eclipse; some Rubyists argue that there isn't one because there is no compelling need for it, as there is in Java.

www.radrails.org

I thought that was focused on Rails, and did not do automatic refactoring or code completion.

But if it works for general Ruby the same way as Eclipse works for Java, then that's quite slick.

52

Francis Cianfrocca wrote:

And to your point about programmers who deliver the goods: I've been
privileged at several times to have some of those magical crazy people
working for me who can deliver almost anything on almost any schedule.
And
although the sample set is small, those I have known all share this key
characteristic: the programming language DOESN'T MATTER. An individual
who
really understands software development doesn't pick a programming
language
to concentrate on. He's productive in anything you tell him to use,
and he
doesn't particularly care either.

When I was one of those "magical crazy people", the choices were fewer.
And almost invariably the magical crazy people programmed in assembly
language whenever they could. Hardware was expensive, compilers sucked,
machines were slow and had limited memory.

Because of changing economics, programming language may not matter as
much as it used to, but I think today's magical crazy people probably,
if they had their druthers, would program in ... (pregnant pause) ... C.
At least the compilers don't suck any more. :slight_smile:

···

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

53

Then someone should post a bounty for those drivers. In open source,
people implement what they need or what others are willing to pay them
for.

That, however, isn't a Ruby problem. It's a Rails problem.

-austin

···

On 6/5/06, ReggW <me@yourhome.com> wrote:

Here is a list of Drivers that people *need* for Rails...
http://wiki.rubyonrails.com/rails/pages/DatabaseDrivers

Approx. 90% of these would go away if they implemented ODBC.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

54

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, X=IBM).

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.

···

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.

55

Because I respect you, I'm going to respond as if you're serious.

It may be that you haven't ever worked with the kind of person I'm talking
about. He's the one programmer in a hundred who can do the work of the other
ninety-nine. I probably wouldn't waste him on a Cobol or a VB project. I'd
certainly consider him for Lisp. If I really had to code something in
Brainfuck and had made the decision rationally, then I'd certainly consider
him for that as well. (But wouldn't assembly language be better than BF for
almost any purpose other than demonstrating BF's specialness? And yes, I
would definitely use my superstar on an assembler project.)

I can't speak to your experience. But in mine, the very best of the best are
seduced by the inherent interest of the project, the opportunity to work
with people they respect (and it's HARD to win their respect), and above all
the chance to learn something new. The choice of programming language is
something they care about (I exaggerated upthread), but it's far from the
top of their list.

I asked one of my favorite guys to do a Ruby project three years ago. He had
never heard of Ruby but he took the project. Just as I expected, he was
right up to speed on Ruby almost immediately (essentially in one night) and
did more production-quality work in less time than all of the experienced
Rubyists on the project. With these guys, it's like their brains are
orthogonal to language issues.

Interesting. I'm always stuck by people who don't get think that

everything is fair game for questioning.

Here, you made two different points ("get" vs "think") as you decided midway
through writing the sentence to pull your punch ;-). I get (and I even
think) that everything is fair game for questioning. But James, think twice
about this: not everything is WORTH questioning.

···

On 6/5/06, James Britt <james_b@neurogami.com> wrote:

Francis Cianfrocca wrote:

> An individual who
> really understands software development doesn't pick a programming
language
> to concentrate on. He's productive in anything you tell him to use, and
he
> doesn't particularly care either.
>

Wow. That's surreal.

I have a hard time imagining someone who really understands software
development and yet doesn't care if someone dictates what language is
used. And yet can be (equally, one hopes) productive whether working
with VB, Lisp, Cobol, or Brainfuck.

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

--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine

56

Francis Cianfrocca wrote:

> An individual who
> really understands software development doesn't pick a programming language
> to concentrate on. He's productive in anything you tell him to use, and he
> doesn't particularly care either.
>

Wow. That's surreal.

I have a hard time imagining someone who really understands software
development and yet doesn't care if someone dictates what language is
used. And yet can be (equally, one hopes) productive whether working
with VB, Lisp, Cobol, or Brainfuck.

Glad I wasn't the only one who was absolutely stunned by that
statement. You expressed what I was thinking far better than I could
have.

Francis, if you truly have people that can produce quality code in the
language of your choosing (at random), well, umm, pay them extremely
well, lock them in a room, and never reveal their names, or they won't
be yours for long.

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

Indeed.

···

On 6/5/06, James Britt <james_b@neurogami.com> wrote:

--
James Britt

"Take eloquence and wring its neck."
  - Paul Verlaine

--
Bill Guindon (aka aGorilla)
The best answer to most questions is "it depends".

57

Giles: this is a Ruby-language forum, and the title of the thread is "I love
Ruby but is its future bright?" As interesting as your comments are about
business, I don't want to stray too far offtopic.

I'd like Ruby to become as good a language and language-implementation(s) as
possible. And to do so quickly would be a big plus. One way to do that is to
get more smart, well-motivated people to work on the language. And one way
to do that is to expand the number of people who use the language. If this
happens, then the big question will be: can Ruby survive success? And that
will depend on the leadership skills of Matz and the more important people
in the community.

If it doesn't happen, then Ruby will continue to be what it is today: a
lovely language with applicability to a reasonably interesting class of
problems.

To your questions about Rails: we sometimes use pieces of ActiveRecord. The
rest of our stuff is done in pure Ruby, using a framework very similar to
Rails without most of the edge features. It usually profiles at least ten
times faster than Rails (often twenty times). The web servers are written in
a mix of Ruby and C++. Made sense for us because we've been writing
high-performance servers for distributed apps for a lot of years so we had a
lot of good knowledge to draw on.

···

<gilesb@gmail.com> wrote:

On 6/5/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> I used to make my living selling my
> programming skills but now I'm mostly a buyer of the programming skills
of
> others. I guess that makes me a crappy business person.)

Well, I would have no way to assess that as either true or false, but
certainly that wasn't what I meant.

It does sound, however, as if you have some crappy business people for
customers. (No offense, so do I!)

> What I meant was that Python has achieved a degree of respectability in
> corporate environments that Ruby hasn't yet. And this doesn't happen by
> itself, and it certainly doesn't happen just because a language is
> particularly well-done or particularly nice for programmers to use. I
think
> you may be underestimating the degree to which technology choices in
large
> organizations are driven by the need to reduce the perception of risk.

No, I am completely aware of that, I'm just firmly of the opinion that
working for large corporations is detrimental for the sharpness of
programming skills.

> It's
> not universally true that a programmer who "delivers the goods" will get
to
> pick his technology.

True, but although it isn't **universally** true, it is true for a
number of excellent programmers who also make very good business and
marketing decisions. Other things are true for other programmers, but
I don't care, because those other programmers aren't my role models.
I'm firmly of the opinion that the answers you find are much less
significant than the questions you ask. Consequently I'm only willing
to ask the questions that will make me an excellent programmer.

> But the question gets asked here time and again: who cares if people in
> corporations don't use Ruby, as long as I can use it on my own projects?

Hold on -- I have herad that question, but you're assuming everybody
only works on large corporate projects. In my case, I don't want to
work for large corporations, but I do want to be paid to use Ruby.

> Entirely valid. But if you really like using a language, wouldn't you
want
> to use at work as well as at play? And to get that kind of acceptance
for
> Ruby will take some serious advocacy. With the rise of Rails, that may
be
> starting to happen, but it's too soon to tell.

The ability to use Rails is a major priority for selecting my next
job. But it only takes serious advocacy if you're choosing customers
who have prioritized minimizing risk over maximizing results. If
you're only even willing to consider customers who prioritize
maximizing results over minimizing risks, the advocacy effort becomes
nonexistent.

> Because I'm a businessperson, I'm always struck that people would
question
> the value of achieving greater acceptance for anything.

Fair enough, you're thinking of marketing, obviously increased demand
can be a good thing. But you have to realize the dangers of a
commodity-oriented model when you're running a service business. You
don't want to compete on price. (Chad Fowler's book "My Job Went To
India" explains why.)

> Different strokes
> for different folks, of course. But at some level, I have to think about
> protecting the investment that I make in people who learn Ruby while
working
> on my projects, which I've done several times in the three-plus years
I've
> been shipping commercial software written in Ruby. Although I personally
> love programming in Ruby and do it whenever I can, your points really
throw
> the larger business questions into relief.
>
> (For the little that it's worth, we shipped a pair of apps in Rails, and
> coudn't get past the performance issues, so we now ship web apps in
> handwritten Ruby with our own handwritten web servers.)

Using parts of Rails, or entirely handwritten?

Are the web servers in Ruby?

> And to your point about programmers who deliver the goods: I've been
> privileged at several times to have some of those magical crazy people
> working for me who can deliver almost anything on almost any schedule.
And
> although the sample set is small, those I have known all share this key
> characteristic: the programming language DOESN'T MATTER. An individual
who
> really understands software development doesn't pick a programming
language
> to concentrate on. He's productive in anything you tell him to use, and
he
> doesn't particularly care either.

I think on this point at least you and I are totally in agreement.
It's good to understand Language X but it's much better to understand
programming.

--
Giles Bowkett
http://www.gilesgoatboy.org

58

Mat Schaffer wrote:

Java, then that's quite slick.

To clarify, code completion is a bit limited, but works. Refactoring
appears to be non-existent in the current release, the I get by
pretty well with Eclipse's search and replace features.
-Mat

I can't get any code completion to work with RadRails.

This is the ONLY thing that RadRails really needs, and it would be the
best Ruby/Rails IDE available.

I think JEdit has the best code completion, but it lacks the rails
features of RadRails and the ProjectViewer plug-in doesn't bring your
entire project directory structure from the hard drive.

Anyway, RadRails is almost the best IDE.

···

On Jun 6, 2006, at 1:54 PM, James Britt wrote:

--
Posted via http://www.ruby-forum.com/\.

59

I would happily do a project in assembly if there was a good reason to. I would hatefully do a project in assembly if Ruby was a 100x better choice.

James is right that we should care which language we use. Using the best language for the job (or a reasonable, competitive choice) is very important. Making your star code everything in Java would considerably lower his morale and productivity.

Francis is right that a star does good projects, and what tools he is using is a side issue, because he can easily pick up any tools ... as long as he wants to. If the tool is actually an appropriate choice, and the project is interesting, the star will want to.

-- Elliot Temple

···

On 6/5/06, James Britt <james_b@neurogami.com> wrote:

Wow. That's surreal.

I have a hard time imagining someone who really understands software
development and yet doesn't care if someone dictates what language is
used. And yet can be (equally, one hopes) productive whether working
with VB, Lisp, Cobol, or Brainfuck.

On Jun 5, 2006, at 8:10 PM, Francis Cianfrocca wrote:

It may be that you haven't ever worked with the kind of person I'm talking
about. He's the one programmer in a hundred who can do the work of the other
ninety-nine. I probably wouldn't waste him on a Cobol or a VB project. I'd
certainly consider him for Lisp. If I really had to code something in
Brainfuck and had made the decision rationally, then I'd certainly consider
him for that as well. (But wouldn't assembly language be better than BF for
almost any purpose other than demonstrating BF's specialness? And yes, I
would definitely use my superstar on an assembler project.)

I can't speak to your experience. But in mine, the very best of the best are
seduced by the inherent interest of the project, the opportunity to work
with people they respect (and it's HARD to win their respect), and above all
the chance to learn something new. The choice of programming language is
something they care about (I exaggerated upthread), but it's far from the
top of their list.

I asked one of my favorite guys to do a Ruby project three years ago. He had
never heard of Ruby but he took the project. Just as I expected, he was
right up to speed on Ruby almost immediately (essentially in one night) and
did more production-quality work in less time than all of the experienced
Rubyists on the project. With these guys, it's like their brains are
orthogonal to language issues.

60

Francis Cianfrocca wrote:

Because I respect you, I'm going to respond as if you're serious.

It may be that you haven't ever worked with the kind of person I'm
talking
about. He's the one programmer in a hundred who can do the work of the
other
ninety-nine. I probably wouldn't waste him on a Cobol or a VB project.
I'd
certainly consider him for Lisp. If I really had to code something in
Brainfuck and had made the decision rationally, then I'd certainly
consider
him for that as well. (But wouldn't assembly language be better than
BF for
almost any purpose other than demonstrating BF's specialness? And yes, I
would definitely use my superstar on an assembler project.)

I can't speak to your experience. But in mine, the very best of the
best are
seduced by the inherent interest of the project, the opportunity to work
with people they respect (and it's HARD to win their respect), and
above all
the chance to learn something new. The choice of programming language is
something they care about (I exaggerated upthread), but it's far from the
top of their list.

I asked one of my favorite guys to do a Ruby project three years ago.
He had
never heard of Ruby but he took the project. Just as I expected, he was
right up to speed on Ruby almost immediately (essentially in one
night) and
did more production-quality work in less time than all of the experienced
Rubyists on the project. With these guys, it's like their brains are
orthogonal to language issues.

I was that sort of programmer a few decades ago. There are only so many
opportunities for "them" (formerly "us"). It took me something like 30
years to outgrow assembly language. :slight_smile: IIRC I wrote my last line of
assembly code (well, Forth for the 80186) in the early 1990s. I went
directly from microcode to Perl :).

At this point, I'd learn Ruby if there was someone else around at work
who was interested in it. I don't suspect that will happen any time
soon. It was tough enough to find another person interested in R, a
language ideally suited to some of the tougher problems I work on.

···

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com