"(And strictly speaking, Facebook isn’t written in PHP; it’s written in a C++ macro language with a striking resemblance.)" I'm a Facebook engineer who works on the HipHop compiler and HipHop virtual machine. It's in PHP, absolutely full stop. It's amazing how much the fact that g++ is involved somewhere in the toolchain confuses people in this matter. C++ is just an intermediate representation; the source language r…
Do your engineers use the PHP interpreter in development (for rapid prototyping) and HipHop-compiled PHP in production (for speed)?
PHP: A fractal of bad design
161–170 of 514 posts
Re: PHP: A fractal of bad design
#162Earlier quoted context omitted.
I posit that one of our modern "Things You Can't Say" is that the widely-held belief that the world would somehow be better if every single average Joe learned to program just might be totally bogus. As was pointed out by djmdjm below, there are Real Consequences when amateur hour overflows into the real world. In many cases it simply would be better had many of these apps not been made by the unskilled - even if tha…
You can put up whatever barrier to entry you like. Invent a certificate for Haskell programmers with Ph.Ds. Require everyone who works on your website to have your certificate. Have fun. But most of the world will tell you where to stick that certification and will cheerfully walk around your "barrier to entry". Then they will hack together a web page using whatever programmers and tools they can find, certified or n…
I wonder what the costs of, say, the Gawker password database breach were? Or perhaps the Sony DRM rootkit on CDs? (Or Apples unpatched Java bug?)
What if the people who wrote and/or deployed the code knew (before they shipped/installed it) that they were going to be held responsible for the costs of any future failures? My guess is we'd then have training and certification and insurance, and professional organisations rising up to certify people as being skilled enough to qualify for insurance for themselves and/or their companies. Much like "Engineers" (who's titles the software industry loves to assume) or "Pilots".
I can torture the "Pilots" analogy further - much like you can do very little training to get a car license, perhaps you'd be allowed to write software that affects only a few people at once, your family and friends, perhaps a colleague or two, even occasionally a stranger, but never more than 6 or 7 other people at once. If you want to store data for more than 6 or 7 people, you need a different class of license - a mini bus license for a dozen or two, then a full bus license, then a train or passenger jet license...
Who _should_ be held responsible for a website's password database getting compromised? At what stage in the progression from "shared GoDaddy hosted out-of-date-wordpress blog about my cat" to "Gawker network with a million or so login credentials inadequately secured" do we draw the line and say "Here is the line in the sand across which more care needs to be taken, and lines of responsibility drawn up and accepted"?
'Cause _surely_ there _should_ be that line somewhere, right?
Re: PHP: A fractal of bad design
#163Earlier quoted context omitted.
Please enlighten me! I'm interested in correctness. The "non-programmers" remark refers to a quote from the PHP 2.0 documentation. I tried to minimize the editorializing.
> Operators are very fragile in the parser; foo()[0] and foo()->method() are both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t find mention of a fix for the latter. The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works? > == is useless. Actually, it's not useless. It does have a few stupid edge-cases and I will admit that. But in mo…
For the most part you've defended PHP's behavior as design decisions or offered workarounds. Workarounds just demonstrate that the language is Turing-complete. Design decisions are only okay if they actually make a useful tradeoff; these generally do not.
I can give you individual responses if you really want, but I suspect you won't be swayed no matter what I say. I will comment:
PHP doesn't need a module system? What? Once your program consists of more than two files, you're going to want to import stuff from one into the other in a structured manner.
Re: PHP: A fractal of bad design
#164Earlier quoted context omitted.
I find it odd how many people keep saying it's that simple to push PHP code to a box and get it working. Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in b…
Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc. Although PHP suffers from this, I'm not sure it is alone. I suffer a lot of pain sett…
I'd consider myself a seasoned PHP dev and it always takes me a few hours to figure out what happened when I get the white screen of death.
XAMPP isn't any sort of solution to this, because not all servers are configured in the same way that XAMPP is (and the fact that they compile in most packages doesn't help).
Developers at a local makerspace did a project last year using PHP, and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.
Understanding how to set up virtualenv isn't trivial for a beginner, but that doesn't stop a beginner from jumping into my python projects with no pain. All they need is to get easy_install (which is included in all distros I've seen) and do a git/hg pull (both probably also available from distro). The rest can be handled by a shell script in the repo that grabs pip+virtualenvwrapper, sets up the virtualenv and installs all the required packages. Then you tell them "if you need to work on this project, just type `workon projectname`", and with that they're ready to start hacking.
Re: PHP: A fractal of bad design
#165is there a major new startup that has been built with php in the last couple of years ? can you name one ? http://www.reddit.com/r/PHP/comments/rh3u2/any_new_major_sta...
Re: PHP: A fractal of bad design
#166Earlier quoted context omitted.
I find it odd how many people keep saying it's that simple to push PHP code to a box and get it working. Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in b…
Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc. Although PHP suffers from this, I'm not sure it is alone. I suffer a lot of pain sett…
I started writing a long rant which essentially boiled down to exactly that - PHP may be shit, but so is everything else. I hate all the languages that we're stuck with, and every time I start a project it's more a matter of picking the least shittily inadequate tool for the job than a matter of picking a language that I actually like, because there are none. They quite seriously all suck, very badly in most cases. The pain comes in different places, in varying degrees, but it's always there, whether it's coding pain, tools pain, ops pain, installation pain, documentation pain, etc. I have yet to find a development stack that didn't make me want to scream "fuck!" at least a dozen times over the course of a week of using it.
The real problem with most non-PHP stacks is that they front-load that pain: I have to say "fuck!" and hit Google many more times before I see a page generated from Ruby, Python, Scala, C, Java, or Haskell running on my webserver than I do to see a dynamic PHP page. Is it any surprise people tend to go with PHP pretty often, given that?
I think detractors would be wise to focus a little bit more about what's awesome about PHP, rather than what sucks about it (there's a lot, nobody argues otherwise). Because there's got to be plenty that's great about the language (or perhaps the environment overall) if it attracts people in such large numbers. We should be trying to add that to other languages/environments, not merely looking down on the newbs that still use PHP.
Re: PHP: A fractal of bad design
#167All those words, and yet the word template only appears once. And that's to assert that PHP has: …no template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program. As if that was a bug and not a feature. PHP succeeds because there is one PHP templating syntax and it is called "PHP" . PHP started life as a templating language, and that's where its soul lies. Which is important,…
Is there something about consistent naming, or consistent behavior of different library functions, or consistent syntax and operators -- they can be lenient and type-coercing, but consistent, like Javascript's -- that would make it a worse language for people to wade into in the form of templated HTML? Of course not. That's what irritates people, the endless parade of bad design decisions that appear totally bad, with no upside, where they could have just as easily made a good decision and didn't.
Re: PHP: A fractal of bad design
#168Re: PHP: A fractal of bad design
#169If PHP really is so shitty, can you please in any other language or framework of your choice finish the following project in 10 minutes, Be able to put a . inside any folder where your apache/nginx serves fiels from, then make your file give a much nicer file listing than the default of nginx/apache with possibility to comment on the file (using a __comments/directory and text file for each comment and sequence numbe…
Re: PHP: A fractal of bad design
#170Didn't we all go through this? 1. Ooo, PHP is awesome, I can make stuff happen on a server! 2. Hm, well, PHP has its problems, let's open source a microframework to fix it! 3. Oh my god, PHP is horrible, let's rant about it on a blog! 4. Who cares that PHP is horrible? It's the application that counts. OP is at step 3, currently.