I sure hope so:
http://duckdown.blogspot.com/2006/03/additional-thoughts-on-why-ruby-isnt.html
Seems like it’s getting genuine rebuttals, though. It’s actually kind
of amusing.
no, it’s sincere. that’s this totally crazy dude who DHH talks about
in his blog.
btw, I think he’s doing it for the Google Ads revenue. his arguments
don’t even make sense.
DHH has been writing about this on his blog:
Boy, is James McGovern enterprise or what!
http://www.loudthinking.com/arc/000577.html
Calling bullshit on the Enterprise A.s
http://www.loudthinking.com/arc/000578.html
Amusing…
On 3/28/06, Edward F. [email protected] wrote:
–
Ben R.
http://www.benr75.com
I’ve been trying to figure out how to retrieve a http head request
date using http-access2.
I thought this could work:
h = HTTPAccess2::Client.new()
res = h.head(‘http://involution.com’)
print response.header[‘date’],“\n”
However, that seems to be returning Time.now. Any suggestions?
FYI, you can view a http request by doing the following:
telnet involution.com 80
Trying 69.58.21.60…
Connected to involution.com.
Escape character is ‘^]’.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
-----> Date: Tue, 28 Mar 2006 23:01:47 GMT <------- Date Header ----X
Server: Apache/2.0.52 (Red Hat)
Cache-Control: no-cache
Set-Cookie: _session_id=670e36e364a03785011afbfafbc15fde; path=/
Connection: close
Content-Type: text/html; charset=UTF-8
I’m looking at trying to find a way to see what time the server thinks
it
is to do some time zone correction foo.
Regards,
I reviewed most of his arguments, and he is dead on. These are exactly
the reasons that I cannot recommend Ruby as an architecture language
for my company. I love Ruby (so far), but it isn’t ready for prime-time
in my day-to-day work environment (large company with over 8,000 users
on a real-time business critical system).
As I am working with Ruby and Rails, I am discovering both how nice this
combination can be and what its shortcomings are. For the most part,
these are a matter of maturity, not principle. Given another year or
two Ruby could be up to snuff.
With that said, I can recommend Ruby “as-is” for “bread and butter”
applications and utility scripting, and as a “watch” technology as
certain features mature.
At the same time, J2EE is showing its age. After ten years of being
used to write web apps that babysit RDBMS’s, J2EE is harder to use than
ever and slow as molasses at Cold Lake in January. The EJB/DAO design
pattern quadruples the programmer’s work with negative payback in
performance and reliability.
JRuby (Ruby running under a JVM) is actually very interesting to us, but
it is about 80 bugs away from being ready for active consideration.
JRuby offers the internationalization, threading, and other support that
regular Ruby does not yet, because the underlying JVM and Java runtime
classes support them.
Considering he is not directing his argument at Rails, I think he is
pretty much right. But Rails (or any web development environment) is
a completely different ballpark. His verbose argument boils down to
the fact that scripting languages are not good for commercial
applications, but he fails to mention they are great for web
applications.
-John
–
John S.
Computing Staff - Webmaster
Kavli Institute for Theoretical Physics
University of California, Santa Barbara
[email protected]
(805) 893-6307
Sorry… But JRuby just mystifies me… Why would you want to make
Ruby slower???
Can you just point out to me how running Ruby in a virtual machine is
going to improve anything?
Regarding the enterprise support for 8000 users… I would say that
it’s not really a problem for Ruby on Rails. It’s more the headache of
the developer of the application rather than problems of the framework
builders. It’s true that many things is immature and untested in Ruby
when it comes to high user base and things like load balancing is
really non-existent. But I frankly don’t want it in there except as an
optional gem because I just simply don’t want to know of it’s
existence until I need to use it.
To sum it up… Yes… Rails is maybe not ready for the enterprise
market. But isn’t it really OUR job to make it ready?
On 3/28/06, David J. [email protected] wrote:
JRuby (Ruby running under a JVM) is actually very interesting to us, but
no, it’s sincere. that’s this totally crazy dude who DHH talks about
of amusing.
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
On Mar 28, 2006, at 5:41 PM, David J. wrote:
I reviewed most of his arguments, and he is dead on. These are
exactly
the reasons that I cannot recommend Ruby as an architecture language
for my company.
Good grief, if you’d read DHH’s post at <http://www.loudthinking.com/
arc/000577.html> you’d see that the guy was initially claiming that
Ruby lacked support for regular expressions, instance variables, lack
of a packing system, no access control, etc. (and he did make these
claims, I read his entry myself before he edited it) and when
“bullshit” was called he rewrote them as the soft, amorphous points
that you’re now agreeing with.
–
Jason P.
[email protected]
“The computer allows you to make mistakes
faster than any other invention, with the
possible exception of handguns and tequila.”
I didn’t see his original post.
His points (current posting) are not about the design of ruby, they are
about the maturity of the platform for use in large scale developments.
To you they may be amorphous, but to my day to day work they are
crippling (except for the powerpoint presentations - I can do without
those).
Give Ruby a year and it can easily be up to snuff, if the points are
addressed instead of shooting the messenger (however obnoxious he may
have been).
Could you be more specific about the points that actually matter to you?
I see very little in Rails that makes it less suitable for the typical
“enterprise” labelled application than either Java or .NET web
application frameworks. Nearly all enterprise applications are in fact
depressively simplistic front-ends to poorly designed databases that
meet the supposed needs of process designers far better than their end
users, and mostly exist only extend the fiefdoms of has-been
technology managers and the change management institutions that they
serve.
We call this politics and accept it as a given, and I am no different
- really I don’t care. The spirit of Rails is so opposed to any sort
of enterprise development of this description that programming in this
language may as well not even be considered the same occupation as
programming in a corporate soup of powerpoints, paperwork, buzzwords
and vendor partnerships.
The battle for the enterprise is not worth winning, why fight it.
On 3/28/06, David J. [email protected] wrote:
have been).
arc/000577.html> you’d see that the guy was initially claiming that
"The computer allows you to make mistakes
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
–
Jeremy H.
I’ve read the arguments and they range from reasonable to foolish, but
the
real point is that he’s ‘not even wrong’ as the saying goes.
I’ve been making my living as an engineering manager working on
commercial
enterprise Java aplicatations for almost 10 years now. Ruby on Rails is
a
perfect example of a disruptive innovation - no it’s not as good as java
in
some ways - time zone support for one - but it’s waaaayyy better than
java
in other more important ways. This guy’s on his way to being the COBOL
programmer of 2010.
The idea, btw, that Java programmers/programs are inherently better at
architecture, btw, is an urban myth.
On Tue, 2006-03-28 at 23:59 +0000, Jon Gretar B. wrote:
Sorry… But JRuby just mystifies me… Why would you want to make
Ruby slower???
If (big if) Ruby follows the pattern of other languages using the JVM,
it will compile the source to java byte code (.class file). My own
benchmarks have established that a Java hotspot compiler (which
recompiles frequently used byte code to native code) will perform within
10% of hand optimized assembly language for the same tasks. I was able
to trace the cause for the 10% difference to the stack frame handling,
which buys stack safety at the expense of a little performance.
If Ruby follows this pattern, the JIT runtime compilers should speed
ruby up to at least match Java.
If there are performance issues with the byte code being generated by
the JRuby compiler then those are best resolved by hitting the keyboard,
not the messenger.
Can you just point out to me how running Ruby in a virtual machine is
going to improve anything?
Off the top of my head …
-
JIT compiler.
-
Unicode support is a huge thing for internationalization. I was
surprised that Ruby kept all of the code page garbage of the '80s, given
the maturity of the C libraries supporting the unicode specification and
that Ruby’s country of origin uses a non-latin alphabet. -
With java’s unicode support is also a mature library of character set
conversions. -
Native support for threading is a critical thing if you are to make
vertically scalable apps. -
Instant, painless migration path to allow reuse of existing mature
application logic. I am not going to rewrite 2 million lines of my
company’s java code in Ruby, but having that pre-existing work available
to reuse without change will save me a lot of effort in migration, and
make it easier to promote the Ruby platform in the long term.
Regarding the enterprise support for 8000 users… I would say that
it’s not really a problem for Ruby on Rails. It’s more the headache of
the developer of the application rather than problems of the framework
builders.
The platform needs to support a few minimum constructs for that to work.
Delphi never made it as an enterprise platform because it did not
support the vertical scalability necessary. Vertically scaling a Delphi
app required one to throw out hte “Delphi” parts of the environment
andbecome an Object Pascal programmer. Java made it at the enterprise
level because the JVM handled the baseline requirements for vertical
scaling, and the core objects in the java runtime library were built to
handle it.
It’s true that many things is immature and untested in Ruby
when it comes to high user base and things like load balancing is
really non-existent. But I frankly don’t want it in there except as an
optional gem because I just simply don’t want to know of it’s
existence until I need to use it.
Bingo … but I need it available before I can even seriously consider
it. Unfortunately, that stuff is not “tack on”. It impacts the core
design of the engine. If the engine doesn’t support it, the language
will never perform adequately under pressure.
There are areas where Ruby needs to mature to make it a viable
enterprise platform. Rails also has some areas it needs to address,
but those are not fundamentally issues with Ruby. None of the issues
raised are with the fundamental designs of either product.
They are issues with their current level of maturity that can be
addressed better by hitting the keyboard than slamming the blogger.
To sum it up… Yes… Rails is maybe not ready for the enterprise
market. But isn’t it really OUR job to make it ready?
I agree … but slamming the messenger in a flame war doesn’t resolve
the issues. Taking his valid points (who cares about powerpoint
presentations) and resolving them would bring Ruby much closer to being
a viable enterprise platform.
On 3/29/06, David J. [email protected] wrote:
ruby up to at least match Java.
If there are performance issues with the byte code being generated by
the JRuby compiler then those are best resolved by hitting the keyboard,
not the messenger.
But having a real ruby compiler (Something I understand is coming
built in version 2) is always going to be faster. The problem I have
always had with java is that virtual machines will ALWAYS slow things
down. It’s just the way it works. Java is indeed faster now when
compiled(but with much higher memory use) but that is because of
compilation. I would think that a compiled ruby app would be much
faster.
Native support for threading is a critical thing if you are to make
vertically scalable apps.Instant, painless migration path to allow reuse of existing mature
application logic. I am not going to rewrite 2 million lines of my
company’s java code in Ruby, but having that pre-existing work available
to reuse without change will save me a lot of effort in migration, and
make it easier to promote the Ruby platform in the long term.
But why oh why Java??? The slowest thing available… People started
developing in Ruby to get away from things like Java.
The platform needs to support a few minimum constructs for that to work.
Delphi never made it as an enterprise platform because it did not
support the vertical scalability necessary. Vertically scaling a Delphi
app required one to throw out hte “Delphi” parts of the environment
andbecome an Object Pascal programmer. Java made it at the enterprise
level because the JVM handled the baseline requirements for vertical
scaling, and the core objects in the java runtime library were built to
handle it.
Yes… Also one of the reason Java won that battle is because for
some reason schools seem to prefer teaching Java. I just don’t
understand why some developers incist on using java for desktop
applications for example. Being cross platform doesn’t help if the
users dislike using the software because it is slow and unresponsive.
But your point is true. But it only says why Java won Delphi.
I agree … but slamming the messenger in a flame war doesn’t resolve
the issues. Taking his valid points (who cares about powerpoint
presentations) and resolving them would bring Ruby much closer to being
a viable enterprise platform.
The messenger was not slammed because of the message. He was slammed
because:
A) Nobody likes people who proclaim themselves industry leaders when
ho showed many times that he had marginal programming knowledge
B) He didn’t even seem to have looked at Ruby. His message was full of
errors and FUD. Even though he tried to hide it later. (ceck out JHH’s
post to see what I am talking about)
–
On 29/03/06, Jeremy H. [email protected] wrote:
Could you be more specific about the points that actually matter to you?
I see very little in Rails that makes it less suitable for the typical
“enterprise” labelled application than either Java or .NET web
application frameworks. Nearly all enterprise applications are in fact
depressively simplistic front-ends to poorly designed databases that
meet the supposed needs of process designers far better than their end
users, and mostly exist only extend the fiefdoms of has-been
technology managers and the change management institutions that they
serve.
Sure, here’s some that come to mind
Support for Oracle; while I haven’t tried using Oracle with Rails
personally, there’s enough people having trouble with it to make me
suspect that Oracle+Rails might not be a good combination
Support for DB2: last time I checked, this was still a problem, but
people were working on it. Anyone know what state it’s currently in?
Support for stored procedures and views: Rails has adopted a stance
that makes stored procs and views (in any DB) difficult to implement.
Never mind that Rails’ “sweet spot” says that stored procs and views
aren’t necessary; in any business-critical enterprise DB, an app
developer will only get access to data via views and stored procs, so
needs to be able to work with them. It can be done in Rails (at
least with Postgres, which I’ve tried), but it’s not trivial.
Support for legacy databases: again, Rails can be made to work with
non-Rails-conformant table and field names, but it’s painful. Not
such a big deal once you get your head around it, but having to do
this will start to slice into Rails’ massive reduction in dev time and
resources over e.g. J2EE.
Lack of support for MQ: this may seem a bit left field, but anyone
with experience across a range of enterprise-class IT will be familiar
with sites that mandate all app-to-DB connectivity must go through
MQ. Your app submits its “request” onto a queue, the database reads
your request and puts the response on another queue, your app picks up
the response from the queue. It’s big and clunky, but it works, is
rock solid reliable and you’ll find it just about everywhere an IBM
mainframe is in place. Sure, you could (probably) build a MQ
interface onto Rails, but it doesn’t exist now. You could use Rails
to bolt a Web services layer onto MQ, but now you’ve just increased
the scope of what you’re developing quite significantly.
Development tools: RADrails is coming along, but it lags behind e.g.
Visual Studio by some way at present. If your entire enterprise dev
team can be infected with the Rails bug, and is happy to put up with
dev tools of a significantly lower standard than what they’re
currently using, fine, but most dev shops will have at least one old
guy in a cardigan who’s memorised every aspect of Visual Studio and
will fight back if you try to take it away from him.
Don’t get me wrong - Rails can do lots and lots of good stuff, and its
niche is a quite large in the scale of “massive enterprise system”
through “Mum’s photo album” development tasks. I really like Rails,
use it daily, and am slowly introducing it to places where I work with
promising results. Building a prototype for some complex app in Rails
in a few hours is an absolutely KILLER way of demonstrating
productivity increases, and Rails fits with my subversive persona very
nicely. I agree that in 12 months’ time, it’ll be a significantly
better fit for many enterprises.
However:
- not all enterprise apps are simple front ends on top of poorly
designed databases - legacy databases and interfaces are all through enterprise IT shops,
and you’d better have a way of dealing with them if you’re introducing
a bunch of new technology - end-users often have an extremely high degree of input into app design
- many/most/all IT managers are constantly bombarded by “the next big
thing” from all their vendors, and Rails is just another “next big
thing” in their minds and will be treated accordingly - J2EE and .NET actually work quite well in a lot of places, for a lot
of apps
Interested in others’ thoughts on this - good thread
Regards
Dave M.
On Wed, 2006-03-29 at 13:54 +1100, David M. wrote:
serve.
Support for stored procedures and views: Rails has adopted a stance
this will start to slice into Rails’ massive reduction in dev time and
interface onto Rails, but it doesn’t exist now. You could use RailsHowever:
Interested in others’ thoughts on this - good thread
I’ll add my $ .02 - easy/good access to enterprise authentication system
and I say this because of the incredible amount of time that I have
wasted trying to make rails connect to an LDAP server.
Craig
On Tue, 2006-03-28 at 21:03 -0500, Jeremy H. wrote:
Could you be more specific about the points that actually matter to
you?
-
Native support for threading
-
Standardized support for prepared statements in the RDBMS adapter
classes (once I have more Ruby experience I plan to address this one
myself) -
Unicode support
-
Platforms other than Windows and *nix. Z/OS would be a good place.
Ruby would be a great competitor for Rexx. -
Performance boost
I see very little in Rails that makes it less suitable for the typical
“enterprise” labelled application than either Java or .NET web
application frameworks. Nearly all enterprise applications are in fact
depressively simplistic front-ends to poorly designed databases that
meet the supposed needs of process designers far better than their end
users, and mostly exist only extend the fiefdoms of has-been
technology managers and the change management institutions that they
serve.
:o) Seen some of that.
On the other hand, when handling well over 1,000,000 transactions per
hour, 24x7 in a highly integrated but heterogeneous environment, where
downtime cost is measured in tens of thousands of dollars per minute,
most of the work is not going into the front end. Pretty is reserved
for the outside world. Internal apps must be fast, correct, and cleanly
constructed to not hammer other apps.
The front end may be depressingly simple (my opinion of a good web page
is pure white with black text in Times New Roman 12 point font, and no
other adornment). But the back ends tend to be both very robust and
challenging, and not entirely because of old bad designs.
We call this politics and accept it as a given, and I am no different
- really I don’t care. The spirit of Rails is so opposed to any sort
of enterprise development of this description that programming in this
language may as well not even be considered the same occupation as
programming in a corporate soup of powerpoints, paperwork, buzzwords
and vendor partnerships.
That is a poor way to promote the platform, and you are making a common
mistake (one that Mr. McGovern did also) of assuming that just because
you use a common programming language you are also using the same design
methods.
He seems to be working under the assumption that all agile development
is unplanned in nature, and you seem to have the opinion that
communication with one’s peers is a bad thing if you’re programming in
Ruby. Ironically, what I see is that you are proving one of his points
by restating it from the other perspective.
Enterprises do engage in agile development. But part of working in an
enterprise environment is the understanding that you are interacting, in
real time, with potentially hundreds other programs that are all
critical to your own paycheck.
Furthermore, since Enron, people go to jail for certain types of
failures. I have on more than one occasion asked for “get out of jail
free” letters where I was asked to manually correct information that a
faulty program or process had entered in a database table. Some of that
paperwork is there for good reasons.
Discussing changes or additions to processes that will impact your peers
in other departments is not a political process. It is a professional
courtesy and a technical necessity. You be the one who is woken up at
3:00 AM on Sunday because someone made a change that hammered your
program and didn’t tell you!
When I was a 1 man IT shop, I could pretty much do what I wanted. In a
2 man IT shop (at my church), we have seen a need for formal change
control. In a company with several hundred programmers and technical
people, maintaining those channels of communication is a large part of
why my company is having record years while our competitors are filing
bankruptcy.
As far as buzzwords goes, Rails is the embodiment of the buzzword “MVC”.
It has “AJAX” support. It uses “Adapters” to talk to “RDBMS”. It uses
“helpers”, “containers”, “blocks”, “hashes”, “iterators”, and so on.
The battle for the enterprise is not worth winning, why fight it.
Because if you can win there, you can win anywhere. In the enterprise,
you win by making the best bottom line consistently. You achieve the
best bottom line through good communication and technical excellence.
Ruby and Rails have a very good foundation, but they need a little more
maturity to enter that market and win decisively. J2EE has essentially
failed, client/server technologies are largely a fad of the past, and
people are unwilling to go back to CICS screens. The spot for Ruby and
Rails is open if the platform can provide the technical underpinnings to
make it work.
Yes… This and other things other people areare saying here are
things I agree with. I personally will not use ruby for enterprise
setup any day soon.
But don’t compare bugs and little problems with what McGovern is
saying. He calls Ruby a trainwreck waiting to happen.
–
I just did it with one of these:
server_date = `curl -I #{um.htmlurl} 2> /dev/null`
print server_date.match(/^Date:.*/), "\n"
which appears to work…
Tony
Anything can be a trainwreck with a sufficiently-ignorant person at the
wheel.
“When I die, I want to go quietly in my sleep, like my grandfather,
not screaming in terror like his passengers”
Dave M.