The Artima Developer Community
Sponsored Link

Weblogs Forum
What Are Your Ruby Pain Points, Really?

29 replies on 2 pages. Most recent reply: Mar 6, 2007 5:08 PM by Mason Deaver

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 29 replies on 2 pages [ « | 1 2 ]
Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 20, 2007 7:41 AM
Reply to this message Reply
Advertisement
> Will someone name a single feature Ruby has that wasn't
> available in LISP or Smalltalk first?

Yeah, yeah. Lisp had it all back in the 60's. C'mon man.

Ruby's strength comes from it's pragmatic mix of lisp and smalltalk ideas with a c-derived syntax that doesn't look utterly foreign to the 90% of developers used to the dot-operator, not from some amazing innovations on Matz's part.

But sure, here's one: ruby makes it very easy and syntactically natural to pass a single closure into a function. This nail's the sweet-spot of the expressiveness/complexity trade-off with closure arguments to higher-order functions: normal humans can get their heads around about one such argument. If you need more than that, you are probably decomposing the problem incorrectly, or there are better ways to model it (say, inheritance.)

Hey, it isn't rocket science, but then rocket scientists are the guys who got us into this mess...

Cheers,
Carson

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 20, 2007 8:12 PM
Reply to this message Reply
> > That's pain point #1 for me - so many Ruby programmers
> > have that band-like "heard it first" syndrome. There
> are
> > just too many snobs who are so dedicated to pointing
> out
> > that they used Ruby before it was popular. I
> > realize I'm not as cool as them, but it really hurts my
> > feelings to have to hear it all the time.
>
> Will someone name a single feature Ruby has that wasn't
> available in LISP or Smalltalk first?

popularity

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 20, 2007 9:12 PM
Reply to this message Reply
@Erik Engelbrecht
@"Will someone name a single feature Ruby has that wasn't available in LISP or Smalltalk first?"

Rails (framework).

And then library bindings, to things such as libsyck.

These were things developed intentionally for use by Ruby programmers. Not for LISP or Smalltalk programmers.

Tiago Antao

Posts: 26
Nickname: tiago
Registered: Feb, 2003

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 21, 2007 1:37 AM
Reply to this message Reply
From someone currently doing scientific computing: lack of libraries.

I would really like to use a DSL-able language like Ruby, but I need the likes of SciPy, Matplotlib and Biopython. What I have seen from Ruby is not (still) comparable to Python.

Performance is also a serious issue for scientific computing (most of the times we are not waiting for a DB backend). This is also a problem with Python, but some C glue (or Java glue - Java performance is fantastic compared with Python/Ruby) would sort it.

My dream future situation would be one where a JVM backend would have enough libraries (clue, Java still lacks good sci libraries) where we could choose the language irrespective of libraries and platforms

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 21, 2007 6:29 AM
Reply to this message Reply
> Performance is also a serious issue for scientific
> computing (most of the times we are not waiting for a DB
> backend). This is also a problem with Python, but some C
> glue (or Java glue - Java performance is fantastic
> compared with Python/Ruby) would sort it.

I was just about to post my laments on the Jython project's stagnancy but I looked at the page and there's was an update on the 7th. Looks like they are getting near a 2.2 release. Considering there had been no update to the site since 2005, this is major progress.

If a dynamic invocation instruction is added to the JVM it could be a pretty awesome platform for Python.

> My dream future situation would be one where a JVM backend
> would have enough libraries (clue, Java still lacks good
> sci libraries) where we could choose the language
> irrespective of libraries and platforms

I think the reason Java lack scientific libraries is that it's widely seen as being a terrible language for scientific work. The lack of operator overloading seems to be a sticking point.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 21, 2007 7:50 AM
Reply to this message Reply
>I think the reason Java lack scientific libraries is that it's widely seen as being a terrible language for scientific work. The lack of operator overloading seems to be a sticking point.

This is OT and pure conjecture, but for example SciPy isn't up to 1.0 yet (but it's close) and I think many of the components, at least by version numbers, are fairly immature. Java tends to be more of a "production" language, while Python tends to be more for working out ideas. Or at least that's how I use it.

There's also the whole web application focus of Java. How many web applications do scientific computing?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 21, 2007 8:21 AM
Reply to this message Reply
> This is OT and pure conjecture, but for example SciPy
> isn't up to 1.0 yet (but it's close) and I think many of
> the components, at least by version numbers, are fairly
> immature. Java tends to be more of a "production"
> language, while Python tends to be more for working out
> ideas. Or at least that's how I use it.

Actually this is why Jython works so well (for me at least) there's a pretty close to seamless integration between Java classes and Objects and Python classes and Objects (and Python modules with Java packages.) I can build the 'hard' code (stuff that needs to be fairly stable) and the 'soft' code in Python. Really Python acts as the glue (filling the role of frameworks such as Spring) and as blurbs of logic that the Java code calls (function pointers would make this cleaner.)

> There's also the whole web application focus of Java. How
> many web applications do scientific computing?

I think there's a perceived focus of Java as a web application language. Maybe it's accurate but I've done very little web-app-focused Java development, unless you consider 3-tier with fat-clients a web-app. Even then I have done anything like that for several years. Personally I'm not all that convinced that that is where Java fits best. On the back-end, I think it works but not on the front end. This is why we have JSP and all its progeny, is it not?

Tiago Antao

Posts: 26
Nickname: tiago
Registered: Feb, 2003

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 21, 2007 8:47 AM
Reply to this message Reply
> I think the reason Java lack scientific libraries is that
> it's widely seen as being a terrible language for
> scientific work. The lack of operator overloading seems
> to be a sticking point.


As far I as see, in Scientific computing there is a strong niche for "platform independent" software. Some journals only publish software that is in fact, platform independent or close.
That means, in practice JVM. In my opinion.
For reasons that would be here OT, Java is not the solution. This makes space for scripting languages on JVM. Currently Python first, others (Ruby, ...) second.
Performance could be solved by Java implementations of inner loops.

There are still problems with libraries. Even when there are JVM libraries, their "cost of entry" is quite high for non CS people. Compare JChart with, say, CPython's matplotlib (dependent on SciPy NumPy library). What you can do in 10 lines of matplotib requires >100 of JCharts'... That is not acceptable for many scientific programmers (why should it be, btw?).

Again, in this context, I think an ecology of JVM with competitive languages on top of it could be desired. Missing are the libraries (and easy to use wrappers). Ruby, would be great, with its nice DSL, metaprogramming approach.

Or, forgetting JVM/JRuby, in my case, I would settle for Ruby + competitive scientific libraries (competitive to CPython). NumPy, SciPy, matplotlib, BioPython are the competition, at least in my case.

Tiago
PS - even for high performance scientific computing there is quite a lot of Java going on, say, grid computing (yes, Fortran also, but Java is already there). One could imagine higher level Ruby/Python code driving low-level HPC code...

Stefan Tilkov

Posts: 13
Nickname: stilkov
Registered: Jan, 2004

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 21, 2007 11:41 AM
Reply to this message Reply
It's very hard to understand complex Ruby code without support for navigation from an IDE.

I don't care about refactoring, or code completion, or debugging (... well ... maybe about debugging.)

The most important thing, though, is that there is simply no way (that I know of) to click on a symbol and reliably find the places where it's used, or where it's defined, particularly if metaprogramming is used. For example, once you have defined a has_many :customers association in Rails, a bunch of methods become available that have been created automagically -- and I don't see how one could resolve them even theoretically.

Maybe metaprogramming is both Ruby's greatest strength and its greates weakness ...

Jeremy Echols

Posts: 3
Nickname: nerdmaster
Registered: Feb, 2007

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 21, 2007 4:56 PM
Reply to this message Reply
Tiago Antao:
> Performance is also a serious issue for scientific
> computing (most of the times we are not waiting for a DB
> backend). This is also a problem with Python, but some C
> glue (or Java glue - Java performance is fantastic
> compared with Python/Ruby) would sort it.

Ruby binds with C beautifully, so performance concerns can be dealt with nicely, if you don't mind writing the C code. I'd prefer Ruby simply be half as fast as Java, then this wouldn't be a concern so much. But Ruby, Python, Perl, PHP, etc. can all be "fast" if you use C bindings. Now this doesn't help the lack of scientific libs for Ruby, but you know....


Stefan Tilkov:
> The most important thing, though, is that there is simply
> no way (that I know of) to click on a symbol and reliably
> find the places where it's used, or where it's defined,
> particularly if metaprogramming is used. For example, once
> you have defined a has_many :customers association in
> Rails, a bunch of methods become available that have been
> created automagically -- and I don't see how one could
> resolve them even theoretically.

That is a good point, but dynamically added methods aren't really due to symbols being hard to find - so I'm not sure what you meant there... and if you're using a framework that makes dynamic changes to your objects and classes, that isn't really Ruby's fault but the framework's fault.

I love Rails, but it definitely does things to make programming somewhat confusing until you learn the framework inside and out. I think that will be true of any language that allows dynamic code injection. If you can take control of somebody else's class, and you don't make damn sure they know what's happening, it will probably confuse them.

I think the metaprogramming is a big plus for Ruby, as it adds a huge amount of DSL options as well as just being plain cool. It also allows people to do horrible things like changing how the plus operator acts on numbers. So I see it as a good feature that needs to be used responsibly. I would rather have the power and see it misused than not have the power at all, that's why I see it as a huge plus.

Aaron Cantrell

Posts: 1
Nickname: aaron
Registered: Apr, 2003

Ruby IDE Posted: Feb 22, 2007 9:41 AM
Reply to this message Reply
Intellij IDEA is has a plugin with ruby support. IDEA is really nice, especially with the IdeaVim plugin.

Joe Peterson

Posts: 1
Nickname: lavajoe
Registered: Feb, 2007

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 22, 2007 10:36 AM
Reply to this message Reply
Overall, I was quite enamored with Ruby when I first started using it. Over time, however, some things started to bother me a bit too much. The purist in my was quite disturbed by, especially, #1 below. Still, I think Ruby is quite beautiful, and it's too bad it has these issues.


1) Inconsistencies in methods on classes standard lib:

For example, I was dismayed to discover that String and Array have very different conventions for what methods are destructive and which are not. This is made worse by the fact that it's "optional" to have destructive/non versions of a method.

For example, String has both "delete" and "delete!", but only one "insert". I guess the developer figured there was no use for a non-destructive "insert", but it's a grey area in my mind and not completely logical (i.e. I can imagine a non-destructive "insert" simply returning a new string with something inserted).

Array, on the other hand, has only "delete", and it's destructive. I assume a different developer with a different way of thinking did this one. Also, Array#delete returns what was deleted, whereas String#delete! returns the string... This makes it hard to remember how these behave - not exactly following the "least surprize" principle.

What makes this worse is that there is really no way to fix the situation. Once you make a destructive method without "!", you cannot go back and make it non-destructive without breaking code. Also, the whole point of "!" is bit nullified because one still has no sure way of knowing whether a method is destructive or not (e.g. String#insert) without looking it up.

For an obvious comparison, it's not always obvious which methods are destructive in Python either, but it has a *great* feature of returning None if it is destructive and returning a value if not. Also, immutable strings help (see below).


2) Noise

Although I see the benefit of "!" and "?" on the end of methods, these conventions are not enforced nor are they always consistently used, and I do think it makes for noisy looking code.


2) Too much "implicitness"

I know that Ruby prides itself in being more implicit than, e.g. Python, and I found things like no need to use "return" explicitly seductive, choosing to use that feature all of the time. However, I also found it can be a bit confusing to read the code and figure out what, exactly, a method is returning (i.e. what constitutes code that causes a return value, etc.). I've grown to like the explicitness of "return" after using Ruby for a while.


3) Mutable strings make for uncertainties

Although mutable strings can be very useful, I can now see the nice thing about immutable ones. In Ruby, you have to be careful to "dup" strings that you do not want modified. If you pass a string into a method, you do not know if it might be changed, etc. There are pros and cons, but in practice, I think immutable strings are more "comforting" when coding.


4) Optional parentheses on methods

I know there are pros to this (i.e. the "uniform access" idea), but I find that deciding whether to use them or not becomes a matter of style, and it can be ambiguous what the right choice is. For example, it might make sense to drop the parens for one-argument calls, but if you need later to use more than one argument, it can be more clear to use parens. I've then felt I was being inconsistent, and I was tempted to go and fix the previous ones, but then I realized this was an arbitrary decision based on trying to be "consistent" within one method or whatever... I find it more "clear" to use parens on methods, I guess. But what about "puts"? Since it *seems" like a statement, it looks better not to use them. I just don't know. :)


I'm sure there are other things I could think of, but these stood out in my mind when writing this.

-LavaJoe

Mark Williamson

Posts: 14
Nickname: mjw
Registered: Jun, 2003

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 25, 2007 12:00 PM
Reply to this message Reply
>
> Will someone name a single feature Ruby has that wasn't
> available in LISP or Smalltalk first?

The biggie is that Ruby doesn't expect everything to be Ruby - Lisp, Smalltalk (and Java) are all very well as long as you stay 'in system' as soon as you start talking to components written in other languages you need to dive into the heavy engineering right off - CORBA, web services and the like.

Ruby (and Python) make it very *easy* to interoperate with other things.

Mark Williamson

Posts: 14
Nickname: mjw
Registered: Jun, 2003

Re: What Are Your Ruby Pain Points, Really? Posted: Feb 25, 2007 12:05 PM
Reply to this message Reply
For me (and this is true of Python too) the MOST annoying thing by far is the way these languages deal with things like seg faults - just dropping you out into the OS. It doesn't happen often but when it does you are well and truly stuck. And then I am left trying to run the language under the likes of valgrind to find out what the %&$# went on (I haven't tried to do that with Ruby yet but Python is not at all nice under valgrind)

Not sure what the solution is but the current lack of information is horrible.

Mason Deaver

Posts: 2
Nickname: mdeaver
Registered: Mar, 2006

Re: What Are Your Ruby Pain Points, Really? Posted: Mar 6, 2007 5:08 PM
Reply to this message Reply
Back in March and April of 2006, David N. Welton posted a blog entry comparing TCL (which he is familiar with) to Ruby (which he was learning at the time). It's a well-thought-out posting: His critiques of when Ruby doesn't stand as tall as TCL can be considered one person's Ruby pain points. It's interesting reading: Part 1 is at http://journal.dedasys.com/articles/2006/03/06/ruby-vs-tcl and Part 2 is at http://journal.dedasys.com/articles/2006/04/12/ruby-vs-tcl-round-2

Flat View: This topic has 29 replies on 2 pages [ « | 1  2 ]
Topic: What Are Your Ruby Pain Points, Really? Previous Topic   Next Topic Topic: The Python Conference

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use