PHP 7 makes life a lot better for PHP devs in many ways but one awesome thing is it obsoletes bunch of out-of-date tutorials by finally removing the old Mysql extension \o/
I actually met a young aspiring web developer who still learned DB-access with mysql_* functions. I urged him to switch to a sane framework like Laravel. Oh boy he was happy in a month and learned bunch of best practices quickly.
> I urged him to switch to a sane framework like Laravel
...why didn't you taught him about PDO, so he can start with something more universal, not tied to one particular framework that happens to be popular nowadays?!
Then he can learn whichever OR/DM or DAL he might like need (Eloquent, Doctrine, Redbean, IdiORM/Paris etc.), and also be able to pop the hood and debug it when needed.
I never get it why so many otherwise-good PHP devs have their heads full of framework-specific knowledge and have a propensity to fall in love with heavy frameworks like Laravel, or worse, with leviathans like Symphony or Zend ...instead of playing to the language's advantages and using light-weight tools and libraries that would allow them to move faster.
I could've done that but that wouldn't have taught the same things. PDO is awesome but requires deeper level of understanding (for a beginner), which may increase the frustration and may end up returning back to the mysql_query and co.
It's easier point to framework that's already using PDO and and making sane defaults and solving bootstrapping problems. Once you've learned bunch of new concepts like ORM in one framework, it's easy to understand other ORs and be able to compare it to DMs.
My own experience with Laravel has been really positive. Actually I was thinking about creating something similar until I learned about Laravel, so it solved lots of existing annoyances regarding PHP coding for me.
Everybody needs to start somewhere and I believe that by nudging towards Laravel, my young friend'll learn more in the long run and in the meantime can concentrate on making services instead of writing home grown PDO helpers and custom routing libraries. They are problems that have been solved already multiple times.
Also, Symfony and Laravel communities are encouraging and teaching about the better ways of doing things so that'll help him in the long run.
In many small project it's more fun and more easier to use $favorite_framework instead of searching for reinvented wheel. There are cases when it's better to do more custom solutions but for many cases frameworks are just awesome
> PDO is awesome but requires deeper level of understanding (for a beginner), which may increase the frustration and may end up returning back to the mysql_query and co.
At the same time I understand why it would be more confusing for newbies.
In a language that already has string interpolation you're telling them to use a crappier custom version of string interpolation that's safe for databases.
But if the example above uses PDO underneath, then it's not just string interpolation though I think. It's sending the query and the parameters separately to the database, which is creating a "prepared data object" to plug the parameter values into.
Do you know any good PHP database frameworks that help you build up the query programmatically?
Over the years, we built one in-house at http://qbix.com/platform/guide/database because we couldn't find one. It does things like sharding out of the box, because it's able to understand the query's criteria and target it to the right shards.
As an interesting side note: Laravel's AR ORM (=Eloquent) is built on top of the Query Builder so you can leverage Query Builder with AR if you know what you're doing. Can also lead to big problems if you don't realize the possibilities and the caveats.
Here has been discussion in another comments about overusing ARs for trying to achieve too complicated things that'll lead to DB performance problems. As stated elsewhere here, AR is good for CRUD operations but after that you should use Query Builder or plain SQL to achieve the more complicated cases.
People who want to do string concatenation will continue to do so no matter what we tell them. At some point, we have to educate users. Giving them an easy-to-use alternative is a step in the right direction.
Why not have the obvious API call for making a query only accept constant strings? You can still have an escape hatch for the rare cases where an expert needs to do something fancy, but hide it well and make it scary and you shouldn't have many problems.
Right, well, "constant strings" don't really exist in scripting languages, and before you mention objects that encapsulate them, what's to stop developers from building them elsewhere before passing the string to an object that encapsulates them?
Chicken and egg.
Education is the security strategy that pays forward the most.
There's no technical reason the language couldn't make it so that string literals can be identified at runtime.
There are several good ways to put a stop to SQL injection. Better education is one, better APIs is another. There is no reason to just give up on the idea of using SQL queries directly because of injection attacks.
I'm not sure what your point is here, because what I'm advocating is precisely to make it easier to use parameterized queries and more difficult not to.
Agree, then again there are different types of people.
Some wants to learn from bottom up(analytic approach), others want to see cool stuff then tweak, modify, replace to find the limits (holistic approach).
IIRC there is a tendency that young people prefer the holistic approach while teachers either are selected for or grow into preferring the analytical approach.
Really good point! Most of us veterans assume that because we have learned things the hard way and from bottom up, everybody else should learn like that.
"Make them suffer like us and they will learn the holy truth" ;D
Whenever I know something well I feel like I'm excited to teach people 'just the good techniques'. I do notice that the things I describe don't sound as cool because they haven't struggled with the less cool stuff, though
Its a good way to start and actually make things happen. But it's also important to get beyond that to become a strong developer.
Some do, some don't.
jQuery is a common way to learn to do front end programming. It saves a lot of time when used well. But it is important to extend the knowledge to core javascript and be able to write code when jQuery is not available (like when writing scripts to embed on different sites).
> instead of playing to the language's advantages and using light-weight tools and libraries that would allow them to move faster.
Depending on what you mean by "move faster", I may have to disagree. Besides a one-off script, I can't envision a scenario where using "tools and libraries" would allow you to move faster than using Laravel.
Laravel comes with an unbelievable amount of stuff done for you, right out of the box. Routing, Auth, Database, Queueing, Caching, Asset Pipeline, Templating, etc, etc. If your goal is to rapidly develop an application, there really is no better framework than Laravel to get that going. There's even a vagrant box that's all tooled for Laravel.
TBF, I may have misunderstood what you meant by "move faster".
Laravel is an excellent Rails clone, but the entire problem with Laravel is that it's a PHP framework.
I've been a PHP dev for 15 years and the biggest issue with frameworks in PHP is PHP itself. A request comes in, the PHP process loads up everything, executes the request and tears down...on every single request.
In just about every other language, the application boots up, loads everything into RAM and each individual request doesn't have to reload things.
There are definitely trade offs here. You can have a 1 TB hard drive filled up with PHP code on a 256mb of RAM server and everything is still going to run fine. There's a lot of value in that and most people who are PHP averse seem to be turning to Lamba from AWS to fill that gap. PHP scales down better than just about anything else out there.
When the other commenter mentioned doing lightweight scripts with PDO that's essentially what he meant though. Lightweight avoids reloading libraries and PHP is lightning fast when you do that.
A lot of progress has been made over the years to help PHP handle frameworks better, but there's a big reason why PHP grinds to a halt with heavy frameworks and that's it. Check out the techempower framework benchmarks.
Using PHP like Go, however, and just pulling in what you need can be extremely powerful.
>A request comes in, the PHP process loads up everything, executes the request and tears down...on every single request.
Wouldn't that make debugging much much easier? Since you get a clean slate for every request, bugs can now be tracked and replicated in a saner way. I personally prefer this method for building and maintaining a huge and complex application despite knowing that it may not be an efficient one.
Yep you're right, its the framework bootstrapping that's the killer, especially when those frameworks are expensively parsing config files each time (Yaml, XML...).
Which modern frameworks never do. The parsed data is usually cached in a php file. Then the (compiled to bytecode) files are cached in opcache. The interpreter doesn't even hit the filesystem on every request.
With caching, this is actually not such a big problem. The isolation is very good for resilience. Compare, for example, Node.js where a single exception can bring down your entire process and all the requests it's currently executing.
Is Laravel really a Rails clone? I thought that was Symfony. I honestly don't understand why the most popular PHP frameworks are all Rails clones. In my own work, I made things more in a PHP style than Ruby.
Unless something has changed, that's the equivalent of keeping the files in RAM but it doesn't maintain state and routes, etc so it still has to reprocess.
That depends on implementation. The cache could be maintained in shared memory, an external process or disk files and in all cases can provide a significant speed up over reading in and compiling hundreds of files without burdening all workers with all compiled opcodes.
The current implementation uses shared memory.
In addition, that does not mean retaining all the variables and data, only the compiled opcodes and that's the bulk of the startup time.
Until you hit something the framework wasn't design to do (which happens 100% of the time in my experience). Now you're working for the framework instead of it working for you.
This guy said it better: “Frameworks invert control. They control the lifecycle of the app, and give you entry points where your code runs. You’re still responsible for the final code, but you’re not in control.” https://aerotwist.com/blog/the-cost-of-frameworks/
I find this very true from my personal experience, but I also fine the repetition in my work to happen often enough that if you don't use a framework, you end up making your own framework
Depends on the framework. Dropwizard, for example, is built upon Jersey, which is designed to be modular and to allow components, even in core, to be extended or replaced (because they're nothing-special Java objects, all the way down). You have to understand the framework, but it's generally safe to assume that the intentions of the framework are good and that by adhering to the contracts between objects you'll get the result you want.
I'm not a big fan or frameworks for that reason. I do like some of the framework functionality and my apps are relatively small so I ended up going the micro framework route (Silex), using what I want (routing, forms, twig) and basically building the rest of the application in my own way.
Yeah, I hear that argument a lot from people who don't understand how the service container works. Laravel is really quite easy to understand if you have a decent knowledge of PHP. You can replace entire chunks of the framework for basically no cost if you want something to work differently.
I think it's great to point new developers to the right resources. Besides sane frameworks, there are some good starting/best practices guides to help (that are regularly updated), such as:
Also, I would encourage them to look at different frameworks, not just one. It'll help if they later move onto other languages, as they'll be already exposed to different ways of doing things :)
I only ask as scanning it I see that it recommends IIS7 for production PHP on windows servers. Which I believe you could only get using an unpatched windows 2008 server?
I don't use PHP on Windows, so I wouldn't know. But looking at php.iis.net and the PHP docs, everything points at IIS7 (or later), so perhaps that's the considered stable/supported version?
If you need to run your production system on Windows then IIS7 will give you the most stable and best performance.
So it seems to be recommending IIS7 specifically, IIS 7.5, IIS 8 and IIS 8.5 have come out since then. So it is a bit like saying you should run this software on windows vista for best performance. IIS7 is old software.
I guess I'm asking, have the IIS team given up on PHP performance or is this recommendation really out of date.
That page is way out of date. There's not really much IIS does other than hand off requests to a new or already warmed up php-cgi.exe (via the FastCGI bits). The performance stuff is really more down to the PHP maintainers (though Microsoft have contributed, and continue to do so).
The only pain point can be when there's a new release of PHP and you have customers who want to access MS SQL databases. This is done via Microsoft's own drivers [0] (Windows only). It's not been unknown for these driver releases to lag a bit behind PHP releases, but that said I see they're on the ball now with support for 5.6.
Other than that PHP runs just as quick and as reliably on Windows as it does on our Linux shared environments (I look after both).
while i cant comment on the validity of their advice, i can say with certainty that it is quite up to date. after all, the last change was just 2 weeks ago...
"LAST UPDATED: 2015-11-16 16:19:03 +0000"
(right below their banner at the top)
> I actually met a young aspiring web developer who still learned DB-access with mysql_* functions. I urged him to switch to a sane framework like Laravel. Oh boy he was happy in a month and learned bunch of best practices quickly.
There is some middle ground good practice which is using PDO, or even better Doctrine/DBAL . I don't think Laravel's ORM is that good, and the Active Record Pattern is somehow controversial.
Well anything is better than the old and original Mysql extension for PHP. If you Google "PHP MySQL tutorial", there's lots of tutorials teaching still about mysql_connect and mysql_query.
AR is controversial but it is approachable.
In addition, I figure, those old PHP tutorials (code like it's the 2003!) are giving bad example and beginners can't understand the difference or realize that mysql_query + bunch of procedural code per file * 10 can be bad thing.
I should've been a bit more clearer. Laravel taught him bunch of generic best practices (like deployment procedures, GIT, OOP, MVC, etc) and using Laravel Query Builder and/or Eloquent makes the DB code more sane compared to mysql_query.
Laravel isn't the only framework which could've done this but like AR, it's quite beginner friendly :)
I spent a good while trying to integrate Doctrine into my projects, and in the end I found it bloated and overly verbose and went back to PDO.
I am sure that it has valid use cases, but for a lot of straightforward PHP projects, it's complete overkill and adds more work than it saves (in my opinion of course).
I agree with knowing PDO though, I would say that's required knowledge for any self-respecting PHP developer.
> I spent a good while trying to integrate Doctrine into my projects, and in the end I found it bloated and overly verbose and went back to PDO.
Were you integrating Doctrine, or were you integrating Doctrine/DBAL, as the parent poster recommends?
Doctrine/DBAL is a bunch of useful helpers around PDO which take out a lot of the repetitive coding (and let me delete many home-grown methods I'd created to 'help' PDO)
Doctrine is great for keeping rails on developers of various skill levels in large projects. But it does come at a cost of overhead.
Most of the time for simple crud operations it doesn't matter, as long as you handle proxy generation and caching correctly. It can add up when you try to write code working on datasets.
In those cases, I bypass doctrine and go direct to SQL.
A row is the DBMS's model of an entity in the domain.
An object is an object-oriented programming language's model of an entity in the domain.
Representing domain entities as objects in the PL that are backed by rows in a database relation (view or table), which is what the Active Record pattern does, is reasonable.
> How it conflates modelling the domain with database structure.
Modelling the domain should drive both application and database structure; the Active Record pattern doesn't promote anything bad I can see there.
There are particular choices in database design that are encouraged by the path of least resistance in some Active Record implementations and related tooling that are, perhaps, not so great.
> A row is the DBMS's model of an entity in the domain. An object is an object-oriented programming language's model of an entity in the domain.
There's why we disagree. I believe the DBMS's model shouldn't be conflated with the application's model. Sometimes the row is an entity in the domain; however consider a normalised data structure, where the entity as the application understands it may span a couple of tables. Or involve data from another source.
DataMappers also shine when working against a legacy database or one that cannot be changed. But ActiveRecord is a heck of a lot simpler to work with.
> Modelling the domain should drive both application and database structure
I am luke-warm on this coupling; too often it leads to the application structured around the database representation, as you point out. Sometimes this is sensible (e.g. a data-processing system), but in my experience it comes back to bite later on.
I'm interested to hear your experience - do your application models match the database structure?
> I believe the DBMS's model shouldn't be conflated with the application's model. Sometimes the row is an entity in the domain; however consider a normalised data structure, where the entity as the application understands it may span a couple of tables.
If the right DB structure spans a couple of tables, then it probably shouldn't be one monolithic object in an application model (there might be a "central" object of sorts, with other related objects of which it is composed; that doesn't mean the models are identical, or even exactly 1:1, as, e.g., aggregates are sensibly single objects in an OO design, but multiple rows with some common attribute in a relational design for the same domain model, but Active Record generally accommodates that.)
> DataMappers also shine when working against a legacy database or one that cannot be changed.
I generally prefer Data Mapper as a pattern for a variety of reasons (just not the particular ones that were raised as problems with AR upthread, or, at least, for reasons that seem different to me than how those were phrased) -- even though I find that there is a usually a close correspondence between the natural relational model for a domain and the natural OO model, with divergences in models usually indicating a violation of good design principles on one side or the other (often the SRP on the OO side), I find AR itself is a violation of the SRP principle; the description of the pattern in PofEAA should raise a big red warning flag about this: "Each Active Record is responsible for saving and loading to the database and also for any domain logic that acts on the data" --"saving and loading to the database" can credibly seen as one responsibility (more succinctly, persistence) but that "and also" introduces a completely separate responsibility.
I also don't like that the simplicity of most AR implementations -- the main benefit they seem to offer for that compromise of the SRP -- tends to rest on making additional compromises, mostly in DB design and use, but sometimes on the OO side. If you avoid those compromises, you end up with something that isn't any simpler to set up and maintain than a Data Mapper, and Data Mapper gives you more freedom to evolve the persistence implementation independently (even if the model is still usually closely parallel to the application model), and even use different types of datastores.
(On a note that does approach one of the issues raised upthread, its also a fact that real world DBs and OOPLs both often require pragmatic compromises to the natural abstract relational or OO models for a domain to optimally address real problems; while it would be ideal to choose better tools -- or improve the tools -- to avoid these problems, that's often not a practical option, and tightly coupling application and relational models means that that compromise you choose on one side gets reflected on the other side, where it may not be necessary, and may be counterproductive.)
Perhaps the problem the OP is referring to is code like
foreach($things as $thing) {
$thing->setValue('new value');
}
and then looping through 10000 rows to do that, instead of using an UPDATE query.
I think the best criticism of ActiveRecord (and ORM in general) is performance, but it's only relevant on medium-to-large websites. It is a fantastic design pattern for prototyping, and good enough for production on small-to-medium websites as long as there are caching layers above it.
Slavishly mapping a row in a database table to an application object is bad. Off the top of my head, an example could be a Product, where the tables are something like:
product - main product details
product_option - options (e.g. Size, Colour)
product_option_values - values for that specific option instance
In my application I don't care about the database structure - whether the tables are normalised or storing everything in one huge serialized blob (or CouchDB, or ElasticSearch or... you get the picture). Instead you want to get the options and save changes straight back when editing the product.
Now this is where my example breaks down as the Product needs to 'know' about what options are available (either to provide a nice API or to know what to display in the UI) and my schema doesn't allow for that (save a Product.getAllOptions() method) but I'll leave that as an exercise for my reader :)
Mainly how easy it is to have zero clue that you're doing something horrible (SQL performance wise). Not positive that's what parent meant, but that's my guess.
The issue is that the line between simple and advanced is blurry, especially for an inexperienced developer.
Maybe someday we (Royal we of all software engineers who build tools other engineers use) will learn there's a limit to abstraction layers applicability and put hard breaks into the code when that happens.
I guess one shouldn't complain, the more tools allow developers to shoot themselves in the foot and not feel the pain until the leg needs to be cut off, the more variety of positions that will be open for engineers who've been there done that.
Sadly, it's not that cut and dry. Even what seems to be a simple CRUD retrieve operation to an inexperienced developer could be a very costly thing to do due to relationships between entities.
I am an experienced programmer but I've only touched PHP a few times, years ago. What are the best books or tutorials to get an overview of modern PHP?
Are there really that many php jobs floating around?
I'm certainly not seeing it.
There are a tonne of 1-click-wordpress-for-$10 companies out there, making $10 websites using it... sure, and certainly, plenty of people use it as a blog; but is there really a professional path for a php developer?
There's no where near the interest in it that there is in engineers using say, java or C#, or heck, even javascript.
I mean, I'm totally down with looking up composer and php classes if you're curious to see what 'modern' php is like, but I certainly couldn't come up with a good reason to do it other than curiosity.
There's plenty of php work. I don't have that language on my resume, I don't seek such jobs, but there are just sooo many of them that 5 of my previous 7 years of employment with 4 firms, probably 10 contracts --- all PHP.
It's just like "alright that's fine". Maybe there's so many of them because my high falutin snobby peers are simply too good for dirty php. Who knows?
You don't have to work for wordpress.com, though. For example, I do some PHP coding for a media company, which also happens to use Wordpress - WP with redis caching can run a big site also. So yes, there is still php work floating around. Incidentally, their internal tools (content auditing, SEO, ...) is also being done in PHP...
Not arguing, just saying that for example London continuously offers lots of good php contract opportunities. Day rates are slightly less compared to some other tech (mostly tech used in finance), but still decent. It is still very popular in media, e-commerce, publishing, with digital agencies and in various other fields.
PHP is a poorly written language. From comparisons to namespaces to other gotchas, it's just pigs guts. From the ground up, it's a badly designed language. Look up "Fractal of bad design" for a better understanding of why.
The numbers tell a different story. Wordpress powers 25% of the entire web. That is a quarter of the entire internet. It's pretty much your opinion vs the entire internet.
You can see how your opinions come off as ludicrous ?
Who cares about the coding language when the market is telling you otherwise? Isn't that the very essence of starting a startup, YCombinator, the whole Silicon Valley mantra? Listen to your customers.
The customers are telling you PHP is preferred to other languages and is here to stay as evidenced by 25% of the web using a single PHP application as the backend.
I won't argue that the language makes the framework popular. But if Wordpress serves 25% of the entire web, Facebook serves 1/7th of the entire world population every single day, and 500M people visit Wikipedia a month, clearly something about PHP works. Perhaps it attracts a certain kind of personality that gets things done, or perhaps its flexibility is what makes it successful, but to call the most influential programming language of this generation pig guts is willful ignorance.
Or perhaps it was easy to learn for novices, or easy to deploy...
This is a straw man. Citing 2 popular web sites and 1 application doesn't mean PHP is a well designed language. You could just as well have picked 2 other web sites written in Java to argue that PHP is rubbish.
I wouldn't even call it influential, unless language developers have been inspired about how not to design a language. Popular, yes, but not influential. I don't see anything from it being incorporated into other languages. It generally seems to have been playing catch up in terms of features, in a similar way to javascript (where there it's less about catch-up and more about breaking out of the browser & supporting OO).
You're not only wrong, you're extremely rude. How many professional PHP developers do you estimate are in the world currently? "no place" indeed.
If you've truly taken the time to understand modern PHP and want to discuss its weaknesses, by all means proceed. Otherwise bashing the professional work of your peers is simply rude.
As far as I understand, most/all new development is done in Hack.
Granted, a lot of Hack features are starting to make their way into PHP (much like how exciting new TypeScript features are making their way into ES6 and above), but focus has been shifted to Hack.
>I think the question is why should you bother with PHP at all?
Because some people just prefer it. They know its warts and have learned to work around it. For me it is a much easier prototyping tool. The crazy number of built in functions and libraries out there makes it so. Eg: Want to turn on and off an IoT device at sunrise and sunset? Well for other languages you have to go find some library or depend on an external service but no not for PHP. For PHP there is freaking built in date_sunrise and date_sunset functions! [1]
I think PHP is ok for simple stuff.
Every other stack I know of needs you to install and configure lots of stuff.
If you know how to program but is bad at sysops PHP might be the choice for you since you can just install one of the many Lamp packages and used managed hosting.
But if you can set up a decent webserver on a VPS you're probably better with something else.
I did the exact same thing back when I was first learning web development in 2012. All the PHP tutorials I used were really outdated but since I was new to it I had no way of knowing that.
Thankfully I didn't get the chance to do any damage before I was exposed to modern best practices.
Wow, they finally made good on their promise to remove ereg_*. I remember reading the deprecation notice on those functions (and using them anyway) maybe half a lifetime ago when I was first learning PHP.
The problem with Laravel is, while being a sane framework, it absolutely kills the performance, especially the last version, which is now slower than Symfony.
At least he was aware of it but preferred to keep it in the browser side.
He had already started building something based on old PHP tutorials, what could be more useful if he has some small site to build:
A. Tell there's a nicer and easier way to do it in PHP with well thought framework
B. Tell server JS is so awesome (and all the cool kids are using:), you just need to start completely from the beginning
Introducing things gradually can help a lot and lessen the frustration. Nowadays he's really into Vue and React but still likes to handle backends with Laravel :)
Also learning is one of those things that helps if the learning stuff isn't too far away from the skills you already have. Introducing too much at the same time makes learning more frustrating - especially if you want to get something finished instead of trying to multiple ways of doing the same thing.
Been learning php on and off for a while, happy to see this release is out. Most likely I will use PHP for my future projects instead of the alternatives.
Languages are learning from each other these days, the new PHP definitely benefited from this trend and is actively evolving itself, which is the major reason I'm to stick with it.
Some PHP developers recommended nodejs over PHP for the future to me, after a few experience I feel PHP may be better for long-term maintenance. Renovation is good, it's just that javascript may have too much of it for me to chew on nowadays.
Wish there will be a light-weight version of PHP, something like micropython or Lua, so I can use it on low-end systems when needed. PHP is still very demanding on resources comparing to other languages, even nodejs can be used on IoT devices with restricted mem/cpu power.
Why do they keep adding global functions like "intdiv"? For example in JS, it being another language with a similar compatibility burden, they are moving most of the global functions (like parseInt) to "namespaces" (like Number.parseInt) while keeping global references there. When I open the docs (for example, the array functions page[1]), I get frightened by the global functions which do not seem to share a naming convention on first glance.
disclaimer: I haven't written anything significant with PHP since too many years.
This is ongoing in the PHP community. For those who like purity there are tons and tons of wrapper classes that hide all that stuff away.
Modern IDEs autocomplete all the functions, I'm using PHPStorm and as soon as I type 'arr' it shows me a list of all the array functions with parameters listed.
Not perfect, but if I was worried about that kind of thing I'd use Python (which I love) or RoR (which I also love).
I never understood this standpoint. I hear this from the Go community sometimes too. Wouldn't having some sane organization of functions make it easier to "just get stuff done"? Just like in Go, wouldn't generics make it easier to get stuff done?
PHP Developers who I've met at conferences and user groups talk about what they're building. Rarely do they seem to care that much about the language. I think many would be happy in many languages, its about being able to build something quickly. If its not elegant, nobody cares.
There are a lot of frameworks (too many frankly) and tooling that enable quick building of custom sites.
When you put stuff in namespaces you need to remember in which namespace it is (and which library to refrence).
Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() (or was it Newtonsoft.Json.JsonConvert.SerializeObject()?) any day.
Sure, names of PHP functions look arbitrary and inconsistent but when you know the name of the function you know everything you need (apart from how to use it which you can quickly and unambigously check like: http://php.net/file_get_contents )
> Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() any day.
It doesn't have to be one or the other.
In fact, array functions could just be under the same static class, like Array::TheFunction() . It would be acceptable and limit chances of namespace collision .
Sure there's a spectrum. But even with one level I'm still guessing whether it was String.toInteger or Integer.toString, or String.parseInt or Integer.parseInt or Number.parseInt or whatever ... and since I need to check I don't mind finding out it's a global function named str2int or even int() that takes whatever.
If you have to look it up anyway, what difference does it make if it's a global or namespaces? If you don't know, you don't know. As such, your point as stated doesn't counteract why polluting global namespaces is a bad thing. There are arguments that could be made (PHP VM specific), but "I didn't ever RTFM and/or retain it" doesn't fly to me personally.
> what difference does it make if it's a global or namespaces?
I feel that it's often easier to remember short unique name like str2int than long, deceivingly reasonable name like: System.Web.Script.Serialization.JavaScriptSerializer.Serialize
I agree though that array_uniq is same as Array::uniq
> why polluting global namespaces is a bad thing.
Why is that bad for language wide utility functions?
I though global is bad mostly in your own custom code or you application specific libraries because it's accessible from everywhere which hides the dependencies (no to mention global mutable state which makes "action at distance" prevalent).
You love continuing to bring up the Java like example, this discussion however is about PHP. PHP will never have namespacing nested like that in the base language, so no point beating that dead horse.
> why is that bad for language wide utility functions?
There's a handful of reasons, but one important one is backwards compatibility with existing codebases (naming collisions).
Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() (or was it Newtonsoft.Json.JsonConvert.SerializeObject()?) any day.
Doesn't help you that much though when Microsoft releases new version of its web stack, naming different things with same class names as before just putting them in different namespace. I still need to guess which of the namespaces I actually need when I'm trying to get running something that I found on the internet.
The basic functionality (given type X import namespace Y) is built into Visual Studio since who-knows-when [1].
In my opinion if you are doing a lot of commercial .NET development then ReSharper isn't an optional extra. Rather, it's money well spent. You get more complete functionality: ReSharper 8 added the smarts to look for NuGet packages in your solution and reference the correct NuGet package. (This is ALT+ENTER and it basically gets the right type and dependency first time around.)
ReSharper 9 goes further and allows you to find types in any package on NuGet - JetBrains maintains their own index of NuGet packages for this purpose [2].
All the existing math functions are global. If you add a new one, it's only fitting that it is global too. Having one and only one math function namespaced would be inconsistent.
Not to mention, if they namespaced all math functions it'd break backward compatibility badly. Given that no core PHP functions are namespaced, I don't see why they should start now.
Also, with the functions in the global namespace you can implement a namespaced copy that takes precedence within the namespace and its children. It can easily confuse people, but I've seen it used to force people away from string functions to their multibyte equivalents (it threw exceptions).
I wish every PHP developer would reread the docs and start using new features available instead of just continuing with what they know already just because it works. And of course if there was any way to remove all those old tutorials out there.
And every php developer would wish that suddenly all php in the world upgrades to v7. We are years away from 7 having a big penetration in the ecosystem. And years more till it hits enterprise.
I interview a lot of php-devs, and a very large proportion of PHP shops are still on 5.4 or earlier (which is all EOL). Very often they are not at all aware of the new features in 5.5 and later.
CodeIgniter is still popular and a lot of developers have no clue about namespaces and composer usage. It will really take a _long while_ before php7 becomes commonplace.
Yeah, this is where we're at. We have a ton of old servers running hundreds of sites, some of them up to 10 years old. It's just not feasible for us to upgrade those servers unless there is a massive security issue. So we have a lot of servers running 5.3 and 5.4.
We currently run on Debian stable and don't upgrade any packages beyond what Debian is supporting. In all likelihood, we won't be using PHP 7 until the next major Debian release, which I believe is scheduled for April 2017.
Regardless, we still have to support clients that are running older instances of PHP on their GoDaddy shared hosting. If it's not EOL, we can't justify not allowing them to use it so we're stuck with 5.5+ for the time being.
The performance improvements along with the support policy should hopefully encourage many sites to move to PHP 7 within a year; PHP 5.6 will be unsupported in 8 months (though it will receive security fixes for another year).
Unfortunately several of the most popular PHP based platforms will be stuck using PHP 5.9 or older for some time. Magento just recently in version 1.9 added support for PHP 5.6. There are still an allarming number of Drupal 6 based sites out there in large scale production that have trouble supporting PHP > 5.4
The recent releases of Magento 2.0 and Drupal 8.0 should help move more sites to modern versions of PHP, but there is a lot of work still to be done on contrib modules to get full functionality out of M2 and D8
> And every php developer would wish that suddenly all php in the world upgrades to v7. We are years away from 7 having a big penetration in the ecosystem. And years more till it hits enterprise.
It will depend on hosting companies for some public websites and sysadmins for internal business apps. Ironically the sysadmins I know will be the hardest people to convince, for some reasons.
that's basically why as much as I can , I chose solutions with no dependencies when I'm working on apps for internal use (like Go,Nim,..). It solves a whole lot of issues. I just can't stand having to convince someone else to do his job in order to do mine.
I'd disagree with this. Performance increases get attention from system admins. It will take time yes, but if it saves them money, they will likely investigate sooner.
I doubt any of those developers are ever going to switch what they're already using unless they are forced by some external factor.
The more serious factor is: if you're on Hackernews, you're at least Elvis or even Einstein. Mort is out of reach for most internet media for programmers.
This is an arrogant and immature type of thing to write. This is programming, not high school cool-kids club. PHP is a wonderful tool that was mostly responsible for the dynamic web. Before it became popular, the web was mostly static HTML with an occasional CGI form, probably written in something like Perl, mostly just for emailing the webmaster. Maybe some small amount of JavaScript for something like rollover effects, but that's about it.
It's kind of like the situation today with the resurgence of JavaScript. One day the kids of the next decade will be posting snarky attitude basically calling JavaScript users retards because they don't use the cool-kids' PepoCOde. Lame. PHP is still excellent technology, and very relevant still for building dynamic server-side websites.
It used to be that people using JavaScript were made fun of for being "scripters", not "programmers". Everyone knows JavaScript is the language of Mort. Only Franken Elvis uses C.
I agree with rejecting the elitist framing but … the web was decidedly not mostly static before PHP came along. Perl had many frameworks (e.g. PHP started as one), as did conventional languages like Java, Python, with deep server integration possible using things like mod_perl. There were also a bunch of web-specific dynamic platforms like Cold Fusion and classic ASP / me-too JSP. Finally, there was server-side JavaScript as one of Netscape's offerings in the mid-90s.
What PHP added was primarily ease of use with the ability to deploy code simply by creating a single file, suitable for mass deployment at ISPs in the era where everyone used shared servers, and the combination of comparative ease of use with enough performance to do serious projects. Cold Fusion was also easy but didn't support things like persistent connections (read: order of magnitude slower) and the core language was very, very slow and also quite limited and buggy. You could find much faster options if you wanted to build, debug and deploy a conventional language like C++ or Java but the cost and risk was so much higher that this was unfavorable unless you really needed performance.
EDIT: if you want a snapshot of what the 90s web was like, http://philip.greenspun.com/panda/ was quite popular in the day. I know at least one well-known business which still has a revenue-generating website built in TCL, too…
PHP was easily one of the first to get some mainstream traction. I was using it in February '96, perhaps earlier. Classic ASP from MS was released in Dec 96, and didn't start making inroads (from my vantage point) until mid '97. I was stuck in '97 doing some odd front page weirdness (htc files? can't recall now) which were extremely limiting. At night, I'd go home and do PHP, and had an ecommerce system (horrible as it was) running on PHP/FI (php v2, essentially) in 1998.
By '97/'98 there were multiple vendors vying in this space - htmlos and ihtml are two names that stick with me, but there are some others I remember but can't recall names. And ColdFusion and whatnot, but... Perl and PHP were the big freebies, even by '97. ASP had speed on its side, but PHP already had convenience and price by '97, and it's gained ever since then. re: Java as server-side web platform - was outside my radar much, but the majority of people I worked with, even Java enthusiasts, didn't give it much credence before '99 - I don't think the infrastructure support was quite settled, and it was too 'wild west' for my colleagues (bunch of other reasons too). (IIRC, CF didn't support user-defined functions for several years, leading to much more difficult to maintain code than it should have been, but... memory gets hazy after 18 years).
But... PHP and Perl were free and largely "good enough" for enough of the problems most people were facing which is why they gained as much foothold as they did. ASP and CF both required a fairly hefty outlay and setup that you generally wouldn't be able to pay for without working in a corporate gig.
I definitely remember that era as the age of Perl but I should note that my first database-driven web app was in 1996, using a beta Java servlet runner with DB/2 on OS/2.
I'm happy to report that I got better at making technology choices.
I stand partly corrected. I only knew for certain servlet spec 2 was out in 99, and had not known anyone doing Java web serving stuff. I had colleagues doing java, and I worked in a commercial web house with those same colleagues, but none seemed to consider java web stuff (server side) usable (again memory's a bit hazy). I do know by 2000 some jumped in to servlets big time, but not many before that.
I think my first was perl/cgi in Jan 96 - not a full "web app" but I could read and write data via web forms to a database (msql IIRC). Feb 96 I know I was doing some PHP/FI, though still did a lot of Perl for years, mostly because that's what most hosts supported. For my own stuff, it was generally PHP even then when I had a choice.
If you were a corporate/academic programmer at the time, or lucky enthusiast, you had access to more things. Most commoner folk stepping up to a local ISP shell from BBS did not have access to all kinds of goodies. There also was less formal education available, so even when technologies existed, without mainstream marketing and documentation, it simply wasn't accessible to the masses. Cold Fusion was proprietary software from Macromedia you had to pay for, as I recall. Some admins were restrictive, and didn't even like you compiling your own stuff.
PHP really was responsible for the dynamic web. It had enough community support to enable newbies to wrap their head around the mind-boggling shift to dynamic server-side websites, and it became commonly provided with cheap or free shared hosting.
A big reason why it succeeded was because it was possible for people who only understood HTML to transition, since a PHP file could be nothing but HTML to start with, and people used a lot of templating rather than start from scratch with code that echoed out HTML. With things like Perl, it was not an HTML templating script first, and so that made it less streamlined and simple for the task of making websites.
Again, PHP made it better and easier but you aren't going to convince me that my direct experience didn't exist simply by repeating the same assertion.
Before PHP became widespread in the very late 90s there were many options for dynamic apps. I worked with ISPs which offered CGI or SSI even on cheap / free plans. Sure, it was ugly but a ton of people got what they needed done by going over to Matt's Script Archive and finding something they could hammer into shape. Before antique PHP apps, the security cliché was formmail.pl & a slew of long-forgotten guestbook / forum scripts.
I'm not saying that PHP didn't help considerably, only that it was very far from first. I remember having to make the case for using PHP 2 or 3 instead of many of those alternatives and it was based on cost and convenience, not the ability to do anything new.
I didn't say first, I said responsible, and first doesn't really matter. Albert Einstein's e=mc^2 wasn't first, it was already published by someone else written slightly differently. But he made it popular, and that's what counts for widespread adoption and propagation of tech.
You sound like an older hardcore nerd. You're from a different planet. What was going on in your circles was not at all a reflection of the web on a whole. Most people didn't even use ISPs in those times, they were on private systems like AOL. The dynamic web we know today, where almost every website is not static HTML, is because the majority of people making any little website had access to PHP, and free tutorials to learn.
Umm... no. I was talking about the subset of devs which are just chugging along without much thought put into the craft of programming. Which includes me sometimes, as well as many PHP developers. But not all of them.
Go search internet forums: "how i script PHP mail?" folks won't use the latest best practices.
And there were dynamic webpages before PHP, PHP just gave a ton more people access to them by easy installation, configuration and most importantly, development/feedback cycle.
I did read it, I know that the conclusion is that reaching out to Mort should be attempted. But most Morts don't work in software companies. And I doubt that reaching them is easy or cheap.
And it's not elitism, it's a fact that many developers are Mort in all situations. Yes, we're all Mort from time to time, but some people are just Mort :)
Not really. We're all relying on things we know to be working.
How often do you check 100% of the APIs you use for every kind of thing you develop (including shell scripts) for deprecation warnings or bad practice warnings?
I, for one, know that I don't. Except for NASA software, I don't think it's feasible.
The performance improvements in this release will hopefully encourage people to upgrade, even if the new features don't. Common PHP applications run 70%-100% faster on PHP 7 than they did on PHP 5.6, comparable with or better than HHVM.
The performance increase is what I'm looking forward to most with 7. I can't wait to see how several of my code-heavy WordPress installations do with 7. From the benchmarks I've seen, it's going to be incredible.
Specifically, I'm hoping the page load times will be cut in half.
My own anecdotal evidence - I couldn't believe how fast our Drupal 7 websites were, and they only threw a couple of deprecation notices. They definitely felt 100% faster. We will be upgrading soon.
I was so excited when I saw this post. Then I realized it's another 'too early' post claiming the tag == release. It's not released until it happens on the PHP site. This is just a tag in the repo. Sure, it likely won't change now, but it could.
Correct, it's not likely to change at this point. Official release is slated for Dec 3 according to their Twitter[1], so it appears they are getting everything ready to launch.
PHP 7 has been very stable, but a serious bug was discovered close to launch that made them delay the release by two weeks. There have been no serious issues found since that time, so release should be imminent.
and if you do this you deserve to burn in a fiery pit for being a bad bad bad release manager
If you tag a commit you better stick to your guns and never change it. You can't just re-tag or re-roll your releases because you found a bug. Bugs happen. Increment your version number, cut/tag a new release, and move on. You will never have a perfect release. Ever.
Yes, but moving a tag is very bad. A tag is meant to be an immutable pointer into a repo.
If you create a php-7.0.0 tag, and you find a bad bug, then make a new tag, either php-7.0.1, or since you might still want to call the release PHP 7.0.0, maybe name it php-7.0.0-bugfix1 or something.
Probably one of the biggest releases since 5 in my opinion. Scalar and return type declarations being added in are a couple of massive additions. For a language that used to cop a lot of flak, PHP sure has grown to become a mature and quite decent language.
I know, but... "I just think those pointless discussions of languageA vs LanguageB are infinite loops and languageA + LanguageB would make both sides evolve faster and the whole community would gain in the end."
Once upon a time it was Atari/Amiga and before that it was a bunch of other smaller computers... Now it's languages and the arguments sounds just the same.
Yes, quote a blog post from NEARLY FOUR YEARS AGO that mostly consists of "I don't like the way this thing is so therefore it's wrong" + "This is a problem that was fixed in a later iteration of PHP" to justify why PHP 7 is bad.
One thing I like about PHP 7 is that they had an opportunity to say "Fuck BC" and chose to use this version change to obsolete the shitty tutorials that make bad programmers (mysql_*).
Have you ever worked with php? I have only slightly and it was truly horrible. The library is a complete rubbish. You couldn't create worse one if you tried.
The language development is bad. Some developers are bad. Many users are bad. Does these points make the language bad? Yes. New features are incoherent and seemingly random, issues pop in and out (and back in) because tests simply fail, there are unexplainable security issues, documentation is bad, and if you look for any help (documentation comments, stackoverflow) you meet the users and their shitty tips.
Response to every criticism is "you just need to learn something". Does that make a good language? No. It's precisely what makes it bad.
PS: There's a nice subreddit for fun and laughs /r/lolphp - there are continuously new things as the language evolves, so the shittiness is not going away
PHP is the language many people love to hate; I guess some of them like the idea of being able to point the black sheep of web development, so that they can tell "maybe we have some flaws, but at least we're not one of these PHP shops".
Do you think there's a reason for that? Maybe a direct one? That it's a bad language for example? Why would it need to be anything more complicated than that.
So I don't think your guess is accurate. It's simply a bad language on its own. No need to compare it to anything. And I don't think anyone can deny that, no one will honestly say that "php is a good language". You can say it has some good features, or that it's good for certain tasks, or perhaps that it's better.. but that's all.
I think PHP is a great language, not just a good one, and its competitors like Python and Ruby offer little to nothing over PHP (and vice-versa). They're all in the same boat. Same programming style (OOP), same constructs, same runtime models (interpreted, JIT). I'm so fucking tired of people who have not programmed in PHP claiming anything, let alone that it's a bad language. I can make that claim about any language currently in existence with plenty of "evidence" to back it up, but my purpose here isn't to annoy. The only thing I can deduce from posts like this is that people lash out against PHP because they get off on being closed-minded and trolling others.
To me, it's a so-so language, with some bad parts, some ok. On the plus side, it's easy to pick up, and it gets the job done for many projects. Perhaps it's a bit like the Ikea of programming languages, if you will--no the best of furniture for sure, but when you need a table and some chairs with little efforts, it's nice to have, and they're not horrendous unless you couldn't build them correctly.
I like the IKEA parallel as IKEA is cheap. So was php (to host), hence the popularity I guess. And as a result of that, there are lots of developers.. and many equals cheap. And the vicious circle continues. Doesn't make it a good language :)
(To be honest, I like IKEA, and I don't think it suck)
> To be honest, I like IKEA, and I don't think it suck
Ikea sucks. Quite a bit of the furniture is just painted cardboard, the quality is absolutely horrible. It looks ok but 'under the hood' it is terrible. It is throwaway furniture, the very opposite of sustainable.
Weird, I've been using my IKEA bed, wardrobe and drawers for many years now and they're fine. Maybe I'm just happy to make do with convenience - like many PHP developers.
It isn't because moving implies taking stuff apart and putting it back together again. As you'll find after your move screws won't catch any more, some of your furniture will have been compressed (holes in table surfaces? WTF?, yes this actually happened to me less than 3 months ago). Surface finish is 1/10th of a mm so it'll scratch super easy.
That's their 'regular' furniture, I'm not sure if they have anything better either. Ikea put a whole raft of companies out of business with cheap and good stuff, once they achieved market dominance they dropped the quality they are selling to something horrific.
The library is C's fault. PHP is basically a scripting language around the standard C library. It's what makes it the fastest non-JIT scripting language, but also what makes it so inconsistent.
It's not really a matter of fault. If being a wrapper around C is a problem, it's a problem PHP designers made, for better or worse. That's not C's fault.
The scalar and return types are really a great improvement IMHO, I can't wait for Doctrine to fully support it for code generation.
But one thing which is missing is the nullable types, as currently it's either you always return a string and you can use scalar typing, or you sometimes return null and you can't use it (which I'm okay with)
The one thing I'd love to see is a native concurrency story with PHP. I'd put my vote in specifically to have Communicating Sequential Processes. I think that feature alone would take the language to another level. I know they've got stream_select, et al. and I've really enjoyed pecl event, reactphp, and of course there's HackLang's Async / Await if you want to convert, but having some modern / native constructs would be nice to have. Does anyone know if that's on the horizon?
PHP has pthreads which are slowly becoming a real thing. There are a few relatively non-minor stumbling blocks in the way, but I imagine that it'll be only 12-18 months between when it can be a priority and when it'll be part of PHP. I expect you'll be able to do true concurrency in PHP in the next ~3 years.
Ah yes, thanks for reminding me. I do recall coming across this project in the past, but never followed its progress. For some reason I decided against exploring further. I think it may have been disclaimers that stated it was still experimental (even though pecl had it listed as stable).
Congratulations to the PHP community with this milestone!
I wonder if people who switched to HHVM, will start using PHP again. HHVM has offered much faster performance than previous versions of PHP. The speed of PHP 7 is at par with HHVM.
HHVM is still a bit faster than PHP7 in most benchmarks (wordpress, etc.). HHVM has also JIT and consumes less memory per request. Though PHP7 is more backward compatible with real word PHP5 code bases and is easier to install.
> The server running pear.php.net had a fatal hard disk failure and gets replaced by a new machine this week. Until the new machine is setup, this page is up to let you continue installing PEAR packages via the PEAR installer.
Have been waiting for this anxiously. I've been running a few test builds on it occasionally, but its nice to have the guarantee to shift prod systems to it.
To me, PHP is still interesting, because of the ProcessWire CMS/CMF [1], which is basically the next best thing afte sliced bread (A generic hierarchical content structure, with a jquery-inspired PHP template API, giving FULL flexibility to customize your design and presentation to anything you like ... even REST apis are just a few lines of code in a template. Add to that dozens of dozens of extremely nicec features built in, such as automatic thumbnail resize through API methods such as <img src="{$image->size(90,90)->url}"> ... and you have something immensely powerful).
Of note: that issue has been ongoing for months, and most of the issues that were found were fixed in PHP core within a few days/weeks. Drupal 8's test suite even caught one regression that delayed the PHP 7.0.0 final release a few weeks!
Most modern PHP apps will work on PHP 7.0.0 with little or no extra effort, but if you have a large legacy app, and haven't ever turned on error logging, you may need to fix a bunch of deprecated code usage!
It really does. I work partly on a 10 year old PHP software. PHP 7 has apart from some other breakages some changes in the evaluation order that I expect to break everything. Thankfully related to objects, so with a bit of luck it will mostly hit the bundled libs (the project of course does not use objects for its own structure) which can then be exchanged or maybe will get updates.
When years ago I started learning Ruby and wanted to use it for the web, my intention was using it like you do with PHP (simply including it in HTML) but I got a bit frustrated because all the resources I kept finding showed the only way of using Ruby in a web context was by using a big framework like Rails or, by choosing a wrong path and playing with stuff which required a lot more in depth knowledge that I did not have (and that I didn't want to be forced to have because I just wanted to focus on app code and experiment).
I only recently discovered https://github.com/migrs/rack-server-pages which allows to simply shove Ruby in HTML the same way as PHP and as a new Ruby dev could expect to be able to do. I think this approach makes learning projects simpler, and at the same has the added value of making people actually learn a lot about those aspects of HTTP that frameworks keep well hidden under their carpet and that can help you become a good web developer instead of "simply" a framework user.
Yes for sure, best practices that frameworks implement are there for a reason, and it's great to have them, but IMHO, this approach has advantages when learning and could also be seen as an essential step to understand what those frameworks you will use next are abstracting and why.
IMHO, what still contributes to new generations of devs approaching PHP, is also its immediateness and simplicity with nothing to do except '<?php' code '?>' and with this comment I just wanted to give a bit more exposure to the fact that a similar solution exists for Ruby too, and that it's a bit of a pity that because of the importance of Rails it got a bit overshadowed.
Congratulations and thank you to everybody who has contributed. I've been running PHP 7 for my hobby project for the last couple of months. The update was refreshingly painless and I've had zero compatibility troubles so far.
PHP 7 literally cuts the load in half for PHP code which means hundreds of thousands of servers can either now save power or serve nearly twice the number of connections.
I've been anticipating this for a while. Some great additions, especially scalar type hinting and type hinting on return types. The ability to enable stricter typing via a directive is also great. It's a shame internals voted down short-hand syntax for anonymous functions, including implicit closure over outer scope variables - a function with closures in PHP can get ugly very fast. Using higher-order functions becomes far more unwieldy.
As a person with more of an ops background can someone explain to me why / when PHP might be a viable language? My experience with hosting PHP apps has historicity been one of fending off security issues and I think that often in the past PHP was often a language for designers that didn't have experienced programming skills, it feels like designers have now shifted to using Node for this?
"My experience with hosting PHP apps has historicity been one of fending off security issues"
Unfortunately PHP seems to have this reputation. It's not so much the language that is the problem but the people using it. PHP typically had such a low bar to entry that literally anyone could pick it up and do anything and everything with it. And quite frankly there were (and still are) a lot of beginner tutorials out there encouraging people to do very stupid insecure stuff. It now seems to be an image that stuck.
If you take a look at the OWASP Top 10, and any big data breaches recently, they are all caused by human error. SQL injection being the major culprit.
That explanation is technically true but it's like blaming human error for factory workers being injured by a machine without safety guards. Since it happens so frequently you have to ask how the language could change to make it less common.
Most of it comes down to being developed ad-hoc with convenience for solving a simple problem right now as the main driving force.
Remember register globals? That was a minor convenience which took ages and millions of exploits to be removed – I remember lobbying for that in the late 90s.
Similarly, you mentioned SQL injection. Unlikely as this may seem now, there was a time when things like prepared statements were an exotic new feature with limited library support and a certain school of programmer thought they were probably too slow. The docs and most tutorials didn't mention things like validation or escaping prominently so most PHP developers were trained to slop everything into strings. When PDO came along, this persisted for too long as well and even after they started recommending placeholders you didn't get something like all of the mysql functions saying “Don't use this, it's unsafe”. I've heard that this has improved but it's been years since I needed to look.
Similarly, look at the lax attitudes toward error handling — errors are ignored by default, database errors or warnings have to be explicitly requested, etc. That's “easier”, saving whole seconds of learning at the expense of millions of successful exploits and hours spent debugging.
PHP is the only lasting language where making code that allows SQL injection is easier than code that forbids it.
PHP includes all the worst practices you'll find on any languages. Javascript has the eval problem - PHP has it too; Perl have the too fluid type system where you can't specify anything - PHP too, except that it lacks Perl's tainted mode; Asp made it easier to create code subject to XSS than code that isn't and is subject to directory traversal - guess what, PHP copied it... and the list goes on and on.
This release fixes still some more problems, but PHP will never become a good language.
> PHP is the only lasting language where making code that allows SQL injection is easier than code that forbids it.
Pretty sure this is true for any language, the key difference is education. When learning JDBC for example, you're taught to use prepared statements with params vs. string concatenation.
It's not just about education.
PHP encourages bad practice. The language is implemented by people who haven't learned from the past 30 years of language design. It's made available to beginners and presented as "easy" when dealing with all the gotcha's is everything but. Etc.
Sure, you can learn how it works and a competent person could probably write safe code with it (given enough time). But it's really a dangerous language, the use of which should be discouraged. Better alternatives exist.
This is my general experience with all platforms and operating systems. You have to keep up to date.
PHP was early on the web scene, and like ASP it encouraged a lot of bad practices (like concatenating user input into SQL strings) before people knew better.
These days, in the hands of a competent developer, it's no worse than any other mainstream stack as far as security goes.
language for designers that didn't have experienced programming skills
A history lesson: PHP was originally known as PHP/FI which meant "personal home page form interpreter". That people started using it for "real work" took everyone by surprise, including the author!
It depends on whats being hosted. If you're dealing with legacy apps that were built in the PHP 5.2 or even PHP 4 days, be afraid. Be very afraid.
If you're dealing with more mainstream PHP apps like WordPress or Magento, its important to stay up on the core updates but also monitor the plugins and templates being installed. The majority of the attack surface on those apps is in the plugins because they're almost never audited.
As for modern customer apps, written in frameworks like Laravel or Symfony, you're usually fine. Those frameworks are on par with Django and Rails in being very hard to shoot yourself with.
> legacy apps that were built in the PHP 5.2 or even PHP 4 days, be afraid. Be very afraid
BS. Most PHP4 code runs just fine, as do PHP5 code. Almost no one used object oriented code in PHP4 days (it was slow!), so the incompatible changes aren't a problem. And all you need to do is to search and replace some function names like mysql_* to mysqli_*. Most old code bases from PHP4 days also didn't rely on frameworks at all and were completely written from scratch or copy&pasted together - actually an advantage in this case.
Upgrading an old Python or Ruby code from 1.x/2.x days is a lot of more work (as it always includes upgrading to a recent framework version) than upgrading from PHP4 or PHP5 to PHP7.
PHP historically had the advantage of being really easy to program for with limited knowledge, while still being powerful enough to let you evolve from small hobby projects to big enterprise web apps. Python and Ruby became popular for similar reasons, but they were harder to host, so PHP kept an edge. I would say that today go and node.js have similar programmability advantages, as well as eclipsing PHP performance-wise, but as long as they're not universally available from shared web hosts PHP will have a niche.
I use PHP for my freelance work mainly because I have no option on hosting. I never got the appeal for PHP (besides being cheap to host). All my personal projects are either done in Python or Node + (Angular, react & now Vue)
Python: PURE elegance
Node: io breeze
PHP: ?
Q: is the "module" system still achieved by dumping file content or is there a linking system?
Just curious, why do you have no option on hosting? I got into PHP many years ago for this exact reason - it was the easiest language to use on low-cost shared hosting. But these days you can get a decent VPS (where you have root and can use any language) for $10-$15 a month, which is exactly what I used to consider "low-cost hosting".
I live in Africa & $10 * 12 = $120/year is way too expensive --- when I say cheap, I'm talking about $3/month (shared, 20GB bandwidth, 1GB storage, MySQL / PgSql)
Great release! I think the BC breaks are all justified :)
And all the shared hosts around still stuck at 5.3 or so, this is your time to move forward. At least start offering a PHP7 version, if not a straightway upgrade.
For a long time, there was a PHP6 in the works, but then HHVM and Hack came around and started making PHP6 look bad. There was another fork called PHP-NG, I believe, which went in a different direction. There was a huge pissing match in the internals list, and in the end, I think they threw threw out most of the PHP6 proposals and started fresh. To clear up matters, they skipped PHP6 and called it PHP7.
Don't quote me on that, but that's my understanding of it.
The primary reasons for skipping PHP6 were that several books had been published on what PHP6 was supposed to be (full unicode support, for example), talks had been given and the original php 6 branch was ultimately ditched. The full list of reasons are at: https://wiki.php.net/rfc/php6
Given how dependent php is on hosts to upgrade, and how slow php hosts traditionally move, it would seem that php would benefit from a 7-to-5 transpiler, similar to Babel for JS. Does anything like this exist already?
Honestly, bigger PHP sites aren't dependent on hosts but on Linux distributions for staying up to date. Once there's an AMI of Amazon Linux and an Ubuntu LTS shipping with PHP7, there should be a huge upswing in adoption.
Funnily, there is no PHP 6. While work had begun for this version, it was later abandoned due to some major issues regarding Unicode handling, as far as I know. Most of the features already implemented in PHP 6 were shipped in PHP 5.4 and they continued with PHP 7 in order to avoid confusion.
I don't use PHP anymore. However, if you want to web program it really is the easiest to get started. So many of my friends who have no interested in programming but want to do simple web stuff learn how to setup apache with PHP and copy paste what they need.
It may solve your immediate problem. But it's dangerous - there are too many hidden gotchas and situations where you have to know the actual implementation (which can change) to know what it does.
It also breaks a lot of conventions established by most other languages, so you really have to be really careful when assuming that "this probably works like I expect" - you may get nasty surprises).
Ohh and it's pretty slow compared to other languages (like C++, Lua & Python - just to name a few).
And that's not even mentioning the fact that the people implementing it seem to be a case of the "blind leading the blind". Just search for how they tried to fix an integer overflow by testing if "foo>intmax" etc - that's just the tip of the iceberg (who the hell thought that converting strings to integers before comparing them was a good idea?) etc etc. Those guys should not be allowed near language design.
So yeah; it's pretty bad.
PHP's architecture is highly discussed in their mailing lists. If you have such a problem with the language, why don't you just jump in and show everyone the light?
I can't believe that you're still talking about things from 2007 or the horribly outdated fractal of bad design article. It's nearly 2016, do things not change in tech over the course of 4 years?
When we are talking about PHP I'd tend towards "no".
The only thing I trust them to do reliably is "fuck stuff up and get things wrong". They've proven very capable at that over the years and I don't see anything changing that.
I was waiting and waiting for this as well, but checked homebrew during RC6 and there was a PHP70-memcached, so I took that to mean it had finally caught up?
Yeah, I know there are two. I was under the impression that the original (memcache) was abandonware. How much difference is there between the two to migrate from php-memcache to php-memcached?
edit: never mind, I'm going to figure this out by using the internet!!
I haven't worked with PHP in quite some time now but I am happy to see its still kicking. Although it does bring back some haunting memories from versions 3 and 4.
http://php.net/manual/en/migration70.removed-exts-sapis.php
I actually met a young aspiring web developer who still learned DB-access with mysql_* functions. I urged him to switch to a sane framework like Laravel. Oh boy he was happy in a month and learned bunch of best practices quickly.