In your opinion....

[Daniel Lewis]

In your opinion(s)....

What is ruby better for and why?
I am talking mainly about is Ruby better for web based development
(i.e. Ruby on Rails)? or other stuff, whether it be scientific,
business or technological?

Thank you all for your answers.

Daniel Lewis.

[Gennady Bystritksy]

Post by Daniel Lewis
In your opinion(s)....
What is ruby better for and why?
I am talking mainly about is Ruby better for web based development
(i.e. Ruby on Rails)? or other stuff, whether it be scientific,
business or technological?
Thank you all for your answers.
Daniel Lewis.

Too lazy to do your own research? It happens ;-). For a starter, check
out http://www.rubygarden.org/ruby?RealWorldRuby

Gennady.

[Daniel Lewis]

Post by Gennady Bystritksy
Too lazy to do your own research? It happens ;-). For a starter, check
out http://www.rubygarden.org/ruby?RealWorldRuby

Thats quite a good little page... thanks. However, I am asking you
lot, in your experience what is Ruby good for.

[Mike Pence]

I am new to Ruby, but its expressiveness as a language is profound.
So, I would say that any application where you want to achieve a high
level of functionality with a fraction of the lines of code and
overall effort of other approaches is a great fit for Ruby.

Of course, there are problem domains where Ruby is not a good fit. For
systems-level development, you want to use C or Assembler. For complex
mathematical modelling, there are functional programming languages
that are a better fit. But for most business and internet apps, Ruby
can't be beat.

Mike Pence

[Daniel Lewis]

"For complex mathematical modelling, there are functional programming languages
that are a better fit."

OK I agree with what you say about this. But according to this site:
http://www.jvoegele.com/software/langcomp.html
Ruby has the ability to be used as a functional language (as well as
Smalltalk, Python, Perl and Eiffel).

In my final year of university (which starts in September 2006), I
will be learning Hugs (a Haskell varient) for Functional
Programming... it will be interesting how it compares to Ruby, and I
would like to learn how to use Ruby as a functional language.

I'll be using Ruby for my dissertation, I'll be developing some type
of program that uses Fuzzy Logic... possibly something to do with
Robotics, Agents or Control... not sure yet.

Please continue to discuss,

Thanks,

Daniel.

[Mike Pence]

Specifically, I was thinking of whatever it is that Mathematica uses
and PL1 -- Ruby is declarative programming language with functional
aspects, but I don't think it is a purely functional programming
languages. Otherwise, wouldn't we be writing functions instead of
methods?

[Kevin Brown]

Post by Daniel Lewis

"For complex mathematical modelling, there are functional programming
languages that are a better fit."

http://www.jvoegele.com/software/langcomp.html
Ruby has the ability to be used as a functional language (as well as
Smalltalk, Python, Perl and Eiffel).

Yes, you can. The opinion expressed above was simply that those other
languages are a better fit.

Post by Daniel Lewis
In my final year of university (which starts in September 2006), I
will be learning Hugs (a Haskell varient) for Functional
Programming... it will be interesting how it compares to Ruby, and I
would like to learn how to use Ruby as a functional language.

Um....it's not hard...? Just don't define classes and do function calls.
It's like trying to "learn" how to use C++ as a functional language.
Eventually, everything collapses to a functional level because it has to to
get executed by the processor. One instruction at a time. So you just don't
use the extra OO framework built into ruby, instead pretending that def gives
you a function instead of a method.

Post by Daniel Lewis
I'll be using Ruby for my dissertation, I'll be developing some type
of program that uses Fuzzy Logic... possibly something to do with
Robotics, Agents or Control... not sure yet.

Cool. :-)

Post by Daniel Lewis
Please continue to discuss,
Thanks,
Daniel.

[Christophe Grandsire]

Post by Daniel Lewis
http://www.jvoegele.com/software/langcomp.html
Ruby has the ability to be used as a functional language (as well as
Smalltalk, Python, Perl and Eiffel).

Well, as long as one can do higher-order functions, one can eventually
program in a functional way. But not necessarily nicely ;) .

Post by Daniel Lewis
In my final year of university (which starts in September 2006), I
will be learning Hugs (a Haskell varient) for Functional
Programming... it will be interesting how it compares to Ruby, and I
would like to learn how to use Ruby as a functional language.

You'll find out Haskell is quite a different beast. It has interesting
features, but it doesn't have much in common with imperative languages
like Ruby. Its IO model is übercool though (completely functional, which
is quite a feat, and basically making IO actions into objects rather
than actions. But if you really want to understand how it works, you
need to understand the monad, which is quite an esoteric mathematical
notion - and I'm someone who used to eat distributions for breakfast, so
abstract mathematical notions normally don't frighten me ;) -).

Yet it's a great way to open your mind to other possibilities, and to a
language where space is meaningful which is not Python ;) .

Post by Daniel Lewis
I'll be using Ruby for my dissertation, I'll be developing some type
of program that uses Fuzzy Logic... possibly something to do with
Robotics, Agents or Control... not sure yet.

Interesting...

[Daniel Lewis]

" But if you really want to understand how it works, you
need to understand the monad, which is quite an esoteric mathematical
notio " - Christophe Grandsire

I thought I had heard of Monads before, I found this:
" Leibniz's theory does not posit physical space; rather, physical
objects are constructs of the collective experiences of monads. This
way of putting it is misleading, however; monads do not interact with
each other (are "windowless"), but rather are imbued at creation with
all their future experiences in a system of pre-established harmony.
The arrangements of the monads make up the faith and structure of this
world, which to Leibniz was "the best of all possible worlds". " -
Wikipedia

I've read about Leibniz before.

Wikipedia also says:
"
* in non-standard analysis, a monad consists of all those numbers
infinitesimally close to a given number;
* in category theory, a monad, also known as triple, is a type of
functor important in the theory of adjoint functors. This term has a
different root than the ones described above; it was formed by
combining "monoid" and "triad". See monad (category theory).
* In pure functional programming languages such as Haskell, monads
are used as data types that encapsulate the functional I/O-activity,
in such a manner that the side-effects of I/O are not allowed to
spread out of the part of the program that is not functional
(imperative). See monads in functional programming.
"
I am still intrigued to find out how this would work in Ruby... maybe
something to do before I start my dissertation in April (2006). Has
anyone used Ruby in a "functional" way before?

My experience of Ruby so far:
* I have been using it for about 2 months now, I have made two
commercial applications:
(1) An additional component to a C++/Qt program to connect to a MySQL
database and collect data and turn it into a CSV file. It uses the
MySQL/Ruby module.
(2) A configuration file maker for (1): writes (and reads) XML files
to be read by (1) as configurations. It uses REXML and WxRuby.
* I have played about with using Ruby to connect to sockets. I have
also tried to use Ruby/tk but couldn't quite grasp it properly.

Ruby has been really good for what I have used it for so far. But will
it be able to withstand the development I do in it for my
dissertation???

Thanks for all your answers... please continue to discuss, its really
interesting.

[Karl von Laudermann]

Post by Christophe Grandsire
You'll find out Haskell is quite a different beast. It has interesting
features, but it doesn't have much in common with imperative languages
like Ruby. Its IO model is übercool though (completely functional, which
is quite a feat, and basically making IO actions into objects rather
than actions. But if you really want to understand how it works, you
need to understand the monad, which is quite an esoteric mathematical
notion - and I'm someone who used to eat distributions for breakfast, so
abstract mathematical notions normally don't frighten me ;) -).

I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
thereof is basically this:

- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
Therefore:
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

I'm sure that my understanding is wrong, but that's what I came away
with.

[Paolo Capriotti]

Post by Karl von Laudermann
I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow
I'm sure that my understanding is wrong, but that's what I came away
with.

That's not quite right, imho. An IO monad encapsulates a sort of "IO
operation", and IO routines are not monads themselves. Instead, they
_return_ IO monads.
In spite of monads, I think that Haskell code can still be considered
without side effects. Something like
main = do c <- getChar
putChar c
should be thought as a manipulation of abstract "IO operations". It
produces side effects only because the resulting monad is finally
evaluated (i.e. executed), and that cannot be done inside the Haskell
domain.

Anyway, monads are not just for IO. There are plenty of monadic
classes in the ghc library which have nothing to do with IO. A list is
a monad, for example, as well as a parser.

I'm still considering the monad subject from the point of view of Ruby
programming. It may seem that monads belong to the pure functional
world only, and Ruby does not need them, but...
when we write ary.map{|i| i+1}, aren't we using the fact that Array is
a functor (in the mathematical sense)? To some extent, inject can be
considered as a way to exploit the monadic properties of the Array
functor.

However, can the monad concept be defined in Ruby in some generality?

Paolo Capriotti

[Christophe Grandsire]

Post by Paolo Capriotti
That's not quite right, imho. An IO monad encapsulates a sort of "IO
operation", and IO routines are not monads themselves. Instead, they
_return_ IO monads.
In spite of monads, I think that Haskell code can still be considered
without side effects. Something like
main = do c <- getChar
putChar c
should be thought as a manipulation of abstract "IO operations". It
produces side effects only because the resulting monad is finally
evaluated (i.e. executed), and that cannot be done inside the Haskell
domain.

Exactly.

Post by Paolo Capriotti
Anyway, monads are not just for IO. There are plenty of monadic
classes in the ghc library which have nothing to do with IO. A list is
a monad, for example, as well as a parser.
I'm still considering the monad subject from the point of view of Ruby
programming. It may seem that monads belong to the pure functional
world only, and Ruby does not need them, but...
when we write ary.map{|i| i+1}, aren't we using the fact that Array is
a functor (in the mathematical sense)? To some extent, inject can be
considered as a way to exploit the monadic properties of the Array
functor.

In some sense. However, I think monads can really be implemented in a
language that uses a type system like the one used in Haskell, where one
can have operations *on types* (that's basically what monads, with their
type constructors, are). This can probably be done in Ruby through
operations on classes, but that doesn't really feel like the Ruby Way
(although it may be fun to implement ;) ).

Post by Paolo Capriotti
However, can the monad concept be defined in Ruby in some generality?

Thanks to Ruby's dynamicity, it is definitely possible. I'd have a hand
at it if I had some time (which I haven't) and if I felt I had a good
enough understanding of monads (which I don't). And then I'd probably
make a fool of myself anyway ;) .

[Brian Mitchell]

Post by Karl von Laudermann

Post by Christophe Grandsire
You'll find out Haskell is quite a different beast. It has interesting
features, but it doesn't have much in common with imperative languages
like Ruby. Its IO model is übercool though (completely functional, which
is quite a feat, and basically making IO actions into objects rather
than actions. But if you really want to understand how it works, you
need to understand the monad, which is quite an esoteric mathematical
notion - and I'm someone who used to eat distributions for breakfast, so
abstract mathematical notions normally don't frighten me ;) -).

I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow
I'm sure that my understanding is wrong, but that's what I came away
with.

Monads are something that seem to be made over complicated. This is
usually caused by the fact that monads can be used to do so many
different things. Here [1] is an excellent introduction to monads for
those already familiar with very basic Haskell. Basic Haskell skills,
for those interested, can be learned from a large collection of
material, much of which is listed on the haskell.org learning page
[2].

To try to answer the original question:

I think it is up to the programmer or the team. I've seen amazing
things done in just about every language. What made these particular
things a success? The effort that the project was given. It is key to
remember that you are the one who will be lifting each finger to
compose each symbol used in your program.

Now, that might sound far fetched, but it isn't. I've seen many
projects fail, some of my own in fact, all because the energies to use
a particular tool (that may or may not have suited the problem)
diminished. I think Ruby's high flexibility lends to the ability to
maintain the original mental picture had when starting the project.

What about things that require absolute speed, parallelism, or
unavailable library support? Take what I just said into your focus.
Now ask yourself, would I get burnt out on this project using Ruby?
All of those things ruby can't do _actually_ can be done. It is just
something that might inhibit your enthusiasm as Ruby will slow you
down. It will require extra effort whether it be in binding a library,
speeding up the interpreter, or building a special framework.

In the end a completed but not perfected project is better than
something half done and perfect to that point. Maybe by the time you
complete the project, you will have found that things can be fixed or
that things aren't how you original thought them to be. Someone else
might have even solved your problem for you by then which also happens
in the Ruby community more often than not.

All I said really boils down to: Choose the tools that will keep *you*
going. The project will stay around as long as you do.

Brian.

[1] http://www.nomaware.com/monads/html/
[2] http://www.haskell.org/learning.html

[Christophe Grandsire]

Post by Brian Mitchell
Monads are something that seem to be made over complicated. This is
usually caused by the fact that monads can be used to do so many
different things. Here [1] is an excellent introduction to monads for
those already familiar with very basic Haskell. Basic Haskell skills,
for those interested, can be learned from a large collection of
material, much of which is listed on the haskell.org learning page
[2].

Thanks for link 1. Since I've read about Haskell and monads, I've been
looking for a good tutorial to improve my understanding of them. It
looks like a great one (and it uses Maybe, one of my favourite Haskell
types, simple but great ;) ).

Post by Brian Mitchell
[1] http://www.nomaware.com/monads/html/
[2] http://www.haskell.org/learning.html

[gabriele renzi]

Post by Karl von Laudermann
I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow
I'm sure that my understanding is wrong, but that's what I came away
with.

# warning: this is just my understanding of monads as an haskell noob
# and it may be completely wrong :)

First, IIRC Haskell had IO even before the "monadic revolution", it was
just even harder to understand ;)

What I had understand about monads is not that they allow you to express
a single point where side effect will happen, and to order them.
Thus any side effect is not really hidden, it is just structured in a
way that it play nicely with the pure functional part of the code.

Think for example of the IO monad: it allows you to state that you
should, say, print "hello" before "world".
The rest of the program is still happy, functional and lazy, since he
does'nt really care about the console output.

OTOH, when you want to read a string, you can't handle it in the pure
functional side of the code, since it won't be referentially transparent.
Thus you happily write your functional processing stuff, then
incidentally you ask a monad to use that functional stuff on something
that will come from the user.

I think of it as somewhat similar to continuation passing style.
You don't ever "return" from a function in CPS, you just say to the next
continuation "hey, here's my value, do stuff with it".
With monads it is the same, you just say to the monad "hey do this
stuff, and take care of the rest of the program".

At least, I think :)

[Devin Mullins]

Post by gabriele renzi
Think for example of the IO monad: it allows you to state that you
should, say, print "hello" before "world".
The rest of the program is still happy, functional and lazy, since he
does'nt really care about the console output.

The word "lazy", and the impression I was forming about monads from
reading these posts, inspired this simple doodad. Is this useful? Is it
already implemented in some other Ruby library out there?

class Lazy
(instance_methods - %w{__send__ __id__}).each {|meth| undef_method meth }
def initialize(blk)
@blk = blk
end
def method_missing(*a,&b)
@inst = @blk.call unless defined? @inst
@inst.send(*a,&b)
end
end

def lazy(&blk)
Lazy.new blk
end

a = lazy { puts "evaled!"; $some_expensive_db_operation or 5 }
puts "Hello!"
p a
p a
__END__

Output:
Hello!
evaled!
5
5

Devin

[Robert Klemme]

Post by Devin Mullins

Post by gabriele renzi
Think for example of the IO monad: it allows you to state that you
should, say, print "hello" before "world".
The rest of the program is still happy, functional and lazy, since he
does'nt really care about the console output.

The word "lazy", and the impression I was forming about monads from
reading these posts, inspired this simple doodad. Is this useful? Is
it already implemented in some other Ruby library out there?
class Lazy
(instance_methods - %w{__send__ __id__}).each {|meth| undef_method
meth } def initialize(blk)
@blk = blk
end
def method_missing(*a,&b)
@inst = @blk.call unless defined? @inst
@inst.send(*a,&b)
end
end
def lazy(&blk)
Lazy.new blk
end

Delegate comes to mind. Not really shorter...

require 'delegate'
class Lazy < Delegator
alias :init :initialize

def initialize(&b)
super(nil)
@bl = b
end

def __getobj__
if @bl
@obj = @bl.call()
init(@obj)
@bl = nil
end
@obj
end
end
def lazy(&b)Lazy.new(&b)end

Only advantage seems that one can reuse lib code for delegation and
initialization.

Kind regards

robert

[Daniel Lewis]

Post by Robert Klemme

Post by Devin Mullins

Post by gabriele renzi
Think for example of the IO monad: it allows you to state that you
should, say, print "hello" before "world".
The rest of the program is still happy, functional and lazy, since he
does'nt really care about the console output.

The word "lazy", and the impression I was forming about monads from
reading these posts, inspired this simple doodad. Is this useful? Is
it already implemented in some other Ruby library out there?
class Lazy
(instance_methods - %w{__send__ __id__}).each {|meth| undef_method
meth } def initialize(blk)
@blk = blk
end
def method_missing(*a,&b)
@inst = @blk.call unless defined? @inst
@inst.send(*a,&b)
end
end
def lazy(&blk)
Lazy.new blk
end

Delegate comes to mind. Not really shorter...
require 'delegate'
class Lazy < Delegator
alias :init :initialize
def initialize(&b)
super(nil)
@bl = b
end
def __getobj__
@obj = @bl.call()
@bl = nil
end
@obj
end
end
def lazy(&b)Lazy.new(&b)end
Only advantage seems that one can reuse lib code for delegation and
initialization.
Kind regards
robert

oooh my thread has split :)

I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

Thanks,

Daniel.

[Lyndon Samson]

Post by Daniel Lewis

Post by Devin Mullins

Post by gabriele renzi
Think for example of the IO monad: it allows you to state that you
should, say, print "hello" before "world".
The rest of the program is still happy, functional and lazy, since he
does'nt really care about the console output.

The word "lazy", and the impression I was forming about monads from
reading these posts, inspired this simple doodad. Is this useful? Is
it already implemented in some other Ruby library out there?
class Lazy
(instance_methods - %w{__send__ __id__}).each {|meth| undef_method
meth } def initialize(blk)
@blk = blk
end
def method_missing(*a,&b)
@inst = @blk.call unless defined? @inst
@inst.send(*a,&b)
end
end
def lazy(&blk)
Lazy.new blk
end

Delegate comes to mind. Not really shorter...
require 'delegate'
class Lazy < Delegator
alias :init :initialize
def initialize(&b)
super(nil)
@bl = b
end
def __getobj__
@obj = @bl.call()
@bl = nil
end
@obj
end
end
def lazy(&b)Lazy.new(&b)end
Only advantage seems that one can reuse lib code for delegation and
initialization.
Kind regards
robert

oooh my thread has split :)
I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.
Thanks,
Daniel.
'Call by Name' is worth looking up as well :-)

--
Into RFID? www.rfidnewsupdate.com <http://www.rfidnewsupdate.com> Simple,
fast, news.

[Robert Klemme]

Post by Daniel Lewis
oooh my thread has split :)

Better your thread
than your head.
:-)

Post by Daniel Lewis
I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

.... although it's by far not restricted to that.

Btw, recently I discovered (better: started using) an interesting idiom that
exploits the fact that both Proc and Hash implement #[].

FUN = config_memoized ?
Hash.new do |h,k|
# complex calculate val
h[k] = val
end :
lambda do |k|
# complex calculate val
end

# later

x = FUN[y]

Nothing really fancy I guess but it's nice how seemingly these integrate.
(Now, is this another thread split?)

Kind regards

robert

[gabriele renzi]

Post by Robert Klemme

Post by Daniel Lewis
oooh my thread has split :)

Better your thread
than your head.
:-)

Post by Daniel Lewis
I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

... although it's by far not restricted to that.
Btw, recently I discovered (better: started using) an interesting idiom
that exploits the fact that both Proc and Hash implement #[].
FUN = config_memoized ?
Hash.new do |h,k|
# complex calculate val
h[k] = val
lambda do |k|
# complex calculate val
end
# later
x = FUN[y]
Nothing really fancy I guess but it's nice how seemingly these
integrate. (Now, is this another thread split?)

could'nt you just use the default_proc in a Hash?
irb(main):001:0> fun= Hash.new do |h,k|
irb(main):002:1* p 'calculations'
irb(main):003:1> h[k]= rand
irb(main):004:1> end
=> {}
irb(main):005:0> fun[10]
"calculations"
=> 0.364681017817929
irb(main):006:0> fun[10]
=> 0.364681017817929

ok it is inverting the concept, I know but it seem to get the same
result :)

[Kirk Haines]

Post by gabriele renzi

Post by Robert Klemme
FUN = config_memoized ?
Hash.new do |h,k|
# complex calculate val
h[k] = val
lambda do |k|
# complex calculate val
end
# later
x = FUN[y]
Nothing really fancy I guess but it's nice how seemingly these
integrate. (Now, is this another thread split?)

could'nt you just use the default_proc in a Hash?
irb(main):001:0> fun= Hash.new do |h,k|
irb(main):002:1* p 'calculations'
irb(main):003:1> h[k]= rand
irb(main):004:1> end

That is what is in the example above. However, he has the trinary operator in
his example. Depending on the value of config_memoized, one either gets a
hash with a default block, or a lambda, but in use both of them may appear to
be the same.

a = Hash.new {|h,k| h[k] = (k * 10000007) % 20}
b = lambda {|k| (k * 10000007) % 20}

a[5]
=> 15
b[5]
=> 15


In the original example, it illustrated how, because lambdas implement #[],
one could have either a memoizing or a nonmeoizing FUN[] depending on a
configuration value.

Kind of neat,


Kirk Haines

[Kirk Haines]

Post by Kirk Haines
In the original example, it illustrated how, because lambdas implement #[],
one could have either a memoizing or a nonmeoizing FUN[] depending on a
configuration value.

To followup:

def create_calculator_object(memoize, &b)
memoize ? Hash.new {|h,k| puts "memoizing #{k}"; h[k] = b.call(k)} : b
end

a = create_calculator_object(true) {|k| (k * 10000007) % 20}
b = create_calculator_object(false) {|k| (k * 10000007) % 20}

irb(main):007:0> a[5]
memoizing 5
=> 15
irb(main):008:0> a[5]
=> 15
irb(main):009:0> b[5]
=> 15


Kirk Haines

[Jay Levitt]

Post by Robert Klemme

Post by Daniel Lewis
I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

... although it's by far not restricted to that.
Btw, recently I discovered (better: started using) an interesting idiom that
exploits the fact that both Proc and Hash implement #[].

Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and its
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.

[James Britt]

Post by Jay Levitt

Post by Robert Klemme

Post by Daniel Lewis
I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

... although it's by far not restricted to that.
Btw, recently I discovered (better: started using) an interesting idiom that
exploits the fact that both Proc and Hash implement #[].

Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and its
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.

Book:
* http://mitpress.mit.edu/sicp/

Not a book:
http://lambda-the-ultimate.org/node/view/4


James

[Alan Gutierrez]

Post by Jay Levitt

Post by Robert Klemme

Post by Daniel Lewis
I'm going to be noting all this down, Lazy Evaluation is a subject in
Functional Programming and AI.

... although it's by far not restricted to that.
Btw, recently I discovered (better: started using) an interesting idiom that
exploits the fact that both Proc and Hash implement #[].

Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and its
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.

I can't recommend anything really, since I don't FP.

But, I've bookmarked...

http://www.drscheme.org/

For it's tutorials.

http://www.plt-scheme.org/software/drscheme/tour/tour-Z-H-4.html

And there's a classic text called the "The Little Lisper" that
has been revised as the "The Little Schemer", which is less than
100 pages, and purports to get you thinking recursively.

--
Alan Gutierrez - ***@engrm.com - http://engrm.com/blogometer/

[Jeff Wood]

Actually, the tour is mostly useless... but, they also have ( all by the PLT
folks )
How to Design Programs
http://www.htdp.org/
and
Learn Scheme in FIXNUM days
http://download.plt-scheme.org/doc/299.400/html/t-y-scheme/

Post by Robert Klemme

Post by Jay Levitt

Post by Robert Klemme

Post by Daniel Lewis
I'm going to be noting all this down, Lazy Evaluation is a subject

in

Post by Jay Levitt

Post by Robert Klemme

Post by Daniel Lewis
Functional Programming and AI.

... although it's by far not restricted to that.
Btw, recently I discovered (better: started using) an interesting

idiom that

Post by Jay Levitt

Post by Robert Klemme
exploits the fact that both Proc and Hash implement #[].

Could you recommend a good book for us old-timers - who grew up in
procedural languages, never learned more Lisp than we needed to
customize Emacs, and are still getting our heads around the now-half-
obsolete OO GoF patterns - to learn about functional programming and its
idioms? From reading this thread, I would have assumed that FP is
another word for "procedural" but clearly it's much, much more.

I can't recommend anything really, since I don't FP.
But, I've bookmarked...
http://www.drscheme.org/
For it's tutorials.
http://www.plt-scheme.org/software/drscheme/tour/tour-Z-H-4.html
And there's a classic text called the "The Little Lisper" that
has been revised as the "The Little Schemer", which is less than
100 pages, and purports to get you thinking recursively.
--

--
"http://ruby-lang.org -- do you ruby?"

Jeff Wood

[Edward Faulkner]

From reading this thread, I would have assumed that FP is another
word for "procedural" but clearly it's much, much more.

Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.

The key idea in functional programming is that the functions you
define are functions in the mathematical sense. If you call one twice
with the same arguments, you'll always get the same answer each time.
They have no internal state and no side effects.

In practice most programs need non-functional parts too, but you can
keep those isolated.

By keeping your code functional, you make it easier to test and debug.
It's inherently thread safe, and optimizations like lazy evaluation
and memoization can be introduced transparently by the
compiler/interpreter.

regards,
Ed

[Jay Levitt]

In article <***@peaches-en-regalia>, ***@alum.mit.edu
says...

Post by Edward Faulkner
Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.

Thanks for summing this up so wonderfully.

[Robert Klemme]

Post by Edward Faulkner

From reading this thread, I would have assumed that FP is another
word for "procedural" but clearly it's much, much more.

Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.
The key idea in functional programming is that the functions you
define are functions in the mathematical sense. If you call one twice
with the same arguments, you'll always get the same answer each time.
They have no internal state and no side effects.

I was going to write something similar. Thanks for confirming that my rusty
CS knowledge on functional programming was not completely outdated!

Post by Edward Faulkner
In practice most programs need non-functional parts too, but you can
keep those isolated.

.... and all functional languages with some significance have non functional
extensions (like side effects, variables etc.).

Post by Edward Faulkner
By keeping your code functional, you make it easier to test and debug.
It's inherently thread safe, and optimizations like lazy evaluation
and memoization can be introduced transparently by the
compiler/interpreter.

IIRC another property of (pure) functional programs is that they are easier
to reason about mathematically and thus to verify (probably because
functions resemble very much mathematical functions).

Kind regards

robert

[Matthias Luedtke]

Post by Robert Klemme
IIRC another property of (pure) functional programs is that they are
easier to reason about mathematically and thus to verify (probably
because functions resemble very much mathematical functions).

That is certainly true! Just think of the functions recursive nature and
how structural induction comes in handy here. Imperative programs often
require harder tools such as e.g. Hoare logic. In theory, at least... ;)

Regards,
Matthias

[Christophe Grandsire]

Post by Edward Faulkner
Indeed, functional programming is almost the *opposite* of procedural.
In a procedural program, most lines are executed for their side
effects. In a functional program, most lines are executed for their
value.

Incidently, since functions in functional languages (pure ones at least) have no
side-effects, order of execution doesn't matter anymore. This also means that
there is no such thing as looping anymore. Instead, for looping purposes
functional languages use recursion exclusively. It isn't a problem as recursion
is more powerful than looping (it is actually mathematically proven that loops
are equivalent to a specific kind of recursion called tail recursion).

Post by Edward Faulkner
The key idea in functional programming is that the functions you
define are functions in the mathematical sense. If you call one twice
with the same arguments, you'll always get the same answer each time.
They have no internal state and no side effects.

Indeed, if you look at a program written in Haskell for instance, it really
looks like a sort of mathematical notation reduced to fit ASCII :) .

Post by Edward Faulkner
In practice most programs need non-functional parts too, but you can
keep those isolated.

The most important case is IO. I personally like the Haskell solution very much
(although it is theoretically complicated), because it is still provably purely
functional, isolating IO side-effects in objects rather than functions.

Post by Edward Faulkner
By keeping your code functional, you make it easier to test and debug.
It's inherently thread safe, and optimizations like lazy evaluation
and memoization can be introduced transparently by the
compiler/interpreter.

The only problem is that functional programming is so far removed from the usual
idea of "giving instructions for the computer to execute" that most people can't
seem to grok it. The functional programming metaphor looks to me more like
"giving rules to the computer and problems to be solved with them".

Some people may be interested in this: http://raa.ruby-lang.org/project/rtype/ .
This is a Ruby interpreter written in Haskell.
--
Christophe.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

[Christophe Grandsire]

Post by Karl von Laudermann
I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

That's not quite correct. Monads are not an ad-hoc concept. They are a
mathematical concept that existed *before* Haskell was even invented.
They have their source in category theory, which is as remote from
programming as any mathematical concept can be ;) .

There have already been good replies, but I thought I might add my two
cents here. Note that it's how I understand monads. It may not be
mathematically correct, but it seems to fit their behaviour.

The thing about monads, and the IO monad in particular, is that they
aren't functions on objects: they are datatypes, or rather parametric
datatypes, i.e. functions that work *on types*. IO, for instance, is a
function that takes a type a, and returns a new type called "IO a". So
you can for instance take a String object, apply an IO operation to it,
and that will return a new object of type "IO String". And note that
this operation doesn't have a side-effect. It's purely functional. It's
rather that when the IO String object will be evaluated, the evaluation
will result in printing the string on the output. That is not a
side-effect, because evaluating a variable isn't an operation, but the
effect of executing a program.

In other words, a variable of type "IO something" encapsulates an IO
action, and the IO subroutines don't have side effects by themselves,
but rather return IO actions as their result. And it's the IO action
itself, when evaluated by the Haskell interpreter/runtime (because it
needs the value of that variable to carry on its computation, like it
could need the value contained in a variable of type Integer) that will
result in some interaction with the outside world. This way, the sides
effects are contained in variables, which can only be of an IO type.

But there's more to it. Being a pure, functional and lazy language,
Haskell doesn't have an order of execution. But IO actions need
sometimes to be ordered. Luckily, by their very mathematical
definitions, monads have to follow some axioms, which define operations
on those monads. One of those operations allows to define a
concatenation operator, which in the case of IO takes two IO actions and
returns a single IO action, which when evaluated will result in the two
IO actions to be evaluated in order. This way, you can ensure that IO
operations happen in the correct order, and to hide the mathematical
aspect of this operator called >> Haskell provides convenient syntactic
sugar (in the form of a do... end block) to write concatenations of IO
actions in a way close to imperative language.

But monads aren't used only with IO. Another monad is the parametric
List, which if I'm not completely mistaken encapsulates linked lists. In
this case, the concatenation operator that was used with IO objects to
evaluate them orderly can be used with Lists to concatenate two Lists
into one.

Monads are quite an esoteric feature, and my explanations probably don't
do them justice. But you can be sure they aren't just an ad-hoc
construction to pretend you don't have side effects in IO. They are a
deep mathematical concept that by chance happened to have the right
operations to be used in Haskell IO.

As for applying something like monads to Ruby... Well, I don't know
whether this would be really necessary. The reasons why monads are
useful in Haskell (encapsulation of side effects, orderly evaluation,
collections, etc...) can be handled pretty well as they are. Moreover,
to implement them in the way Haskell does, the monad would probably have
to be defined as an operation transforming a class into another class
(in the case of IO, a class would be transformed into another class
which would have the peculiarity that when an object of that class is
evaluated by the Ruby interpreter, it results in some input or output
interaction). It would be an interesting exercise (hey, I might look
into it just for fun), but I'm afraid it would be rather academic, but
fun ;) .

[Brian Mitchell]

Post by Christophe Grandsire

Post by Karl von Laudermann
I certainly don't understand the monad. I read some introductory
material re: Haskell just a couple of weeks ago, out of curiosity about
the language. My understanding of the monad concept and Haskell's use
- Haskell is a purely functional language
- Purely functional languages cannot have side effects
- A language that can't do I/O is useless, so we need a way to put side
effects into a purely functional language
- We'll put I/O subroutines into Haskell, *but* we'll call them
"monads", and that magically fixes the problem somehow

That's not quite correct. Monads are not an ad-hoc concept. They are a
mathematical concept that existed *before* Haskell was even invented.
They have their source in category theory, which is as remote from
programming as any mathematical concept can be ;) .
There have already been good replies, but I thought I might add my two
cents here. Note that it's how I understand monads. It may not be
mathematically correct, but it seems to fit their behaviour.
The thing about monads, and the IO monad in particular, is that they
aren't functions on objects: they are datatypes, or rather parametric
datatypes, i.e. functions that work *on types*. IO, for instance, is a
function that takes a type a, and returns a new type called "IO a". So
you can for instance take a String object, apply an IO operation to it,
and that will return a new object of type "IO String". And note that
this operation doesn't have a side-effect. It's purely functional. It's
rather that when the IO String object will be evaluated, the evaluation
will result in printing the string on the output. That is not a
side-effect, because evaluating a variable isn't an operation, but the
effect of executing a program.
In other words, a variable of type "IO something" encapsulates an IO
action, and the IO subroutines don't have side effects by themselves,
but rather return IO actions as their result. And it's the IO action
itself, when evaluated by the Haskell interpreter/runtime (because it
needs the value of that variable to carry on its computation, like it
could need the value contained in a variable of type Integer) that will
result in some interaction with the outside world. This way, the sides
effects are contained in variables, which can only be of an IO type.
But there's more to it. Being a pure, functional and lazy language,
Haskell doesn't have an order of execution. But IO actions need
sometimes to be ordered. Luckily, by their very mathematical
definitions, monads have to follow some axioms, which define operations
on those monads. One of those operations allows to define a
concatenation operator, which in the case of IO takes two IO actions and
returns a single IO action, which when evaluated will result in the two
IO actions to be evaluated in order. This way, you can ensure that IO
operations happen in the correct order, and to hide the mathematical
aspect of this operator called >> Haskell provides convenient syntactic
sugar (in the form of a do... end block) to write concatenations of IO
actions in a way close to imperative language.
But monads aren't used only with IO. Another monad is the parametric
List, which if I'm not completely mistaken encapsulates linked lists. In
this case, the concatenation operator that was used with IO objects to
evaluate them orderly can be used with Lists to concatenate two Lists
into one.
Monads are quite an esoteric feature, and my explanations probably don't
do them justice. But you can be sure they aren't just an ad-hoc
construction to pretend you don't have side effects in IO. They are a
deep mathematical concept that by chance happened to have the right
operations to be used in Haskell IO.
As for applying something like monads to Ruby... Well, I don't know
whether this would be really necessary. The reasons why monads are
useful in Haskell (encapsulation of side effects, orderly evaluation,
collections, etc...) can be handled pretty well as they are. Moreover,
to implement them in the way Haskell does, the monad would probably have
to be defined as an operation transforming a class into another class
(in the case of IO, a class would be transformed into another class
which would have the peculiarity that when an object of that class is
evaluated by the Ruby interpreter, it results in some input or output
interaction). It would be an interesting exercise (hey, I might look
into it just for fun), but I'm afraid it would be rather academic, but
fun ;) .
--
Christophe Grandsire.
http://rainbow.conlang.free.fr
You need a straight mind to invent a twisted conlang.

I've toyed with the concept myself before. Perhaps a good place to
start would be Maybe...

data Maybe a = Just a | Nothing

Simple enough right?

Brian.

[Rob Rypka]

Post by Daniel Lewis

Post by Gennady Bystritksy
Too lazy to do your own research? It happens ;-). For a starter, check
out http://www.rubygarden.org/ruby?RealWorldRuby

Thats quite a good little page... thanks. However, I am asking you
lot, in your experience what is Ruby good for.

If you watch this list for a while, you'll start to recognize some of the
names on that page :-).

Anyways, I've carrying around some loose change, so you can have my $0.02:

I am probably one of the few people on this list who haven't used Rails (I
installed it, and I intend to, but I'm too busy/lazy). I think that Ruby
excels in a number of areas.

The first is as a "glue language," which is something that Perl is generally
attributed to. This usually involves text processing, and between the
Perl-like regular expressions features, OO and Mixins, and iterators/blocks,
this becomes cake.

An example: At work, we used Ruby to convert strace output from a build to a
list of compiler calls, so we could send them to another compiler-like tool.

Ruby also has many good database access interfaces. You can go the more
standard route (DBI), or dig into Og or the Action stuff. My experience here
has been pretty boring, just doing some basic DB queries.

Finally (for this mail - there are many other possibilities), designing an
application is very fluid in Ruby. I have found that I can sit down and
flesh out the design of an application directly in Ruby, so I have a working
version when I'm done. Changes are really quick (you can even change things
around while running the program in irb to see if something else will work).
Even if it's just used for proof-of-concept purposes (you plan to rewrite it
in Ruby or another language), this has been very valuable to me.

--
Rob

[Tim Hammerquist]

Post by Daniel Lewis

Post by Gennady Bystritksy
Too lazy to do your own research? It happens ;-). For
a starter, check out
http://www.rubygarden.org/ruby?RealWorldRuby

Thats quite a good little page... thanks. However, I am asking
you lot, in your experience what is Ruby good for.

Relieving depression that not all future OO languages need be
unimaginative iterations of the same C++/Java trainwreck?

Inspiring new, elegant, readable code, without being tied down
by Python's fascist syntax control, or Perl's line noise?

Curing boredom on a lazy weekend?

If you're looking to trap anyone into saying something like
"Ruby is great for RoR stuff, but I don't really use it anywhere
else", you're not going to get it from me. Ruby was a breath of
fresh air from the second I found I could have intuitive,
functional, and readable variable names *AND* intuitive regular
expression syntax at the same time. As I got the hang of
iterators, it just got better.

(I still love Perl, and at the moment, I'm still more fluent in
Perl than in Ruby, but I never stop practising.)

If you're just want us to justify your learning Ruby,
stop stalling already and jump in!

Tim Hammerquist

[Robert Klemme]

Post by Daniel Lewis
In your opinion(s)....
What is ruby better for and why?
I am talking mainly about is Ruby better for web based development
(i.e. Ruby on Rails)? or other stuff, whether it be scientific,
business or technological?

Do you mean better compared to language X or do you mean what application
area Ruby suits best?

IMHO it's very good for scripting and learning (programming in general and
especially OO).

Kind regards

robert

[Daniel Lewis]

Post by Robert Klemme
Do you mean better compared to language X or do you mean what application
area Ruby suits best?

What application... but if you have made a tool in ruby and another
language... you could tell us about it.

Daniel.

[Martin Ankerl]

Post by Daniel Lewis
What is ruby better for and why?

I think your question is a bit vague. For me, programming Ruby is
usually better than falling out of a flying plane without a parachute.
On the other hand, I usually prefer having a parachute with me than
programming Ruby when I am already in free fall.

[Phil Tomson]

Post by Daniel Lewis
In your opinion(s)....
What is ruby better for and why?
I am talking mainly about is Ruby better for web based development
(i.e. Ruby on Rails)? or other stuff, whether it be scientific,
business or technological?

Ruby has already proven quite successful for web development (via Rails). I
use Ruby for various scientific applications and for me it's been quite
successful, YMMV.

Phil

[Warren Seltzer]

Ruby is NOT good for:

1) Writing Garbage Collectors or other memory allocators.
2) Ram tests.
3) Simulating the weather or designing A-bombs -- most of the stuff they do on a
super-computer.
4) Device Drivers.
5) Code that goes in ROM, or other embedded systems.
6) Winning the Obfuscated C contest.
7) Building SPAM systems to send out zillions of offensive e-mails.
8) Violating the laws of thermodynamics.

Warren Seltzer

[Justin Collins]

Post by Warren Seltzer
1) Writing Garbage Collectors or other memory allocators.
2) Ram tests.
3) Simulating the weather or designing A-bombs -- most of the stuff they do on a
super-computer.
4) Device Drivers.
5) Code that goes in ROM, or other embedded systems.
6) Winning the Obfuscated C contest.
7) Building SPAM systems to send out zillions of offensive e-mails.
8) Violating the laws of thermodynamics.
Warren Seltzer

Actually, I think Ruby would work quite well for #7........


uh, not that I uh would you know.

-Justin

[Rob Rypka]

Post by Justin Collins

Post by Warren Seltzer
7) Building SPAM systems to send out zillions of offensive e-mails.

Actually, I think Ruby would work quite well for #7........
uh, not that I uh would you know.
-Justin

I just about had the same response (I, um, don't know either). Then I
started thinking...

<devil's advocate>
Wouldn't a goal of spam software be to load it onto someone else's machine
so you don't get caught (and for parallelism)? In order to get the maximum
return on this sort of program, you should target Windows boxes of
non-technical/home users - security is looser, and they probably won't
notice until it's too late (ISP b4|\|n4g3!). But, really, how many of these
machines are going to have Ruby installed? You're better off writing these
in some native Windows scripting thing - the code may be uglier, but it
would at least run...

Now, of course, Ruby would be great as a meta-programming language to
generate variations on these scripts!
</devil's advocate>

--
Rob

[John Carter]

Post by Daniel Lewis
What is ruby better for and why?

The perl folk describe perl as the Swiss Army chain saw.

Meaning it has as many uses as a Swiss Army knife that has many different
blades and gadgets and is powerful as a chain saw.

Ruby is like Perl but better.

ie. It is Very Good for Many purposes.




John Carter Phone : [phone]
Tait Electronics Fax : [phone]
PO Box 1645 Christchurch Email : ***@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

Post by Daniel Lewis
From this principle, all of life and physics may be deduced.

[Greg Loriman]

Post by Daniel Lewis
In your opinion(s)....
What is ruby better for and why?

Ruby is good at attracting bores. Notice how many people have replied to
your message with non-answers, perhaps supposed to be amusing, but really
just irritating and unfunny. Or worse, the presumptuous : "go and do your
homework". Makes me feel an unchristian desire to kill.

Perhaps this is the penalty of a geek language; the signal to bore ratio in
this group is not so good.

Coming back to your question : Ruby is nice, but don't get bamboozled by the
ruby crowd. Someone with a clear head needs to come along and critique the
language more objectively than I have seen so far. hOwever I'm not saying
its a bad langauge; far from it,

For example: although some would push Ruby for big projects there are
reasons to be circumspect about such a decision. Not being a Ruby expert I
cannot elaborate too much, except to say that there are some
industrial-strength-unfriendly-and-too-powerful-perhaps features in the
language, like C++ but much more elegant possibilities for self destruction.
The Rails project also needs proper examination. It seem like the soloution
to all our problems, the way people talk about it. But there are sounds from
the deep (the WWW) to think that it is not the solution to all our
problems. Again I am unable to elaborate, but you can look around.

So be careful of the ruby fanatics; they have funny starring eyes and froth
coming from their mouths, like mad dogs.

Greg

[Kev Jackson]

Post by Greg Loriman
Ruby is good at attracting bores. Notice how many people have replied to
your message with non-answers, perhaps supposed to be amusing, but really
just irritating and unfunny. Or worse, the presumptuous : "go and do your
homework". Makes me feel an unchristian desire to kill.
Perhaps this is the penalty of a geek language; the signal to bore ratio in
this group is not so good.

Why would you say that ruby is a geek language? Are not all computer
languages at least a little geeky? And to be honest with you I find
this to be the opposite, there are far more people on this list who
(like myself) seem to have just started with ruby coming from
php/perl/$dynamic language than people with the deepest ruby knowledge
(although there are a few of those too).

If you want to see real evangilizing, drop in the rails mailing list :)

to answer the original question..

From my experience ruby is useful for data munging tasks, it's useful
for prototyping (rails is a good framework to build a little just to get
initial feedback from the customer).

They're the only things I've used ruby for so I'd be lying if I said
that you could program satellites/mars rovers/"enterprise thingies" etc.

On a personal note, I like it, I like it more than Java, more than C,
much more than VB or C#. It feels productive to me - no more
compililations is a good thing when you have to knock up a one-off
tool. On the other hand it's currently an interpreted language so for
certain classes of problem (HPC/TPC) it's probably not the best choice
yet. Still Lisp feels hyper-productive and can be compiled, Haskell
also feels good and you can compile that, but neither of them as as easy
to pick up as ruby, so it depends a lot on what you want

I'm going to use it to build up a small app that I've got 50% complete
in Java to try it in a different problem domain, I'll be initerested to
see how much difficulty I have with it there (UI+ natural language data
crunching)

Kev

[Devin Mullins]

Post by Greg Loriman
For example: although some would push Ruby for big projects there are
reasons to be circumspect about such a decision. Not being a Ruby expert I
cannot elaborate too much, except to say that there are some
industrial-strength-unfriendly-and-too-powerful-perhaps features in the
language, like C++ but much more elegant possibilities for self destruction.

When I started out with Ruby, I had the same suspicions. Open classes,
no type declarations on method headers, require
'filename_instead_of_class_name', among others, scared me about using it
as part of a team. I did my best to investigate this to see if it rang
true -- my conclusion now is that Ruby is not a good idea if nobody has
any control over the team, and it's complete chaos. There are enough
harmful things that can be done, but are harder to do in whatever your
team already uses (if only because they know the language), that you
need a team to actually coordinate, and write unit tests, and rdoc
comments, and agree on certain standards, and review each other's code,
etc. But if you have that, it seems to me that Ruby would make the team
go much faster.

Post by Greg Loriman
The Rails project also needs proper examination. It seem like the soloution
to all our problems, the way people talk about it. But there are sounds from
the deep (the WWW) to think that it is not the solution to all our
problems. Again I am unable to elaborate, but you can look around.

I can elaborate a little bit. The "sounds from the deep" mostly point to
a lack of JMS, JTA, an ESB. Instead, Rails & Ruby have different
solutions to asynchronous messaging, transactions, and distributed
processing -- and they may not be overly complex enough for your needs.
:) If you've got requirements for that sort of stuff, then...

Post by Greg Loriman
So be careful of the ruby fanatics; they have funny starring eyes and froth
coming from their mouths, like mad dogs.

Actually, we're pretty reasonable.

And yes, I'll throw in a "Ruby is fantastic for prototyping, and then
realizing that your prototype is actually a fully-functional version of
the thing you were trying to mock up." But that took me, like, 2 days
to discover.

Devin "Mad Dog" Mullins

[Austin Ziegler]

Post by Greg Loriman

In your opinion(s).... What is ruby better for and why?

Ruby is good at attracting bores. Notice how many people have replied
to your message with non-answers, perhaps supposed to be amusing, but
really just irritating and unfunny. Or worse, the presumptuous : "go
and do your homework". Makes me feel an unchristian desire to kill.

I actually think that most people have heard this questions -- or at
least variants of it -- for a long time and are, to be honest, tired of
answering it. The RealWorldRuby page is an *excellent* indication of
what Ruby *is* good for.

[... Nonsensical FUD deleted ...]

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

[Daniel Lewis]

Post by Austin Ziegler
I actually think that most people have heard this questions -- or at
least variants of it -- for a long time and are, to be honest, tired of
answering it. The RealWorldRuby page is an *excellent* indication of
what Ruby *is* good for.

I originally asked to find out peoples personal experience... to find
out interactively. Not to do some research on the Internet about what
Ruby is good for. I wanted to know opinions. Yes, you may have heard
similar questions before, but Ruby is continuously being updated and
new types of development/design occur. Its important to keep up to
date.

[Austin Ziegler]

Post by Daniel Lewis

Post by Austin Ziegler
I actually think that most people have heard this questions -- or at
least variants of it -- for a long time and are, to be honest, tired of
answering it. The RealWorldRuby page is an *excellent* indication of
what Ruby *is* good for.

I originally asked to find out peoples personal experience... to find
out interactively. Not to do some research on the Internet about what
Ruby is good for. I wanted to know opinions. Yes, you may have heard
similar questions before, but Ruby is continuously being updated and
new types of development/design occur. Its important to keep up to
date.

Two things:

1. My statement was not meant to reflect on you, the OP. It was,
however, intended to suggest that if you sometimes seem to get
flippant responses to such questions, there's good reason ;)

2. To the best of my knowledge, the RealWorldRuby page is updated often.

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

[Rob Rypka]

Post by Greg Loriman
For example: although some would push Ruby for big projects there are
reasons to be circumspect about such a decision. Not being a Ruby expert I
cannot elaborate too much, except to say that there are some
industrial-strength-unfriendly-and-too-powerful-perhaps features in the
language, like C++ but much more elegant possibilities for self destruction.

I definately prefer elegant possibilities for self destruction of Ruby to
the inelegant possibilities for self destruction in other languages.

"The way I see it, if you're gonna build a time machine into a car, why not
do it with some style?"

--
Rob

[Ryan Leavengood]

Post by Greg Loriman
Coming back to your question : Ruby is nice, but don't get bamboozled by the
ruby crowd. Someone with a clear head needs to come along and critique the
language more objectively than I have seen so far. hOwever I'm not saying
its a bad langauge; far from it,

I really enjoy programming in Ruby, in fact I would say it was my
favorite language. But it is not perfect, and I'll try to describe
some of the flaws I see in it. To give some background I've been
involved with the Ruby community since 2001, so I think I have a good
perspective:

- It is slow. Or to be more exact, compared to some other languages,
Ruby is slow in certain problem domains. Recursion is quite slow for
example. Part of the problem is the fact that the current Ruby
interpreter works by parsing the code into an abstract syntax tree and
then executing that tree directly. The normal standard for
interpreters these days is to compile the code into an intermediate
byte-code and then executing that, which is usually much faster than
the current Ruby method. Fortunately we have a very smart fellow named
SASADA Koichi working on a Ruby byte-code interpreter called YARV (see
http://www.atdot.net/yarv/), so this flaw won't be around for much
longer. Of course the reality is that Ruby, by its very nature, can
never be as fast as a static compiled language like C or C++. Plus as
others have said there are certain problem domains where you would
have to use those kind of languages instead of Ruby (operating system
kernels, device drivers, etc.)

- Ruby is almost too flexible. This is subjective, but the powerful
ability to modify base classes of the system brings a certain
responsibility that some people may not consider. This doesn't apply
too much to little throwaway scripts that we all tend to write, but
there are several examples of Ruby libraries doing stuff here that has
bitten people. These are probably some of the hardest bugs to find,
since few people think that the core classes could have been changed
under their noses. Fortunately most Ruby library developers are aware
of this and they follow certain etiquette rules to ensure these kind
of problems don't come up.

- For large projects the flexibility of Ruby source code organization
could cause problems (in that you aren't forced to put one class per
file for example, like Java), but again this isn't that big of a flaw
because it just requires a small amount of discipline in being
organized with your code.

- The state of Ruby libraries still leaves a bit to be desired. This
has been a persistent problem even since I started with Ruby in 2001,
in fact it inspired me to create the original RubyGems prototype which
has since been supplanted by the RubyGems system we have today. While
this has certainly been a big improvement, not everyone makes use of
the gem system, so there is still some fragmentation. Also RubyGems
still has a bit of a "tacked on" feeling, and this won't go away until
its flaws are fixed and it is fully integrated into a Ruby release. In
addition there are tons of "dead libraries" that haven't been touched
for months or years, yet still provide useful functionality. There are
some efforts to dust off these libraries and bring them up-to-date
though, so hopefully we will see some improvement here.

- Ruby documentation also leaves a bit to be desired. Thanks to the
great Pickaxe book and several others, the Ruby core classes are
pretty well documented, but there are still certainly areas for
improvement there. But I find that way too many libraries (especially
many that actually ship with Ruby) have little or no documentation. I
can't tell you how many times I've just decided to read the source
code of some library to figure out how to use it because no decent
documentation was available. Again there are efforts to solve this
problem as well, but I think the solution needs to be more of a change
in Ruby culture to promote documenting libraries one develops, instead
of leaving that job to someone else. A big part of this could be the
language barrier, since many cool Ruby libraries are developed by
people who may not be confident in their English ability. In that case
some good example code would certainly be better than nothing.

- There is no standard Ruby GUI. Maybe this is a moot point with how
things are going with the Web these days (and Ruby has that realm
covered with Nitro, Rails, Wee, etc), but desktop operating systems
and applications aren't going to disappear overnight, so a good and
somewhat standard Ruby GUI would be nice. Right now there are
certainly many options when one has to create a Ruby GUI (too many in
fact), but each has particular flaws or is lacking maturity in
comparison to the same GUI bindings in Python or another language.
This is a very difficult problem though, and even Java has had a lot
of struggles here (despite tons of money and time from Sun and many
other companies.)

This email is already too long, so I'm not going to answer the
original question of this thread, but hopefully the above will be
enlightening.

Ryan