2012: A Year in PHP
techportal.inviqa.com
techportal.inviqa.com
> The community is always quick to learn from
> its mistakes however
http://codular.com/implementing-pagination
$sql = 'SELECT * FROM `articles` LIMIT ' . $startArticle . ', ' . $articlesPerPage;
INSERT INTO `ratings`
(`rating`, `ip`)
VALUES ('{$rating}', '{$_SERVER['REMOTE_ADDR']}')
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.
Do you not find that with other languages as well? I do.
The PHP core community might not write such tutorials but there are loads of people who do.
Edit: "encourage" as in (a) not discouraging and (b) making them easier to use for novices (without understanding the consequences).
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.
That's not the point. The point is that PHP tutorials/books/best practice guidelines repeatedly and consistently do this sort of thing.
Even "PHP: The Good Parts" spent most of the chapter on SQL without mentioning security until the very last part, where they sort of waved their hands at it.
In the edit to my comment above I touched on this. In short, when you instruct someone on how to do something you put the focus on the task and not the peripheral stuff. You may mention it in passing but to explicitly go over certain things may not be the right thing to do. I can totally see any book or tutorial showing people how to do certain things without mentioning security or kind of glossing over them. That's because you want to make sure a person gets the concept first. Once a person gets how to work with GET/POST or do anything else for that matter, you can then explicitly go over security, mention where to look for vulnerabilities, where to use the security techniques etc.
I learned a touch of Ruby and I'm getting decent with Python right now and pretty much everything I've read either completely skipped security or mentioned it in passing. At a certain point security is introduced and by that point I understood the language enough to know where to apply it in the previous examples from whatever I read. I've also been reading a copy of "Javascript: The Good Parts" and it does much the same thing where you get comfortable with the concepts and security comes later.
I think that because of PHPs history of security problems people are extra sensitive to any PHP code they read online and are almost looking for any way to jump up and say "that's not secure!!". PHP deserves that because of how it used to be but things have and are still changing very much.
You can shoot yourself in the foot with any programming language. PHP just happens to have one of the shallowest learning curves and greatest availability, so simply by virtue of being everywhere it's responsible for a lot of damage. It doesn't help that a newbie that came up with a working (but dangerous/incorrect/...) solution can then easily start answering other newbies' questions, although that's hardly a PHP-specific thing.
Further - because it's so many people's first programming language, they don't even know to look for information about best practices, let alone go out of their way for it. It takes a seasoned programmer to go out of his/her way to avoid repeating other people's mistakes.
The argument that community is not relevant to a languages usefulness is simply wrong. PHP suffers from poorer community than other languages. This is improving as the article highlights but it still has a long way to go.
I completely agree about the community (I'm not sure who your comment is addressing, as I never argued that community is irrelevant, nor did the person to whom I was responding). But on the flip side - having some single pool of up-to-date knowledge is different than a circlejerk, and the "our way or the highway" attitude is very prevalent in some programming communities. Besides being incredibly alienating to newbies, it actively holds back development of new features and discussion of new ideas because these community managers are not trying to solve the same set of problems as the developers using the language/framework.
Yes, it's a damn shame that plenty of PHP example code is from 2006 and still sitting at the top of Google - but by and large, it still works just fine and has accurate information. It may be doing messy stuff like mysql_real_escape_string instead of prepared statements, but the end result is the same.
All of the community and documentation in the world won't stop people from using the tools wrong, and if you take away all the potentially-dangerous tools, you're left with very few things that are actually useful. I'll reiterate my previous point here: something with a low barrier to entry will tend to attract novices, and novices tend to make a lot more mess than seasoned practitioners. If PHP didn't exist and Python or Ruby took its place as the easiest thing to get up and running with, most (no, not all - I've worked with PHP long enough to know which ones are genuinely PHP-specific, and it's not many) of these PHP-hate comments could be run through s/PHP/NEWLANG/g and be completely accurate. Even when you start looking for best practices on a new language you'll encounter a valid counterexample for every single one of them, since it depends on what you're doing.
Python, Ruby, Perl, Java and even C# all have popular, widely used SQL interface libraries where placeholders are the norm. Only PHP even considers injecting user data into queries. This is extremely harmful.
Tutorials should show best practices, not just the first thing that works. There should be significant attention paid to how to construct a safe and reliable query. This is not a secondary concern, not when there are automatic hacking tools with a very scary list of features (http://sqlmap.org/) out there for anyone to download.
Microsoft used to be very hand-wavey about security issues and it cost them severely. Now they've tightened all the bolts and Windows is in much better shape because of it.
The PHP community needs to root out these poisonously bad tutorials and eliminate them from search results. How can this be done? By making better tutorials and linking to them more aggressively.
Stop pretending this isn't a problem and start fixing it.
Forcing cheapo web hosts to enable mysqli or PDO will hopefully help a great deal.
I just think they should have added E_DEPRECATED warnings in 5.4 - but I see why they didn't.
PHP 5.5 will produce warnings when using mysql_query. It's a small step forward.
I do disagree with you on some of your points about tutorials though. You claim it's possible to find such insecure example code for any language, and that's probably true. But is it easy? The first search result for "python mysql tutorial" [1] doesn't contain any SQL injection vulnerabilities. Neither does the first result for "ruby mysql tutorial" [2]. All seems well with "java mysql tutorial" [3] too. Surely the first Google result for "php mysql tutorial" [4] can't be that bad then?
$first=$_POST['first'];
$last=$_POST['last'];
$phone=$_POST['phone'];
$mobile=$_POST['mobile'];
$fax=$_POST['fax'];
$email=$_POST['email'];
$web=$_POST['web'];
mysql_connect(localhost,$username,$password);
@mysql_select_db($database) or die( "Unable to select database");
$query = "INSERT INTO contacts VALUES ('','$first','$last','$phone','$mobile','$fax','$email','$web')";
mysql_query($query);
[1] http://zetcode.com/databases/mysqlpythontutorial/
[2] http://zetcode.com/db/mysqlrubytutorial/
However, PHP is no longer a templating language. It's a full featured programming language that is used to build a variety of different systems. Trained developers work with PHP every day to build solid, testable and secure code.
There is no excuse for any trained developer to write code like that. Perhaps you shouldn't judge the language just because some untrained idiot put up a bad tutorial.
But anyway I think we might just view tutorials differently. To me, what's posted above is an outdated, insecure way to put data into a database but it definitely answers the question "how do I put stuff in a databse" simply and right to the point. And that's what I like about PHP tutorials. I'd rather put the onus on the programmer to learn how to put "way to do X' and "way to do Y" together on their own rather than muddy the waters with "here's how to do X but this is important too so let's show you how to do this other thing at the same time".
I do agree that the above example is the rule rather than the exception as most books I've owned show something similar or worse:
foreach($_POST as $key => $value) { ${$key} = $value; }
That's almost as convenient as that magic global form garbage they used to have turned on by default.
I was under the impression though that the MySQLi adapter and PDO both made use of prepared statements. All we need to do now, is clean up the last few years of cruft/misinformation still floating around.
If by "magic" you mean simply disallowing non-structured queries (which is pretty darn easy with a Structured Query Language):
http://en.wikipedia.org/wiki/Language_Integrated_Query
http://www.impredicative.com/ur/
http://pgocaml.forge.ocamlcore.org/
https://github.com/mfp/ocaml-sqlexpr
and that's just off the top of my head.
DB["insert into foo (bar, baz, qux) VALUES (?, ?, ?)", bar, baz, qux].insert
And the library handles all the escaping, and even type conversion for you (e.g. Date objects to SQL compatible date strings)
I'm fairly sure crap tutorials and SQL injections are possible in every language.
Blaming some badly written tutorials on the language is just trollish-lame.
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.
The SPL data structures are meant to be faster and leaner implementations of common data structures that are usually created ad hoc in plain PHP.
[1] http://ca.php.net/splfixedarray
[2] http://ca.php.net/manual/en/class.spldoublylinkedlist.php
If a VM makes them design sane consistent and useable versions of those plugins from the ground up PHP may be improved as a result.
APC is a bit more than an opcode cache. It can be used like memcache, although restricted to the machine it's running on. It's my understanding that it is a part of hhvm?
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 )
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.
var myObject = { memberOne: 'some string value', memberTwo: { subMemberOne: 42, subMemberTwo: 48 }, memberThree: false };
Has this as the closest equivalent in PHP right now:
$myObject = (object) [ "memberOne" => 'some string value', "memberTwo" => (object) [ "subMemberOne": 42, "subMemberTwo": 48 ], "memberThree" => false ];
It's verbose, really, I would very much prefer a native solution that doesn't enforce casting from array and quotation around property names.
People have proposed it and commented on it but it does not get enough support (votes) from senior devs to get included. Maybe with more requests it will get included finally.
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?
It's a symptom of people trying to solve everything with one toolset ("Me know hammer, me use hammer!").
In practice, most OO projects regardless of language have classes like 'LatestThingOtherThingIKindaRememberSomethingSomeoneElseWroteDontTouchIt', combined with a non-negotiable and often intrinsically (looking directly at any given piece of code) inexplicit set of dependency assumptions around the global object model.
In general we need less OO, and more immediately apparent, procedural, loosely coupled code. Programs that "do one thing and do it well".
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.
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.
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.
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.
Rest assured, plenty real annoyances with php :-)
Any backend will scale if it runs in parallel and you throw enough hardware at it.
Perhaps a more important question would be whether PHP scales codebase-wise in larger projects.
Yes, it does. From my experience and apparently, that of Facebook.
And each of those implementations is PHP. It is open source and is available to the public. I am working on integrating it into my stack.
> If anything, their case shows that they threw enough money at it to make it work.
I thank them for their money and will now apply their hard earned work.
What other language has that kind of commitment behind it?
Note to self: research (non-existent) parallel processing in (single threaded) PHP; also, find enough hardware to make PHP scale ;-)
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.
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.
I came up to speed with PHP recently and spent a lot of time searching for "best practices" or other variations of that keyword to see what I could build on. The stuff I found was generally quite frighteningly bad, mostly people getting excited about the most absurd micro-"optimisations" (and that's after explicitly discounting anything more than a few years old).
But the ecosystem around symfony 2 seems to be where all the sane (imho) PHP developers are heading. In particular they seem to have drawn a line under old versions of PHP and made good use of the newer features added to the language to build modular components.
For a while I wondered whether everyone who wanted to use these techniques had all been driven out into the arms of Ruby (on Rails) and Python. But the Symfony guys seem to have just re-imported a lot of the best ideas back into PHP from projects like Rack, Sinatra, Django, Rails, Cucumber etc.
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.
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 :)
Happy new year, PHP community.
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."
As for the "I don't work with bad code because I wrote it myself or in this particular small environment" comment, that's great. I have worked in many countries, so I have a fairly broad experience, and IMHO much of the webcode industry to be pretty fire-and-forget vs. other areas of programming.
I think if you are working at a scale where this is even ridiculously relevant then you will prefer to manually specify required libraries and maintain a closer understanding of control flow at all times.
If not, then you would at least start measuring performance characteristics. When you do that, you will find that if you are pre-loading these things on your last query they will just live in OS filesystem cache (ie. already in memory). (Note: If your load time is disk-affected, a half decent sysadmin could just hard cache your code in memory anyway...)
Sure, you will have slightly longer interpreting time (again, not likely to matter, except at huge scale), but that will be offset by things like: (1) Any number of potential caching layers - OS filesystem, APC, etc. - which should maintain these cached either in memory or both in memory as PHP bytecode, thus largely effacing this concern (2) enhanced simplicity for everyone.
While I'm all for low-hanging performance fruit, this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy, whilst harming simplcity. It's justifying itself as optimization, and on many levels it just isn't. It's going backwards.
Manually specifying the libraries creates the problem in the first place -- it's a very difficult problem when your dependencies have dependencies and so on. You have code that depends on resource A but doesn't use resource A on every request; how do you manage something like that manually in a huge project?
> Sure, you will have slightly longer interpreting time
If you have a large framework almost everything depends on everything else. So you end up loading and interpreting 100% of your framework on every request. Even worse, you load it all at the start of the request! If you code only uses a small fraction, lets say 20%, of the framework and only loads and interprets it on demand that will make a difference.
> While I'm all for low-hanging performance fruit, this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy, whilst harming simplcity.
I don't much care about the performance considerations but I find autoloading far simpler than manually specifying every dependency. In fact, most modern languages don't bother with that either -- going back to C/C++ from Java/C# gives the same sort of pain. I'm not sure why you think it "costs too much" given it's likely to cost less in performance and code written. Performance was not the main concern for the addition of autoloading.
I work at a scale where this is extremely relevant, and autoloading is a godsend. Manually including files is not only error-prone, but is tedious and requires development effort [time] that would be best utilized elsewhere.
> [...] this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy
Costs too much? Have you not implemented it? It's not hard at all to implement, even if you have an unorthodox file & class naming convention. The only caveat is that you can only have 1 class per file (which hopefully you'd agree is good practice in the first place).
Performance increases can be pretty large, too, especially at scale. Consider class A, which in some methods requires access to class B. You _could_ put the include inside those methods, but I can guarantee you that you'll see a noticeable performance hit if that method is called in iteration (we're talking a few seconds worth of time if iterated 1000+ times). That's non-trivial. So, what do you do? You could move it to the top of the file, so that it will only be required once. However, the problem here is you end up with 5-10+ includes at the top of every file. So now when you require that one file, you're now requiring an additional 5-10+ files, each with their own possible set of includes. I've seen instances of needing to require a single file result in having 100+ files being required due to the cascading. With an autoloader, that 100+ goes back to 1.
> whilst harming simplcity
This couldn't be further from the truth. You will have less LoC overall, less developer time spent trying to get the perfect set of includes so that you only require them once and only when they're needed. You will have fewer bugs due to the problems with manual includes, which again, means more time for developers to actually do stuff that matters.
Really? You run Facebook or something? Got any figures?
> autoloading is a godsend. Manually including files is not only error-prone, but is tedious and requires development effort [time] that would be best utilized elsewhere.
Hang on. How many files are you including? Generally you only need to include one, right. Your framework, maybe an external library. Then you can call in whatever modules you need, as you need them. Right? Or are you using some weird kind of framework without modules?
> > [...] this particular approach ('autoload') costs too much and delivers too little to be generally praiseworthy > > [...] whilst harming simplcity > Costs too much? Have you not implemented it? It's not hard at all to implement, even if you have an unorthodox file & class naming convention. The only caveat is that you can only have 1 class per file (which hopefully you'd agree is good practice in the first place).
To clarify, the overheads I was referring to were (1) conceptual; less "WTF" for new developers to deal with (2) complexity; code-flow is both simpler and more explicit.
> Performance increases can be pretty large, too, especially at scale. Consider...
If you can provide some demo code, I'd love to see it. I think you will find largely it's just a result of having a dumb framework or being ultra-contrived in your example to an unrealistic degree. I also think you'll find that second-guessing require_once (a language-level feature) is not going to be faster than simply using it.
http://till.typepad.com/blog/2008/10/zendframework-performan...
> Removing require_once in favour of __autoload shows
> one of the biggest performance improvements in my
> entire application - I shaved off roughly 220
> milliseconds by removing about 15 (or so) calls to
> require_once in my bootstrap.php file. And that's
> with APC enabled, and a decent sized realpath.cache
> (and .ttl).
No matter what your gut feeling about language-level features may be, I know that at my day job, we measured a clear performance boost when we removed require_once and switched completely to autoloading. For those of us working on very large, long-term PHP codebases, autoloading really is a good thing and I hope you can respect that in return.
Any reasonably sized codebase is going to load a lot of files. Because your projects are so small that this is not an issue is not a reflection on the quality of every one else's work.
I feel this comment contributes nothing to the conversation but a baseless personal accusation.
The code is already explicit enough, requiring directly is pointless busy-work that is more likely to be wrong.
100 total devs, over 10 years of development, with the codebase spanning 5k files and over 1 million LoC.
> Hang on. How many files are you including? Generally you only need to include one, right. Your framework, maybe an external library. Then you can call in whatever modules you need, as you need them. Right? Or are you using some weird kind of framework without modules?
This is a homebrew framework, but you're missing the point: regardless of how you kick it off, the framework itself still has to include files left and right. And modules or not, some code somewhere still has to include supporting files.
For every single file in your codebase, you will have at least one include call to it somewhere, possibly many more. It's silly to look at this as a "how many includes do you need to launch a request", because any simpleton can make it so that all you see is a single include, but that doesn't stop the fact that you must still manually include each and every other file -- at some point in the framework -- before you can use it.
> (1) conceptual; less "WTF" for new developers to deal with
I'll point to the supporting evidence provided by others here that shows that pretty much every modern framework uses autoloading. Thus, I wouldn't say it's a WTF, rather, the opposite is probably more true: who manually includes files anymore?
> (2) complexity; code-flow is both simpler and more explicit.
Removing include calls does not make the code more complex nor harder to follow, any decent IDE will let you control-click into the definition of classes. I'd argue that less LoC is a good thing (so long as we're not talking about "clever code", which this isn't).
> If you can provide some demo code, I'd love to see it.
Or, you know, you can read what I said as I perfectly explained the situation. But I'll play along.
// test 1
$start = microtime(1);
$i = 1000;
while (--$i);
$end = microtime(1) - $start;
printf('%.7f', $end); // .00004s
die;
// test 2
$start = microtime(1);
$i = 1000;
while (--$i) {
require './test.php';
}
$end = microtime(1) - $start;
printf('%.7f', $end); // .082s
Even with this simple example, the non-require version is 2000x's faster than the require version. This is also in a perfect world, e.g. there's no other files also being required that'd overflow the realpath cache, nor is there really any other OS activity that will hamper my tests. In the wild, there could be 50-100 requests being served concurrently, which would affect the system calls even more.
> I think you will find largely it's just a result of having a dumb framework or being ultra-contrived in your example to an unrealistic degree.
It's a dumb framework, but considering that it's a legacy project that has survived 10 years of organic growth and is still paying my salary (I've been here less than 1/2 of that time), it's not getting re-written anytime soon. But, weren't we talking about autoloading?
OK, so your codebase is certainly large, ungodly large, and frankly worrisome, but that alone isn't that all that interesting. Is it possible to feed my curiosity and supply queries/sec? :)
> ... any simpleton can make it so that all you see is a single include, but that doesn't stop the fact that you must still manually include each and every other file -- at some point in the framework -- before you can use it.
No, you only need to include the files you actually use. When you use them.
There's a strong argument to be had for being explicit, especially once performance becomes a concern.
The thread here is about arguing for autoload on performance grounds, and my opposition to such.
> pretty much every modern framework uses autoloading.
Pretty much every framework is crap, and a very bad way to build larger, complex systems, and maintain them over time. The majority of them are CMS and conventional website oriented, and apply poorly to other use cases. But you are perfectly welcome to limit your perceptions based upon what you consider to be modern and popular frameworks if you wish; it's entirely possible that - as I suspect - my experiences going beyond the above are a bit abnormal.
> Removing include calls does not make the code more complex nor harder to follow, any decent IDE will let you control-click into the definition of classes. I'd argue that less LoC is a good thing (so long as we're not talking about "clever code", which this isn't).
If you are looking at a block of code and the execution flow is dependent on an entire framework's dependency resolution mechanism (autoload or similar), with inexplicit dependencies, then it seems to be an obtuse perspective to argue that the code has not lost the property of being explicit.
> Even with this simple example, the non-require version is 2000x's faster than the require version. This is also in a perfect world, e.g. there's no other files also being required that'd overflow the realpath cache, nor is there really any other OS activity that will hamper my tests. In the wild, there could be 50-100 requests being served concurrently, which would affect the system calls even more.
First of all, clarity of code is far more important than performance in almost every case. If you really want to justify the lack of explicit dependencies on a performance basis, my point is that it's not possible.
> with this simple example, the non-require version is 2000x's faster than the require version
Err, here's what I got.
test1: 0.0000250 test2: 0.0177090 test3: 0.0062518 (same as test2 but with require_once instead of require)
Yeah the overhead is larger, no it doesn't really mean anything. However you include, you still have to include. not including is faster than require_once() is faster than require(). Nothing shocking there. I believe if you add APC and php-cgi and/or tmpfs as a mountpoint (vs. raw disk) this will decrease markedly, with no requirement to alter code.
I remain unconvinced.
Props on the custom framework vibe, IMHO every time I've looked, what's out there prebuilt is all crap (not relevant for anything but web-only, OO-centric, high overhead both performance and cognitive).
Most misunderstood quote of programming. Premature is the qualifier.
When it's right to care about simplicity and clarity: absolutely all the time.
Incorrect. There are things people do all the time with the understanding of mature optimization techniques. We know, for example, that certain algorithms perform better then a simple brute force technique, so we start there We might test various algorithms, too, before everything works. But we are testing.
Premature is not about time. It's about effectiveness. Sometimes you cannot gauge effectiveness until everything works, sure. But often times this is not the case.
I'm not denying there's better code and worse code in a performance-measurable sense that's written before 'optimization' goes on later in a project.
However, in the real world, we deal with problems. If you have a performance characteristic that's causing issues and you can reproduce it, then you have a problem and you can work on it. The inverse is also true.
Point of premature optimization quote: Most of the time more than a passing / higher-level-architectural thought about performance is not a good idea.
What is the effect of the additional text in the file with the closing tag? They are output, and visible.
What is the effect of the additional text in the file without the closing tag? It is interpreted as code, becoming a potential security issue.
Are they difficult to track down because your development process sucks, or because there's something illogical and mystical going on? (Hint: There's nothing illogical and mystical going on)
Using continuous integration (an RCS/VCS-linked automated testing scheme) you can trivially determine which change broke which part of a system. In fact, you don't have to, because the system will tell you.
If you are worried specifically about accidental newlines at the end of a file, you can just write a rule in ~project/.git/hooks/pre-commit (or similar on a server) that rejects checkins that don't match that style.
Going around telling the whole world to adopt some ridiculous habit because your development process is out of the stone age is a reflection on that process only.
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.
As for your argument against traits, using global functions clutters up the global namespace and doesn't lend very well to modular development. Next thing you know you have two libraries with "create_hash($string)" or something similar that do two different things.
*Edit: clarification
OO is all about loose coupling, greater re-usability, and conceptual clarity. That is literally the point of it all. You can fume about the abuse of OO but the exception is not the rule. It's quite unlikely that, in general, plain old procedural code is better for coupling, re-usability, or clarity unless your problems are boringly simple.
It's theoretically an interesting language pattern. However, it grew from controlled environment of experiments for which it is most suited.
It's perhaps telling that, today, a fairly large number of experienced programmers tend to avoid it. Have a look at the interviews in 'Coders at Work: Reflections on the Craft of Programming' for some good examples.
I actually just bought this book again specifically to find this quote, which is gold:
"Armstrong: I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project. Programmers have been conned into using all these different programming languages and they've been conned into not using easy ways to connect programs together. The Unix pipe mechanism-A pipe B pipe C-is trivially easy to connect things together. Is that how programmers connect things together? No. They use APIs and they link them into the same memory space, which is appallingly difficult and isn't cross-language. If the language is in the same family it's OK-if they're imperative languages, that's fine. But suppose one is Prolog and the other is C. They have a completely different view of the world, how you handle memory. So you can't just link them together like that. You can't reuse things. There must be big commercial interests for whom it is very desirable that stuff won't work together. It creates thousands of jobs for consultants. And thousands of tools to solve problems that shouldn't exist. Problems that were solved years ago."
Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Locations 2680-2689). Kindle Edition.
No, you have a small number of proponents of functional programming who avoid object oriented programming. These people are a statistical anomaly compared to the overwhelming number of experienced developers working in and on object-oriented technologies in the majority of platforms and languages. It's not even necessary to advocate for OOP anymore.
Perhaps if you were using functional programming instead of OOP I would give you points for this line of reasoning but you aren't.
Each to their own. FYI, I spoke at Code Generation 2010 at Cambridge University in the UK and generate much of my code from DSLs and/or other kinds of models these days.
Functional is good, pragmatism is also good. OO is in my view over-used and rarely the best solution.
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.
Or you could just leave off the closing tags that serve no purpose?
a) you're assuming everyone uses git b) you're assuming everyone uses a cli interface to git c) you're relying on the PHP linter to identify errors. A trailing newline character is not a syntax error, it's just a potential gotcha in terms of the output that is sent to a browser. d) you're assuming that any such fix (assuming you actually removed the newlines instead of simply linting the files) has to apply to all files
All of that, because you specifically ADDED extra content to the file in the first place. Seriously, what drugs create a mind state where that is "elegant"?
Did I say that? No. My assumption in that (concise) means of expression was that people can understand an example and extrapolate, ie. "if you are afraid of (easily detectable problem x), use the hooks provided by your version control system". Hooks exist in [an|ever]y half-baked version control system.
> b) you're assuming everyone uses a cli interface to git
Hooks work through any interface... and can often be applied on the server, so they remain constant for all members of a development team.
> c) you're relying on the PHP linter to identify errors
No, I was giving an example. The PHP linter can surely be configured to pick up lack of a closing tag, if not then it could easily be convinced to do so.
> d) you're assuming...
No, again. This is an example.
To re-iterate: if you want to enforce something, you enforce it programatically. You don't go around telling people to change their more-correct habits and shouting from the roof tops about how your perspective is technically superior, because, quite frankly, it isn't.
I agree that not having closing tags as a coding style might be admittedly handy if you're dealing with the average (ie. low skilled) set of people and a crappy development process, but it's not something to aspire to - or defend.
> Seriously, what drugs create a mind state where that is "elegant"?
Drugs. Mmm. Don't want to get on to a tangent now, do we?
Objectively, elegance is correctness. Good development process is elegant. In fact, it follows that elegance in process is more important than elegance in code, because it produces demonstrably correct code as a side-effect. This is the same "one level up" power-of-abstraction that code can wield on data, or LISP can wield on itself. Sorry to have to spell it out.
I hope this inspires you to investigate improving your development process.
So how is deliberately adding an un-needed line that is known to cause problems to the end of a file, only to have to implement a pre-commit hook in your vcs to remove it or trailing whitespace, an elegant solution.
Surely the elegant solution is to not type the line in the first place.
Bad developers will remain bad developers if they want - they are an unmovable force ... and this guy appears to be a horrible developer. If he ever somehow managed to weasel into a team of mine, I'd fire him with a quickness.
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.
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.
My point in mentioning this (little discussed, IMHO) property of web development in general was that many people's experience in PHP is limited to such projects, and therefore their notional understanding of software design from a maintenance perspective is limited; most of the community are not experienced programmers. IMHO this limit has been further amplified by a reliance on frameworks which are themselves often based upon fairly questionable design decisions, and are blindly worshipped as some kind of gospel.
Why on earth are you, the guy preaching simplicity, advocating for including absolutely useless, unneeded code at the end of every file?
How does that reconcile?
Now, if you open it and don't close it, that's gonna be working, but it's gonna be working using an assumption. Yeah? Yeah. So like, what is the mother of all screwups? The assumption.
So why would you ever remove it? Well now there's like all these other people claiming they wasted some time 'cause they like pressed enter a few times after the end of the scope. I mean, how much time did they waste? And was that because they were simply unfamiliar with the issue or execution environment? And who's fault is that? Really? It's not PHP's, and it's certainly not the set of other people who happen to bother being explicit as good practice.
A large number of text editors automatically add a newline at the end of a non-empty final line. This problem doesn't have to come up because of some explicit action.
... and doesn't PHP ignore it? I believe so. You actually need two newlines to cause issue, ie. "?>\n\n".
And, anyway, the solution is trivial and good practice anyway, on a number of levels. So why continue to argue? Sometimes people don't like to change their habits.
PS. Many editors can be configured to add "?>" for you, too!
What is the "assumption" I'm making? That my .php files will only have php code? YES! That's correct! Because we're not co-mingling PHP and HTML like it's 1999.
There is absolutely zero valid reason to have a PHP closing tag at the end of a PHP-only script.
Zero.
End of discussion.
And, on the face of it, it seems logical.
Unfortunately, it's not very good practice, for the reasons I have already outlined around relying on assumptions. (Edit: Oh, you missed the assumption - that the PHP interpreter will deal with your laziness)
For just one example, assume I have one file that produces a header, one file with some static content, and one file that produces a footer. For some reason, I want to refactor them in to a single file.
With explicit close, I can just concatenate the files. With the leave it out method (or, "look mom I saved two keystrokes after my MegaSillyStupidIndentFactoryClassMethod!"), you wind up with parser issues.
In short: If you want files with just PHP code in them, write files with just PHP code in them, and feed them to the PHP interpreter. If you want files with open tags in them, then use close tags.
"zero end of discussion i win mirror haha". Child.
The recommendation is to not put them at the end of files that declare symbols, e.g. class files (or function files if you're allergic to OOP), as those files shouldn't have html mode output anyway.
Let's also hope that no noobs that were doing, or trying to do, the right thing (formal company coding practice aside) were negatively impacted in the process through performance reviews, perception, compensation, or otherwise. We understand that best practices are subjective to a degree, and that features of any language or platform will be abused. I also take this opportunity to encourage the PHP developers to add features that they believe solve real world problems and continue to make life easier for other developers.
slams gavel
Thank you for watching Coding Court lmao
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.
Thanks, much appreciated.
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.
In hindsight I think having this just work for a lot of people is where PHP trumped perl and ruby in a way.