Re: Confirm my Performance Test Against Java?

On Thursday 20 August 2009 10:22:39 am Ben Christensen wrote:
> That being said, I am trying to figure out what the "Ruby way" is -
> which so far is far from clear to me.
[...]
> What example opensource projects can you refer me to which espouse the
> "real Ruby" style of doing things?

I can't think of any particularly good examples, mainly because...

> unless it's a small team
> of very competent people who all believe in the same paradigm and treat
> their code as art.

I was part of just such a team. We built a set of semi-formal rules, and an 
always-outdated document about coding style. Mostly, though, our coding style 
evolved together because we were always in each other's code and over each 
other's shoulder.

So, unfortunately, I've developed a very visceral and intuitive sense of what 
"real Ruby" should be, what's idiomatic, but I find it difficult to express.

I can point to a few things you've probably heard:

 - Duck typing. The type and class hierarchy is completely irrelevant. All you 
care about is whether the object in question responds to a particular method. 
(This means you should more often use #responds_to? rather than #kind_of? if 
you're testing your arguments at all.)

 - Encapsulation. Not as in enforcing what's private, because you can't 
(there's always #send and #instance_variable_get), but as in, push the logic 
back into the appropriate object, rather than into something operating on that 
logic.

 - DSLs. Or, less buzzword-y, define what you'd like to be able to do, and then 
figure out how to do it. Go by what's most expressive, and most sounds like 
English -- treat code as communication. "Code like a girl."

 - Don't Repeat Yourself.

I can give you some extreme examples: Rake (or even Capistrano), Hpricot (or 
better, Nokogiri), Sinatra, Markaby, and Rspec (or test-spec, etc).

I'm not suggesting you read the source of all of them. Rather, see how they 
might be used. Sinatra is a particularly powerful example, especially combined 
with Markaby -- though I prefer Haml for real projects. Rails is a fine 
framework, but it's beautiful to see a framework dissolve into nothing more 
than:

get '/' do
  'Hello, world!'
end

> For example, if both Java and Ruby both performed single threaded
> transactions at 150ms each, and both scaled to 10 concurrent threads
> equally well, but Java continues to scale to 30 concurrent threads and
> Ruby does not, then that's a scenario where I can add 3 machines to
> scale Ruby horizontally and truly argue that the cost of the hardware is
> more than made up for by lower developer costs.
>
> But, "per request" performance does not get improved by this type of
> solution.

A good point. Still worth investigating whether Ruby can be "fast enough" for 
this. Just for fun, here's a quick presentation:

http://www.slideshare.net/wycats/merb-camp-keynote-presentation

This is also relevant, as there are plans to merge Merb and Rails at some 
point, while retaining the advantages of Merb -- particularly performance.

> Adding faster hardware does not make Ruby catch up to Java - since Java
> also improves with faster hardware.

Yes, you've said this before -- but it doesn't have to. Take your example 
above -- if you can get Ruby under 150 ms, that's good enough. Adding faster 
hardware gets Ruby under 150 ms. If it gets Java down to 30 ms, what's the 
point?

> It provides a better use experience to the user and (according to Google
> and Amazon) increases their usage of the system.

I'm curious what the threshold was for this to make a difference.

Certainly, at a certain point, it doesn't. The difference between 16 ms and 0.6 
ms would actually be invisible to the human eye. But while 100 ms vs 50 ms may 
make a difference, I'm skeptical. Users are annoyed at having to wait a tenth 
of a second for a response?

> The speed at which an application responds to an end users request
> impacts the overall usability of an application.
>
> It is for this same reason that things such as network compression,
> network optimization (CDNs, Akamai route acceleration etc) and client
> side caching also all play a role.

These all make sense -- Akamai in particular -- in the context of having a 100 
ms response instead of, say, 500 ms or a full second, or in the context of 
scalability.

> --  when was the last time the type system saved you?
>
> It's the toolset as you stated that you suspect.
>
> The readability of code to know exactly what types a given argument,
> variable or array contain.

To me, this falls back into Duck Typing. What type does this argument contain? 
Why is this a meaningful question? If I want it to contain a string, for 
instance, all I really need to know is whether it responds to #to_s.

More likely, it's a more complex object, but it's still the behavior that I 
care about, not the type of it. And this intuitively makes sense -- in the 
real world, also. When making a hiring decision, do you care about the "type" 
of the person -- their degree, their sex, their skin color? Or do you care 
what they can do, and how they'll interact with the rest of the team?

Yes, the degree may be an indication of that, but it's not really what you 
care about. And certainly, the other things I mentioned shouldn't enter into 
the equation at all.

> For example, code completion in these tools to suggest the available API
> methods is almost useless, as they offer virtually every method
> available under the sun, as they are not interpreting what actual type
> the variable is.

Because it probably doesn't have one yet.

While it's a bit different, try running an IRB shell with your favorite 
framework loaded and some sort of tab completion. It won't be perfect, but 
it'll probably work.

In the mean time, I'm going to say that it isn't an issue for me, simply 
because if the framework I'm using is so complex that I need code completion 
for daily work, I'm probably using the wrong framework. I can think of some 
times it would've been convenient, but not nearly worth having to use one of 
these other languages.

> Therefore they'll show me 15 different versions of a
> method with the same name, all for different object types from the Ruby
> API.

Any one of them would probably have been a starting place.

> Thus, I must now depend on a team of developers properly documenting
> everything, using very descriptive naming conventions (and properly
> refactoring all of that when changes occur), and wrapping everything in
> unit tests.

These are things you should rely on anyway.

No, not Hungarian notation, but calling the variable something more 
descriptive than 'a' and 'b'.

> Now, all of those are "ideal" cases - ones I believe in and stress
> continually. I have hundreds and hundreds of unit tests and automated
> build servers etc - but in the "real world", getting teams to comment
> every method, properly name (and refactor) variable names and cover
> everything in unit tests just doesn't happen

I don't comment every method. I should comment more than I do, but for 
example:

def writable_by? user
  # ...
end

Tell me you don't at least have a guess what that does.


> -- 100 lines of code is generally easier to read and
> -- debug than a thousand.
>
> I'll give you that - but I have yet to see anything that proves to me
> that a competent developer using both Ruby and Java (or C# for that
> matter) would have 10x as much written code than they would in Ruby.

It's probably an exaggeration, but not much, though I admittedly have limited 
experience in Java. But as an example, how much time do you spend writing 
interfaces? Maybe it was the nature of the assignment, but I would guess 
easily 20-30% of my time doing Java in school was doing things like writing 
interface definitions.

That whole file becomes irrelevant in Ruby.

And I would say the same for Ruby or Python, and to a lesser extent, Perl and 
Lisp -- it does end up being _significantly_ less code. I'm learning Lisp now, 
and this book:

http://gigamonkeys.com/book

opens with just such an anecdote:

"The original team, writing in FORTRAN, had burned through half the money and 
almost all the time allotted to the project with nothing to show for their 
efforts... A year later, and using only what was left of the original budget, 
his team delivered a working application with features that the original team 
had given up any hope of delivering. My dad credits his team's success to 
their decision to use Lisp.

"Now, that's just one anecdote. And maybe my dad is wrong about why they 
succeeded. Or maybe Lisp was better only in comparison to other languages of 
the day..."

I could say the same -- certainly Java is going to be better than FORTRAN. But 
you'll still occasionally find the story of the team which beat everyone to 
market, or swooped in and rewrote a failing project, or won.

> The "cruft" so often referred to are things that I don't even consider
> or think of. Boilerplate code ... clutter and sometimes annoying ...
> fades into the background and tools remove the pain of it.

I don't think tools would remove the pain of looking at it, at least -- and 
yes, it is annoying. Even if the language is going to be statically typed, 
consider the runtime exception. If the Java compiler knows enough to know that 
I forgot to declare what type of exceptions a method might throw, why do I 
have to specify them at all? If it's for the sake of other developers, why 
can't the tool tell them?

After all, there are going to be plenty of methods which really wouldn't care 
about exceptions -- just let them pass through, let some other layer handle 
them.

I also find it telling that with Ruby, I can get by with just a good text 
editor -- TextMate for OS X was excellent, though I now use Kate on Linux -- 
whereas with Java, I would pretty much need a tool just to remove the pain of 
the language.

> Amazon referred another book called "The Ruby Way" which may also
> provide me good insights. Any experience with that one?

None. I did read a book called "The Rails Way" which was excellent, and seems 
to be from the same series, but by a different author.

> In fact, I'm trying to figure
> out how to rip Java out of my webapps completely and leave that to the
> backend webservices and let the presentation layer be as free from
> "code" as possible.

Look at Haml and Sass. You'll either love it or hate it.

> For example, if I can accomplish a dynamic front-end purely driven by
> client side Javascript using AJAX techniques with a REST style
> webservices backend, I will try to pursue that.

I like jQuery for this. Rails and Merb seem to be moving back towards 
integrating this kind of thing -- "link_to_remote" is an old-school example, 
and I suspect we'll see more of this sort of thing in the future.

I've also been a big fan of replacing the X in AJAX with either JSON or HTML, 
as the situation demands. While it's a bit sloppy, HTML makes sense in that I 
can then have all the HTML-generation stuff in the server-side views, where 
they belong, and the Javascript on the client is that much simpler. But if I 
was writing a richer client, JSON would be ideal, at least until someone shows 
me a decent Javascript Yaml library.

> The middle ground seems to be pursuing Ruby or something else that is
> still server-side, but better suited to the always changing pace of
> webapp dev and more creative, script driven coding style better suited
> to web developers and designers.

I think this would work well with the above. In particular, Rails has been 
very REST-oriented for a very long time.