"Java facing pressures from dynamic languages"

[vgarcia]

Also doing the transformation in a programming language destroys many benefits of MVC, that is you have to have a programmer work on "view code", where as must html/css guys can figure out xslt. But....again more anti-xslt junk.

I don't think you give "most html/css guys" enough credit. This:

<h1><%=@page_title%></h1>

Is just as easy to figure out as this:

<xsl:template match="page-title">
<h1><xsl:value-of select="."/></h1>
</xsl:template>

[The New Guy]

I don't think you give "most html/css guys" enough credit. This:

<h1><%=@page_title%></h1>

Is just as easy to figure out as this:

 <xsl:template match="page-title">
 <h1><xsl:value-of select="."/></h1>
 </xsl:template>

And if its not. The solution isnt to use XML. It should be using an application with a simple GUI. Some kind of WYSIWYG app which would just spit out template code. They would never have to see the code. This is samething voostind came to the conclusion to 3 years ago.

[Stevenwulf]

@snaily

<snip>
The point, was that generics have made java less dynamic <b>in the sense that there is now more type checking.</b>
</snip>

ArrayList<Object> list = new ArrayList<Object>();
Well, if the above does not involve any additional type checking then I stand corrected.

[Snaily]

I don't think you give "most html/css guys" enough credit

I don't even know what to say to this..did you read what was posted? How does the variable you are referencing magically get set...the discussion was assuming the data was in xml. If you are dealing with a situation where you can easily extract a few variables from the xml and then set them to a template...then you most likely don't need the xml in the first place. This strategy would not work at all for a complex mark-up.

Anyhow, its odd that xslt is treated as blasphemy in this thread...I suppose that is what happens when people religiously adhere to certain technologies. But the fact remains xml and xslt are wildly useful in many cases (including usages outside of web services).

[Majglow]

But regardless, the templating engine that rails uses can be easily changed.

It seems to me that "enterprise" is quite a useless and meaningless term. People should be focusing on solving the problem at hand. Nothing can solve every problem out there. The real trick is figuring out what the best solution to the problem might be.

As for scalability, it doesn't seem like too much of a problem... just throw more machines at it.

[Snaily]

As for scalability, it doesn't seem like too much of a problem... just throw more machines at it.

Scalability should also refer to the scalability issues that go along with development...that is how well does rails fair when you have 10+ developers working on something, when the code base is huge etc. I'm not trying to say rails doesn't scale in this sense...I have no idea.

Out of curiousity does anybody know how rails does on performance....I can't imagine it performing that well but I've never bothered to benchmark it against something else.

[vgarcia]

Anyhow, its odd that xslt is treated as blasphemy in this thread...I suppose that is what happens when people religiously adhere to certain technologies. But the fact remains xml and xslt are wildly useful in many cases (including usages outside of web services).

I use XSLT every day at work, in addition to Java. I also know where both technologies have proven to be less than optimal in my past projects. There are lots of cool things you can do with XML and XSLT, but in lots of other cases all it does is introduce complexity where it's not needed.

[jobr700]

Here is a little quote from Tim Bray about dynamic languages:

I tend not to be religious about technology; I’ve been wrong enough times to be unsurprised when I run into a good argument pointing a direction I wasn’t thinking of going. But sometimes I’m sure of something, and right now I’m 100% take-it-to-the-bank bet-my-career sure of this: dynamic languages (what we used to call “scripting languages”) are already playing a large role in Enterprise Software Development; and their role is going to be growing in size, at least for the next little while

Read all of it on
http://www.tbray.org/ongoing/When/20.../05/03/Pedroni

He is talking about Jython and Python, but the logic (in the first part at least) works for Ruby as well.

Note that it is an old article and that the role of dynamic languages probably has grown since then, even if I think it could grow much more.

[jobr700]

Scalability should also refer to the scalability issues that go along with development...that is how well does rails fair when you have 10+ developers working on something, when the code base is huge etc. I'm not trying to say rails doesn't scale in this sense...I have no idea.

One thing to note is that most people working with Rails and Ruby says that the devleopers are much more productive. This means that 5 developers might be doing the same work that takes 10 or 15 developers using Java. That should be worth something even from a business standpoint. And I know this is a little hard to proof, but not impossible. If you work with the technology for a while you should be able to get metrics that you can compare with metrics for similar projects using other technologies.

About the scalability I don't think it is a huge problem. If you use testing and version control you can have a lot of developers working on a project without disturbing each other too much. Please don't tell me you are working on large enterprise system projects without version control and tests.

Unfortunately I haven't been involved in any large project using Ruby yet, I can only say that it worked very well for me in a smaller project. And I didn't even use rails, just Ruby (it was a server side script with no web interface).

I haven't done much Java work the last years either, but I am working with .NET which people seems to think is enterprise ready. One thing I note is that in our web projects we tend to write more and more components that gets called from xml code (that is .aspx pages, where you normally calls controls in ASP.NET). We generally strive to get to the point where we can do quick changes in the xml-code for almost all common changes in the main logic or presentation. The reason for this is that changes in the the xml-code is much quicker to do, probably because they are not compiled (or only JIT-compiled). Java seems to be moving into tag libraries which work in a similar way. This means that (web-) developers prefer not having to compile things all the time and that it is good to resuse components. With scripting languages you have the same short turn-around time since they don't compile and any good language lets you create components that can be reused. This goes for both Ruby, PHP (5) and Python.

[Majglow]

Scalability should also refer to the scalability issues that go along with development...that is how well does rails fair when you have 10+ developers working on something, when the code base is huge etc. I'm not trying to say rails doesn't scale in this sense...I have no idea.

Out of curiousity does anybody know how rails does on performance....I can't imagine it performing that well but I've never bothered to benchmark it against something else.

As for scalability with developers, I think that for most languages / frameworks it really comes down to how good the system architect is at designing the structure of the project as well as how good the communication is between the developers.

As for performance, I do expect the execution of the ruby code to be slower than other languages (for now). However, most of the time isn't the main bottleneck the database queries? This part of the application as a whole really comes down to how well your database is designed and how well the code was designed to query it.

If for some reason there is any real logic bottleneck in the code, further optimization of the ruby code isn't possible, and for some reason adding another server isn't a possibility, then that bit of logic can be extracted to a C extension.

[Mazr]

As for performance, I do expect the execution of the ruby code to be slower than other languages (for now).

I've seen some annecdotal evidence that RoR is slower but since there are no high traffic sites, you really need to do your own benchmarking (which you should be doing anyway). The good thing is that RoR is renewing interest in FastCGI which helps all scripting languages. Is mod_ruby still too buggy to be used in production?

However, most of the time isn't the main bottleneck the database queries? This part of the application as a whole really comes down to how well your database is designed and how well the code was designed to query it.

You're right, DB access and the ORM are often the bottleneck. Raw SQL is slow enough but ORMs can be several times slower. If you have an ORM generating your queries it comes down to how good your ORM is. For RoR, that basically comes down to how good ActiveRecord is.

From what I've seen, ActiveRecord may be the Achilles heel of RoR since it basically treats databases like flat files. It purposely ignores foreign keys and dumbs down your database to the lowest common denominator. Check out this The Joel on Software Discussion Group article response:

After using Rails for 1+ year, I've got some concerns too. I love Ruby (although even it could be improved). And I've got to say, Rails really makes me productive. But it could be so much better.
[...]
2) ActiveRecord is just OK. I know I could replace it with something else; I just haven't gotten around to it. The FK issue is a pain. Worse is the abysmal handling of many-to-many relationships, especially when these tables have their own attributes. It's really difficult to update these tables.

How about tables with primary keys that are not auto-increment integers? DHH hates these, so he hasn't implemented them in Rails. So you have to hack your way around them. And God forbid you should have a M-to-M join table where one of the PKs is a character field - yikes!

And in general, God forbid you should have to work with a pre-existing database schema.

3) DHH is sometimes Rails' worst enemy. OK, he's built some good software, and he's obviously got a knack for publicity. But could he be any more arrogant? Jeez, his response to everything is 'That's a terrible idea. My way is the right way. No logic in the database! You shouldn't do it that way, so Rails doesn't.' I guess he's entitled to his opinions, but come on. Who wants to use software led by a guy like that? Plus I get the feeling he just doesn't have a lot of experience in the *real world*. His opinions are sometimes, shall we say, not well informed.

Here's some more discussion:

From what I understand, each join creates 2 additional queries to the DB which then have to be mapped to objects. In my test app, I had a join across 8 tables (common for my apps with database normalisation techniques). MySQL ran the join and returned a resultset of 5000 records in a little of 20ms. PHP managed to churn this out to the screen in a little under a second with formatting. RoR... well... I gave up.

I know there are other ORMs for RoR but are any of them popular and with the features that ActiveRecord chooses not to have?

You could say "just fall back to raw SQL" except you shouldn't have to for these features. There are ORMs for other languages / frameworks that do support these features. It's not like ActiveRecord can't, it's purposely designed not to.

[bonefry]

What does "enterprise-ready" mean?

Please, please don't go there.

The "Enterprise" label, although blurred in time by all corporate talk and bullsh*t that does nothing else but justify spendings, is actually easy and straightforward to define. But you'd better start searching for answers somewhere else.

Also, I will shoot anyone on sight that asks ... "What's a scripting language anyway ?"

It seems to me that "enterprise" is quite a useless and meaningless term. People should be focusing on solving the problem at hand.

I knew you would eventually get here, and it's a short-sighted statement.

Anyway, just some hints ... can you rely on Ruby & Rails for distributed applications (that comunicate with legacy software, of course) and does Ruby & Rails have any kind of transaction support or messaging API ?


Rails is a great framework. It won't become mainstream, but that's not such a bad thing as popularity attracts dumb programmers that always want something.

[Majglow]

From what I've seen, ActiveRecord may be the Achilles heel of RoR since it basically treats databases like flat files. It purposely ignores foreign keys and dumbs down your database to the lowest common denominator. Check out this The Joel on Software Discussion Group article response:Here's some more discussion:I know there are other ORMs for RoR but are any of them popular and with the features that ActiveRecord chooses not to have?

You could say "just fall back to raw SQL" except you shouldn't have to for these features. There are ORMs for other languages / frameworks that do support these features. It's not like ActiveRecord can't, it's purposely designed not to.

This is scary news for me....

what do you mean that ActiveRecord is designed not to?

[Luke Redpath]

You hit the nail on the head. RoR is getting a lot of fame for building toy applications. How well it can be used for real apps is where a lot of complaints appear.

A lot of those complaints seem to come from people who aren't actually spending enough time with Rails and using it day in day out.

People are building real apps with Rails and having a lot of success doing so.

[Luke Redpath]

From what I've seen, ActiveRecord may be the Achilles heel of RoR since it basically treats databases like flat files. It purposely ignores foreign keys and dumbs down your database to the lowest common denominator. Check out this The Joel on Software Discussion Group article response:Here's some more discussion:I know there are other ORMs for RoR but are any of them popular and with the features that ActiveRecord chooses not to have?

You could say "just fall back to raw SQL" except you shouldn't have to for these features. There are ORMs for other languages / frameworks that do support these features. It's not like ActiveRecord can't, it's purposely designed not to.

It may be worth looking at some of ActiveRecord's newer features - theres some cool stuff in there such as proper join models that address some of those concerns.

[Majglow]

It may be worth looking at some of ActiveRecord's newer features - theres some cool stuff in there such as proper join models that address some of those concerns.

I just got Rails 1.1 on my personal system and am going to play around with it some.

[Mazr]

what do you mean that ActiveRecord is designed not to?

DHH is a very opinionated person. Things that he doesn't agree with don't get implemented and he goes out of his way to tell people why they are wrong on his LoudThinking blog. That's not a problem unless he doesn't agree with something you (and often many others) need. Sure, there's some cool stuff in AR but I think it's unfortunate that some of the rejected features are very basic (and should be baseline ORM features IMO).

It may be worth looking at some of ActiveRecord's newer features - theres some cool stuff in there such as proper join models that address some of those concerns.

Can you be more specific on which of the concerns listed by Kian are addressed? Foreign keys, many-to-many relationships, non-auto-increment primary keys, character-based primary keys, existing schemas? Does the new join model solve the 2 extra queries per join issue?

Also, does the current version of ActiveRecord support multi-column character-based primary keys? This is an absolute requirement for me. It didn't as of a year ago according to DHH:

> Is there a way to set an ActiveRecord object to point to a table
> with a multi-column primary key?

Not really, no. Active Record was designed for a single column
primary key and that assumption runs pretty deep. AR is not a Data
Mapper, so you have to be within a reasonable vicinity of its
assumptions to enjoy it.

Only handling single column primary keys seems to be bad assumption and a design flaw to me. Other ORMs can certainly handle multi-column primary keys. It seems wrong to have to design the schema around the ORM's limitations.

[Majglow]

Can you be more specific on which of the concerns listed by Kian are addressed? Foreign keys, many-to-many relationships, non-auto-increment primary keys, character-based primary keys, existing schemas? Does the new join model solve the 2 extra queries per join issue?

- Foreign keys aren't "solved" as in rails still makes you add the lines "has_many", "belongs_to" etc... but I believe that you can always add Foreign keys and constraints to your database schema anyway.

- I'm not up to speed on the many-to-many concern

- You can deal with non-auto-increment primary keys by using before_validate_on_create

- Character-based primary keys... i don't know yet.

- Existing schemas can be used by rails (It seems that there are some limitations to this though, such as, at the moment I believe there is no support for multi-column primary keys

- I also believe the new join model solves the multiple queries per joins, but I am testing that now.

[Majglow]

My quick schema:

  create_table "authors", :force => true do |t|
    t.column "my_parent_id", :integer
    t.column "text", :string
  end

  create_table "groups", :force => true do |t|
    t.column "my_parent_id", :integer
    t.column "text", :string
  end

  create_table "my_parents", :force => true do |t|
    t.column "text", :string
  end

  create_table "orders", :force => true do |t|
    t.column "my_parent_id", :integer
    t.column "text", :string
  end

  create_table "users", :force => true do |t|
    t.column "my_parent_id", :integer
    t.column "text", :string
  end

@parent = MyParent::find(6)

Generates the following:

Processing TestController#index (for 127.0.0.1 at 2006-04-12 12:44:03) [GET]
  Session ID: 9a3f41b5f8020da4dfe82c68e5489cf8
  Parameters: {"action"=>"index", "controller"=>"test"}
  MyParent Load (0.003991)   SELECT * FROM my_parents WHERE (my_parents.id = 6) LIMIT 1
Rendering  within layouts/application
Rendering test/index
  Author Load (0.187731)   SELECT * FROM authors WHERE (authors.my_parent_id = 6) 
  Group Load (0.002873)   SELECT * FROM groups WHERE (groups.my_parent_id = 6) 
  Order Load (0.003503)   SELECT * FROM orders WHERE (orders.my_parent_id = 6) 
  User Load (0.003082)   SELECT * FROM users WHERE (users.my_parent_id = 6) 

Whereas this:

@parent = MyParent::find(6, :include => [:authors, :users, :orders, :groups])

Generates one DB call:

[4;36;1mMyParent Load Including Associations (0.056154)   SELECT my_parents."id" AS t0_r0, my_parents."text" AS t0_r1, authors."id" AS t1_r0, authors."my_parent_id" AS t1_r1, authors."text" AS t1_r2, users."id" AS t2_r0, users."my_parent_id" AS t2_r1, users."text" AS t2_r2, orders."id" AS t3_r0, orders."my_parent_id" AS t3_r1, orders."text" AS t3_r2, groups."id" AS t4_r0, groups."my_parent_id" AS t4_r1, groups."text" AS t4_r2 FROM my_parents LEFT OUTER JOIN authors ON authors.my_parent_id = my_parents.id LEFT OUTER JOIN users ON users.my_parent_id = my_parents.id LEFT OUTER JOIN orders ON orders.my_parent_id = my_parents.id LEFT OUTER JOIN groups ON groups.my_parent_id = my_parents.id WHERE (my_parents.id = 6) 

Note, I removed all development server related queries from the log output.

[Mazr]

Another issue that may be important to some is that Ruby and Rails don't seem to handle unicode well. This is another show stopper for me. See below which says "Rails basically knows nothing about Unicode" and talks about some hacks.

http://wiki.rubyonrails.org/rails/pa...UnicodeStrings

Also see the following which says "By default, Ruby has no encoding or character set support in its String class. You’ll notice this when you try to slice a string on a multibyte character"

http://www.fngtps.com/2006/01/encoding-in-rails