A look at modern PHP
161–170 of 610 posts
Re: A look at modern PHP
#162PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.
By operating as a non-threaded application, entire categories of bugs and security holes are avoided.
Are there situations where threads could genuinely help? Sure, there is always an exception to any rule, but for the vast majority of projects where PHP is used, I don't believe threading would achieve much in terms of performance gains.
Re: A look at modern PHP
#163The main weakness I see in PHP is the lack of modules. PHP provides namespaces to avoid name conflicts. First of all, that does not completely root out naming conflicts. The developer who puts a namescpace into their code can only hope that it does not clash with someone else's.
Secondly, it makes it necessary that both, the code that provides reusable functionality and the code that uses it have to deal with the issue of namespaces.
A module system like Python and Javascript have is superior to this. Then only the user of the reusable code decides where to put it into the namespace.
Re: A look at modern PHP
#164The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…
For example "foo"==TRUE, "foo"==0 and TRUE !=0 are logically consistent now?
Or json_encode no longer returns null for invalid input?
Re: A look at modern PHP
#165For web applications, I think PHP's idea of a clean slate for every request also makes a lot of sense and immensely simplifies development. I can write a simple PHP application that handles thousands of concurrent requests without even thinking about threading, synchronization, memory leaks or anything like that because handling that stuff is basically built-in.
PHP has a really good ecosystem. A framework like Laravel can do just about anything you'd need in an application out of the box. Routing, rendering HTML, generating URLs, handling sessions, logging, validating requests, an ORM, translations, encryption, sending emails, queues, schedules, caching - it's all there. I've never seen anything quite as fully-featured in any other language. On Packagist, I can find packages for pretty much anything from clients for obscure SOAP APIs to libraries for handling GraphQL. There's also a lot of great tooling, with a good package manager, static analysis tools like Psalm, code formatters etc. Also, PhpStorm is a fantastic IDE.
Outside of PHP, I mostly have experience with Java and JS.
If you know Java, modern PHP isn't all that different. Java has some nice stuff that I hope we'll get in PHP some day (generics is the big one). I built an application using the Play framework (Java version) a couple years ago and it was quite similar to modern PHP frameworks. However, there was always a bit more complexity with Java. Everything was just slightly more complicated. So with the trade-off basically being performance (which is better in Java) vs. ease of use and developer experience (which I think is better in PHP), I'd choose PHP most of the time.
Now, when comparing it to JS, I'm really glad I mostly get work with PHP instead of JS. I know this might sound strange coming from a PHP developer, but holy shit, JS is a mess. When writing JS, I'm constantly going between "oh, nice, this is really easy to do with Vue" and "what the fuck does that error even mean, how am I supposed to find any problem buried under several layers of bundlers, polyfills, loaders, transpilers and reactive frontend black magic?". If JS wasn't the only thing that works in a browser, I would avoid it like the plague.
Re: A look at modern PHP
#166Earlier quoted context omitted.
It never made sense. The original hash bucketing mechanism for the function lookup in PHP was the length of the name of the function, so each new function was named a specific length to ensure the function list was evenly distributed across the hash table.
Can you link or be more clear? I assumed you are talking about the array and string related functions that are not consistent in argument order.
Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.Re: A look at modern PHP
#167If you're starting with WebDev in 2020, choose Go or Rust. Concurrency & safety + simple deployable static ELF binaries > weak typing and legacy bloat.
The paradigm and the workflow are alien to most, the discipline needed to write with it needs learning.
Re: A look at modern PHP
#168The thing that PHP does right that so few languages do is having a stateless core in the webserver. This is an incredibly efficient approach to serving HTTP traffic. Consider the startup cost issues with Java, or Rails' single request at a time model or even Python's startup (and GIL).
The second thing PHP does right is it request scopes everything. Simply throw away everything you created when the request ends. No dangling references and memory leaks (pretty much) like you get with stateful Java services (eg whatever servlets is now).
And the third is no multithreading in the core API. Starting and synchronizing threads is incredibly difficult to get right and adds a huge overhead to everything with little gain when you're just servicing an HTTP request, almost all of the time.
Hack has 2 things PHP7 doesn't quite have that I'd miss:
1. A better type system; and
2. async/await for cooperative multi-tasking.
I still hate the backslash for namespaces though.
Re: A look at modern PHP
#169The amount of misinformation, false claims and unsupported statements in this thread is mindblowing for the quality that I've been used to see on HN. Here are some facts: - Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language) - PHP has more active contributors than it ever had [2] - Laravel is one of the most used frameworks in the world…
Symfony is an outstanding framework and a real pleasure to build with.
I prefer Scala to PHP, the language is much more expressive. When you want to replace a bit of core functionality, in Symfony, you extend the desired class, add it to the dependency injection container, and you're done.
In the Play framework, I once wanted to make a one-line change to the routing. When it turned out I'd have to touch 30+ files which have hardcoded dependencies on each other, I quickly gave up.
Re: A look at modern PHP
#170I've hardly ever used PHP over the course of my 20 year career, being mostly on C, Java and JavaScript, but on the few times that I have, I have always been really impressed with all aspects of the experience.
Whatever academic semantic deficiencies PHP might have, there is no more accessible language for making web site backends with and its sad that so many people are discouraged from using it.