Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Which PHP5 Framework is Your Favorite?

Cliff posted more than 8 years ago | from the beyond-your-personal-home-page dept.

138

matt_j_99 asks: "With all the talk about Ruby on Rails, I've been thinking about PHP frameworks. Ruby on Rails looks pretty cool, but frankly, I don't want to learn a new language. It seems that with all the slashdot discussion about RoR, somebody always makes the valid point that PHP is not a framework. But with PHP5's, Object Oriented features, a standard framework might emerge. Prado, Carthag, BlueShoes, and PHITE all seem like interesting frameworks. What PHP frameworks have you used in your applications? What were the pros and cons of each? Which framework do you think will have the best chance of long-term viability and maintenance?"

cancel ×

138 comments

Pretty obvious answer (2, Insightful)

rylin (688457) | more than 8 years ago | (#13316394)

Our in-house framework, as it does precisely everything we need - no more, no less.

Re:Pretty obvious answer (0)

LuckyStarr (12445) | more than 8 years ago | (#13316407)

We must use the same framework, as mine does exactly the same.

Re:Pretty obvious answer (1)

rylin (688457) | more than 8 years ago | (#13316415)

GASP! You've stol^H^H^H^Hcopied our codebase?
Prepare to be sued into the next millenium!

Re:Pretty obvious answer (2, Insightful)

KILNA (536949) | more than 8 years ago | (#13316441)

Indeed. You have the choice of someone else's idea of what features and work-flow you need, or your own. Writing wrapper classes for output, databases, etc. isn't that hard, and you can get a solution 100% tailored to you needs.

The only argument I could imagine for using someone else's framework is to reduce the overhead to bring in new programmers since they'll already know much of the ropes. But in the case of PHP there really isn't a clear winning system with a large pool of available programmers...

Your own DBMS (1)

systems (764012) | more than 8 years ago | (#13319542)

Okay, I admit the analogy is a bit extreme but it makes the points obvious.

The thing is I think people don't think deep enough anymore.
What is a framework?
I not sure we can all agree on the answer, I am sure that there is a formal answer.
I would say a framework, is a factory.
Someone else can say, a framework is a meta-tool, a tool that makes tools.
Another can say, a framework is a domain-specific language.
And another (the one I like the best) would ask, what is the difference between all those answers.
Does C++ or Haskell, qualify as frameworks, why and why not?
Does PostgreSql qualify as a framework? why not, couldn't we say that pgsql is a framework to create databases, it just happens to implement that standard language called Sql.

The point I want to make is, a framework is software that helps you tell the computer what you want to do, in that I don't see how can a framework be any differant than any software you've used (thinking about it I can say MS Word is a framework to create documents). So disregarding frameworks altogether is just wrong.

A framework will include the know-how of some developers, you should not start from scratch, you should not start from the beginning, you should always start from where others have ended, to learn from their work and experience, else have other have said it before me, you are deemed to reinvent the wheel, and you will be pushing your self back to the stone age (or whenever they actually reinvented the wheel)

PHP? Switch to Python and Django (0, Troll)

Boffy (881935) | more than 8 years ago | (#13316442)

I've been exclusively PHP for a number of years now, but the lack of innovation in frameworks and the OO limitations in PHP have lead me to Python. Python has a great up-and-coming framework called Django [djangoproject.com] which was covered on slashdot recently. I've switched over to this and can see my productivity shooting right up once I've got to grips with it

Re:PHP? Switch to Python and Django (1)

ciroknight (601098) | more than 8 years ago | (#13316708)

No offense, but that's pretty trollish. The article specifically mentions that he wants to do things with PHP and not Ruby on Rails, and since Django is Ruby on Rails for Python, you're not helping.

As for my contribution: I've worked a *miniscule* bit with Prada and I really didn't like it. But you might find it to your own liking. Different strokes for different folks I guess.

Re:PHP? Switch to Python and Django (1)

yasth (203461) | more than 8 years ago | (#13319031)

I think django might still be little bit raw to be used in production. I mean they don't have an official version yet for crying out loud. It is really cool though.

Re:PHP? Switch to Python and Django (1)

Boffy (881935) | more than 8 years ago | (#13319827)

The roadmap is coming along. It's basically feature complete, they're just fixing bugs at the moment and sorting some usability issues. I'm using the development version for a small project to get to grips with it before I use the release version for my main project. By the time you're ready for any serious stuff, I expect 1.0 will be ready. It's not gonna be one of these OSS things that stays in beta forever

lame excuse (0, Troll)

namekuseijin (604504) | more than 8 years ago | (#13316488)

"I don't want to learn a new language"

how about learning a true language like Ruby rather than continue with a subpar Perl reject like PHP?

Re:lame excuse (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#13316504)

How about learning a "real" language like C, rather than a script piece of shit like Ruby?

Re:lame excuse (2, Interesting)

namekuseijin (604504) | more than 8 years ago | (#13316541)

how about learning a modern, multi-paradigm, very higher-level language for rapidly developing business apps like Ruby rather than an ancient portable assembly to build infrastructure like C?

Re:lame excuse (2, Insightful)

D'Sphitz (699604) | more than 8 years ago | (#13316613)

How about just accepting that while Ruby may suit your needs just fine, most people aren't interested. Then you can quit wandering around all pissed off at everyone because they don't use Ruby, and be happy that you use Ruby even though other people prefer Python or PHP.

Seriously, is Ruby some kind of a cult or something? I thought mac zealots were bad, but everytime a scripting language is mentioned the ruby enthusiasts come out with such hate for everything non-Ruby. Get a grip.

Re:lame excuse (1)

Santana (103744) | more than 8 years ago | (#13316673)

How about learning a "real" language like C, rather than a script piece of shit like Ruby?
how about learning a modern, multi-paradigm, very higher-level language for rapidly developing business apps like Ruby rather than an ancient portable assembly to build infrastructure like C?

I don't see the zealotry nor the cult here. He replied to a troll, with a nice summary of Ruby features not found in C.

You get a grip

Re:lame excuse (1)

google (125927) | more than 8 years ago | (#13318312)

I suppose Ruby could be a cult, as evidenced by the fact that Ruby can be used to lure Genine Garafalo into your unicorn garden [hobix.com] ... or something like that.

But does Ruby like koolaid? I don't know. I just don't know.

To be honest, I've been using Ruby in a zen-like trance to help me attain my buddha-hood, so I haven't watched these in awhile.

not ruby specific (1)

namekuseijin (604504) | more than 8 years ago | (#13316687)

it's not like i'm advocating ruby for any task whatsoever. i was just pointing out it was stupid to complain about learning a new language or tool. my example was ruby because the man cited RoR.

i could go with other languages like Python, OCaml, Scheme, Perl and many others, all with far better support for higher level programming, OO and modularization than that PHP crap.

Re:lame excuse (1)

ciroknight (601098) | more than 8 years ago | (#13316738)

Oh you mean like Visual Basic.. I tried it and it sucked.

I find that even if it takes a bit longer to code, you will get better results out of C/C++/ObjC. Objective C is slowly but surely gaining momentum in my programming portfolio as I think "hey, that'd be easier to do in ObjC than it would C++".

As for scripting, PHP is pretty good now. It used to be trashy, but version 4 and 5 are very nice, easy to work with, and reasonably fast. Python's not my cup of tea (little too much like Java for me, and I really don't like my "language" to include a library for everything; I can find my own and include them or write my own). Ruby would be interesting to learn, but I doubt if I'd ever use it for anything.

Inevitably, as higher level languages are written in C, you're almost always going to find that you get better performance out of a comparable C app. But I guess if you're looking for speed of development and don't really mind if the language dies in the next ten years, Ruby or Python will work for you. Meanwhile my C app will be maintainable by the newest upstarts to the oldest of the oldies.

Re:lame excuse (2, Insightful)

namekuseijin (604504) | more than 8 years ago | (#13316805)

i said "modern, multi-paradigm, very higher-level language", not a "severely patched M$ offering for a very old, simple and basic language for beginners", not unlike PHP btw.

"find that even if it takes a bit longer to code, you will get better results out of C/C++/ObjC."

"Inevitably, as higher level languages are written in C, you're almost always going to find that you get better performance out of a comparable C app."

ah! the "slow performance" argument, easily refutable by noticing that most performance bottlenecks in systems come external factors like file system, DBMSs, network etc; and also that most libraries for such languages are just ( mostly thin ) wrappers for native libs.

"As for scripting, PHP is pretty good now. It used to be trashy, but version 4 and 5 are very nice, easy to work with, and reasonably fast."

it really isn't: it's still a mess of a language with no support for modularization other than OO classes or relying on shallow naming conventions for functions in the global namespace.

"Python's not my cup of tea (little too much like Java for me, and I really don't like my "language" to include a library for everything; I can find my own and include them or write my own). Ruby would be interesting to learn, but

"I doubt if I'd ever use it for anything."

you won't. remember the mantra: "right tool for the right job"

"don't really mind if the language dies in the next ten years, Ruby or Python will work for you. Meanwhile my C app will be maintainable by the newest upstarts to the oldest of the oldies"

FUD. plain and simple. your C app from 10 years ago most likely depends heavily on external 3rd -party libraries that may be hard or impossible to either find or make them work today.

Python, Ruby and company are open-source projects with already more than 10 years old and are likely to stay.

Re:lame excuse (0, Offtopic)

mattyrobinson69 (751521) | more than 8 years ago | (#13316575)

troll? jesus, he's right.

uh-oh (4, Insightful)

Santana (103744) | more than 8 years ago | (#13316562)

but frankly, I don't want to learn a new language

That's the worst thing that can happen to a professional (assuming you are one): not willing to learn new things. I strongly recommend you to learn Ruby, "it puts the fun back on programming", you won't regret.

Re:uh-oh (1)

imgumbydammit (879859) | more than 8 years ago | (#13316592)

I dunno, I can sympathize with that sentiment. Sometimes it's better to build on something you already know, rather than start over at the bottom learning what might seem to be yet another flavour of the month language.

Re:uh-oh (2, Insightful)

mysticgoat (582871) | more than 8 years ago | (#13317789)

I also go along with the sentiment (of sometimes wanting to avoid learning yet another language).

This can be summed up with the question: "Is this guy a programmer with ten years' experience, or a programmer who has repeated one year of experience ten times over?"

As Grasshopper plans his career it can be good if he asks himself how others will see him in a few years.

Re:uh-oh (2, Insightful)

ibbey (27873) | more than 8 years ago | (#13318468)

This argument falls flat pretty quick. You don't need to abandon everything else you've learned to learn a new language. I'm not arguing that you need to learn every new language that comes along, but spending an hour learning -about- a new language is quite reasonable. Once you've done that, you can make a reasonable decision about whether you should continue and learn more.

Every language has advantages & disadvantages. I love Ruby & Rails, but for some jobs, I'll still use PHP. Some jobs are best suited to Perl, and some to C. A good programmer will be able to choose the best tool for the job at hand. Remember, all four of these languages have the same underlying inspirations, so once you know one, it's much easier to learn another. If you're a good PHP or Perl programmer, you can be a competent Ruby programmer in a week with some effort. Do you truly believe that your career & programming ability will be better served by NOT making that effort? If so, that's fine, that just leaves more jobs for the rest of us.

not only that.... (1)

Xtifr (1323) | more than 8 years ago | (#13316609)

It's not like Ruby's a hard language if you already know Perl/PHP. I was able to pick up the basics in a couple of hours browsing. Now, if someone came out with, say, a functional scripting language, I might hesitate. I keep meaning to study Haskell or one of its cousins, but never find the time. But Ruby? That's about as straightforward as it gets!

Going right off topic here (1)

heinousjay (683506) | more than 8 years ago | (#13316735)

Now, if someone came out with, say, a functional scripting language, I might hesitate.

You don't know Javascript? Or maybe you don't know that it has much in common with Lisp/Scheme, with C-like syntax [crockford.com] ? Look into it - as much as people denigrate it, it's one of the coolest languages out there.

Ruby has pretty much the same features - functional programming is very possible. If you master the concepts using these mostly familiar tools, it's much simpler to jump into the functional languages (or at least it was for me.)

Re:Going right off topic here (1)

Xtifr (1323) | more than 8 years ago | (#13317184)

Nope, don't know the first thing about javascript. Outside my domain for the most part.

I do see that Ruby has functional aspects, but I don't have to use those for the basics--I can stick to the models I know, like OO. So its easy for me to get started. Eventually, yes, I suspect it will be as you say, but I'm not quite there yet. Still, I'm having fun, and that's the important thing. :)

Re:Going right off topic here (1)

Bitsy Boffin (110334) | more than 8 years ago | (#13319063)

Indeed, Javascript is a very nice language. Prototypes rock. Now if somebody would come up with a nice shell binding for one of the mozilla JS engines, that would be cool.

Re:uh-oh (1)

RevAaron (125240) | more than 8 years ago | (#13316703)

Yeah. Or learn Smalltalk, where you have all the power of Ruby, in it's pure, mature and untainted form. Or, maybe a Ruby user could try to learn it. FUN! Actually put the fun back in coding...

Re:uh-oh (2, Insightful)

downward dog (634625) | more than 8 years ago | (#13316709)

I switched from PHP to Ruby after reading the Pragmatic Programmer's tip to learn a new language every year. Learning new languages makes you a better programmer, and Ruby is a great language to learn.

After only a few months using Ruby on Rails, I can't imagine trying to manage a large project in PHP. My attempts at OOP resulted in huge classes (100+ lines), my code wasn't reusable, unit testing was nonexistent, and adding functionality to an existing page usually meant breaking the rest of the application. I'm sure that there are better programmers out there than I was, who can avoid these problems while using PHP. That is fine. But Ruby and Rails helped me to become a dramatically better programmer.

Re:uh-oh (1)

Mr. Slippery (47854) | more than 8 years ago | (#13317190)

resulted in huge classes (100+ lines)

Did you leave a 0 out of that? Or is most of your programming done in trivial problem domains where a 100 line class can do something? (Or have you been infected with one of the object obfuscated memes where one useful class must be shattered into several smaller ones to fit some arbitary idea of proper module size?)

unit testing was nonexistent

Err, if you don't write unit tests, whose fault is that? I don't see how language choice helps with that.

and adding functionality to an existing page usually meant breaking the rest of the application.

Encapsulation [wikipedia.org] . Learn it. Love it. Live it.

Re:uh-oh (1)

downward dog (634625) | more than 8 years ago | (#13317311)

So what was it about my post that set you off? Or are you just having a bad day?

Did you leave a 0 out of that? Or is most of your programming done in trivial problem domains where a 100 line class can do something? (Or have you been infected with one of the object obfuscated memes where one useful class must be shattered into several smaller ones to fit some arbitary idea of proper module size?)

Yes, you can do something with 100+ line classes. (Notice that 500 lines is larger than 100 lines, and would therefore be 100+ lines.) My entire point was that with Ruby on Rails, I was able to do a lot with 5 to 25 line classes, which tends to make development and maintenance more manageable. Three lines of Active Record code can duplicate 300+ lines of PHP. Which would you rather write?

Re:uh-oh (1)

Mr. Slippery (47854) | more than 8 years ago | (#13317425)

Yes, you can do something with 100+ line classes. (Notice that 500 lines is larger than 100 lines, and would therefore be 100+ lines.)

Uh, yeah. My point of contention was that 100 lines makes a "huge" class.

Three lines of Active Record code can duplicate 300+ lines of PHP. Which would you rather write?

Depends. Dunno "Active Record" from a hole in the ground, but I've had plenty of experience with packages that only take 3 lines to give you almost what 300 lines would otherwise do, and somewhere down the line you end up writing most of those other 297 lines to handle the edge cases.

Re:uh-oh (1)

mangu (126918) | more than 8 years ago | (#13317180)

I strongly recommend you to learn Ruby, "it puts the fun back on programming", you won't regret.


Do you have any more compelling arguments than that? The first time I read about Ruby I was interested. Now, by the 10000th time I read how much better Ruby is, without any specific reason other that some people love it so much, I'm pretty bored.


And, BTW, you are way off topic. This article is about PHP frameworks. Let me explain to you. PHP is considered by some to be an excellent language. However, differently from Ruby, PHP users are ready to acknowledge its shortcomings. So, how can we make PHP a better language? Frameworks are one kind of solution.


Ruby users are like "Hey guys, Ruby is better!!!", PHP users are like "Let's see, how can we improve PHP?". Guess which language will be a better solution in the end?

Re:uh-oh (0)

Anonymous Coward | more than 8 years ago | (#13317273)

Ruby users are like "Hey guys, Ruby is better!!!", PHP users are like "Let's see, how can we improve PHP?". Guess which language will be a better solution in the end?

Henry Fort was like "Hey guys, automobiles are better!" Blacksmiths were like "Let's see, how can we improve horseshoes?". Guess how many non-Amish Americans still use a horse and cart?

(Of course, Ruby still has disadvantages, like being dog slow and lacking static checks. But while it's not quite on the level of your Haskells and MLs, it's still a million times better than PHP, which is just about the worst language in general use today.)

Re:uh-oh (1)

mangu (126918) | more than 8 years ago | (#13318152)

Henry Fort was like "Hey guys, automobiles are better!" Blacksmiths were like "Let's see, how can we improve horseshoes?". Guess how many non-Amish Americans still use a horse and cart?


Funny typo, perhaps you were thinking about Charles Fort? [forteana.org]


But, if you really meant Henry Ford, he fell in love so much with his Model T that General Motors have sold more cars than Ford in every year since 1927. Ford was unable to view objectively his own creation and realize that it wasn't perfect, while Chevrolets were improving from year to year.


it's still a million times better than PHP, which is just about the worst language in general use today


Can you explain in a few words why Ruby is so superior? Can you explain why PHP is worse than, for instance, Visual Basic, Fortran, or Cobol? If it's so obvious, it should be very easy to demonstrate.

Re:uh-oh (1)

MarkusQ (450076) | more than 8 years ago | (#13319198)


it's still a million times better than PHP, which is just about the worst language in general use today
Can you explain in a few words why Ruby is so superior? Can you explain why PHP is worse than, for instance, Visual Basic, Fortran, or Cobol? If it's so obvious, it should be very easy to demonstrate.

A few words? How about one: taint [phrogz.net] .

Or for a broader one that incompasses the first, security [harvard.edu] .

These are just two examples of what I see as a broad pattern. The attitudes of the two languages (and their associated communities) are very different.

--MarkusQ

Re:uh-oh (1)

AaronBrethorst (860210) | more than 8 years ago | (#13319488)

VB's a real object-oriented language [microsoft.com] . It's not perfect, no language is. Not C, PHP, VB, C#, Objective C, Ruby, or any of the others. But, it's come a long, long way since the days of VB 6. Ruby is incredibly cool, though, I have to say. I took the "learn a new language every year" idea to heart, and it's made me a far better developer for my trouble.

Ruby resources (3, Informative)

Santana (103744) | more than 8 years ago | (#13317334)

Heh, well, no offense but, people that use to reply like you haven't tried Ruby, or don't understand it. Otherwise you would be in love with it already.

We cannot compare PHP and Ruby. It's like comparing BASIC and Perl, you get the idea. Remember when you discovered Perl and all its magic? Well, that's what happens when you get into Ruby. It's a true object oriented and dynamic language ready for real applications.

This might or not make sense to you. It depends on the use you are giving to your language of choice. If you write one-liners in Perl, you might not feel motivated to move to Ruby. If you are writing templates in PHP for your web applications and you're doing fine, you might not need Ruby either.

You see the light :) when you want to write OO applications/scripts. PHP used to have an awful hack (I haven't seen PHP 5), so does Perl 5. Python would be your choice, but for some reasons I cannot explain (yes, this is subjective) Ruby feels more natural.

Ok, I have fallen again in the "I love Ruby so much" that gets you so bored. So, here is some homework for you (some very nice presentations and small articles):

Ruby: A transparent, object-oriented programming language [pragmaticprogrammer.com]
10 Things Every Java Programmer Should Know About Ruby [onestepback.org]
The Ruby Programming Language [informit.com] (by Matz, Ruby's author)
Thirty-seven reasons I love Ruby [rubyhacker.com]
Blocks and closures in Ruby [artima.com]

Re:uh-oh (1)

ibbey (27873) | more than 8 years ago | (#13318245)

And, BTW, you are way off topic. This article is about PHP frameworks. Let me explain to you. PHP is considered by some to be an excellent language. However, differently from Ruby, PHP users are ready to acknowledge its shortcomings. So, how can we make PHP a better language? Frameworks are one kind of solution.

Well, we're not really THAT far off topic. The reason that the OP doesn't want to use Rails is that they don't want to learn another language. That's a good reason on the surface, but to those of us who have made the leap, it's absurd. As many have pointed out, if you know PHP or Perl, the learning curve of Ruby is really shallow. You can get the basics in a few hours, and be quite proficient in a few weeks. And once you've taken the leap, you WILL be more efficient on 99% of tasks. So rather then being off topic, we are pointing out that the entire question is based on a flawed premise.

I'm not qualified to really explain the technical advantages & disadvantages of Ruby vs. PHP. But there's a high level overview of what's great about Ruby on the Ruby website [ruby-lang.org] . If you want more, the first edition of the excellent Programming Ruby is available for free online. You could easily scan through the first chapter [rubycentral.com] in half an hour, and it touches on all the major parts of the language. If you're honest about your curiosity about Ruby, then I highly recommend you spend a few minutes & scan the online docs. You won't be disappointed.

Re:uh-oh (1)

chriseyre2000 (603088) | more than 8 years ago | (#13320021)

There may be good reasons why someone is sticking with PHP.
I maintain a site in PHP (I am not about to slashdot myself). It was not my first choice for a language. I bought a cheap (£20 for two years - including 1GB transfer per month- can you show me a ruby hosting service that can match that?) domain plus hosting based on the availability of Python support. Unfortunately they had discontinued Python support shortly before that. I ended up using what was available (the choice was Perl or PHP).
PHP is not a great language but I have found that is fit for purpose for small sites (I make no claims for large sites having no experience in it).
However I have yet to find things that it can't do easily - PHP has been sufficient for my needs.

Re:uh-oh (1)

ibbey (27873) | more than 8 years ago | (#13318611)

Ruby users are like "Hey guys, Ruby is better!!!", PHP users are like "Let's see, how can we improve PHP?". Guess which language will be a better solution in the end?

Yep, you're right. Us Ruby users are just sitting on our asses cheering, not actually improving anything. Oh, wait. No, we're not. The entire Rails environment is only about a year old, and is advancing literally every day. The core ruby language has been at the same version number for a while now, but there is a new version on the near horizon, all of the supporting technologies have advanced greatly in the meantime. Ruby might or might not be as successful as many of us believe, but it's not going to go away no matter how much you want it to.

Re:uh-oh (1)

Atzanteol (99067) | more than 8 years ago | (#13318951)

Is it good for a "professional" to just ignore the parameters of a problem and answer with what they wish were the question?

Not all companies 'sanction' all languages. I typically don't have much of a choice on language when doing my job. What makes you think everyone else does? What the hell is wrong with you Ruby zealots?

Re:uh-oh (1)

Santana (103744) | more than 8 years ago | (#13319099)

Is it good for a "professional" to just ignore the parameters of a problem and answer with what they wish were the question?

What are you talking about?

Not all companies 'sanction' all languages. I typically don't have much of a choice on language when doing my job. What makes you think everyone else does?

What makes you think I'm thinking everyone else can choice his/her language? Anyways, the OP clearly *can* choice his language. He's just too lazy to learn another one. And that's what I'm replying to.

What the hell is wrong with you Ruby zealots?

The only Ruby-specific in my post is the suggestion to learn it. You wouldn't have thought the same if you had read it like s/Ruby/PHP/.

Fear not Atzanteol, Ruby is not a threat for you. This is your own [PHP] space and you're safe in it. Here, take your pill, and those zealots you see will go away.

Re:uh-oh (1)

Atzanteol (99067) | more than 8 years ago | (#13320555)

Wow, what arrogance. You assume that the OP has nothing better to do with his time than to learn your new pet language? Maybe he's married with three children and doesn't quite have the spare time like you seem to have? Perhaps he wants to keep the languages he learns to those that may be of use to him at his company (or future companies)? Maybe he doesn't pick up new languages as well as you do and it'll take much longer? Such an investment of time must be carefully made.

People without spare time needen't go learning every language just because *you* think it's nifty. I barely see any use of Ruby at all, and nearly nobody I work with even knows what it is. I have little reason to learn it. And If I had little spare time I would probably never think to pick it up until I start hearing about it at work.

How *dare* you assume to know what other people's time is worth?

The only Ruby-specific in my post is the suggestion to learn it. You wouldn't have thought the same if you had read it like s/Ruby/PHP/.

Fear not Atzanteol, Ruby is not a threat for you. This is your own [PHP] space and you're safe in it. Here, take your pill, and those zealots you see will go away.


Again, your arrogance shines... What makes you think I'm a PHP developer? Simply because I'm not ravenously pushing Ruby like crack? If so then I'm unlikely to ever become a Ruby dev. Sound like a bunch of born-agains. In fact, they're becoming almost as annoying as the Mac folks. Uh oh, you're not a Mac zealot too are you?

Question: I'm doing PHP work under Linux, can somebody suggest some books?
Answer from 500 morons: Get a Mac and do your stuff under Ruby!

Re:uh-oh (1)

kannibal_klown (531544) | more than 8 years ago | (#13321956)

I'm all up for learning new things. Heck, I'm learning 2 things right now: 1 for work and 1 for home.

There is one problem though: if he works for a company, they may have very strict regulations about what he can/cannot use (for stuff at work).

For example, at my place we're pigeon-holed into using only a small set of languages and frameworks. They even recently cut back one or two.

The common reasoning is, if they don't put down controls, then developers go off and do their own thing, which is ok for the short-term. But then when someone else has to maintain it, they might not have the skillset.

So great, learn Ruby on your own! But his company might force him to use PHP and javascript.

yet another framework (3, Informative)

larry bagina (561269) | more than 8 years ago | (#13316574)

I haven't used it (I only learned about it from one of the endless /. RoR articles), but Cake [cakephp.org] is another option. If nothing else, the logo is making me hungry.

MVC Framework (1)

antigravity (841907) | more than 8 years ago | (#13319462)

http://www.mojavi.org/ [mojavi.org] Check the forums for many open source example sites.

Which PHP5 Framework is Your Favorite? (4, Funny)

dont_think_twice (731805) | more than 8 years ago | (#13316584)

Which PHP5 Framework is Your Favorite?

I guess I sorta like them all ...

Re:Which PHP5 Framework is Your Favorite? (2, Informative)

alatesystems (51331) | more than 8 years ago | (#13316699)

Dude, I totally wish I could mod you up right now for that totally subtle Office Space reference. That made my morning.

+5, Awesome

Re:Which PHP5 Framework is Your Favorite? (1)

Safety Cap (253500) | more than 8 years ago | (#13316840)

I feel the exact same way.... I celebrate the guy's entire catalogue.

Learn Ruby (5, Insightful)

Anonymous Coward | more than 8 years ago | (#13316627)

Listen, I've been programming PHP since version 3. I've been writing Perl since.. well since before some of you have been born. I've been working in Lisp and C since before that!

The secret to Ruby on Rails is RUBY. You just can't do that kind of stuff in PHP. PHP is pretty pathetic once you get beyond the basics. It is truly a language for the "bottom 95%" as I call it. PHP has at least the following flaws:

* poor metaprogramming: try creating an anonymous function in PHP, it's just a STRING! Yuck. Closures? Never heard of 'em. Try writing a one-liner in PHP that sorts a list of objects. Impossible.

* global variables for session, cookies, etc. Makes unit-testing a bitch!

* no "finally" clause on exceptions. WTF? Built-in functions don't raise exceptions. WTF?

* no way to refactor object fields. Yes you can use "__get/__set" but those "fake" fields don't work in every place a regular field works. WTF? In Ruby everything is a method, there are no fields, refactoring is a breeze.

* No "mixins".. I can't write a method and then stick it into multiple classes. Not even with include().

* Exposes variables vs. variable references. I thought PHP5 would get rid of "&" forever. I was wrong.

Now Ruby ain't Lisp, that's for sure. But I'd rather stick forks in my eyes than programming in PHP again.

Anyway, a good programmer has no problem learning a new language. It'll take you longer to learn the framework than the language. Ruby is simple and clean and VERY consistent from top to bottom, give it a try.

Hi, please shove it up your ass (-1, Troll)

Anonymous Coward | more than 8 years ago | (#13316694)

Ruby people are getting extremely annoying these days. Every time any sort of scripting language is mentioned, you're all compelled to tell us why Ruby is better. You know what? We've heard enough of your cheerleading.

Time for a new Netcraft report... (0)

Anonymous Coward | more than 8 years ago | (#13317619)

Netcraft confirms: Ruby is dying

Re:Hi, please shove it up your ass (0)

Anonymous Coward | more than 8 years ago | (#13318467)

Jesus people are getting extremely annoying these days. Every time any sort of scripture language is mentioned, you're all compelled to tell us why Jesus is better. You know what? We've heard enough of your cheerleading.

Ruby is a passing fad, a PhD's toy (1, Informative)

mangu (126918) | more than 8 years ago | (#13317031)

Your arguments remind me of a professor I once had, trying to tell me how Modula2 was so much better than C/C++, which he called "medium level" languages.


Yes, sure, if you worry about "metaprogramming", "refactor object fields", or "Exposes variables vs. variable references", then Ruby is the language for you, but... how about Oberon? Now that's one language I'm sure you'll love!


OTOH, if you aren't in an ivory tower and have to program for a living, then PHP is like C, a language the "perfessors" hate,but it keeps working just fine for the 99.5% of us.

Re:Ruby is a passing fad, a PhD's toy (2, Interesting)

ttfkam (37064) | more than 8 years ago | (#13317552)

OTOH, if you aren't in an ivory tower and have to program for a living, then PHP is like C, a language the "perfessors" hate,but it keeps working just fine for the 99.5% of us.
Would that be the 99.5% of all C apps that have weekly buffer overflow exploit notices?

Or would that be the 99.5% of PHP apps that have constant SQL and variable injection attacks. *cough* PHP XML_RPC support *cough*

Re:Ruby is a passing fad, a PhD's toy (1)

Unordained (262962) | more than 8 years ago | (#13318001)

Err ... yes. Most languages get used both carefully and not. Even the best keep-you-from-shooting-yourself-in-the-foot languages won't prevent you from writing incorrect programs; I'm really not sure why people bother. Buffer overflows aren't hard to prevent, and if a programmer gets caught writing one once, will probably never do so again. SQL injection is an issue in any language because people insist (note, I do this too) on writing their SQL as strings and injecting values into those strings, as opposed to using prepared statements with placeholders (which is much safer, but I'm not sure all API's support it.) It's a matter of using libraries correctly. But hey, let's complain about divide-by-zero errors and blame the language rather than the programmer.

Buffer overflows and SQL injection can be prevented, if you just learn a little bit. Those responsible are either chronically irresponsible and shouldn't be coding at all, or haven't learned enough yet, and should be taught. Irresponsibility and ignorance aren't language issues, they're people issues. Language choice is much more about preference/habit/comfort than language features or available libraries.

People vs. Technology (2, Interesting)

ttfkam (37064) | more than 8 years ago | (#13318121)

Except that for years PHP and MySQL, tools marketed to beginners, didn't have the "correct" option available.

And beginners won't know to ask about it. The incorrect option is all they know. The solution, of course, is better tools. ...and tutorials. There is no excuse as a documentation/tutorial author to demonstrate values injected into SQL strings in examples.

And, once again, there is NO excuse for building a network-aware technology that allows for setting variables from the URI query string. None. Even PHP's predecessors had better sense. It speaks volumes that after it was exposed as the security nightmare that it was, it was simply disabled as opposed to removing it outright. Why? Because it would break existing apps? Guess what? Apps that blindly allow end-user manipulation of variables are already broken.

The correct decision is fixing the flaw, not merely disabling the flaw by default. It should not be an option. If developer need that functionality for some corner-case reason, they should be knowledgeable enough to write the functionality themselves.

That, in a nutshell, is why I don't like PHP. It doesn't present good decision and allow people to make bad decisions, it presents bad decisions by default unless developers write the better behavior themselves -- better decisions that newbies, by definition, will not make.

Re:People vs. Technology (1)

stonecypher (118140) | more than 8 years ago | (#13318484)

Except that for years PHP and MySQL, tools marketed to beginners, didn't have the "correct" option available.

And beginners won't know to ask about it.


Eh. There's no way to give amateur developers the ability to produce professional code. If you want a secure system, don't hire a novice. It's not PHP's fault that a developer is a failure, to be quite blunt.

And, once again, there is NO excuse for building a network-aware technology that allows for setting variables from the URI query string. None. Even PHP's predecessors had better sense.

Actually, in PHP and PHP/FI days, that was common practice, and in some languages still is.

Re:People vs. Technology (2, Insightful)

ttfkam (37064) | more than 8 years ago | (#13318639)

Actually, in PHP and PHP/FI days, that was common practice, and in some languages still is.
I meant predecessors like Perl. As for common practice, not in any circles I've been exposed to. Even C tutorials from twenty years ago for command line apps preach distrust and validation of user input as standard procedure.

In the modern internet, the practice is unforgivable.

Re:People vs. Technology (1)

stonecypher (118140) | more than 8 years ago | (#13319076)

Oh, I'm certainly not defending the problem; you're quite right to suggest what an issue it is. I just tend to believe that the problem comes from the programmers, rather than the language.

Re:Ruby is a passing fad, a PhD's toy (1)

ibbey (27873) | more than 8 years ago | (#13318095)

There's a reason that Ruby programmers are such annoying cheerleaders-- the language is genuinely fun. Add to that the facts that you get much more done in much less time and your code is inherently less buggy, and you begin to see the reason for our enthusiasm. I challenge you to pick up Programming Ruby (or the new Agile Web Development in Rails). You may not decide to switch but you'll understand why we have.

The need to learn a new language is certainly a reasonable concern. Fortunately Ruby has a reasonably shallow learning curve. Coupled with the boost in productivity you'll get from using Rails, you will likely make up the downtime lost to learning on your first sizeable job.

Re:Ruby is a passing fad, a PhD's toy (1)

CatGrep (707480) | more than 8 years ago | (#13318843)

Yup, dag nab it! Them Ruby college boys keep come'n round here'n tell'n me that I need to learn their language, but I'll stick with my COBOL thank ya very much!

Re:Ruby is a passing fad, a PhD's toy (1)

Colonel Panic (15235) | more than 8 years ago | (#13319255)

Yup, it's way too hard for you. Best stick with PHP.

(while the rest of us program rings around you in languages like Ruby, Python and Lisp)

Re:Learn Ruby (1)

Bitsy Boffin (110334) | more than 8 years ago | (#13319125)

THANK YOU MR COWARD!

That is the most coherent list of the deficiences in PHP compared to other more well designed OO languages that I have seen. Most people just say "oh PHP is rubbish compared to a real OO language" but they never bother to say exactly why they feel that way.

nobody can deny that PHP is a bit of a dogs breakfast when it comes to "design", it's had a very evolutionary and "throw everything in" history (a bajillion functions always there, no modularity), but the fact is that it works, it's not a great language but it does get the job done, and it is very popular because of the huge following and number of open source applications it has (bit of a catch-22 there).

What I find interesting is that Ruby has really started to take off, in the face of more established, and equally well designed languages such as Python (indented blocks not withstanding...ugh). One wonders if it's just the "ooh, new ad shiny" factor, or if Ruby is gonna be a force to be reckoned with for the long haul.

Certainly interesting times ahead, especially with PHP6 development beginning which sounds like it's just gonna bite the bullet and break compatability in order to fix the stupidities.

Can this discussion ever happen without... (0)

Anonymous Coward | more than 8 years ago | (#13320893)

...the idiotic "OMG PHP is teh sux0rz [ruby|perl|ada95|..]==l33t". Let's just assume that we all know some people hold that opinion (about any language), and if you promise to keep quiet, the rest of us will acknowledge what a strain it is on you.

Yes, PHP has some flaws; so do all other languages. There are many metrics by which to judge a language, and you will never find two programmers able to weight them all the same. One metric might be adoption (and thereby the amount of functionality implemented); PHP ain't doing too badly in that respect. If it serves your needs for a given project, its *good enough*.

At least you gave some actual reasons, which is why I'm responding to you and not the thousands of other /. trolls this article is sure to bring out of the shadows.

* poor metaprogramming
This is a valid argument; however, there are a lot of applications where this just doesn't come up. Especially in the realm of web/cgi programming - if you're using anonymous functions, are you *sure* you're not just complicating things unnecessarily? (I've used them, in PHP, but only after serious deliberation..) Something other than a string would certainly feel less icky, granted, but one of PHP's strong points is a fairly simple and consistent syntax.

* global variables for session, cookies, etc.
omg, no main() function! Seriously.. I don't get it. Surely you are extracting the information you need from these at initialization and passing them thereafter?

* no way to refactor object fields. Yes you can use "__get/__set" but those "fake" fields don't work in every place a regular field works. WTF? In Ruby everything is a method, there are no fields, refactoring is a breeze.
__get/__set don't work in some cases to prevent possibly infinite recursion. I don't agree with this decision personally (protecting novice programmers at the expense of clean functionality), but its perfectly explainable, and solvable: call __get/__set explicitly inside the class, or anywhere that __get/__set is already in the stack. In any case, "everything is a method, there are no fields" doesn't sound like the only (or best) way to solve that "problem".

* No "mixins".. I can't write a method and then stick it into multiple classes. Not even with include().
Wrong. There have been several ways to cope with this in the time I've been using PHP. Aggregate functions, the Classkit extension, and now Runkit. (I'd prefer multiple inheritance to any of these, but they *do* solve the problem you describe.)

* Exposes variables vs. variable references. I thought PHP5 would get rid of "&" forever. I was wrong.
Er.. are you saying that the distinction is unnecessary? I'm not sure I understand. FWIW, the new object model eliminates the *majority* of use cases for the &; you still need references to explicitly pass (or return) a primitive, however.

I'm not trying to say PHP is perfect; I have my own list of gripes that I won't bother to go into. But it is good enough for a lot of applications. And language flames are just stupid. Choose a language you're comfortable with that can do the job. If you spend half your time second-guessing yourself over syntax, then using the slightly l33ter language has not paid off.

Delphi (0, Offtopic)

baadger (764884) | more than 8 years ago | (#13316637)

Did anyone else click the PRADO link see TForm, TButton and TTextbox and just say to themselves "Delphi programmer"?

I don't have a point. I just thought it was kinda neat.

Re:Delphi (1)

namekuseijin (604504) | more than 8 years ago | (#13316730)

yep, definetely a Borland brew.

Oy vey... (1)

Phleg (523632) | more than 8 years ago | (#13316764)

Ruby on Rails looks pretty cool, but frankly, I don't want to learn a new language.

What a silly perspective. I've never met a carpenter who knew how to use a hammer, but refused to learn screwdrivers, miter saws, and a lathe.

you win the horrible anaolgy of the day contest (3, Insightful)

geoffspear (692508) | more than 8 years ago | (#13316851)

I've never come across a carpenter who could drive nails, cut boards, and turn table legs with a hammer.

Hammer + tool (1)

loadquo (659316) | more than 8 years ago | (#13317019)

You could theoretically cut boards and craft table legs with a hammer + chisel. Doesn't mean they would be nice or pretty, but it is theoretically possible

Re:you win the horrible anaolgy of the day contest (1)

bluGill (862) | more than 8 years ago | (#13321255)

Really? Come visit some time, I will introduce you do a few.

Carpenters do not use hammers for driving nails much anymore, their are tools that do the job faster. Take a hammer and beat a chunk of wood with the claw and you can get an acceptable dado. Not as good as what a chisel/dado saw/router can do, but acceptable for rough work, and you may not have the other tools.

I've never done it, but a sharp claw ought to be able to turn a table leg just like real lathe tools. Mind it would be very dangerous, but when you just need to get the job done and you don't have the tools...

Come to think of it, first year carpenters use their hammer more as a shovel than anything else. (how else to make a ladder sit level on a hillside?)

But none of this changes the fact there there are better tools for those jobs. If you need something quick, use the tool you have. If you spend a lot of time doing something, you should get the right tool for the job. Thus if you need a web page quick, and already know php, then use php. (though why you would know php I'm not sure...) If you are going to design a website, it is worth your while to get something better. Either Ruby or Python is better than php.

Zelots. (1, Insightful)

Saeed al-Sahaf (665390) | more than 8 years ago | (#13316796)

Why is it that there is very little PHP discussion here, and this story has been taken over by the RoR zelots? Seems like that's par here at Slashdot.

Re:Zelots. (0)

Anonymous Coward | more than 8 years ago | (#13316809)

Because PHP sucks so much?

Re:Zelots. (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#13316828)

PHP programmers aren't online as much. They're out spending the money they've made because they finished their app a long time ago. Java and RoR zealots have time to peruse Slashdot while they try to find jobs and figure out why their apps are incompatible with various systems.

Re:Zelots. (2, Insightful)

aminorex (141494) | more than 8 years ago | (#13317310)

When a large number of intelligent people with practical experience conclude that a given tool is superior to another given tool, it's a good idea to check it out.

PHP is very accessible, and that's a great strength. But any time you start talking about "frameworks", you're well outside the user base that is best served by accessible.

Having said that, there are a lot of big PHP projects doing good service in the real world. It might not be the place to start new development, but integrating it into new development is going to be important for years to come. I'd be particularly interested to hear of good experiences integrating existing PHP apps with RoR development.
 

Frameworks for PHP, not that hot. (5, Interesting)

Elamaton (771817) | more than 8 years ago | (#13316842)

But with PHP5's, Object Oriented features, a standard framework might emerge.

Indeed, one might. So far, not looking so good on that front. All the frameworks I've encountered so far have seemed cumbersome or tedious somehow (I glanced at Prado just now; the advantages of their approach aren't readily apparent, I'd say. The demos are unimpressive, using some god-awful javascript: pseudo protocol links for updates and deletes, which really puts the internals of the framework into serious question).

It seems that PHP is bereft of any real, exciting developments on the framework front. There are a lot of frameworks, but I guess the reason why none stand out like Rails does with Ruby is simply that none are good enough, providing no significant added value.

You have to ask yourself: why a PHP framework? What such significant advantages would one of the existing frameworks provide that learning its ins and outs wouldn't be a waste of time and energy? If you're looking to automate some of the drudgework of form processing, for example, I suggest you roll a minimalist "frameworklet" - or simply "component" - yourself (if that's plausible in your situation) for that specific purpose, making it generic enough to be reusable, but not so generic that you end up fitting your projects to the tools instead of vice versa, which often happens with frameworks.

I've found minimalism to work really well with PHP. Frameworks that try to be all things to all people mostly end up being more trouble than they're worth. It may very well be faster and more efficient (and more fun) to code a small component for a specific purpose than trying to work with an existing solution. Your own solution will be tailored to fit your application and will work as your mind wants it to work, not the way the framework creator sees fit for himself.

It's a Unixy approach, I think: combine small tools in inventive ways to accomplish even the largest tasks. Of course, with tools of your own creation, you wouldn't have to deal with inconsistent APIs, a thousand syntaxes and wholly different philosophies across these tools. Write a custom session handler here, a generic input validator there... Even if you create these tools for a specific project, you will most likely find yourself reusing them in future projects, too, with possible minor customizations.

An example: when I first wanted a lightweight way of separating the business logic from the display logic for a project, I coded a single class that did the template stuff, using standard PHP with no additional burdens. Smarty etc. were readily available options, but PHP is already a templating language, and separate template engines would just have added excess bloat to the mix. My solution wasn't as feature-rich, of course, but it did exactly what it had to in the parameters set by the project specs. I've successfully and rapidly reused the code (and more importantly, the overall technique) in several later projects. Besides templating, I've had similar good experiences with an extensible input validation system I cooked up once, adjusting and refining it to later projects.

The way I see it is this: languages like Ruby and Python benefit from good web frameworks, since they're non-web-specific languages, and these frameworks make their use a lot more convenient in web programming. PHP, on the other hand, is very much a web programming language at heart. Ignore the "PHP suxx0rz!" trolls, it is a good tool for that purpose. (Even though it's capable of more, it's rarely - if ever - the best choice in those circumstances.) The best a framework would do with PHP is addressing clear shortcomings of the language in some way, but you don't really need a full-fledged framework to fight these annoyances. I find the "invented here" mini-component approach superior.

In short, I don't see a framework "enabling" significantly better ways to do web programming in PHP, unlike with Ruby or Python. For PHP, a framework will probably be more trouble than it's worth for any given project.

Personally, I've been coding PHP for about five years now, but I'm looking to broaden my horizons a bit, having grown tired of PHP. You mentioned Ruby on Rails, and another poster mentioned Python and Django. I'd check out both if I were you. I know you said you didn't want to learn another language, but I urge you to reconsider.

Who knows, you just might be inspired by the approaches Rails and/or Django take, find a way to transfer some of that knowledge to PHP programming and become a better PHP programmer in the process, with an extended set of tools, both mental and in code.

So now, think about what it is that you want to do. Would it be too much trouble to code your own stuff to deal with it? Is it conceivable that you'd be halfway finished using your own solution by the time you grasp a framework well enough to be productive with it? Is the initial investment in learning a framework going to pay off substantially enough for it to beat writing your own set of tools in comparison?

Best of luck, whatever you decide.

Re:Frameworks for PHP, not that hot. (3, Insightful)

Qa1 (592969) | more than 8 years ago | (#13319963)


The way I see it is this: languages like Ruby and Python benefit from good web frameworks, since they're non-web-specific languages, and these frameworks make their use a lot more convenient in web programming. PHP, on the other hand, is very much a web programming language at heart.

I heartily disagree.

First of all, can you explain what's a good "web-specific-language"? As both a web-programmer and a general-purpose programmer, I'd say there's nothing really "web-specific" about a core language. You do need some good library support for stuff like handling web protocols (HTTP, url parsing, etc.), and both Python and Ruby (and many more) have that.

What's important in a core language in order to be suitable for web-programming is good string handling facilities. Which, when you look at it, is what "web-programming" is really all about: generation, manipulation, and occassionally parsing of strings.

I'm not sure how you can imply that Python and Ruby are not as good as PHP for web programming. You indicated that you're "looking to broaden my horizons a bit". So I guess you do know PHP well, but you don't really know Python or Ruby yet.

I've been a PHP programmer for years too. I worked in positions where it was just too problematic to switch. But eventually, I did, although it meant rewriting a lot of legacy code in a new langauge.

Why did I switch? Because I finally understood what I wrote in the above paragraph: that webprogramming is really all about generation, manipulation, and occassionally parsing of strings.

I've used Python a lot for general purpose programming, and I found myself over and over again unfavorably comparing PHP to Python when developing in PHP.

I would say to myself "o.k., now I need to get this substring from the incoming string, manipulate it a bit and plant it in the response page." And immediately a very short, concise and elegant solution Python would pop to my mind. But then I'd need to translate that elegant solution to some awkward PHP translation, and my mind would ache

To get the substring, I couldn't just do "substr = str[3:24].lower()" like I would do in Python. I had to use some godawful substr(str, 3, 24) function, and then run another function on the output, since PHP doesn't support the slice notation and treating of strings as objects that modern languages like Python and Ruby support as core feature.

Also, PHP's handling of regex (another important tool in the web-programmers toolbox) is coarse and awkward. Python's regex support is incomparably better, and Ruby's - even more so.

To sum up, I switched to Python from PHP4 since Python is, hands off, an incomparably better language for web-programming. And Ruby is even better than Python, which is why my current tool of choice is Ruby on Rails.

And while we're on the subject, why didn't PHP manage to create a framework as good as Rails, with all its huge advantage in user-base size?

That's because PHP isn't just an inferior language to Ruby in the web department (supposedly its home court) - its also generally a clunky programming language.

Writing a good web development framework is a general programming task. You need a good object system. PHP didn't even have a half-decent object system until release 5.0, and most of the world still uses PHP4. PHP doesn't have closures. It doesn't have elegant flow control mechanisms like Ruby has. It doesn't have any meta-programming facilities I'm aware of, while Ruby is the best meta-programming language I've used (with the possible exception of Lisp with its uber-macros).

So not only is PHP inferior to Python and Ruby for the simple tasks; for complex tasks, such writing a web-development-framework, the gap only widens. The result is that developing with a better language like Ruby, and on a superior platform like the RoR framework, is incomparably easier, faster, and more maintainable, even for the simple stuff PHP used to be good for.

In the past we had heavy-weight frameworks like Zope, which were designed especially for complex, large applications. The hidden assumption was that if you needed something simple, you already have a very popular alternative: PHP.

Current frameworks, like those you mentioned (Rails, Django) take a different, light-weight approach. They first of all take care of the fundamentals of the web-programmers work (parsing requests, managing sessions, allocating appropriate responses), making them trivial. Then they scale up. And I can attest that Rails scales up very well. So even for the simplest stuff I could do in 50 lines of PHP, I now just write a 5 liner using Rails macros, and I'm done.

With languages like Ruby and frameworks like Rails, why would any professional still use the archaic PHP?

Good question.

Which PHP App? (4, Funny)

ttfkam (37064) | more than 8 years ago | (#13316913)

Isn't that like asking what type of sauce you want on your spaghetti (code)?

I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.

Do be fair, PHP 5 looks pretty good -- or at least is a vast improvement. Unfortunately I can't say the same thing about the people who've coded in PHP up to this point. Even when PHP shows some growth, most PHP coders ignore it.

"Database abstraction? Why would anyone need that?"

"Namespaces? Why would anyone need that?"

"Design patterns? What are those?"

"Security? If it's a problem, we'll fix it later."

PHP: We'll be there for you if your development environment doesn't have enough side effects.

PHP: Because we know the money's in the maintenance contracts.

PHP: Because you obviously don't know any better.

PHP: We take security as seriously as Microsoft ten years ago.

PHP: Doing it fast is always better than doing it right.

PHP: Proving that if any idiot can write an e-commerce package, any idiot will.

PHP: Yet another great reason to make regular backups.

PHP: Fast, cheap, and robust. Two out of three ain't bad, right?

-----
I'm liking this meme. Anyone got any more?

Re:Which PHP App? (0)

Anonymous Coward | more than 8 years ago | (#13317034)

Bullshit.

I know someone modded you funny, but its not. Its just a propogation of the same stereotypes.

I moves away from ASP several years ago into PHP. I would have made the switch earlier, but I had the same preconceived notions that you have -- that it was a language for amatures. Before ASP, I did straight C CGIs as well as dabbling in perl and AppleScript (I'm not sure which was less up to the task at the time...I still can't stand Perl for anything more than shell scripting and never understood how it took off for the web...but some people are very capable programmers even with a crappy language).

But since the time I moved over to PHP, my programming has gotted a LOT better. I stopped reinventing the wheel each and everytime I had a problem.

Everything is class oriented now instead of using pseudoclasses under ASP (dictionary objects and other hacks...and yeah, I know asp.net can deal with these, but I switched at a time that this wasn't an option nor was the lock in).

For once, I have the same ability to program that I did back in the C(++) days of compiled CGI apps without having to do 10x the programming (the speed was nice once, especially if the server allowed for caching the app).

And I'm still only using PHP4...5? I haven't seen anything in 5 thats got be thinking of switching yet. All the problems you complain about are things that ANY language has...and should be addressed by the programmer. For instance, security and otherwise can be taken care of by turning off globals and making the app strict. This should be done on any production server (unfortunately, most kiddie programmers can't afford a production AND a development server and thus these are turned off by default).

Its a simple language to program in and thus you have a lot of people with bad practices. Restrict programming to something that needs a lot more theoretical knowledge and you won't have this problem...you will also make things more difficult for those of us that can deal with the theoretical details and now how to avoid the problems.

At this point, I'm at the risk of making this a rant just like yours so I'll stop. All I know is that many languages have advantages others don't have and they all have their disadvantages...I'm happy with the advantage that I can do almost anything I want in PHP if the disadvantage is that it attracts a lot of idiots. I'm intrigued by the programmers that work with RoR but the language doesn't appeal to me any more than the hardcore database guys that love coldfusion (I had a developer working for me that begged to use this language until I had a major project to do and let him hang himself on it...the database part worked right, but the whole application side of things was a bust...I never had to hear him beg for coldfusion again...not a bad language, it just didn't do what I need -- and I need a good general language that is middle of the road in features but can be extensible to do 99% of what I need...and thats php).

Ok, the rant didn't stop where I wanted it to...

Re:Which PHP App? (1, Flamebait)

ttfkam (37064) | more than 8 years ago | (#13317323)

I moves away from ASP several years ago into PHP.
Sounds conspicuously similar to "I was coding in Prolog when I discovered BASIC."

For very simple pages, pages that amount to slightly more code than a server-side include, PHP is a perfect fit. This is obvious because PHP was originally made to be a page-embedded version of Perl -- originally written in Perl. Back in the days of CGI scripts, mostly in Perl, when you only had a little bit of code and a lot of markup, PHP (and ASP, ColdFusion, etc.) were a breath of fresh air.

However...

Embedding logic in your presentation layer is a bad idea. It ties your code to how your presenting it. Want to change how your site looks? Gotta change code. Want to change from HTML tables to CSS? Looks like it'll be a fundamental rewrite.

This is the problem that PHP -- and most mod_perl-based frameworks for that matter, like Slashdot -- have. It's a write-once language that you simply pile more and more code on until it breaks. Then you start over again.
I would have made the switch earlier, but I had the same preconceived notions that you have -- that it was a language for amatures. Before ASP, I did straight C CGIs as well as dabbling in perl and AppleScript (I'm not sure which was less up to the task at the time...I still can't stand Perl for anything more than shell scripting and never understood how it took off for the web...but some people are very capable programmers even with a crappy language).
We do not have the same preconceptions. We are coming from completely different points of view.

You: PHP is just as valid a programming environment -- if not more so -- as ASP, JSP, ColdFusion, and all the others for writing logic in web pages.

Me: Writing logic in your presentation layer (your web pages) is a bad idea no matter what language you use.

See the difference?
But since the time I moved over to PHP, my programming has gotted a LOT better. I stopped reinventing the wheel each and everytime I had a problem.
Of course you have. Usually the more you do something, the better you get at it. But I'm not suggesting that you drop PHP for something like JSP. I'm suggesting that they both suck as web development models. PHP is simply the newest kid on the block to support this crappy development model.
Everything is class oriented now instead of using pseudoclasses under ASP (dictionary objects and other hacks...and yeah, I know asp.net can deal with these, but I switched at a time that this wasn't an option nor was the lock in).
But ASP had CreateObject to instantiate any scriptable COM object registered with the system. ASP was meant to be a logic linking framework, not the logic itself. In other words, the code that did the heavy lifting was not supposed to be the Visual Basic Script; it was supposed to be your COM objects -- written in a more powerful language.

People are writing the "heavy lifting" code in PHP. This design pattern is known as "Big Ball of Mud." You may be getting better at giving it form, but it's still a ball of mud.
For once, I have the same ability to program that I did back in the C(++) days of compiled CGI apps without having to do 10x the programming (the speed was nice once, especially if the server allowed for caching the app).
So in other words, you are doing today what you did ten years ago, only faster -- neither cleaner nor more secure.

Incidentally, speeds for process invocation and forking on many platforms has increased dramatically. Those old CGI scripts in C and C++ would run faster even on the same hardware, eg. running the same code on Linux 2.0.x versus 2.6.x.
And I'm still only using PHP4...5? I haven't seen anything in 5 thats got be thinking of switching yet. All the problems you complain about are things that ANY language has...and should be addressed by the programmer. For instance, security and otherwise can be taken care of by turning off globals and making the app strict. This should be done on any production server (unfortunately, most kiddie programmers can't afford a production AND a development server and thus these are turned off by default).
No, globals and other lameness should not have been there in the first place. Period. End of sentence. By the time PHP was first being developed, most folks had learned that input from the internet could not be trusted. Setting variables from query strings? My God man! Are you nuts!?

SQL injection attacks are another case. How long did it take for prepared statements to make it into 3rd-party libraries let alone the language proper? C'mon, be honest. How often have you written code like the following:
mysql_query('SELECT foo FROM bar WHERE id = $id')
Oh wait! I almost forgot. We can't forget those quotes around the integral value in case the user passes a string. (You know why having your data layer silently accept string values in numeric fields is a bad idea, right?)
mysql_query('SELECT foo FROM bar WHERE id = \'$id\'')
Namespaces: making sure that a programming team doesn't clobber each other's function definitions. This is not a problem, as you state, that all other widely-used programming languages have. In fact, other than C and PHP, NONE of them do. No, instead of fixing this gaping hole in the language, PHP coders simply added prefixes.

mysql_connect(...)
ora_connect(...)
mysql_query(...)
ora_query(...)

This is one of the main reasons that database abstraction took so long to appear in the PHP community. Unfortunately there were so many newbie coders that didn't know any better and only six months prior even learned how to write HTML, very few even realized it and other defects could be a problem.
Its a simple language to program in and thus you have a lot of people with bad practices. Restrict programming to something that needs a lot more theoretical knowledge and you won't have this problem...you will also make things more difficult for those of us that can deal with the theoretical details and now how to avoid the problems.
I'm going to analogize your point to building bridges. A simple bridge to cover a six-foot hole in the road is fairly simple to solve: just get a seven- or eight-foot piece of metal, and lay it down. Problem solved and no advanced knowledge or planning necessary. However, building a bridge that spans hundreds of feet and must support regular traffic requires more than just some simple metal slabs.

Some problems are hard; they require a certain level of education and planning.

For a better model -- whether you like Java or not, it doesn't matter -- take a look at Apache Cocoon [apache.org] . Take the model and write it in Perl, C, C++, LISP, or whatever, it's a far better model than what PHP is designed for.

Take special notice of the sitemap and the flow engine. Once you see that the URI should have nothing to do with the language in use... Once you how to truly separate logic from presentation... Once you understand the power of continuations for server-side applications (any web-based form processing would qualify) and how the current method is just plain idiotic, you will understand my rant.

It isn't that I think PHP coders fail to solve some problems better than they can with other technologies. It's that PHP coders in general don't realize that they're often solving the wrong problems. Good design is not an afterthought. Security is designed in, not patched.

Contrary to your assumptions, I am not making fun of it because of its reputation. I'm making fun of it because I have actually developed professionally with it.

Big.

Ball.

Mud.

Re:Which PHP App? (2, Interesting)

tom's a-cold (253195) | more than 8 years ago | (#13317637)

Me: Writing logic in your presentation layer (your web pages) is a bad idea no matter what language you use.
While I agree with this, I think that, for trivial apps, it's not such a big deal to mix the presentation layer and the logic. The problem I have with PHP is that some over-enthusiastic developers have tried to extend its use to writing enterprise applications. That's not what it was designed for, though feature-creep has moved it a little in that direction. There's not much wrong with it for small-scale throwaway web apps, but beyond a certain point, it just isn't the right tool anymore.

I saw some earlier posts that were sneering at language features that "95% of us don't use." Well, that might become what keeps you from being one of the 5% who will still be programming five years from now. Though I've met a few diehards who were writing spaghetti ten years ago and still are.
And, just to be very clear, I'm not a language zealot. I have coded in, and led teams who coded in, C, C++, Java, Smalltalk, Lisp (various flavors), Perl, Python, Ruby and various app development frameworks. Despite my having used other languages, and the likelihood I will continue to do so, I understand what drove the additional features in Python and Ruby and enjoy the added productivity that they enable. PHP was meant more to "get the job done, screw the fancy stuff" and the simplistic feature set has become a limitation as its usage has grown.

Re:Which PHP App? (1)

Bitsy Boffin (110334) | more than 8 years ago | (#13319154)

I didn't read your whole post, becaue I'm inherently lazy, but this statement...

Embedding logic in your presentation layer is a bad idea. It ties your code to how your presenting it. Want to change how your site looks? Gotta change code. Want to change from HTML tables to CSS? Looks like it'll be a fundamental rewrite.

This is the problem that PHP -- and most mod_perl-based frameworks for that matter, like Slashdot -- have. It's a write-once language that you simply pile more and more code on until it breaks. Then you start over again.


I agree that embedding business logic in your html is a bad idea, but PHP IS a templating language. I see no problem with
<?php echo $somevar ?>
rather than your typical template language's
{somevar}
or
<?php foreach($record in $records) { ?> <tr>....</tr> <?php } ?>
instead of
{loop $records} <tr>...</tr> {/loop}
(or whatever your chosen template language syntax for looping is).

Separate the _business_logic_ from the _display_logic_, and you'l be just fine and write maintainable views in PHP.

Re:Which PHP App? (0)

Anonymous Coward | more than 8 years ago | (#13321350)

Again, you really don't know what you are talking about.

You are confusing PHP with any language that a novice might write in.

Abstracting logic with presentation? Only an idiot does this. This is one of the great things about the language -- you can mix the two if you are a bad programmer, and really bad programmers don't even know how to think past the fact that its possible to do this -- and it doesn't care.

Seriously -- design with a decent OO oriented structure and you will not have any worries. It took me all of a day to change my last PHP app to utilizing CSS. It would have taken me much longer if we were taking static web pages. The ASP running on the same server (from a much earlier project that we haven't been able to get back and rewrite) took a bit longer because there was a LOT of mixing presentation with logic. Again, these things happen because of experience. Working in ASP, when I have to, these problems don't happen today.

And as for: mysql_query('SELECT foo FROM bar WHERE id = $id')

Seriously? You'd pass a variable into a SQL command? Without doing any preprocessing? You'd even think that this was possible? Until you just posted this, I completely forgot some idiots think this way.

Me -- I don't want *ANY* programming language editing the variable I'm throwing at a specific function. If I ask it to throw $id='1; DELETE * FROM BAR;' into the SQL Query, I don't want the application editing my query.

Then again, thats what stored proceedures with specific rights given to each are designed for. My programming language worries about the security of the program and my sql app worries about the security of the SQL statements.

But *ANYONE* even thinking in such a way that they'd allow their SQL statement to pass variables along like this is an idiot. Anyone that thinks a programming language should be holding your dick when you are programming statements like this is, too, and idiot.

As for globals and 'other lameness' -- again, you show how little you actually know about programming. I guess the whole idea of Constants is also bad because someone might get into one of your files and edit it where it effects the entire program. And that you do nothing to make certain that these variables are nondestructive in the context of your application simple because they say they are what they say they are. Thats just plain bad programming. Of course you can't fucking trust whats posted to you...but at the same time, there isn't anything wrong with accepting them and automatically reproces them yourself. Thats the FIRST thing that happens with any query data that comes into my system -- I save the original query string to another location intact and then replace the old with safe strings. Again, this is something the application developer should be doing NOT THE LANGUAGE. I have reasons I keep the unaltered strings intact -- I may need them exactly as they say they are.

As for 'Big. Ball. Mud.' Congrats. You learned a new phrase and are trying to use it correctly. You have failed, but you get a gold star for the effort. You cannot even think outside of your little world and understand how this can be done.

I miss the days when I was a know it all programmer that thought I was right and everyone else was wrong. Now these days, I realize the only people I know more than are the dumb fucks that post to Slashdot professing to be experts when they are just parroting an opinion they read on some website. Thanks for reminding me why I grew up.

A Short History of Web Apps (1)

ttfkam (37064) | more than 8 years ago | (#13317503)

In the beginning, you had files and web servers. Then people starting writing extensions to the web servers and the dynamic web was born.

But the problems with patching your web server for even the slightest dynamism were immediately obvious even in the early days of "a patchy server". So CGI (Common Gateway Interface) was born and Perl rose up as the dominant web language. Process creation overhead became an issue as the web took off so techniques for mitigating this were put in like mod_perl, servlets, etc., but overall the process stayed the same.

People started learning, slowly, that the internet wasn't a nice place. Maliciously altering query string variables to affect server processing or inject SQL code started to become commonplace. Libraries that urldecoded query strings and database libraries that used prepared statements to prevent (basically eliminate) SQL injection attacks made the rounds.

While an improvement over what came before and most definitely useful, embedding markup was an absolute pain. All sorts of hacks rose up to programmatically write markup. But then a lot of people noticed at the same time that a lot of their dynamic pages were mostly static markup with only a token amount of logic. Thus the age of ASP, PHP, JSP, ColdFusion, et al. was born, and it was cool runnings for a while. If you needed a lot of logic, you wrote code with a markup generation library. If you only needed a little logic, you wrote a markup file with code markers for logic.

Things started going south when people with no programming experience started learning from those ASP, PHP, and JSP examples. They gleefully added huge tracts of code in these files, giving new life to a much maligned design pattern known as "Big Ball of Mud". Soon everyone starting getting stuck in the ever-growing balls of mud. Simplify! Encapsulate! Componentize!

We'll just add new markup. We'll call them "tag libraries" and put all the code snippets into these markup fragments. Brilliant! Now the people who don't know how to program can just write markup and coders can write stuff further up the chain.

Further adding insult to injury, PHP completely ignored the security lessons of the preceding years and allowed arbitrary variables to be set from the browser URL and completely ignored not only database abstraction facilities in the language in which it was originally written, Perl and it's DBI, but the entire concept of a prepared database statement.

JSP and its ilk were born just before this point, tag libraries and embedded Java in all their splendor, enforcing markup well-formedness and driving popular usage.

People still wrote logic in their markup though. And even the tag libraries became more and more monstrous. A tag library for databases. A tag library for data formatting. A tag library to make more tags. A tag library to perform backend workflow. A tag library to do the laundry and wash the dishes.

Meanwhile, academic gadflies coined the acronym MVC (Model-View-Controller) and starting going on about something called SoC (Separation of Concerns). Everything started going gonzo at that point.

HTML was no longer supposed to have styling info; that is now CSS's job. Our data repositories may change -- and may or may not be relational databases anymore. Hard-coding database connection strings, table names and column names is frowned upon.

URIs were also full of .asp, .php, .pl, and other extensions that didn't describe the content returned, but how the content was generated. Switching or upgrading technologies often meant creating large numbers of redirections -- commonly with the king of web voodoo, mod_rewrite -- at best, breaking links on your and other sites at worst (and more likely).

Enter the sitemap. Have the framework handle the URI space. Now your site can become technology-agnostic. As an added benefit, those framework authors also added processing pipelines where a given URI may pass content through multiple filters or transformers. The Apache web server added rudimentary support for this concept of filtering in its 2.0 version. The next version will incorporate even more robust and flexible permutations of this idea. (It's a shame it's saddled with such a piss-poor configuration file syntax.)

Then a brilliant individual thought about how nice it would be to have continuations in web development. Here we have logic in a separate file that generated data structures for display and formatting by the templating language. No more passing variables to and fro for multi-page web forms and wizards.

I, for one, am excited to see where the future will take us. But one thing is clear, the future is not coming from current PHP incarnations. It's only trying to make things easier by looking backward into the past.

Re:Which PHP App? (1)

Mr. Slippery (47854) | more than 8 years ago | (#13317226)

I have yet to see a PHP app -- especially one that also used MySQL -- that used a design pattern other than "Big Ball of Mud" most often.

You can remove the PHP qualifier from that statement and it's just as true. I've seen just as much good PHP code as good code in any other language - i.e., precious little.

Re:Which PHP App? (1)

ttfkam (37064) | more than 8 years ago | (#13317580)

Fair enough. :)

Re:Which PHP App? (0)

Anonymous Coward | more than 8 years ago | (#13317709)

Agreed. Just like the developers of PHP think that not including legacy VB/ASP's "option explicit" or Perl's strict mode is a good design choice.

Re:Which PHP App? (1)

JonasH (183422) | more than 8 years ago | (#13318268)

PHP will spew a notice if you use an unitialized variable. Whether or not that's good enough is debatable, but it's better than nothing at least.

Of course, notices aren't shown by default (presumably because it'd wreck havoc on most pieces of php code) so most people won't know. First thing I do to my php.ini is to set error_reporting to E_ALL (default is E_ALL & ~E_NOTICE it seems).

I know which one (0)

Anonymous Coward | more than 8 years ago | (#13316916)

Use that one that makes it dead-simple for some asshole to come and hack your web site (c.f. avrfreaks.net two weeks ago). That way I will clean up in the consulting fees telling you why you shouldn't use PHP.

Does PHP5 suffer from excessive RAM usage? (1)

CyricZ (887944) | more than 8 years ago | (#13316933)

I read a post a few days back regarding PHP5's supposed excessive use of memory:

http://books.slashdot.org/comments.pl?sid=158685&c id=13297391 [slashdot.org]

Now, I have been contemplating the use of PHP5 for various webapps, but after reading that I am unsure about whether or not I should use it. Mind you I do not want to invest large sums of money into an accelerator, which appears to be necessary if reasonable server memory usage is a goal.

Does PHP5 indeed suffer from excessive memory consumption, and if so, can it be easily remedied? Considering I have a low-end server hosting several fairly busy personal sites, minimal memory usage is extremely important.

I use... (1)

Karaman (873136) | more than 8 years ago | (#13316935)

gtk.php.net

version 2 will work with gtk 2.x, which is great!

It is not much of a thing, but will be ok!

eGroupWare, of course! (3, Informative)

mangu (126918) | more than 8 years ago | (#13316959)

I was assigned a task that would seem to be more or less the dream of any programmer: develop a QA management system (ISO9001 compliant, of course) for the whole company. Choose freely how you want to do it.


After searching all over for several weeks, I chose eGroupWare [sourceforge.net] . Their "etemplates" framework settled the issue for me.

Re:eGroupWare, of course! (3, Funny)

Seumas (6865) | more than 8 years ago | (#13318493)

I was assigned a task that would seem to be more or less the dream of any programmer:develop a QA management system (ISO9001 compliant, of course) for the whole company.

This completely explodified my sarcasmification detector . . .

Frameworks create as many problems as they solve (0)

Anonymous Coward | more than 8 years ago | (#13317142)

Creating my own framework was one of the first things I did in PHP, it's currently on it's 4th incarnation since it went live in 2001 and powers several commercial sites. The final revision was a possibly premature conversion to PHP5 that I begun last October.

The majority of web frameworks I have looked at consist of wrapper code to instantiate classes and other pointless indirections. It's as if somewhere along the way the authors begin writing code for the sake of it, constructing these hugely complex systems that offer no real world benefit over writing a simple procedural script. For example, creating classes to produce html elements that require more work to create than just hand typing the html is a pointless waste of time.

PHP really isn't the greatest language to write anything but the simplest of frameworks in and the performance of the current (PHP5) engine is terrible (APC still doesn't support the new object model). PHP6 will essentially be PHP5.1 + unicode which is the deciding factor for me... I'm moving on from PHP and away from web frameworks, although I will continue to laugh at the anal buzzwords used by their proponents to justify them.

I'm considering rewriting our webapps in ruby. I'm also about ready to punch the next person who mentions "rubyonrails" in my vacinity.

Re:Frameworks create as many problems as they solv (0)

Anonymous Coward | more than 8 years ago | (#13320293)

PHP6 will essentially be PHP5.1 + unicode which is the deciding factor for me..


What? [php.net]

Have your cake... (1)

Hallow (2706) | more than 8 years ago | (#13318757)

Oh, uh, yeah, how about cake [cakephp.org] ? It's a rails knockoff for php.

frameworks? no i18n, no custom auth, ... (2, Insightful)

HTD (568757) | more than 8 years ago | (#13319964)

Almost all the frameworks, no matter which language they are written in, don't provide the basics for a real world application. What about i18n? I have yet to see a framework where the template system AND the application supports translation of messages.

Customize Authentication? There are more complex apps that don't just require username+password to login (e.g. logon to database - username+password+database depending on the database you may have access or not). Also users may be in many groups, each group having different rights, even each user could have different rights - where the next isssue comes up.

Only few socalled frameworks have rights-management. There are actions that should be restricted to qualified users, like editing customer-accounts, adding new co-workers. There are things that should be displayed only to certain users. Think of current items in-stock of an online-shop. You probably want to show the shops co-workers the real in-stock amount and some info when the next delivery of that stuff is coming and the customers would see in-stock minus 10% and no info on the upcoming delivery - from the same template, only difference is the rights the user has.

These are just 3 examples of missing functionality that keep me from even considering any of those "frameworks".

Re:frameworks? no i18n, no custom auth, ... (0)

Anonymous Coward | more than 8 years ago | (#13321360)

Doesn't the Horde project allow for all of the things you mentioned?

php.MVC (1)

slopedome (864529) | more than 8 years ago | (#13320695)

Try this:
http://www.phpmvc.net/ [phpmvc.net]

It's in beta, but I think a good MVC framework is all PHP needs to stop looking like such spaghetti. In defense of the Ruby zealots: I've haven't learned Ruby yet, but it's exactly the futuristic *REAL* object-oriented language that's going to propel us into the future. PHP is very old-school in the way code is written -- it DOES encourage spaghetti coding -- and for that I think it deserves to be phased out.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...