Setting the Ruby
Aidan Mark
Whats Perl, he asked ? I explained. "It will never be heard of again" was
his comment.
Of course Perl far from dissapearing became the swiss army knife of
programming due mainly to its use for CGI programming in the early web. Sure
Perl had nice features like regular expression string processing, DBI
interfaces, and a growing module base but it was principally the CGI niche
that launched it out of the obscure programming language corral. Lincon
Stein's CGI.pm made it simply unbeatable in this area (until, sadly maybe,
PHP came along).
My question is therefore which niches do people predict will launch Ruby
into the mainstream?
Where will Ruby simply be indespensible and "competing" languages like
Python, Perl and Java simply not do?
Aidan
Rafael 'Dido' Sevilla
On Fri, Feb 08, 2002 at 06:04:55PM +0900, Aidan Mark wrote:
> My question is therefore which niches do people predict will launch Ruby
> into the mainstream?
>
The reason why languages like Python and Ruby seem to be gaining
popularity is largely due to dissatisfaction with Perl. Perl, for all
its virtues as the "swiss army chainsaw" of hackers, is a terrible
language to do programming in the large. The fact that Perl makes it
easy to do quick and dirty hacks winds up making any large program in it
very, very dirty really quickly. As someone who has had to maintain
a few large perl scripts with thousands of lines each, I have long
personal experience with this fact.
Both Ruby and Python have attempted to address these shortcomings in
their designs, both by having a clearer syntax and object oriented
system cleaner than Perl's. Python, IMHO, went a little too far in this
respect, with its baroque ideas about block structuring with whitespace,
which operates under the assumption that what's readable code for Guido
van Rossum is readable code for everyone. It also didn't go all the way
in its object oriented approach, making it a hybrid of a procedural and
an object oriented language.
Ruby has, on the other hand, taken a more pragmatic approach to cleaning
up syntax: by reducing the amount of unnecessary syntactic clutter, and
IMHO, this is a Good Thing(tm). Ruby also takes the object-oriented
paradigm to its logical conclusion and is an even purer OOP language
than Python.
We're presently starting to see these two languages eat into the niches
that Perl has traditionally filled. I think this is the beginning.
--
Rafael R. Sevilla <sevi...@team.ph.inter.net> +63(2) 8177746 ext. 8311
Programmer, Inter.Net Philippines +63(917) 4458925
http://dido.ph.inter.net/ OpenPGP Key ID: 0x5CDA17D8
Heute die Welt und Morgen das Sonnensystem!
Erik Bågfors
As Rafael wrote they are partly eating into perls niches but I also
think there is another important thing to think about.
Today computers are alot faster and with more memory then they were
1994. This makes languages like perl,python,ruby and even java and C#
better suited for large and complex tasks than they were in 1994 which
means that they can do alot more than run web pages.
I think the scripting languages will eat into the niches that java and
C# wants to own and I think they want to own the current c/c++-market.
Weather or not ruby will have a large piece of this is another question.
I hope so.
/Erik
--
Erik Bågfors | er...@bagfors.nu
Supporter of free software | GSM +46 733 279 273
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Phil Tomson
Aidan Mark <ahu...@DELETEgmx.net> wrote:
>
>Where will Ruby simply be indespensible and "competing" languages like
>Python, Perl and Java simply not do?
>
I did a search for Ruby on the perlmonks.org site a few weeks back and
found that over the last few months there have been several positive
mentions of Ruby there in the heart of Perldom. The one I liked best:
"Ruby is Perl's prettier younger sister". Perl refugees looking for a
much cleaner way for doing OO will continue to make up a big part of the
Ruby user base.
As far as Ruby niches go, I think we need to look in to creating modules
that would get Ruby widely installed. For example, what if we were to
come up with a killer version control system written in and
configurable with Ruby that would compete with and
be seen as a replacement for CVS? If it was good people would use it and
Ruby would get installed. How about the discussion about a 'make'
replacement that was big here a few months back? Same story, if we had a
viable make replacement that was Ruby based it would help spread Ruby.
Other niches/strengths:
* Testing - Ruby has a lot of unit testing resources. Could probably use
more 'black-box' functional testing tools.
* dRuby - its so much easier to use than the XML-RPC or SOAP schemes out
there (no http servers to set up) and it is probably also much more
bandwidth efficient (XML being verbose when compared to Ruby's Marshal format).
* Ruby Cocoa - seems to make Ruby a very attractive scripting language for
MacOSX. (perhaps it needs to be promoted more in the OSX community?)
* Webrick - I'm not too knowledgable in this area, but from what I've read
here it makes it a whole lot easier to set up http servers (servlets) than
Java (maybe someone can compare how it's done with Webrick and how it's
don in Java?)
Others?
Phil
Chris Gehlker
> * Ruby Cocoa - seems to make Ruby a very attractive scripting language for
> MacOSX. (perhaps it needs to be promoted more in the OSX community?)
I think two tools would make a Ruby Cocoa a killer scripting language for
MacOSX. Most important is a nice IDE that can read Dictionaries published by
other applications, especially the old school style. Whacking away with a
resource editor is just too much work for many simple scripting tasks. The
IDE could also make Ruby scripts double-click launchable.
This is definitely on my To Do list.
The other thing that would be nice is glue to the Cocoa DO model. Proxies
are even more bandwidth efficient that Ruby marshaling and easier to code
around.
--
When I was a boy I was told that anybody could become President. Now I'm
beginning to believe it. -Clarence Darrow, lawyer and author (1857-1938)
Pat Eyler
>
>
> > -----Original Message-----
> > From: Phil Tomson [mailto:pt...@shell1.aracnet.com]
> > Sent: Friday, February 08, 2002 8:26 PM
> > To: ruby-talk ML; undisclosed-recipients:
> > Subject: Re: Setting the Ruby
> >
> > ...
> > be seen as a replacement for CVS? If it was good people would use it and
> > Ruby would get installed. How about the discussion about a 'make'
> > replacement that was big here a few months back? Same story, if we had a
> > viable make replacement that was Ruby based it would help spread Ruby.
> >
People thinking about replacing CVS might want to go see www.regexps.com
and look at arch. I first saw this on the free software business mailing
list, and immediately thought that it should be rewritten in ruby instead
of sh, sed, and awk ...
People wanting to work on a make replacement might want to go see
sc-archive.codesourcery.com (the old Software Carpentry project).
If nothing else, these might have some thoughts worth stealing.
Other ideas might include:
better ruby-gnome support - I have visions of someday being able to use a
rubyWM that could be extended with new methods on the fly ...
a rubyshell - scsh with ruby instead of scheme
-pate
>
> I'm working on it (Rubuild), but so far, it has not "crystallized".
> Expect an alpha version by the end of the month (maybe :)
>
Christian Boos
> -----Original Message-----
> From: Phil Tomson [mailto:pt...@shell1.aracnet.com]
> Sent: Friday, February 08, 2002 8:26 PM
> To: ruby-talk ML; undisclosed-recipients:
> Subject: Re: Setting the Ruby
>
> ...
> be seen as a replacement for CVS? If it was good people would use it and
> Ruby would get installed. How about the discussion about a 'make'
> replacement that was big here a few months back? Same story, if we had a
> viable make replacement that was Ruby based it would help spread Ruby.
>
I'm working on it (Rubuild), but so far, it has not "crystallized".
Expect an alpha version by the end of the month (maybe :)
So far, the idea is to have 'BuildSet' objects that logically group some
root 'BuildNode' objects. A 'BuildNode' can have explicit dependencies
on other 'BuildNode' objects. Each 'BuildNode' knows how to rebuild itself,
using some 'Tool' object.
To effectively trigger a build, one gives a 'Configuration' object
to the 'make' method of a 'BuildSet'. The combination of the 'BuildSet'
info and of the 'Configuration' info enables the right 'Tool' instance
to be created.
Ok, that was a very sketchy description :). Basically the build files
will look like:
#######################################################
require 'rubuild/qt2' # triggers the require of the rest
include Rubuild
class Qt2Integration < BuildSet
attr_reader :qruby # so that it can be referenced from
# another build file elsewhere
def initialize
super "qt2/integration"
@qruby = Cplusplus::Library.new "qruby"
@qruby << "qruby.cpp" # the Library creates a
# Cplusplus::Source BuildNode
# for /\.cpp$/ dependencies
@qruby << Cplusplus::Qt2::Modifier.new # a tool modifier will change
# the settings for the tools
# used (here Cplusplus::Compiler
# and Cplusplus::Linker)
self << @qruby
end
end
if $0 == __FILE__
local = Qt2Integration.new
local.make # default config is used,
# object files will be created under
# ENV['RUBUILD_POOL']/default/qt2/integration
local.make (Configuration.new :debug => true)
# will build in 'debug' mode under
# ENV['RUBUILD_POOL']/debug/qt2/integration
end
####################################
(see also http://www.bct-portal.com/opensource/ruby/rubuild/index.html,
but the site is also quite 'alpha', and there is no package to download
right now).
-- Christian