PHP 7 Released(github.com) |
PHP 7 Released(github.com) |
That comment looks a bit scary if it's true :(
Python: PURE elegance
Node: io breeze
PHP: ?
Q: is the "module" system still achieved by dumping file content or is there a linking system?
Hostgator, Godaddy...
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.
Huge thanks to the internals for their hard work.
The latest release according to php.net [0] is 5.6.15 which come out October 29th of 2015.
Don't quote me on that, but that's my understanding of it.
Yes.
Good.
I haven't laughed this much in a long while. PHP was my first language and indeed I got far away as soon as I knew any better.
Yup, there are two, and they are entirely different.
One uses the historic library, the other uses the new library. Why they decided to do it this way is beyond me.
edit: never mind, I'm going to figure this out by using the internet!!
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?
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.
...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.
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
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".
Edit: Posted this before seeing the other comments suggesting it already, dope
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 :)
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?
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.
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 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.
What is controversial about AR?
Thankfully I didn't get the chance to do any damage before I was exposed to modern best practices.
http://blog.a-way-out.net/blog/2015/03/27/php-framework-benc...
Did he already know javascript? if not, why didn't you point him to that instead?
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.
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.
disclaimer: I haven't written anything significant with PHP since too many years.
Specifically, I'm hoping the page load times will be cut in half.
[1] https://twitter.com/official_php/status/669940548128534528
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.
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)
https://wiki.php.net/rfc/nullable_types https://github.com/php/php-src/pull/1045
With this, it will permit to have even better static analysis "a la" HHVM/hack (i.e detecting that you haven't check for is_null in your code
- Type declarations (this is a HUGE move forwards).
- Grouped use statements, not sure if I like how that looks
- ?? will shorten statements
- Anonymous classes seem a bit odd looking to me
- Unserialize filter is a nice security bump
Anxious to try it out and see the speed improvements I've been hearing about too.
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.
"build error".
Wait, what? You just released it, it should definitely work! Clicking that icon[2], checking the failed build[3]:
ERROR: no certificate subject alternative name matches
requested host name `pear.php.net'.
To connect to pear.php.net insecurely, use `--no-check-certificate'.
Really? See what's in http://pear.php.net/
> 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.
In 2015? Cool.
Connecting to the https website ...
% openssl s_client -connect pear.php.net:443 ... Certificate chain 0 s:/CN=mail.cweiske.de
So you're using CN=mail.cweiske.de for pear.php.net. I don't even know what to say.. Well, happy hacking!
[1]: https://github.com/php/php-src [2]: https://travis-ci.org/php/php-src [3]: https://travis-ci.org/php/php-src/jobs/94372493
Do you actually think there's a point in time where mechanical hard drives are going to last forever? If so I have a bridge to sell you.
Hard disks fail, but if you're hosting something important on them, you might want more than one (to grossly oversimplify things).
>So you're using CN=mail.cweiske.de for pear.php.net. I don't even know what to say.. Well, happy hacking!
Yeah, but it's cool that they used Let's Encrypt.
string random_bytes(int $numBytes);
int random_int(int $min, int $max);
New Features list is at https://secure.php.net/manual/en/migration70.new-features.ph...
My favorite is scalar typehinting by far.
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!
Lots of work.
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.
win-win
almost as fast as hhvm but much easier to adapt
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).
The ethos of PHP is to just get stuff done: http://axonflux.com/5-quotes-by-the-creator-of-php-rasmus-le...
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?
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 )
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 .
Or, to keep with the JS example:
JSON.stringify()
This is comedy gold! I almost didn't spot the sarcasm :-D
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).
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.
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 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.
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.
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.
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.
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.
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!
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.
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.
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)
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.
There are a lot of frameworks (too many frankly) and tooling that enable quick building of custom sites.
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
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.
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.
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 :)
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.
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.
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...
"LAST UPDATED: 2015-11-16 16:19:03 +0000" (right below their banner at the top)
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.
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].
[1] http://stackoverflow.com/a/186920/242520
[2] https://www.jetbrains.com/resharper/whatsnew/whatsnew_9.html...
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.
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.
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).
> 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).
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…
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'm happy to report that I got better at making technology choices.
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.
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.
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.
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
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.
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?
foreach($things as $thing) {
$thing->setValue('new value');
}
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
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 :)
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.
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.
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.
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
}
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.
I may be wrong, so please correct me if so.
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.
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.
"Make them suffer like us and they will learn the holy truth" ;D
It's not like you learned to speak with your parents reading you the dictionary beginning with the letter A.
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).
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?
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.)
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.
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.
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?
Curiosity is a perfectly good reason to do things, isn't it?
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.
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.
Plus, who cares if anyone learns Cobol? If they want to, there is not reason to stop them.
You can see how your opinions come off as ludicrous ?
PHP has no place in modern development.
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.
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.
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]
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'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.
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.
Without a heavy framework, you get the best of both worlds.
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.
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.
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/
Advanced: Everything else
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.
...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.
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 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.
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.
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_*).
Every reddit post about PHP outside /r/php ends up with it as well.
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
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.
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.
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.
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.
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).
(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.
...
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.)
So, yes, total agreement there. Parameterized queries are key. I find it crazy that anything else ever existed, let alone still gets used.
Most people don't realize how much these vulnerabilities have in common, in the abstract, until you frame it like that.
They do "regular" furniture as well, not sure about its quality though.
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.
I have an ikea bed and rack that is made from wood. Lots of their furniture is regular wood. The cheap ones usually untreated.