Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×
PHP Programming

PHP5 Vs. CakePHP Vs. RubyOnRails? 469

Posted by kdawson
from the please-choose-one dept.
OldJavaHack writes "If you could start a website (with MySQL for persistence) from scratch and you had a choice of PHP5, CakePHP, or RubyOnRails — which would you choose and why? Things to consider in your decision: 1. Maturity of solution; 2. Features; 3. Size of community of skilled users (to build a team); 4. Complexity/ease of use (for neophytes to master); 5. Greatest strength of your choice, and the greatest weaknesses of the other two. Here is a comparison of capabilities."
This discussion has been archived. No new comments can be posted.

PHP5 Vs. CakePHP Vs. RubyOnRails?

Comments Filter:
  • by Anonymous Coward on Monday September 10, 2007 @01:45AM (#20535377)
    This seems to be yet another kdawson story which exists to solely promote the "my X is better than yours" bashing, trolling and flames that always seem to follow these stories. Come on, can we get a new editor already?
  • Brrrr... (Score:2, Insightful)

    by jfclavette (961511) on Monday September 10, 2007 @01:47AM (#20535389)
    I can't comment on Ruby on Rails, but PHP (yes, even PHP5) is such an horrible language. Yes, it's widely available and is pretty much the only option out there for free/cheap hosts, but I just don't understand why someone would choose to use it in any serious project.

    JSP and ASP.Net (Yes, I know, this is Slashdot) are, IMHO, much more much more powerful and pleasant to work with. If I had to pick amongst the proposed solutions, I'd pick RoR if only for the fact that Ruby is a nice language. I don't know about Rails' features but I could at least trust the language it's built on.
  • by Anonymous Coward on Monday September 10, 2007 @01:50AM (#20535405)
    ... real journalists and good standards!

    Of course, that's just me.
  • by david_bonn (259998) * <davidbonn@@@mac...com> on Monday September 10, 2007 @01:59AM (#20535447) Homepage Journal
    Honestly, great websites and web applications have been written using all three of those products. What the best choice for your website will be depends a lot on what your website is. Each of those frameworks makes certain assumptions about how the world works, and you will be happiest with a framework that is closest to your pwn assumptions -- otherwise you'll spend as much time fighting the framework as writing your website.

    Any halfway skilled programmer will be able to do useful work with any of those frameworks fairly early on, but all of them are also very rich environments, so there's always more to learn.

    I've written web apps in an ungodly tangle of PHP4 and PHP 5 and Perl and using Ruby on Rails. Currently Ruby on Rails is in favor, but is far from perfect.

    Probably most of my frustration with Rails and PHP 5 has to do with Active Record. My big gripes are: (1) Schemas, entity-relationship diagrams, and queries tell me how an application works -- with Active Record this information is strewn across a whole bunch of files (especially in Rails); (2) Database-independence is a nice idea, but in reality, how often over the lifetime of your website will you migrate to a different database? Usually your database is chosen for you. Usually a switching databases involves coordinating with a lot of people who you'd usually rather not have to deal with -- those issues will take far more time and energy than differences between MySQL and Oracle; (3) a pretty common design pattern for web pages is to have a form that let's you fill in a few parameters (date, maybe geographical information) into a huge multi-table select statement -- you can do that in Active Record, but basically all you gain is a marginally fancier wrapper than you would have with DBI.

  • Re:Brrrr... (Score:5, Insightful)

    by Baddas (243852) on Monday September 10, 2007 @02:00AM (#20535453) Homepage
    JSP and ASP are terrible compared to rails. You really ought to pick up Agile Web Development with Ruby On Rails [amazon.com] and go through the sample project at least.

    It'll change the way you think about development for the web.

    Or, if you're really set on Java, try Rails for Java Developers [amazon.com] and you'll see how much more concise the exact same code is in Rails.
  • Re:Rails (Score:2, Insightful)

    by astrotek (132325) on Monday September 10, 2007 @02:00AM (#20535459) Homepage
    ror is good for concepts but I haven't seen any good examples of it in production.
  • Re:Sure (Score:4, Insightful)

    by Bogtha (906264) on Monday September 10, 2007 @02:02AM (#20535469)

    PHP is what kids write My First Sites with.

    Seeing as "Our team is familiar with..." plays no part in this decision whatsoever, I'd say that we are dealing with kids writing Their First Site. Or, looking at the peculiar phrasing and noting the date, kids who have just received their first homework assignment for a project that requires them to submit a plan first.

  • by corychristison (951993) on Monday September 10, 2007 @02:08AM (#20535489)
    I agree.

    Lately people (aka: script kiddies) seem to be losing the distinction between what is a language, and what is a framework. I cannot remember the last time I downloaded a PHP script and it required PEAR. I absolutely despise PEAR, and all other frameworks that really don't seem to have a place.

    Over the past 5 years or so (I develop websites for a living) I've developed a framework-style setup that I use for all new projects. Most sites don't share the same code as I develop project-specific. But the structure is the same, and in most cases I could grab a pile of files from one site and plop them in the next and it would work.

    Use the tool as it is meant to be used. PHP is a language. A framework is a framework. Please don't compare them on the same level.

  • by jaaron (551839) on Monday September 10, 2007 @02:12AM (#20535511) Homepage
    What about the requirements of the, you know, actual website application?

    You've provided no information on the actual website that you intend to develop. That's the important part -- the features and functionality to the customers and end users.

    Instead of considering the features of the language and framework first, how about the features of the application? How many users? Who will be supporting it? What kind of server resources are available? Do you need internationalization? What's the roadmap for the site over the next 3 to 5 years? Maybee then you can map the features of the website to the features of the framework or language, such as the maturity of the libraries directly related to your webapp.

    But picking the implementation language independent of the functionality of the website is a classic sign of solving the wrong problem. I don't care what you program it in, if you're asking these questions first, you are programming it in the wrong language.
  • Tapestry (Score:4, Insightful)

    by Anonymous Coward on Monday September 10, 2007 @02:15AM (#20535525)
    Or another Java framework, due to the maturity, scalability, availability of libraries, and number of people who know it.

    Rails just does not have a stable server. Webrick + fastCGI, or Mongrel, they both crash regularly for us. Also I've had to maintain several Rails apps written by others, and it sucks. All those neat tricks that makes it "productive" for the first programmer makes it difficult to understand and maintain for everyone else.
  • In other words... (Score:5, Insightful)

    by jaaron (551839) on Monday September 10, 2007 @02:21AM (#20535557) Homepage

    I've never used Ruby or RoR... my experience with PHP is limited as well...

    In other words, you were trolling. :-)

    Having done websites in PHP, Rails, Python and Java, I can say that they all suck one way or another. Ruby and Rails are both very different from PHP and my personal unconfirmed suspicion is that a lot of the Rails problems people have are from programmers who jump over into Rails without first learning what they're getting themselves into. Deploying Rails can be very difficult and you can face a lot of issues that you would never face for PHP.

    Personally, I prefer Python or Ruby over PHP any day.

  • by jalmond (1154263) on Monday September 10, 2007 @02:28AM (#20535599) Homepage

    What we have here is another usual question that all really depends on your project type. That being said, I'll try to break from the typical, slashdot format and attempt to address your question:

    1. Maturity of Solution: 1st PHP5, then Ruby, then Cake. Shouldn't be a lot of controversy here. PHP has been around since the dinosaur age, ruby came around with all that slick don't repeate yourself talk and then cake came about and tried to add ruby like framework to PHP.
    2. Features is really going to depend on what your looking for. Rails allows you to write a lot of fairly complex stuff quickly, cake arguably has better built in security, PHP5 will scale better then any of them.
    3. Everybody and their mama knows php5, any new kid thats worth a darn is probably learning rails, and then there's cake, which has nowhere near the dev support of the other two.
    4. Rails wins here if your starting from scratch, but since so many devs already have php experience, complexity becomes sort of relative.
    5. For better or worse, if you were to poll most devs that are building commercial production apps (at least out of the three options mentioned) php5 is going to win hands down. For my company it was a simple decision that hinges on two of the points: scaling and experience. We wanted something to scale to slashdot numbers, while being able to hire a bunch of kids from college to help the dev team build it all. Typical of online startups, we wanted the most bang for the bucks, and php5 was the choice.

    P.S. A similar question of Rails vs PHP vs Java question was somewhat subjectively discussed late last year http://www.cmswire.com/cms/industry-news/php-vs-ja va-vs-ruby-000887.php [cmswire.com]

  • by misleb (129952) on Monday September 10, 2007 @02:28AM (#20535609)
    Rails for Ajax stuff? There are WAY better reasons for going with Rails than to get Ajax. A proper MVC framework, for starters. Rails is really meant for building *applications,* not necessarily "sites." If you can frame your site as an application, great, but don't expect Rails to power (well) just any old site.

    And, yeah, comparing Rails to PHP5 is kinda dumb because Rails is a framework and PHP5 is a language. The problem with using "PHP5" in any non-trivial application is that you invariably end up building your own framework(s) which can be a huge time sink. Now, comparing Rails and CakePHP would make much more sense. I haven't used CakePHP, but it looks like it has all the major framework features that Rails has. Though being based on PHP is a huge handicap, IMO. PHP is just kind of a dumb language... at least compared to Ruby. Ruby is just an awesome little language. If only it were faster. :-/
  • by Bluesman (104513) on Monday September 10, 2007 @02:37AM (#20535659) Homepage
    "but in reality, how often over the lifetime of your website will you migrate to a different database?"

    If you told me I could pick either the database to use or the scripting language to code in, I'd pick Postgresql and let you pick the language. Most of the things people try to do in scripting languages can be handled in the database much more elegantly and scalably. Of course, most people don't realize this because they've only used MySQL and don't realize how much it's missing.

    If you told me I could pick both, I'd go with Perl, unless I were doing something very simple that's been done a thousand times before.

    PHP is decent enough for what it is. Historically there have been security problems with it, and the design is crappy. But it's quick and easy.

    I've never used Rails, but it sounds like it does a lot for you. In my experience, that can be a blessing if you're doing something textbook. If not, have fun fighting with the assumptions other people made.
  • Re:Brrrr... (Score:5, Insightful)

    by @madeus (24818) <slashdot_24818@mac.com> on Monday September 10, 2007 @02:50AM (#20535721)
    Compare a straightforward Java class, with try/catch (a silly example, but obviously just to provide some syntax):

    public class DoStuff {
        protected double someNumber;

        public setSomeNumber( double number ) {
            try {
                someNumber = number;
            } catch (Exception e) {
                // See e.getMessage() for error
            }
        }
    }

    ... with some PHP for the same code, which would look like this:

    public class DoStuff {
        private someNumber;

        public setSomeNumber($number) {
            try {
                $this->someNumber = $number;
            } catch (Exception $e) {
                // See $e->getMessage() for error
            }
        }
    }

    I don't see how that's wacky syntax in the slightest. Just people people use PHP like it's Perl+Mason doesn't mean you can't use PHP for serious, scaleable, enterprise software. I know from experience that people are just as likely to write nasty Perl, Ruby or ASP as they are nasty PHP.

    Personally I think Java makes it more difficult to be wacky (even though of course it can't force people to write code that's ultimately good) and that has definite benefits in an enterprise environment, but that lack of flexibility (which scripting languages like Perl and PHP have) is also why I don't tend to want to use Java.

  • by RegularFry (137639) on Monday September 10, 2007 @02:50AM (#20535727)

    Use the tool as it is meant to be used. PHP is a language. A framework is a framework. Please don't compare them on the same level.

    Except that in this case, the comparison is valid. PHP without a framework is, if you will, the null framework. Its advantages are that there is no learning curve, deployment is trivial, and there's no runtime framework overhead to heat up your CPUs. On the other hand, it doesn't help you at all in writing the app, and once your site gets beyond a certain size you'll probably end up writing a framework anyway - as it sounds like you've done, after a fashion.
  • Re:Sure (Score:4, Insightful)

    by Baddas (243852) on Monday September 10, 2007 @03:01AM (#20535779) Homepage

    You have the right idea about RoR (speaking as someone who excitedly spent /wasted/ a month learning into it). RoR has some hot ideas but it tries to be too smart and locked down for its own good.


    The beauty of Ruby is, even if you don't like it the way they do it, you can always monkey patch it. Open up the object and override the method(s) you don't like.

    Try doing that to the PHP core libs. Better know C, and love it a lot.
  • by patio11 (857072) on Monday September 10, 2007 @03:01AM (#20535785)
    ... when the complaint is similar to "PHP is a really cruddy language to write a graphics driver in". This is true -- using PHP to write a graphics driver is like attempting to change a car tire with a banana, but thats hardly a knock on PHP, its just a mostly banal comment on choosing the right tool for the job. What Rails excels in is choosing the right job for the tool -- given that you have Rails, you now know with pretty good certainty that you can bang out a CRUD site in your target vertical of choice on a very nice timescale while still being feature-rich. That is a really, really nice feature for a platform to have for small software houses.

    Granted, I wouldn't write Digg in it, but *I'll never write Digg in anything*. Neither will 99% of the world's programmers, and for the 1% that are making social networking sitse with desired user numbers the size of nation states, they have the LAMP stack and God bless them for it.

    As for me, I've got one quite profitable desktop application written in Java (folks laughed at me for that -- what can I say, it got the job done) and am having a bloody ball working on a small business vertical app which, at $15 / account / month and low predicted need for users to interact with the app, would replace my day job income at about three dynamic page hits per hour. I have this funny feeling that Rails will scale that far.
  • by MBoffin (259181) on Monday September 10, 2007 @03:01AM (#20535791) Homepage
    Sorry, can't say much more than that. If you've never used Ruby on Rails, I'm sure CakePHP would be a joy to work in. However, if you've used Ruby on Rails, then CakePHP will hurt. The Ruby language is beautifully suited to this kind of framework, and PHP is not.

    This is not to knock CakePHP. In its own right, CakePHP is an excellent framework and a lot of quality work has gone into making it what it is. It's a powerful framework.

    The move to this kind of framework can be quite a mind job, whether you're moving to Rails or CakePHP. It requires breaking down very solid foundations of ideas that you've built up over the years on how to build a web application. If PHP is your thing, then weathering that mind job will be all the more easier if you're doing it in a language already familiar to you. But if you're willing to try something new, then it's worth making the jump to Ruby on Rails.
  • Re:Brrrr... (Score:2, Insightful)

    by Anonymous Coward on Monday September 10, 2007 @03:07AM (#20535819)
    The problem with java is not the coding, it is the ridiculous amount of hassle you get in deploying multiple apps on a single server. Having to change XML config files buried in archives, ClassLoader problems because two apps need to use the same (or different versions of the same) library. Stupid hassles when versions upgrade which serve no real purpose (moving classes from java.what.ever to javax.what.ever).

    Java is great if you work on a single application with its own hosting environment, if you need multiple websites or webapps it quickly becomes a configuration nightmare. I think that is why a lot of experienced java developers seem to really like Ruby, because right now configuration is the single biggest hassle in the development of java websites.
  • Re:Brrrr... (Score:3, Insightful)

    by BladeMelbourne (518866) on Monday September 10, 2007 @03:10AM (#20535845)
    RoR is a framework, you can't fairly compare it to PHP, which is a language.
  • by ubernostrum (219442) on Monday September 10, 2007 @03:25AM (#20535913) Homepage

    Only a python fanboy would call python "much cleaner" than ruby (come to think of it though, one area where python does win big is in sheer quantity of fanboys...

    Yes, damn that Python. I mean, Ruby is so much cleaner. In Ruby, everything's an object! Wait, no, that's true in Python too. But in Python you have to prepend self to talk about an instance variable, that's ugly! Oh, wait, Ruby uses @ and has self for some cases, too. Hm. Well, Ruby's got all that metaprogramming goodness, surely you can't do that in Python! Er, no, forgot about __metaclass__ (which, by the way, doesn't have an equivalent in Ruby -- you have to monkeypatch the class object after it's created), never mind on that one.

    Etc., and so forth. Only a "fanboy" would proclaim one language or the other as being inherently superior; in the long run, the biggest difference between the two is idioms (the languages themselves are remarkably similar once you discount superficial syntax differences; see, for example, Python "fanboy" Alex Martelli explaining how Ruby and Python are far more similar than different [google.com]). And in doing so you've tipped your hand.

  • Re:Brrrr... (Score:3, Insightful)

    by shutdown -p now (807394) on Monday September 10, 2007 @03:32AM (#20535953) Journal

    JSP and ASP are terrible compared to rails.
    In speed of development, yes. But what about perfomance, scalability, and reliability? How about amount and quality of available documentation?
  • Re:Sure (Score:5, Insightful)

    by dk.r*nger (460754) on Monday September 10, 2007 @03:46AM (#20536003)

    I've never used Ruby or RoR, but my impression of it seems to be one of great expectations and not a lot of delivery. I've read way too many blogs by people who built web sites with RoR only to have them crash and burn under load. Also, the language itself seems to place a lot of importance on clever syntactic sugar, which being an old fart I automatically dislike.


    You could, you know, link to those "way too many blogs" and thus let the rest of us decide for ourselves if this is incriminating evidence against Ruby.

    "I read it on a blog" does not in any way imply truth.
    "I read it on many blogs" doesn't really make it much better.

    And until then, you shall remain a troll. After you post the links, you'll have your status upgraded to "person with an opinion, willing to discuss".
  • Not hard (Score:1, Insightful)

    by Anonymous Coward on Monday September 10, 2007 @05:09AM (#20536397)
    > PHP5 Vs. CakePHP Vs. RubyOnRails?

    One of the most visited sites with dynamically generated content, Wikipedia, is written in PHP. So, I'd say that shows it's scalable and heavy-duty.
  • by Anonymous Coward on Monday September 10, 2007 @05:15AM (#20536423)

    (and the syntax is basically the language)

    ROFLMAO
  • by dankelley (573611) on Monday September 10, 2007 @05:58AM (#20536583)

    A key issue, in contrasting PHP with RoR, is deployment.

    Deploying PHP is easy in most environments, perhaps as much because of its age as because of its inherent character. I work in an academic environment, in which all professors and students have the ability to make PHP sites. Each of my personal computers also lets me make PHP sites with no difficulty. Deployment amounts to no more than a file copy, perhaps with a change of file permissions. (I won't mention the database work, because of course it is the same for all schemes, PHP, RoR, etc.)

    But, unless you're using a host that has been set up to server RoR, deployment may involve changing Apache configuration files, compiling new Apache modules, etc. Such changes require root access (not available to folks sharing machines), and have the potential to break the other sites on the machine.

    I think there is a reason why the RoR tutorials, books, and promoters so seldom mention deployment: it is difficult for many people in non-commercial environments that are not set up for RoR.

    Oh, and one more thing. All of this fiddling with apache is boring to those who have set out to create websites. Learning Ruby to do RoR is quite fun, actually, and it has the advantage that it lets you use Ruby for other tasks as well. But learning apache doesn't help you with anything but apache; it's a bit of a single-lane road.

    RoR has a sort of elegance about it, and you gain a great deal of functionality from the system (e.g. for logins, etc.), and so it is a terrific tool for rapid development, particularly of an evolving idea for a site. It sounds crazy, but the optimal path may be to write the site in RoR and then rewrite it in PHP, so that deployment will be easy and so that the site will scale well[*].

    * -- I've not mentioned scaling and speed because these issues are covered in other posts here. Basically, RoR is not impressive on either.

  • Re:Sure (Score:2, Insightful)

    by LizardKing (5245) on Monday September 10, 2007 @06:02AM (#20536595)

    PHP users seem to spend inordinate amounts of time worrying about the latest exploit in the PHP engine, or how easy it is to introduce exploits at the application level thanks to the awful library functions, while RoR users end up mulling over the lack of scalability in their apps once the initial prototype is complete. Meanwhile, "boring" Java apps continue to power large scale systems with increasing reliability and maintainability. Perhaps it's because neither PHP or RoR has the depth of experience or literature on best practices that J2EE now has. That's not to say that things have always been so rosy in the Java world - EJB conventions buggered up a lot of projects until a decent set of patterns were identified and people had bought into the ideas behind lightweight frameworks such as Spring.

  • by LuckyStarr (12445) on Monday September 10, 2007 @06:27AM (#20536691)
    I've used PHP, Perl, Ruby and Python (in that order) and I can confirm that Python is in fact cleaner. One of the reasons being it's spartan syntax. It's one of the goals of the language [c2.com]. :)

    PHP is just ugly, (see grandparent) Perl and Ruby are quite fun and share the same philosophy (see TIMTOWTDI [c2.com]) where Python is just the opposite (although fun too).

    Python and Ruby also share their deep roots in clean object orientation, where Perl's OO syntax is - though bolted on - very flexible and even more TIMTOWTDI than Ruby's.

    Just to set things straight, I really like Perl, Ruby and Python, though I can confirm that developing web applications with Django is bliss.
  • Re:Nriyh (Score:3, Insightful)

    by Qbertino (265505) on Monday September 10, 2007 @06:56AM (#20536821)
    PHP. People do build large apps in PHP. Having used it quite a bit it remains a mystery to me a)how and b)why. Its ugly and handles state poorly - a disaster for a web language in my view.

    It's difficult to understand, since PHP combines the quirkyness of Perl with the syntactic bloat of Java and does have some other shortcommings. However, it handles all web stuff very gracefully. Tons of functions in PHP are built to handle the everyday shortcommings the WWW Inet-service brings along. And they are all come in the box without any classpath or you-need-this-seperate-servlet-running-to-handle-m e crap. Oneliners convert objects to HTML characters, walk arrays or connect to a database. The God-Datatype in PHP is the PHP Array - compareable to Pythons dictionary - and offers tons of functions to handle them and do neat stuff to arrays fast. Despite (or because?) some 300+ core functions it's extremely newbie friendly - no need to add any libs or stuff just to halfway deal with webstuff. There-is-more-than-one-way-to-do-it applies to PHP as much as it applies to Perl, without PHP bugging people with a to terse but arcane syntax.

    PHP is the king of all SSI solutions because it's built for exactly that sort of task and nothing else. That's why the most successfull, non-trivial web applications are built with it. It's the best tool for the job, plain and simple.
  • Static typing (Score:1, Insightful)

    by Anonymous Coward on Monday September 10, 2007 @07:59AM (#20537249)
    The difference that I can see between those two examples is that the first one declares the types for its variables and parameters, and the second doesn't. So in the Java code (as in C or C++) you'll get compiler errors for many more programming errors. In my experience, this is a huge advantage.
  • Twitter Follow-Up (Score:4, Insightful)

    by jaaron (551839) on Monday September 10, 2007 @08:01AM (#20537265) Homepage

    And there's a good follow-up [romeda.org] by one of his coworkers:

    We've been extremely happy with Rails, and make use of the multitude of helpers that it offers us - like any application on any stack, though, providing fast response times to a (rapidly) growing number of users is a challenge. The solutions are often tightly coupled to the application and its characteristics, and while scaling the most trafficked Rails site in the world, we've run into situations where existing solutions weren't enough.

    Rails is best at database baby-sitting, which is not what Twitter is about and it's understandable they would have issues. Ruby is slow and we need a good virtual machine. Nevertheless, Twitter does run on Ruby which shows that it can be made to scale. Not that Twitter is a good measure of anything other than, well, Twitter. And I'm sure someone could have done it with PHP, Python, Erlang or C.

    Which is always why blanket statements about languages and platforms is always a bad idea. Just look at the comments on this article. It's just a chance for everyone to trumpet their favorite web framework or language. Sure we have our favorite tools, but most of them suck at one thing or another.

  • I learned PHP once (Score:4, Insightful)

    by seebs (15766) on Monday September 10, 2007 @08:44AM (#20537659) Homepage
    Everyone talked a lot about PHP.

    I started learning it. By about a chapter into the PHP book, I was thinking "holy crap, this language is uglier than perl". It has everything you would expect from a language thrown together by people who were either ignorant of software engineering or aware of it, but aggressively hostile to it. Everything global by default? WTF?

    I have never seen a language with so many carefully crafted security holes that the developer needs to learn to avoid. Default behavior for inclusion is to allow URLs, so you can, you know, run code from any site in the world. There's a feature everyone always wanted, which is never going to be subverted!

    I made it through about two and a half PHP books. In that time I learned that the MySQL and PostgreSQL interfaces were substantively different, and of course, used differently-named functions with slightly different calling conventions. Why? Because there's no abstraction or generalization going on; just whatever features sound cool getting thrown in with some name that wasn't previously in use. I learned that this is just BASIC all over again.

    I spent several days thinking hard about bleach, and went back to programming languages that were designed with some kind of consideration given to the development of larger projects.

    Ruby's undoubtedly "slow". That's what everyone said about perl and awk, too. Come to think of it, I've had people tell me that C was too slow. But Ruby has the amazing, shining, virtue that it is not a stupidly-designed or ugly language. I spent a while working with Ruby, and some helpful people pointed out that, in fact, the language does have a gotcha to watch out for. One. Not so many that you have to buy whole books full of things that you'd obviously try that don't work, open your site up to XSS, or behave erratically. No, just the one.

    Can PHP work? Sure. But the tacked-on afterthoughts provided to allow you to, in theory, if you remember to and want to put in the work, use basic software engineering principles, are not enough. The language provides a huge array of runtime functionality, with a function for everything. It doesn't provide the basic tools you want for engineering large projects, meaning that the workload of maintaining big stuff in PHP is exponential, not just quadratic.

    It can be made to work, but it really is that badly considered, and I wish people would stop doing things in it. Life is easy enough for the botnet people already, we don't need a language in which you have to be warned not to set the flag that lets remote sites set every global variable in your program.
  • Re:Sure (Score:3, Insightful)

    by outZider (165286) on Monday September 10, 2007 @10:08AM (#20539031) Homepage
    There's a tad of a failure in logic there. There are high profile sites written in Lasso as well, but that doesn't make it a serious tool, it just makes it a functional tool. PHP was designed to create pages with logic very easily, and it's being bent in a lot of ways now, which is cool in a way, but there's really no reason why anyone should work that freakin hard. At this point, creating an AJAX enabled site is far easier, and still scalable for a competent admin, with Java, or Perl with Catalyst, or Ruby with Rails.
  • Re:Sure (Score:3, Insightful)

    by Tassach (137772) on Monday September 10, 2007 @11:28AM (#20540349)

    You have the right idea about RoR (speaking as someone who excitedly spent /wasted/ a month learning into it). RoR has some hot ideas but it tries to be too smart and locked down for its own good.

    I had the same experience. Right now I'm trying out Catalyst [catalystframework.org] + Mason [masonhq.com] running under mod_perl.

    Catalyst takes most of the good ideas from RoR and combines them with Perl's TIMTOWTDI philosophy, rather than Rails' "our way or the highway" attitude.

    Mason is a PHP-like templating language for Perl.
  • Re:Sure (Score:1, Insightful)

    by Tazz_ben (619965) <ben@wb[ ]stems.com ['psy' in gap]> on Monday September 10, 2007 @11:58AM (#20540847) Homepage

    I also find the "CakePHP vs PHP5" question to not make any sense, I'm sorry.
    Maybe just me, but that made perfect sense. One option available to a programmer at the beginning of an application is to not use a framework at all. There is a number of reasons why the person may choose to do this. Maybe none of the frameworks do what you want to do with the application, maybe you can make them more efficient not using the framework. Or maybe there is a business decision that would drive you to not use a framework. I can tell you from personal experience that when we started on Heap CRM http://heap.wbpsystems.com/ [wbpsystems.com] we looked at Java, some of the PHP5 frameworks, etc. And it was business decision to (in our case) to write our own internal framework.

Real Users never know what they want, but they always know when your program doesn't deliver it.

Working...