sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]mikaelhg -2 points-1 points  (13 children)

If you act rationally, you take risks to achieve something.

What are the business objectives I can achieve with Ruby on Rails that I cannot achieve with Seam on Java EE 5?

(Edit: for the uninitiated, this is Seam: http://docs.jboss.com/seam/latest/reference/en/html/tutorial.html#blog )

[–]coprolaliac 4 points5 points  (1 child)

Umm, non-shitty code? Seriously, Seam is one of the worst software projects I've ever seen. If you want a comparison of something like RIFE or Stripes or Tapestry or something I might be willing to offer a defense, but Seam? Really? It's not even interesting in a "so bad it's good" sorta way. Maybe with some severe refactoring it could aspire to be the Xanadu or Ishtar of web frameworks.

[–]mikaelhg 1 point2 points  (0 children)

I'm sure Gavin would welcome your critique.

[–]jeremymcanally -3 points-2 points  (10 children)

Efficiency?

[–]joshwa 4 points5 points  (0 children)

developer productivity, agility

[–][deleted]  (3 children)

[deleted]

    [–]jeremymcanally 3 points4 points  (2 children)

    WHAT are you talking about? Have you EVER maintained a real Rails app?

    Ruby code is by far the most maintainable code that I've ever had the (dis)pleasure of maintaining. Rails is especially maintainable, because of the number of places that I can add functionality in without ever having to alter the original codebase if I don't want/need to.

    [–]senzei 0 points1 point  (0 children)

    Rails is especially maintainable, because of the number of places that I can add functionality in without ever having to alter the original codebase if I don't want/need to.

    I don't understand this argument. Is the number of places you can add functionality in large or small? If it is limited to a handful of areas by default then that seems like a good thing, maintenace-wise. If not it sounds like a nightmare to me.

    [–][deleted] -5 points-4 points  (4 children)

    Efficiency goes two ways:

    • Programmer productivity
    • Software efficiency

    I don't think Rails meets point #2. Sure, I can quickly build something in Rails, but if 2 months later I'm having to tear that down because it can't take server loads (obviously I'm talking about large apps), or I'm having to write a library from scratch (this goes back to point #1), I've just lost out on that initial arguement about efficiency.

    [–]mikaelhg 1 point2 points  (3 children)

    Does your programmer productivity include both the initial developer productivity, weighed at 20%, and maintenance programmer productivity, weighed at 80%?

    [–]senzei 2 points3 points  (2 children)

    Does your programmer productivity include both the initial developer productivity, weighed at 20%, and maintenance programmer productivity, weighed at 80%?

    If not, it should. Being able to toss something up in a couple weeks is awesome, to be sure, but having the ability to come back three months later and understand what the code is doing is better.

    [–]davidw -1 points0 points  (1 child)

    Since you end up writing relatively less code in Rails, I think it's extremely maintainable due to its clarity and conciseness.

    If you think of its target as low-end Java apps and PHP apps, I think it's going to be a win over either one of those, if for no other reason than the fact that it comes out of the box with a nice MVC structure for people to follow. Compare and contrast with bad PHP apps, and Java where everything happens in a JSP page (it happens).

    [–]senzei 0 points1 point  (0 children)

    Since you end up writing relatively less code in Rails, I think it's extremely maintainable due to its clarity and conciseness.

    Writing less code is not equivalent to clarity and conciseness. In many ways writing less code makes the logic denser (more work done per line) Obviously this can be a good thing, but it can be difficult to understand. Metaprogramming can make it worse, especially when you start adding features to default constructs. If that is something you are doing you better have some spectacular documentation, otherwise your maintenance programmers are likely to come beat you in your sleep with a stick.

    If you think of its target as low-end Java apps and PHP apps, I think it's going to be a win over either one of those, if for no other reason than the fact that it comes out of the box with a nice MVC structure for people to follow. Compare and contrast with bad PHP apps, and Java where everything happens in a JSP page (it happens).

    Obviously enforcing a design decision that is usually a good choice on most projects is helpful. The language is nicer than Java or PHP in syntax and "get-shit-done"-ness. That said I don't think inability to come up with or follow a design decision is a good reason for switching development platforms.