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

Ruby
21

Austin Z. wrote:

ReggW wrote:

Look at Kylix and C++Builder X, they fit the bill when they where
released, but now people are scrambling to find a replacement (or a
new job).

Actually, neither was a problem, nor are they really problems. Just
because a tool falls out of favour does not mean that the tool was bad
in the first place. Java will fall out of favour, just as COBOL has.
That’s inevitable. The trick is to be an agile enough to recognise when
something new has to be done.

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

  1. No native OS threads.

This is less a problem than you might imagine. However, it will be
addressed with YARV/Rite. (In fact, Ko1-san is possibly planning on
making it possible to have Ruby’s green threads run on top of OS
threads. Last year’s YARV presentation suggested that it might even be
possible in the future for a green thread to migrate across OS threads
for performance reasons.)

This is a problem that I’m experincing now.
I’m “trying” to convert an existing app that uses thread to Ruby.

This brings up another issue that I have (and I suspect many other) is
that I’m always seeing these new names being used. Like YARV/Rite but
none of this is anywhere on the rubyonrails.org website.

The website doesn’t inform you of what is being worked on for the next
release, actually, the website doesn’t inform a person about much of
anything that is currently going on with Ruby.

  1. No generic database drivers built into Rails for databases other
    than the top 3 and open-source databases. (Makes it impossible to
    migrate to RoR if you use a different database)

This is more a matter of applicability; if most folks don’t need it,
they won’t create it. Maybe it would be worth talking to the vendor
about this.

Talk to what vendor?
My database vendor?
And asked them what??

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

  1. Slow performance.

This is often claimed, but never conclusively proven in a way that is
generally applicable and generally applicable to the language. Yes, Ruby
has points where it is slow. But performance is not an absolute
measurement; it is a relative measurement. There are definite places to
get improvements from the language, and many of these will be
addressed by YARV (which I’ll finally be able to play with!).

I wish I knew what this YARV is…it sounds like the magic bullet I’ve
been looking for. I’ll do some research on it later.

Thanks

22

On 6/5/06, ReggW [email protected] 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?

  1. No native OS threads.
    This is less a problem than you might imagine. However, it will be
    addressed with YARV/Rite. (In fact, Ko1-san is possibly planning on
    making it possible to have Ruby’s green threads run on top of OS
    threads. Last year’s YARV presentation suggested that it might even
    be possible in the future for a green thread to migrate across OS
    threads for performance reasons.)
    This is a problem that I’m experincing now. I’m “trying” to convert an
    existing app that uses thread to Ruby.

Um. Why does your existing app use threads, and does the assumption that
moved you to threads still apply, or may multiple processes with some
form of IPC be better? I wouldn’t simply try to do a functional
conversion of an application from any language to Ruby. I’d take it as
an opportunity to reimplement based on what I’ve learned about how the
application is actually used.

This brings up another issue that I have (and I suspect many other) is
that I’m always seeing these new names being used. Like YARV/Rite but
none of this is anywhere on the rubyonrails.org website.

Nor would it be. Rubyonrails.org is about Rails, not Ruby. Look at
ruby-lang.org and rubygarden.org and the mailing list history[1].
The Rails website will never be about Ruby in general.

The website doesn’t inform you of what is being worked on for the next
release, actually, the website doesn’t inform a person about much of
anything that is currently going on with Ruby.

This is correct. This is because it’s the Rails website, not the Ruby
website. The Ruby website needs a bit more content up-to-date, but I
hope that will change when the new visuals come on-line, too. If you
REALLY want to know what’s happening with Ruby’s future, join
[email protected] and watch rcrchive.org.

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.

  1. Slow performance.
    This is often claimed, but never conclusively proven in a way that is
    generally applicable and generally applicable to the language. Yes,
    Ruby has points where it is slow. But performance is not an absolute
    measurement; it is a relative measurement. There are definite places
    to get improvements from the language, and many of these will be
    addressed by YARV (which I’ll finally be able to play with!).
    I wish I knew what this YARV is…it sounds like the magic bullet I’ve
    been looking for. I’ll do some research on it later.

There are no magic bullets. YARV is predicated on Ruby 1.9 and there are
syntactical changes in Ruby 1.9 (which is the development bed for Ruby
2.0).

-austin
[1] You may think you’re posting to a web forum. You’re not. You’re
posting to a mailing list ([email protected]) over a web forum
interface. You’re dealing with something that has a much longer
history than Rails.

23

On 6/5/06, ReggW [email protected] wrote:

This brings up another issue that I have (and I suspect many other) is
that I’m always seeing these new names being used. Like YARV/Rite but
none of this is anywhere on the rubyonrails.org website.

The website doesn’t inform you of what is being worked on for the next
release, actually, the website doesn’t inform a person about much of
anything that is currently going on with Ruby.

That’s because ror.org is for the Ruby on Rails framework, not an
informative site for the Ruby language itself. For that, check out
http://www.ruby-lang.org

I wish I knew what this YARV is…it sounds like the magic bullet I’ve
been looking for. I’ll do some research on it later.

http://www.atdot.net/yarv/

24

Many capable Rubyists that I know are of the opinion that nothing
matters but the joy of programming Ruby. True enough as far as
it goes, and that alone will drive significant acceptance of the
language. But not as fast or as far as I would like. I realize I’m
throwing down a gauntlet here, but the Pythonists have been
better at this than we have so far.

Not sure what “this” is. Corporate acceptance?

“This” appears to be resume-padding usefulness.

Two corrections: first, it’s Pythonistas, not Pythonists. I don’t know
why, but it is. Second, my experience of the two communities is that
while these statements might be perceived as a gauntlet being thrown
down in the Python community, that perception seems much less likely
in the Ruby community.

Anyway – to answer your main question – I have a very skeptical,
cynical side which believes that the real question here is “how much
padding will my resume gain if I learn Ruby?” That’s such a bad
question. The real benefit in learning a new language is not the
ability to get better jobs but the ability to write better programs.
If you’re learning a language simply because it has a bright future,
you’re investing your effort in the language’s future rather than your
own.

Two of the best languages to learn are Smalltalk and Lisp. Neither one
of these languages has virtually ANY future, but if you learn them,
you will become a better programmer, and YOU will have a brighter
future, because your work will improve. Invest time and energy in YOUR
future. I’m new to Ruby too but one thing I really like about it is
that I’m learning a LOT more from my beginner steps in Ruby than I
learnt from my beginner steps in Python (or indeed at almost any stage
in coding Java).

DHH was able to write in Ruby, even though at the time the language
had no mainstream acceptance. Avi Bryant has an entire company running
on Smalltalk, even though that language has no mainstream acceptance.
Paul Graham sold a company for $40 million after writing every line of
its code in Common Lisp, even though that language had no mainstream
acceptance either (and probably never will). Coding in a language
because it has mainstream acceptance is putting the cart before the
horse.

Good programmers produce business results. Business people don’t
understand what the difference is between languages in the first
place. They don’t care – in fact since they can’t even tell languages
apart in any meaningful sense, they don’t even have the ability to
care. The crappy ones say various things as if they really cared but
the truth is they’re just BSing to protect themselves in various
ridiculous corporate environments – and the truth is you don’t want
anything to do with crappy business people anyway. If you produce the
business results, you can use any language you want, and if you don’t
produce the business results, you’re just screwing around – in which
case, again, you might as well use any language you want.

Long story short, focus on your SKILL. Focusing on whichever trend is
most popular with corporations at any particular moment is a recipe
for turning yourself into a bad programmer. Don’t believe me? Learn
Java!

25

On Jun 5, 2006, at 10:30 AM, Giles B. 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:

(Opinions vary)

The reason these languages are good to learn is they have important
knowledge in them. We want knowledge in our future, don’t we?

Elliot

26

Tom M. wrote:

I’m still new to the language myself, but I’m comming at it as an
enterprise
web developer (Java/.Net).

The killer app for Ruby, for me at least, is Rails. Rails has got so much
right with regards web development it makes you question how Sun got it
quite so wrong… or at least not as good.

Sun had a different opinion on how to do Web development.

–
James B.

“I often work by avoidance.”

  • Brian Eno
27

On Monday 05 June 2006 11:42, Elliot T. wrote:

On Jun 5, 2006, at 10:30 AM, Giles B. 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:
^
(Maybe so, but you’re missing an opening parenthesis… :wink:

28

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

On Jun 5, 2006, at 10:30 AM, Giles B. 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:

And always will be… :slight_smile:

29

On Jun 5, 2006, at 17:50, James B. wrote:

Sun had a different opinion on how to do Web development.
https://glassfish.dev.java.net/

https://phobos.dev.java.net/

There’s always something new around the corner, and it always builds
on past experience. Don’t fool yourself into thinking that there are
constant revolutionary changes and “killer apps” for any language.
Java was meant to be its own “killer app” - whither now the Virtual
Machine, making all platforms equal? They’re running on servers,
which is almost the exact opposite of the original view of Java.

As for “what language should I use?” I think there are few more
informative essays that one could read than this one by Paul Graham;
it’s Lisp-centric in its particulars, but many of the points made can
apply to Ruby as well (even some of the Lispier ones, at a stretch):

“Revenge of the Nerds”
http://www.paulgraham.com/icad.html

Other good ones are:

“Being Popular” - very interesting in light of Ruby’s recent surge in
popularity.
http://www.paulgraham.com/popular.html

“LFM and LFSP” - Expands to “Languages For the Masses and Languages
For Smart People”, some speculation on what makes languages “fun.”
http://www.paulgraham.com/vanlfsp.html

matthew smillie.

30

On 6/5/06, ReggW [email protected] wrote:

Here is a list of Drivers that people need for Rails…
Peak Obsession

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

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

31

Austin Z. wrote:

On 6/5/06, ReggW [email protected] 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.

32

Hector wrote:

I’m at a point where I’m asking myself if it is worth the trouble for me
to learn Ruby…

My answer would be yes, not because it is the best language
that will /ever/ be written, but because of the way the
features it has implemented provide an almost unlimited
capacity for future scaling.

That capacity derives from Ruby’s ability for
/language extensions/. I wrote at length on that subject
here: http://www.treelight.com/software/ruby/RubyRocks.html

On the other hand, I agree that documentation is an issue.
The situation is getting better, though. (Thank goodness for
Wiki pages!) And there are several great books.

Too, I really miss the kinds of APIs that are generated
for Java, as well as IDEs that interact with them so
nicely.

So my take at the moment is that it can take several hours
to figure out how to do something, but when I finally do,
the solution is small, clean, and elegant.

So Ruby is where Java was in the mid-90’s, but without
the huge investment required to market it, document it,
and make technology additions.

But it is hecka fun…
:_)

33

Both you and someone else asked what I meant by saying that the Python
community is ahead of us in some important respects. It didn’t haven’t
even
the slightest thing to do with resumes. I’m not sure if you’re applying
your
skepticism and cynicism to your case. You’re not applying it to mine. (I
haven’t written a resume in 15 years. 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.)

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.
It’s
not universally true that a programmer who “delivers the goods” will get
to
pick his technology.

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.

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.

34

Somebody mentioned that if you want to do any serious application
programming you should look elsewhere. I’ve also noticed that while
there are several attempts out there at application frameworks based on
Ruby, there don’t seem to be any that beget any enthusiasm. Discussions
of the existing ones are usually of the form “Yeah this one wasn’t too
bad, and the other one was almost adequate”.

Since Rails is considered by many to be the “killer app” for Ruby, why
doesn’t there seem to be a contender in the non-web-app type application
framework genre for Ruby? Is there something about the language that
makes it an inappropriate choice for “real” application work, or is it
more just a matter of coincidence that the right group of people hasn’t
done something as stellar as Rails in that space yet?

I, for one, would fall in love with Ruby all over again if there was a
truly cross-platform native application framework even half as brilliant
as Rails. You could call it “Ruby on 'Roids”.

thanks,
jp

35

Francis C. 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 B.

“Take eloquence and wring its neck.”

  • Paul Verlaine
36

Francis C. 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 !!

37

On Jun 6, 2006, at 2:42, James B. 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, 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.

38

On 6/5/06, James B. [email protected] 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 C. wrote:

than BF for
the chance to learn something new. The choice of programming
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 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 T.

39

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.

40

On 6/5/06, James B. [email protected] wrote:

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.