I'm trying to wrap my head around why so many developers down PHP development like it is a second class language?
Secondly, what are the better alternatives for web development?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (64)
Python is just a toy language. Ruby is just for small scripts and not big applications. Java is verbose and overengineers simple things...
I could go on and on for any X language that has had mainstream following for the last few decades. People love to hate what's popular. If PHP 8 adds a
solve_world_hunger()function, people will still hate it because why not.EDIT: For those not familiar, the quote is from the creator of C++: Bjarne Stroustrup. Ain't that neat? :D
Just yesterday, these two tweets got me soooo pumped to be working with Ruby on Rails
The future is bright and Ruby is every bit the small script language it always was. I'll be the first to say that Ruby is a weird language to have become such a staple for sprawling apps. But it's about so much more than the code. It's the ecosystems that spring up around it.
No programming language is great or bad in and of itself. Nothing exists in a bubble.
True.
PHP's a language people love to hate. It's messy, it's clunky, the standard library uses inconsistent nomenclature, it lends itself to a multitude of sins particularly in larger application architectures. It is often not taken seriously as a language, mostly for bad reasons, but the faults it does have do tend to make people who have used both PHP and other languages prefer those other languages to it (I among this number).
As with other things people love to hate its objective badness is often performatively overplayed. Eventually this becomes part of the legend, as it were, and people with no hands-on experience begin to immediately dismiss what worth it does have and what it's possible to accomplish with it. I hear PHP 7 fixed a lot of the real problems with previous versions, which is great, but I am also sure that this will do little short- and medium-term to stem the tide of PHP hate.
Modern web development is pick-your-poison. There's lots of interesting stuff happening with Node.js right now, to the point that the scene has become quite fragmented, but that process seems to be approaching stability as communities coalesce around a few major web and frontend frameworks. Ruby is also a substantial presence thanks to Rails' popularity, Elm is a thing, and there are of course still popular web frameworks in other languages like Python and Elixir. More server-centric web applications may still use a .Net or Java stack.
I get everything you say! I've made those same observations. I do like your point in which you said people who haven't even coded in it already dismiss it.
NodeJs is the new nice and shiny everyone is falling in love with. But ES5 currently doesn't even support classical OOP. So if the argument is that a language is fundamentally bad because it has faults, then why aren't languages like Javascript and NodeJS being looked at in the same light? Because they certainly do have their issues. Proven by the point that we needed to create Typescript.
I hate to break it to you, but many of us consider this a feature, not a bug.
If you value Composition over Inheritance then Javascript is for you. In any case I don't think it is fair to consider this a "fault", and many people (myself included) think that introducing
classin ES5 was a big mistake.This isn't to open a flame war about OOP vs. Functional programming. Just that if your language is good at functional programming, you should double down on that, rather than adding functionality for OOP-driven developers who don't understand why Javascript is a powerful functional language, and how to leverage that.
So you get people using classical inheritance patterns in a language that's meant for prototypal inheritance.
The thing with Javascript is, you have no real choice about using it on the front end. I think a lot of the server-side momentum is driven by this fact. The thinking being that a dev can leverage the knowledge that already have for the server side too.
I consider Javascript far worse than PHP (and I don't care for PHP that much after writing a lot of things in it). But that does not alter my lack of choice about whether to use Javascript. If I were coming at this thing fresh, I would be tempted to try to use the same non-optional language across the board too.
Many people don't take JavaScript seriously either thanks to its checkered history and common usage on the frontend. PHP is just lower on the totem pole.
For what it's worth, I consider prototypal inheritance and a lack of type safety reasons for using JavaScript. If I wanted classical OOP and static types, I'd use a language built around classical OOP and static types.
Interesting. What scenario would you say a developer might want a prototype model over plain-old OOP?
Many! Composability is a really powerful technique with a host of applications, and it's much, much easier to accomplish with a prototypal model than it is with classic object orientation.
For a concrete example, I maintain a data access library which introspects a database to build an API over it. A database contains tables, views, functions, and schemas. Tables can be read and written; views can be read; functions can be executed; schemas act as namespaces and contain objects of the other three types. The first three object types have certain attributes in common: a name, a schema they belong to, et cetera.
A classic OO approach would be to create an
Entityclass which centralizes the common attributes, and have each ofTable,View, andFunctioninheritEntity. A method may act on any "real" database object (omitting schemas, which just contain things) as long as it takes anEntityand either only referencesEntityproperties and methods or performs the appropriate checks and casts.Then you get into the "building an API" stage. The goal is to return a
Databasetree that lets you issue a statement likedb.things.stuff.find(), wherethingsis a schema andstuffa table, determining the query target by navigating the tree. This isn't so hard: simply ensure that you create namespaces and attachEntitiesat the appropriate path.However: the default schema is unnamespaced, so what happens when it also contains a table named
things? What do you do now? Classic OOP has no easy answer. Do you create classes forTableWhichIsAlsoASchemaandTableWhichIsAlsoAFunctionand all the other possible collisions? Do you cross-contaminate your three base classes and gate alternative logic behind introspection checks? Good luck!With prototypal inheritance, resolving these collisions isn't just possible, it's easy: just keep applying prototypes as they come in! If you already have a
Tableat a path which turns out to resolve to a schema as well, you can just hang the new stuff on the existing object. The only collisions that can't be resolved are due to (small-f) functions being overridden or becoming ambiguous, not due to simple pathing.Because it is, for many reasons (most of them I blame on the community):
There are many reasons to not make it your first language:
With a 7 year experience on it (and I loved it for many years), after I have exit my bubble where PHP was everything I realized that it deserves to be a second class language and it doesn't worth to be added to a professional career skillset.
This. So many times this. One can think whatever comes to mind about PHP, but this bubble thing is especially hard to oversee.
I started my career with other languages than PHP. Basically I started with (Visual)Basic. Some C(++) during school(s). Started "real" programming with Delphi. From there the journey continued to some VB .NET and finally C# professionally.
For the web gigs involved I really enjoyed RoR for big projects and Django to some Degree. Even ASP.NET for corporate work is on the list. ASP.NET Core just feels like getting most of the rings right for now. But it mostly depends on the context of the project what the right choice of tool/framework is. Tried Phoenix (Elixir) for some toy project recently. FP is hard to grok if you come from OOP oriented school of thought, but the concepts and ideas make sense in a lot of places.
Due unforeseen circumstances PHP is currently part of my day to day work. And what should I say? I hate it. I always hated it and will probably always hat it.
Maybe you can write clean code with PHP. It is still dominant across the web. Unfortunately people still start new projects in PHP. But does that mean it does anything really well? It feels just mediocre every time you touch it. Eerytime. In any single place.
Anyway, I try to keep my mind open and try to find and accept the good parts of PHP.
But the most annoying thing is the ignorance of the people that live exclusively in their PHP bubble. They never saw anything else, but think PHP solves every problem the right way and try to convince you, that you are wrong criticizing things created by and in PHP. Don't get me wrong. I'm not generalizing all PHP folks. But I never experienced this bubble mindset in any other ecosystem as much as in the PHP bubble.
I can just propose everybody to look left and right and learn new ideas and concepts. Even if you're profession is and will stay PHP. But my bet is that if more people would do that, PHP would certainly loose it's dominance. Dominance of ignorance as I'd like to call it.
All of your points seemed to fit within the mold of what everyone else says bad about PHP. But I have not seen the statistics to prove the claims. Most people say it would be dead language as you made the same claim. How is it then, that it powers 88% of the web according to w3techs.com? w3techs.com/technologies/details/p...
In benchmark tests I agree it is slow. There are plenty of resources out there to prove that. However, I have been on many projects, where PHP out performed Java applications they had running in the same house. My own personal experience has been that If you build PHP correctly, you can get 15ms response times. Java out of the box gives me 100ms response times running none of my code.
There is not a direct correlation between "powering the net" (which can be said about bash and linux too) and how good PHP is as a language, the quality of the code and the number of jobs or its performance.
One guy that does not know PHP can take care of 100 WordPress and joomla websites with no sweats.
You can read the search for other statistics: most open positions, best payed positions, best cloud language, language popularity in 2018 and so on ..
well it doesnt have to be sudden death. but when golang and alike will become simple enough for entry-level devs to comprehend and amount of tutorials on how to launch your blog in go will grow, php will die away. along with RoR. and Python&Flask. Some mentioned that you can run php on a hosting. Its 2018 and spinning up few containers with stack of your choice was never easier, so this argument doesnt hold anymore.
also, looking at focus and rate of new libraries appearing for php, I predict it would miss next big thing with all these stream processing microservice setups.
@tux0r Imo, don't prefix, don't use hungarian notation.
If we get typed properties in PHP 7.4 (or any later version) there's very little ground to cover that isn't typed.
Using type hints everywhere with
declare(strict_types=1)fixes a lot of these issues.@lucafabbri
I like the two different method call notations. Clear separation of calls to static methods and instance methods.
Not sure what you're driving here, but if someone can't do OO design then what can i say? If you're talking about global functions like
in_array()then i agree. Yes they are bad. But frankly, do they really differ that much from static method calls likeArray.map()orMath.max()?Let's say that you are new to PHP and you are bugfixing someone else code. There is a lot of overhead understanding what belongs to global, to user functions and classes. This is not clean. While a class in other languages specifies all namespace in its header, in php you can come to a fall of includes that you need to drive back until you find where the function is. Namespace are actually more clean, easy to debug and extending.
Ah, now i see. Yes, this is incredibly bad practice.
PSR-4 autoloading with Composer is really the only sensible way to deal with imports. There should only be a couple of script files in a project that are not classes. Maybe some bootstrapping script if vendor/autoload.php doesn't cut it and a front controller. Most frameworks also ship some sort of console script to run different commands. That should be enough.
There should be no need for
require()s orinclude()s in other parts of the application.check out this - eev.ee/blog/2012/04/09/php-a-fract...
some of it is not valid anymore, but gives you perspective, from where and from which mindset php is coming. And even though latest version might report another performance boost, and opcache became usable in cli commands (basically any non-web background processes) there is no php webserver - it relies on nginx, so no gRPC server, for example. As well as almost nothing from background processing or reactive/async patterns are available (kafka connectivity for example). PHP is still fine for Drupal/Wordpress, but if you are starting your own project, its very likely that sooner or later you would need something more than templating engine (which php at its core essentially is))), and here you will be dissapointed by what this platform can bring to the table.
As alternatives for web-based projects I would name Ruby + Rails or Python and Flask, if you want to start fast, and virtually any all-purpose stack, if you are fine with learning it first (its extremely simple to start with ror or python, but this should not make you think its easy to handle complicated design descisions)
The first two lines of the blog told me everything I need to know about writer... "I’m cranky. I complain about a lot of things." This hardly seems like an unbiased approach to reviewing a language.
Your main point about it relying on a web server. I think most languages do and don't come bundled with one. Java (a very popular web language) relies on an external web server as well.
its a pity that first two lines draw you away from a darn good writeup. anyway, my point was more about php not being able to run its own production-grade webserver, rather than having or not having built-in one per se
PHP was my primary (bread-winning) language for a long time. I think a large part of it comes from the quality of a lot of the PHP code out there. Also the ease-of entry means there are a lot of people writing code that is not very good, and so it perpetuates the notion.
However, you CAN write good PHP code. There are a lot of good developers writing a lot of good PHP applications. Still, there are probably many more developers out there writing bad PHP, so this reputation will probably carry on for a long time yet.
If performance is not a big concern, then PHP is a half-decent language these days. The only reason to really dislike the language itself would be just the sheer amount of bad code out there that exists and is being written (for whatever reasons, popularity, ease-of-entry, or the platforms/CMSs written in it... who knows?).
Elixir is my default language for web stuff these days unless I have a really good reason to not choose it.
Go interests me and I have friends who love it. I think it would be great in some cases.
People writing bad code is hardly a reason to hate a language. If that were the case, than by default we would be forced to hate all languages. It is something deeper than that I feel like. Maybe it's the fact that Devs, seem to overall, dislike and will look down on people who are just getting into coding? PHP is such an easy language to pick up so that's were a bunch of us start in web development. And maybe it also has to do with peer pressure somewhat? As if you tell another dev you are coding in PHP, you will automatically be looked down on.
Yet we discount the fact that 80% of websites are powered on PHP. We somehow discount the fact that PHP has seen the tool to generate the most income out of any other language in the world.
I don't really think most devs dislike beginners, but I could be wrong.
I honestly just think it's an outdated (but well-earned) reputation from when PHP was a messy procedural language being reinforced by all the bad code in the wild. And also it's "cool" to hate on PHP.
Many devs seem to dislike non English speakers, including a lot of php devs. As long as php is used heavily by the rest of the world, even after their code quality improves, people will hate on them and their chosen language.
I see this argument in most threads when PHP is discussed. IMO you can switch pretty much any mainstream programming language in PHP's place and this will still hold true.
That's true, but I am certain that PHP destroys all the others in ratio and just plain ole massive volume.
They say PHP is behind 80% of the web and that scares me... and I like PHP.
I think one of the reasons why Elixir is not more popular is its lack of support by popular Paas offers on cloud services. Lobby to fix that and you have a bigger community instantly :D
For example Elixir is not present in the list of default languages for Heroku - heroku.com/languages - (yes, you can use custom buildpacks but you don't have the company support) nor in Elastic Beanstalk's - aws.amazon.com/elasticbeanstalk/faqs/ - nor in Google App Engine's - cloud.google.com/appengine/kb/ - nor in Azure App Service - docs.microsoft.com/en-us/azure/app...
None of this has anything to do with the language, just needs a little support by the major vendors...
Haven't posted here for a while, but obviously topic close to my heart, so here goes.
Languages and frameworks are like religions - in the end they all do the same thing, yet the language one person uses is absolute single one everyone else should use, and every other option is bad, dying, dead, etc.
As with any language, if things get tough, you find a solution. Maybe different algorithm works better for given problem? Maybe you need to change server setup a little bit?
While these discussions still add to generic self doubt and impostor syndrome, I wouldn't pay too much attention on what other developers say, especially the ones that admit they don't use the current version of the language - they have their own reasons to prove that they do not need to use PHP, and that has nothing to do with you or your projects.
However, the problem rises when non-technical people start to request language or framework changes purely based on trends or articles on tech blogs that are close to click-bitey.
But as long as you keep your clients happy, no matter what tech you build your projects on, that's the only thing you need to worry about, IMHO.
Let me start with a blatant opinion: I'd rather use PHP than pre-
awaitNode for writing a web application, because callback-oriented development is stupid. Node only became worth using when they addedasync-await, and even with that you end up having to write wrappers for outdated parts of the standard library just to write straightforward code. JavaScript just isn't that good of a programming language anyway.Now with that out of the way, PHP has two big problems:
It's inconsistent. Like, blatantly inconsistent, for no obvious reason. Some functions have prefixes like
array_map($arr, $fn), some of them don't likesort($arr), some of them are not actually functions likeempty($arr), and PHP has method call syntax, but doesn't use it for any of the array stuff. And parts of the standard library use CamelCase, while others use snake_case. The classesstdClassandDateTimeare both in the standard library, too, just in case you were wondering what type of case class names should use.It has built-in affordances that are unusable in large, well-tested codebases. Superglobals, for example, make any functions that use them much harder to test, and php.ini is just one more piece of the environment that can affect whether a piece of code works right or not. And when PHP starts writing warning messages to the browser that get interleaved with the rest of your HTML, stuff can get really, really broken, so you have to turn that off, too, in production.
PHP is the only language where I have seen development practices that are mind blowingly awful. I fully understand that you can write bad code in any language, but for some reason PHP devs manage to top any expectation of bad code one could have.
Let me give you 3 examples.
The
switchstatement (or equivalent) is available in many languages. It is fine to use. The paradigm is that you switch on a variable and each case is a constant. There are two languages I am aware of that do not enforce that constraint. javascript and PHP. There is only one language I have seen this constraint ignored. PHP. In multiple places in the code they usedswitch(true)and thecasestatements called functions. This was a well known company.Using comments as code. I was trying to use a CMS developed in house (different company to the one above, not well known) and I was trying to figure out how to change which the main page was. I had to change part of a comment. I realise this isn't a default part of the language, so I guess the dev must have felt really proud of themselves.
Drupal 7 breaks PHP's raison d'etre. In my opinion PHP is a templating language for HTML. That's the best you can hope for it. Drupal 7 (maybe 8 is better, I don't know, I ran from PHP after this) is clunky, slow and confusing. But on top of that we had installed three themes, two were deactivated. Yet somehow a deactivated theme was able to interact with the active theme and break the templating it provided. Amazing. Why would Drupal allow deactivated themes to do that?
So, sure, you get bad programmers everywhere, but the frequency and severity which they occur in PHP means I am never going near it again. It is a bad language.
As an alternative, I find Django a lot easier to get into and use than Drupal.
I guess what people do mean, when they arge about the language, if more about quality of stdlib, community, high-level concepts available in language - lambdas, pattern matching, type system, that allows you to expeess solution better (it is to some extent a matter of taste, and preferences of your team)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.