Yes. Ruby is beautiful when you come from PHP or Java or C++. If you come from Python it's meh because it's a very similar language (though the community is different and a number of recipes/best practices are very different) at the syntactic and at the semantic levels, and if you come from Lisps, from Smalltalk, from ML or Haskell, etc… then it's not "meh" it's "ugh", because the language is far more complex less orthogonal and far more full of weird corner-cases than what you come from.

TFAA came to Ruby from Java, so Ruby was like seeing the Sistine Chapel for the first time.

Likewise (and this is just a throwaway argument, not the general point I'm trying to make), Lisp may be more elegant conceptually than Ruby, but when trying to find an individual incorrect line of code to make a change, Lisp's "elegant" uniformity actually hinders scanning, whereas Ruby's bumpy, "inelegant" syntax gives your eyes regularized shapes to abstract sections of code into, and thus visually skip them without having to read into their contents.

However, as the mouse's elegance matches well with a paint program, Lisp matches well with Turing-complete data-specifications ("code as data.") Usability is not a one-dimensional spectrum, like your partial ordering of "beauty" above, but rather a consideration made separately for each task an interface is used for.

What's the last useful LISP program you have used? What proportion does it consist among the other useful programs you use?

Was that a subtle dig at those who spend too much time on HN?

Given that close to 100% of my time is spent in XMonad, and >50% of my time is spent in Emacs, and every session involves at least some interaction with my collection of scripts... I'd say I use quite a lot of useful programs written in those fanfare-laden languages.

It's just a personal preference, but I find anonymous code blocks to be a lot more elegant and intuitive than decorators + with statements + for comprehensions. I also like that classes are open, and that you can execute code inside the declaration of a class and that self is implicit ... making tasks suited for the __metaclass__ concept in Python trivial.

I also find Lisp / Haskell and ML to be really ugly ... as in, I could never look over a piece of code and understand what it is doing without learning the language first (with the learning curve being as steep as it gets).

     the language is far more complex less orthogonal and far 
     more full of weird corner-cases than what you come from

E.g. I don't appreciate that ML doesn't have a simple concept like operator overloading, or that in LISP every DSL still looks like LISP. I don't like that a Smalltalk application is not portable between implementations or that applications are big, monolithic images of the virtual machine with everything included, even the IDE.

It's easy to get into these mine-is-bigger-than-yours contests, especially with languages, but you know what works better than formulating half-baked opinions?

Results. It's a lot better to shut up and show me some code ;)

2. The learning curve of those languages is not bigger then the learning curve of other languages. Time time I spend with making pretty OO designs in school was way bigger then the time it took me to learn clojure and FP in general but this of course is a issue we can not solve. I just don't like it if people say something as if it is a fact.

3. Is it more convenient to do this array.select &:even? better then (filter even? array)

The later seams more intuitive to me and I didn't have to learn more syntax.

4. In Lisp not every DSL looks like Lisp.

If only it wasn't for the fact that reality and history has proven otherwise...

Most programmers went form basic (lack of alternative) to C then C++ and now Java thats a path of simularity. Most where never exposed to functional programming and now the all have a hard time to switching there OO brain off.

The only proof we have of something being easier to learn, beside anecdotal evidence ("oh, I tried it and it was easy") is statistical empirical evidence, i.e people actually learning it. Well, people are not actually learning those languages. They are learning the "other ones".

(Where by people, I mean: a significant percentage of people, > 1%. I'm sure me, you and that "professional programmer who gives a shit about Haskell" do not a significant percentage make).

Even in universities, students find functional languages difficult, and opt-out of those classes.

Wow.

> I don't appreciate that ML doesn't have a simple concept like operator overloading

ML operators are nothing more than functions. The issue of "operator overloading" comes from the type system and the simplicity of the language.

> or that in LISP every DSL still looks like LISP

You might want to read on Scheme reader macros.

> I don't like that a Smalltalk application is not portable between implementations

It's true that you don't have this issue in Ruby as the "standard" is simply the original implementation (aka there is no standard at all, and not really any competing implementation).

> or that applications are big, monolithic images of the virtual machine with everything included, even the IDE.

That definitely isn't the case. That's not the case in GNU Smalltalk, and most commercial smalltalk let you create a stripped production image which contains only the necessary code.

Check out https://github.com/rubyspec/rubyspec.

And there are plenty of competing implementations: JRuby, Rubinius, MagLev, etc.

In fact, can you mention a single language with a standard that doesn't brake compatibility with its standard?

And yet the point is moot, because compatibility between implementations is manageable for popular languages like Javascript, C++ and yes, Ruby (JRuby, Rubinius). That's not the case for Smaltalk.

<bait>When your language is already at the top of the beauty chart, why would you write a DSL that is not also beautiful?</bait>

It is really a programmer choice. Lisp programmers generally love the way Lisp looks because of the advantages awarded by those looks (check Myth #7 here: http://www.algo.be/cl/myths.htm). But you can certainly create a DSL that requires more extensive string parsing, and CL provides a lot of help towards that end, including native translations of strings to Lisp objects where your parser needs them.

I'd like to see more effort put toward creating programming environments that provide clean abstractions that span entire multi-process distributed applications.

# Ruby

string.reverse()

# Python

string[::-1]

Which looks better?

Edit: I'm not sure why this is being down voted. It's a true statement.

Edit2: With all the down voting on Hacker News recently, I'm about to quit sharing my knowledge here. Maybe pg will do something about this. It needs to change otherwise good people will stop posting here.

Edit3:

irb(main):002:0> x = "hacker"

irb(main):003:0> puts x.reverse()

rekcah

>>> x = "hacker"

>>> print x[::-1]

rekcah

But yeah, I hear you on the downvoting.

It's all subjective, but I prefer concise, exact non ambiguous readable code.

From a google for 'ruby sample code'...

http://www.fincher.org/tips/Languages/Ruby/

  print " with no line breaks."

  printf("\n\nprintf ... %7.2f,... %s.",3.14156,"me")

  def welcome(name)
   puts "howdy #{name}"
  end

  "hello".upcase() => "HELLO"
  "hello".upcase => "HELLO"

  balance = -10.0
  puts "Bankrupt" unless balance > 0.0

Java code has a very exact, easy to parse syntax. We all know it, and it's easy to learn - {} for code blocks, () for method invocations, etc

That's just for starters.

I would point out, however, that printf is fairly rarely used and that I am not familiar with fincher.org in the context of sites to recommend newbs to learn Ruby from.

Removing the difference between accessing an attribute (variable) and invoking a method is a solid OO principle. You, as a client of the API, should not care how obj.foo is implemented.

It's called the Uniform Access Principle[1] and the languages that don't take advantage of it often suffer from a getter/setter hell.

[1] http://en.wikipedia.org/wiki/Uniform_access_principle

Hey presto! Now you have the best of both worlds.

I disagree. Code execution is not data access. They are very separate concepts.

Whether you like that or not is immaterial. You are free to avoid that aspect of OOP or the paradigm altogether.

For example,

  class flower
  property color
  property numberOfPetals
  method pluckPetal()
  method water()

Could you give some pointers to the OOP principle that blurs the line between these two?

There are languages where UAP is enforced by the syntax (eg. Eiffel, Smalltalk, Ruby) and languages where it's a matter of convention. But even in the latter it's considered a good practice to keep properties private and encapsulate them with accessors. Some even have dedicated features that help with that (auto-properties in C#, properties in Python).

There is absolutely no reason for that, and the grandparent of all things object-oriented (Smalltalk) very strongly disagrees with you: everything is a message, and there are no properties.

> A property defines data about an object, and a method defines something you can 'do' with the object.

A getter method is a property and a method. Properties are irrelevant, access should be uniform, the implementation details of an object (whether a "property" provides direct access to internal data or not) is of no concern to the user of the object.

A property is nothing more than a method whose contract is "give me some data"

However, for me, and the CPU, we treat code execution differently to data access.

1. It's not ugly

2. It's how CPUs work

3. It's how most people think

2. If you want a programming language that maps closely to how CPU's work, Ruby's definitely not for you. Assembly and C are for you.

3. I can't speak for most people. What I can say is that I can think in C and I can think in Ruby, and it doesn't seem difficult for me.

"public static final" is not particularly verbose. It's a one time upfront cost which defines a few flags. It's error free, since a typo in any of those keywords will be picked up.

It can also be automated easily etc.

But Ruby using 'end' etc instead of curly braces, that's going to add up to a lot of verbosity.

Furthermore, variables can't be called. If you have a proc object in a variable, you use "myproc.call" to invoke it. The only ambiguity is between methods call within the same 'self' and local variables:

    def foo
      42
    end
    
    def bar
      puts foo #=> 42
      foo = 30
      puts foo #=> 30
      puts self.foo #=> 42
    end

  class Foo
    attr_reader :bar
    
    def initialize (num)
      @bar = num
    end
  end
  
  puts Foo.new(42).bar

    public class Foo
      int bar;
      
      public Foo(int bar) {
        this.bar = bar;
      }

      public int getBar() {
          return bar;
      }

      public static void main(String[] args) {
        System.out.println(new Foo(42).getBar());
      }
    }

You should make bar private, and add a setter. After all, we might want to change the rules on setting bar sometime, and you wouldn't want to have to go back and change everywhere that accesses it...

It's package-access by default, that's enough to hide it from the third-party users of the class.

> and add a setter

The original code uses `attr_reader` which defines a readonly "property". The Java translation is a single getter, with no way to set the value from outside the class.

    public class Foo
      int bar;
      
      public Foo(int initBar) {
        bar = initBar;
      }

      public static void main(String[] args) {
        System.out.println(new Foo(42).bar);
      }
    }

2. let's say you solve this conundrum by making the field public

2.1. This piece of code is now frozen solid, you will not be able to ever refactor it (where refactoring is defined as changing implementation without changing behavior) since you can not transparently swap fields and methods in Java

2.2. This piece of code is dead to abstract types, as fields can not be part of interfaces in Java.

2.3. This piece of code is incompatible with Java Beans and will therefore be unusable in e.g. JSP taglibs

and your other points don't really make any sense at all. There is no such thing as 'fozen solid code'. Unless you're interfacing to external libraries etc and have agreed on a specific API, which is unlikely to include "yeah just reference 'bar' directly" unless you're insane.

I can't count the amount of time I wasted typing things like

  LongVariableName longVariableName = new LongVariableNameImpl();

Your comment comes across as someone who is either trolling or has no real experience in a language outside of java.

    -

    a
      b
        c
          d
          end
        end
      end
    end


    a {
      b {
        c {
          d {
          }
        }
      }
    }

    -

    -

    puts "Bankrupt" if balance <= 0.0

Essentially you could get any non-programmer to solve a problem on paper, and turn it into Ruby code which, without too much fuss, describes their process.

    # get the customers text file
    # each customer is on their own line, w/ their name and age separated by a comma
    # group the customers by age
    # show me the top 3 most common ages

    file = File.open('customers.txt')

    customers = []
    file.each_line do |line|
      name, age = line.split(",")
      customers << {:name => name, :age => age.to_i}
    end

    grouped_ages = customers \
                    .group_by{ |c| c[:age] } \
                    .map{ |c| [c[0], c[1].size] } \
                    .sort_by(&:last) \
                    .reverse

    grouped_ages.first(3).each do |age, size|
      puts "#{age} years old: #{size} customers"
    end
    

Uh, you realise that describes any high level language, right? Ruby scores pretty low on the readability scale, about halfway between Perl and Python, but I find it's more familiarity with a particular language that determines how readable people find things.

Here's a quick Python version. The main thing to notice is that while the overall flow/structure is similar, I don't have a lot of { } << \ characters hanging around, and I don't have to chain blocks together since I have list comprehensions.

    from collections import defaultdict

    customer_file = (line.strip().split(',') for line in file('customers.txt'))

    grouped_ages = defaultdict(list)
    for name, age in customer_file:
        grouped_ages[age].append(name)

    age_lengths = sorted( [(len(names), age) for age, names in grouped_ages.items()], reverse=True )
    for length, age in age_lengths[:3]:
        print "%s years old: %s customers" % (age, length)

I'm inclined to agree. I think the following also pretty closely matches the english requirements.

    (with-open [rdr (reader "customers.txt")]
      (->> (line-seq rdr)
        (map #(second (.split % ",")))
        (group-by identity)
        (map (fn [[age coll]] [age (count coll)]))
        (sort-by second (comparator >))
        (map first)
        (take 3)))

I think one of the side effects of learning a Lisp is that you get a bit blasé about using map. Do you find list comprehensions easier than map/filter? Is there a list comprehension equivalent in Lisp, or would you have to write your own?

As for preference, given that map, filter, etc., are lazy, I like the clear visibility of each step working on each element of the sequence.

Clojure has a list comprehension, for, though using it here is more trouble than it's worth since you have to group and sort, both of which require you to step outside the comprehension and work on the whole list; that's why your code has multiple sections.

Instead, I see the example as just a selection/transformation process on sequences of data. Each step in the clojure code takes and returns a sequence of values (the ->> macro weaves them together):

  0. a sequence of lines from a file
  1. a sequence of age strings
  2. a sequence of [age, [ages...]] tuples
  3. a sequence of [age, count] tuples
  4. a sequence of [age, count] tuples sorted by count desc
  5. a sequence of age strings
  6. a sequence of up to 3 age strings

Anyway, ataggart didn't write a macro he just used one that's already part of the language. Using a macro does not count as changing the language.

Also, I'm pretty sure that writing a macro counts as 'changing the language', although that line's a bit blurred when you're talking about lisps ;) ;)

You brought up list comprehensions, and something about being "blasé about using map". I wanted to show how a different way of modeling the problem yields a different structure to the code (namely, as a chain of transformations on sequences).

One is not better or worse than another. One of the things I enjoyed most about learning clojure was forcing myself to think in these different ways.

Also, this is a better version in Ruby:

    file = File.open('customers.txt')

    customers = {}
    file.each_line do |line|
      name, age = line.split(",")
      customers[age.to_i] ||= []
      customers[age.to_i] << name
    end

    grouped = customers.sort_by{|age, names| names.count}.reverse

    grouped.first(3).each do |age, customers|
      puts "#{age} years old: #{customers.count} customers"
    end

That's likely because you're not used to reading Python. For me, Ruby seems unreadable - you have all these weird << and ||= assignments, {||} blocks, etc. I don't parse those as well, because I don't program much Ruby. I'm sure if I did, it'd make a lot more 'intuitive' sense - ditto for you and Python's list comprehensions.

That said, I do find the more "squiggly" languages (Perl, Ruby, C) to be less readable than the equivalent Scheme or Python, and I suspect that it's because there are fewer weird characters, so it's closer to English.

  from itertools import groupby

  customer_data = (line.strip().split(',') for line in     file('customer.txt'))
  grouped_ages = groupby(customer_data, key=itemgetter(1))
  print sorted((len(list(g)), k) for k, g in grouped_ages)[-3:]

   from operator import itemgetter

    def some_method { ... }
    def some_method; ... end

    obj.something # "something" is allways a method
    # never a var, say accessor (getter, setter &c ...)

I'm just more at home with exact, specific concise well structured syntax.

I know it's an extremely unpopular opinion to hold, especially round these parts, but I don't see any beauty in Ruby syntax. Same with Python...

{} or do/end work for blocks, however.

There is nothing infamous about it. It's a multimethod, the designers of Python decided that mandating the same function for everything (via a common protocol under the covers) was better than risking people implementing a thousand different method names. They did the same with the iterator protocol.

What is not true of every function?

[1] http://www.python.org/dev/peps/pep-0020/

That said, I think Ruby is beautiful for a few reasons, but they mostly stem from the fact that Ruby strikes the perfect balance between Lisp and Other Languages: it's taken just enough of the good parts of Lisp and grafted them onto a more 'usual' language. Maybe 'grafted' is too harsh, it's Lisp _from the perspective of the rest of the world_. It's taking Lisp's ideas through a slightly different lens.

Whatever, I'm almost rambling. You get the idea. Some people think Java is beautiful, too...

Ruby doesn't have Lisp-style lambdas, or macros, or conses, it has blocks and messages (it tries to anyway) and classes. That's the Smalltalk recipe book. Ruby uses `select` and `reject`, `collect` and `inject`. Those come from Smalltalk's collections.

You're speaking of Lisp's _features_, I'm talking about Lisp's _ideas_. It may not have 'Lisp macros,' but it does embrace metaprogramming, for example.

Are you reminding yourself of that issue?

> but matz has specifically said Lisp influenced him, as well.

He might have said that, but I don't see it. Then again, considering what he did to Smalltalk it might be very, very well hidden. And in a pretty sad shape.

> You're speaking of Lisp's _features_, I'm talking about Lisp's _ideas_

They're in the same state.

> It may not have 'Lisp macros,' but it does embrace metaprogramming, for example.

Lisp metaprogramming is macro-based, unless you're getting into CLOS.

Smalltalk's metaprogramming is based on metaclasses and "unhandled message" forwarding.

Guess which one Ruby has?

Both of us, yes. My original comment was painting with a broad brush, and your follow-up is too.

> Guess which one Ruby has?

You're still speaking around me. The implementation of Ruby's metaprogramming is irrelevant, it's the place of prominence it's been given in the design and culture.

The rest of the language is definitely more about pragmatism. How could it not be with the Perl legacy?

For example:

    array.select &:even?

    array.select{|n| n.even?}

    filter even xs

    filter (\x -> even x) xs

The latter is readable.

I want to note that the &:even? idiom is only used in the simplest cases.

http://news.ycombinator.com/item?id=1948234

And yes, installing scipy from scratch is a bear. If you're using a modern linux distribution, you probably want to install a python scipy package.

And that's another difference between the two communities: Gems are always installed through Rubygems, no exceptions. Distribution's packaging systems (I'm looking at you, Debian) have always just screwed things up, and so Rubyists tend to just remove any system Ruby, install rvm from source (which entails running one bash script), and doing it all through there. Then, everything works great.

"There should be one-- and preferably only one --obvious way to do it."

The "obvious" portion of that makes it a little less strict than your quotation. I think it is a "good" axiom to try and aim for. The problem is people think differently and you can't force that really.

I like Perl, where almost anything goes, though. :)

    The "obvious" portion of that makes it a little less
    strict than your quotation.

"Obvious" is a problematic goal much like "fair" and "equal" are problematic goals in society. You end up sacrificing much that is good and valuable in pursuit of what is often a vague and situational ideal.

The subjectivity of the obviousness being nicely handled by the next stanza:

> Although that way may not be obvious at first unless you're Dutch.

I do think, though, that Python's list comprehensions are quite beautiful, and I'm looking forward to using them.

i.e you write 4+2 to add things not 4.add(2)

    >>> class Foo:
    ...   def __init__(self, name):
    ...     self.name=name
    
    >>> a1 = Foo('Alice')
    >>> a2 = Foo('Alice')
    >>> a1==a2
    False

    >>> Foo.__eq__ = lambda self,other: self.name==other.name
    >>> a1==a2
    True

The explicit self for methods comes straight out of the Python "rule" that explicit is better than implicit. Python is purposefully putting explicitness ahead of beauty, and I agree it's not particularly beautiful. Something that I find even less beautiful in Python is its super syntax:

super(theClass, self).method()

I'm still relatively new to Python, but I would argue that the super syntax goes a bit too far in explicitness (and I think it's fair to argue the same thing for the "self" in methods). Incidentally, there is a PEP (Python Enhancement Proposal) from 2007 to make super just work as super().method().

http://www.python.org/dev/peps/pep-3135/

Python then actually ends up taking advantage of this by having len able to use any of several interfaces. It may call double-underscore-len, but it may also traverse an iterator. It could potentially do other things as well. It's actually a straightforward application of the "prefer interfaces over inheritance" to the dynamic language case. You can criticize the spelling of the double-underscore methods (which if you are really grumpy, can actually be fixed by a metaclass, though I think the cost/benefit tradeoff is bad unless you are the only person who will ever use that code), but if you haven't used them you may not realize just how finely tuned they are, and how well they work with the functions that actually search over the interfaces to find the best one to use in a way somewhat difficult to replicate directly with a "method".

    Python's arguably not merely "OK" but more right than
    Ruby here, if you are really going to be an OO purist 
    (of certain flavors).

Lately I've heard a lot of chatter about Ruby Interfaces. They could be useful to achieve better unity. Though the Ruby collection API is already pretty consistent.

* You can nest classes and methods. This is ugly, so I never use it except in testsuites where declaring a mock class right in the test method is the best way to do it, but it's great to have "self" be the testcase and "xself" be the mocked method.

* There's no such thing as a magic variable. Every name you can reach is declared somewhere, either locally, globally, or from `__builtins__`. If self were automatic, then it would be invisible like the builtins, but it would change depending on where you used it from. The consistency is worth the minor inconvenience, IMHO.

unlike 'self' in other languages as a keyword, 'self' is just a variable with the same scoping.

i.e self always refers to the most inner scope in other languages (a special variable), meanwhile self in python is wherever self was bound in the current scope.

and fwiw: len is a holdover from earlier python (you can define a method __len__ if you want...)

No. len is basically a multimethod.

> (you can define a method __len__ if you want…)

You have to, it's part of the length protocol, `len()` will not work if you don't. Because `len(o)` calls `o.__len__()`). If you start calling underscore-methods directly (outside of a super() access), you're heading for trouble with your coworkers.

    each(list) vs list.each
    def(self, args)
    __ugh__
    can't do templates (erb?)
    dislike object model (objects != functions etc)

This also bugged me the last time I wrote any Python code. I decided the sensible response was to go write Scala code until the situation resolved itself. Has it?

(I hope Python never acquires the problem C has, where its users are scattered so far and wide that every halfway valid tool attracts enough satisfied users to sustain itself, preventing the community from being coherent enough to advance in any direction at all. Guido needs to be a Ghengis who keeps all the tribes pulled together and galloping in the same direction, not scattering into disconnected groups.)

There's really no fragmentation whatsoever that I've seen. Install a package using your preferred way, in the end everything installs fine whether it's built with setuptools, distutils or distribute (or just copy the files to your site-packages directory). I haven't read the entire blog post yet, so I haven't gotten to the part you quote, but that's my two cents.

Also, the affirmation that everything install fine whether you use setuptools/distribute/distutils is simply not true. We get almost daily bug reports/user complaints in numpy/scipy because of installation issues mostly caused by distutils, or people using pip/easy_install (which does not work with numpy distutils extensions). The situation is confusing for a lot of users, especially the ones who are not super familiar with python.

This is a complex issue, though, especially if you want to play well with native tools on each platform. It does not help that python packaging tools have been created by accretion instead of begin designed around simple, robust principles.

There's also a [packaging discussion group] which seems to be primarily focused on distutils2 development.

[Tarek]: http://ziade.org/

[^1]: http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distu...

[packaging discussion group]: http://groups.google.com/group/the-fellowship-of-the-packagi...

Also, will study your Oct. 13 blog post on the matter to learn more about the issues.

  public int[] filterEven(int[] array) {
    aggregator = int[array.size()]
    for(int i: array) {
      int aggregatorSize = 0;
  
      // The next line is the only unique part of
      // this function!
      if(array[i] % 2 == 0) {
        // Someone please tell me there's an easier way
        // to append to an array than this
        aggregator[aggregatorSize] = array[i];
        aggregatorSize += 1;
      }
    }
  }
  
  int[] array = { 1, 2, 3, 4, 5, 6 };
  filterEven(array);
  // => { 2, 4, 6 }

So it'd be:

  List<Integer> result = new ArrayList<Integer>();
  for(int i : argument) if(i%2==0) result.add(i);

And if you really needed to work on an argument passed in the form of a primitive array, you'd use Arrays.asList(arrayArgument) to easily turn the array into a list.

Java really shines when you are doing multithreaded code because you have a rich set of thread safe collections. (e.g. multiple simultaneous requests in a web app all modifying shared data structures).

With reading something into a file, anyone that does this often will just use a library (either their own or a 3rd party one).

Thus, they'd just do:

  String data = FileUtil.readFile("abc.txt");

It's certainly possible to write beautiful code in Java, it's just not very common :)

One thing that Java could benefit from greatly would be type inference. That alone would remove so much syntactical noise.

Honestly, who cares that you need to write a Main class? This is quite commonplace, and only really inhibits scripting tasks. In any real application, this is a non-issue.

I get it for the FORTRAN -> Java transition; I understand that you'd want to port your stuff to Python from Java. But why would anyone port massive and complex libraries (SciPy is not your regular "Yep, coded that in 4 days!"-gem) to a virtually identical language? [1]

No point. Learn Python, and get some stuff done.

[1] Now, if you're about to build a good scientific/numerical/statistical/(...) library for Clojure -- I'm all ears.

But where's the package management? Clojure might be a bit too young.

1. Use Maven as Maven with https://github.com/talios/clojure-maven-plugin - My impression is that this option is often more popular with people coming to clojure from java, as you get the full XML and maven experience.

2. Use Leiningen https://github.com/technomancy/leiningen – this is a project and dependancy management / built system built in clojure on top of Maven's libs. You have a single (and simple - no XML) project.clj file that describes your project. My impression here is that lein is popular with people coming to clojure from non-JVM land. Being a former pythonista, this is my preference.

There is also a default maven repo that i believe both work with hosted at http://clojars.org.

In both cases maven handles dependency resolution and package management. My experience is that a global install of jars is not common like it is in python or ruby land.

The other tool that you will want to look at is https://github.com/liebke/cljr which is a repl built ontop of lein's package management commands. This is useful because it lets you run a repl without a project (lein requires a project) but still gives you control over what libraries are available. If you are using incanter (the stats package mentioned by Estragon) you will want cljr

I'll have to check out cljr.

  ...if you're about to build a good scientific/numerical/statistical/(...) 
  library for Clojure -- I'm all ears.

I'd love to see more people pitch in and help develop tools that would make scientific analysis easier.

I did a presentation at RubyKaigi on this general subject actually: http://www.slideshare.net/knowtheory/mapping-the-world-with-...

(and a video: http://rubykaigi.tdiary.net/20100829.html#p09 )

fwiw: this works in python too

>>> class Foo(object): ... def __add__(self, x): ... print "%s+%s"%(self,x) ... >>> a = Foo() >>> a+=8 <__main__.Foo object at 0x657d0>+8 >>>

You can override __iadd__ separately too.

However for sheer pragmatism Python wins; almost every API and library you can think of has its own Python bindings.

    array.select &:even?

    filter(even, array)

I wish Ruby implemented them the same way as in Smalltalk, to be used as objects passed to a method's arguments.

All the 'do..end, {}', '&', 'yield', block_given?, etc. would have been gone. And there would be just one unified way to construct and call a block.

This is the only part of the language I find wrong in Ruby. Any Rubyists share the same feeling?

This is largely true for Ruby too. Both have great C FFIs, so it's not hard to write these kinds of wrappers. I've never been wanting.

I don't think you can really call this a general win for either language, though Ruby does tend to lose out to NumPy and SciPy (from what I hear).

I'm dabbling with RoR and it's certainly pleasing at times, but there are the odd bits of Python I keep running into that make me smile too. Especially map. :]

To me it seems that half the anti-Python sentiment is because you can write some truly terrible Python code, just as you can write some truly terrible Java code. You can also write some elegant Python code (although there are some situations where you just will run into those damned underscores), but it's in the minority.

Coming from Perl (no, really) and Python, my main issue with trying to learn Ruby is all the extra syntax and punctuation. It just looks and feels wrong until you force your way through it and see it from the other side. There are some really nice advanced features of the language (I sat in on an advanced Ruby class and found it surprisingly easy to follow given a background in ML, Perl and others) so I'm still going to persevere and learn it, but I'm still at the "Ruby feels arse-backward" stage. I think to me Ruby feels like Python does to Rubyists. Sort of.

http://d.pr/wfTk

Urgh, Rails...

You can hardly blame Rails for your programming error.

I like both, but Ruby does it for me bigtime. I actually wish it also had Python's whitespace rules, but since I use Haml a lot I still benefit from it sometimes.

One important facet of Ruby is that it was written to optimize programmer happiness. As a result, it is a lot of fun to code in. The article's author says something similar himself:

"Now, I want to be clear: I like Ruby better than Python. Its semantics make more sense to me than Python’s, and the language itself is more beautiful."

As someone who codes between 2 and 20 hours a day, a language like that is where I want to be. Ruby does have its gaps so other languages are needed too - I use actionscript for front-end stuff (instead of MacRuby) and functional languages for concurrent programming (instead of EventMachine).

http://www.wedesoft.demon.co.uk/hornetseye-api/files/Hornets...

One thing that hit me though. The author of the article maybe should consider a little effort. I mean...libraries for scientists should probably be developed by scientists (the target group), which means it's an excellent opportunity for the ones that identify the problem to get something started. No code falls down from heaven. Supply and demand.

If they're comparable, why not use JRuby and use all the Java libs you want?

I wasn't saying that is how I would implement filters. Just that that is the DRYest way to do so--and it's easy in Ruby.

I'm not looking to second guess each of your examples, many of which were fine. I felt that your currying example was trying to bring in a purely functional toolkit ala Lisp when it wasn't appropriate. Function composition (which you allude to in your reply, yet I don't see) and blocks (especially!) show off Ruby's functional capabilities quite well and would be just as effective and more practical.

Btw, if you're quite new to Python, do yourself a favor and learn about list comprehensions. They can be quite wonderful.

Good luck!

As I say, I wouldn't use that last technique in my actual code. It just shows how powerful the language actually is. I think my normal code falls in line with the standard Ruby paradigms, but with a functional twist.

And yes, list comprehensions are fantastic. :)

The point is not that the two samples are exactly equivalent. The points is that you can go no simpler with Java's standard libraries.