Beefy Boxes and Bandwidth Generously Provided by pair Networks Frank
Problems? Is your data what you think it is?
 
PerlMonks  

Ruby vs Perl vs LISP; the killer feature lacking in Ruby

by filesurfer (Novice)
on May 20, 2012 at 05:13 UTC ( #971463=perlmeditation: print w/ replies, xml ) Need Help??

First off, the title sounds like a "this language is better than this language" rant. I don't intend that. I intend to point out to something that I discovered while learning Ruby.

LISP is a language that has fallen behind, in terms of popularity compared to other languages like Python, PERL, C, and Java. It's used in the science crowd alot, but mainstream programming its arguable it has dropped back a bit.

Ruby is the new kid on the block and is jockying for positioning. I picked it up to learn it. It just hit me a while ago that Ruby, in it's innate object system, forces a certain level of abstraction onto the "mind space" of the deveoloper. So it influences the deveopers thinking in a negative way. LISP on the other hand, is pliable and simple enough for the dev to flow with his code map to his way of organizing the app at the time. Ruby lang maps the devs mind around "Ruby thinking." PERL in it's glory also does more of what LISP does, rather than Ruby. PERL is simple enough that the dev's mind takes it and flows with it so much that the level of abstraction optimal for the program is done automatically by the brain; so instead of thinking in PERL or LISP, the dev thinks in terms of the programming problem and the simplicity of LISP or PERL makes the expression of those thoughts very transparent and natural. This vital process if harder with Ruby since it's more disjointed in it's design. The language doesn't flow in the brain like LISP or PERL. Ruby was made to be easy for devs to code in, as in easier to get work done, but I think that aim had the cost of losing the ease of expression like in LISP and PERL. Ruby destroys "flow," or that ultra concentrated, focused state of mind. LISP and PERL doesn't.

What do you think?

Comment on Ruby vs Perl vs LISP; the killer feature lacking in Ruby
Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by Anonymous Monk on May 20, 2012 at 05:40 UTC

    What do you think?

    I think you need more * :)

      Need more of... elaborate please :)
      Oh, I just caught what you said. Yes I might need more reasons, but I think that is a key feature that LISP and PERL each have over Ruby. Ruby does kind of what JAVA does, it requires the dev to wrap their thinking, and map the organization of their code around the limitations of the language. With PERL, the language becomes a new tool for working on each project, like when LISP becomes a domain specific language. Of course you can do that with Ruby too, but the language design will give you more work than any good coder will bargain for.

        FWIW, it's LISP, Perl, and Java rather than the strange capitalizations you've used.

Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by zwon (Monsignor) on May 20, 2012 at 10:12 UTC
    aim had the cost of losing the ease of expression ... destroys "flow," or that ultra concentrated, focused state of mind

    Well, judging by your post you're possibly right, RUBY has destroyed your ease of expression. I'd recommend you to do some Perl every day to restore your mental abilities, and beware of JAva - it may (and certainly will) make things worse ;)

Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by zentara (Archbishop) on May 20, 2012 at 10:52 UTC
    What do you think?

    I think it's supposed to be Perl not PERL. All caps is like shouting and destroys that ultra concentrated, focused state of mind. Why did you all-cap LISP and PERL, and not Ruby, Python, and Java?

    Consistency is a good THING.


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by tobyink (Abbot) on May 20, 2012 at 11:04 UTC

    You don't mention it explicitly, but my impression is that you've been using Lisp and Perl for a lot longer than you've been using Ruby. If that is indeed the case, then it should not be especially surprising that when using Lisp and Perl you don't need to devote as much time to thinking about the model, syntax, APIs and idioms of the programming language than you do with Ruby, a language you have less experience with.

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

      I find that using LISP interrupts the flow of my thought processes much more than Perl or Ruby. Probably because I've done similar amounts of stuff in Ruby and Perl, and don't really know any LISP. Then again, it could be the all caps vs. normally capitalized names...

Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by eyepopslikeamosquito (Canon) on May 20, 2012 at 12:10 UTC

    Ruby, in it's innate object system, forces a certain level of abstraction onto the "mind space" of the deveoloper. So it influences the deveopers thinking in a negative way.

    Ruby destroys "flow," or that ultra concentrated, focused state of mind.

    I wonder what the folks at rubyflow: the ruby community blog would make of this? :)

    You don't provide a shred of evidence for your eccentric point of view. Or even an indication of how you happened upon this deep psychological epiphany. I would be interested to learn, ideally from specific examples, what caused you to form the opinion that "Ruby destroys flow".

    Though initially gobsmacked by the originality and audacity of your post, I am sorry, but my considered opinion is that it is psychobabble.

Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by eyepopslikeamosquito (Canon) on May 20, 2012 at 22:09 UTC

    To make a more compelling case that "Ruby destroys flow", you need to analyse some specific code examples.

    To give an illustrative example, in this Builder AU interview, Damian Conway analyses a Java program that prints "Hello World":

    Programming in Java always feels like a chore to me, because the language so often gets in the way of the problem you're trying to solve. The cliched example is, of course, the well-known exercise of getting a language to print "Hello World". In Java, that's:

    class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } }
    It's a cheap shot to point out how syntactically overburdened that is, but it does illustrate a far more important point: that it's *cognitively* over-burdened too.

    To get the job done (i.e. print out a simple greeting), the Java programmer needs to understand the concept of classes, Java's particular class mechanisms and class declaration syntax, the concept of methods, Java's method syntax, the general concept of types, the specific concept of a void type, the concept of parameters and return types, Java's type and parameter syntaxes, the concept of arrays and Java's array declaration syntax, the concept of static methods, the concept of public class members, the concept of -- and Java syntax for -- method calls, the notion that method calls can return other objects which can then have method calls applied to them, the concept of class methods, the notion of a System class aggregating all system interactions, the concept of an I/O class mediating input and output, and the fact that "println" is an abbreviation for "print line".

    And *then* you can print "Hello World".

      That can be golfed down to just 80 characters.

      class H{public static void main(String[]a){System.out.println("Hello W +orld!");}}

      In Perl there's of course the 21 character solution, which can be reduced to 19 if STDERR is allowed.

      In PHP there's a 13 character solution.

      (I'm assuming that in all cases, "!\n" is required at the end.)

      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by sundialsvc4 (Monsignor) on May 21, 2012 at 12:11 UTC

    I’ve worked in way too many programming languages now (including one of my own invention) to pick any favorites, nor particularly to feel that the way of thinking imposed by one vs. the other is “onerous.”   I simply don’t, so to speak, indulge in flame-wars anymore.   (And I am not, by making that quip, saying that this is what this thead is.   I don’t.)   I also avoid arguments or business propositions that make heavy use of adjectives that end in “-er.”

    To me, the “importance of” the language does not lie in the language itself:   it lies in what has already been written and thoroughly debugged in it.   In the case of Perl, that’s CPAN.   Also significant to me is how easily and how successfully you can integrate what they did with what you did.   The way to get anywhere is by standing on the shoulders of giants.

    It takes time for any contributed library to develop surety and strength.   I witnessed that first-hand in a project that was supposed to replace “Perl code that worked” with Ruby code that was supposedly going to be better.   It was not.   The “gems” upon which this project was supposed to rely started producing messages like: not yet implemented.   And, most troubling, the project was well under way at the first time this deficiency was discovered.   I am not faulting the expert programmers who encountered this most-rude discovery.   I am not per se praising the Perl language for having the robust packages that happened to be written in it.   I would learn and use a language named Golf Ball if it possessed the best software packages.

    If your team has to write massive amounts of new source-code itself, it does not matter much what language(s) you are wasting your time and money in.

      Exactly, sundial. And this is why Java rules the world. CPAN nicely differentiates Perl from the pack of other 4GLs, but it's a child's toy compared to what exists in Java land. Just look at what is coming out of Apache alone, not to mention all of the independent development incubators (and not to mention -- really -- all the commercial software libs for Java out there...)

        Alas, in my three decades in this biz, nothing “rules the world.”   Although it may well be human nature that drives every new language to proclaim that it just did so.   The Lone Ranger rides his horse through the radio waves to the entertainment of all, but in real life there ain’t no silver bullet.   Sux...

        I daresay that, during the course of any given work week, most of us switch routinely from one language to another, including Java “of course,” and that we are most-often dealing with systems that involve more than one language and/or type of computer system at a time.   (Therefore, a “Perl” community most emphatically is not a “Perl-only” community.)

        Java is a fine tool.   If it could seriously have standardized on just one pseudo-machine implementation (as seen by the language, that is), it might well be a better one.   Ruby is a fine tool.   LISP is ... The First One.

        Nevertheless:   the moment the word, “versus,” enters into speech about computer programming languages, I do think that a key point has just been missed.   Computer programming tools (of all sorts ...) fundamentally co-exist.   Wholesale replacement of any technology is never a viable option; nor is it (almost) ever justifiable to the business.   Every technology that, all(!!) things considered, offers a pragmatic benefit will always be considered, but the total decision is never cut-and-dry and ought never be judged as being such.   This practical observation obviates much religious fervor.

        (Heh.   Did I just say that this entire thread is pointless?   Oops.   Me bad.   Have fun.)

      The way to get anywhere is by standing on the shoulders of giants.

      And what if the giants you like to walk all over had taken that same attitude?

      All those flat-pack libraries that you are so dependent upon wouldn't exist, and you'd be dead in the water.

      If your team has to write massive amounts of new source-code itself, it does not matter much what language(s) you are wasting your time and money in.

      I'm not a FaceSpace, MyBook, twittingGram fan, but the level & depth of the technology behind the recent IPO shows that you cannot throw a few pre-existing modules together and create success; you have to (re-)invent a whole shitload of technologies too.

      You recently cried wolf (“Be afraid. Be very afraid.”) on the subject of unit labor costs; but completely miss the fact that it is only once jobs are reduced to line assembly place-fillers, that they become commoditized.

      Churning out yet another shopping cart by mix'n'matching few self-assembly libraries is the very epitome of that commoditzation. The guys researching, inventing, writing, and maintaining those libraries should have healthy and financially secure futures. Those using them; not so much.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by Jenda (Abbot) on May 21, 2012 at 13:27 UTC

    But there are killer features in Ruby. Plenty actually. Features that kill it, that is. Its cryptic error messages. Its fragile and incorrectly designed statements-end-on-newline-or-maybe-not and leading-whitespace-matters syntax. The names of almost all list related built-ins. The syntax sugar for methods accepting one block/closure - the syntax in itself is silly, but the worst thing is that it restricts you to just one such parameter unless you jump through hoops even most "seasoned" Ruby developers are not aware of. The cool and meaningless names of even the most basic libraries (guess, without looking, what's hpricot for!). The fact that not only you can't force yourself to declare variables, there's simply no way to declare one even if on a specific place you did want to be sure you are working with a new X ("hey, a method should have no more than five lines. There's no need to declare variables." - "Sorry, I've got five hundred methods already, I've run out of names!").

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

      it restricts you to just one such parameter unless you jump through hoops even most "seasoned" Ruby developers are not aware of

      Is it easy to do this in Perl? It's not possible at all, afaik.

      multifoo { $_ * 2 } { foo($_) } @things;
      I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
        multifoo sub { $_ * 2}, sub { foo ($_) }, @things;
        hoopsy hoops, right?

        And now the method body:

        sub onefoo { my ($reasonably_named_sub, @params) = @_; whatever; for my $foo (tweaked @params) { $reasonably_named_sub->($foo); } } sub multifoo { my ($toDo, $filter, @params) = @_; whatever; for my $foo (grep $filter->(), tweaked @params) { $toDo->($foo); } }
        Yieieiaield anyone?

        There is a little syntactic sugar for functions (not methods) in Perl, but the difference between using the sugar and not is tiny. If I need to pass two "pieces of code" into my subroutine, I pass them, I name them and I call them the same way I would if I had just one.

        In Ruby, if your method gets a single block/closure parameter, you do not get to name the parameter, you use the ill-named statement yield and it kinda, behind the scenes, maybe, works. If you need to pass two you are, basically, screwed. But then 640KB ought to be ... I mean one block ought to be enough for anybody.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

        As well as Jenda's suggestion, it's also possible to declare a little wrapper like this:

        sub also (&;@) { return @_; }

        Enabling you to do this:

        multifoo { $_ * 2 } also { foo($_) } @things;

        This is what Moose does for its type constraints system, providing little wrappers like via, where and message so you can write code like:

        subtype 'ModernDateTime' => as 'DateTime' => where { $_->year() >= 1980 } => message { 'The date is not modern enough' };
        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://971463]
Approved by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (12)
As of 2014-04-23 17:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (548 votes), past polls