My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki. I run an instance for my family and it's great.
But there are loads of things. And I notice that many of the sites I like using...are built on well maintained PHP stacks.
How so?
I think the danger with PHP is more its ability to easily cause *very bad things*.
This would partially be poor training (my University literally taught PHP with SQL-injectable examples), and I think the language itself making it very easy, such that less-experienced developers using it - most of them, early on - don't realise what's wrong until it's gone wrong.
With PHP being such an early tool online, and the above properties existing, it earned a reputation for being insecure and bad.
Is there any language where you can't?
Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses
String a = new String();
String b = new String();
a = "test";
b = a + "";
if (a == "test")
{
// true
}
if (b == "test")
{
// false
}
if (a == b)
{
// false
}
PHP has an operator for something you should never do in a sane codebase.
You know that python wants good good to look good?
PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be honest with ourselves. It is a bad tool. Good programmers can even write good programs with bad tools. Doesn't mean you shouldn't avoid bad tools given the option.
There probably is a "PHP the good parts". But Javascript actually had a pretty nice core, and an utility of being in all web browsers that no other language could replicate. What niche does PHP have where it brings more value there other nicer languages can't be used instead?
Note though that @ was already neutered in some earlier recent PHP releases.
One common use case for the @ operator, is when "destructuring" array members into variables. In some cases, you can't know if the member will be available, but it's not important if it's missing. In that case, you can silence the warning.
$array = ['apple', 'pear']; @list($mainFruit, $secondaryFruit, $tertiaryFruit);
Since I suppress the warning that would occur due to the third member not being present, the program will continue executing instead of halting.
The @ operator doesn't get rid of exceptions it get rids of "warnings" which are basically built in log messages.
It used to get a bad wrap for also silencing fatal errors, but it stopped doing that a while ago.
The @ operator is something that should only be rarely used, but it is no way comparable to catching exceptions and doing nothing with them. There are sane uses for it.
For the longest time the language had been developed with this mentality that it's okay to continue running if something broke, that it's better to print out something than to do nothing and bail out.
Which means that for things to run reliably, you have to write very defensive code that checks everything you can think of. Which is probably a good idea with any language, but I find that old PHP requires much more of this.
Thankfully, they've been changing that over the past decade while still maintaining decent compatibility with old code. I just recently finished porting a pretty large project (~2 mil SLoC) from the ten year old 5.6 to the currently latest 8.4, and it's been pretty painless. The only things that broke were those that were never actually properly implemented and worked by pure chance.
During that same period, there were a lot of mediocre tutorials and documentation online, including on the PHP website itself which allowed people in comments to post code examples, but as far as I know there wasn't a lot of moderation on those.
And finally, a lot of people ended up writing their own frameworks and the like, because they could. But also because there weren't any or not many good and widely adopted frameworks out there, that came later with first Zend Framework and then Laravel, the latter being the de-facto standard nowadays.
But of course this assumes that you work with a team that can see a year ahead, let alone 10.
PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff.
Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as well.
There are languages that are _much_ more stable and reliable than that.
Not everything will always update flawlessly but with Composer and a popular framework with planned depreciations and releases the ecosystem tends to sync fairly well.
PHP code requires very little maintenance to keep working for a decade+.
AzuraCast because I like learning by looking at code and hosting my own radio/music
Another wiki that uses php is Wikipedia.
People like to shit on php but it powers some of the largest sites in the world.
At the end of the day, programming language doesn't matter much. You can be a good programmer in any language and a bad programmer in any language.
A really good forum software.
Coding in PHP can be a lot like playing the guitar or writing poetry: many people can do it, but it’s easy to do very badly.
My salary literally doubled within two years of getting a gig that wasn't PHP. If you see a listing for PHP dev work, there's a good chance it's notably lower salary. There are still solid gigs for it, but I swear they lean lower.
The other problem is the existing codebases. There is some awful legacy PHP 4 era code. There are also a lot of practices that old PHP had that are just awful to work with, and there's a bit of variety in there. So many bad data access patterns out there. Many of old PHP codebases have their own spin on that kind of thing.
I understand this isn't actually due to the language, but there is a real correlation (in my experience) between old bad code and it being in PHP. Which is totally fair because it was a good tool to reach for to "get shit done (r)" and that code was successful enough to have to continue to live.
Modern PHP has, thanks to the core language and the big frameworks, made it wonderful. I lead a big push to go from PHP 5.8 to PHP 8.1 at the time at my last company. It was wonderful. The quality of the code we were enabled to write was huge.
If I was starting a new project today, I probably wouldn't reach for PHP, but I'd gladly join in on a modern (last ten years) Laravel project.
The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function. It's a mess and more bug prone than just nesting the functions.
It's coming - but to get PHP RFCs to pass they have to be salami-sliced, otherwise they're voted down.
md5($password)
|> sha1(...)
|> sha1(...)
|> md5(...)
|> rot13(...)
|> crc32(...)Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.
The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching
Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).
When you consider this, it’s amazing that we get so much from so little.
What is your background? I've been working mostly with PHP and Python for about 25 years. Do you come from e.g. Java?
Now we have two syntax to be familiar with and maintain. And you just know the clowns are going to come along and convert one syntax to the other because they can, which completely ruins the git commit and you can't tell what actual functionally was changed at a glance. There will be bickering and bikeshedding about "modernizing" codebases.
I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…
Still, even if it was "just" the web, why wouldn't it evolve? It's a great language, with a big user base, and there's always room for improvements and to increase the developer experience
Although there is a proposal for adding "methods" but I don't remember the link.
I'm not a blind PHP hater, but it seems like PHP community members sometimes celebrate new PHP features when their equivalents have been there for many years in other programming languages. https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...
Imagine I want to AfD a custom string function for a feature which uPpErCaSeS every second letter as I need that for some purpose: I can't do in OOP style.
In OOP I could extend the string class, but most other parts of the code won't magically use my string type now.
Thus I have to create a free standing function for this (which probably also is better as I don't need internal state of thee object, thus livingnoutisde is good for encapsulation)
And thus my string function works different from other string functions.
my_casing($string->trim())->substr(3);
Having them all be simple functions makes it equal.
Of course there are alternative approaches. C++ argues for years about "uniform call syntax" which would always allow "object style" function calls, which could also find non-memwbr functions where the first argument is of compatible type, but such a thing requires stricter (or even static) typing, this won't work in PHP.
$output = $input
|> trim(...)
|> (fn (string $string) => str_replace(' ', '-', $string))
|> (fn (string $string) => str_replace(['.', '/', '…'], '', $string))
|> strtolower(...);
$output = $input
|> trim($)
|> str_replace(' ', '-', $)
|> str_replace(['.', '/', '…'], '', $)
|> strtolower($);As for the partial function application, there is already an RFC to add that, but it's not decided on as of now. [2]
1: https://www.php.net/manual/en/functions.first_class_callable...
var input = "Some kind of string.";
var output = Optional.of(input)
.map(i -> i.trim())
.map(i -> i.replace(' ', '-'))
.map(i -> i.replaceAll("[./…]", ""))
.map(i -> i.toLowerCase())
.get();
var input = "Some kind of string.";
var output = input.trim()
.replace(' ', '-')
.replaceAll("[./…]", "")
.toLowerCase();
I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.
#[SkipDiscovery(static function (Container $container): bool {
return ! $container->get(Application::class) instanceof ConsoleApplication;
})]
final class BlogPostEventHandlers
{ /* … */ }
Given that the cat effectively is out of the bag, does the example on the release page (sneak preview) make more sense to you: https://www.php.net/releases/8.5/en.php#closures-in-const-ex...?
> As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#"
Yes, unfortunately the off-the-shelf software of the Wiki uses a custom-built highlighter instead of the `highlight_string()` function that is bundled with PHP: https://www.php.net/manual/en/function.highlight-string.php
Clout.
TLDR: The PHP compiler isn't really suited for the job, it would introduce a lot of complexity to an already complex codebase and the memory/performance hit would be substantial.
Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.
Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.
> Adding generics to PHP would make CS fundamentalists somewhat happy
PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.
For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.
PHP chose to check types at runtime. To check that a value is really an array<int> the runtime could have to loop through the entire array. All the types PHP currently implements are simple and cheap to check. For more elaborate cases you need an offline checker like PHPstan and comment-based type annotations. (PHPstan catches 99% of issues before the runtime gets to it so for my own code I'd prefer the Python approach with its cleaner syntax.)
The runtime checking seems the key difference, not so much the historical strength of the type system. Python's language implementation does very little typechecking itself and PHP's third-party offline typecheckers are respectably advanced.
This could be the way PHP could go, they just need the lexer to handle types, and not do any runtime checking at all.
But i guess that goes against what the php devs want, but it sounds so wasteful, to typecheck the same code time after time even if it passed some sort of initial "compile time step".
This subtle difference has huge implications. You could in theory have an "compile step" in. Python, but in PHP you really cant as the program is never "running".
Python built syntax for types / generics etc. Its actually a quite capable typesystem (im not a python developer, but use python on some occasions). Python then has tools for static typechecking that can be run outside execution.
This means that if python would do actual static typechecking on runtime it would be nothing more than wasted cpu cycles.
Thats why python opted for the syntax only, as its basically zero cost. In php land the typechecking is done on EVERY execution, even if the code was unused. (a void functions that has an int param, but gets passed an string, that just discards the parameter). Even worse, a type error thats not executed wont be caught by every execution.
In short PHP typesystem is just runtime checks for primitives / classes and wont catch errors where not executed. Its like the worst of both worlds.
What do you mean by this? The types of variables in PHP >8 are not in comments. Or did I misunderstand something?
Why is it bad?
In particular, why is it worse than not being able to declare a typed array in your current scope? (I understand the basic argument in favor of typed arrays, but I also understand why PHP would choose not to go that route; I'm not sure I see how it's worse to not be able to return one from a function, given that they don't exist elsewhere.)
A even more simpler example is An array of some sort of Item. I cant return array(Item), but i only can return an array.
What is not working?
But that is no different than if you created the array in that scope.
So, again: Why is it "really bad" that you can't return a typed array from a function? What is worse about that than not being able to create a typed array in the current scope?
Also: What, exactly, about that is "not working"? As I said above, I understand the basic arguments about typed arrays; they're conceptually equivalent to weak/dynamic types. And there is value in having strong and static types. But it's hardly a showstopper not to, and PHP works just fine even if you don't use any. It just...makes it easier for us, as programmers, to make mistakes.
So to say it's "not working" simply because it's possible to add elements to the array that don't match the types you want seems like an exaggeration.
Yes array is the evil collection type of everything, but that's how it's meant to work. Array is the quick and dirty 'throw everything in there' thing. PHP has classes and they're very full featured and offer lots of type safety - use those.
LOL, no its not. PHP has an weak type system, while python is strong. Both are dynamic.
$sum = 10 + "50"; // 60 in PHP
sum = 10 + "50" // TypeError in pythonAlso, you can just flip on strict typing in PHP, and you should know that.
Really, that's probably enough for a lot of cases, because PHP doesn't have operator overloading. Yes, you can add '10' + 10 and get 20, but not if either of those go into any function. If you have a function that needs to do string stuff, you take string stuff in, and you don't have to worry about string operations or coercing ints or anything.
I have no clue what the future brings for PHP, but PHP 8 is definitely a good start, and we should put PHP 5 to rest.
PHP 10 might not be that different from PHP 8 for all I know.
We do not know if there will be "constant change". Out of curiosity, what programming language do you use that you also love?
FWIW, if by "constant change" you mean improvements or bug fixes, then I do not see why we should not have those. I do not even mind breaking backwards compatibility if the reasons for breaking justifies it, but it has to be a really good reason.
That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.
Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.
A person that invests time into their language knowledge will not have issues handling new syntax because they spend as much time as necessary to get familiar with the new syntax
So the criteria is being a 9-5 who doesn't particularly care about coding and doesn't invest time into their language knowledge
If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.
“Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”
And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.
And I would double down on my bet regarding ISO C related questions, as I have met a few folks that contrary to myself as language nerd, hardly know what is written there or have even opened the PDF drafts at least once in their life.
But, if you want an answer to your question:
You can learn to avoid undefined behavior in about 30 seconds.
If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.
> You can learn to avoid undefined behavior in about 30 seconds.
Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.
Before when?
Microsoft(R) MS-DOS(R) Version 6.22
(C)Copyright Microsoft Corp 1981-1994.
C:\TMP>type foo.c
void main() {
long q = 0;
q = 0/q;
}
C:\TMP>cl /Od foo.c
Microsoft (R) Optimizing Compiler Version 5.10
Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved.
[...]
C:\TMP>foo
run-time error R6003
- integer divide by 0
C:\TMP>type bar.c
void main() {
long far *p = 0;
long q = 0;
*p = 0;
q = 0/q;
}
C:\TMP>cl /Od bar.c
[...]
C:\TMP>barJava and C# are a couple other popular languages where the same is also true.
Python's success is explained by it being the language of choice for AI.
I think the reason is that it is easy to learn enough to get things done, but it is very flexible, very readable, and once the ecosystem started gaining momentum (which it clearly had by the time of the XKCD cartoon) that became an advantage too.
non of the "modern" things are particularly taxing to teach someone with more than two braincells. If they don't understand them then they haven't kept up with ANY programming trends in the past decade and are best placed infront of the TV with an iPad than left to mess with the possible critical infrastructure of a business.
The only one that's caused me any significant stress is the deprecation of the old `mysql` DB interface; I had to refactor a whole bunch of code for that, since I'm maintaining a codebase that's been in continuous use & development since 2001.
The additions to PHP since 5 add more things you can do, but they don't really change the simple things you can do to first learn PHP. You can still just create a .php file and start interspersing HTML and <?php script tags with basic operations.
But PHP 5 was released 21 years ago and is unsupported. Companies using it are putting their customers at risk.
Backticks as an alias for shell_exec() are deprecated
like in `mkdir $dirname`;
The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since the launch of PHP 5 and so it isn't as easy to understand from scratch as it used to be
ZEND?
I remember "nulling" software in the mid-00's and Zend was always a terrible ball-ache.
Which, if that was your project, is high praise. :)
But once multiple people are involved and I have to read someone else's code, then I really start to appreciate languages with less features. There are some language I love to write code in, like Ruby or Haskell, where I feel like a damn genius when I write it, but want to pull my hair out when I have to read someone else's code.
In the time that it took Python to go from Python 2 to 3, PHP underwent 5.2 -> 5.3 and 5.6 -> 7.0. 5.3 changed how you write PHP in a fundamental way by introducing namespaces and PSR0 autoloading. Then, 5.6 -> 7.0 cleaned up the parser, resulting in massive speed improvements.
They did this by not breaking the universe in these major updates...or really, any of there updates. Each update would break a few specific things, warn you about a few other things that were going to break in the near future, while giving you ways to shim the old behavior if you _really_ needed it.
They also gave you ample carrots reasons to update - aside from what was already mentioned, my personal favorite update was PHP 5.4 because it introduced short array syntax, made UTF-8 the default charset, introduced traits, and finally put register globals and magic quotes out of their misery...but giving you a shim if you had some ancient project that needed it.
If you're wondering why PHP 6 was abandoned, it was because it was an update in the style of Python 3 by breaking strings everywhere. In retrospect, I think the decision to cancel 6 was the right one. Somehow, I doubt that PHP would've had the influx of data science and AI that saved Python 3.
Hats off to the project - I've long been off of the CGI-style web development narcotic, but the language put food on my table for quite some time, and the people steering the language treated their community well.
I don't think the amount of breakage per se was the problem with Python 3. I think the problem was that for a long time (until u"" strings in 3.3? four years after 3.0?) there was ~no way for a library to support both 2 and 3 in a single codebase. That meant that each project had to either maintain a fork, or do a "flag day" migration, which in practice meant you couldn't migrate until all your dependencies were migrated. Big mistake in retrospect.
The lack of u"" is just another manifestation of the complete breakage they wrought upon Python's string handling, isn't it?
It was closer to a decade (3.7) till they'd put enough of the bits they'd ripped out back in for Py3 to be suitable for the things I used Py2 for.
Its still so annoying that you have to use mb_real_uppercase($name) for unicode. The other gripe is that the stdlib is SO messy. With PHP 5.3 they had a once in a lifetime opportunity to cleanup the stdlib and introduce a new namespaced API for builtins, and optionally introduce a uniform function call syntax:
"foo"->strtoupper();
PHP has come a long way from the PHP 4.0 era, but is still lacking in multiple areas, and i dont see it being a pick for greenfield projects in 2025.
As for concurrency/async, it's possible to do requests in parallel with curl_multi_*. Other async/prallel things are also possible, but tend to be more complicated compared to JS or other languages with promise and async support.
You don't see it because you're not looking. There are many Laravel jobs in my area. If you think that is only for Legacy projects, might be mistaken.
Jobs? Sure. There are PHP jobs, and the PHP devs are a dime a dozen. But i will agree with you, Laravel is a fine pick for websites, but not so much for more real world, high load applications.
Theres also 100x more jobs for WordPress than Laravel, so if you want to do PHP, i suggest going the WordPress route instead.
And who really cares about bloat anyway? Hardware is super cheap nowadays. People are expensive. So why not use a framework that enables you to be (in your terms) 100x more productive?
On top of that, you’re arguing about languages and frameworks you’re not even familiar with. Why does your opinion matter at all?
That told me all i need to know. When you work on missing critical software bloat is usually THE killer in disguise. And its really hard to get rid of after a certain point.
> So why not use a framework that enables you to be (in your terms) 100x more productive?
Because i can be just as productive, and even more so by vetting, and choosing my dependencies with some hindsight. I dont cowboy pick some hype of the day thing, i take a real close look at the code and want to actually understand whats happening.
> On top of that, you’re arguing about languages and frameworks you’re not even familiar with.
I am indeed familiar with the PHP ecosystem, been there and done that.
No, I'm not bitter.
People pointing fingers to "outdated" languages for not having some of the most trendy constructs.
The pipe operator is definitely one of the feature that create more ways to do the same thing while providing unclear benefit.
Never in my life I was in a situation like "with the pipe operator this I would have saved me hours of debugging/reading/creating code".
#[SkipDiscovery(static function (Container $container): bool {
return ! $container->get(Application::class) instanceof ConsoleApplication;
})]
final class BlogPostEventHandlers
{ /\* … \*/ }PHP 8.2 has this:
``` readonly class BlogData
{
public function __construct(
public string $title,
public State $state,
public ?DateTimeImmutable $publishedAt = null,
) {}
```
Whereas in php 5.6, to accomplish the same you need all this:
``` class BlogData { /* @var string / private $title;
/** @var State */
private $state;
/** @var \DateTimeImmutable|null */
private $publishedAt;
/**
* @param string $title
* @param State $state
* @param \DateTimeImmutable|null $publishedAt
*/
public function __construct(
$title,
$state,
$publishedAt = null
) {
$this->title = $title;
$this->state = $state;
$this->publishedAt = $publishedAt;
}
/**
* @return string
*/
public function getTitle()
{
return $this->title;
}
/**
* @return State
*/
public function getState()
{
return $this->state;
}
/**
* @return \DateTimeImmutable|null
*/
public function getPublishedAt()
{
return $this->publishedAt;
}Such a change makes it a completely different language with no compatibility. Thus all previous code is lost, no easy migration paths (especially for libraries which would like to support both during transition)
Maybe https://getrector.com could auto-fix 99% of code but it would still be very hard to get adoption.
What about introducing a new file extension for this? Something like MyClass.p so that .php is for classic syntax and .p Can support newer syntax? You could support old codebases while at the same time support better syntax.
It’s probably too much for the core php team to maintain both though
Most of the time if I want the first or last element I don't care about the array itself so array_shift and array_pop work just fine.
The url parse example is not being compared to the builtin parse_url function that is just as easy to use.
The pipe operator is indeed just syntactical sugar (and the article links to another article specifically about it which does cover the case of temporary variables), but with the coming partial function application feature it (in my opinion) will make easier to read/reason chains of code than temporary variables or nested function calls.
Probably because compile/interpret is one way street. There is no way to lets say view/transform a part of the code in functional or imperative depending on what you need to do with it.
Reading modern php or even worse mixed generations code base feels like another full time job on top of the regular one - coding with it.
I remember when escaping SQL input data was "the correct way" to use your mysql database. Parametrization? Nah, just use mysql_escape_string or whatever it was called.
So I guess it depends on what you mean by unhelpful. PHP as a language makes it pretty easy to do bad stuff. PHP as a community makes it easy to Do The Right Thing.
And let's be real - most handwritten SQL code in existence in most languages just builds queries from concatenated strings, even when more secure options exist. A lot of code doesn't even bother to escape anything. That's not a language problem so much as a developer laziness and assumption that "simplicity always equals correctness and frameworks are always wrong" problem.
---
Books:
* PHP & MySQL: Novice to Ninja by Tom Butler
* PHP 8 - Quick Scripting Reference by Mikael Olsson
* PHP 8 Objects, Patterns, and Practice by Matt Zandstra
* Programming PHP (2020) by Kevin Tatroe and Peter MacIntyre
I personally found them to be really good. I learned a lot from the first book especially.
You can find the code from the first book here: https://github.com/spbooks/phpmysql7
I hope this helps.
And a new language could have been developed , call it hack or whatever Facebook tried. Anyway I remember php coding gave me headaches. Tried it again 2 years ago and found out the same kind of issues(outdated /inexistent documentation, different ways to do the same thing that actually didn’t work and stuff like that). Try to connect to sql database using ssl and see what I mean.
I see no reason to learn PHP anymore or start up your company using php. We live in a vps/docker age. The advantage of php hosts everywhere has been lost.
But PHP is still so strong because it offers much more than "easy hosting".
What I personaly love most is the instant save file->see results feedback loop. There's no perceptible compilation step. Meanwhile my Java project takes a minute to compile.
Also the shared-nothing model by default is powerful and rare.
Laravel is probably the most well documented frameworks even comparing frameworks from other languages. And symfony, also a PHP framework, is not far from that.
When you say "SSL" I can only think your reasoning is based on outdated information since no one calls it SSL anymore. It's TLS for some years now. And I have been connecting to databases using PHP TLS/SSL since version 5. For almost a decade now.
- URI extension: there was already the internal `parse_url()` which was imperfect, and alternative libraries that were RFC 3986 compliant. An official extension will bring speed, but now there will be 2 official ways to parse URLs.
- The pipe operator is a matter of taste. In the release notes, the new code is more verbose, because it defines anonymous functions. This alternative syntax means keeping a consistent code style will be harder.
- The update of "clone" replaces 2 lines of code in some cases. Unless I misunderstood, it's a very minor change.
- The #Discard/void will replace the similar feature from static analyzers.
- Closures in constants is one of the 2 features that bring more than an alternative syntax. It's one more little step toward a preprocessor. But I'm not thrilled about the future #attributes assigned with complex closures.
- cURL persistent handles are a real performance feature, because curl_init() is costly.
- array_first() is a minor syntax-sugar. In a project of 100k+ lines of PHP, I probably could use it twice or thrice. Was it worth a global function?
PHP like Ruby had some big companies built on it - Facebook: PHP, Ruby: Github/Shopify
PHP was able to swallow Hack and become PHP8 - they optimized for getting beginners into the language / ecosystem
Ruby while a beautiful / friendly language and ecosystem - got into political wars - didn't optimize for beginners on windows etc
even as a person who favors Rails - Laravel is ahead -> on documentation & bringing various ways to do things into the framework. There's no stick with Hotwire. You wanna do livewire go ahead, we will help you. You wanna do Inertia + JS - go ahead we will help you.
nick-sta•2mo ago
hu3•2mo ago