I agree with the McGovern thing, btw. At least, I think I do…it was
hard
to understand what he was trying to say with so many spelling, grammar,
and
logic mistakes.
I blogged a few responses, if anyone’s interested in reading a few more:
Charles,
Informative and exciting post. Thank you for it and for your work on
JRuby. I look forward to it.
Best regards,
Bill
----- Original Message -----
From: Charles O Nutter
To: [email protected]
Sent: 2006-03-30 12:46 PM
Subject: Re: [Rails] Re: Is this an elaborate hoax/troll?
I just stumbled across this thread, and figured I should inject a few
opinions. I am one of two active developers on JRuby, where my main
charge has been the redesign of the core interpreter and planning for
various stages of compilation. I also recently got IRB and Rails’
generate script working, and I’m currently focused on optimizing the
interpreter a bit before we present JRuby at JavaOne. I’ll try to
address some of the issues people have brought up:
- Java is slow
I had thought this myth was entirely debunked, but as others have
commented Java is nothing like slow. In certain scenarios there’s a bit
more overhead than on “hand-optimized assembler code” but then you
probably aren’t going to hand optimize a million lines of assembly
either. Java is actually, in many cases, faster than compiled C code,
owing to its ability to optimize and re-optimize code based on usage
patterns. There’s never just one way to optimize a code path, and the
mixed-mode compilation Java does while running allows it to exceed
native code frequently. Take a look at any of the typical language
shootouts or performance benchmarks. On equivalent algorithms, Java is
extremely fast…in many, many cases far faster than the current Ruby
code.
The following benchmark shows Java beating Ruby by an order of
magnitude in almost every case, though it frequently uses more memory to
do it:
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ruby&lang2=java15
Even if the benchmark is flawed, it’s hard to argue that an optimized
Ruby implementation on the JVM would necessarily be slower.
- Enterprise is a loaded term that isn’t important
I agree. Enterprise has become as meaningless as SOA, Middleware, and
their ilk. However, the concepts behind the word (or the concepts I’d
like to believe are behind the word) are very important.
“Enterprise Java” has come to mean many things to many people. If you
equate Enterprise with Enterprise Java Beans, then you’re selling the
platform short. EJBs may have been initially compelling, but their
verbosity and complexity have doomed them to ridicule. Don’t write off
the entire platform, however. The Java Transaction API has made
cross-request and even cross-server transactions trivial to handle.
Enlisting n remote servers into a larger transaction is handled
transparently. The Java Message Service has provided a simple, reliable,
cross-platform and cross-server means of handling asynchronous
communications. It really “just works” and provides huge benefits for
long-running processes and offline transactions. Java Management
Extensions, while not officially part of Enterprise Java, provide
consistent, uniform remote administration and management capabilities,
along with managed, monitored services throughout an application
cluster. And while we’re on that topic, clustering, failover, and
session replication within typical Enterprise Java clusters “just works”
too. I won’t even go into JDBC, perhaps the most impressive
cross-platform and cross-database SQL api that exists.
I am by day officially a “J2EE Architect”, though my eventual role has
me mostly escorting other developers through the pain of writing J2EE
applications and trying to find better tools, frameworks, and patterns
to make that process simpler. I feel all the typical pain of J2EE
developers, and I agree there are bad areas…but don’t throw the baby
out with the bathwater.
- Bringing Ruby and Rails to Java will somehow corrupt Ruby and Rails
The goal of JRuby is to create a fast Ruby interpreter that looks,
feels, and acts just like Ruby. We will not require any modifications to
Ruby (and in fact we run with Ruby’s own lib/ruby/1.8 libraries), and we
only reimplement specific features where the Ruby equivalent doesn’t
consider Java’s capabilities or where Ruby implements those features in
C. A similar argument goes for Rails: Rails must be able to run without
modification under JRuby, albeit behind a “mock CGI” Servlet that can
simulate running with fastcgi and friends.
What we do hope to provide is a way to access Java’s good features
from within Rails. JDBC is an obvious match for ActiveRecord, and JTA
can provide transaction support seamlessly. Once inside a J2EE cluster,
we can also enable replication and failover for Rails sessions and
requests by wiring those subsystems into those provided by the cluster.
We can wire JMS into available messaging libraries for Ruby, allowing
Rails to submit jobs to any JMS-aware server (which ultimately could
mean any messaging server, since most of them support JMS). The list
goes on and on.
It is true, and must be accepted, that while Ruby the language is a
marvelous, beautiful thing, Ruby the platform still has some growing up
to do. Unicode support is partial and inconsistent. Support for
locale-specific calendars, messages, and behaviors is nowhere near what
Java provides. Integration with other languages and other platforms is
sketchy at best. Ruby simply lacks many features that would help it gain
acceptance as more than “just another scripting language.” I’m certain
Ruby will get everything it’s missing over time, but by putting Ruby and
Rails on the JVM we may be able to have them now. Who knows, perhaps the
APIs that develop out of Ruby on the JVM will filter back into the
design process for future versions of Ruby.
- My plan for JRuby (though just one view of where we’re going)
I will try to lay out briefly the current plan for JRuby.
- We are currently working very hard to get Rails running for a simple
case. The generate script already works and generates usable code and
configuration. The next step is getting Rails to handle a request. We
currently get pretty far into that process before things bomb out, and
expect to have it working by the end of this month. - JRuby is, despite Java’s speed, quite slow right now. The original
author just did a simple port of Ruby’s C code to what it would look
like in Java, and as a result many JVM features that could speed Ruby up
were crippled or impossible to utilize. My work recently has been to
completely rewrite and rewire the internals of JRuby to enable
compilation to Java bytecode, full continuations support, tail-call
optimization, and multi-VM (running multiple “Rubies” inside the same
JVM). All of these will help improve performance, and we hope to exceed
Ruby 1.8 performance at some point.
I would welcome any questions or comments. Our main goal with JRuby is
to provide a real Ruby environment that happens to be running on the
JVM, and to enable Ruby code to integrate with Java code whereever it is
useful to do so. We would be as happy as you all if Ruby were to
supplant Java as the language-of-choice, and if JRuby helps further that
goal…all the better.
–
Charles Oliver N. @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
On 3/30/06, Charles O Nutter [email protected] wrote:
I just stumbled across this thread, and figured I should inject a few
[snip]–
Charles Oliver N. @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
Thanks for this great post, Charles. Thanks especially for dispelling
the “java is slow” myth that just will not die, and was getting thrown
around a bit earlier.
Thanks for this great post, Charles. Thanks especially for dispelling
the “java is slow” myth that just will not die, and was getting thrown
around a bit earlier.
I don’t know about the speed in web service application. But most
people get the “java is slow” thing from java desktop applications.
Which are utterly useless and famous for being unresponsive and I have
never seen a good java desktop application.
However comparing a compiled java application with an uncompiled ruby
application as was pointed out in a chart earlier is strange. It’s
strange to say that the solution would be to run ruby in java instead
of just making a ruby compiler.
I’m just afraid that hereafter there will be 2 version of ruby. One
real and one in java.
–
I understand that perspective, but our goal is to run Ruby apps as well
as
Ruby does, without modification. In other words, we want to run whatever
the
C implementation can, as much as possible. We’re not about to try
forking
the language or “embracing and extending” it, Microsoft-style.
As for the compiler question…the current work being done on a Ruby
compiler does not, I’m sorry to say, compile Ruby down to native code.
It
compiles it into bytecode, just like Java, and the new Ruby VM then
executes
that bytecode. It promises considerable performance improvements in some
areas, but since it will be layer on top of the existing implementation
it
will only provide limited improvements in others. It’s excellent work,
but
it’s important that when Rubyists refer to the new “compiler” they
understand that it is a bytecode compiler.
What, then, is the harm in writing a compiler to turn Ruby into Java
bytecodes? The Java VM is well-established and has shown its potential.
It
performs extremely well, considering object allocation, garbage
collection,
and native threads are all provided out-of-the-box. It is also very
stable,
widely-deployed, and supported on many platforms. I think Ruby on the
JVM is
a sure win, both both the Java and Ruby worlds.
Want more justification? There are at least three projects going right
now
to make Ruby for the .NET CLR…I’d certainly hate to see Microsoft
corner
the market on VM-based Ruby, how bout you?
On 3/30/06, Jon Gretar B. [email protected] wrote:
Thanks for this great post, Charles. Thanks especially for dispelling
the “java is slow” myth that just will not die, and was getting thrown
around a bit earlier.I don’t know about the speed in web service application. But most
people get the “java is slow” thing from java desktop applications.
Which are utterly useless and famous for being unresponsive and I have
never seen a good java desktop application.
This used to be the case, but Swing and SWT have come a long way.
Take a look at SmartCVS, Eclipse, Azureus, etc. They may use a lot of
resources and be hard to develop, but they aren’t necessarily slow. 
Anyways, back to Ruby…
On 3/31/06, Rob S. [email protected] wrote:
This used to be the case, but Swing and SWT have come a long way.
Take a look at SmartCVS, Eclipse, Azureus, etc. They may use a lot of
resources and be hard to develop, but they aren’t necessarily slow.
Actually… I hate to use both Eclipse and Azureus. Those are not slow
in the processing part. But simple things like resizing the window or
dragging seperators is intolerable. It’s like having the monitor
working on 5 frames a second. And that is just wasting valuable time
and intolerable in an IDE.
And they don’t take a lot of resources… The take A LOT of
resources. Having Azureus running made my laptop unusable since it
only has 512mb.
–
To me, that sounds to me more like failure to understand the concept of
architecture than over-architecting. Architecture should be about
making the programmer’s life easier by making the the processes cleaner
and more obvious. This framework you describe is forcing programming by
side effect, which is always a bad idea.
An architecture is a wonderful servant, but a terrible master.
I hate programming by side effect. It leads to misuse of the platform
and odd behaviors when people unwittingly trigger event loops. I spent
5 years straightening out one of those messes.
I understand your pain - I have seen similar situations. I am fortunate
to be senior enough to get away with saying “that won’t work here
because …” and having the leeway to do things right.
A lot of times, the degree of dynamism you describe is actually a result
of a failure to understand the problem space fully. That does not mean
spending a bazillion hours poring over some nimnul’s powerpoint
presentations. It means recognizing that complex solutions generally
mean that you don’t understand the problem yet, and striving for a
simpler solution that encompasses the entire problem space.
In general, it really is easier to solve the entire problem than to
solve just bits and pieces. Special conditions (even if they are
embodied in framework side effects) are generally a sign that something
is not understood fully yet. This is true whether it is J2EE,
Rails, .not (sorry - .net), or even lowly COBOL.
I don’t know about the speed in web service application. But most
people get the “java is slow” thing from java desktop applications.
Which are utterly useless and famous for being unresponsive and I have
never seen a good java desktop application.
I consider eclipse as a good java desktop application, nevertheless,
starting a JVM is expensive in terms of memory consumption and process
cycles.
However comparing a compiled java application with an uncompiled ruby
application as was pointed out in a chart earlier is strange. It’s
strange to say that the solution would be to run ruby in java instead
of just making a ruby compiler.
Well, for the Ruby compiler, there is YARV which is supposed to compile
ruby
2.0.0
I’m just afraid that hereafter there will be 2 version of ruby. One
real and one in java.
The java ruby version probably will just be used for special cases (one
interesting example: together with red5 http://www.osflash.org/red5
Flash
streaming media server)
Roberto S. - http://rsaccon.com
On Thu, Mar 30, 2006 at 10:47:19PM +0000, Jon Gretar B. wrote:
[…]
} I don’t know about the speed in web service application. But most
} people get the “java is slow” thing from java desktop applications.
} Which are utterly useless and famous for being unresponsive and I have
} never seen a good java desktop application.
[…]
I used a good Java desktop application some years ago. It was the DB2
administration application, and I was pretty pleased with it. I also
wrote
a very simple one that worked nicely. That said, I’ve used numerous Java
applications that completely failed to impress me with their
responsiveness, including Azureus and Eclipse.
} Jon Gretar B.
–Greg
I found an answer (Piers C. helped).
Most of you probably already know this but just in case someone is
reading or searching the list archive and would like to know:
The routes in config/routes.rb are TWO-WAY, mapping incoming url
requests AND used as the template to generate urls by the app. Of
course now looking back it is obvious that it has to work that way.
Adding this to the routes.rb map:
map.jnlp ‘page/jnlp/:id/activity.jnlp’, :controller => ‘page’,
:action => ‘jnlp’
Not only handles parsing this incoming url:
http://localhost:3000/page/jnlp/1/activity.jnlp
But the map also is used when interpreting this code in a
PageController view to produce the same url:
link_to ‘Run’, :action => ‘jnlp’, :id => activity
What I’d like to do now is figure out how to combine the :id number
and the static text ‘activity.jnlp’ so that the url can end in:
/activity1.jnlp
This doesn’t work, it is not parsed correctly:
map.jnlp ‘page/jnlp/activity’ + :id + ‘.jnlp’, :controller =>
‘page’, :action => ‘jnlp’
And this doesn’t work:
map.jnlp “page/jnlp/:id/activity#{:id}.jnlp”, :controller =>
‘page’, :action => ‘jnlp’
It produces:
http://localhost:3000/page/jnlp/2/activityid.jnlp
I find it interesting reflecting on my process trying to figure this
out. I tried to follow the url_for code in the rails source but I
knew I was missing something. One part was getting my head around all
the meta-programming used in Ruby and Rails and the other was the
fact that as implemented in Rails, routes affect both halves of the
url process.
On Thu, Mar 30, 2006 at 09:01:55PM -0600, David J. wrote:
} To me, that sounds to me more like failure to understand the concept
of
} architecture than over-architecting. Architecture should be about
making
} the programmer’s life easier by making the the processes cleaner and
more
} obvious. This framework you describe is forcing programming by side
} effect, which is always a bad idea.
I don’t know that it’s always a bad idea, but too much of it certainly
gets frustrating.
} An architecture is a wonderful servant, but a terrible master.
[…]
…and I think that is an excellent definition of overarchitecting.
Overarchitecture means that developers spend more time satisfying the
framework’s demands than the system requirements.
} A lot of times, the degree of dynamism you describe is actually a
result
} of a failure to understand the problem space fully. That does not
mean
} spending a bazillion hours poring over some nimnul’s powerpoint
} presentations. It means recognizing that complex solutions generally
} mean that you don’t understand the problem yet, and striving for a
} simpler solution that encompasses the entire problem space.
Oh, I completely left out the management issues that led to this. The
project began (years before I got involved) with large chunks of the
system
being pushed into development before requirements had been written, and
the
framework was developed concurrently with them. It is only within the
last
year that the framework has stabilized and the developers have stood
their
ground on not starting to code without solid requirements.
} In general, it really is easier to solve the entire problem than to
} solve just bits and pieces. Special conditions (even if they are
} embodied in framework side effects) are generally a sign that
something
} is not understood fully yet. This is true whether it is J2EE,
} Rails, .not (sorry - .net), or even lowly COBOL.
It would be lovely if a high-level list of desired features for the
system
were available to developers. If such a thing exists, it certainly isn’t
available to us nor to the architect who built the framework. Without
knowing what is planned, it’s hard to be abstract in the right places
and
concrete in the others.
I experienced a similar issue in my first real job. I was tasked with
building a new simulation and visualization frontend (in C++) for an AI
engine. I was not told what future use the frontend might be put to,
only
that the existing one was too hardcoded. I wound up writing a
magnificently
abstract MVC system full of clean interfaces that was loosely coupled
and
automatically registered interface implementations at load time and
instantiated objects based on a simple XML file format. It was a thing
of
beauty. It was also too complicated for the owner of the project to
understand (granted, he hadn’t learned how to use any feature of C++
that
wasn’t supported by g++ circa 1990), yet too restrictive to make it easy
to
split the UI and the simulation into separate threads easily.
If they’d just talk to us, we could do what they need. But they never
do.
–Greg
} On Thu, 2006-03-30 at 10:17 -0500, Gregory S. wrote:
} > On Wed, Mar 29, 2006 at 07:35:21PM -0600, David J. wrote:
} > } On Wed, 2006-03-29 at 15:21 -0700, Giles B. wrote:
} > […]
} > } > I’d imagine there are probably lots of overarchitected
enterprise apps
} > } > that could run on Rails quite happily, though.
} > }
} > } Overarchitected? I’m not sure what you mean. I have seen poorly
} > } architected apps, and apps that solved complex problems, but I
have never
} > } seen something that I could truly call overarchitected. Could you
} > } elaborate?
} > […]
} >
} > I will give an example of an overarchitected app. This is not a web
app,
} > but rather a .NET thick client. The names of the various companies
involved
} > are withheld to protect my butt. Basically, the project is in-house,
} > mission-critical software. It is backed by several large databases,
and
} > performs a variety of data entry, manipulation, cleaning, crunching,
and
} > reporting functions.
} >
} > The basis of this application is the almighty framework. In this
} > application, there are persisted objects which are all represented
in a
} > single table with universally relevant information like parent
object, plus
} > side join tables for specific types. Loading and saving is handled
} > automagically by the framework. All such objects exist in memory as
an
} > instance object which holds onto an ADO.NET typed dataset.
} >
} > All screens (and partial screens) must be implemented as subclasses
of a
} > particular framework class, which does framework magic with the
persisted
} > objects. Screens are actually shown to the user in nested tabs and
stacks
} > and popups and such based on a database representation of how the
pieces
} > fit together. For each (partial) screen a user will see, there is an
} > automagically-handled persisted object (AHPO from here on) which
specifies
} > which class to load from which DLL, to what type of AHPO it is
conceptually
} > attached, its title, etc. Of course, it may be a container screen
for other
} > screens, in which case it has no DLL or class itself, just child
screens.
} > And you can have another variant that just points to a screen but
with
} > slight changes. All this information about screens makes it possible
for
} > many controls, based on their names, to automagically bind to the
} > appropriate data value.
} >
} > Constants are held in the database as well. There are these items
with a
} > unique number, a short name, a longer name, an ordering value, and
several
} > additional fields for extra information. They belong to some primary
group
} > of items, but they can belong to more than one group. In the
additional
} > groups, the long name (but nothing else) can be overridden. These
are used
} > for various automagical dropdowns.
} >
} > When first working with this framework, it seemed like it took care
of a
} > whole lot of stuff for you, and the idea of separating out as much
} > functionality as data rather than code was appealing. Eventually,
though,
} > it becomes clear that the app spends so much time on framework magic
that
} > actual user interaction suffers. The system is painfully slow. It
must be
} > deployed on terminal services so that the system running the app can
be on
} > a gigabit link to the database server because so much data has to be
read
} > by the app to accomplish anything, and so much data gets persisted
when the
} > user does anything.
} >
} > This is what it means to be overarchitected. The system is full of
} > beautiful design ideals, but doesn’t actually get the job done well.
Their
} > may be development and maintenance gains, but they are hidden by the
} > development costs (new developers require months of ramp-up time,
which can
} > also lead to staffing problems) and the cost of lost user
productivity as
} > the users wait for the system to respond.
} >
} > --Greg
} >
} > _______________________________________________
} > Rails mailing list
} > [email protected]
} > http://lists.rubyonrails.org/mailman/listinfo/rails
}
}
On Fri, 2006-03-31 at 08:54 -0500, Gregory S. wrote:
} An architecture is a wonderful servant, but a terrible master.
[…]…and I think that is an excellent definition of overarchitecting.
Overarchitecture means that developers spend more time satisfying the
framework’s demands than the system requirements.
I can accept that, with reservations. To me, that still sounds like a
failure to understand architecture at all, with a resulting failure to
architect. But I can agree to disagree.
framework was developed concurrently with them. It is only within the last
year that the framework has stabilized and the developers have stood their
ground on not starting to code without solid requirements.
Your organization is starting to mature. But, you have to be cautious
of the other extreme that leads to capital-M paper Methodologies and
endless meetings (sometime with evil Power Point presentations).
Instead, get your programmers out doing the work of the people whose
jobs they are automating for two weeks, then tell them the problem, and
then let them loose to solve it. It’s a novel approach, but it can
work.
concrete in the others.
wasn’t supported by g++ circa 1990), yet too restrictive to make it easy to
split the UI and the simulation into separate threads easily.If they’d just talk to us, we could do what they need. But they never do.
Most of the time, I have found that the end-users don’t really know what
they want until they see it. It is our role as a support industry to
understand their businesses that we are programming for better than the
users do. The turning point for me was when I was the entire IT
department (third hat), writing applications in support of my own work
(first and second hats).
If the programs didn’t work, the senior estimator (me) went to have a
hear to heart with the IT manager (me) and we made things work. It
didn’t matter that the user (me) didn’t tell the programmer (me) up
front what he wanted. What mattered was that in transacting business we
had discovered a weakness in the tools we had made that was costing us
money, and we fixed the tool to meet our needs.
Apart from multiple personality issues, that experience changed how I
view and construct software. I became much better at anticipating
business requirements in general, and much more understanding that the
business requirements are often fluid.
I began building my programs to offer options and guidelines instead of
rigid rules, and in the process discovered that I was writing less code
that was both simpler and more effective at meeting the business needs.
I wish you good luck in untangling your product. Been there, done that.
There is a light at the end of the tunnel, and it might not be a train.
David J.