Comment by dasil003 | Hacker News Reader

Comment by dasil003 | Hacker News Reader

Parent Full thread

I sort of agree, but you're coming off a little over-excited there, and I say that as a 5-year Rails developer.

The thing about Rails is that it represents the maturation of web development. It's not anything amazing per se, just a clever roll up of the best practices that emerged from the decade of Perl, Java, PHP development that preceded it. Ruby is the secret sauce that makes things just feel so slick.

I don't mean to minimize the initial innovation, it's just that Rails is no longer very unique. A lot of frameworks have largely caught up even if written in less flexible languages, and long term I see opportunities for new frameworks to leapfrog Rails.

The biggest liability for Rails is the Ruby runtime. Yes progress is being made here, but it's still a pretty sad state of affairs with regards to memory leaks and performance. I bang my head up against this every few months and it really hurts.

Another issue is the need to handle more complex applications. Frameworks like Seaside allow you to set up complex stateful apps in a more robust way than will probably ever be technically possible in Rails (again due to limitations with Continuations in the Ruby runtime).

A related issue is the question of what dark places we will end up in over a couple decades of large code bases running under Ruby with no warnings. I think it's pretty clear by now that Java is an unnecessary straitjacket, but do-whatever-the-fuck-you-want-with-no-warnings-whatsoever Ruby environment is not necessarily the most conducive to long term stability. I'll take it over Java any day, but I still have my doubts.

Finally, there is the issue of increased ajax-ification of apps. Rails was a leader here early on insomuch as it provided proof of concept that Ajax could be done easily without a cross-browser-DHTML-guru certification, but 5 years later the Prototype + Rails helpers paradigm is quite dated. Ajax has huge potential for simplifying back-end code and making web apps inherently more scalable and performant. This is one area where Rails could re-invent itself, but a mature framework like Rails is going to have a disadvantage against a fresh approach starting from first principles.

In short, I think the competition has openings.

I love Rails to death and do Big Freaking Enterprise Web App Development in Java all day.

A lot of what people identify as pathological is an evolutionary advantage in BFEWAD. Straight-jacketing the programmer is often a good thing because on a team of 100 programmers in three continents (you might think I exaggerate), including (by my last count) 12 programmers who have less than 3 months of professional experience, we want to make sure the damage done by the least skilled programmer on his worst day is strictly contained.

I don't know if Rails scales to that sort of development, to be honest. The least skilled developer, touching one part of one class at the periphery of the project, is essentially one line of code away from blowing up the entire project.

I should know: since I'm the sole Rails programmer at my business, I am by definition the least skilled programmer. And since I've managed to corrupt the results of my analytics code by making a one-line ill-considered addition to my printing code (which are kept in wildly divergent classes in different packages and namespaced from each other), just because it was not obvious I was altering the global state of the interpreter. That sort of bug has never happened to me in Java.

A lot of techniques which are considered kosher in the Rails community don't scale to large distributed teams really well. Monkey patching is the obvious example -- if you have two developers who have different understandings of what Array#pack is supposed to do, you're going to run into HELLACIOUS, difficult to debug bugs. If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.

But who would ever monkeypatch Array#pack?

I think you're generally pretty safe as long as you stay away from the core library methods. It's the attempts to transparently extend well-known methods that I think tend to blow up on people.

a) I don't trust the least-skilled programmer in my company to tie his own shoelaces without supervision, as he might accidentally hang someone.

b) You will eventually generate a namespace collision based on the birthday paradox alone, no matter whether programmers avoid the core methods or not, if they are working in the same classes. The Ruby community encourages people to have fun with String, Number, etc because it results in easy to write DSLs.

c) array = []

array.methods.size => 127

require 'activesupport' => true

array.methods.size => 185

Those added methods include, among others: sum, to, split, blank?, rand, load, to_xml, to_json... and numerous other things some intrepid developer might decide their own arrays could benefit from.

Edit: The code sample didn't demonstrate what I wanted it to demonstrate, so I changed it to one that did, although it demonstrated something related anyhow.

Yeah ok, you win.

Actively encourage? There are only a handful of libraries that actively monkey patch the core classes. ActiveSupport, RubyGems, extlib, and uhm.... I don't know anything else. If anything most of the Ruby blog posts on monkey patching always warn programmers that it should be done with care.

If you're so afraid of incompetent developers money patching things so that they break, why aren't you afraid that they write Java* code that spawns 2 million threads, crashing the system? Or code that deletes the hard drive? There are plenty of easy ways to break a program besides monkey patching.

* With "Java" I mean whatever your favorite language is that you think will prevent incompetent developers from doing stupid things.

If you aren't patching something, don't use monkey patching. It's a band-aid fix: eventually your code gets better and you get rid of it.

And code that modifies core classes, like your Array#pack example, is almost always bad code. It doesn't matter if you're working alone or with 100 people.

I worked with this dude who would make changes to the CakePHP API without telling anyone and then I'd spend like a day trying to figure out why the documentation didn't match up. I tried to get him to at least make a prominent declaration and documentation every time he made a change that broke the API, but he didn't listen to me.

Shortly thereafter, they terminated my contract because my work was not "up to their standards". :C

To protect yourself from damage and code corruption, use source control and tests in combination with code reviews and coding standards. Don't use a straightjacket for a language.

The Rails community with all its various gem and plugin authors is a large distributed team of programmers. We already work on that scale.

Sorry... BFEWAD?

Big Freaking Enterprise Web App Development, of course :-)

Of course! I was able to work out the WAD part.. but what I know as BFE didn't make any sense.

Thanks.

And, rereading, he either edited his message or I have really poor reading comprehension.

I don't know if Rails scales to that sort of development, to be honest

Waaay off topic, but i wouldn't use the expression "scales to." Asking how to scale Rails up to 100 programmers is asking the wrong question. Asking how to maintain the same application with just one team on one continent is the question and Rails might be the answer. Then again, it might not be the answer for your specific company. But that is the question to ask.

If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.

Again, you have my sympathies. But Rails is not the answer to this problem and neither is Java. One answer to that question that has worked for others in this situation could be continuous integration. Why didn't your automated tests fail when the dev in Seoul checked his code in?

I am not saying Rails is for you, or for anyone with 100 devs on multiple continents. But I do have a little experience with multiple developers on separate continents building C++ and Java applications, and the problem of stopping developers from breaking code was always solved with processes like continuous integration and code reviews and not because of some special property of Java.

I like Rails for certain things and not for others. I am not arguing you should use it. But I do feel that the issues you raise are not Java vs. Rails issues but process issues. Java won't solve them for you and neither will Rails.

"Asking how to scale Rails up to 100 programmers is asking the wrong question"

Just imagine what we could do with a Beowulf cluster of 100 Rails programmers!

In Soviet Russia, Slashdot flashbacks to you!

Now that I re-read what I wrote, it sounds like I am giving a wholesale green flag to Rails. Not so, I also dislike modifying or even extending core classes. It's something I don't like to do at all even on solo work, and the Birthday Paradox you mention has already bitten a friend of mine:

http://github.com/raganwald/homoiconic/blob/master/2009-04-0...

So while I was ranting a bit about the process vs. tools issue, I fundamentally agree with your concerns that programming Ruby in the style of Rails has issues.

"we want to make sure the damage done by the least skilled programmer on his worst day is strictly contained"

I strongly suggest this kind of risk to be dealt with at the human resources department.

Last time I had to deal with something like this, I suggested firing the HR person who interviewed the then candidate and who did nothing to stop what should have been pretty obvious even to someone without any tech background.

The saddest fact in BFEWAD is that, at the same time Java makes it safe to use 100s of programmers in several continents, you won't need a 100s developers in several continents if you use something less primitive.

As for the monkey patch, there is another technique that prevents it from ruining your week: all automated API tests must pass _before_ the kid in Seoul commits a file.

OTOH, I find Ruby's syntax a bit too flexible and that makes it difficult for me to parse someone else's code unless I know that person very well. When comparing Rails and Django, I prefer the latter. It's just that I can wrap my head around it more easily.

> I strongly suggest this kind of risk to be dealt with at the human resources department.

Assuming that the only problem is that they are inexperienced...

On a team of that size, you're not only doing development, you are (or should be) grooming future senior devs. In the enterprise world, on timelines that run 5-10 years, with groups 100+ in number, you have an entire ecosystem to manage.

Also, in groups of that size, you're going to make mistakes in hiring. I've seen the same thing on small teams, where the whole team interviews someone who ends up sucking. With a 95% success rate, with 100 people, you're still talking five screwups.

Breaking things into smaller teams doesn't necessarily get you what you want, either. You end up with a bunch more management, turf wars, and a bunch of other hard-to-deal with crap.

Basically, at the really large scale, it is less about the code, and a lot more about managing people over a long timeline.

One of the key arguments in this thread is that, perhaps, you won't need 100+ developers unless the technology you are using requires 100+ developers to meet your deadlines.

I have been using non-C++-ish languages for about two-and-half decades now and I never met a BFEA that demanded such a huge team. In fact, I regard huge projects like this as very risky and always advise smaller projects that can bring more to the bottom line and that can be implemented in steps.

What the hell are you doing that needs such a huge team?

Why would they all be working on the same thing? If you've got 20K+ employees, 100+ developers isn't all that many. Hundreds of departments across dozens of businesses leads to a few dozen projects going on at once. Add in the maintenance of apps that are often 5-10 years old taking up a large chunk of those resources, and 100 developers isn't really all that many.

BFEA-wise, the technical challenges revolve around the intersections between the various projects - message queues, batch servers, databases, storage (and more storage). Proponents of independent teams tend to dismiss these challenges, resulting in an overall environment that is more expensive to implement and manage. (for example, sure, that obscure OSS project may be _perfect_ for the task, until the one guy that knows it leaves, and you have to pay someone top-dollar to ramp up on it)

To be fair, there's usually a lot of room for improvement, efficiency-wise. To continue to be fair, I don't know that the success rate of small dev shops is any better or worse than the large: there are more failures than successes, and many more "good enough" situations.

Just to make my last paragraph a little clearer, I find that, while Java's prolixity hides (buries in mountains of syntax) the intent of the programmer, Ruby's flexibility hides a significantly useful amount of implementation information in order to make intent more obvious.

A certain balance is required between exposing intention and implementation information for one to easily grasp what is going on and how can one interfere with it.

Just wanted to say:

If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.

Code reviews are absolutely required with any dynamic language. It's a good practice anyway, to keep everyone on the same page.

i'd also wonder why a unit test didn't catch this. In my experience if you catch a bug close to the time of it's introduction, it's easy to debug.

Agreed. In fact, I'd say that doing code reviews would not only catch this problem but also the fact that the test for it is missing.

Where by absolutely required you mean pretty useful.

I hope I don't sound too argumentative but, no, I mean absolutely required. I review my own code (and not just casually, either) a few days later and where I work we all read every commit.

It's so "absolutely required" that most of the most popular web applications, all written in dynamic languages, are not the product of reviewed codebases.

You don't sound argumentative. You sound hyperbolic.

I don't think we're on the same page about what 'code review' is. I'm only talking about having your co-workers/peers look at your code and keep up to speed on what's happening to the code base you're all working on.

Do you have a citation for 'most' of the popular web applications not being code reviewed? Have the developers at, say, twitter said they ignore commits and code written by co-workers?

The Rails Javascript helpers are a huge blind alley, and something that should have been jettisoned a while ago --- as is RJS.

I got addicted to Sinatra because it pretty much begged me to try Haml + jQ --- which is an amazing combination --- and we recently ported all our Erb's to Haml in our Rails app as well.

I think it's a major design mistake to hide or abstract Javascript now that jQuery has pretty much won the JS framework war.

I also stopped using RJS once I switched to JQuery. I however haven't moved to HAML just yet. Something makes me nervous about not working with raw HTML (especially with all the non-rails front-end development work I do). Why is HAML + JQ an amazing combination and am I really missing out on something here?

they have a very similar syntax, and haml reduces line noise of plain html.

Because most of the day-to-day things you do in jQuery involve doing something special with an element by id or class, and Haml's syntax for special classes and id's is painless. For instance:

  %a.post_link.confirm_link.destructive_link{link_to(@x)}  
    Hi mom

I'm probably not selling it very well. But basically, you know the old DOM tutorials that talk about how you can do you own tags like:

  <box name="foo">
    <item number="1" />
    <item number="2" />
  </box>

and then convert it to

  <div class="box" id="foo">
    <div clas="item" id="item_1" />
    <div clas="item" id="item_2" />
  </div>

or whatever; in Haml, that's just:

  .box#foo
    .item#item_1
    .item#item_2

In some ways I can really see the readability gains - haml is very succinct and neat. But there's a cost involved, namely getting my eyes and brain to comfortably recognize new syntax and patterns, something that for me usually takes a long time.

I also worry about creating something in HAML and having people not familiar with it not be able to dive into the project and start working right away. I'm actually on the other side of that scenario right now and it's a pain.

But I do have to admit, it's a very pleasing syntax.

It's not even readability that makes it a win; it's that the combination of jQ and Haml is like working in a markup language that has native support for every widget or UI flourish you could want.

Very intriguing. Hmm.

Reply on news.ycombinator.com