Hacker News new | comments | ask | show | jobs | submit login

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/

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.




> 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.

Yeah, that's basically why I wrote EasyDB. https://github.com/paragonie/easydb

    $rows = $db->run('SELECT * FROM comments WHERE blogpostid = ? ORDER BY created ASC', $_GET['blogpostid']);
    foreach ($rows as $row) {
        // etc
    }
Teach people to do things this way rather than concatenate strings, say goodbye to SQL injection vulnerabilities.


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.

Tutorials need to be more upfront about that.


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.

I may be wrong, so please correct me if so.


I've got "writing an open access PHP 7 online book to hopefully serve as a new, best-practices tutorial" next on my to do list.


Yep. PDO still leaves room for string concatenation issues. Unfortunately, so does Doctrine.


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.


Laravel at least has Query Builder: http://laravel.com/docs/5.1/queries

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.


Like what kind of problems?


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.


Apologies, I meant string literals.

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.


Pop quiz: What is the singular cause of SQL injection, XSS, and stack overflows that causes a security vulnerability?

...

The answer is: Data being treated as an instruction.

Solution: Separate them so that data can never be interpreted as an instruction!

In SQLi, this solution is to use parameterized queries. You send the query in one packet, then the parameters in a second one. SQLi is thus prevented.

(Not that SQLi is the only vulnerability possible.)


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.


I wasn't being argumentative, I just thought that would be something worthwhile to add for people following along.


Gotcha, sorry. "Pop quiz" always makes me think it's being sarcastic.

So, yes, total agreement there. Parameterized queries are key. I find it crazy that anything else ever existed, let alone still gets used.


Ah, yeah, I hadn't considered the normal usage.

Most people don't realize how much these vulnerabilities have in common, in the abstract, until you frame it like that.


What do you think of Propel?


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


Doesn't holistic approach just make sense?

It's not like you learned to speak with your parents reading you the dictionary beginning with the letter A.


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).


The approaches aren't exclusive either, you can start "holistic" and then learn more by going "analytic" afterwards, once you have the gist of things.


Agreed, this is my preferred way of learning.


> Laravel ... solved lots of existing annoyances regarding PHP coding for me.

Can you name a few such annoyances and how Laravel addressed them?

And do you mean to say that Laravel addresses them, while other frameworks don't?


> 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.

Here's an entire presentation on it that I gave to a local PHP group. http://www.slideshare.net/barrywjones3/whats-the-right-php

FWIW, I do really like Laravel and even recommend it if you HAVE to use a big framework.


>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.


It does, but you get that whether or not you're using a heavy framework.

Without a heavy framework, you get the best of both worlds.


> A request comes in, the PHP process loads up everything, executes the request and tears down...on every single request.

It's called the "shared nothing architecture", and its by design. Nothing is shared between requests, so why _not_ tear down?

That model actually has a lot of benefits for web applications (it scales very well), and I consider it one of PHP's strong points.


I do to, except with heavy frameworks.


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.


That's not a bad thing fwiw. Rails is popular for a reason.


Pretty sure newer versions of php have an opcode cache built in, so they don't need to load everything on every request now?


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.


Can you give an example of something you would like to do that a framework like Laravel won't let you do or you feel like you have to fight against?


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.


My final project in my php class last year was way better than it would of been due to one simple website : http://www.phptherightway.com/

Edit: Posted this before seeing the other comments suggesting it already, dope


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:

http://www.phptherightway.com https://phpbestpractices.org

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 :)


Is phptherightway up to date?

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?


I work for a shared hoster and can confirm that PHP works great on IIS6 (with FastCGI add-on installed) and IIS7+.


Yeah, but this is what it actually says:

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).

[0]: https://www.microsoft.com/en-us/download/details.aspx?id=200...


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)


Very first part of the tutorial: "Use the Current Stable Version (5.6)"


Yes, 7.0 isn't out yet (it's only been tagged, it comes out tomorrow). And for a while yet it might be a good idea to stick with 5.6


> 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.


> Active Record Pattern is somehow controversial.

What is controversial about AR?


> What is controversial about AR?

How it represents rows as objects. How it makes people think about them.

How it conflates modelling the domain with database structure.

https://www.google.co.uk/search?q=activerecord+vs+datamapper


> How it represents rows as objects.

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.

My understanding is ORMs were originally developed to handle the mapping between domains, and https://en.wikipedia.org/wiki/Object-relational_impedance_mi....

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.


Soooo one row of a collection represented as an object instance of a collection of instances is bad? Why?


No not at all :)

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.


AR works nicely for simple basic queries but everything more advanced should be done with custom queries. That helps a lot :)


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.


Simple: CRUD operations

Advanced: Everything else


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?


I found http://www.phptherightway.com/ to be very useful. Here is also a review of it to get another impression of this freely available book: http://alanstorm.com/php-the-right-way-review


Thank you!


I thought Modern PHP by Josh Lockhart, also the author of PHP the Right Way, was a helpful overview.

http://shop.oreilly.com/product/0636920033868.do


If you're into videos, then Laracasts is awesome :)


I think the question is why should you bother with PHP at all? It had its time in the history of the web but that time has passed, long, long ago.


Wordpress alone runs 25%+ of all websites. PHP's time is clearly still now.

I probably won't bother with PHP, but it can't hurt to keep my idea of what it's like up to date.

It's only technology, no need to be fanatical about it.


To be fair, don't just down vote the parent comment because your don't like someone bashing php; it's a pretty reasonable question to ask.

Most people don't actually know that php powers such a large portion of the internet, because globally there's waning interest in php (http://www.tiobe.com/index.php/content/paperinfo/tpci/PHP.ht...) and it's generally dreaded by developers (http://stackoverflow.com/research/developer-survey-2015#tech...).

In all seriousness, why would you get into php at this point?

Do you want to go and work for Wordpress.com? (I mean, heck, they're building node sites now (https://developer.wordpress.com/2015/11/23/the-story-behind-...).

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.


I never suggested I wanted to get into PHP, I just want to see modern PHP to see how much of its reputation is still deserved.

Curiosity is a perfectly good reason to do things, isn't it?


Honestly I see more (well paid) php offerings than other rogramming languages. And most of it is not wordpress work.


Pretty much every job seeker website disagrees with this assertion...

...but to be fair, international sites may not reflect local conditions in your particular area.

In mine, I see virtually no php related jobs.

Still, stats show it as roughly 1/5 as 'in demand' as C# or java, generally.


Probably large part of it is an America vs Europe thing.


WordPress is a big part of it, but PHP goes even beyond that. 81% of all sites are powered by PHP. http://w3techs.com/technologies/history_overview/programming...


Cobol is still in use. That doesn't make it good.

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.


Yes, so everybody says, but I prefer forming my own opinion!

I simply don't like to call something that millions of programmers work with "pigs guts" if I haven't actually looked at it for about a decade.


But Cobol isn't used by 25% of all websites. It's just a tool, one that learning will give you access to a large share of jobs on the market.

Plus, who cares if anyone learns Cobol? If they want to, there is not reason to stop them.


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 ?


Not really. How many owners of those 25% of web sites are programmers who have any opinion whatsoever about programming languages?


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.


No the customers are saying they like the product (wordpress). They couldn't give a rat's ass what it's written in.


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).


Just because a lot of sites run it doesn't mean it's not crap. A lot of companies still host stuff on Windows like it's still 2002, as well.

PHP has no place in modern development.


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 I read it he's saying the language is crap not his peers who use it.


"PHP has no place in modern development" implies that peers choosing PHP for new dev are essentially incompetent.


Correct, though I would go with "ignorant of the state of the art", though "incompetent" means the same thing.


You do realize that the number 2 ranked website on the internet runs on PHP.

Get over your elitest attitude. PHP is a fine language and has it's warrants of use.

Speaking of, 2 days ago marked a year since I last used PHP.


Are you talking about Facebook? They're transitioning over to Hack.

http://hacklang.org/

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.


Hack is derived from PHP, they've only tuned the engine for their own usecase, and not to mention anyone in the PHP community can use Hack.

Hack is basically the TypeScript of PHP. Regular PHP works fine on Hack, but you can start incorporating Hack things into your PHP.

If you want to go that route, then my site is actually powered by Babel and not JavaScript.


> number 2 ranked website on the internet runs on PHP

The frontend is "PHP", but with a replacement engine, a replacement language, and a replacement standard library...

Having written a bunch of facebook-style Hack and wordpress-style PHP, I would personally consider them about as similar as C++ and Java.


The number one bank runs FORTRAN. What is the point you are trying to make?


>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]

[1]http://php.net/manual/en/function.date-sunrise.php


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.


What would you use instead and why?


Watch this video: https://www.youtube.com/watch?v=sTSQlYX5DU0 Erik Meijer likes php.


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.

http://blog.a-way-out.net/blog/2015/03/27/php-framework-benc...


That's how it's taught at the college I go to. About half the class already had experience with PHP/MySQL, and were a bit horrified.


aspiring web developer

Did he already know javascript? if not, why didn't you point him to that instead?


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.


Oh you can most certainly compile mysql right back into PHP7


Someone who's using mysql_* functions is probably not compiling their own versions of PHP.


Urge him to switch to a sane language instead. You are doing no one a service by advising them how to make using PHP suck less.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: