Ruby

Every 15 years or so, languages are replaced with better ones. C was replaced by C++, at least for large-scale application development by people who needed performance but desperately wanted data types too. C++ is being replaced by Java, and Java will doubtless be replaced with something better in seven years — well, seven years after it finishes replacing C++, which evidently hasn't fully happened yet, mostly because Microsoft was able to stall it before it became ubiquitous on the desktop. But for server-side applications, C++ is basically on its way out.

Perl will be gone soon, too. That's because a new language called Ruby has finally been translated into English. Yep, it was invented in Japan, of all places — everyone else was as surprised as you are, since Japan's known for its hardware and manufacturing, but not for its software development. Why, is anyone's guess, but I'm thinking it's the whole typing thing; I just can't imagine they were able to type fast enough before, what with having an alphabet with ten thousand characters in it. But Emacs got multibyte support a few years ago, so I can imagine they're pretty dang fast with it now. (And yes, they use Emacs — in fact Japanese folks did the majority of the Mule [multibyte] support for Emacs, and it's rock-solid.)

Anyway, Ruby stole everything good from Perl; in fact, Matz, Ruby's author (Yukihiro Matsumoto, if I recall correctly, but he goes by "Matz"), feels he may have stolen a little too much from Perl, and got some whale guts on his shoes. But only a little.

For the most part, Ruby took Perl's string processing and Unix integration as-is, meaning the syntax is identical, and so right there, before anything else happens, you already have the Best of Perl. And that's a great start, especially if you don't take the Rest of Perl.

But then Matz took the best of list processing from Lisp, and the best of OO from Smalltalk and other languages, and the best of iterators from CLU, and pretty much the best of everything from everyone.

And he somehow made it all work together so well that you don't even notice that it has all that stuff. I learned Ruby faster than any other language, out of maybe 30 or 40 total; it took me about 3 days before I was more comfortable using Ruby than I was in Perl, after eight years of Perl hacking. It's so consistent that you start being able to guess how things will work, and you're right most of the time. It's beautiful. And fun. And practical.

If languages are bicycles, then Awk is a pink kiddie bike with a white basket and streamers coming off the handlebars, Perl is a beach cruiser (remember how cool they were? Gosh.) and Ruby is a $7,500 titanium mountain bike. The leap from Perl to Ruby is as significant as the leap from C++ to Java, but without any of the downsides, because Ruby's essentially a proper superset of Perl's functionality, whereas Java took some things away that people missed, and didn't offer real replacements for them.

>>119 (surry tu rooeen zee echeeefement)
Declereeng zee ignurunce-a ooff sumetheeng, duesn't meke-a deeseppeer: it leeke-a heeding yuoor heed in zee sund. Bork Bork Bork!
Boot here-a, yuoo try tu sey sumetheeng under zee sund, veethuoot uny knooledge-a ooff vhet heppens ebufe-a(becoose-a yuoo dun't vunt tu knoo) und ell yuoo cun theenk ooff is zee cuncepshuns ooff Zee Ooootseede-a, leeke-a un eleeee vurld vheech moost be-a efueed et ell custs. Bork Bork Bork! Predeectebly yuoo oonly get sund in yuoor muoot und nut mooch ilse-a(seence-a telkeeng tu Zee Ooootseede-a, infulfes getteeng yuoor heed oooot ooff sund). Bork Bork Bork!

__________________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Felux It Estroom gemedef furoom: http://itestroom.phpbb3noo.cum
A deefffferent cuncepshun ooff suceeety, fery deefffferent frum thet vheech noo prefeeels, is in prucess ooff furmeshun.

>>117
Of course it's inefficient. Recursion is inefficient.

Iterative Fibonacci:
Time: O(n)
Space: O(1)

Recursive Fibonacci:
Time: O(n²) (O(fib n), to be more accurate)
Space: O(n)

Your Fibonacci:
Time: O(n)
Space: O(n)

>>122 So you admit that recursion is inefficient. Why you use it?



___________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
Remember happiness doesn't depend upon who you are or what you have; it depends solely on what you think.

>>122 Su yuoo edmeet thet recoorseeun is ineffffeecient. Bork Bork Bork! Vhy yuoo use-a it? Bork Bork Bork!



___________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Felux It Estroom gemedef furoom: http://itestroom.phpbb3noo.cum
Remember heppeeness duesn't depend upun vhu yuoo ere-a oor vhet yuoo hefe-a; it depends sulely oon vhet yuoo theenk.

>>123
I never said it wasn't inefficient. My point was that simulating recursion (not making a recursive algorithm iterative) is not a straightforward process.
It's not juts a matter of leaving a few gotos here and there and it's done.

>>122
Tailcalls can be turned into loops. Just the other day I tested 4 different implementations of fibs and the tail-recursive version vs iterative version turned out to have exactly the same performance (as your iterative fibonacci), and disassembling the compiled functions showed very similar code.

#include <stdio.h>
#include <stdlib.h>

typedef unsigned long ulong;

typedef struct {
    ulong step,
        n,
        res[2]; //0 stores fib(n-1), 1 stores fib(n-2).
} stack_frame;

ulong pseudo_recursive_fibonacci(ulong n){
    long stack_size=0;
    ulong step;
    stack_frame *stack;
    stack=(stack_frame *)malloc((n+1)*sizeof(stack_frame));
    stack[stack_size].step=0;
    stack[stack_size].n=n;
    while (stack_size>=0){
        if (stack[stack_size].n<2){
            if (stack_size){
                stack[stack_size-1].res[stack[stack_size-1].step]=stack[stack_size].n;
                stack[stack_size-1].step++;
            }
            stack_size--;
            continue;
        }
        step=stack[stack_size].step;
        n=stack[stack_size].n-stack[stack_size].step-1;
        switch (step){
            case 0:
            case 1:
                stack[++stack_size].n=n;
                stack[stack_size].step=0;
                break;
            case 2:
                if (stack_size){
                    stack[stack_size-1].res[stack[stack_size-1].step]=
                        stack[stack_size].res[0]+
                        stack[stack_size].res[1];
                    stack[stack_size-1].step++;
                }else
                    stack[0].n=stack[0].res[0]+stack[0].res[1];
                stack_size--;
        }
    }
    n=stack[0].n;
    free(stack);
    return n;
}

int main(){
    ulong a=0;
    for (;a<10;a++)
        printf("%d\n",pseudo_recursive_fibonacci(a));
    return 0;
}

>>125 Why you need this overhead of parameters and growing space for calculations?
Any tail-recursive function can be converted easily.


___________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
Let me have those letters and I'll send them to Santa's workshop in the North Pole.

>>125 Vhy yuoo need thees ooferheed ooff peremeters und grooeeng spece-a fur celcooleshuns? Bork Bork Bork!
Uny teeel-recoorseefe-a fooncshun cun be-a cunferted ieseely. Bork Bork Bork!


___________________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Felux It Estroom gemedef furoom: http://itestroom.phpbb3noo.cum
Let me-a hefe-a thuse-a letters und I'll send zeem tu Sunte's vurkshup in zee Nurt Pule-a.

>>127 Thats amazing(I wouldn't ever force myself to write such horribly inefficient code though).
 The whole overhead is getting to the surface.
I want every LISP ``enthusiast' to see how "elegant" and "simple" their recursive functions become when they get deconstructed to primitive operations.


_______________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
Having dreams is what makes life tolerable.

>>127 Thets emezeeng(I vuooldn't ifer furce-a myselff tu vreete-a sooch hurreebly ineffffeecient cude-a thuoogh). Bork Bork Bork!
 Zee vhule-a ooferheed is getteeng tu zee soorffece-a. Bork Bork Bork!
I vunt ifery LISP ``inthooseeest' tu see-a hoo "ilegunt" und "seemple-a" zeeur recoorseefe-a fooncshuns becume-a vhee zeey get decunstroocted tu preemitife-a oopereshuns. Bork Bork Bork!


_______________________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Felux It Estroom gemedef furoom: http://itestroom.phpbb3noo.cum
Hefeeng dreems is vhet mekes leeffe-a tulereble-a.

>>130
That's not a very strong argument. What I wrote up there is just the lower lever implementation of my previous post (>>79 ). It's possible to make disasters like that in any language.

>>132 But functional languages encourage it, unlike C buffer overruns, recursion is almost mandatory there.


_________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
...what we call education and culture is for the most part nothing but the substitution of reading for experience, of literature for life, of the obsolete fictitious for the contemporary real...

>>132 Boot fooncshunel lungooeges incuoorege-a it, unleeke-a C booffffer ooferroons, recoorseeun is elmust mundetury zeere-a. Bork Bork Bork!


_________________________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Felux It Estroom gemedef furoom: http://itestroom.phpbb3noo.cum
...vhet ve-a cell idooceshun und cooltoore-a is fur zee must pert nutheeng boot zee soobsteetooshun ooff reedeeng fur ixpereeence-a, ooff leeteretoore-a fur leeffe-a, ooff zee oobsulete-a feectitiuoos fur zee cuntempurery reel...

>>133
Which is why tail recursion exists:
(define (fib n)
    (define (iter i r-1 r-2)
        (if (= i 0)
            (+ r-1 r-2)
            (iter (-1+ i) (+ r-1 r-2) r-1)
        )
    )
    (if (< n 2)
        n
        (iter (- n 2) 1 0)
    )
)

As opposed to just:
(define (fib n)
    (if (< n 2)
        n
        (+ (fib (-1+ n) (- n 2)))
    )
)

The former is iterative and the latter is recursive.

>>135 Yes, this (iter i r-1 r-2) is storing variables as >>80 except they are passed in parameters.



________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
The basic objectives and principles of war do not change.The final objective in war is the destruction of the enemy's capacity and will to fight, and thereby force him to accept the imposition of the victor's will.

>>135 Yes, thees (iter i r-1 r-2) is stureeng fereeebles es >>80 ixcept zeey ere-a pessed in peremeters. Bork Bork Bork!



________________________________________________
http://xs141.xs.to/xs141/09303/av992393.jpg
Felux It Estroom gemedef furoom: http://itestroom.phpbb3noo.cum
Zee beseec oobjecteefes und preenciples ooff ver du nut chunge-a.Zee feenel oobjecteefe-a in ver is zee destroocshun ooff zee inemy's cepeceety und veell tu feeght, und zeereby furce-a heem tu eccept zee impuseeshun ooff zee feectur's veell.

>>133
FV, you may think it's a disaster, but if you examine the disassembly of a tail recursive implementation of fibs, you'll find out it actually uses a simple imperative implementation underneath, much simpler than >>127's code. You're also forgetting how most CPUs work: they have a stack for a purpose, and if tailcall elimintation takes place, there's no recursive calls involved at all.

Not all languages supporting the functional paradigm force you to use tail recursion. I could easily post a 10 page practical proof showing exactly how these things work in practice, but that would just mean that IHBT.

Please try to ignore troll posts.

>>138
He isn't forgetting. He's simply trolling. Ignoring him is the only path to victory.

A strange game. The only winning move is not to play.

>>141
(Score: +5, Funny)