As another startup in Atlanta trying to hire good PHP developers, I can sympathize entirely with MailChimp on this one. I have been searching for months for local PHP developers with experience doing TDD or other agile/modern practices and it is extremely difficult. If you are one, please feel free to contact me.
I think good TDD/agile/architecture cultures are more prevalent in ruby/python but as those languages have become more mainstream the quality of the average dev in those environments has dropped quickly. A few years ago only really good devs ventured into ruby stuff. Now everyone is trying it as the tools have made the language much more accessible for the average developer. I am seeing more and more programming mistakes in the ruby code I dive into than I used to.
Language choice doesn't matter too much from a technical perspective. It matters from a practical perspective. Consider the jQuery/prototypejs war. Prototypejs was technically superior for a long time, yet due to jQuery's more accessible plugin culture and prettier web site they were over time able to build a more robust community and took the mindshare lead in the js space. I still think one of the core reasons ruby/rails and python/django got big is that for a long time there was only one major framework available for the language and this caused a better community than the php landscape, which pre-dated frameworks by a long time (this happened to perl as well). So there wasn't "one true way" in php to build apps quickly, and this hurt the php community when rails got big. I think as a community we lost a lot of talent to ruby/rails in the last few years.
Bottom line is that accessibility, pervasiveness and low-learning-curve are critical to the initial and continued success of any platform, whether it's a language (ruby > php > perl), OS (ios > android > rim), etc.
Language advances in PHP (circular gc, traits, closures, etc) have brought php's language capabilities forward enough that it's a respectable platform for sticking with. However, you can't fix the community really since it's so fragmented. Fortunately some frameworks are getting enough traction to have rich ecosystems, and that's definitely a great thing for the language and the community.
Have you tried hiring good devs and then let them learn php, rather than narrowing your pool of candidates by only considering good devs who know php well? I mean, the latter may be preferable, but the former will often do.
I have not yet resorted to that. My concern (which is possibly unfounded) is that it would take significant investment before the productivity gain made it worth it. Then you have the risk that a newly trained person would leave the company as well. Also, I am not sure that a good developer from another language (like ruby/python) would consider using PHP on a day-to-day basis due to the perception of php as a crappy language.
I'd argue it's completely unfounded. PHP is the easiest language in the world for someone who is reasonable at other scripting languages, because there aren't very many new or weird paradigms that it forces on you. I last touched PHP in high school but haven't had any problems readjusting to it here at Facebook. In fact, I'd wager that very few of the people in Facebook's bootcamp program right now came with any of the experience you're looking for.
PHP is very easy to read, very easy to pick up. However, it is full of bizarre edge cases. It seems like every function definition is followed by at least 3 comments saying "Just so you know, you will try to do this - > PHP actually does this."
Alternately there are 5 comments showing boilerplate for the most common use case, and none of them are quite what I'm looking for.
Compare to Python, 9 times out of 10, the boilerplate 4-line example (in the primary documentation) is exactly what I'm looking for.
I think PHP might actually have a good language lurking inside of it, but someone would need to rewrite most of the standard functions and classes by going through the comments on their documentation and asking "Why doesn't this function solve the problem this bit of boilerplate solves?"
Thanks for your thoughts! I can see your point. I think mainly I was trying to get away without having to do training, but clearly that isn't working out so well.
Can I ask you what your language of choice was before FB and would you have taken a php job somewhere that wasn't FB?
When you say "having to do training".. A great programmer don't need "you" to do the training. Just give him/her a couple of days to read your codebase and learn the language. Anyway, even if it was the best PHP programmer, you'd still have to walk through your architecture and important design decision. So, at this high level, it's not important at all whether the guy/girl understand the inner details of PHP.
And, might I add, PHP is so easy to understand and read.. You don't even have to know PHP to read the majority of code written in it ;-) Compare that to, say, haskell or scheme, where it's a whole new paradigm.
This is a crucial blunder from all no-tech people I know who are trying to hire great programmers. Seek Great Programmers, not Great "insert a language" Programmer! A good programmer will be good in any languages; a bad one will be bad in all languages.
If I had to choose I'd probably say C or Python, but language wasn't a very strong influence on my job choice (other than knowing that I wanted to avoid Java). That Fog Creek has done well with Wasabi [1] says to me that language is not the most important thing for most candidates.
I think you are correct that any good programmer could learn PHP (or any language, really) to be productive in a reasonably amount of time. All the startups I've been involved with hire talent over language experience. However, I think the hirer was correct in noting that a PHP job would not be the most attractive job in this period of high demand for engineers.
I've struggled with it and given up almost entirely because it's so hard to memorize. Surmountable with full time use, I suspect. Very inconsistent function names led me to either living from a reference book or constant Googling even when I thought I knew the name of the function I needed.
Please don't hire based on knowledge of a language or a framework. It's a bad habit, because the best software engineers span languages and frameworks.
I am not a super-dev, but I can write code in an unfamiliar language in a day or two (non-idiomatic, of course). Better people than I can do better, I am sure.
I am sure you will be able to find great engineers if you open up your playing field.
You may be able to write code, but can you understand code that was already written by someone who knows all of the idiosyncrasies of a language you're not familiar with?
I would actually say that the developer who has experience in a handful of languages/framework and is willing to learn php for the sake of a cool project/team/company is potentially a better developer than one that has just mastered php (note: not saying php dev == bad, but that multi-langage/framework dev that values problems over tools more typically == good). So by limiting your offering to just good php devs you may actually be driving away some of the best devs interested in working for you.
It's really not a bad way to go. You may still get reactions like you've come to expect from developers, but a sign of a good developer is whether after having that knee jerk reaction, they start asking about your technology choices and how you've implemented things. Essentially you want a generalist who is technology agnostic and is willing to roll up their sleeves and get to work in any codebase. PHP isn't that different from other languages and after a week spent learning the nuances with a little training help they should be able to be productive.
I'd love to chat. Please reach out to me - not sure the most proper way to do that in an HN thread. I am apinstein on GitHub or check out tourbuzz.net contact page.
I was at php|works Atlanta, but I didn't present. I have presented it at ATLPHP before. I've presented on other topics as well though and usually at least mention that I created phocoa during my bio.
Our position isn't just PHP actually, but that is our primary back-end language. Probably makes the other commenters' posts about multi-language experience all the more relevant. We do a lot of front-end work in Javascript and we use ruby a decent amount as well (rake, chef, capistrano).
Even developers that know PHP inside out have to learn your framework first. I guess a good developer would pick up PHP along the way.
As a side note, I never understand when someone says learning Objective-C makes iOS programming harder for someone who does not know the language in contrast to Java developers which can directly jump into Android development. The hard part is to learn the framework (Cocoa Touch vs. Android API), not the language.
I am amused by the perception that a pro software engineer is assumed to only be proficient in the programming language they used in their last job. If an engineer is applying for your job, talk to them and make sure they are a good personality fit for your team. They are probably going to take more time understanding your dev tools and procedures than boning up on PHP.
The motive behind that wasn't about people not being skilled outside their current language (which I agree would be amusing), but that I wasn't sure trying to pitch a PHP job to ruby/python/java developers was going to be successful.
I guess seeing all the PHP-bashing that happens in the world (especially on HN) made me a little gunshy about approaching high-level devs to work on our project.
Fortunately thanks to some very well-made points and stories shared on this thread, I am now optimistic that I should be able to convince devs used to "better" languages that working on a PHP project could still be cool and a good learning experience.
This thread has been really great for me. Thanks, HN!
My concern (which is possibly unfounded) is that it would take significant investment before the productivity gain made it worth it.
Anecdotally, I took a job as Rails developer some years back. I had zero experience with it before starting (Having worked mainly with PHP before), but because the environments are so similar (http is the same, gnu/linux is the same, mysql is the same, architecture and oop is the same etc. etc.), I was creating value after about three weeks and I would say that I was fully up to speed after something like 3 months. Consider that it can easily take the same time to get the business, the problem domain and your new colleagues to know, I'd say that the cost for my employer was close to nothing.
Now, I'm not saying that anybody can do this - I consider myself a fairly good developer and beside PHP, I have tinkered with a broad spectrum of languages, which surely helped my transition. And the point isn't that Ruby is such an easy language that it can be learned in 3 weeks either (In fact, I think it is a rather complex language). What I take from my experience is that a good (and diverse) developer, with a motivation can jump from related technologies with relative ease.
I do agree with your sentiment that it might be easier to sell a jump from php than to, but that is a different problem. If your project is interesting in it self, I'm sure you can find good developers who don't fret too much over what particular language they write in.
Every change of job I've made in the last 8 years has involved at least one change of language. In my mind a professional developer can pick up Perl or PHP or Cobol or Scala or whatever.
If somebody's got the attitude that 'Java sucks, I only want to code Ruby', that person's not a pro in my book.
The funny part is that when Rails and Django were rising to fame, it was argued that PHP was the better choice because finding developers to maintain the code in the future will be easier. Now that we are here, it seems it didn't turn out that way at all. Goes to show you should choose technology for technical reasons and technical reasons alone.
In addition to the functional programming techniques it offered (which are now handled by underscore in the jQuery landscape) its selector was much more performant than jQuery's for a long time.
The enumerables prototype took from ruby were really nice. I always liked being able to do things foo.map(function(p) { return p.length; }); jQuery's $.map felt clunky in comparison.
(this is all with the understanding that prototype adding methods to standard objects was dangerous...)
〉 I have been searching for months for local PHP developers with experience doing TDD or other agile/modern practices and it is extremely difficult. If you are one, please feel free to contact me.
I believe I meet your criteria but can only work remotely. I am currently looking so if remote is an option please let me know and I can send you more details.
Please reach out to me, I'd love to chat. I'm not sure what is the most proper way to do that in an HN thread. I am apinstein on GitHub or check out tourbuzz.net contact page (feel free to call).
My main beef with PHP is that the most deployed applications that use it are some of the most difficult to manage and messy pieces of code that I've ever seen.
I'm talking about Wordpress and vBulletin.
While MVC isn't the only valid design pattern, some varient of it is rather nice when working with websites and these two seem to ignore it through and through. Testing? What's that?
I know that better can be written in PHP, but for apps that I've had to deal with, PHP normally looks like an overpowered scripting language that's just a mess. I'll stay with Rails and Sinatra when I can.
Having recently created a theme for MediaWiki and then reskinning that theme for another install, let me just say... it is frightening.
MediaWiki is all over the place and the themes included in the install are just horrifying. Whoever made the original (monobook) theme should get slapped in the face.
I agree with you that WordPress and Drupal aren't examples of great code. It has to do with the fact that CMSes take a long time to gain traction and acquire a true community, and WordPress and Drupal were started at a time when MVC was almost unknown in the web community. By the time they got traction, the oldest code in the codebase was, well, ugly. Things that have been added to WordPress and Drupal recently are usually okay code-wise.
For many years now, more and more code has been moving to the client side. At this point, for me, PHP is just the glue between the database and the client side code. There's nothing left to hate. Move on already.
There still has to be a lot of glue logic on the server. When your client-side code calls something like "validate_purchase" on the server, you'd better have some trusted code handling that.
> When your client-side code calls something like "validate_purchase" on the server, you'd better have some trusted code handling that.
Why am I calling "validate_purchase" on the server?
Client Clicks Buy -> JSONP to Payment Gateway -> Gateway to Server (with all the info) -> Server to Client Confirming Transaction
All my server is doing is recording the transaction and forwarding the info to the client. The gateway is trusted, since they are processing payments.
I'm serious. This is where we're headed. Yes, you will have a hell of a lot of server-side code on the gateway, but that's a service, not the application.
Your payment processor isn't going to know how much anything costs. You'll need some (server-side) validation logic if you don't want people buying new high-end smartphones for a penny. Which event invokes that logic is immaterial.
> Your payment processor isn't going to know how much anything costs.
So?
> You'll need some (server-side) validation logic if you don't want people buying new high-end smartphones for a penny.
That validation logic should be expressed in SQL. It's really really simple. If inventory id and price match in your inventory table, insert into your transaction table.
Again, see my original point. PHP is just the glue for the database.
- the price changed in between the time the person added it to their shopping cart and checkout
- two people are processed for a payment on the last item in inventory at the same time
- there are different options on the item, e.g. color, that change the price
- other people bought the last item in inventory already, but there's an equivalent product at the same price
- the person bought the product using a combination of real money and gift card money, which the payment processor does not handle
- the person bought other things in the same transaction, e.g. a gift card, that do not have an inventory ID
Those are just a few cases off the top of my head, but the short end of it is that expressing all of this with a combination of SQL and client-side logic is just madness. If you're saying that we don't need to write business logic in PHP any more, I think you just don't work with the same constraints that most businesses do.
All of these, save for the payment processor one, can and should be done in sql.
I think you are uncomfortable with SQL.
Ultimately it is the designer's choice where the business rules are handled...but to abstract those rules to levels above where the 'business' actually happens seems like a poor practice.
'Business' does not just happen within the database! You will have to perform logic based on events that occur elsewhere, e.g. on the network or within outside data sources! And to say that something should be done in SQL just because it can is patently absurd--do you know how much performance suffers as soon as you start roping in subqueries and calculated values? Half of the things I listed would require stepping outside of indexed columns in awkward ways--that was kind of my point. Good luck keeping that performant past a few million rows.
In fact, I would love to see you design a query that branches on the condition that the item is out of stock and automatically returns the top 3 equivalent parts for each brand using a junction table containing equivalencies, ordered by a column in the junction table containing the closeness of fit. Go ahead, humor me. Then try to pretend that that query will ever stand up under scale.
OK, I understand your point a bit better now. You're basically talking about writing the backend in almost-pure SQL.
The main drawbacks I can see to that are:
1) Most developers couldn't write enough SQL to escape a paper bag. That's fine; usually, you don't need to escape a paper bag with SQL. The problem is that this only works for people who are very comfortable with SQL. I'm decent with it, and perhaps I'll lean a bit more that way for my next project, but I'm not seeing most people doing this.
It's also not quite as simple as you say, because multiple items are typically combined into one. This is many:many, so you'll need a table to cross-reference them.
So, you'll need to have a transaction table and a subtransaction table. The subtransaction table can match against inventory, and the transaction table can sum the subtransactions to make sure the total is correct. This gets a little hairy around foreign keys, but it's pretty easy to code around.
2) This example is fine, but for any transaction more complex than this, you risk tying yourself to a particular DB backend. That's probably OK, as the DB backend contains most of your app code: it's like tying yourself to Python on the backend. It's just something to be aware of.
3) This is likely to result in a large number of transaction rollbacks, due to price changes and whatnot. This might be OK, or it might trip anti-fraud features on your payment processor.
> Most developers couldn't write enough SQL to escape a paper bag.
Agreed, but you can split your SQL queries into really simple ones and glue them with PHP. What I don't see anymore in my code is a hundred lines of unbroken PHP. Actually, I don't even see a dozen. A few lines, SQL, a few lines, SQL ... that sort of thing. That's what I'm talking about.
You don't need to be puritanical, although of course, you can. That's personal choice.
> it also has dead-easy deployment, cheap and reliable hosting
Matters for a single 15 years-old developer. Deployment is never easy when you get do anything non-trivial, and the cheap hosting... hosting for other languages start at $5 or $10... The only cheaper hostage PHP has is free.
> good documentation
That's highly debatable. I've also seen the PHP doc comments being pimped, I could never find anything worth more than a laugh in that cesspool.
Regarding hosting I wasn't just talking about shared hosting. Setting up a LAMP VPS is just a couple of clicks. Compare that to setting up e.g. Django or Rails. I personally love Django, Flask, etc., but setting up a website is still faster with PHP (depending on your setup, of course).
Try to instruct a noob on configuring Apache for vhosts or adding users to mysql then come back and tell me the deployment story for LAMP is so good.
Node.js wins for deployment if you ask me. Node.js + riak handily beats the pants off of the LAMP stack. It's so easy I'll tell you how to do it right now:
1. Install node, ./configure && make && make install
2. Install riak, make all rel && mv rel/riak /usr/local && export PATH="/usr/local/riak/bin:$PATH"
3. Install your app: scp -r remote:/my/app /web
4. Install dependencies: cd /web/app && npm install
5. Run your app: node /web/app/do/something/cool.js
Back to my coffee.
(I'm being somewhat facetious and these instructions don't get you startup services and such, but I do believe that Node.js stacks are much simpler than traditional stacks and easier for devs that have to wear the sysadmin hat too)
They'll be puzzled when they copy and paste something but their vhost still doesn't work because they didn't, say, enable vhosts in httpd.conf in the first place.
If they can install and configure Apache on a remote server, they can install and run node. I don't think it requires any more skill to copy and paste different commands into the console and you don't have to edit any configs or ask questions like "what distro? does your distro configure apache for vhosts out of the box? do you have an httpd.conf or vhost.enabled? run nano and hit ctrl-o to "write out" the file..."
Honestly though I don't think noobs do these things anyway. They will just ftp stuff into a directory on their host if they're using PHP. If they're using node I think the easiest deployment scenario is doing a git push. So practically speaking PHP is still the easiest for a clueless Windows noob to use.
To use WSGI (which is what most people would use instead of mod_python) you have to write some lines in your server configuration plus a script that loads your framework of choice.
Compare that to getting CodeIgniter up and running: SFTP the files into the server, and you're up. No server configuration needed.
One could argue that this is not a feature of PHP itself, but that doesn't change the fact that "normal" PHP solutions are simply faster to get up and running.
(Read my tone here is debatish and not di^kish plz)
In what circumstances does the fact that a Hello World can be setup in 5 mins versus 10 actually matter?
We spend thousands of hours developing software.
Five mins versus 10 is truly moot.
Besides, you're going to get into httpd.conf to configure a vhost before long -- mod_php or mod_wsgi -- so it's not as if it's a hands-off experience with PHP.
That's what I get for being poetic. I've done a lot of python development but not all that much for the web. When i have, I used Tornado. Which is also really easy to get running.
Yeah, Django and Flask are just as easy (if not easier, thanks to services like Dotcloud) to deploy as PHP.
Let's take your VPS example. Install nginx, gunicorn, and your database of choice. Set up gunicorn to serve your app, set up nginx to serve static and proxy to your gunicorn instance. Do any app-specific setup.
That doesn't take any longer than deploying a PHP app, at least not for me.
Several PaaSes support PHP, too, so no major difference there. In a VPS environment, however, setting up PHP doesn't require anything - it works right out of the box - whereas Django and Flask require more packages to be installed /and/ require some lines of server configuration and a script that loads your framework.
In a VPS environment, however, setting up PHP doesn't require anything - it works right out of the box
Well, you do need to install the AMP part. Since you're installing and configuring three components, why not install and configure different ones? It's not more or less work either way.
If you're talking about AMI/StackScript-style pre-built VPSes, there are plenty for various Ruby, Python, and Node stacks as well as PHP.
Since when were the 15 minutes you might save by setting up PHP instead of a reasonable software development environment worth more than preventing the years of torment and pain you'll suffer from choosing the wrong technology?
Nope. You have to set up a webserver (Apache or whatever) and PHP. Then (to get on par with Django+virtualenv practices level) get some PHP framework of choice...
Sure, PHP comes pre-configured out of the box. But there are no real differences between `apt-get install python-django` (comes with a development web-server, runnable as ./manage.py runserver) and `apt-get install apache2 libapache2-php`.
Exactly. There are tradeoffs to be made when making any architectural decision. PHP may not be the right choice for someone, but it might for someone else in a different situation that values the characteristics you highlighted. However, it is ultimately a potential hire's choice what they want to grow their experience in.
PHP is what I've started with and after many projects in Python and Java I still come back to it whenever I need to get stuff done. I mean look at the array functions (http://www.php.net/manual/en/book.array.php)! Some consider this bad design, but I love this about PHP.
There are some good reasons to like PHP but the array functions in the standard library are not one of them.
* Arrays are created with array() as opposed to a more modern [].
* Arrays are not objects, so you have a ton of functions in the global namespace starting with array -- array_join() as opposed to $array->join().
* The functions are not consistent. Half of them don't have "array_" as a prefix. The order of arguments isn't consistent with other parts of the standard library.
I'm really curious about why you consider this a strong point of PHP.
I hear what you're saying about arrays not being objects and there's really no excuse for the conflicting ($array, $argument) & ($argument, $array) signatures of many functions, but regarding "array() as opposed to a more modern []:" whenever I read this I can't help but think "Who fucking cares??"
When people want to pick nits about this or significant whitespace it makes me think that there must very little variance between the languages if THIS is the issue that deserves scrutiny. Am I missing something about array() vs [] ?
It's not nitpicking to want consistency of convention.
When I work with an unfamiliar class in Ruby, or come back to something familiar (say, Array) after a long time away, I'll often not "know" the exact method signatures for what I want, but I'll just guess something reasonable based on my knowledge of the language and idioms. And, lo and behold, most often it works!
Having to "remember" (does this method use array_?) or "translate" is a mental tax; there's cycles wasted that could keep your mind in the business logic.
> When people want to pick nits about this or significant whitespace
> it makes me think that there must very little variance between
> the languages if THIS is the issue that deserves scrutiny.
For the record: this is not the issue that deserves scrutiny. The other issues are more significant.
However this "short array syntax" is representative of PHP's sluggish internal development process. [] is very nearly the de-facto solution for creating arrays, and yet the PHP core devs have, for two years, rejected[1] patches that implement it on ridiculous grounds.
This is one thing that really bugs me about the arguments against php. The language has fundamental flaws. Poor oop, no functional programming whatsoever, minimal reflection.
Finding the argument order for a method takes ~3-5 seconds. Its irrelevant. array() vs [] is actually a bigger deal as its indicative of php's verbose syntax. But its not a killer.
People like JS because it got the fundamentals right. The bad parts are just details. PHP is bad because it got the fundamentals wrong. But people still harp on the details.
Yes, PHP has fundamental flaws. But the only decent fix for that is to use a different language, and there may be many valid reasons why a developer is using PHP.
But the "details" grate daily. Poor reflection, no FP? Fine, you craft solutions that don't require them. But having to look up order of arguments for standard library functions is a pain in the ass.
PHP 5.3, which certainly does provide that, is more than two years old. (And it also introduced late static binding and a few other tweaks and benefits to make its OOP significantly better.)
Not to mention, some of the functions return an array, and some of the functions act of the array passed as argument. Unless you remember exactly, you'll constantly be checking the doc to verify the method does what you think it does.
Does it really matter to you whether array slicing is implemented as syntactical sugar as opposed to the array_slice() function? If so, why?
In my view the only problem with PHP array functions is the fact that the naming scheme is an absolute disaster (as it is all over PHP, for historical reasons).
Yes, it DOES. Syntax matters. Small improvements in a few places add up.
For example, let's say you've got a string like 4|1|45|343|22. You want to return a string with the last three numbers, but seperated by a comma and a space.
Small conciseness improvements snowball as the codebase gets larger. In fact, being unable to chain functions in PHP is actually my biggest beef with the language. If you could do
> In fact, being unable to chain functions in PHP is actually my biggest beef with the language.
That's just a lie or at least a horrible misconception, depending on your intentions. Furthermore, the example line you used to illustrate this entirely made-up inability of PHP does in fact work. You can do
What's that supposed to mean? That PHP devs don't actually have to use array slicing? That languages without a dedicated syntax for array slicing are unusable? Or that you prefer a syntactical shortcut and everyone who disagrees is an idiot?
I mean I'm with you on the fact that it would be nice to have this in PHP. I just don't get how you can argue this point to show that it's supposedly a bad language. The difference between
array_slice($array, -3)
and
$array[-3:]
isn't that important to a lot of people. Interestingly, this criticism never comes up when, say, C# or Java are discussed. Only PHP is treated this way. As I said: sure it would be nice to have this feature, but I wouldn't imply that any language that doesn't have it is unusable. Ruby and Python are fortunate in this regard, but this feature alone wouldn't sway my choice either way. In the end, the number of array slicing operations per line of code isn't usually that big.
It means that although it does not truly effect the languages effectiveness, it does negatively effect those who use it. Syntactical sugar exists because people have to use these languages. There is a reason so many languages of the same niche as PHP include array slicing.
"Or that you prefer a syntactical shortcut and everyone who disagrees is an idiot?"
No, not everyone who disagrees with me is an idiot. Just those people who read the sentence "Rather, it matters to me." and somehow think I mean "everyone who disagrees is an idiot", apparently missing the EMPHASIS ON "ME".
Imho, php arrays are not better but more convenient for the job: they are silent, not throwing exceptions when keys dont exist etc, they are all hashtables so you can use them as both arrays and lists, "foreach" syntax is better, nonexistent values convert to "" or 0 appropriately, you can do $a[1][2][3][4][5]++ without defining $a etc. Not better, just more convenient when you're in a hurry.
they are silent, not throwing exceptions when keys dont exist etc
I think this is a bad feature and causes bugs. In Python there's a fail fast feature, where it'll throw an error if you go past the end of an array. It's places like this were bugs creep in. In python, you find out that there's a problem with this array, in PHP you have to hunt around and only later look at the array X lines above where the bug manifests.
they are all hashtables so you can use them as both arrays and lists
Python dicts (i.e. hashtables) are better than PHP arrays. PHP arrays only have number or string keys, so you can't use arrays as a key in a PHP array. You can in python.
And then in a couple of months when you have to come back and figure out where that weird bug is hiding, you probably will wish that you spent a little more time writing your code properly. Just because PHP lets you write horrible code doesn't mean you should.
Drupal. Recently rumored to platform 1% of all websites. The codebase is clean (even cleaner in Drupal 7), and naysayers be damned the hook system baked in makes modular coding a breeze. Of course, code quality varies once you start looking at community contributed modules, but that's to be expected.
Drupal's core architecture is extremely dated. You might like the hook system, but it is in no way a replacement for dependency injection a la Symfony2.
Yes, by mine. I've spent quite a lot of time elbow-deep in Drupal. It is better code than Wordpress--though that is damning with faint praise--but does not really reach the bar of a Lithium or a Symfony2.
Now, it's certainly more normal-friendly than Symfony2 or the like by way of allowing non-developers to implement (a subset of) features, but I wouldn't call it programmer-friendly and I wouldn't use its internals as an example of good code.
Urm, no. There's lots to like about Drupal, but clean code isn't one of theme. I mean, it's not PHPNuke, but clear and logical it ain't. I'm saying that as lead dev on a drupal site that pushes pretty heavy traffic and has thousands of man hours in it.
Another developer introduced me to Yii when he got me on board for a PHP contract he needed help with. I was hesitant to take PHP work at first, because my previous experiences were harrowing at best. However, I found the framework was almost pleasant. It had a lot of the features I had grown used to in frameworks like Rails, and though I still have to wrestle with some frustrations of PHP, it is a minor annoyance as I go about writing good OOP MVC code.
I would personally pick another language if I were doing something from scratch, but the benefit is that it is a language others are already familiar with and so adding a framework like Yii isn't too hard.
If only they could get the docs back up to par! Things were sort of OK for 2.x, even if you needed some background in CodeIgniter to really understand everything, but half of the wiki for 3.x is empty pages with TODO's.
I still recommend that people new to Kohana start with 2.x because a framework is worth a lot less without quality documentation, when you have to go read the code all the time. Not that you shouldn't do that eventually, there's a lot of good code in there to learn from!
That's good but it also makes it annoying to work with it. I prefer having good docs which takes me 30 seconds to scan and find what I am looking for than having the better code in the world so I go with CodeIgniter instead (the new version is pretty good).
At least it's not ColdFusion... I'm convinced some websites out there use fake .cfm file extensions as a joke. No way they're actually using ColdFusion!
It's actually not as bad as that anymore. Adobe CF has traditionally been pretty poor (though it's better these days) but there are great alternatives now (Railo is a top notch open source alternative).
I wouldn't ever expect to convince anyone who had ever worked on an old CF site to move back to CF ever again (believe me, I'm still scarred from it) but it's actually pretty good these days (Railo, that is).
My experience isn't limited either; Rails, Django, Flask, .Net (Umbraco), CodeIgniter, Drupal to name a few. They all have their warts. I hate to say it but in my experience Railo (CF) is way more performant than any of them.
I have 5 years of coldfusion and I can't understand that people can like it. It's too much buggy (yes it is). I don't like PHP but I cant say that PHP is a lot better.
Fortunatly, this is my last month with coldfusion, and don't want to work with again.
That and utterly unreliable servers, to the point of having a process running under Windows to restart the server when it accumulated, say, 50 pending requests.
This seems to be a common essay from well-established companies who use PHP and then write "oh gosh we use PHP!"
The key here, as it states, is that they "built their own framework/libraries", which essentially means nothing to indie-devs and other small non-well-established companies who want to build something...
So the trend is simply this:
1) We use PHP because it's what we know, easy to get started with etc.
2) It gets us by while we build our business
3) Profit! Re-factor our codebase, in PHP!
Thus, the blog post should read: "Hey Mailchimp is doing awesomely, so we refactored our PHP codebase with our very own custom framework!"
It's not that PHP is all bad; it just lost the "framework wars" IMO, and I think when companies come out and state things like this, it kinda proves it...
Well yes, when you speak to experienced PHP devs that's their response when confronted with the "PHP sucks" argument -- they always say they have their own framework/libraries, which don't suck and thus in turn "PHP is fine"...
I don't think everyone is doing that (building frameworks), or can, or even should when they're other possibilities outside of the PHP world...
If you're in Atlanta you're near Georgia Tech. They're pumping out CS graduates, have undergraduate students looking for experience, and also have a pretty good internship program. It is not Silicon Valley but you're better situated than a lot of other places.
Damn, long thread. I use Java, PHP, and Ruby: whever gets the job done in the given problem domain. Not a fan of a technical monoculture at all. PHP has been the language that is fashionable to hate for years now, but I still love it for web apps.
The GP talked about "the given problem domains". One problem domain is simple, one-shot processing for plain old websites. Custom sign-up forms for stuff. Forms that email their data to some address. Homecooked personal-use search boxes that have "magic" functionality. All kinds of simple shit. These are deployed by FTP just fine.
Another problem domain is deploying something to virtually any cheap shared hosting provider. These very seldomly have e.g. ruby support. Sometimes, for all kinds of practical purposes, you don't get to choose.
You just bought your shipment of 1000 servers. Do you really think you ssh to each one, edit config files, and copy your code over? Nope. You write a computer program to do all that. (See: puppet, etc.)
At that point, it's equally easy to install a stack like haproxy + varnish + nginx + a bunch of CPAN modules as it is to rsync over a bunch of .php files, and therefore "it's easier to deploy" is meaningless. You click a button.
Not to pick on you specifically, but one argument that comes up quite frequently, especially in PHP vs. X discussions, is "I don't see how xxx feature of other language is beneficial." Well, the reason you "don't see" that is because you simply don't have enough experience yet. Deployment is the same way; a lot of people get by for years without ever "doing it right". But that doesn't mean the wrong way is right, it just means you haven't been required to get deployment right yet.
>At that point, it's equally easy to install a stack like haproxy + varnish + nginx + a bunch of CPAN modules as it is to rsync over a bunch of .php files
Ahem. I get what you are trying to say, but I think you're gonna have a hard time saying that Ruby is as easy to deploy "right" as PHP. Rsyncing a bunch of PHP files is a single shell command. Writing puppet or bcfg2 specs to deploy your six-tier web stack for your RoR app is a bit harder, it is most certainly not a button click out of the box, and neither process is necessarily more "right". It certainly helped the PHP ecosystem that deploying a LAMP stack is as easy as running three package installs and copying over some PHP files. The fact that a simple-to-understand, well-established process will scale you up to decent load before you need to get fancy will continue to make it an attractive platform.
The types of problems I usually work on are more complex than a single file form-to-mail script, but if I needed it, Heroku gets you up and running with Sinatra (or plain rack) in a single file.
But seriously, I find programming language fights to be mostly useless. Its like trying to argue English is more expressive than say French or German or whatever language. They all can convey human ideas, but each makes certain concepts a bit easier to express and others more difficult. In the end though, the thought or concept can be conveyed.
PHP started at a time when web development was not considered "serious programming". I mean, people switched to it from building GUI or console apps on C/C++ and Perl. It was fast, efficient, had convenient hashtables and defaults in place, and it was better than writing simple HTML files, but it was still considered "scripting". Nowadays, web apps are a lot more complicated, but web development is still messy: as HTML always stands in the way, it's still hard to abstract the whole web development process without restricting yourself to a specific mode of development and its limitations.
It's hilarious how most PHP programmers think they are exceptional compared to the rest. While most of them rarely code in any other language besides PHP/ActionScript/JavaScript/ASP. And virtually none of them read a serious algorithms book.
Java and JVM as reliable platform +1 just go whatever language you want Scala, Haskell, Ruby... here language doesn't matter. If you want to create custom web based application (not RIA one ofc) go django or rails, now it's more matter of taste both choices will give you a lot benefits, and ofc you can run it ontop of JVM. But if you considering building anything today on PHP (when you have sooooooooo fucking many better platforms) you are incompetent and plain stupid, because it will be a big technical debpt for the whole project.
I could live with sun+java but oracle+java? no thanks... it can be technically perfect, i really don't care...
> But if you considering building anything today on PHP (when you have sooooooooo fucking many better platforms) you are incompetent and plain stupid, because it will be a big technical debpt for the whole project.
I think we have a bunch of stupids like facebook and mailchimp... Php or any other programming language is a tool, a proven one. So if you can do some amazing things go for it.
"You use X then you are an idiot. Y is for masters !" approach is childish and proves that you can only use Y technology.
From the CTO perspective choosing a niche language is considered a much bigger risk because when your lead developer gets bored and quits you then have to scramble to find another lead dev who can quickly grab the reigns and continue. I've talked to many a CTO who have mandated PHP for exactly this reason, because you can throw a rock and hit a dev who knows PHP.
Oh, a snide question deserves an equally snide answer. =)
Probably better than finding a good dev in other languages for web development considering all the good PHP developers are still using PHP, and all the ones that couldn't cut it went on to learn the next LotM.
Honest answer: The same chance of hitting a good dev regardless of the language.
Unless you're Werner Vogels, in which case you mandate whatever the implementation team feels like using, as long as it scales and adheres to the service interface specifications.
I've heard Werner Vogels talk about this subject before. He chose Ruby for one of their projects specifically because they wanted very fast iterations, even though they new it wouldn't scale and they would have technical debt down the line. I don't think you are accurately describing how Amazon does things.
I don't know about the more technical debt stuff, sure if you go off and use all the parts of the language any old way it will let you make a mess but there is no reason you can't apply some of the same practices that something like rails enforces on you.
Agreed. Symfony2 is an excellent base for this reason--Fabien Potencier and friends are, as far as I'm concerned, the guys to look at for writing clear, maintainable, excellent PHP code.
It's not only Symfony2, PHP has a lot of high-quality projects going on: Zend Framework, Doctrine, Solar/Aura, Twig, Lithium, Jackalope, FLOW3 and probably much, much more.
While some of your other listed projects are okay (as it happens, Doctrine and Twig are both used as part of Symfony2), Zend is generally considered about as ancient as CakePHP today, and I don't really know anyone who recommends using it for new projects. Most of the "big-name" PHP projects out there are creeping horrors (I'm looking at you, Wordpress), and Zend kinda falls into that bucket.
Personally I'd be very wary of Lithium as the code looks pretty slipshod internally from a brief scan into it, but Solar and FLOW3 are solid projects.
ZF is from a totally different league than CakePHP or Wordpress. Yes, a bit ancient today but in many parts it's a solid, well-written, flexible and extensible code well-suited for more "enterprise" needs. Probably more "production-ready" than Symfony2 is at the moment. Plus: ZF2, which will require PHP5.3, is in the works so it should make the project more "relevant" again.
Didn't dwell too much into Lithium's code but saw they have some interesting ideas also based on 5.3 features, e.g. they use a sort of aspect-oriented programming based on closures and lambdas. Sounds cool, even if only for experimenting with different programming approaches.
ZF2 may fix a lot of the complaints I (and other folks) have with Zend, but right now it's really hard to recommend it.
It's actually pretty much in the same league as CakePHP: old and slow. Not much to recommend it right now. (Symfony2 actually can pull in Zend-based libraries on its own without a problem, which is why among the more sarcastic of us I've heard Symfony2 described as "Zend 2 but actually here".)
Well, Symfony2 itself only until very recently was using some of the ZendFramework libraries internally (and Fabien often praised ZF), which I would say comes as a proof that it is a solid code, even if it's obviously lacking in some parts comparing to younger alternatives. In many cases it's still the best thing in the market though (Zend_Search_Lucene, Zend_Pdf, Zend_Amf, Zend_Gdata come to mind).
Strongly disagree. Kohana is, IMO, rather poorly designed (while rewritten, it's still fundamentally all too similar to CodeIgniter for my liking). There is not a strong focus on security[1], there is not a strong focus on modernity--it's inexcusable to not be on PHP 5.3 today, and while Kohana will run there it does not understand PHP 5.3 idioms and features--and the code quality, after auditing, is not all that impressive.
Symfony2, on the other hand, puts a fairly strong emphasis on security, is fully based around PHP 5.3 idioms, and is written with sparkling code.
[1] - http://dev.kohanaframework.org/issues/2766 comes immediately to mind; forget the resolution of the bug (such as it wasn't), the behavior of the developers is not good. I get the feeling from those who've used Kohana that this isn't a unique situation.
I think good TDD/agile/architecture cultures are more prevalent in ruby/python but as those languages have become more mainstream the quality of the average dev in those environments has dropped quickly. A few years ago only really good devs ventured into ruby stuff. Now everyone is trying it as the tools have made the language much more accessible for the average developer. I am seeing more and more programming mistakes in the ruby code I dive into than I used to.
Language choice doesn't matter too much from a technical perspective. It matters from a practical perspective. Consider the jQuery/prototypejs war. Prototypejs was technically superior for a long time, yet due to jQuery's more accessible plugin culture and prettier web site they were over time able to build a more robust community and took the mindshare lead in the js space. I still think one of the core reasons ruby/rails and python/django got big is that for a long time there was only one major framework available for the language and this caused a better community than the php landscape, which pre-dated frameworks by a long time (this happened to perl as well). So there wasn't "one true way" in php to build apps quickly, and this hurt the php community when rails got big. I think as a community we lost a lot of talent to ruby/rails in the last few years.
Bottom line is that accessibility, pervasiveness and low-learning-curve are critical to the initial and continued success of any platform, whether it's a language (ruby > php > perl), OS (ios > android > rim), etc.
Language advances in PHP (circular gc, traits, closures, etc) have brought php's language capabilities forward enough that it's a respectable platform for sticking with. However, you can't fix the community really since it's so fragmented. Fortunately some frameworks are getting enough traction to have rich ecosystems, and that's definitely a great thing for the language and the community.