Rails May Not Suck 160
KDan writes "With astonishing regularity, articles or posts come out claiming that the popular Ruby on Rails framework sucks in some way or another. People complain that Rails isn't as easy to deploy as PHP, that Rails just didn't do it for project XYZ. They range from the articulate and well thought out to the frankly inane and stupid (and wrong). Recently, there's also of course been the spectacular nuclear rant by Zed Shaw, which was more a rant against random elements of the community than against Rails, but was still presented as a rant against Rails.
Here's an article that tries to put some perspective on why these opinions are irrelevant to whether or not Rails sucks."
Re:Too Generic (Score:4, Interesting)
Re:Ruby (Score:3, Interesting)
Part of it may be Ruby's heavy reliance on higher-order functions. For a programmer with established habits it can be a problem in terms of the way you're accustomed to thinking about code. Imagine if Perl had special syntax for passing anonymous subs as arguments, and idiomatic Perl code used them for everything all the way down to most looping constructs...
Do you think that's the issue, or something else?
Like I always say (Score:5, Interesting)
Of course, hating a system doesn't mean you know it. You can hate a system in a completely uninformed way.
Now back when I got involved with computers, in the 70s, it wasn't like this. We didn't have frameworks, we had libraries. Either a library met you needs and you used it, blessing its authors, or it didn't and you didn't use it. Of course people didn't expect much from applications back then, either. Programs by in large just started up, did something useful, then went away. There was a whole "software tools" philosophy built around this very idea: write programs that do one thing (usually some kind of filtering task), then go away.
By contrast all but the meanest programs today look like operating systems. They're supposed to run forever an take god knows what input from god knows where and do precisely what the designer wanted them to do, plus whatever he would have wanted them to do if he had had the foresight, but nothing else.
And you've got to choose a framework. It's not just diving into a program and deciding you need something that's in a library somewhere. It's not just choosing a framework before you really know what your application has to do. You've got to choose the framework before you interview for the job. So really, life as a programmer involves relatively less solving of real problems and relatively more finding ways to hammer square pegs into round holes.
It's not that writing software is any less fun than they were back in the day. It's that on top of being fun its goddamned annoying.
Re:This just seems like nonsense. (Score:3, Interesting)
Re:still waiting to use it... (Score:3, Interesting)
It seems that RoR makes heavy reliance on this relationship, which is where it gets it power, has a literalism that disallows abstraction to easily take place. I might be able to abstract the data well enough that it doesn't matter how its held in the SQL DB in a different language/framework/library. However, I'm going to assume that RoR isn't meant for that type of coding.
I've just started to read up on Cocoa's Core Data, which has some similarities. Though it has a GUI in order to map the relationships. There's definitely power in relationship mapping for data. Going back to abstractions, it would be interesting to see a more general approach taken with Ruby that would do more than just SQL databases (unless it does, and I'm just missing something).
Speed and Protection (Score:4, Interesting)
1. Protect the code. I need to be able to deploy it without the code being easily copied and reviewed. I know, I've seen it all on this topic: I don't really need to protect it, whatever I'm doing isn't that hard to figure out, etc. Trust me, I really need to protect the code. I write products for a living, and my customers will unfairly pirate/sell/give my code away, and it will cut into my income if I can't keep control of who gets my code. This is why I'm using C# and Mono. And yes, I realize that can easily be decompiled. But it's still more than adequate protection in my business space.
2. Make it faster. Ruby is too slow for what I need to do. My customers can only afford around $100 USD/mo for hosting my special purpose application, and for the number of people they get hitting the site, Ruby doesn't cut it. I know, I know, do more caching do more magic, get more computers, build a server farm, etc. Whatever. I just rewrote the thing in C# and I could support way more users per $100 of server. It made me cry to have to do it.
Please, if there's ways to do better on those 2 areas, let me know! But trust me, I really do need to protect the code.
I'm thinking I might be able to solve both of these problems using JRuby some day, but I'm not sure yet.
Re:This just seems like nonsense. (Score:3, Interesting)
Ruby vs Python (Score:2, Interesting)
While Ruby has one advantage or two over Python, such as multi-expression lambdas and Python's statements turned to expressions (statements are a common root of evil and an unnecessary procedural concept), the main problems I see in Ruby as a language, leaving libraries aside, are that it has several different implementations of the same concept of function - blocks, procs and methods, having mediocre first-class function support due to keeping that silly value vs. function value behaviour inherited from the equivalent Common Lisp misfeature, completely misunderstanding properties (partly as a result of the former: a method should really be just a property which happens to be a function, or an object that can be used with the (...) operator), and having unnecessary complexity and irregularity in the syntax which is good for nothing and bad for everything. I suppose people who enjoy Perl may enjoy Ruby in the sense that it feels like you're writing some kind of "seekret haxxor code", but all you're really doing is spend about the same time writing a much less readable and maintainable program that looks like ass.
I'd like to post quote from the first words of R6RS, the Scheme standard, which I consider to be the ultimate design criteria, not only for programming languages, but for software in general, and perhaps things beyond software:
"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
Re:This just seems like nonsense. (Score:2, Interesting)
Quite. Apart from the lack of Java in the hosting space, let's be honest, the whole Apache->Tomcat connector story has been a sorry one indeed. mod_jk, mod_jk2 etc has been a real mess over the years.
Where does this stem from? I think it is a case of the wrong tool for the job again in a way, this time by Sun.
Originally Oak (Java) was designed to run on set-top boxes, where it made sense to have a long-running virtual machine. The web took off just as Java 1.0.2 was launched with a whole 6 packages. Not long after, Apache was the prevalent web server, and worked well for static content. Dynamic content was served by CGI, and that didn't work too well because every request required launching a separate process.
So PHP comes along and quite nicely solves this problem by running in an Apache module, with the requests handled in forked Apache child processes (pre-fork MPM).
This model doesn't fit with the virtual machine architecture of Java - you can't have multiple copies of the VM in each of Apache's children. So we end up with the mod_jk architecture.
I used to think that the PHP MPM Apache children approach was a bad thing, compared to the ability to create threads, caches of shared data, database connection pools etc in Java. But the PHP shared-nothing architecture has definite benefits.
For one thing, it gives you isolation. If one child fails, other children are unaffected. In my experience, the PHP architecture is more robust, for example, in the case of recovery from database failure. I've seen Java web apps where if the database is restarted, invalid connections stay in the connection pool and you have to restart Tomcat.
Also, horizontal scalability is so much easier. Java has solutions to this, but it's a bit of a mess in some ways. Of course I don't think PHP is a better *language*, but the reason HTTP itself has been successful is because of its statelessness. The PHP shared-nothing architecture respects that, Java goes against it.
That, in my opinion, is why PHP rules the roost on the public internet.
Re:This just seems like nonsense. (Score:2, Interesting)
VS.PHP IDE [jcxsoftware.com]
I'm pretty happy with it although I'm a