Ruby is beautiful (but I'm moving to Python)

http://allthingsprogress.com/posts/ruby-is-beautiful-but-im-moving-to-python

by djacobs • 16 years ago

121 172 16 years ago

mcritz• 16 years ago

I think the author has done a great job pointing out a need: science tools for Ruby.

I still think Ruby is a little too "expressive" to be taken seriously is scientific circles. In my view, DSLs are not a positive feature in academic work, because everybody's D is different from the next guy's. This is why the linga franca of almost all algorithms papers is, in fact, pseudocode. Python is sufficiently structured that it practically reads like pseudocode.

sigzero2• 16 years ago

Yes, but Perl has a huge scientific following as well, so Ruby should be able to used there as well. However, I think with Python and Perl in that niche, it would be hard for Ruby to break significant ground there unless a RoR moments hits for that area with Ruby.

apl• 16 years ago

There was a similar discussion elsewhere about this. Short version: what's the point in developing them? Despite what ardent proponents of either will tell you, they're essentially the same language. Porting code from one to the other is straightforward or trivial. Learning one with a background in the other is a matter of days.

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.

djacobs13• 16 years ago

I am, in fact, trying my hand at stats in Clojure, to see if it's a viable alternative. I finished the Wilcoxon Rank Sum Test yesterday, and it's ridiculously elegant compared to the current SciPy implementation. Clojure is pretty fantastic.

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

Estragon2• 16 years ago

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

Presumably you're aware of Incanter (http://incanter.org/), which wraps scientific libraries for Java.

knowtheory• 16 years ago

Right, so i agree with the author on this front, but it's not to say that there are no tools with which to do analysis, but many of them are pretty rudimentary.

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 )

telemachos3• 16 years ago

Why is the website telling me I'm an administrator?

http://d.pr/wfTk

djacobs13• 16 years ago

I'm having cache problems, sorry! (This is my first production app.) The problem should be solved for now, though I had to turn off caching to fix it.

Urgh, Rails...

telemachos3• 16 years ago

No apologies necessary. I just wanted to make sure you saw it in case there was a hole you needed to close.

SteveC• 16 years ago

"Urgh, Rails..."

You can hardly blame Rails for your programming error.

mnutt2• 16 years ago

You can't use static page caching, but rails caching should work fine if you use administrator status as a cache key.

telemachos3• 16 years ago

I'm not sure why this is bugging me, but p and puts are not the same thing in Ruby. In most non-debugging contexts, p 'hello world' would be odd since it would print the string for inspection (i.e. with the string literal quotes around it), no?

djacobs13• 16 years ago

Yes, that's true. And since I used println in the Java example, I guess I should switch the Ruby example to puts. Will do that now.

jewbacca• 16 years ago

http://mitpress.mit.edu/sicp/full-text/book/book.html

Estragon2• 16 years ago

I'm not saying you're wrong: I have been using python for so long, there are undoubtedly problems with it which I am so used to I just don't see them. But I'm curious about why python has a reputation in the ruby world as ugly.

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.

gvnonor• 16 years ago

I think len() being a function instead of a method, explicitly specifying self for each method and other inconsistencies(albeit small) lead rubyists to think of python as ugly. I'm no rubyist(I prefer expediency to elegance, hence python over ruby), so take this with a grain of salt.

tef__3• 16 years ago

the thing is, self being explicit makes it more consistent

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

gxti• 16 years ago

There are two nice things that you get with an explicit "self":

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

baddox• 16 years ago

I think the relationship between lists, iterators, and generators is one of the greatest features of Python. I think len makes sense as a function in the same way the sum function makes sense as a function. Both do an operation on any eager iterable, including ones that don't store or "know" their own length.

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/

jerf• 16 years ago

Ironically for people still criticizing "len" as a function, it is now the more acceptable way of accomplishing the task than what Ruby is doing in many circles. In Python, len is a generic function that can call anything that implements a certain interface. This is more correct that baking the "len" function in somewhere in the object hierarchy, or implementing it relatively randomly throughout the hierarchy with a series of "len" methods that may or may not actually be connected. (len isn't the best example since it's in the "standard set", but in general just because two methods have the same name doesn't mean, well, anything in particular, really.) Favoring interfaces over inheritance leads you to the Python solution, not the Ruby solution. 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).

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

djacobs13• 16 years ago

I only know a little bit of Python so far, but I think it's things like the "underscore methods" (__len__, __cmp__, __init__) and the lack of blocks (which give Ruby a kind of elegant unity).

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

tef__3• 16 years ago

To some extent: the underscore methods represent 'magic behaviour' i.e. this gets called implicitly by something else, you never call this directly.

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

prodigal_erik• 16 years ago

Blocks are indisputably useful, but beautiful? There's no shortage of rants on the bizzare inconsistencies between blocks and proc and lambda (do I use call or yield? can I use return? why does arity checking rarely work?)

utku_karatas2• 16 years ago

Maybe it's me but I find those underscore methods very helpful while skimming code.. They clearly point out the "magic functionality - probably adding syntactic sugar" declarations, helping me focus to the actual interface of the class.

steveklabnik7• 16 years ago

I can't speak for the 'Ruby world', but the loss of blocks is significant. Significant whitespace makes code ugly sometimes. "There should only be one way to do it." is wrong. Basically, Ruby values _flexibility_ above all else, and Python introduces unnecessary rigidity, which feels 'wrong' to a Rubyist.

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.

sigzero2• 16 years ago

That quote isn't quite correct. The PEP quote is:

"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. :)

clyfe3• 16 years ago

I shunned py because:

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

drpancake• 16 years ago

I think there's always been a bit of 'grass is greener' sentiment between the Python and Ruby communities. As a Python guy I do appreciate the look of Ruby code.

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

steveklabnik7• 16 years ago

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

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

endtime• 16 years ago

Hmm, not for me. I think things like paren-free function calls are awful for readability and

    array.select &:even?

is far, far less clear to me than

    filter(even, array)

Ruby just seems to have tons of unnecessary syntax, I guess.

zya• 16 years ago

A lot of 'unnecessary' syntax is comming from the fact that block forms 'do..end, {}' are not objects in Ruby.

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?

tef__3• 16 years ago

'I love that I can define + for any object in Ruby and that doing so gives me += for free.'

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.

jfb2• 16 years ago

This is a perfectly cromulent article, but as someone relatively new to Ruby, I don't see the beauty. Perhaps I've spent too much time with the airless asceticism of, say, Scheme, but Ruby just reads a mess to me. Too many synonyms, too much implicit behavior. There's too much language for my taste. Of course, beauty is in the eye of the beholder &c., &c., &c., and I wouldn't deny that there is a certain pragmatic attraction (even I like to get shit working). But beauty?

steveklabnik7• 16 years ago

I think you've answered your own question: beauty is in the eye of the beholder.

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

masklinn13• 16 years ago

It's mostly taking Smalltalk's ideas, not Lisp's, and it's crashing those ideas from orbit into Perl, of all things.

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.

spacemanaki2• 16 years ago

From Scheme (or even Common Lisp), I would agree with you, Ruby isn't exactly beautiful. But from Java (which the article compares it to), it's glorious.

jfb2• 16 years ago

Nobody could possibly gainsay that. Java is hideous.

dasil003• 16 years ago

I find the beauty of Ruby to be in its object orientation model. The underlying simplicity of Ruby's Modules, Classes and Eigenclasses, and the richness of the architectures they enable is quite elegant and inspired.

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

ashleyw3• 16 years ago

I really didn't like some of his examples (especially the part containing 'longer_than_5', that was hideous IMO!) He tried explaining Ruby's simplicity…by using some of the most confusing idioms.

For example:

    array.select &:even?

Is really just:

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

I generally always use the latter. It's just cleaner. I hate overly clever code.

jpr• 16 years ago

Overly clever or confusing to you, idiomatic to others (and vice versa).

ionfish• 16 years ago

Which of these Haskell examples do you prefer, then?

    filter even xs

    filter (\x -> even x) xs

masklinn13• 16 years ago

> This is a perfectly cromulent article, but as someone relatively new to Ruby, I don't see the beauty. Perhaps I've spent too much time with the airless asceticism of, say, Scheme

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.

rue5• 16 years ago

I have a strong dislike for the now-nearly-meaningless terms "beautiful", "eloquent", "elegant" &c. but for me the deciding factor between Ruby and Python for a project (assuming no constraints from libraries required and such) is Ruby's internal consistency. Python is a bit more haphazard; the infamous `len(str)`, to wit.

derefr• 16 years ago

Instead of a simply giving your subjective aesthetic evaluation, based on some measure of "elegance", you could objectively compare, in HCI terms, the usability of the languages as user-interfaces to the computer. A mouse may be more elegant than a keyboard, but for, say, word-processing, it would have comparatively-horrible usability.

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.

axod14• 16 years ago

FWIW, I come from Java and find Ruby to be fairly ugly.

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")

Eugh brackets are optional for invoking functions? So I can no longer just look for () after a name to determine what is a function invocation?

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

"end"? Seriously? Verboseness... (This is one of the things that for me, makes ruby very ugly. It's needless verbosity and doesn't have any advantage over using {} ).

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

Yuck. So how do you know what's a function and what's a variable?

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

Starting to look like cobol here... 'unless'? seriously? Why is that nicer than an if statement?

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.

bad_user2• 16 years ago

I'm a Python programmer, and I find code written in Ruby to be more beautiful.

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

But that's the price you pay for convenience.

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 ;)

16s• 16 years ago

Ruby is nicer to read than Python. Here's how each language reverses a string:

# 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

sahglie• 16 years ago

Or you could use Ruby where it continues to make the most sense and use Python where that makes the most sense. After all, the languages are so similar that keeping them both in the tool belt has less mental overhead than say Ruby and Scala.

insight• 16 years ago

guys, sorry beautiful and sexy are not for Programming Languages. Really.

grimen• 16 years ago

I'm not a scientist but this article got a really valid and good point. I only know about this Ruby-lib within the scientific context:

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.

oomkiller• 16 years ago

As a Ruby programmer, I think it's great to learn Python. While they are similar, there are many differences, and even some advantages to Python. Plus, it never hurts to add to your resume! Finally, Python is usually installed on more systems than Ruby, so if you do lot's of systems administration, you don't have to worry about adding another package.

ludicast2• 16 years ago

Title is a little flamebaity, considering it seems like he is adding python, rather than "moving to".

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

jpcx01• 16 years ago

Using Ruby extensively with CoffeeScript is also making me long for significant whitespace. I think CoffeeScript gets it perfect. Unfortunately, it's just a wrapper around JS so it has limited uses (until Node.js gets mature).

ludicast2• 16 years ago

Haven't checked out CoffeeScript before, but it's very terse. Me like.

rue5• 16 years ago

Yes, I am not sure why one would "move". Learn Python, presto, you now know two handy languages and can use them at your discretion.

djacobs13• 16 years ago

That's valid. I'm adding it, not moving. That sounded weird for a title, though.

jamesbritt4• 16 years ago

How does Python's science libraries compare to Java's?

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

dkarl• 16 years ago

In Python, though, there seem to be competing managers (easy_install and pip) and separate ways to package libraries for uploading. I’m also hearing names like setuptools, distutils, distribute and virtualenv, and I have to say that the whole ecosystem isn’t too clear to me yet. And the documentation tends to assume I know what all the above mean already!

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

StavrosK• 16 years ago

Those names are not all disjoint. pip has superseded easy_install, so you should use the former, distribute is a way to write setup packages (pip only installs them), and virtualenv is a way to avoid messing up your system with packages by installing them to a single, self-contained directory.

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.

cdavid4• 16 years ago

Actually, there is fragmentation: pip does not supersedes easy_install, since easy_install does things that pip cannot do (like installing from something that is not a source tarball). Also, distribute being a fork of setuptools, with neither distribute/setuptools being a superset of each other, means more fragmentation as well.

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.

cdavid4• 16 years ago

Python packaging is indeed a mess. The scipy community in particular is acutely aware of the issue - distutils and all the cruft on the top (setuptools, pip, etc...) are not robust and extremely adverse to extensibility.

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.

cookietime2• 16 years ago

For anyone who wants to help Python wrt packaging, get behind [Tarek] and his work on distutils2. That's the future of Python packaging (with Guido's blessing) [^1]. More info on python packaging temporarily at http://guide.python-distribute.org/ .

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

yesimahuman• 16 years ago

Comparisons between Java with exception handling and a scripting language with a one liner that does no error checking are pretty worthless.

djacobs13• 16 years ago

The point is: when I'm writing a script (or better yet, doing this interactively), I don't want error checking. I see an error, and I fix it. This article centers around agile scripting for science, not building enterprise applications or libraries.

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.

chrisbroadfoot2• 16 years ago

Au contraire, I am of the opinion that checked exceptions are the scourge of Java.

srgseg• 16 years ago

Instead of:

  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 }

in Java, you'd normally use collections and not arrays.

So it'd be:

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

So it's really 2 lines, not 7.

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");

djacobs13• 16 years ago

Duly noted. I asked for alternatives because idiomatic Java eludes me. Thanks.

chrisbroadfoot2• 16 years ago

Agreed. A lot of complaints about Java are because of shit APIs (standard library) rather than the language itself.

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.

Tichy• 16 years ago

What are good alternatives for data crunching? Incanter suitable yet?

jlees2• 16 years ago

This is the reason I stuck with Python for my development and production code. Python scientific programs running on the backend, using all sorts of fancy libraries (NLTK and numpy mostly) and then a Django frontend that plugs right in.

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.

spacemanaki2• 16 years ago

Map isn't really an "odd bit of Python" that you ran into, it's a bit of Lisp.

jlees2• 16 years ago

Actually, I know it from ML. I was more smiling at it existing in Python, than Python having 'invented' it.

softbuilder2• 16 years ago

An unsatisfying article. Judging from the code, I am not convinced that the author gets Ruby. At the very least, Proc#curry doesn't make a very compelling example.

djacobs13• 16 years ago

I'm sorry you feel that way. What about that example makes you think I don't understand Ruby? Composing functions (and currying in arguments one at a time) is probably one of the more powerful things you can do with the language.

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.

softbuilder2• 16 years ago

You have nothing to be sorry about. If I had noticed that this was a self-post I would have phrased my response more personally and (hopefully) with more tact.

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!

Ruby is beautiful (but I'm moving to Python)

Related Stories