Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming Ruby

Ruby, Clojure, Ceylon: Same Goal, Different Results 138

snydeq writes "Charles Nutter, Rich Hickey, and Gavin King each discovered that 'simplicity' doesn't mean the same thing as they developed Ruby, Clojure, and Ceylon, respectively. 'Languages that are created with similar goals in mind may yield highly disparate final results, depending on how their communities understand those goals,' writes Andrew Oliver. 'At first, it surprised me that each language's creator directly or indirectly identified simplicity as his goal, as well as how differently the three creators and their languages' communities define what simplicity is. For Ruby, it is about a language that feels natural and gets out of your way to do what you want. For Clojure, it is about keeping the language itself simple. For Ceylon, it is a compromise between enabling the language to help, in King's words, "communicating algorithms to humans" and providing proper tooling support: the same general goal, three very different results.'"
This discussion has been archived. No new comments can be posted.

Ruby, Clojure, Ceylon: Same Goal, Different Results

Comments Filter:
  • by betterunixthanunix ( 980855 ) on Sunday June 17, 2012 @10:53AM (#40351829)
    Where is the information about Ruby or Ceylon? There are Clojure code snippets designed to illustrate the Clojure philosophy of "simplicity," yet no equivalent Ruby or Ceylon code. Overall, this article seems to be devoid of content...
    • by pmontra ( 738736 ) on Sunday June 17, 2012 @11:15AM (#40352053) Homepage

      There isn't. But this is how to do it in Ruby

      String.instance_methods.select {|m| m.match("sub")}
      => ["sub", "gsub!", "gsub", "sub!"]

      instance_methods returns an array. select iterates on it calling a code block on every element. If the block returns true it adds the element to the array it will return at the end of the loop. |var| is how the element is passed to the block. Blocks can span over multiple lines, it's usual to wrap them inside a do..end but { } still work.

      String.instance_methods.select {|m| m =~ /sub/}} is the perlish alternative.

      I didn't match "last" as in the article because Ruby's String has no methods with "last" in their name.

      • Re: (Score:3, Informative)

        by MarchHare ( 82901 )

        A slightly better way, IMHO:

            String.instance_methods.grep /sub/

        • by pmontra ( 738736 )
          More compact but people without a *nix background won't understand it without looking at the docs. Anyway I think I'll start using it :-)
          • by PCM2 ( 4486 )

            Programmers with zero *nix background puzzle me.

            • Programmers with zero *nix background make sure you get your dole check and ensure that the local kwik-e mart has goods for you to spend it on.

          • I prefer the more concise "".methods[/sub/].

            • by pmontra ( 738736 )

              Does that work?

              > "".methods[/sub/]
              TypeError: can't convert Regexp into Integer

              I tried it with 1.9.3 and 1.8.7. Array's rdocs don't list a [] method with a regexp argument.

      • "String.instance_methods.select {|m| m =~ /sub/}} is the perlish alternative."

        Actually your "Perlish" form is the preferred way to do it in Ruby.

        On the other hand, that's one of the nice things about Ruby. There are different ways to get things done. There are a few people who might consider that a flaw, but that does not seem to be the general consensus.

  • by Anonymous Coward on Sunday June 17, 2012 @10:59AM (#40351909)

    If it gains traction, then it will have to deal with feature creep (keeping up with the new hot languages), standard library bloat, backward compatiblity, and differing interpretations of the spec by compilers and developers. Then it becomes no longer simple.

    Java is the classic example. It's hard not to giggle or mutter "WTF?" when you read Sun's original positional paper claiming the language was "simple".

    • Well, from my understanding changing times/styles also contribute to this. Wasn't C once considered a relatively "high" language when it first emerged and is now more of a "middle" language?

      Compared to rubbing two sticks together or use of flint matches are "simple", but now we have lighters.

      • "Wasn't C once considered a relatively "high" language when it first emerged and is now more of a "middle" language?"

        No, C has never been considered a "high level" language in the Computer Science world, when compared to its predecessors such as BASIC and PASCAL. (Say what you want about BASIC, but it *is* a high level language, and vastly more so today than when it first appeared.)

        People who insist that C a "high-level" language (you did not do that) make me cringe. At best, C is a "mid-level" language, lying somewhere between a high-level language and Assembly.

      • by jeremyp ( 130771 )

        C is absolutely fairly and squarely a high level language.

        What features do Pascal and Fortran and Cobol have that make them high level and C not?

    • Re: (Score:3, Insightful)

      by phantomfive ( 622387 )

      Java is the classic example. It's hard not to giggle or mutter "WTF?" when you read Sun's original positional paper claiming the language was "simple".

      It was, and still is, simple compared to C++, or ADA.

      Although at the time, there was the quote "Claiming Java is easier than C++ is like saying that K2 is shorter than Everest." And there is some truth to that.

    • Java combines the natural and easy syntax of C with the blazing speed of Smalltalk.

      *Tadum* *Crash* *Thud*

      Thank you, thank you, I'm here all week. Try the fish and tip your waitor.

  • Mad (Score:3, Insightful)

    by Anonymous Coward on Sunday June 17, 2012 @11:03AM (#40351941)

    This makes me mad to see a link to an article about "9 top languages", in which some major (established) players of the field such as Haskell or OCaml are not mentioned, while languages-to-be get some nice coverage.

    Creating a programming language boils down to being fashionable, rather than doing something neat.

     

  • And yet none of these languages is actually simple. Ruby is readable and consistent, Clojure is sparse but confusing, and Ceylon is unknown (ok, maybe it's simple, but I'm not going to learn it to find out).
    • by Osgeld ( 1900440 )

      apparently its a java remix

      • "apparently its a java remix"

        Not even close.

        Its syntax is nothing like Java's. Its structures are nothing like Java's. Both being high-level languages, of course it is almost inevitable that they deal with some of the same data structures, like strings and arrays. But program structure is markedly different.

        When it was first becoming popular outside Japan, various comparisons showed Ruby to average about 20% as many lines of code to get the same job done as Java programs that did the same things.

        Granted, those demonstrations m

      • It's not really, but of the 3 it's the most similar maybe. We're trying not to stray too far away from familiar territory for Java developers.

  • by metrometro ( 1092237 ) on Sunday June 17, 2012 @11:19AM (#40352093)

    Simple leads to different results because it usually means something more like "quality". Simple is in itself not an absolute value. Instead, the simplicity of something is a ratio of its value to its sucking. So what they're really saying is "I'd like to achieve high value outcomes with the least amount of sucking along the way." There's a lot of ways to do that.

  • by slasho81 ( 455509 ) on Sunday June 17, 2012 @11:41AM (#40352253)
    Rich Hickey's keynote talk from Strange Loop: Simple Made Easy [infoq.com]. Unlike the posted fluff article, this talk is easily the most insightful talk you've seen this year, or your money back.
    • He's a smart guy and that's a good talk, but his arguments about simplicity are a little weird. Trying to use the etymology of the word 'simple' as a justification for design choices? I found Clojure to be a language where first you had to make the leap-to-lisp before it was easy, and making that transition wasn't helped by having the JVM/standard lib/Java syntax as prerequisites (not to mention lein/ant/maven/ide configs/etc...).

      Heh, consider what this description says about clojures simplicity: "Leiningen

      • by cduffy ( 652 )

        Heh, consider what this description says about clojures simplicity: "Leiningen is for automating Clojure projects without setting your hair on fire."

        Keep in mind that Clojure users could use Ant or Maven or Grails for their build system, and all of those work perfectly fine; Leiningen, on the other hand, is simpler than any of them.

        Clojure developers have a high bar for simplicity, albeit measured in a way that might not make much sense to anyone who doesn't first grok LISP.

  • Matz designed Ruby with "principle of least surprise" in mind. No, not for you. you might be surprised or not. It's whatever causes least surprise to the creator Matz. 8D

    • by murdocj ( 543661 )

      Yes. And perhaps Ruby is simple... to Matz. One important point: simpler != fewer characters in source code.

      • "One important point: simpler != fewer characters in source code."

        But you can be as verbose as you like in Ruby. Unlike many other languages, the "standard" way of getting things done is not mandatory. You have options.

        So you can make your source code compact, or, if you think that's not easily readable, expand it to a "simpler" form.

        Case in point: while working on a project, one of my fellow workers (very smart guy) refactored some of my code to a single line of nested lambdas.

        I examined his code very carefully. But the simple fact was that it was too hard to me

        • I love Ruby. It's easily my favorite language right now.

          With that said, more verbose doesn't always equate to easier to read nor does terse and short equate to simple. I'm very happy with Ruby's flexibility in that regard.

          • I can hardly wait for Ruby 2.0. They have promised at least the ability to bytecode-compile scripts and that should do a great deal to promote it for making desktop apps. Currently, it is not usually used for desktop apps because your code is 100% exposed.

            Even MacRuby does not really compile, but exposes your raw code. JRuby does, of course, but it's not 100% compatible and requires JVM. JRuby is an admirable project, don't get me wrong... but having native bytecode compilation would be tremendous.

            One
            • It's trivial to decompile Java bytecode, and even decompiling machine code isn't all that hard. It really doesn't matter, just use Ruby for desktop apps if you like it.

              • "It's trivial to decompile Java bytecode, and even decompiling machine code isn't all that hard. It really doesn't matter, just use Ruby for desktop apps if you like it."

                It is trivial for knowledgeable people to decompile bytecode. It isn't trivial for the majority of commercial software customers. And it is far more trivial to simply read the raw code from non-compiled programs.

                Further, don't confuse the task of decompiling with the task of making sense of the decompiled code. In most cases there are no meaningful variable names; instead they get named things like "integer0", or whatever the decompiler decides is a good designation. And it is not generally well-formatte

  • Functions are special cases of relations. Procedures are functions between states (ie: STATEments).

    Stop looking under the lamp post for the keys.

There are two ways to write error-free programs; only the third one works.

Working...