"Jeff Atwood has stated publicly that one of his ulterior motives with the Discourse project is get people to stop using PHP and start using Ruby."
This just won't ever happen. The people that wanted to drop PHP for something else (Ruby, etc) largely did so years ago. The hosting/running situation for PHP is just too basic and easy for people to get in to vs having to 'run a server' (Rails, etc).
PHP is still the only language that assumes HTML output by default. Put a file on a web server, hit it via a URL, and get HTML output. It's that simple. You can start at 'simple' then graduate up to complex stuff like Symfony if/when you want to. Every other language or platform forces a lot of extraneous concepts on you on day one, which is always going to be a turn-off for a not-insignificant portion of the people coming in to the field.
Exactly. I am still using PHP for pretty much all of my projects despite all of its shortcomings. The reason for this is just how easy it is to write simple scripts and deploy them. For most small hobby projects it is just not worth spending hours setting up the development environment required to create a Ruby/Flask/... project when you can achieve the same thing with a single PHP file. And when it comes to deploy it, virtually every single managed web hoster out there supports PHP, so you just upload the file and it works.
I did play around a bit with Flask a while ago and it does feel a lot cleaner and more efficient. But once you actually try to deploy your app you realize that hardly any web hoster actually supports the required Apache extensions and suddenly you end up having to set up your own server and fiddle with config files to get it to work.
It is even easier if you use Phusion Passenger, either in combination with Nginx or with Apache. It is almost as easy as PHP. Put your Ruby app somewhere, set your document root to it, done. Nowadays, Phusion Passenger even supports Django and Node.js.
I've deployed a number of small PHP-based websites in a similar way for similar reasons over the years. However, I think the next "simple" project like that that I need to do will be statically rendered from frozen-flask and hosted on S3, with any small interactivity provided on the client, with JavaScript.
> PHP is still the only language that assumes HTML output by default.
For me, that's not a feature, it's an oddity that I have to work around. I guess it's a feature if you're using PHP as the HTML template language it was designed to be, but I suspect that's a minority use case these days.
I would actually argue that using PHP as the templating language in a PHP MVC application has become the majority use case.
Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself?
There are cases where you may need to do this (if you can't "trust" the templates for example and you need to enforce some kind of validations or restrictions on them) but otherwise you just need to follow/enforce business rules about what can go in your views, and just use plain ol' PHP..
> Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself?
From past experience: to stop shittier developers at your company putting controller logic in the templates. Using something that does nothing but templating ensures that your templates do nothing but present data.
I actually agree with you. It's been a while since I used PHP much, but the last time I did some work in, erm, I think it was Symfony, I remember thinking that PHP was pretty nice for the template layer. That may partly be because I'd got used to Django, which had an aggressively simplistic template layer at the time.
Edit: By which I mean, Symfony improves things by working around PHP's suboptimal default.
Twig too, and you can sandbox functions and auto-escape data. To me, using templates is more or less the same as using a framework with PHP -- it does add overhead and you could get by with, say, plain PHP and having urls point directly to resources but sometimes I think the benefits of that extra abstraction, even if it is a bit recursive, outweigh the potential costs of not having logical buffers between a request and its execution. An app that's too dumb can come back to bite you just as hard as one that's too clever by half.
Blade (used by Laravel) seems to be more along the lines of "bare PHP/bind to PDO object" but I haven't studied it too hard because i'm such a twig fanboy.
> For me, that's not a feature, it's an oddity that I have to work around.
Well, I would venture a guess that you should have looked up the language's name and its meaning, then the entire focus of PHP might not come as much of a surprise.
> Zeev Suraski and Andi Gutmans rewrote the parser in 1997 and formed the base of PHP 3, changing the language's name to the recursive acronym PHP: Hypertext Preprocessor.
Yes, to get back to my point, it is basically a templating language for HTML, hence the hypertext. I think the name made it clear being ambitious with it outside of HTML was going to be difficult, unless you like the challenge of making cars into airplanes, and submarines in to hang-gliders.
That's not what I mean, and I don't think it's what the person I replied to meant either. I assume text/html is the default content type for all web frameworks.
I was referring to the fact that the first thing pretty much all PHP apps do is say "Wait! Don't output anything yet! I have code to run!". I believe modern PHP frameworks generally borrow the controller/template pattern from other languages, because it generally makes more sense than PHP's default of outputting HTML unless told otherwise.
I think node can beat out php in regards of ease of hosting. I've simply never worked with a version or package manager that works as well as nvm and npm. Trying to do the same thing with Ruby or Python is like pulling teeth. Even compared to PHP it's a breeze. I know it isn't on all hosting solutions like PHP, but Heroku and Nodejitsu are free for small or open source projects respectively.
But you're right, PHP assuming HTML output by default is a huge boon. With node you have to set up your own server and routes, and more... That's a lot more work than installing WAMP, running it, and putting your php files in the right folder.
I don't really want to stand up for php, but this just isn't true.
"git push heroku master" comes at a steep price. PHP hosting is, in general, ubiquitous, cheap, and incredibly easy. You can get comparable pricing for ruby hosting, but you'll be doing some server setup yourself.
yeah you're missing something, unless you're just running something low priority like a personal blog:
Although an app may not require the resources of more than a single dyno, we recommend running at least 2 dynos for a production app. One reason for this is that dynos restart roughly every 24 hours, and dyno redundancy helps ensure that you don't experience excessive queueing or dropped requests while a single dyno restarts. Additionally, dynos and the processes running on them can occasionally crash, and having another dyno helps ensure that you don't have downtime while that dyno recovers. Finally, single web dynos sleep after an hour of inactivity, and having a second dyno means that all dynos will stay awake.[1]
I'm as cutting edge in the PHP community as any is going to be (having used the latest betas & community-best-practices since 2004).
I still have serious doubts about PHP, and always insist to new developers should learn a (ruby/python/... clojure/...) too.
The main problem with PHP is the language itself. There is no paradigm it does well. If you're into class-ical OO, then the language's type system is a joke (esp. with the lack of co/contra-variance in type hinting).
If you're into dynamic OO, PHP's java leg-humping perpetually gets in the way. There is no meta-classes, monkey patching, etc. everything that should be dynamic is static.
If you wanting functional programming... you have nothing. Literally. The best they've been able to do is a half-baked closure system. Half the library uses references (rather than returning meaningful data) so you cannot compose functions and there is no hope for any kind of collections system (lists, arrays, etc.) that support a typical functional manipulation.
All you're left with is a "dynamic C".
Add to this that PHP is designed to terminate immediately... and you're modern "daemonic" web requirements (concurrency, queuing, etc.) are completely out of the window.
From the point-of-view of "web-scale" application development PHP is a broken toy: both in the sense that talented developers are hampered by it, and in the sense that its execution model is ill suited to the problem.
Plus there is PHP's aesthetics. I can't help but see all PHP code visually unpleasing. Programming isn't just a technical task. It's also an art like writing novels. I'm not satisfied when the code I produce doesn't look pretty, independently from the algorithm. In the article here, the Ruby code looks much cleaner to me than the PHP version, even though it's technically the same. Aesthetics is the main reason why I switched from PHP (that I learned in class) to C# (that I learned on my own).
Well, wherever you look you'll find the same thing as the whole framework is written in the same way: specific classes with small methods. And you can't say that the framework as a whole does nothing.
I agree about the python code that it is reasonably readabale, but i still think it's ugly. Those two things are not the same.
Syntax is highly important, however. A poor syntax can make an otherwise decent language quite unbearable. A nice syntax doesn't make an otherwise poor language good, either.
Special chars, like PHP $, Rust's ~, Ruby's @, help the programmer tell things apart easily.
Vastly better than having to keep the information in your mind after the declaration -- and much lighter and better than full-on hungarian notation madness.
As for the braces, they never went out of style. In fact, with the exception of Python, the languages that don't use them are not that popular, compared to the ones that do. Coffescript, for example, is insignificant compared to the plain Javascript use.
I'm afraid you picked a pretty terrible example. That PHP code is 414 lines of getters and setters - the code does nothing of actual value. It's a mess of design patterns and OOP verboseness, which mainly suggests that the PHP community are determined to copy the worst aspects of the Java ecosystem.
The Python code, while a little heavy on decorators for my personal taste, spends the same number of lines of code implementing a whole swathe of useful application functionality.
I'm not saying your particular example proves anything about PHP vs Python, I just think you chose an apples-to-oranges comparison to illustrate your point. It would be much more interesting to see some PHP code that implements business logic similar to that Python.
I already answered this below. Anywhere you look in the framework you'll find that it is written in the same manner, so i couldn't possibly find any code that is comparable in style to the python codebase. Yet, it is a full-stack framework, so you can't say it doesn't have any "useful application functionality".
Since the point was to show what kind of code you'll be looking at depending on the choice of your language/framework i think that the examples are appropriate. Which application implements better design patterns is a discussion that goes a little beyond the point of this thread.
Purely about aesthetics, I find ruby to be ugly and inconsistent. Every time I hear about how beautiful ruby code, I can't help but laugh. You mention the code in the article, and I can't see how it can be beautiful. I mean, it prefers magic over being explixit. It doesn't try to be consistent. You can at least read the php code. With ruby, you have to infer meaning.
Simply put, ruby is ugly as sin. I much prefer php's syntax. Granted, I also much prefer other C style languages, even objective-c. I mean, that probably says it all. Objective-c is probably on the opposite end of the syntax tree compared to ruby.
Simply put, ruby is ugly as sin. I much prefer php's
syntax. Granted, I also much prefer other C style
languages, even objective-c.
*I mean, that probably says it all.*
Java->queuing->Just put sleep.. why so so hard ?
with the lack of co/contra-variance in type hinting
Write proper code oop and comment->Most latest ide can see it.
Now php much okay with namespace.. only what i really wanted now is partial class.. Other no need..
How would they fix it anyway? It was never really designed, it just evolved as a slow accretion of features using whatever syntax was convenient in the parser codebase over a couple of decades.
The author makes a good point that people like me who ditched PHP in the mid-2000s should probably stop complaining about it since we don't really know the current state of affairs.
The problem is when we have languages like Ruby, Clojure, Scala, Haskell, or even plain old Javascript ala Node, why would I waste another thought on PHP? PHP was created to make very simple dynamic web pages, and I would still use it for that in the way that I still write bash scripts for simple shell operations to avoid a higher level dependency like Ruby or Perl. I'll use PHP for small stuff, but I see no benefit towards putting any real engineering effort into a PHP project.
I'd argue that PHP came out of the gate with some pretty powerful properties, too.
They hit a sweet spot of
* Being there at the right time (none of the "good" languages in your book was around or usable for web dev at the time of PHP4 and PHP5 came out)
* Being easy to learn - giving beginners quick rewards.
* Being powerful enough to do quite a bit more than "simple web pages", as you say. This enabled people to "graduate" from "simple web pages" to "web apps".
In fact, most of the web was built in PHP (Wikipedia, Facebook, Wordpress runs on 50% of all webpages or so, Drupal is incredibly popular, Magento runs loads of webshops, and on and on). This has not happened merely by accident.
I feel it's a bit wrongheaded to suggest otherwise.
* Being dead easy to deploy on almost any webhost (Drop files, hit them with their url, be done - almost no other language delivers this even today)
In all i feel PHP has moved the web forward tremendously.
In time, itself has evolved as well. It may not have evolved as fast as one would want.
"Being there at the right time" is pretty much the only redeeming quality it has, and it's not so much a quality of the language, is it?
"Easy to learn" is not the same as giving beginners quick rewards. Being easy to learn, in reality, would probably result in things like Wordpress not having more holes than a swiss cheese.
"Powerful enough" -- most web frameworks are. Saying that it didn't happen by accident of course depends on how you define accident. Personally I think the only thing PHP has got going for it is the timing and next point:
"Dead easy to deploy" again isn't a property of the language. Saying that "almost no language delivers this" about something that's really up to the service you're using to host your website isn't fair, in that it actually has nothing to do with the language.
I must say that I wholeheartedly agree with your closing statements, though.
Well that's why I said "even" Javascript. Brendan Eich actually pulled off a small miracle by embedding incredibly powerful functional and prototypal paradigms in JS. It's not perfect, and there are plenty of warts, but JS came out of the gate with a powerful core that PHP took decades to add in a Frankenstein manner.
Enough with the "JavaScript is a functional language" myth, please. Merely having first-class functions does not make a language a functional programming language.
JavaScript does not promote the use of pure functions, referential transparency, and the minimization of state.
JavaScript does not encourage the use of recursion.
JavaScript has an atrociously broken type system, rather than a robust and theoretically sound one.
JavaScript does not offer pattern matching and other functionality offered by modern functional languages.
In fact, JavaScript goes out of its way to promote a very imperative, non-functional style of software development, even when efforts are made to try to use it in a functional way.
And JavaScript's prototype-based OO is anything but powerful. In practice, it's nearly useless. That's why we see so many JavaScript developers try to fake a class-like OO system using it, since class-based OO does offer what they need and want. But due to the incapability of JavaScript's prototype-based approach, these hacks end up being incompatible maintenance headaches.
JavaScript does not have a "powerful core". It has a rotten core, just like PHP, and it has evolved in a broken manner, just like PHP.
JavaScript's design is clearly much more coherent than PHP's. Whereas PHP's developers have added features haphazardly over several years, the JavaScript language hasn't changed much since its initial design in 1995. Warts aside, having a (barely) complete initial design that was done by one person over a short time and has since been mostly left alone is an advantage. And JavaScript is flexible enough that library and framework developers have been able to explore several different approaches while the language remains frozen. Therefore, it's quite misguided to lump JavaScript in with PHP in terms of language design.
It's certainly not accurate to categorize JS as a functional language, but it is flexible enough that one can program in a more or less functional style; and unlike PHP, it always has been.
Also, I've read several of your anti-JS diatribes, and I feel compelled to ask this: What drives you to denigrate JavaScript, and programmers who willingly choose to use it, wherever you can? Do you feel the need to show your superiority by bashing the languages that many programmers use to produce useful applications despite their lack of expertise? Can we not accept that all mainstream languages have warts, and that in many cases, practicality may dictate that we use a language that doesn't please us aesthetically but is nevertheless useful?
A bad programming language that remains bad for nearly two decades isn't really any better, in my opinion, than a bad language that undergoes some change that may have mixed results in the end.
JavaScript is bad. PHP is bad. They're both bad in many of the same ways, and they're bad in different ways. None of this changes the inherent fact that they're both bad programming languages.
Of course all programming languages have "warts". Very few, however, have as many horrible and inexcusable "warts" as JavaScript and PHP do.
As an industry and as a community, we can do better than JavaScript and PHP. In fact, we have already done better in the past (sometimes many years ago), many times over.
So, yes, I will speak out against programming languages that are inherently broken and inferior, and even extremely harmful, whenever I get the chance. It's the right thing to do.
This is not about my ego, or about my "superiority", or about me at all. This is about doing things properly, as an industry and as an entire community of programmers and software developers. JavaScript and PHP are very clearly not acceptable programming languages to use, even if a lot of people make the mistake of doing so.
I take issue with your recurring assertion that JavaScript is bad. Not just that it isn't to your liking, but that it's objectively bad, something that the software development community ought to avoid. JavaScript's bad parts have been discussed to death, so I won't rehash them; it's enough to point out that programmers can easily get used to avoiding or working around them. What's more important is that there are good things about JS which make it very desirable as a cross-platform, general-purpose programming language. Specifically:
1. JS is the native language of the Web platform. Because of its ubiquity, the likes of which Java, Flash, and Silverlight never achieved, the Web platform is an attractive deployment target for many apps.
2. Because of JS's role in the Web platform, it has the support of every major player in personal computing, specifically, Apple, Google, and Microsoft. Languages like Python, Ruby, and Lua have nowhere near that level of corporate backing.
3. Yet no single company owns JavaScript, so there is no patent trap as with Java or .NET. Nor is there any threat of vendor lock-in.
4. Because of the strong corporate backing and the fact that most Web browsers are now based on open-source engines, there are mature, open-source, non-copyleft implementations of JavaScript for all major desktop and mobile platforms. (The "non-copyleft" bit is in contrast with, say, Mono, whose license enables Xamarin to charge a premium for use in iOS, Android, and Mac apps.)
5. Because JavaScript is the native language of the Web platform, full-stack Web application developers basically know it to some extent, regardless of what language they prefer on the back-end. So many programmers know JavaScript, making it an attractive choice for a software company wanting to hire more programmers, or an open-source project looking for contributors.
6. Because of the competition among browser developers in recent years, all of the major JS implementations are now very fast.
7. Unlike C and C++, which are AFAIK the only languages that match or exceed JS's ubiquity, JS guarantees memory safety. This eliminate a whole class of bugs that many programmers are not equipped to deal with or prevent. These bugs often turn into security holes.
So these qualities, largely political and business-related but important nonetheless, make JS very attractive to anyone wanting to choose a mainstream, high-level, general-purpose programming language for cross-platform application development. In light of this, how can you say that JS is objectively bad?
Don't set me up as straw man for your anti-JS rant. I never said JavaScript was a functional language, and I never said it was a great language. I just said it is better conceived than PHP, no more, no less.
Support for higher-order functions is obviously a minimal requirement of a "functional programming language". But functional programming extends far, far beyond that.
It also embodies a philosophy emphasizing the purity of such functions. It encourages the use of recursion for iteration. It encourages the use of robust type systems. It encourages the use of pattern matching. It discourages the use of many imperative approaches.
Although they may offer some form of higher-order functions these days, I don't consider languages like JavaScript, C#, C++, Ruby or PHP to be "functional programming languages". They're imperative languages that just happen to have added the most basic of functionality expected from functional programming languages. They don't truly encourage, and only partially enable, the writing of software using a functional approach.
I wouldn't say so. It's far, far closer to a functional programming language than JavaScript is, for instance. But it's clearly nowhere near what Haskell or Standard ML are, either.
Maybe "semi-functional" would be a good term for it and Scheme. It has some of the important elements of functional programming, but not all of them.
You would have to break it to fix it. Backwards compatibility kills you unless you never make bad decisions. Some languages manage this, eg Lua that has a (long slow) cycle of deprecate, remove on features.
What you say is very true. PHP is in the same boat that JavaScript is in. Their very severe, yet very inherent, language flaws just cannot be covered up with one library or framework after another.
The only real option is to give up backward compatibility, to then throw out every broken language feature, and to then reimplement them properly. Unfortunately for those two languages, that would involve an awful lot of stuff getting thrown out and reimplemented, which is very likely why it hasn't happened yet.
Given how much core functionality needs to be reworked in both cases, I don't think they can really be saved. There are numerous other better languages out there, and it's easier just to use them instead of trying to salvage PHP or JavaScript.
For example they have now deprecated the dreaded mysql_, pgsql_ interfaces (including mysql_now_escape_the_string_for_real() and the like ;) for accessing the database in favor of PDO.
They will be removed in the future.
Lots of projects still use those.
Just 1 example of PHP dropping backwards compatibility.
It's not quite so bad as you make it out to be.
Deprecation of those awful vendor specific DB extensions is a good start, no doubt. But those are library functions, rather than language features.
Another thing to consider is that PHP developers have a track record of deprecating certain functionality, then a few releases later changing their minds and no longer deprecating it. Some examples of this include is_a, and var in property declarations.
Given how it's still relatively common to see PHP 4.x installations in use today, 10 or more years after they were first released in some cases, merely deprecating some of the broken functionality now won't help much. We'll still see deprecated features in use in 2020, if not well beyond then.
The broken functionality needs to be stripped out completely within a reasonable time frame (well under a year), not merely deprecated and left around for years, if it even stays deprecated. But this involves the PHP community acting responsibly, and going along with these changes for their own good. I don't think we can expect that level of responsibility out of them, unfortunately.
I agree about the need to really strip out the bad stuff, not just deprecating.
Wrt removal of language features:
They seem to be in the process of cleaning up some there as well.
For example in 5.4 they removed safe mode, register globals, magic quotes (and those were really awful).
see: http://php.net/releases/5_4_0.php
I also agree that there is a lot of bad stuff still around.
Look at how slow Python 3 adoption has been. I don't think completely breaking backwards compatibility is a quick thing. The Python folks expected 5 years for Python 3 to become the default version because of the dramatic changes.
I've worked on a number of software systems at several different organizations that have very effectively used Python 3 for years now. I think that Python 3 has been adopted perfectly fine by many other people and organizations, too.
We're just not overly vocal about using it, because it has worked for us with so little pain and so little effort in many cases. It really wasn't much different going from 2.7 to 3.0 or 3.1 than it was going from 2.6 to 2.7, for example.
I strongly disagree, php 5 has introduced a lot of fixes, performance improvements and many nice and great new features.
I'm a big fan of python and I think that very intelligent people are behind its architecture, but honestly most of the money I made through the past years came from php websites that I can build really fast.
I have eventually used python (fabric) to automate creating php websites.
Not so fast. PHP evolved a lot as a language, maybe it will never be enough to fix its ancestry, but namespaces, closures, generators, ~~typed~~ expressions (you can finally slice a function call returning an array without unnecessary variables) and some literals. It's still not 1958-worthy to me, but they do evolve.
It is evolved indeed, but is there any language designer / guru who ever come close to exploring its good parts (like Douglas Crockford did with Javascript)? I don't think so...
Well, first I think it's irrelevant with what we were saying. Secondly, I doubt there will ever be such a document toward PHP, since it wasn't conceived with a linguistic background (Rasmus Lerdorf wanted a pragmatic dynamic layer on top of C code without resorting to perl). There's no special abstraction principle in PHP, as opposed to prototyping, which (after a quick wikicheck) is not a core abstraction in mainstream languages and could benefit from a book explaining how to think in it. PHP is more and more aiming toward mainstream class based OOP, and everything has been said about it but I can be wrong.
A fixed php would be a different language. The differences between Python 2.x and 3.0 would be minor compared to what would need to be fixed in php... and look how well that migration has worked out for python.
I spent a couple of years with php recently. I was using Codeigniter as a framework. Php frameworks now compete with the rest and the language is as complete as most others. Setup couldn't be much easier and it's probably the most ubiquitous web language.
It does, however, have some bad behaviours of out the box that promote bad app development. I was startled at the default error handling when I had to start using it again recently. It was a fight to get it to display errors - and stop executing - whenever something was wrong in the code. This is madness. If your code is broken, it should notify you. I tried doing the same thing to existing well known php apps. They wouldn't even load. That, for me, is the core issue. You have an ecosystem devoloped by people who seemingly don't even care if there are bugs in their code.
Your framework may have been catching exceptions and continuing execution.
If you want all errors displayed, you should tell PHP about it. In fact, it is recommended you display everything possible and code to strict standard while in dev. Doesn't sound like you were doing that.
Ive been working with the Symfony PHP Framework since 2007 and to me it has transformed PHP completely. Many people left PHP when Rails came along and never looked at it again, and the biggest misconception is that many of those still look at PHP like it was in 2005/2006.
But alot has happened!
Symfony2, my framework of choice, has a very mature and solid architecture and offers anything you could imagine from other frameworks. The code is clean and maintainable if done right and still its extremely flexible and extensible. It also depends on PHP 5.3 which has Namespaces, closures, lambdas etc. So id argue its up there with any of the other top Frameworks, it might even be the best. While its true that there are languages that are more beautiful to work in, i dont think its all that bad. For me, the biggest flaws of PHP are present in any dynamic-typing language. The syntax is just stuff to get used to once and be done with it.
I have been using symfony1 since january 1st, 2008 and then migrated across to 2 for other projects.
symfony2 is a solid framework for php, and very quick to get started and maintain. With composer it is even easier, and git repositories are pretty small as well.
I wish people would stop trying to defend PHP against "the haters" - firstly because no amount of reasoned argument is going to change the views of fundamentalists, and secondly because they are a minority group whose opinions are unlikely to inhibit the rise of the PHP ecosystem.
I would argue that the "rise of the PHP ecosystem" has been massively damaged by the amount that has been written about PHP's flaws. An ecosystem needs talented programmers working on open source libraries for that ecosystem, or helping spread best practices.
You don't see much fresh innovation in the PHP community these days - instead, you see developers who work with PHP having to recreate libraries and techniques developed by other languages.
Meanwhile, the Node.js, Python, Rails etc communities are overflowing with talented developers who used to work with PHP and are now busily inventing the future on top of different languages.
I'd take issue with arguing that there isn't much innovation in the PHP community.
It might not be the best language for every application (I find myself using it less and less these days), but there have been a whole ton of recent developments that have made it much nicer to work with.
PHP 5.4 made some pretty significant improvements, and Laravel is one of the nicest full-stack frameworks I've ever worked with. PHP now has good/sane dependency management via Composer, and many of Laravel and Symfony's components can now be used outside of the main framework. Microframeworks are a pleasure to work with in PHP, which is especially nice for smaller one-off webapps.
Many of the recent improvements have been (very) late to the game, but they're nevertheless welcome. I could do without the Java-esque levels of verbosity that PSR-0 encourages, but it does seem to result in highly-maintainable code.
"New PHP" projects (written from scratch, targeting 5.3 and above) tend to be of surprisingly high quality. As I've mentioned before, Laravel emerged from nowhere as a lightweight and very high-quality framework, long after the PHP community had been declared moribund.
The people you refer to as "haters" are usually just professional software developers. As professionals, they don't stand for the unjustifiable inferiority exhibited thoroughly by PHP and JavaScript. So of course they'll speak out against such programming languages.
And contrary to your beliefs, what they say does have an impact. We wouldn't see so much emphasis on web development using languages other than PHP and JavaScript if what you were saying is true.
I'm just wondering, why should it take 15 years to get operators [] and -> to work with any subexpression (and to my knowledge it's still not 100% there)? Shouldn't it be implied and kind of automatic in a programming language?
Or why should it take 15 years to adopt [...] as an array constructor in a language where arrays are one of the central data structures?
Here is opinion No. 823,664,783 about PHP from a long time PHP developer: it sucks (for me) because somehow I don't have a sense that the language itself is in good hands. I'm not sure if, say, they introduce a new basic operator in expressions and that it will not take another 15 years until it makes full programming sense.
It is indeed in bad hands. No language designer / guru ever that I know ever come close to exploring its Good parts. I'm talking Anders Hejlsberg / James Gosling / Douglas Crockford level here...
I wouldn't say that Crockford really "explored JavaScript's good parts".
Rather, he just covered parts of JavaScript that shouldn't be used, and whatever wasn't completely broken was considered to be "good". It isn't truly good, however. It's just not "severely bad" like the rest of JavaScript is.
I started with php and never used a framework quite some time ago. Every web site/app I've built had different file structures and my own little twists on how to abstract away certain things. I rarely used any third party php code too but my code slowly improved on its own.
Now a days I use rails and prior to that I used node/express for a year or so. I think working with php made me a better developer because you need to learn from your mistakes and using bare bones php is the best way to ensure you make mistakes.
You don't really understand why things are done a certain way until you've experienced first hand at how horrible it is to maintain a 6,500 line php file that's mixed with sql, php, html and a ton of inline css in a project that has about 500kb of mixed php/html/css files and like 30 different dynamic pages.
You don't really understand why things are done a certain way until you've experienced first hand at how horrible it is to maintain a 6,500 line php file that's mixed with sql, php, html and a ton of inline css in a project that has about 500kb of mixed php/html/css files and like 30 different dynamic pages.
It's quite possible to write PHP applications which aren't that terrible, tightly coupled or unmaintainable. Perhaps you can blame PHP's low bar for entry for making those kind of bad practices possible, but it's not as if the language requires you to work that way.
Although I do see that kind of thing a lot in Wordpress, still.
Yes I know but if you want to pickup "web development" as a beginner then chances are you're going to start with PHP unless you are getting trained by someone who happens to be using a different technology.
At least that's how it was back in 2006ish when I started. Its low barrier of entry is exactly why it's easy to make mistakes. You are given 5000 functions and no guidelines other than the ones you make yourself.
It's still bad, and there's a lot of bad legacy PHP code out there, but I don't believe it's as bad as it was. Although most new developers working with PHP will probably be hacking wordpress themes and plugins (which don't really have much in the way of best practices other than WP's sometimes infuriating API and mixins as a feature) but others will still end up using a framework like Symfony or Laravel, or Composer to manage dependencies and autoloading.
I don't know if it's even as common as it was to start in PHP without at least touching some kind of framework... although that's just an assumption on my part. At the very least there's a lot more good PHP code out there and better practices to be found, even if education seems like a dauntless task.
I think many developers on here evaluate programming languages solely based on technical merits without considering business needs. PHP's sweet spot currently makes it the wisest choice for many small business projects.
When you're talking about any project that's less than a thousand lines of code or so, PHP's weaknesses don't really present a major problem and its strengths (ease of deployment, ease and ubiquity of hosting, having a bunch of necessary features for websites from DB access to email built into the language) are ideal for smaller organizations, particularly those without a full-time technical staff.
Think about how many small businesses out there (restaurants, real estate agents, a simple online store) just need 1 or 2 basic dynamic elements (simple DB access, a contact form, some validation on an order form, maybe sending a confirmation email on a sale) on their website to work to enhance their business. PHP is a great choice for these types of projects - a good portion of non-technical small businesses don't need anything more elaborate than this.
I wouldn't recommend PHP for large or ambitious projects, as other alternatives like Node and Rails are likely better fits. But when you have a very simple small business project, PHP is by far the best choice for a lot of these types of projects.
PHP as a language is broken. I don't want to speak in broken language. It hurts my brain as human..
Unlike other popular language which has language designer around it, PHP 'copy' other language feature without even serious consideration around it. Even more, there are no language guru who want to research the Good parts of it, like Javascript who has Douglas Crockford who tels us the good parts...
The thing that irritates me the most with Php, is not being able to quickly jump around the code from class to class without some hack. While magic autoloaders are great my IDE/text editor isn't smart enough to know how to do this. You could probably write some code to help in this respect for your editor or use some other tools. It ultimately ends up that I want to hold too much of the project in my head, which is a brain muck.
I personally recommend Python over Php to newcomers because I think it's an easier language to understand and get going with.
I would suggest that this in particular is a problem with your workflow and IDE/editor and not PHP. I've usually just kept everything open as a project in Sublime Text, works just fine. As far as the code itself goes, using PSR-0 and/or Composer makes most of the headaches with class loading just go away.
PHP is like that old phillips screwdriver you have in your toolbox. You know, the one with a crack going down the side of the handle. Wrapped in masking tape to keep the thing together. You bought it when you moved into your first house and you need to screw a lighting fixture that was about to fall off the wall. It's been with you for years, always there in case something needed a little tightening.
Sure you have better, more streamlined tools in your shed, but sometimes you just need a little elbow grease and your old pal the screwdriver.
"I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.
You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.
You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.
You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.
And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.
Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.
I'd say one of PHP's biggest flaws is that it's just too easy to get started. One might argue that's not a flaw, but it is - it allows junior developers to dig right into the code without knowing the basics of how web works, in turn producing extreme technical debt and waste years on bad practices.
I've been there too, and I must say I agree with Jeff on this matter - if I was forced to use Ruby instead of PHP when starting my career, I'd be a better developer today. But I'm catching up :)
Prepare yourself for gross generalizations, but I have a point :)
In 1997, people moved from perl to PHP in the same way that in 2004+ people moved from PHP to Ruby.
At the time, the hard part of web programming was deployment, easy access to libraries of functions relevant for web programming, digesting forms, and emitting HTML. PHP suddenly made that trivial. PHP was basically a new language with a stdlib for web programming. It was enjoyable to work with, and it took off.
Circa 2004, the hardest part of web programming was managing the DB from the app code (migrations,ORM), quickly accessing the prolific output of the OSS community (RubyGems), and having some sane organizing principles around building apps (opinionated MVC).
In 2004 I had the same problems in my PHP apps. I had just come off of 2 years of Cocoa development and couldn't stand doing PHP the "old" way. It was too painful. I ended up porting the Cocoa framework to PHP so that I'd have a sane way of building apps. I later discovered ruby/rails, but frankly at that time it was less mature than my framework so I didn't jump.
As someone stuck in PHP land, I was frustrated by the relative lack of progress in the PHP community vs Ruby, but I was never really enamored with Ruby the language. It's powerful, and easy to read, but frankly I felt that power would eventually work against it. As the less-savvy developers moved to it, the quality of the code would greatly diminish. I feel that this has happened.
I do use a lot of Ruby projects as well, and it's rare that I don't run into critical bugs almost immediately. For as many nice things as there are about ruby, I find it very difficult to debug, and the broad application of metaprogramming, mixins, and other language tricks ends up delivering apps that have highly coupled state that fail in unpredictable, hard to debug ways. Javascript has the same problem. Frankly I don't think the ruby community is producing code of better quality than the php community at this point. There is great stuff that we can finally easily share thanks to composer.
Metaprogramming & dynamism are neat ideas but I just don't think it scales well with the constructs that those languages have. PHP 5.4 has traits which are really nice for this type of thing, and Scala's traits are even nicer. The point being that other languages can deliver that flexibility without becoming unmanageable, and I don't think there's a path to that with Ruby or Javascript.
IMO, I think languages like Ruby and Javascript will actually WANE in the far future as new languages come along with better constructs for empowering developers with dynamism that can be better managed and have faster runtime performance. I think Ruby will end up as a frowned-upon language with crap libraries and Javascript will more and more just be used as a build target.
One of my main challenges with PHP is that it has no package manager with large community support. With npm and gem, and the community supporting them - developers get so much help in building robust products. Every developer that I've known for a few years and successfully switched from PHP to Node has said "Why didn't you tell Me about this before?!"
Honestly, how can languages (what PHP in the end boils down to) possibly evolve?
Example: you cannot bolt OO to it later on, PHP, Perl and to some lesser extend even Python are a testimony to that. It just does not feel right, leads to syntactic horrors and is usually not very performant.
Neither can you modify the syntax. You can add to it. But not much modify existing syntax. For tiny changes all hell breaks loose.
> [...] and feel like they're doing the wider community a service by making declaring a religious war against PHP.
I think the religious-war card is clearly overused. This is not a religious-war, it is an effort by programmers who rather use the best tool for the job then the bizniz/customer dictating them a languages/framework/CMS. PHP will not be fixed, mission impossible, they know it and therefor advocate a retreat-strategy.
The article describes that the community has (be it very late) finally developed some tool, a package manager, that make it slightly more bearable. But the language and its community still suffer the exact same unfixable problems.
An analogy: even in COBOL-land some problems get fixed up until today, but not fundamental language issues, nor community issues.
Yes, I compare COBOL with PHP. Many, or most, languages will someday be 'legacy' languages. Some just a little sooner then others. :)
I'm not sure why you're getting modded down, I think you make a very obvious point. There is a programming language (syntax) and there are libraries. PHP syntax is not informed by much of Computer Science of the 30 past years, and it can't be fixed, that would be a new language. Frameworks can evolve and as long as the syntax allows enough, can be as amazing as anyone bothers to engineer them. This has nothing to do with how good a language actually is.
The code example he gave in ruby and PHP demonstrate perfectly that the PHP version is verbose (not to mention that the ruby code isn't the most concise one). It could be just me, who, as a develop, is sensitive to every single unnecessary characters in the code, which happens a lot in that couple lines of php code.
It's not fair that you can't see anything good about Discourse just because of the JS requirement. That's just one handicap.
It has its good points and all of its current features can be implemented (and already has in other projects) with HTML fallback in PHP. But I feel the biggest problems Discourse is attempting to solve is sociological, not software based. Whether software can fix human nature is another topic altogether.
Full disclosure: I don't use Discourse and don't plan to any time soon. I still believe any site/forum worth it's salt should be available via wget so that rules out most web apps (I don't believe a forum should be a web app).
PHP was shit then and it's shit now. I earned my first money by writing things in that language and I'm very glad that I moved away from that particular technology and web development in general.
When is "then"? I'm a rubyist, but I worked with PHP for a year and was impressed with how far the language has come in the last decade. Before PHP5 (2004ish), the language wasn't really even object oriented. In the last few years, PHP has gotten garbage collection, namespacing, native JSON support and others.
I really dislike PHP as a language, but it's not fair to call it shit. The language is maturing.
Can anyone recommend a good PHP framework? I've used Zend and Yii - they are okay, but I'd like to try something new. So, other than these two, which ones are good?
Many of Laravel's components can also be stripped out and used as microframeworks. Their database ORM is particularly nice, and I use it alongside Slim on a few projects.
From my experience using it, Laravel also feels a lot "lighter" than the other big frameworks of the past. It's a bit less opinionated, and it's much easier to get set up and running.
The best web platform is haskell and postgres, or ocaml-java/yeti and mysql on appengine. Phpers and rubyers are missing out on the most delightful and least error-prone ways to use functional and relational programming.
This just won't ever happen. The people that wanted to drop PHP for something else (Ruby, etc) largely did so years ago. The hosting/running situation for PHP is just too basic and easy for people to get in to vs having to 'run a server' (Rails, etc).
PHP is still the only language that assumes HTML output by default. Put a file on a web server, hit it via a URL, and get HTML output. It's that simple. You can start at 'simple' then graduate up to complex stuff like Symfony if/when you want to. Every other language or platform forces a lot of extraneous concepts on you on day one, which is always going to be a turn-off for a not-insignificant portion of the people coming in to the field.