Going Back to PHP
pathdependent.com
pathdependent.com
PHP is also not tuned to some fitness function; it tunes its users. In exchange for not having to understand abstraction or OO, you get to learn the wierd quirks of thousands of inconsistently-named functions that live in a shared global environment. Sure, the number of "concepts" you have to know is low (no closures, no MOP, no lexical scope, ...), but the number of inane details you have to know is high. PHP shows that people would rather understand the exact details of arguments to a function instead of understanding abstraction and metaprogramming. (Similarly, people like to cram for exams without really understand the subject matter.)
That is fine, but unless you are "people in general", you are missing out on a lot by "choosing" PHP.
(Deployment is always a big issue. Do you really want to market your app to people that can't even run a package manager, "cpan" or equivalent, and so on? I find Perl perfectly easy to deploy. If I can't "apt-get install" the app, I type "cpan AppName", wait a while, and my app works.
Additionally, users that find deployment too hard unless it's "untar this and click pictures" are going to require a lot of support but aren't going to contribute a lot of code back to you. So maybe this isn't the best optimization to make.
Finally, why not JSP for this? Startup Tomcat, edit code in a web page, and boom, your "app" works. It ain't pretty, but it's better than PHP. Tomcat is no harder to setup than Apache + mod_php either.)
I disagree. While yes, the function names and parameters are not always consistent and easy to remember, the point is they don't have to be, because it takes very little time to type "php.net/thefunctionorclosetoit" into a browser and quickly reference whatever you need.
Add a smart IDE that gives parameter hinting into the mix and you don't even need to do that most of the time.
Yes, PHP is a simple language but in many ways that's a virtue not a curse. Jrockway is right about PHP's inconsistency but that doesn't exclude one from building solid software in the language.
Yes I realize PHP has made strides in some of those areas, but its mostly too little too late.
Java has interfaces and namespaces. Both C++ and Java have static typing, which is a tool for building certain kinds of large scale software projects (dynamic typing -- combined with an actual type system -- as in Python, Ruby or Lisp -- is another tool).
Lastly, Java (as well as PHP) are garbage collector. C and C++ don't -- yet many large scale software projects were created without a garbagage collector. Does this mean that you don't gain a lot of power from a garbage collector?
C++ and Java are not examples of powerful programming languages either. You don't use them because they're the most powerful and elegant programming languages. Typically, they're used out of HR considerations ("it's easy to hire Java programmers"), performance requirements (C++ is fast; properly tuned JVM can be at most 10% behind C for applications which don't require a large heap) or libraries (although availability of other languages on the JVM overrules that argument as well in many cases).
Hate to be blunt, but you're speaking as a Blub Programmer. Sure, you can get things done in PHP (or in Java, or in C++) but there are languages out there with a greater amount of power that you willingly neglect. That's sad.
Likewise, I can use multiple inheritance in C++ exclusively only to mimic interfaces (as purely virtual classes) or Mixins (and in fact a lot of corporate style guidelines, e.g. Google's explicitly say that), but it isn't quite the same as having these as language features.
I never claimed they were, in fact I purposely lumped PHP in with them. I'm not ignoring other languages, but the these criticisms against PHP are entirely wrong. There are languages with a greater amount of cleverness, I agree. And yes, I probably would rather be programming in Python at this point. But PHP isn't bad because it lacks closures or mixins.
The problem with PHP is not one thing that it lacks. It's the complete lack of design in the language. Everything is tacked on, and the sum result is quite ugly. Certainly it's a usable tool, and you can build large scale systems with it, but there is no language that's as much of a mess except for Perl, and Perl at least is incredibly powerful.
If you want to write clean, large-scale applications, you are going to need abstractions that those languages don't have. (Too bad CL never caught on, that would be perfect for what people use Java and C++ for...)
That's pretty much false given that nearly all large-scale applications are written in C and C++. Every operating system, every web browser, almost every type of server software, and most desktop software. You might not want to it (I prefer C# for desktop development) but it's possible. And most large-scale web software (Facebook, etc) is written in PHP. So perhaps all those developers know something that you do not.
All those features are just not necessary. They're nice to have, perhaps. You can shoot yourself in foot with them, also possible. But you can build really great and clean software without them. And you can certainly build a massive ball of mud with closures and mixins.
You can argue about closures and mixins, which are handy for people that know how to use them, but are not essential. But are you really going to argue against namespaces?
Ironically, the newer versions of PHP have most of those things, but most people who would care to use them left PHP years ago.
I'm not arguing against namespaces, I'm just saying for PHP they're more of a luxury than a necessity.
My guess is that you haven't actually done enterprise-level jobs using those languages before, otherwise you probably would have seen many of those standard techniques used in the so-called "blub" languages of C, C++, and Java, even if the language didn't provide the feature natively.
As for everything else, PHP can hang. I actually particularly like their implementation of closures. I know people fretted about NS but that is all much ado about nothing. Millions of keystrokes wasted complaining about which single keystroke is used as a NS delimiter.
If you must do some PHP and you've come from Python, Ruby, Scala, etc, do check out the Flow3 framework. You'll feel closest to home.
No. However, my template engine compiles to PHP's built-in template language.
> In exchange for not having to understand abstraction or OO
My PHP code is just as object-oriented as my C++, Java, or C# code. As for the functions, you memorize what you need and have a good IDE for the rest. One of the benefits of PHP is that there's a function for just about every common task and using them is really easy. Other languages may have the same functionality in a library, but the setup and calling is far more complicated.
PHP is a get-things-done language and it always has been. You can dick around with all the abstractions, frameworks, and meta-programming you want but often that's just more complicated and a waste of time.
There are a lot of complaints about PHP from people who've never even used it. They have bullet-point list of features lacking or strangeness and think they can make an informed comment. But I have built several large scale projects in PHP and at the time I started them most everyone's pet language here was too immature in the web space to consider. Look at Ruby, the tools of choice for deploying it and serving it up are constantly changing. I don't have time for that fire and motion. Maybe for the next project I will choose something else. But I think developers here would rather fawn over the pet language of the week than hear from someone using PHP effectively.
The only reason I can see for picking PHP for one's own internal applications is ignorance. Any language is better.
So I needed to start up a new project those years ago and it really wasn't the best time to learn another language. Ruby and Python were still a bit lame in the web space at that time. I'm not even sure Rails was out at the time; and if it was it was really new. I definitely didn't need to start a massive project on something that was very much untested. Performance and stability are also factors.
You are entitled to your opinion, but I don't find PHP to be all that painful. I've built up a large body of code and, more specifically, a coding style that makes PHP as productive to me as most other languages. For example, all my objects inherit from a root Object class that provides automatic properties: declare a method as setFoo and you use $object->foo = 'hello' to call it. My framework library is very modular and uses the autoload facility. I have a template library that is like smarty only less weird (and much less code). I have a few different database abstractions for different needs. Entity objects that can be loaded and saved. Classes for quick inline queries (similar to what you've used in other examples). An an abstraction for larger more complex SQL queries. In addition to basic templating for the UI, I also have something akin to ASP.NET user controls so I can built up complex forms just by adding tags to the template. The UI is connected end-to-end with the database so load, save, and validation is automatically generated (including client-side javascript) from a description of the data. I can push about a CRUD page in minutes.
So really, I have lots of reasons besides ignorance to stick with PHP at this point. Now, if I had to start the project again now, I'd have re-evaluate all my options but it would have to weighted against the body of code and knowledge I already have. I won't claim that PHP is better than any other language -- but it's really not as bad as you make it out to be. Just look at all the things that are possible in it!
No, PHP is a template language... just a very complete one.
> PHP is a get-things-done language and it always has been
No, PHP is more of a spaghetti language. Sure, it's easy to get something working. Make a tweak here, a bug fix there. If you need a quick knock off, just copy the files, copy and paste a bit, and you're good to go.
But after going through that a few dozen times, you quickly end up with a tangled mess of spaghetti code. Speaking as someone who wrote and had to fix plenty of code (from myself and others) like that, it's not something that I'd like to do. PHP makes it very easy to get trapped like this.
Like any language, it is possible to write good, well abstracted code. Unlike others though, PHP makes is very easy to write bad code. I don't know why... perhaps it's that the learning curve is _too_ low.
The newer versions are definitely trying to elevate the language, but I think that ship has already sailed.
That's a style of programming, it really has nothing to do with the language. I can cut'n'paste code in any language and I can write nicely abstracted modular code in PHP. Why are you confusing the two?
> PHP makes it very easy to get trapped like this.
Really? Why is that? What is so different about PHP than every other language in existence? You don't even know, do you?
> Unlike others though, PHP makes is very easy to write bad code. I don't know why... perhaps it's that the learning curve is _too_ low.
I'm not sure how the learning curve would have anything to do with it. If you already know how to program well, PHP isn't going to break your legs. You're not suddenly going to stop doing good design because of a few dollar signs, are you?
But anyway, well-abstracted PHP ends up looking like Java -- very verbose. Quick example; if you want to pass around a callback that has state, you have to make it a class, since there are no closures (instances of classes and closures are about equivalent). This is, however, a lot of typing to do something simple. Instead of a quick one-liner, you now have a new file and a new class, or, at the very least, an interface and anonymous class. Messy.
You can't abstract away that pattern, either, as there is no MOP (to auto-generate the classes as needed), or macros (to at least type in the code for you automatically).
Anyway, something that's just a few characters in other languages is now multiple files. Sure, it's well-abstracted and pretty easy to understand. But it's also massively over-engineered, and distracts from the task that you were actually trying to accomplish.
If you are going to write PHP code that looks exactly like Java, why not just use Java and get your 70x speed boost?
I think you sort of have that backwards, all variables in PHP are local unless you go out of your way to make them global (or just start typing into an empty file without any functions). I pretty much surrender the global scope. None of my variables are global except for static class members. I don't have any global functions, except static class methods.
> Quick example; if you want to pass around a callback that has state
I don't pass around callbacks that have state very often. I tune my programming style to the language that I'm working on. Often there are different ways of handling the situation in PHP -- it's is actually quite dynamic in places. I prefer to keep my pages pretty KISS anyway -- I can do hell of a lot (see my other replies) without needing stateful callbacks.
> If you are going to write PHP code that looks exactly like Java, why not just use Java and get your 70x speed boost?
I don't know, why are Java sites so painfully slow and all PHP sites so fast?
PHP is itself an abstraction. CPU instructions don't generate HTML, after all...
It is interesting that you assume PHP is the perfect level of abstraction. I think that is called "blub". You should try deeper abstractions some time.
Today I wrote a complicated database query joining by saying "$securities_rs->find({ security => 'USD', month => DateTime->new( year => 2009, month => 1 )})->messages->users->count" to see how many users looked up data on the USD for 2009/1. It is one SQL query, and there is no speed hit for writing it this way. A bit of abstraction made my app infinitely flexible; any query I can imagine is just a line of Perl. Abstraction is good.
Don't think that pounding on your keys as fast as possible makes your productive -- it doesn't. Thinking about your application's needs and designing your code to be easily tweaked to fit those needs is what you really want to do. When you have a mess of SQL, HTML, and PHP all in one file, you are stuck with what you wrote forever. When you abstract things, big changes only involve a small amount of code.
It's interesting you assume I said that, but I did not. In PHP you can have all kinds of levels of abstraction (and I use a multitude of levels). It is just as interesting that you assume most levels of abstraction are not possible.
If you call that a complicated a database query, we're clearly working at different levels. Get back to me when you hit 100 lines of SQL.
> I think that is called "blub". You should try deeper abstractions some time... Don't think that pounding on your keys as fast as possible makes your productive -- it doesn't.
The self-righteousness and ignorance here is absolutely astounding.
Your initial post called this "a waste of time". That is why I assumed you didn't do it. If you do do it and think it's a waste of time, you are probably doing it wrong, as the rest of the programming community disagrees with you.
Also, you have 100 line SQL statements embedded in your PHP programs? That is the wrong level of abstraction.
The point of my abstraction is that a quick one-liner is the same mental complexity as your supposed 100-line statement. The idea is that most of the complexity is abstracted away by specific names. You compose the specific names into something that ends up being physically complex, but mentally simple as you are reading your code.
Anyway, probably not worth arguing with you, since you are quick to make personal attacks, aren't consistent with your own ideals, and won't discuss anything specific. (Well, I guess you will discuss how many lines of code something is.)
> Also, you have 100 line SQL statements embedded in your PHP programs? That is the wrong level of abstraction.
If you need to calculate payroll against a schedule of appointments consisting of elements that need to be calculated as a flat fee, percentage, or sliding scale of appointments and you need to return results in real-time than it's the right level of abstraction. And when you actually need to mix in values, constants, and even function calls from the software into that SQL statement, you need something very different from your example.
"The point of my abstraction is that a quick one-liner is the same mental complexity as your supposed 100-line statement."
The same technology that allows you to make quick one-liners of moderate SQL statements would balloon my 100-line statement into a 200 monstrosity that would be impossible to follow. There are trade-offs with abstractions. Look at Rails, absolutely great for certain types of projects but when you need to do something outside of the box it gets very complicated to work with.
"Anyway, probably not worth arguing with you, since you are quick to make personal attacks"
You're the one making a lot of assumptions about "PHP programmers" that I could take offense with. I really don't think pounding my keys really fast makes me productive. Or that my HTML, PHP, and SQL is all in one file. Or the countless other things that you've said. Really, if I was black would you think I talked all gangsta too?
> and won't discuss anything specific.
I was just very specific, enjoy.
Even its supposed deficits are advantages sometimes. PHP stops you from a lot of temptations to go non-REST. Anyone who's seen a Java project where the web server is spawning multiple threads per request can understand.
It just gets incredibly annoying when you try to do anything complex with programming logic. Due to its rather low ceiling of abstraction, PHP encourages you to cut and paste rather than refactor. Again, not actually a problem for many, until you get to a very advanced stage (say three years) and how many projects even last that long?
I'm a Ruby guy, but I do recognize that PHP deployment is generally fast, smooth and easy.
But yes, generally Passenger does the trick.
It must be me, though, because every time I mention it, someone accuses me of being an idiot or trolling.
Small websites with low cohesion between pages can probably get away with scp or rsync and nothing else. For a more highly trafficked website, you'll hide server instances from the outside world as you update their files and configuration. But this still isn't rocket science.
I haven't done PHP work for almost 5-6 years, but when we did it, I had post-commit scripts set up in SVN (or was it CVS back then?) that if a commit was tagged "production" would trigger the production server to perform a fresh checkout. That was the only deploy step needed.
Funny, but you can get the same type of setup working with any language. Scp a WAR file into the appropriate Tomcat directory and your Java project is good to go (no reloading of the appserver required). Or, if you have auto-reloading of modules setup in Python, you can do the same thing.
So, this type of deployment isn't just for PHP... but with PHP it is the default (only?) method.
I should have been more precise. I should have said the vast majority of web development is not complex, not web development is not complex. PHP is a good fit for the majority of projects. For exceptionally large projects (the far right of the distribution), the weak abstraction may impose a penalty.
Facebook, Yahoo! and lately (at least, looks like) twitter (that's just a guess after seeing their server-status pages) do use PHP. I do, also.
You can build huge projects using a self-made (or external maintained) abstraction structure fitting your needs (database, data clustering, middleware). Or just a countdown page with the days before the next party (?). And, in both examples, it wouldn't be slower to code things with PHP than with RoR.
Two of our oldest clients who also happen to be the busiest and most profitable have been with us for 4+ years, and have been requesting feature changes, etc., without a total rewrite.
So, from my experience, enough.
Ok, maybe PHP 5.3 has this now, but previously, the lack of anything lambda-ish made some refactorings just impossible. Even with Java you could make a functor that, while ugly to code, would be reasonably performant.
As your comment shows, PHP spent most of its life as a procedural language and it took a few versions to get objects right. And being not-strongly-typed, refactoring tools are necessarily incomplete or primitive. I just went Googling and it seems that many PHP devs think that refactoring is the same thing as applying a regular expression search and replace to their codebase. Compared to what's possible with Java plus IDEA or Eclipse, it's no wonder PHP devs hate to refactor.
Lastly: PHP encourages you NOT to separate presentation and logic. This is why big PHP sites tend to use some other templating language even on top of PHP. The barriers to refactoring when presentation and logic are commingled should be obvious.
Ahhhhh, Java.
Is this a stated policy, or are you inferring it based on the structure of PHP being embedded in HTML?
There's nothing about PHP which prevents separating the two. There are even the shorter tags and braceless syntax, which are especially friendly to templating. Eg,
<? foreach($pages as $page): ?>
<h2><?= $page->title ?>
<div class="content">
<?= paragraphs($page->content) ?>
</div>
<? endforeach; ?>http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
I can cherry pick: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
too: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
My favourite chart is still this one though: http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
If that doesn't show how optimized Erlang is for certain use cases, nothing does.
It's also worth noting that where PHP does well is in direct calls to C libraries; compare the C version and PHP version of pidigits; they are almost identical. A few languages do as well with their native numerical tower, which is very interesting.
Specifically?
(I am pretty sure GHC uses GMP for its core math routines, though.)
Exactly, so I don't understand in what sense we could say GHC is an example of languages that "do as well with their native numerical tower"?
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...
And that PHP :: SBCL webpage has a link to "Overall Performance: PHP is rarely the bottleneck (HTML slides)" ;-)
I've never felt a strong repulsion to any language like I do with PHP and I wonder why. I think at the core of are these facts: it's optimized for web development, doing anything complex or CS/math intensive (developing algorithms, doing off line computation, systems programming) is sometimes possible, but always painful. I've played with PHP3 before college and other than what I've learned in a databases course, very little what I've learned in a university seems to be applicable to routine PHP programming. It doesn't feel like actual development.
Ironically, PHP seems to work very well in conjunction with more powerful languages: Yahoo, Facebook and others are built with PHP as essentially a template layer, with Java/C++/Erlang/Perl/Python on the backend. Perhaps the fact that coding PHP doesn't feel like software engineering is it's greatest asset. It's a language that a web developer can immediately be productive in. Yet it also exposes what is often tediousness and triviality of most web development. I remember first playing with emacs, SLIME, cl-sql, mod_lisp and UCW: while I was writing a web application (something PHP is well suited for), I felt I was excercising my brain a great deal more. To a lesser extent it felt true with Python/CherryPy and Perl/mod_perl.
Perhaps what makes PHP successful at Yahoo and Facebook is that they're serious, well-funded technology companies who are able to attract talented developers (who can take advantage of PHP's easy interoperability with C). An early stage start-up choosing PHP seems to almost doom itself by attracting a crowd that treats PHP as Blub (rather than as a sometimes appropriate tool), or in less refined terms "script kiddies".
Though not as satisfying as using source control and having a one command "deploy" that's just as quick as SCPing a bunch of files.. I can deploy - to production - local builds of my Ruby projects in seconds.
There are no significant advantages to using PHP or disadvantages to using Ruby or Rails presented in that blog post, even though it tries to make it seem that way. (And on the library complaint, the Ruby libraries that came along for things like S3 and EC2 are better than the official ones by a long shot.)
Despite that, different strokes for different folks. Use what works for you and all that!
I only ever used the SCP method when I did PHP stuff, but the projects were never anything that big. Now that I do Rails all the time, having a tool like Capistrano is amazing. 'cap deploy' copies my code, changes the symlink, updates my database schema, notifies my error reporting, restarts my webserver, and cooks me dinner.
Okay, I exaggerate. But seriously. Automation! It's awesome.
But I mean, do whatever makes sense for you. PHP apps are good for business for us. =)
I don't care.
Here's the thing: good engineering means that you should automate as much as possible. That way, everything is consitant. One command deployment is amazing, regardless of your technology stack.
[9:28pm:/playbook] DIVISION:tqbf [0:279]% cap deploy
the task `deploy' does not existI would say better designed, but the engineering definitely leaves a lot to be desired. Here's hoping Rubinius gets finished one day.
The inconsistent function library definitely gets annoying, but I guess that's why PHP has such excellent documentation. Using Eclipse PDT code hinting also mitigates the API annoyances.
I've regretted that decision many times. Not all MVC frameworks are created equal, and I can say from painful experience that Rails is far superior to CakePHP. We got the job done, and I may have been right that I was more productive in PHP back then than I was in Ruby. But three years later, it is far more difficult to get things done on this web app than if it were built on Rails.
I'm not one to engage in language wars, and I still enjoy coding in PHP. But if you want a great framework, I'm still not sure you can beat Rails, and I really don't think there's anything in the PHP world that can.
Anyway, the main issues I ran into were all related to database queries. This application was not a standard CRUD-style app at all, it has a lot of pretty complex queries for building reports. I found the way that CakePHP deals with joins and associations really clunky and hard to use compared to Rails' ActiveRecord. I'd often have to write the raw queries and try to shoehorn them into CakePHP's ORM objects.
I just found myself frequently frustrated with the way it was working. It's been too long since I really worked on it for me to be able to give much more detail than that (also, it probably has improved a lot since then too).
That said, using it as a web framework still made coding the app a heck of a lot easier than it would have been without it. Also, I found that it really improved my PHP skills, I picked up a ton of good stuff from using it.
I mostly work on larger projects, so application updates are usually simply a pull from the repository. It is usually a bigger hassle to get a smooth transition of the database schema, file-system storage or anything else that holds data.
For the few rails projects I developed, I used capistrano but for small projects this felt unrewarding. Tangentially (to git pulls), I did notice that PHP developers favor SVN to git, which I don't like as much.
I can attest to this. I spend a lot of time working with PHP with a lot of different people, and almost every single one of them uses SVN for deployment. I'm not sure if this good practice or not, but it's just so convenient.
I don't really understand why you'd prefer to deploy over SCP, either. You know what's really trivial? "cap deploy"
As far as speed goes, I think of Ruby as some sort of investment, in that I believe Ruby's 2.0 era will surpass PHP, and perhaps come close to Python.
But will any of them catch up to JavaScript :-)
Then there is the mass of programmers that could witch from PHP to something better. All they want is a mod_please_make_ruby_simple that is, like mod_php but for Ruby. You install it on Apache, and all the pages called .rhtml will get executed with the trick of things outside <? ?> being translated into echos.
This module should also provide, automagically and built-in, support for all the obvious stuff like file uploads, MySQL bindings and so on.
I understand that PHP got this right for the masses, but can't understand why no one is trying to do it the right way for other much more powerful and elegant dynamic languages.
For a serious app, I'll have to start paying, but the prices seem worth it to me because they're saving me a lot of time. Maybe it's expensive compared to other hosts; that I don't know.
I want to create "yet another" social networking site for a niche market, and am trying to figure out what technology would work best for this space.
I've been using asp.net for the last several years, and used to code in mod_perl, java, etc. But, I don't have any experience with the newer open source languages. I want to pick what's a good fit (even if I have to learn a new language). I know these are just basic details, but would greatly appreciate any feedback.
Thanks! (long-time lurker, first-timer poster)
I wrote about Java once on my blog. Never again. That is a crazy language community.