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

[Austin_Ziegler5 (Austin Ziegler)]

Phil Tomson wrote:

Actually, you should never get complacent about a language's 'lasting
power'. Always be ready to learn a new one.

I don't agree with this statement.

I'm not sure why you don't agree, because your example (Kylix &
C++Builder) very *much* agrees with what Phil said.

You should look very hard at a language (just like the owner of this
thread is doing), to make sure you are making the right choice.

If you're planning on making it your primary programming language, sure.
I don't get to spend a lot of time programming in Ruby with my current
job, but my Ruby has definitely informed and improved my C++ (and
congealed my hate of that language).

[...]

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.

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

2. To get the fully benefit from Rails, your database has to have a
specific naming convention. (Makes it impossible to migrate to RoR
from something else).

This isn't a Ruby problem. It is, however, still possible to migrate.
You will have to do a little more work, but you *can* override the
defaults for ActiveRecord and once overridden, all of the rest of the
benefits still apply.

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

4. 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!).

5. Kind of a hack job to get it to work with Apache. (But this could
also be my lack of knowledge)

I can't answer this, but I suspect that it's a knowledge thing.

-austin

···

On 6/5/06, ReggW <me@yourhome.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

[Phil_Tomson1 (Phil Tomson)]

Phil Tomson wrote:
>
> Actually, you should never get complacent about a language's 'lasting
> power'. Always be ready to learn a new one.
>
I don't agree with this statement.

You should look very hard at a language (just like the owner of this
thread is doing), to make sure you are making the right choice.

It may be years before you know if you've made the 'right' choice.

If you do happen to choose 'wrong' (whatever that might mean for you)
you can always go back and learn another language(s). It's not like
you're locked into some binding contract or something.

Many developers, Project Managers, etc., have lost thier jobs because of
making the wrong development choice.

Perhaps it's not because they made the 'wrong choice' but more because
they weren't willing to learn new things?

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

Those are tools, not languages. If they know C++ well, they'll be fine.

Phil

···

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

[James_Britt4 (James Britt)]

Tom Marsh 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 Britt

"I often work by avoidance."
- Brian Eno

[James_Britt4 (James Britt)]

Jeff Pritchard wrote:

...

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?

Perhaps there are languages that, by their nature, require an application framework exist before one can expect to build certain kinds of applications. And there are there other languages where this is not needed; they make it easy enough to just grow your own application or in-house set of tools; they language helps avoid exploding complexity.

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.

···

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

[Elliot_Temple]

there are things that make coding more or less fun. maybe all coding is more fun than flipping burgers. but not all coding is equally fun. here are a few thoughts:

if you were required to use copy/paste as a replacement for methods, that would get annoying quickly (if the methods take arguments, just edit the paste by hand each time to use the right value

ultimately, any technique with unnecessary repetition can get frustrating when you know better ways to accomplish the same task.

ruby does a good job of helping us avoid repetition. it's always possible in other languages (at least if you count code generators). but in ruby it's often convenient. and if you're being paid to do something, you have to do it reasonably fast, so you can't write a code generator to avoid a little copy/pasting.

also, a lot of us aren't perfect. so we'd like to avoid repetition, but don't always know how to, or notice the repetition. ruby helps us notice it, and avoid it. sometimes ruby helps us avoid it without even noticing anything has happened. this could increase the subjective fun factor of ruby, because we find ourselves writing better, DRYer code.

similarly, by being higher level than some languages, ruby sometimes helps us to write complex, interesting algorithms.

ruby is prettier and less verbose than some languages. hitting extra keys on the keyboard is a form of needless work/repetition. pretty and elegant code seems fun to me.

if we can still read our code a month later, maybe that's fun. if we can read our code to our girlfriend because it's so much like English, maybe that's fun.

-- Elliot Temple

Curiosity Blog – Elliot Temple

···

On Jun 9, 2006, at 8:10 PM, M. Edward (Ed) Borasky wrote:

Oh, yeah ... one more thing. This may be the wrong thread to bring this
up, but it's certainly the right *forum*. I'm tired of hearing "Ruby
programming is fun, and programming in other languages isn't." I've
programmed in macro assembler, Fortran, C, Lisp, Pascal, Forth, Ada,
Perl, Java, Awk, R, Neliac, APL and even some microcode. It's *all* been
fun! Even the microcode ... even the Neliac.

Then again, I've never programmed in C++ or worked on a project as a
junior member of a 1500-person team.

[Tanner_Burson]

> 1. No native OS threads.

I hear this argument a lot. I do web development, so I rarely worry
about threads at all. What's the problem here that it makes so many
people's lists?

From a web perspective it even has the potential for performance issues.
Because there are no native threads, its very easy for a system call (file
or socket handling most commonly) to block the entire Ruby process, not just
the current ruby thread. Thanks to the ease of IPC in Ruby it can be less
of an issue, but is definitely something that potentially affects many
people's views of ruby.

2. To get the fully benefit from Rails, your database has to have a
> specific naming convention. (Makes it impossible to migrate to RoR
> from
> something else).

You can configure ActiveRecord to a certain extent. It sounds like
you might want to investigate it more before saying "you have to".
You could also use rails w/o ActiveRecord if you really wanted to.

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

I think you're wrong here. I'm seeing stuff in the rails wiki for
Oracle, SQL server, Sybase...

> 4. Slow performance.

"Fast enough" seems to be the going mantra.

> 5. Kind of a hack job to get it to work with Apache. (But this could
> also be my lack of knowledge)

I haven't had a lot of luck here either.

Correction, getting RAILS to work with Apache is a pain. While pure CGI or
mod_ruby may have performance issues in many cases, it is far from difficult
to set up. But given the size and complexity of the Rails environment it
has significant performance requirements, that go beyond the ability to use
CGI or mod_ruby, but that isn't entirely the failing of Ruby.

···

On 6/5/06, Mat Schaffer <schapht@gmail.com> wrote:

On Jun 5, 2006, at 11:22 AM, ReggW wrote:

--
===Tanner Burson===
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...

[ReggW]

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

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

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

···

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

[Giles_Bowkett]

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!

···

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

[Matthew_Smillie]

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.

···

On Jun 5, 2006, at 17:50, James Britt wrote:

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

[Francis_Cianfrocca]

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.

···

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

Jeff Pritchard wrote:
> ...

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

Perhaps there are languages that, by their nature, require an
application framework exist before one can expect to build certain kinds
of applications. And there are there other languages where this is not
needed; they make it easy enough to just grow your own application or
in-house set of tools; they language helps avoid exploding complexity.

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.

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

[Pete1 (Pete)]

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

···

-------- Original-Nachricht --------
Datum: Wed, 7 Jun 2006 01:22:16 +0900
Von: James Britt <james_b@neurogami.com>
An: ruby-talk@ruby-lang.org
Betreff: Re: I love Ruby - But how bright is Ruby\'s Future?

Jeff Pritchard wrote:
> ...

> 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?
>
Perhaps there are languages that, by their nature, require an
application framework exist before one can expect to build certain kinds
of applications. And there are there other languages where this is not
needed; they make it easy enough to just grow your own application or
in-house set of tools; they language helps avoid exploding complexity.

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.

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

[M_Edward_Ed_Borasky1 (M. Edward (Ed) Borasky)]

Phil Tomson wrote:

···

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

Phil Tomson wrote:
>
> Actually, you should never get complacent about a language's 'lasting
> power'. Always be ready to learn a new one.
>
I don't agree with this statement.

You should look very hard at a language (just like the owner of this
thread is doing), to make sure you are making the right choice.

It may be years before you know if you've made the 'right' choice.

If you do happen to choose 'wrong' (whatever that might mean for you)
you can always go back and learn another language(s). It's not like
you're locked into some binding contract or something.

I've lost count of how many times I made the wrong choice of language. I
don't regret the learning I've taken from macro assembler, Lisp, APL,
Forth or Java. But I made money programming in Fortran, Perl and R. So ...

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

[M_Edward_Ed_Borasky1 (M. Edward (Ed) Borasky)]

Elliot Temple wrote:

ultimately, any technique with unnecessary repetition can get
frustrating when you know better ways to accomplish the same task.

ruby does a good job of helping us avoid repetition. it's always
possible in other languages (at least if you count code generators).
but in ruby it's often convenient. and if you're being paid to do
something, you have to do it reasonably fast, so you can't write a
code generator to avoid a little copy/pasting.

also, a lot of us aren't perfect. so we'd like to avoid repetition,
but don't always know how to, or notice the repetition. ruby helps us
notice it, and avoid it. sometimes ruby helps us avoid it without even
noticing anything has happened. this could increase the subjective fun
factor of ruby, because we find ourselves writing better, DRYer code.

*Somebody* has to do the tedious jobs. Our preference as programmers is
to automate them, of course. I'd like to semi-challenge a couple of your
frames, though:

1. "If you're being paid to do something, you have to do it reasonably
fast." Sure, we have to meet deadlines, but if you can't ask for more
time to get correct results, I don't care what language you're using ...
fun just disappeared by definition.

2. You can usually write a code generator very quickly in almost any
language. Regular expressions make it easier; so do compiler-compilers
if you know how to use them.

similarly, by being higher level than some languages, ruby sometimes
helps us to write complex, interesting algorithms.

I think most of today's languages allow recursion, iteration, control
flow, and some form of object-oriented design, although the details of
the object paradigms are widely different in Ruby and, say, R or CLOS.
What I see as Ruby's main advantages are

1. Scripting language features: interpreted, dynamic typing
2. "Conventional" object design paradigms: classes, methods, message-passing
3. Built-in data structuring and regular expression handling.

Perl has 1 and 3 but falls short on 2. Objects were tacked on to Perl
and it shows. Java has 2 and 3 but falls short on 1. R has a little of
1, an unconventional but highly useful (for its domain) set of object
paradigms, and some of 3. C has none of these and C++ only has 2.

ruby is prettier and less verbose than some languages. hitting extra
keys on the keyboard is a form of needless work/repetition. pretty and
elegant code seems fun to me.

There are different kinds of elegance. I find elegance in Forth's
threaded inner interpreter, Lisp's macros, selectors, constructors and
predicates, APL's array orientation, Perl's arrays and hashes, and
*everybody's* garbage collection. And, of course, given how long I've
been programming, I find immense joy in the simple fact that I now have
both upper and lower case letters at my disposal.

if we can still read our code a month later, maybe that's fun. if we
can read our code to our girlfriend because it's so much like English,
maybe that's fun.

OK ... again it seems that the programming practices and styles are what
makes programming fun or not fun, not the language.

···

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

[Ola_Bini3 (Ola Bini)]

Correction, getting RAILS to work with Apache is a pain. While
pure CGI or
mod_ruby may have performance issues in many cases, it is far from
difficultto set up. But given the size and complexity of the Rails
environment it
has significant performance requirements, that go beyond the
ability to use
CGI or mod_ruby, but that isn't entirely the failing of Ruby.

Hi

I've gotten Rails to work with Apache and FastCGI _VERY_ much without
pain. Getting Tomcat to play with Apache is much harder in my opinion.

/O

[Francis_Cianfrocca]

Because there are no native threads, its very easy for a system call

(file
or socket handling most commonly) to block the entire Ruby process, not just
the current ruby thread.
<<<<<<<<<<<<

Try it. You'll find that your statement is false. There are a lot of reasons
why one might want native-thread support in Ruby but not blocking a whole
process on a file or socket i/o isn't one of them.

[Pat_Maddox1 (Pat Maddox)]

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/

···

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

[Austin_Ziegler5 (Austin Ziegler)]

Austin Ziegler 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).

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
ruby-core@ruby-lang.org and watch rcrchive.org.

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

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.

4. 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 (ruby-talk@ruby-lang.org) over a web forum
  interface. You're dealing with something that has a much longer
  history than Rails.

···

On 6/5/06, ReggW <me@yourhome.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

[Elliot_Temple]

Lisp is *the* future

(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

···

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

[Francis_Cianfrocca]

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.

···

On 6/5/06, Giles Bowkett <gilesb@gmail.com> wrote:

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

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

[Dick_Davies]

Worth pointing out that this is only an issue if you are using a multithreaded
webserver. It's not an issue with fastcgi dispatchers, as a blocked thread only
blocks one dispatcher.

···

On 05/06/06, Tanner Burson <tanner.burson@gmail.com> wrote:

On 6/5/06, Mat Schaffer <schapht@gmail.com> wrote:
>
> On Jun 5, 2006, at 11:22 AM, ReggW wrote:
> > 1. No native OS threads.
>
> I hear this argument a lot. I do web development, so I rarely worry
> about threads at all. What's the problem here that it makes so many
> people's lists?

From a web perspective it even has the potential for performance issues.
Because there are no native threads, its very easy for a system call (file
or socket handling most commonly) to block the entire Ruby process, not just
the current ruby thread. Thanks to the ease of IPC in Ruby it can be less
of an issue, but is definitely something that potentially affects many
people's views of ruby.

--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/