PHP 7.1.0 Released
php.net
php.net
Implicit nullables across the board are extremely useful when designing loose-coupled and natively unit-testable code. They allow you to design code paths with a minimum of fuss (don't worry about a parameter if you're not actually using it right now), they allow you to substitue simple nulls instead of mocks, and can help to deep-map code paths and use cases for specific parameters.
Another issue is the inconsistent manner of dealing with errors generated when attempting to use a parameter as its actual non-null type. They range from notices to fatal errors (non-catchable with try). By contrast, in Java you consistently get a "null pointer exception" when this happens (and Java also has implicit nullables).
One way is to forbid them outright (which is what Tony Hoare regretted not doing when he made the "billion dollar mistake" presentation IIRC).
Allowing them to run unchecked is obviously not a good idea.
The "null object pattern" is another option, where the nulled var will be replaced on the fly with a "mock" that will not cause any trouble.
Here's another approach. It's more convoluted and you need the language to help you with it (Java does), but it return it offers the benefits described in my previous post:
* Implicit nulls across the board. * No penalty if the nulled variable is not used in an ambiguous manner (passing-on and checking the reference are ok). * Consistent runtime fail-fast behavior if the nulled variable is used in a manner that requires the declared type. (Java throws an exception, which uncaught leads to the stop of the program, thus preventing undefined behavior, but also allows the programmer to catch and recover.) * Most importantly: you DO NOT check for nulls with inline checks or assertions, but instead rely on unit tests to validate intended behavior.
The technique is called "passing nulls" in UT.
The end result is a more "relaxed" code, which promotes loose coupling and leads to more flexible code paths, which in turn make possible additional patterns. If you're not hurting anything by nulls why be forced to conform to rigid declarations? And if you are hurting something, then you will be forced to deal with it in a consistent manner.
How is that different from the usual approach in Java, which exactly produces the problems observed?
Other languages, eg. Kotlin and now PHP enforce that variables and parameters that are declared to be not null are not null. Not null is the default behaviour. If you want nullable vars or params, then you have to declare it through `?`.
That is MUCH but why not on the very long term? One can dream.
Something like a disclaimer: Last time I seriously used PHP, rumors said that PHP 6 was going to be big. I actually fiddled a bit with PHP 7 too. I wrote a file sharing script (incredibly messy code because the minutes I spent on it are in the same order of magnitude of those I spent on this comment), which turned out to be damn fast and I am impressed. Saying this as a person who enjoys Rust and Go.
Why? Native PHP excels at html templating, that's what it was created for.
If they built syntax-aware templating in, that might be interesting, but AFAIK, for now you have to use a third-party template implementation to get something semi-enjoyable to use safely. It would be better to just throw out the "template" features because they encourage messy, unsafe code.
PHP's native templating is perhaps prone to more issues in this area, but template frameworks (for the most part) still allow you shoot yourself in the foot with data contained in strings.
1. Ease of quick-and-dirty prototyping
2. Large application code-base (especially Wordpress)
Your proposals would negate both of those selling points. What would be left to make it attractive? There are plenty of other languages that already meet your requirements.
Disclaimer: Actually a PHP developer. I know for a fact that if your proposal caught on, my managers would not like us to spend time rewriting a million lines of code to what is practically a new language. That doesn't contribute to making money for anyone.
I for one love the $ and wish other languages had a clear identifier for human variables.
Opening tag at the beginning of file is not really worth of doing anything about. If you separate concerns in your code, you don't do HTML in your model code, therefore the only tag in a the vast majority of PHP files is the opening tag a the top of the file.
Paradoxically, today you don't use PHP as templating language in modern PHP, because it is clunky. You use a templating language like mustache or twig.
Standard library, yes. That ought to be fixed. My proposal to solve that is to implement function autoloading and support for callable types (parameter and return type signatures to callables). With that you could start implement outside of PHP core and start deprecating old core functions and supply a library shim for those who need it.
And also with those two language features, it will be much easier to do functional programming instead of the now dominating OOP i the PHP community.
PHP since 5.5 is quite good and with this release it is even better. It is flexible but at the same time rigid with very good performance. No built in state, which is perfect for stateless API:s.
> Dollar ($) as prefix to variable names is actually quite good. You know instinctively what is a user created variable and not a language keyword. Easy to find variables when scanning large chunks of code and easy to use with string replacement to avoid string concatenation or sprintf.
Dollar prefix is hard to type with many keyboard layouts. You can also get the same effect with let/var/def/whatever and without the useless repetition. Also, any text editor with minimal support for your syntax would be able to highlight the definition/usages. The theoretical Utopian syntax would perhaps also allow $ in template strings. Further,
$foo;
Why shouldn't it be a compile-time error, in the same way as your suggested `def foo;`?
I can't think of a legitimate reason for wanting to write an intentional no-op (at least at the level of PHP; obviously assembly etc. is a different ballpark entirely).
Yes, a good text editor helps a lot, I use PHPStorm, which is the best IDE to use for PHP. But there are times when you just scan code like diffs or what not, then it helps. Or search/grep for that matter.
I type on a Swedish QWERTY keyboard layout, then you are used to use ALT-Gr for almost all special characters when coding, but I understand if you are on a US QWERTY then it can be a nuisance. Personally I find And ALT-Gr is easier to use then SHIFT.
US https://en.wikipedia.org/wiki/File:KB_United_States-NoAltGr....
The bits of code that talk to native PHP functions will be platform specific, but I've been building up a little library of utilities that work with Haxe's other compilation targets - mainly JS, C++, Python, and C# for me. I've been especially impressed with its Javascript generation - it emits very readable and understandable JS, and its dead code elimination is quite smart; if you import a library and only use one method from one class, that's all you'll get in your compiled code.
And if you're ever unhappy with the language and want to jump in and wrangle the syntax tree yourself, it has a decent macro system.
That's like having a son, growing up as a male, maturing, and then saying "I want you to also be a female now" - if you want a daughter, have another child.
1. The name might not be the most respected one after events, but the work he did and the technical points he made are entirely unaffected. In the light of Snowden revelations and NSA backdoors, Jacob Appelbaum once proposed a drinking game where you read RFCs and every time you encounter a requirement of putting random bytes "on the wire", you drink.
Now the NSA might or might not have been able to backdoor all common PRNGs, but Dual EC DRBG was one good example. There's just no good reason not to use hashing before outputting raw bytes other than the reason they removed it from PHP: "less complexity" and improved performance. Then again, in PHP the method was quite complicated with too many tweak options.
2. What if no CSPRNG is available? They seem to fall back and just "read 60 bytes extra for faulty PRNGs", which to my knowledge does not help much in preventing predictability. With a bit of bad luck, this would make sessions entirely predictable.
I really wonder whether they couldn't have kept a single hashing algo in with good defaults, rather than allowing to tweak this stuff. That would have been a big speedup and complexity removal already.
Could you please avoid speaking in riddles?
"function example(): string? {"
vs
"function example() : ?string {"
Even a blind php dev...
PHP actually once supported this kind of ambiguity (PHP/FI 2.0 ended PHP code with a single > yet also allowed if ($a > $b)), but this wasn't a good idea and resulted from a greatly suboptimal implementation.
Question mark never appeared directly after colon before this, so the second syntax is not ambiguous. The first one would be understood as part of a ternary operator, followed by choking on the start of a block.
Reusing :: for namespaces would complicate this. Is foo::bar a class constant or a namespaced constant? Do we autoload src/foo.php or src/foo/bar.php? If I do `new foobar::qux`, is foobar::qux a class, a class constant containing a class name, or a namespaced constant containing a class name? Do we autoload src/foobar.php or src/foobar/qux.php?
It's not like the lexer or parser could magically solve this. The way the language is designed, there is inherent ambiguity here.
In some other languages, there is a unified symbol table, so you don't have this problem. But PHP doesn't have that.
Because the alternative conflicts in case we ever introduce generics. Consider <?php new Foo<Bar?> ?>. This could either be a generic instantiation, or it could be the same as <?php ((new Foo) < Bar) ?> ?> (which is how it is currently interpreted -- this is valid PHP code!)
Of course, you could specify how this is to be interpreted and implement the necessary parser hacks to make it happen, but it's best to avoid the issue altogether by using ? as a prefix.
I assume that this is also the reason why Hack does the same.
But, for a brand new greenfield application. Why would someone choose PHP for their backend, when Golang is available?
I was at a developer meeting with a company who were reviewing what to use for a client project. The developers are from PHP/jQuery shop, however they felt it necessary to be with the times so to speak, for the future to get other projects. They opted for Vuejs and Golang with server side processing.
Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow with their own internal testing.
Many thanks!
- it's easier to find PHP programmers
- you get a lot of mature frameworks with huge communities
- most of the time you don't need fast but fast enough
I would hazard a guess that if PHP was not so hated (like the one kid on the playground that everyone decides to mock because everyone else is, and because it keeps attention off of them) devs who are familiar with and articulate in PHP would not hesitate to start new projects with it.
Anyways, my personal perspective is server-side is becoming a smaller and smaller piece of the web. Any reasonably designed language should be sufficient. Unless maybe if you're Google or Microsoft, or deal heavily with extremely large datasets such as BigData / Analytics / Machine Learning companies. And even then worst case scenario you just throw all the data into AWS RedShift or something like that.
If you're writing an OS, building a Linux driver or writing a memory management library I'd certainly recommend avoiding PHP :)
BTW, I've run side projects where PHP (before 7.*) sufficiently handled databases with 100's of tables containing billions (yes, that's a 'B') of rows each on a single $250 laptop. That includes jobs running relatively heavy analytics jobs on those tables. My guess is if the company was spending money to get appropriate talent to handle their infrastructure they might be able to make PHP work well for them without a lot of trouble. And by that I don't necessarily mean they have untalented people. I'm saying if they're truly "fluent" in PHP, or are willing to put in the effort to learn PHP, it shouldn't be hard to do.
No programmer can expect to use just a single language over their whole career. They might have career stability if they choose that but very risky stability.
So if Go looks better to you, you should use that.
The problem is that PHP needs to bootstrap the entire environment for every request (minus some more or less efficient caching) which may be OK for monolithic applications but as soon as you want to build an app on HTTP2 that runs many requests, it will just always feel sluggish. And for this symfony already cheats massively by merging all class files into one huge bootstrap.php file etc. PHP just wasn't made for large applications.
Personally I avoid ORMs and write SQL, better control and better performance.
Compare this to a Java Application using JPA and JAX-RS with >50 model classes and >10GB data which gives response times of <10ms with debugging enabled (OK it uses more RAM, but meh).
When you use proper opcode caching, you avoid the startup hit.
And having a generous amount of RAM usable as disk cache also helps in framework-heavy projects - the more files can be cached in RAM, the less PHP has to hit the disk on require/include.
In a setup with nginx, php-fpm and symfony here is how i understand the whole process.
1. A request hit nginx
2. Nginx parse the request and send it as fastcgi protocol specify to
php-fpm.
3. Php-fpm looks it's pool of php processes if there is none
available, it starts a php process (so some code is run).
4. Php-fpm fill the $_GET,$_POST etc... variable of the running php
and give it a file to execute.
5. The php process check if the file is in opcache load the bytecode
from it otherwise compile the file to bytecode and store it to
opcache.
6. The process run the script and write back to php-fpm who write back to nginx.
So now more on 6. from the point of view of a Symfony app.
1. the app.php will include an autoloader, this mean during the
lifetime of the php process every time a new
\Some\Class\Or\Function\Or\Whatelse is encounter the autoloader
code will be run. To mitigate this composer could generate an
autoload that is an associative array of \ClassName\And\The\Like =>
filename.
2. Then it include the bootstrap.cache.php this file is a
concatenation of the Symfony classes (all or the most used) in
order to reduce autoloader calls.
3. Then it create the kernel the it load more file (from app/cache)
like the service container definition+configuration and the
routing (and maybe more stuff but i don't know).
4. Then it put $_GET,$_POST etc... on it's own abstractions
(HttpFoundation\Request etc...).
5. At this point the bootstraping is done.
And i also want to remind that a class declaration like "class House
{}" is a code, that create a datastruct that has to be run on every
request, this is also what people call bootstraping.
The bootstraping is take seriously enough to have :
1. composer -o (generate the associative array)
2. bootstrap.cache.php
3. the whole app/cache directory of symfony which i find pretty
terrible as comp. sci. point of view (choose a limited language and
build compilers to work around) even if they do a great job at
error reporting.
4. php-fpm pool of thread
5. opcacheAnother question, with those modern PHP frameworks you are already learning and applying almost every concept that you can use with (let's say) JAVA. Then why not to use that powerful platform which inspires PHP? It is like you have driving licence for a truck and you can drive a truck almost perfectly after 3 months of practice, but still you prefer your old minivan to carry 10 tons of load. The minivan was not designed for 10 tons of load but there are some modifications allowing that, but if you spend 30% more fuel.
Don't come with the argument of "php is easy". It is as hard as other similar languages.
Large PHP frameworks I think is starting to reach end of line. Seems like a micro framework trend has started with Zend Expressive and similar middleware based frameworks.
There was a trend of making PHP into Java, I think that is the wrong path, as you say, Java already exists. That trend also existed in JavaScript a long time ago. Seems like a natural instinct by some developers to do so when trying to create structure from a chaos like world.
Much better to build on PHP strengths. Dynamic, stateless, fast development cycle.
Everyone else is just taking advantage of a few milliseconds here and there (for example compiled language vs interpreted language) that might "appear" the language is better suited to the task, but ultimately only are as good as the architect(s) of the system made them.
I disagree PHP the language is deficient in any significant way that would prevent anyone from building large, modern web apps with it.
We have pretty good success just using a user space cache, like apcu or memcached, along with the bundled opcache.
It does still have some bootstrap overhead with each request, but it's not become a performance barrier.
I suppose this is different at a certain scale, but I'd wager that's a pretty small percentage of real world use.
- easy deploy
- large community
- anyone can code PHP and become productive fast
- No built in shared state.
- PHP is available almost everywhere
- proven
- simple development cycleThe up-side to PHP is that it is super-flexible. The down-side to PHP is that it is super-flexible. You can work fast with it, which also allows you to be extremely sloppy with it. The programmer has to wield all the discipline, because the language sure isn't going to help.
The up-side to Go is that Rob Pike is older, wiser, and learned all of the mistakes of C and C++. Rather than have it be all things to all people, he made some very opinionated design choices with crystal-clear trade-offs. More code will have to be written. It will be in an imperative style. Errors will need to be handled explicitly rather than through a catch-all exception. Elbow grease! Elbow-grease that results in more robust code that is easier to understand and reason about.
So, why PHP? Sometimes quick and workable is preferable to slow and great.
PHP right now is in an interesting space: It's very stable, it has an enormous ecosystem, it has some extremely strong frameworks and tooling, the syntax has stopped being egregiously bad, it's starting to get quite fast, and the PHP request/response model is very attractive for some purposes, and avoids an entire class of bugs which crops up with, eg, nodejs.
If you're doing something where PHP is appropriate (which is a lot of stuff), and you're familiar with it, you're going to be extremely productive. Switching to golang (especially if not familiar with it) is like deciding that instead of going to the supermarket and buying a loaf of bread, you're going to buy a farm and figure out how to grow wheat. You have the ability to end up with a better product, but there's no promise you will, and it'll be a lot more work.
> Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow
Of course if the client requires you to use golang, then sure, use golang. But it makes me wonder about the design the client is imagining. If your web server is trying to do very intensive calculations as part of the request/response cycle, you're probably doing something very, very wrong. But if you're not doing that, why does your need to do intensive calculation impact your choice of frontend? What's stopping them from having a lightweight frontend which queues up jobs in a task queue, and then have workers written in golang or C or whatever? And then maybe a websocket server to feed results back to the browser as they arrive? Where did they get the idea that a project needed a single language for every feature?
I started my career with PHP, it really is a bummer that it seems destined for the language graveyard
Saying PHP is destined for the "language graveyard" is just spreading FUD around a language that made miraculous improvements in a last couple of years. Both in terms of speed and language features.
Modern PHP is a joy to work with.
Would you clarify that? I've not followed PHPs evolution but it never struck me as a particularly notable language except for the fact it used to be the easiest/cheapest to deploy apps for.
It got a proper, rewritten, parser.
It got a free-double-the-speed update for almost all working code in version 7.
It got a full featured package manager (composer).
It got many next-generation frameworks and libs that don't fall prey to the issues that plagued early PHP codebases.
It got the "share nothing" model correctly from the beginning.
It's still the easiest and cheapest to deploy, and has tons of extensions for everything.
There's active work for a JIT and async (a la Node/Tornado etc) hooks.
You can also lighten Symfony's footprint: http://symfony.com/blog/new-in-symfony-2-8-symfony-as-a-micr...
Great. Are you really telling that one of the selling point of the language is that it got a "proper" parser, In it's 7th iteration and 20 years later? What. A. Joke.
EDIT: And downvoted. Classic Php apologist response..
For one, I just saw your comment, so didn't downvote you when you wrote that. Others did.
That said, "classic X apologist" is beyond juvenile for my tastes, so any downvotes I'd call deserved.
Yes a language can get a proper parser "in it's 7th iteration and 20 years later" and still be good for some use cases and a success. In fact, the mere fact that it got to its 7th iteration and had a huge following despite not having a proper parser might point you to the fact that it should have gotten some other things very right to compensate.
But that would require thinking, instead of a knee jerk reaction and a general assumption that everybody using it is stupid and you are the clever one.
Yea, like letting people compare "0x0a" == "10" and have it return true. Sure. I can imagine some newbie somewhere looking at that and go "You can do that? That is soooo coool".
A lot of such things, that traded off sanity and security for ease of use made it popular. But that does not mean it got those things "right".
I am ignoring other inflammatory things you said, since I don't expect any better from someone who thinks php is hot shit. It is utter crap, and no one should have to start their programming career with utter crap like php when there are so many alternatives.
Ease of use is sanity in its own right too.
And C has been praised to high heavens by the most hardcore of hackers, but nobody would dare call it "secure".
>I am ignoring other inflammatory things you said
I think you confuse what the word "inflammatory" means. You posted ad-hominens in both this and the previous comment.
I am not sure what that means. By sanity, I mean sane/sensible/unsurprising behaviour. As an example, think of a gun with a feather touch trigger. It improves "ease of use", because you don't have to "pull" on the trigger and might improve accuracy for people inexperienced with guns, but it trades off safety completely. Php is like that. It was a language meant to process data coming from html forms. A lot of these insane behaviour can be attributed to that.
Because there hasn't been a formal/proper development/review process [1], only god know what hidden pitfalls there are hidden within the language, that is, in addition to the pitfalls people already know..
Php 7 is a dangerous farce, because it still has got all these problems, but is marketed/promoted as a "modern" language. Luckily, it seems that very few people are buying it..
[1] https://www.reddit.com/r/lolphp/comments/5fhmbg/if_an_invali...
It means that being easy to use is a desirable trait if you want a sane development experience. Having to go through bs hoops to use some language/tool/etc can drive you insane.
>By sanity, I mean sane/sensible/unsurprising behaviour.
And you'll find more or less the same amount of insanity in C or Javascript, as you will in PHP.
And in PHP it's mostly moot, because the insanity is in corner cases and stuff that's trivial to avoid.
I feel like PHP5+ was made by Jetbrains to sell their overpriced Web IDE solutions.
Isn't it more like that with Javascript an IDE can't help you much anyway.
Ever checked Ruby's or Python's feature list? Or ES7 for that matter?
I assume you mean because they both use literal words like "class", "public", "private" in the syntax?
It seems fairly logical to use descriptive syntax to me. See c++, c# as well.
Anyway, PHP is alive and well, people picks it for new projects too, and 7 was a big jump forward in the right direction, imho... it is just slowly getting better. People also thought that C++, my second favorite language, is also destined for graveyard...and, it isn't. :-)
I don't think you should worry about it. There are so many languages and organizations out there, majority of them better than PHP for nearly every task.
Just ignore PHP and be happy! I'm trying to get there currently, but just need some more time to shed the pain of being in a rather obstinate PHP organization for a few years :)