Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Why I don't use Ruby.

Reply
Thread Tools

Why I don't use Ruby.

 
 
Stefan Schmiedl
Guest
Posts: n/a
 
      07-03-2004
I know I shouldn't, but I'm going to anyways ...

On Fri, 2 Jul 2004 08:08:01 +0900,
Lothar Scholz <(E-Mail Removed)> wrote:
>
> 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.
 
Reply With Quote
 
 
 
 
bruno modulix
Guest
Posts: n/a
 
      07-04-2004
Carl Youngblood a écrit :
> OCaml is as dynamic as LISP


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

Bruno
 
Reply With Quote
 
 
 
 
bruno modulix
Guest
Posts: n/a
 
      07-04-2004
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
 
Reply With Quote
 
Gawnsoft
Guest
Posts: n/a
 
      07-05-2004
On Sat, 3 Jul 2004 20:21:46 +0100, "daz" <(E-Mail Removed)> wrote
(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
 
Reply With Quote
 
Lothar Scholz
Guest
Posts: n/a
 
      07-05-2004
Hello Gawnsoft,

G> On Sat, 3 Jul 2004 20:21:46 +0100, "daz" <(E-Mail Removed)> wrote
G> (more or less):
G> ....
>>Mid-1980's -- BBC Micro (Acorn) - BASIC Interpreter
>> 6502 processor (OK, not the best


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

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's




 
Reply With Quote
 
Sean Russell
Guest
Posts: n/a
 
      07-06-2004
James Britt <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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
 
Reply With Quote
 
Mikael Brockman
Guest
Posts: n/a
 
      07-06-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Sean Russell) writes:

> James Britt <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>> 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



 
Reply With Quote
 
Joel VanderWerf
Guest
Posts: n/a
 
      07-06-2004
Mikael Brockman wrote:
> 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".


 
Reply With Quote
 
Mikael Brockman
Guest
Posts: n/a
 
      07-06-2004
Joel VanderWerf <(E-Mail Removed)> writes:

> Mikael Brockman wrote:
>> 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".


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



 
Reply With Quote
 
Joel VanderWerf
Guest
Posts: n/a
 
      07-06-2004
Mikael Brockman wrote:
> Joel VanderWerf <(E-Mail Removed)> writes:
>
>
>>Mikael Brockman wrote:
>>
>>>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".

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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments