Why I don't use Ruby.

[Stefan Schmiedl]

I know I shouldn't, but I'm going to anyways ...

And even if you go this way, your program will then be as save as a
program in FORTH - or a C program where everything is casted to (void*)

Actually, my Forth (you may use lower case, nowadays) programs are quite
stable. I have much more faith in them than in other compiled programs,
where I don't know what's going on.

Lisp guys write some routines in this "typed Lisp", rubyist's write
them in "C", so it's not so different.

And you usually have a built in assembler available in Forth

Have a nice weekend, everyone.
s.

 

[bruno modulix]

Carl Youngblood a écrit :

OCaml is as dynamic as LISP

Due to static typechecking, it certainly ain't...

Bruno

 

[bruno modulix]

TLOlczyk a écrit :
(snip)

Let us as an example look at a program that looks at a directory of
Web pages, and traces through them. If it cannot find a link to a
certain page, then it creates a link on a page in a prescribed manner.

You've written the program and tested it on a small data set.
Now you want to test it on a large data set. It fails miserably
and you try to debug.
Phase one of the program gets a list of all the files in the directory
( recursively ).
Phase two is to scan the root files for hrefs. Then scan the files in
the hrefs. Then ... untill there are no more files to scan.
Phase three is to pick some file you didn't reach and create a link to
it.

So you work on Phase one and get it to run.
Then you work on Phase two. But it takes Phase one
ten minutes to run. So each time you test a fix in phase two
it takes at least ten minutes to run.

So you save an image at the end of phase one.

What you have to save here is "a list of all the files in the
directory"... Which is quite easy to write to/read from file, be it by
serialization (ie : marshaling) or in a flat or structured text format -
which is amazingly easy with langages like Ruby.

Having played with 'image-based' systems, I can well understand why you
like it, but your example may not be that good... !-)

Bruno

 

[Gawnsoft]

(more or less):
....

Mid-1980's -- BBC Micro (Acorn) - BASIC Interpreter
6502 processor (OK, not the best

And, of course, it ran at twice teh clock speed of the Apple ][

Implemented in 8K ROM (including two pass assembler)

This snippet loads a 512-byte machine code file into a fixed
location in the adequate 32K RAM and assembles 3 patches over
the memory copy of the file ready for saving or running.
It uses the offset-assembly feature which generates code to
be run in a block of memory other than where it is being
assembled. (No segment registers provided on 6502)

BASIC functions and variables are available within the [asm] block.
FNorg just updates the instruction address for the next patch and
returns "self" to the OPT (assembler options) directive.
Functions such as this and the ability to drop in and out of
BASIC gives a macro-like flexibility.


*LOAD AProg
10:
70 LD%=&37AD
80:
90 o%=3: \ flags
100:
110 FOR pass%=4 TO 4+o% STEP o%
120:
130 [ OPT FNorg(&42A)
140 JMP &43F
150\
160 OPT FNorg(&52E)
170 LDX #0
180\
190 OPT FNorg(&5C1)
200 TXA
210 ]
220 NEXT
230:
300 END
310:
320 DEF FNorg(p%)
330 O%=LD%+(p%-&400)
340 P%=p%
350 =pass%

Have a nice weekend, everyone.
s.

( Difficult without an assembler in Ruby ?~)

cheers,

daz

--
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk

 

[Lothar Scholz]

Hello Gawnsoft,

G> (more or less):
G> ....
G> And, of course, it ran at twice teh clock speed of the Apple ][

G>

I just saw an episode of Futurama today, the one with where they win
the Slurm party. What du you think is in benders head ?

http://www.ruby-ide.com/bender.gif

 

[Sean Russell]

Um, I don't see this as true. Certainly one can write all the
procedural code one likes in Ruby (I know *I've* managed to do it), and
I believe the same is pretty much true for writing functional code.

"Functional code" is a rather broad term, but one popular feature of
many functional languages is pattern matching[1], which Ruby doesn't
support. Indeed, the entire structure of functional programs is
generally alien enough to OO or procedural languages that any mapping
you could do would be difficult to describe as being functional,
except in the broadest sense.

Procedural and OO languages are very similar. Functional languages
require a different mindset, and I believe that it *is* a stretch to
claim that you can do functional programming in Ruby. Furthermore,
I'd say it would be difficult to do pure procedural programming in
Ruby -- you'd have to redefine most of the API to avoid calling
methods on objects -- however, it could be done.


[1] in the sense of matching the appropriate function based on the
arguments.
Consider the function sum(). Given a recursive procedural definition:

int sum( array ) {
if ( length( array ) == 0)
return 0;
else
return array[0] + sum( subset( array, 1, length( array ) - 1 ) );
}

In Ruby(procedural) this might be:

sum( array ) {
return 0 if length( array ) == 0
return array[0] + sum( subset( array, 1, -1 ) )
}

(being pedantic, and avoiding *all* OO methods). In Haskell, this
code would be:

func [] = 0
func (x:y) = x + func( y )

Converting the Haskell code to Ruby would give you the same code as
the procedural version (again, if you avoid all of the OO
constructions that you possibly can). I don't think I'd be
exaggerating if I said that, in general, Ruby( procedural ) == Ruby(
functional ), and yet, functonal and procedural programming are
fundamentally different styles.

--- SER

 

[Mikael Brockman]

Um, I don't see this as true. Certainly one can write all the
procedural code one likes in Ruby (I know *I've* managed to do it), and
I believe the same is pretty much true for writing functional code.

"Functional code" is a rather broad term, but one popular feature of
many functional languages is pattern matching[1], which Ruby doesn't
support.

Lots of functional languages lack pattern matching. Scheme, for
example. One can write Scheme-styled code in Ruby.

Indeed, the entire structure of functional programs is generally alien
enough to OO or procedural languages that any mapping you could do
would be difficult to describe as being functional, except in the
broadest sense.

Procedural and OO languages are very similar. Functional languages
require a different mindset, and I believe that it *is* a stretch to
claim that you can do functional programming in Ruby.

I disagree. Ruby lacks purely functional I/O, but so do Scheme and
Lisp. I don't see why Scheme would surpass Ruby's functional
programming ability.

[1] in the sense of matching the appropriate function based on the
arguments.
Consider the function sum(). Given a recursive procedural definition:

int sum( array ) {
if ( length( array ) == 0)
return 0;
else
return array[0] + sum( subset( array, 1, length( array ) - 1 ) );
}

In Ruby(procedural) this might be:

sum( array ) {
return 0 if length( array ) == 0
return array[0] + sum( subset( array, 1, -1 ) )
}

(being pedantic, and avoiding *all* OO methods). In Haskell, this
code would be:

func [] = 0
func (x:y) = x + func( y )

Converting the Haskell code to Ruby would give you the same code as
the procedural version (again, if you avoid all of the OO
constructions that you possibly can). I don't think I'd be
exaggerating if I said that, in general, Ruby( procedural ) == Ruby(
functional ), and yet, functonal and procedural programming are
fundamentally different styles.

In Scheme, sum would be:

(define (sum xs)
(if (null? xs)
0
(+ (car xs) (sum (cdr xs)))))

Translating to Ruby, we get:

class Array
def sum (xs)
if xs.empty? then
0
else
xs.first + xs.tail.sum
end
end

def tail
self[1..-1]
end
end

You're mistaken in believing that functional programs must lack method
calls. Scheme's CAR and CDR are just as `object-oriented' as Ruby's
first and tail. Ruby just makes it explicit.

mikael

 

[Joel VanderWerf]

In Scheme, sum would be:

(define (sum xs)
(if (null? xs)
0
(+ (car xs) (sum (cdr xs)))))

Ruby doesn't optimize this tail recursion, but Scheme does. That's one
way Scheme could be said to be more "functional".

 

[Mikael Brockman]

Ruby doesn't optimize this tail recursion, but Scheme does. That's one
way Scheme could be said to be more "functional".

There's no tail recursion in that function, but you have a point. TCO
would be nice, but it's easy to perform the optimization manually.

mikael

 

[Joel VanderWerf]

There's no tail recursion in that function, but you have a point. TCO
would be nice, but it's easy to perform the optimization manually.

Oops. Quite right. The (+ ...) prevents that. I think sum can be written
in a TCO-friendly way though: call a second function sum2 that has two
args, an accumulator and xs, which recurses with

(sum2 (+ acc (car xs)) (cdr xs))

Anyway, once you've manually optimized a tail call in ruby, it doesn't
look very functional any more, does it? Maybe I'm not understanding your
suggestion...

 

[Mikael Brockman]

Oops. Quite right. The (+ ...) prevents that. I think sum can be
written in a TCO-friendly way though: call a second function sum2 that
has two args, an accumulator and xs, which recurses with

(sum2 (+ acc (car xs)) (cdr xs))

Anyway, once you've manually optimized a tail call in ruby, it doesn't
look very functional any more, does it? Maybe I'm not understanding
your suggestion...

It doesn't _look_ very functional, but it is. The same concepts are
embodied in

def sum (xs)
tally = 0
until xs.empty?
tally += xs.first
xs = xs.rest
end
tally
end

as in

(define (sum xs)
(sum-acc xs 0))

(define (sum-acc xs acc)
(if (empty? xs)
acc
(sum-acc (cdr xs) (+ (car xs) acc)))).

Real programmers can write Scheme in any sufficiently powerful language.
It's probably possible in Java, but extremely tedious. Ruby is much
better. The notation for closures in Ruby is even _better_ than the
lambda of Scheme!

mikael

 

[Martin DeMello]

Ruby doesn't optimize this tail recursion, but Scheme does. That's one
way Scheme could be said to be more "functional".

http://www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf
suggests that no language should be called properly OO unless it does
tail call optimisation

martin

 

[Hal Fulton]

http://www.ccs.neu.edu/home/matthias/Presentations/ecoop2004.pdf
suggests that no language should be called properly OO unless it does
tail call optimisation

Heh. I hereby pronounce that no language is truly OO unless its name
starts with an R and ends with a Y.


Hal

 

[Mikael Brockman]

Heh. I hereby pronounce that no language is truly OO unless its name
starts with an R and ends with a Y.

A noble initiative, but Felleisen's is slightly less arbitrary. He
shows how a properly OO linked list needs TCO.

module ProperlyOO
class Cons
def initialize (car, cdr)
@car, @cdr = car, cdr
end

def length
# This requires tail-call optimization.
1 + cdr.length
end
end

class Empty
def length
0
end
end
end

module ImproperlyOO
class Cons
def initialize (car, cdr)
@car, @cdr = car, cdr
end

def length
# This doesn't require TCO, but it's ugly.
length = 0
current = self
until current.kind_of? Empty
length += 1
end
length
end
end

class Empty
def length
0
end
end
end

I guess the iterative version would be better with a method is_empty?,
but I'm just the messenger.

mikael

 

[Stefan Schmiedl]

(more or less):
...

Mid-1980's -- BBC Micro (Acorn) - BASIC Interpreter
6502 processor (OK, not the best

And, of course, it ran at twice teh clock speed of the Apple ][

Ok, fellow dinosaurs, who's up for writing a Forth in Ruby as a warmup
for some work worthy of Real Programmers, namely a Ruby in Forth?

Cheers,
s.

 

[gabriele renzi]

Ok, fellow dinosaurs, who's up for writing a Forth in Ruby as a warmup
for some work worthy of Real Programmers, namely a Ruby in Forth?

well, at least there was a package named Ratlast for fothr in ruby
usage, IIRC

 

[Sean Russell]

Lots of functional languages lack pattern matching. Scheme, for
example. One can write Scheme-styled code in Ruby.

In this, and following posts, you make the claim (directly and
indirectly) that all languages are functional languages, rendering the
term "functional language" meaningless, or at least useless. I
oppose attempts to generalize words into meaninglessness.

There *are* good, useful definitions of what constitutes a functional
languages, and Ruby does not match the criteria for most of them.
Probably the most fundamental of all criteria is that the language
does not allow side-effects, such as assignment.

I'll concede that, if you're allowed to write a lot of non-functional
code in the form of a library, it is possible to write a Ruby
application that is visually indistinguishable from a purely
functional program. I'll even grant that it is possible to write a
few very short programs using only the inherited functions in Kernel,
ignoring the fact that math in Ruby is, in fact, method calls on
objects rather than function calls or primative operations. However,
I'll maintain that this is a far cry from satisfying the claim that
one can do functional programming in Ruby.

I disagree. Ruby lacks purely functional I/O, but so do Scheme and
Lisp. I don't see why Scheme would surpass Ruby's functional
programming ability.

Because they satisfy several other criteria that are usually
attributed to functional programming languages, such as support for
optimized tail recursion. They may not be "purely" functional, but
Ruby is about as contaminated a functional language as is possible to
achieve.

And maybe that's a more useful way of looking at this. I doubt that
there are many languages that are less "functional" than Ruby.

You're mistaken in believing that functional programs must lack method
calls. Scheme's CAR and CDR are just as `object-oriented' as Ruby's
first and tail. Ruby just makes it explicit.

No they aren't. car and cdr aren't methods on objects. They are
functions that take objects as arguments.

Now, a better example would have been to point out OCaml, which is
*both* functional *and* OO, something which I believe is fundamentally
impossible, in that it can't be pure OO and pure functional. However,
it has a lot of features associated with functional languages, and
many features associated with OO, so it can claim to be a functional
language with OO capabilities.

--- SER

 

[Sean Russell]

You're mistaken in believing that functional programs must lack method
calls. Scheme's CAR and CDR are just as `object-oriented' as Ruby's
first and tail. Ruby just makes it explicit.

Incidentally, from the comp.lang.functional FAQ:

"Functional programming is a style of programming that emphasizes the
evaluation of expressions, rather than execution of commands. The
expressions in these language are formed by using functions to combine
basic values. A functional language is a language that supports and
encourages programming in a functional style."

and from NIST:

"Definition: A language that does not allow any destructive
operation---one which overwrites data---such as the assignment
operation. Purely functional languages are free of side effects, i.e.,
invoking a function has no effect other than computing the value
returned by the function."

--- SER

 

[Joel VanderWerf]

Incidentally, from the comp.lang.functional FAQ:

"Functional programming is a style of programming that emphasizes the
evaluation of expressions, rather than execution of commands. The
expressions in these language are formed by using functions to combine
basic values. A functional language is a language that supports and
encourages programming in a functional style."

and from NIST:

"Definition: A language that does not allow any destructive
operation---one which overwrites data---such as the assignment
operation. Purely functional languages are free of side effects, i.e.,
invoking a function has no effect other than computing the value
returned by the function."

--- SER

Well, ruby _is_ based on evaluation of expressions. Even control
structure expressions have value (though the value of a while always
seems to be nil).

Also, OOP and FP can coexist. String#gsub, for example, is a pure
function that could be implemented differently in different instances of
String. Much of the ruby library could (in theory) be implemented in
this way.

However, Ruby encourages using objects to store state that changes
during execution of the program, so I wouldn't argue that ruby was a
functional language, just that it has some functional aspects.

 

[James Britt]

In this, and following posts, you make the claim (directly and
indirectly) that all languages are functional languages, rendering the
term "functional language" meaningless, or at least useless. I
oppose attempts to generalize words into meaninglessness.

There *are* good, useful definitions of what constitutes a functional
languages, and Ruby does not match the criteria for most of them.
Probably the most fundamental of all criteria is that the language
does not allow side-effects, such as assignment.

Interesting. Paul Graham, author of a few books on Lisp, has a new book
out called Hackers and Painters. It's a collection of essays, most if
not all of which are, I believe, on his web site (paulgraham.com).

There's an essay ("Revenge of the Nerds") toward the end of the book,
part of sequence that sings the praises of (surprise) Lisp, and in it he
mentions that many of the newer programming languages seem to follow a
pattern of each one (perl -> python -> ruby ) being increasingly more
like Lisp. Ruby is mentioned only sporadically in his book, and mostly
in the latter chapters, but in this essay he goes so far as to say that
if you showed Lisp to hackers in 1975, and said it was a dialect of Lisp
with some syntax added, no one would argue otherwise.

Later in the book he compares power/elegance in various languages, and
uses an simple Lisp example of a function that returns another function,
with the returned function parameterized by an argument passed tot he
creating function. His first example in another language is in Ruby;
the code is nearly identical. Other languages (perl, python, java, C)
fair less well in accomplishing this task in a clean, straight-forward
manner (if they can do it at all).

For me, the question is whether Ruby allows one to do proper functional
programming, not that it forces one to do so.


James