INSERT INTO `ratings`
(`rating`, `ip`)
VALUES ('{$rating}', '{$_SERVER['REMOTE_ADDR']}')
In fairness these aren't your typical "straight out of $_GET" vulnerabilities, but they impart a lax attitude towards security. For example, in the latter example above, $rating is escaped just prior to its use in that query, but $_SERVER['REMOTE_ADDR'] isn't. In the former, there is no indication whatsoever of where the variable $articlesPerPage has come from so it's impossible to tell.
The notion that some variables are "safe enough" that they don't need escaping is naive. $_SERVER['REMOTE_ADDR'] is a global variable that any other code anywhere in the script can write to. While you can't get owned immediately after putting that code live, it is still a tiny little SQL injection vulnerability waiting behind the scenes for an attacker to chain it together with some other similarly minor flaw and break in.
To this day I still come across PHP code that is vulnerable to serious, immediate SQL injection vulnerabilities and it isn't always old code. I'm not so sure that the PHP community is so quick in learning from its mistakes.
Can you tell me which language is impervious to SQL vulnerabilities? Is there some magic language out there that cleans all external input for you? Pick a language, any language, and you will just about always find that GET and POST variables aren't cleaned for you and rightly so! The language should be a tool to let you do whatever you want and leave it up to the programmer to clean input. Now, if you want to talk about frameworks that's a different story.
You picked one site with one tutorial and based off that have basically proclaimed PHP to be an insecure language. For every tutorial that skips over security or has some mistake or vulnerability there are others out there that don't. The one you chose is in PHP but you can find tutorials in any language with the same flaws.
We all get it by now. PHP is lame and it's cool to bash it. It has a history of being crappy. Fine, we know. But PHP in past couple of years has begun to address those flaws and has come a long way. Now that it's starting to get better people seem to want to cheer for it to fail. No matter how uncool it is it's still incredibly popular even among people here on HN. It's just that they don't like to talk about it out loud because of the stigma it now has among the language snobs.
I mean, come on man. Was this really in fairness or just another cheap and easy shot. An opportunity to pile on.
And to address the quote you mention... the web may still have a lot of those old and awful tutorials but that doesn't mean the community hasn't learned. More recent tutorials and information you find online is much better and the community is far more cognizant of PHPs vulnerabilities and are now using best practices far more frequently. It's always fun to bash PHP but let's just give credit where credit is due. It has taken enough steps in the right direction for it to be worthy of people taking notice.
EDIT:
Also, the tutorial site you linked to is actually quite good. Tutorials are tutorials, not technical manuals. So when you want to show someone how to, for example, take GET or POST input and manipulate it somehow you want to focus on that and not explain every little thing like all the ways your GET or POST array can kill you via XSS or SQL injection. You might mention in passing that you'd better clean your input but unless the article is about sanitizing and escaping inputs itself I don't see why it has an obligation to go into that much depth.
Sorry about this grumbling old man comment. I was bored and tired and I was meaning to delete it, but it has replies and stuff now so it seems a bit too sneaky. Something about HN brings out the angry jerk in me sometimes. My bad, though.
> To this day I still come across PHP code that is vulnerable to serious, immediate SQL injection vulnerabilities and it isn't always old code. I'm not so sure that the PHP community is so quick in learning from its mistakes.
Do you not find that with other languages as well? I do.
It's a bit harsh judging the entire PHP community by the presence of yet another crap tutorial on the internet. You can bet that the people who go to PHP conferences etc (and who comprise the core PHP "community") wouldn't write example code like that.
Judging the whole of PHP and its community on the basis of one very poor tutorial is very unfair to PHP and its community. There is a lot of good PHP code out there and successful applications which don't/rarely suffer these kind of exploits (at least no more so than other apps written in other languages).
I'm fairly sure crap tutorials and SQL injections are possible in every language.
Part of this problem is that a good part of the community is amateur/hobbyist, they won't learn anything.
Some people in the PHP community love to think that PHP is used like Java, but for most of the amateurs it's a "cut and paste what works" workflow.
HipHop making an alternative VM. I see that as the biggest change in PHP in 2012. Sure HipHop has a translator/compiler (HPHPc) for a while now, but now they have a full fledged VM with a JIT (HHVM). Maybe next year we can get a sane extension framework and make a less memory intensive construct then zvals.
HipHop is incredibly promising, though it basically wasn't used outside Facebook in 2012. I hope it will get more adoption in 2013, which (as well as the performance benefits) should make PHP play a bit better with the Heroku-style services. (Since it makes a full-on web server unnecessary.)
What still bothers me about PHP is the split personality between the old parts (global functions, bad defaults), and the newer OO parts. I want a proper string object that is natively unicode. I want methods on my primitives like in javascript.
I've done some experimenting with meta-programming that into PHP, but it should really be done at the language level.
I too have been doing some work with meta-programming in PHP (specifically working on a typed language that cross-compiles). PHP isn't completely object oriented...even new functions for password stuff in 5.5 are added as stateless global functions w/ params. At this point, it's not worth it to change the language significantly...everyone knows the mistakes made and they just move on.
As for your project, it's neat. Runtime parsing and handling of docblock annotations can be a tad heavy and cumbersome. Some kind of pre-compiler might be nice. Also, toss your stuff on composer/packagist and you might find https://github.com/phpDocumentor/ReflectionDocBlock helpful too.
I agree with you and I always wondered why the internals team hadn't done this themselves and just left the original functions as warty aliases for backwards compatibility.
I hate how to this day PHP still lacks of an obvious way to write object literals, instead forcing you to either cast arrays, which is verbose and ugly, or use stdClasses, which personally I do but damn are they a pain to use and maintaining for nested structures. This reason alone is what would make me switch to nodejs next time I start something.
There has been support for object literals for quite some time now (https://wiki.php.net/rfc/objectarrayliterals) but maybe just not enough. It would definitely be a welcome addition to the language. At least we no longer need to write array() for arrays lol.
I thought the point of autoloading was to make things easier, not to replace require_once with something more verbose. Why should I have to import classes from within my own package?
People seem to forget that enterprisey code is drastically different from your own small projects. Having even composer in multi-person dev teams that have niche understandings can drastically improve code quality because it tends to lend itself to componentized architecture. This alone will help you escape the typical procedural nightmares if you are so inclined to do so.
PEAR was crap and lent itself to crap code. Composer is the opposite and it shows. Github and composer really should be the winners of PHP 2012 (aside from the advancements in PHP itself) as they alone have transformed the landscape in very tangible ways. I'd give props to Symfony too as they have forced most other frameworks to begin thinking outside the monolithic framework mindset.
Then again I suppose it's a little naive to expect people to escape their bubble of understanding, but I can keep on hoping.
I don't really get Laravel. The docs talk about dependency injection but at the same time they really really love static function calls. For example there's no event manager class, only a single, global event manager: e.g. "Event::fire('loaded')".
What if I want to use a different event manager? (To pass event calls across the network, for example.) There doesn't seem to be any way to do this, and pretty much all the core classes are like this.
yesss, laravel is the most promising of all. few weeks ago, i wanted to make small site in php, i evaluated nette (poor docs, bugs), silex (couldn't get autoloading to work on shared host) and finaly laravel - by far best! especialy eloquent orm is simple yet very usable AR impl, all api's very simple and clean - this fw has very railsy feeling overall.
there is laravel 4 behind the doors, i was playing little bit with it, it's even better (copy of rails :-)) - autor claims full DI support so testing should be simple...
Laravel is my first experience with php frameworks.
I have yet to actually finish a project in it which is disappointing (for something whose entire purpose is to make finishing projects faster) but I really like it. It's been a huge educational experience for me.
PHP is getting traits? The next thing you know PHP will be type safe and scale, heh, heh ;-)
Seriously, Wordpress with a custom theme is a nice way to slap some bling on the front end and provide clients with an excellent CMS, but otherwise, for custom functionality, PHP? Thanks, I'll pass.
PHP definitely has its annoyances: the function naming scheme alone still drives me mad after nearly 15 years of PHP experience.
That said though, like most IT projects, the more you put in at the start, the more you get out in the end. If you rush into a project and don't plan out even the basics, it only stands to reason that you'll end up in a mess.
Along these lines, I have to wonder how many problems the quick-fix tutorial-style articles cost after developers copy-and-paste in an attempt to hurry through a project. My guess: lots.
Personally, I think it's an exciting time to be in PHP. It's possible to put together complicated, scalable sites in what is really an incredibly short amount of time.
4 of years ago I liked symfony. Haven't really tested it in a while though but later versions look like improvements in everything but learning curve. But I'd say the same goes for rails.
Check out the symfony framework version 2.1+
Its the best way to write PHP applications today and i am pretty sure its ahead of the web frameworks in most other popular languages.
It's not that bad, really. Most people are using 5.3 and are either moving towards 5.4 or recently moved to 5.4.
Those on 5.2 are probably stuck there for reasons outside of their control. And 5.5 hasn't even been released, so you can completely ignore it for the most part.
My year in PHP was spent counteracting godawful newbie PHP developers' idea of what is 'best practice'. "Framework convergence"? "A common autoloading strategy"? Come on. Perhaps 85% of PHP (we could almost say web) projects are fire-and-forget, with minimal maintenance.
No, I don't have sources, but yes, you know it's true. This is the web programming world's dirty-little secret. Same goes for RoR, and the rest of them.
What does this mean? The code produced simply doesn't matter. Bitrot is accepted. Nobody cares. Of course, then there are maintained projects, complex infrastructures, things that push the boundaries. But they are so few and far between that their lessons are difficult to generalize, certainly with any significant bearing on PHP as a language as opposed to general programming practice.
Meanwhile, people scream from the lamp-posts about 'best practice'. For example, I was informed by an inexperienced developer a couple of years ago that it was now considered (by who?) 'best practice' to leave out the closing tags in PHP files. WTF?
More muck - let's look at the article's topic of 'autoloading'.
Symptom: annoying code to type all over the place, thinks developer: "my HairyStinkySpittingCamelCaseClass extends GeneralObjectOrientedAnimalIrritantClass". Oops, need to also type in 'require_once('classes/irritants/animals/objectoriented/general.inc');' up there. Oh no, now I'm getting lazy. Oh but this framework has this autoloader thing! I should use that. That's what someone else did! How cool is that!" Wrong. You are incrementally introducing complexity, tight-coupling, and turning your execution flow in to spaghetti.
Probable cause: Extreme overuse of the OO model, generally.
Obvious fix: Stop (over)using OO.
Yes, you heard me right. Stop using OO. Just try it. Code immediately becomes so much more concise, readable, and re-usable. (Oh, for the days of PHP3! Hahah.) I challenge you or your team to refactor some part of your codebase in to non-OO and see if it doesn't improve. Of course, if you are really new then your whole codebase is linked to your framework's inherent model (probably some MVC thing that only partially functions architecturally) and you won't be able to figure out where to start with such a task. But do try, it will be interesting, I guarantee it.
I'm not saying OO is useless, just that most times it's used in PHP code it's contributing nothing useful and would be better having been left out. Look hard and I would be surprised if you don't concur.
So yes, for me, 2012 was mostly a year like any other in PHP. Ignoring vocal people while getting things done. Still amazed at how broken the whole pear thing is. And PHPUnit, hah. That thing is so PHP4+ Javafied best-practice Germanic, it should be in a modern art gallery. (And I say that as a nominal German.)
Anyway, 14 years and PHP is still the most bulletproof language for getting stuff done on the web.
So dear PHP authors, thanks for saving us from perl/cgi (though perl has it's place, it's not the best tool for the web). You deserve a medal. Particularly for early and reliable UTF8 support, which gave me a fine excuse not to switch to ruby 5+ years ago, even though I really, really wanted to, and still prefer its syntax and features. However, your OO implementation was crap, and your function naming and parameter ordering is impenetrably wacky, even after a decade and a half. But that's OK, nobody's perfect. We still love you :)
Ohh hey your that guy I have been cleaning up after. Thanks for making the lives of everyone who comes after you miserable. Keep up the good work. I will keep rewriting all your crap.
> For example, I was informed by an inexperienced developer a couple of years ago that it was now considered (by who?) 'best practice' to leave out the closing tags in PHP files. WTF?
With this statement, I can't decide if you are being serious or just having a good laugh.
> Perhaps 85% of PHP (we could almost say web) projects are fire-and-forget, with minimal maintenance.
Keep in mind, your knowledge is based on your environment. If you work with bad code, that's all you know. I don't, so I don't realize what it's like working "in the wild."
You're probably a bit too hard on the emerging techniques - Class loading is easily one of the best things to happen to PHP in years (along side closures).
But... I'm inclined to agree with you about OO. It's far over used by developers who don't have the experience to know when to stop. Dependancy Injection? God damn, are we actually solving problems or covering up issues with a programming paradigm? This solves a problem I never knew I had...
Traits and "mix ins" blow my mind. How bout just using a bloody function call in a library (yes, these can be testable just fine too without the word "class" in there).
Maybe I've just head my head neck deep in functional/procedural code for too long to appreciate things, but none of my OO systems has ever achieved the need for overly complicated management systems like DI or traits.
Your criticism of autoloading comes as a surprise. During 2012 one of my colleagues squeezed a little extra performance out of our software by removing all the calls to require_once from our installation of Zend Framework, thus handing full control to the autoloader. It's a trick that's even mentioned in the official documentation: http://framework.zend.com/manual/1.12/en/performance.classlo.... Apparently it's quicker. Typical bloody PHP.
Hmm, if you thought the person that told you that leaving out closing tags was a noob then what does that make you :)? It is a good practice to leave out closing tags, RTFM to learn when and why.
Edit:
After reading the rest of your comment I don't think you really learned or experienced much over 14 years. It also goes to show how misleading experience in number of years can be.
There is a good reason to not include the closing tag. Silly people can add newlines after the ?>. That leads to random newlines in your output which are annoying to track down.
It's like you've taken every good thing done recently to PHP and turned it on its head.
Protip: You exclude closing ?> tags from your files because if there's a new line after them, you'll get the headers already sent error, which is a big headache to track down.
Seeing all the bashing of your anti OO comment, I must leave a note of appreciation. PHP is not Java. All framework developers should write that phrase 100 times, Bart Simpson style before designing their framework.
It's not acceptable having to import a monolithic framework to write a simple webapp. All webapps start simple...
It's not acceptable having MVC crammed down my throat, when MVC, which fits desktop development perfectly, feels shoehorned in webapp environments.
So many frameworks have great code in there only to be unusable because it's trapped in monolithic OO monsters. I'm looking at you Zend, or Cake, or even symphony...
That being said, nicer frameworks are appearing. Aura and Fuel both look great.
> The code produced simply doesn't matter. Bitrot is accepted. Nobody cares.
It's a real bug-bear of mine that, in the profession as a whole, this attitude is rarely criticised, and sometimes even praised (especially on HN with the JUST SHIP IT startup mentality).
A lot of people are fine with this and can probably offer a lot of reasons pertaining to business interests, which is fine. Those can be measured, deliberate compromises backed by sound reasoning and opportunity cost. But there's this other school of thought that just thinks, "fuck it, it's just code innit."
And it seems that newcomers to programming (in PHP/on the web) are still being taught at that school.
> Particularly for early and reliable UTF8 support
What do you mean by that? It has a rather simple concept of strings and a very interesting set of mb_... functions as far as I remember. PHP strings are just bytes and are not even encoding-aware themselves.
[+] [-] h2s|13 years ago|reply
http://codular.com/implementing-pagination
http://codular.com/part-2-rating-system In fairness these aren't your typical "straight out of $_GET" vulnerabilities, but they impart a lax attitude towards security. For example, in the latter example above, $rating is escaped just prior to its use in that query, but $_SERVER['REMOTE_ADDR'] isn't. In the former, there is no indication whatsoever of where the variable $articlesPerPage has come from so it's impossible to tell.The notion that some variables are "safe enough" that they don't need escaping is naive. $_SERVER['REMOTE_ADDR'] is a global variable that any other code anywhere in the script can write to. While you can't get owned immediately after putting that code live, it is still a tiny little SQL injection vulnerability waiting behind the scenes for an attacker to chain it together with some other similarly minor flaw and break in.
To this day I still come across PHP code that is vulnerable to serious, immediate SQL injection vulnerabilities and it isn't always old code. I'm not so sure that the PHP community is so quick in learning from its mistakes.
[+] [-] bpatrianakos|13 years ago|reply
Can you tell me which language is impervious to SQL vulnerabilities? Is there some magic language out there that cleans all external input for you? Pick a language, any language, and you will just about always find that GET and POST variables aren't cleaned for you and rightly so! The language should be a tool to let you do whatever you want and leave it up to the programmer to clean input. Now, if you want to talk about frameworks that's a different story.
You picked one site with one tutorial and based off that have basically proclaimed PHP to be an insecure language. For every tutorial that skips over security or has some mistake or vulnerability there are others out there that don't. The one you chose is in PHP but you can find tutorials in any language with the same flaws.
We all get it by now. PHP is lame and it's cool to bash it. It has a history of being crappy. Fine, we know. But PHP in past couple of years has begun to address those flaws and has come a long way. Now that it's starting to get better people seem to want to cheer for it to fail. No matter how uncool it is it's still incredibly popular even among people here on HN. It's just that they don't like to talk about it out loud because of the stigma it now has among the language snobs.
I mean, come on man. Was this really in fairness or just another cheap and easy shot. An opportunity to pile on.
And to address the quote you mention... the web may still have a lot of those old and awful tutorials but that doesn't mean the community hasn't learned. More recent tutorials and information you find online is much better and the community is far more cognizant of PHPs vulnerabilities and are now using best practices far more frequently. It's always fun to bash PHP but let's just give credit where credit is due. It has taken enough steps in the right direction for it to be worthy of people taking notice.
EDIT:
Also, the tutorial site you linked to is actually quite good. Tutorials are tutorials, not technical manuals. So when you want to show someone how to, for example, take GET or POST input and manipulate it somehow you want to focus on that and not explain every little thing like all the ways your GET or POST array can kill you via XSS or SQL injection. You might mention in passing that you'd better clean your input but unless the article is about sanitizing and escaping inputs itself I don't see why it has an obligation to go into that much depth.
[+] [-] h2s|13 years ago|reply
[+] [-] RobAley|13 years ago|reply
Do you not find that with other languages as well? I do.
[+] [-] simonw|13 years ago|reply
[+] [-] jamescun|13 years ago|reply
I'm fairly sure crap tutorials and SQL injections are possible in every language.
[+] [-] tangue|13 years ago|reply
[+] [-] rorrr|13 years ago|reply
Blaming some badly written tutorials on the language is just trollish-lame.
[+] [-] dkhenry|13 years ago|reply
HipHop making an alternative VM. I see that as the biggest change in PHP in 2012. Sure HipHop has a translator/compiler (HPHPc) for a while now, but now they have a full fledged VM with a JIT (HHVM). Maybe next year we can get a sane extension framework and make a less memory intensive construct then zvals.
[+] [-] mjs|13 years ago|reply
[+] [-] Joeri|13 years ago|reply
I've done some experimenting with meta-programming that into PHP, but it should really be done at the language level.
(For anyone interested, this is my experiment: https://github.com/jsebrech/php-o )
[+] [-] kodablah|13 years ago|reply
As for your project, it's neat. Runtime parsing and handling of docblock annotations can be a tad heavy and cumbersome. Some kind of pre-compiler might be nice. Also, toss your stuff on composer/packagist and you might find https://github.com/phpDocumentor/ReflectionDocBlock helpful too.
[+] [-] lhnz|13 years ago|reply
[+] [-] Mahn|13 years ago|reply
[+] [-] yogo|13 years ago|reply
[+] [-] vojant|13 years ago|reply
[+] [-] astrodust|13 years ago|reply
[+] [-] tiwazz|13 years ago|reply
https://github.com/symfony/symfony/blob/master/src/Symfony/B...
I thought the point of autoloading was to make things easier, not to replace require_once with something more verbose. Why should I have to import classes from within my own package?
[+] [-] methodin|13 years ago|reply
PEAR was crap and lent itself to crap code. Composer is the opposite and it shows. Github and composer really should be the winners of PHP 2012 (aside from the advancements in PHP itself) as they alone have transformed the landscape in very tangible ways. I'd give props to Symfony too as they have forced most other frameworks to begin thinking outside the monolithic framework mindset.
Then again I suppose it's a little naive to expect people to escape their bubble of understanding, but I can keep on hoping.
[+] [-] joshstrange|13 years ago|reply
[+] [-] mjs|13 years ago|reply
What if I want to use a different event manager? (To pass event calls across the network, for example.) There doesn't seem to be any way to do this, and pretty much all the core classes are like this.
http://laravel.com/docs/events
[+] [-] nyam|13 years ago|reply
L4 https://github.com/illuminate/app
[+] [-] embplat|13 years ago|reply
[+] [-] krapp|13 years ago|reply
I have yet to actually finish a project in it which is disappointing (for something whose entire purpose is to make finishing projects faster) but I really like it. It's been a huge educational experience for me.
[+] [-] virtualwhys|13 years ago|reply
Seriously, Wordpress with a custom theme is a nice way to slap some bling on the front end and provide clients with an excellent CMS, but otherwise, for custom functionality, PHP? Thanks, I'll pass.
[+] [-] eitland|13 years ago|reply
Rest assured, plenty real annoyances with php :-)
[+] [-] mootothemax|13 years ago|reply
That said though, like most IT projects, the more you put in at the start, the more you get out in the end. If you rush into a project and don't plan out even the basics, it only stands to reason that you'll end up in a mess.
Along these lines, I have to wonder how many problems the quick-fix tutorial-style articles cost after developers copy-and-paste in an attempt to hurry through a project. My guess: lots.
Personally, I think it's an exciting time to be in PHP. It's possible to put together complicated, scalable sites in what is really an incredibly short amount of time.
[+] [-] AlexMuir|13 years ago|reply
I used to do all my work in PHP but moved to Rails and adopted TDD/BDD. I'm just not sure how this would fit back in to the PHP world.
[+] [-] eitland|13 years ago|reply
[+] [-] kayoone|13 years ago|reply
[+] [-] dangerlibrary|13 years ago|reply
I thought Python limping from 2.7 to 3.3 was silly and confusing. I'm glad I haven't been working in a PHP shop recently.
[+] [-] k3n|13 years ago|reply
Those on 5.2 are probably stuck there for reasons outside of their control. And 5.5 hasn't even been released, so you can completely ignore it for the most part.
[+] [-] contingencies|13 years ago|reply
My year in PHP was spent counteracting godawful newbie PHP developers' idea of what is 'best practice'. "Framework convergence"? "A common autoloading strategy"? Come on. Perhaps 85% of PHP (we could almost say web) projects are fire-and-forget, with minimal maintenance.
No, I don't have sources, but yes, you know it's true. This is the web programming world's dirty-little secret. Same goes for RoR, and the rest of them.
What does this mean? The code produced simply doesn't matter. Bitrot is accepted. Nobody cares. Of course, then there are maintained projects, complex infrastructures, things that push the boundaries. But they are so few and far between that their lessons are difficult to generalize, certainly with any significant bearing on PHP as a language as opposed to general programming practice.
Meanwhile, people scream from the lamp-posts about 'best practice'. For example, I was informed by an inexperienced developer a couple of years ago that it was now considered (by who?) 'best practice' to leave out the closing tags in PHP files. WTF?
More muck - let's look at the article's topic of 'autoloading'.
Symptom: annoying code to type all over the place, thinks developer: "my HairyStinkySpittingCamelCaseClass extends GeneralObjectOrientedAnimalIrritantClass". Oops, need to also type in 'require_once('classes/irritants/animals/objectoriented/general.inc');' up there. Oh no, now I'm getting lazy. Oh but this framework has this autoloader thing! I should use that. That's what someone else did! How cool is that!" Wrong. You are incrementally introducing complexity, tight-coupling, and turning your execution flow in to spaghetti.
Probable cause: Extreme overuse of the OO model, generally.
Obvious fix: Stop (over)using OO.
Yes, you heard me right. Stop using OO. Just try it. Code immediately becomes so much more concise, readable, and re-usable. (Oh, for the days of PHP3! Hahah.) I challenge you or your team to refactor some part of your codebase in to non-OO and see if it doesn't improve. Of course, if you are really new then your whole codebase is linked to your framework's inherent model (probably some MVC thing that only partially functions architecturally) and you won't be able to figure out where to start with such a task. But do try, it will be interesting, I guarantee it.
I'm not saying OO is useless, just that most times it's used in PHP code it's contributing nothing useful and would be better having been left out. Look hard and I would be surprised if you don't concur.
So yes, for me, 2012 was mostly a year like any other in PHP. Ignoring vocal people while getting things done. Still amazed at how broken the whole pear thing is. And PHPUnit, hah. That thing is so PHP4+ Javafied best-practice Germanic, it should be in a modern art gallery. (And I say that as a nominal German.)
Anyway, 14 years and PHP is still the most bulletproof language for getting stuff done on the web.
So dear PHP authors, thanks for saving us from perl/cgi (though perl has it's place, it's not the best tool for the web). You deserve a medal. Particularly for early and reliable UTF8 support, which gave me a fine excuse not to switch to ruby 5+ years ago, even though I really, really wanted to, and still prefer its syntax and features. However, your OO implementation was crap, and your function naming and parameter ordering is impenetrably wacky, even after a decade and a half. But that's OK, nobody's perfect. We still love you :)
Happy new year, PHP community.
[+] [-] dkhenry|13 years ago|reply
[+] [-] jasonlotito|13 years ago|reply
With this statement, I can't decide if you are being serious or just having a good laugh.
> Perhaps 85% of PHP (we could almost say web) projects are fire-and-forget, with minimal maintenance.
Keep in mind, your knowledge is based on your environment. If you work with bad code, that's all you know. I don't, so I don't realize what it's like working "in the wild."
[+] [-] blindhippo|13 years ago|reply
But... I'm inclined to agree with you about OO. It's far over used by developers who don't have the experience to know when to stop. Dependancy Injection? God damn, are we actually solving problems or covering up issues with a programming paradigm? This solves a problem I never knew I had...
Traits and "mix ins" blow my mind. How bout just using a bloody function call in a library (yes, these can be testable just fine too without the word "class" in there).
Maybe I've just head my head neck deep in functional/procedural code for too long to appreciate things, but none of my OO systems has ever achieved the need for overly complicated management systems like DI or traits.
[+] [-] h2s|13 years ago|reply
[+] [-] yogo|13 years ago|reply
Edit: After reading the rest of your comment I don't think you really learned or experienced much over 14 years. It also goes to show how misleading experience in number of years can be.
[+] [-] thelarry|13 years ago|reply
[+] [-] jtreminio|13 years ago|reply
Protip: You exclude closing ?> tags from your files because if there's a new line after them, you'll get the headers already sent error, which is a big headache to track down.
[+] [-] sergiosgc|13 years ago|reply
It's not acceptable having to import a monolithic framework to write a simple webapp. All webapps start simple...
It's not acceptable having MVC crammed down my throat, when MVC, which fits desktop development perfectly, feels shoehorned in webapp environments.
So many frameworks have great code in there only to be unusable because it's trapped in monolithic OO monsters. I'm looking at you Zend, or Cake, or even symphony...
That being said, nicer frameworks are appearing. Aura and Fuel both look great.
[+] [-] FuzzyDunlop|13 years ago|reply
It's a real bug-bear of mine that, in the profession as a whole, this attitude is rarely criticised, and sometimes even praised (especially on HN with the JUST SHIP IT startup mentality).
A lot of people are fine with this and can probably offer a lot of reasons pertaining to business interests, which is fine. Those can be measured, deliberate compromises backed by sound reasoning and opportunity cost. But there's this other school of thought that just thinks, "fuck it, it's just code innit."
And it seems that newcomers to programming (in PHP/on the web) are still being taught at that school.
[+] [-] encoderer|13 years ago|reply
[+] [-] vojant|13 years ago|reply
[+] [-] viraptor|13 years ago|reply
What do you mean by that? It has a rather simple concept of strings and a very interesting set of mb_... functions as far as I remember. PHP strings are just bytes and are not even encoding-aware themselves.
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] wolfpackk|13 years ago|reply
[+] [-] M4N14C|13 years ago|reply
[deleted]
[+] [-] xxiao|13 years ago|reply
[deleted]