PHP has come a really long way, I really hope to see it's resurgence some day after everyone has been burned enough from running JavaScript as their server.
People seem to love to hate it because it's the "cool" thing to do. Yet PHP developers continue to ship things faster, while JS devs are probably still fiddling with their Node environment setup...
While I agree with this, I think the tone is slightly dismissive. From what I have seen, older people in our trade seem to recommend against PHP due to it having a terrible relationship with consistency, functionality, performance, etc. in its history. Though I have (thankfully) seen that the language and its standard library has undergone several large improvements, which is great to hear.
> Yet PHP developers continue to ship things faster, while JS devs are probably still fiddling with their Node environment setup...
On your point of JavaScript, the build environment nonsense can definitely get hairy. It's why we get things like Deno, which attempt to throw all this cruft away and start again. And sometimes that's a good idea. If you're dedicated to Node, replacing Webpack with Rollup seems to be what is generally recommended. The only obvious disadvantage there is compatibility with Webpack plugins.
It would be nice to have a type-checked JavaScript variant with a practically non-existent build environment (no Webpack, Rollup, etc.) As much as I adore TypeScript, the compiler itself is massive and takes quite a long time to even start.
Really happy to be working with it again, even if on the side for now.
For example, PHP could get along without async/await and promises in a lot of situations, because threading was effectively subcontracted to the underlying web-server. You could just treat, say, a curl call as blocking-- resulting in a simpler code flow-- knowing that wouldn't lock your entire web server.
The improvements over the lifespan of PHP7, and the new things in PHP8 make PHP such a nicer language to work with.
Just needs a FastCGI wrapper.
Another "Node, but PHP like" project that compares itself to EJS and other similar things: https://github.com/Yahweasel/nodejs-server-pages#why-nodejs-...
> Use the _ operator to format numeric values:
> $price = 100_10;
> // $100 and 10 cents
Makes it sound like the underscore replaces the decimal, which it doesn't. The underscores are simply ignored by the PHP parser, so that 10_0.1 === 1_00.1.
You could afterwards use PHP to replace the `_` with a comma for display purposes, and I assume that is what they are trying to say.
They really should just use a simpler example, like 10_000_000 being easier to read as "10 million" than 10000000.
> They really should just use a simpler example, like 10_000_000 being easier to read as "10 million" than 10000000.
Numbers can contain underscores for readability purposes.
These do not affect the value of the number, but can help read large numbers
more easily.
141592654 # how large is this number?
141_592_654 # ah, it's in the hundreds of millions!
Like all `Readability` issues, this one is not a technical concern.
But you can improve the odds of others reading and liking your code by making
it easier to follow.
[1] https://github.com/rrrene/credo/blob/master/lib/credo/check/...
And I've been loving all the new additions to PHP over the last few years as well. Version 5 was rather limited but since 7 it has grown into an actual programming language for which I feel I don't have to apologize for.
I guess it might be Stockholm syndrome - but I'm quite comfortable with a "list/array" type (numeric keys, ordered) and a "map/hash_map" type (objects as keys).
Especially give that with phps "power" you can:
$array = array(
1 => "a",
"1" => "b",
1.5 => "c",
true => "d",
);
var_dump($array);
array(1) {
[1]=>
string(1) "d"
}
And for the record, it's not Stockholm syndrome, I use plenty of other languages and I know the benefits and drawbacks of each of those.
It's not 'a' ⇒ 1, it's 'a' => 1, just write it out the correct way. Why are you trying to be fancy?
EDIT: I wrongly assumed at a glance because of the shape of the $. On closer look the characters are much wider than iosevka. It's jetbrains mono
PHP stdlib needs an overhaul, IMO.
However you do have options to choose from with php these days. Really well maintained libraries exist for basically everything you could want, often they are fast, well tested and modular. And it's nice because you can even choose the style you prefer with this.
Grab the symphony string lib for instance: https://symfony.com/doc/current/components/string.html
https://mobile.twitter.com/woketopus/status/1447150924846313...
[1] https://spatie.be [2] https://freek.dev
PHP should have chosen to undergo a rebranding a few years ago, if you ask me. The stigma it has to deal with is probably unsurmountable and will be forever. If you think PHP, you think WordPress and Joomla, and that means "hacks and vulnerabilities"...
It's a good language nowadays, with quirks like any other language, but I still have one big problem with it: There are too many "PHP developers" out there, and most of them are very bad, and many of the good ones are from poor regions in the world and you can find them on Fiverr doing kick-ass work for a grand total of $50.
if (md5('240610708') == md5('QNKCDZO')) {
echo "true\n";
}
php > echo md5('240610708');
0e462097431906509019562988736854
php > echo md5('QNKCDZO');
0e830400451993494058024219903391The 5840 built-in functions provide easy ways to get many useful things done with minimal dabbling.
In other words, one can be a "scripter" instead of a "programmer", and for many projects that's 100% OK.
Other languages automatically filter out "scripters" from their field by demanding a certain level of mental abstraction to produce anything moderately useful.
While there is absolutely no difference between a good programmer using PHP, or a good programmer using any other language/environment, but there is a big difference between the median levels and below.
This in turn lowers the reputation of the field, and it becomes uncool to put PHP on one's resume, therefore the more capable programmers propagate out to other languages, which further lowers the median, etc.
This happened with Perl, too...
It would really make writing scripts a lot easier and cleaner.
This approach also has the added bonus of stopping PHP from accidentally evaluating something inside the strings.
It’s really weird to me, I mean don’t we do this all the time? Work with eg. an $options array/obj passedto a constructor, or say, a message decoded from JSON…
I could write $name = $message[‘username’] … and there is no checks in ide or runtime, while the phpdoc will just document $message to be an object or array… what am I missing?
It looks like php devs create full blown classes to represent just about every data strcuture, but what if it’s just data and you don’t need any attached logic’ Isn’t there a concise way to declare a complex type?
Typed properties, constructor properties, and Read-only properties can significantly reduce the code bloat.
- https://php.watch/versions/8.0/constructor-property-promotio...
If I have a function that receives eg a Message, it means an instance of the class right? So somehow my assoc.array/object still needs to be instanced, and if I do just $message = new Message($theData) … it doesn’t auto assign properties right? That would be handy though still very much boilerplate.
I guessthe language is just designed for how it’s been used so far, may e it will change if JIT makes php more open ended in its uses.
Here's two of the most common ones. These are very mature and are very broadly used. Most editors also come with some support for these annotations so you often get help in the editor when something is wrong.
https://psalm.dev/docs/annotating_code/supported_annotations...
The examples you mentioned are interesting because I consider `options` arguments to be a code smell that tends to happen because TypeScript is missing named parameters, which PHP has. And typing JSON messages is far from a solved problem in TypeScript, because there is no widespread solution for runtime type checking.
It really needs a way to declare type of small data structures though, in a very concise way (no class boilerplate, for performance eg. going through 10000’s of entities).
PS : on the other hand I’m starting to dislike how languages become "designed by committee", and lose the purity of the original design.( thinking of JS mostly here with its gazillion rfcs)
JavaScripts nullish coalescing operator landed in chrome 80 (feb 2020) over 5 years later… more like it’s PHP syntax landing in JS land.
> Union Types - Combine several types into one union, which means that whatever input must match one of the given types: `function find(int|string $id)`
TypeScript and PHP have the distinct honor of being a popular language with ad-hoc union types (not the concrete subclass/enums that other languages seem to think are sufficient).
I wish frontend developers would stop messing with UI :(
Some of us edit the styles as normal practice for a large number of sites, especially after the widespresad use of thin fonts, grey text etc.
Surely there will also be tools (add-ons) to replace css elements as needed per domain...
The opposite is PHP5-style code from the early 2000s, no package management, no type strictness, no object orientation, just a giant spaghetti mix of JS, HTML, SQL and PHP in a 10kloc file.
The 7.4 did not finish the type system work. Docstrings were still needed for basic type hunting.
Exceptions as expressions--I can stop writing, `$x = $context['x'] ?? ThrowWrapper::missingValue('x');`
Named Arguments -- I use a hacky diy `Reflection` heavy version of this for an RMI/dispatch where json key-vals mapped to function params.
Static return type and union types -- I have been relying on PhpStorm docstring hacks for this sort of type-hinting.
`readonly` will be very helpful to express performant, immutable classes. I have a number of classes that are immutable-by-convention, trusting the caller not to monkey with the internals. (The idiomatic way to do this, `$immutable->getAttr()` is too costly in tight loops compared to `$immutable->attr`)
PHP still has lots of warts (function calls why you so aspensive?!?!?) but I keep being pleasantly surprised by how good of a tool it's evolving into.
Static return type, useful but since I use interfaces for everything it's not really needed. Union types, also not really needed because either 2 interfaces share a common ancestor or I'll have separate methods for different types. But most of the time, I encapsulate things behind interfaces that do one thing, so having different methods per type can often be avoided.
Named arguments are a pain for me since now I can't change parameter names anymore. This is particularly annoying with different coding styles in dependencies vs my own code. My code ends up not conforming to the coding standard that I've used since it was introduced (PSR-2R).
Exceptions as expressions is a nice to have, but exceptions in general are a thing to avoid doing. Not that things can't go wrong, not that chugging along in the face of errors is good, of course it's not. But if you have a lot of exceptions in your code, that's a smell of bad design. I've got 13 different exceptions used 20 times in total, over 4683 LoC on my current project. Mostly, whenever one of them is triggered, whatever I changed last was incomplete and led to an inconsistent configuration.
That said, your use case for PHP is probably very different. Especially since I don't care much at all about performance anymore. I used to, but CPUs are so much faster nowadays and PHP itself has improved.