[HN Gopher] Modern PHP
___________________________________________________________________
Modern PHP
Author : doppp
Score : 226 points
Date : 2022-03-24 06:43 UTC (3 days ago)
(HTM) web link (dnlytras.com)
(TXT) w3m dump (dnlytras.com)
| boredtofears wrote:
| Just curious, does match expressions have any advantage over
| using a hash (or in PHP terms an associative array)?
| francislavoie wrote:
| Yeah, it's more like a switch but as an expression. Some more
| examples: https://php.watch/versions/8.0/match-expression It
| only executes the matching branch, ignoring the others. If you
| used an array/map + index, then it executes the right-arm of
| each of the options if they're functions for example, even if
| their result is thrown away.
| Moru wrote:
| The Named Parameters [0] are useful but there are editors that
| solves the problem in another way. Write a function with a
| docblock [1] on top of it and then mouse over the function call
| and it shows you the documentation of the function with every
| parameters use. Or start typing the function name and
| autocomplete fills in the rest with parameter names and show the
| docblock above. Saves my sanity many times per day.
|
| [0] https://dnlytras.com/blog/modern-php/#Named-parameters
|
| [1] https://docs.phpdoc.org/latest/guide/guides/docblocks.html
| Beltalowda wrote:
| The obvious downside of this is that you're adding all these
| noisy "@param string $filename The name of the file." and
| "@return string The modified filename." comments.
|
| A lot of PHP projects are littered with this kind of stuff, and
| when there's actually some important comment it's easy to miss.
| Tijdreiziger wrote:
| Isn't this a pretty generally accepted pattern? Java and
| Python use a similar format for their docstrings.
| Beltalowda wrote:
| It's okay-ish if you need to document that actually needs
| documenting, but if you use docstrings for typing/IDE
| assistance people will document every single thing for
| that, leading to useless "documentation" like in my
| previous comment.
|
| That said, I personally prefer just a paragraph or two of
| prose over "structured" formats.
| paulryanrogers wrote:
| Agree, I like to see at least an example value in the
| Docblock
| deergomoo wrote:
| I think named parameters were a mistake for PHP. They weren't
| really added for documentation purposes, but to avoid the
| situation where a function with n arguments with default values
| needs you to specify all the intermediate ones just to override
| a value at the end.
|
| They're a great idea in languages designed with them from the
| start, but adding them to an existing language makes something
| that was previously a private implementation detail part of the
| public contract, and only for certain versions of the language.
| There are already packages that opt out of considering
| parameters names part of their semantic versioning, effectively
| demoting it to a "use at your own risk" feature.
|
| I would almost have preferred it to be added only as a special
| case for built-in features, which are almost all plain
| functions and have become somewhat unwieldy in places. Third-
| party code is more often than not object oriented, and so could
| easily lean on stuff like parameter arrays or fluent interfaces
| to avoid the ergonomic issues from having tons of parameters.
| conradfr wrote:
| I would have preferred a "default" keyword.
|
| So given: function foo(string $arg1, int $arg2=2, string
| $arg3='reddit') {}
|
| You could called it like: foo('bar', default, 'HN');
| danielovichdk wrote:
| What is this array'ish construct ?
|
| ['title' => $title, 'description' => $description] = $post;
| deergomoo wrote:
| It assigns the values of $post['title'] and
| $post['description'] to the variables $title and $post,
| respectively.
| faitswulff wrote:
| Aside, but I hate ligatures in code. If I didn't know what they
| were, I would have no idea what the blog's representation of a
| fat arrow => or a triple equals were. As it is, I still have to
| translate them before I fully get it.
| unfocussed_mike wrote:
| I heartily agree. Ligature fonts and the word "performant"
| belong in the same circular filing cabinet, marked "not as
| clever as it seems".
| jimmaswell wrote:
| Performant: well-performing. There's nothing wrong with the
| word.
| unfocussed_mike wrote:
| Don't feel too bad. Everyone has to be wrong about
| something. Luckily for you it's something small like this
| ;-)
| nkozyra wrote:
| What am I missing?
|
| https://dictionary.cambridge.org/us/dictionary/english/pe
| rfo...
| unfocussed_mike wrote:
| > What am I missing?
|
| My joke?
|
| (I always forget how HN is hostile to whimsy. Even when
| it is carefully signposted with an emoticon.)
|
| Just to add though: a word making its way into a
| dictionary is no guarantee of its usefulness, correctness
| or value. It only means a couple of definitions have been
| found in print. That's the standard by which words make
| it into dictionaries; there's no semantic gatekeeper.
| nkozyra wrote:
| You're qualifying my response as "hostile?" I guess we're
| getting into fluid definitions, so sure :) I'm not sure
| calling someone wrong accompanied with an emoticon
| qualifies as whimsical, either.
|
| All that said, "correct" in language is "incorrect"
| tomorrow. That's how it's always worked.
|
| If I learned to accept "entitled" as meaning "given a
| title" I'm sure we can all handle a fairly terse and
| parseable usage for performant.
| unfocussed_mike wrote:
| > You're qualifying my response as "hostile?"
|
| No, not you -- that was exasperation at the sudden,
| aggressive downvoting of what was clearly signposted as a
| joke. > I'm not sure calling someone wrong accompanied
| with an emoticon qualifies as whimsical, either.
|
| It was as clearly whimsical as I can make it.
| Complimenting on being wrong on something so small.
|
| But you're just making my point for me. I genuinely
| forget this place hates jokes that don't come with
| footnotes.
|
| > If I learned to accept "entitled" as meaning "given a
| title" I'm sure we can all handle a fairly terse and
| parseable usage for performant.
|
| "Never give up! Never surrender!"
| nkozyra wrote:
| I think the issue is less jokes than posts without enough
| context to live on their own.
|
| I've seen plenty of humorous posts received well here
| when they're not jokes for the sake of the joke.
| unfocussed_mike wrote:
| Fair point.
| petepete wrote:
| It was only added to the OED in 2018 after being misused in
| tech for fifteen or so years.
|
| Originally a performant was someone who'd performed in
| something (similar to combatant).
|
| Unfortunately it stuck.
| nkozyra wrote:
| Why is it unfortunate? The English language is built on
| an endless supply these mutations.
| petepete wrote:
| Just taste really, it sounds wrong to me.
|
| On the scale of new words I dislike, it's nothing
| compared to how football pundits describe players as
| 'unplayable' when they're on form.
| anamexis wrote:
| Surely the worst word to come out of sports pundits is
| "winningest"
| unfocussed_mike wrote:
| On a scale of new words I dislike, it's actually more
| annoying to me than "revert back" meaning "get back to
| you on that", which has a wry charm.
|
| Mind you, I am still annoyed by people saying "addicting"
| when they actually mean "addictive", or "concerning" when
| they mean "a cause for concern".
|
| So I'm really not a good judge. But it still has to go in
| the circular filing cabinet.
| 1123581321 wrote:
| If we were better at keeping -ive suffixed words, we
| could have had concernive instead to shorten that phrase
| without misusing -ing. :)
| unfocussed_mike wrote:
| Now you're just trying to upset me. ;-)
| yakshaving_jgt wrote:
| Greetings, fellow curmudgeons!
| ojintoad wrote:
| I remember when I saw the access operator "->" for the firsr
| time written as just a single connected right pointing arrow
| on a whiteboard as part of my first intro to programming
| class and being so confused about what button I was missing
| on my keyboard!
| bmn__ wrote:
| The key (vulgo button) is not missing, merely the legend
| (vulgo labelling). In X, you can either press _AltGr_ + _i_
| or _Compose_ , _-_ , _>_.
| unfocussed_mike wrote:
| IBM used to have a specific keyboard for APL programmers
| :-) Go big or go home.
| prophesi wrote:
| I think the hate for ligatures is overblown. You'll only
| encounter them in code, so you should instantly realize what
| they represent. I can understand _preferring_ to not have
| ligatures enabled, but hating them entirely seems unwarranted.
| eyelidlessness wrote:
| It's an opinion. About typography. I can't understand having
| an opinion that another person shouldn't have whatever
| opinion about typography they want.
| prophesi wrote:
| If you really want to go down that rabbit hole, I was
| simply stating my opinion on another's opinion, and I can't
| understand having an opinion that another person can't
| understand another's opinion.
| bmn__ wrote:
| > you should instantly realize what they represent
|
| Often doesn't work in practice. I cannot instantly
| distinguish
|
| * || from ligated ||
|
| * ... from ligated ...
|
| * *** from ligated ***
|
| * ?? from ligated ??
|
| * - from ligated ->
|
| * ~ from ligated <~
|
| * - from ligated ->>
|
| * = from ligated =>
|
| * = from ligated <=>
|
| * ~ from ligated <~~
|
| * [?] from ligated \/
|
| * [?] from ligated ::
|
| * [?] from ligated :=
|
| * [?] from ligated !=
|
| * <= from ligated <=
|
| * [?] from ligated <<
|
| * [?] from ligated |-
|
| * [?] from ligated <>
|
| * [?] from ligated <<<
|
| * < from ligated <|
|
| * == from ligated ==
|
| * x from ligated x with hex digits following
|
| & al., but I have to examine the characters in kcharselect, a
| REPL or similar.
| karlerss wrote:
| With monospaced fonts, as used in programming, the
| ligatures take up 2 or more "spaces", but the special
| characters only take up one space. Thus, they are quite
| easily distinguished, for me.
| prophesi wrote:
| Linters will also complain if you find rare unicode
| symbols in your codebase as well.
| eyelidlessness wrote:
| I tried to like ligature coding fonts. I really _wanted_ to
| like them. Ligatures are a really cool feature of prose fonts,
| and often even make text more readable. And they _looked cool_
| when I first encountered them in code. But every font I've
| tried with these ligatures added cognitive load in practice.
| And now I find the same when I see them in code examples.
|
| Maybe there's a way to do them "right", where they have the
| same positive impact on code readability. But I haven't found a
| font yet which pulls that off.
|
| I'm not a font designer, so this is just using my imagination,
| but I suspect they'd work better if they still left some space
| in the monospace grid rather than fully spanning multiple
| characters. Eg => looks like an arrow but with a very fine gap
| (1px at any size? maybe 1 device pixel on high DPI at smaller
| sizes?) between the characters.
| dimitrisnl wrote:
| Author here, I agree. I use ligatures mostly because I write JS
| and it's not that annoying. Now that I wrote something about
| PHP it's a bit problematic.
| farleykr wrote:
| I wholeheartedly agree. I don't think I will ever understand
| why people want to mess with legibility in a craft that is so
| heavily dependent on using correct characters in correct
| places.
| steve76 wrote:
| lbj wrote:
| Also a good read in the same vein:
| https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
| unfocussed_mike wrote:
| This is a) ten years old, b) fairly out of date, and c) much
| more passive-aggressive and opinionated than people sharing it
| seem to think it is.
|
| I mean, in the "stances", just as an example -- "a language
| _must_ be concise "?
|
| Really? It _must_? I think this is inappropriately assertive.
| IMO the better JS I have seen has avoided some of the more
| unnecessary conciseness. And that is before we discuss the
| worst example of "conciseness" thinking in a generation: JSX.
|
| PHP and its community is, if you want a different opinion, more
| mature, more pragmatic and entirely less screwed up than
| Node.js, which is, to borrow the terminology, a fractal of
| _indiscipline_.
|
| PHP's developers and its wider community have gone about fixing
| problems while NPM just seems to create new ones.
|
| _(The author of that post is in fact a Python fan, which makes
| it even more chucklesome when looked at over a ten-year
| timescale. One of the two languages managed to bring developers
| along for that whole decade with a campaign of carefully
| planned major improvements and deprecations, without causing
| major schisms, and it wasn 't Python.)_
| throw_m239339 wrote:
| > This is a) ten years old, b) fairly out of date,
|
| No, most of the problems listed still exist in the language.
| PHP Core didn't fix these, they just added more features on
| top of them.
|
| Take this part:
|
| https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-
| design/#...
|
| Can you tell me which assertions aren't true as of 2022?
| conradfr wrote:
| Most of the things in that article that are still true
| don't actually come up on a day to day basis for
| professional coders with a good framework and a decent IDE
| (basically PhpStorm).
| francislavoie wrote:
| > [] can be used on any variable, not just strings and
| arrays. It returns null and issues no warning.
|
| It warns, will likely become an error in a later version
| (these are being slowly increased in error level to give
| people time to migrate): https://3v4l.org/qQdSP
|
| > The [] indexing operator can also be spelled {}.
|
| Not anymore: https://3v4l.org/jtjCj
|
| > Unlike (literally!) every other language with a similar
| operator, ?: is left associative. So this:
|
| Not anymore: https://3v4l.org/t8io2
|
| Regarding string/number comparisons:
|
| https://wiki.php.net/rfc/string_to_number_comparison
| zach_garwood wrote:
| This dead horse again?
| nobleach wrote:
| While I enjoyed that article many years ago, and even
| identified with those sentiments. I've kept an eye on PHP over
| the years. It's not that same language. Certainly PHP, like all
| languages are not perfect. But I gotta hand it to the team. The
| evolution has been awesome.
| [deleted]
| muglug wrote:
| It's not really in the same vein, since the OP is referring to
| modern PHP and your article was written over a decade ago.
|
| Many of the points in the decade-old article still stand, but
| the ecosystem around PHP has papered over a _lot_ of the cracks
| in a variety of ways.
| unfocussed_mike wrote:
| It's not _just_ papering over cracks, though. (There 's a bit
| of that, but they do try to avoid it)
|
| It's a slow, deliberative process to properly fix the most
| widely deployed server-side web programming language. It's
| not going to be easy, and it is being done by fairly wise
| heads.
| naoqj wrote:
| The author of that piece is much less clever than he think he
| is.
| skilled wrote:
| Can anyone recommend books/courses that actually cover "modern"
| PHP?
| phil_dev wrote:
| "PHP and MySQL" by Jon Duckett (Wiley, 2022) is a great
| introduction to server-side web development. If you are
| familiar with his previous books then you'll be glad to hear
| that he employs the same highly-visual yet comprehensive
| approach.
| francislavoie wrote:
| "Front Line PHP: Building modern applications with PHP 8" is a
| pretty good book. https://front-line-php.com/
| conradfr wrote:
| I would suggest to go to
| https://symfony.com/doc/current/index.html and follow the "Get
| Started".
|
| Or reading their free book https://symfony.com/book
| poopypoopington wrote:
| Isn't modern PHP just Hack?
| krapp wrote:
| I wish. As far as I'm concerned, Hack was a better language and
| I wish it had taken off. But no. For one thing, HHVM supports
| XHP by default, but PHP doesn't, so you still need a separate
| framework with a DSL to safely handle HTML in PHP. Hack also
| had async/await, type checking and generics.
|
| Also PHP's Composer no longer supports Hack. Hack was supposed
| to get its own package manager but AFAIK that never
| materialized.
| svnpenn wrote:
| I stopped using PHP. The language itself is fine, but PHP doesn't
| include a package manager. People will shout "but composer!",
| That is not PHP. That is a third party tool. What Rust
| understands, what Go understands, what Ruby understands, is how
| important the package manager is to the language.
|
| No one is an island, and "batteries included" only gets you so
| far. In my mind, PHP is in line with C, with the mindset of
| "figure it out yourself" in regards to packaging. That's not
| acceptable.
| lillesvin wrote:
| Is Ruby Gems a first party thing now? I remember, back in the
| day, being tangentially involved with creating a Ruby package
| manager before Gems had become the de facto standard.
| n42 wrote:
| what a strange hill to choose to die on. what would be
| different if composer came bundled with the PHP runtime?
| svnpenn wrote:
| I wouldn't have to install it...
| yaseer wrote:
| This sounds like an objection based on a personal
| principle.
|
| I think if you tried explaining your design choices like
| that in a technical interview, or to a teammate, they may
| not be persuaded.
| [deleted]
| voidfunc wrote:
| How is it any different than Python (pip) and Java (maven,
| gradle)?
| svnpenn wrote:
| > Java (maven, gradle)?
|
| Its not, I dont use Java either, same reason.
|
| > Python (pip)
|
| Python comes with Pip, at least the one I use anyway:
|
| https://nuget.org/packages/python
| voidfunc wrote:
| You are logically inconsistent then with regards to Python.
| Your distro might bundle it out of convenience but its not
| a first party component.
| svnpenn wrote:
| OK, does PHP do that?
| ByteJockey wrote:
| Does PHP control nuget packages? No. No they do not.
| Neither does Python (the python package you linked to is
| managed by a Microsoft employee).
| mmcnl wrote:
| Seems petty to me. Who cares if it's not first party? It's
| widely used and is the defacto standard package manager. Is
| that not enough?
| mekster wrote:
| What a small reason to decide on what language to use. There
| are far bigger reasons to choose a language but it's your
| choice.
| gmfawcett wrote:
| Nitpick, but Go the language doesn't have package management.
| The 'go' tool -- an implementation detail of the most popular
| implementation -- has features for fetching packages, etc., but
| the language spec does not require these features or constrain
| how they work.
| francislavoie wrote:
| Everyone has standardized on Composer. It's a better package
| manager than NPM, doesn't have many of the security problems
| that plague NPM.
|
| The PHP internals maintainers don't have the time to maintain a
| tool like Composer alongside the rest of the language. And if
| it was bundled with PHP, it would be stuck in lock-step with
| PHP version releases, which means improvement can only be made
| once a year, basically. That's not acceptable. Composer
| wouldn't be what it is if it had to release so slowly.
| svnpenn wrote:
| I dont care. Plenty of other languages manage it, so for
| those who dont, its just excuses.
| civilized wrote:
| It seems like you have an unexamined presumption that
| bundling a package manager with a language is a superior
| practice, and you "don't care" about any argument that
| might challenge that.
| jonwinstanley wrote:
| The PHP community gets on fine with Composer, no need to
| bundle it in the language IMO
| skissane wrote:
| > And if it was bundled with PHP, it would be stuck in lock-
| step with PHP version releases, which means improvement can
| only be made once a year, basically. That's not acceptable.
| Composer wouldn't be what it is if it had to release so
| slowly.
|
| CPAN is bundled with Perl, but CPAN can update itself to a
| newer version (try `cpan CPAN`). Similarly, NPM is bundled
| with node.js, but NPM can upgrade itself to a newer version
| (on Linux/Unix/macOS by running `npm install -g npm@latest`;
| unfortunately doesn't work on Windows for whatever reason.)
| Why couldn't Composer use the same model? Composer supports
| updating itself (when installed as a PHAR) via "composer
| self-update". So bundle the PHAR with PHP, and then when you
| run it, can check for a newer version and print a warning if
| there is a newer version available, and in response to that
| warning you can run "composer self-update".
| mhitza wrote:
| I think Pear was the equivalent of Python's pip way back.
| Haven't really looked back since composer dropped.
| briandilley wrote:
| and it kicked and screamed the entire time
| YATA0 wrote:
| Using PHP in 2022+ should be considered a crime of negligence.
| unfocussed_mike wrote:
| Why, specifically? I mean, it has problems, sure, but all
| languages do.
|
| What should those negligent people use instead, particularly?
|
| What's your suggestion for an alternative system that is as
| deployable?
| temp8964 wrote:
| Because I never intentionally follow the updates of programming
| languages I use, I find from time to time that I am not using the
| new features. However, I find JetBrains IDEs can be very helpful
| in this regard. Its warning messages educate me to use new
| language features I am not aware of or I have never tried.
| cletus wrote:
| There are a lot of great things here but PHP just needs to
| embrace static typing (IMHO).
|
| Take match expressions plus enums. Incredibly useful. You know
| what's even more useful? When it's a type error to leave out one
| of the values. This means when you add a new value you'll get a
| bunch of errors you need to fix. Technically you can get around
| this with a default case but I consider that an anti-pattern in
| most such cases.
|
| The Hack type system, particularly the ability to express
| nullability, is just vastly superior.
|
| Named parameters are an interesting one. The Hack equivalent is
| to use shapes [1]. This is slightly verbose but you can express
| what shape fields are required and optional. Javascript manages
| without named parameters using anonymous objects, which is
| basically the same thing.
|
| I didn't know PHP lambda expressions can't be multi-line. That
| seems weird. Again, Hack is simply better here allowing both this
| syntax and anonymous functions, all of which can be multi-line.
|
| I also find the Hack collection types (vec, keyset, dict) to be
| superior to PHP's array with more obvious semantics and less
| weird type coercion. PHP's default of maintaining insertion order
| is amazingly useful and I'm honestly surprised more languages
| don't copy this. Of course you have things like LInkedHashMap in
| Java but doing this out-of-the-box I tend to find more natural.
|
| Anyway, I think the hate on PHP is a trope at this point, largely
| outdated and just boring. Modern PHP is actually quite pleasant
| to develop in (IMHO).
|
| [1]: https://docs.hhvm.com/hack/built-in-types/shape
| mekster wrote:
| > Javascript manages without named parameters using anonymous
| objects, which is basically the same thing.
|
| It's not. Unless you have a strict typing on the function in
| TS, you can't know if you're typing the right member.
|
| This is actually one of the thing in PHP I like more than TS.
|
| It takes no effort to provide meaningful names to parameters
| from the caller.
| throw_m239339 wrote:
| > There are a lot of great things here but PHP just needs to
| embrace static typing (IMHO).
|
| Static typing cannot be retrofited into PHP. Core already has
| hard time with generics. PHP Types will always be just type
| guards with dynamically typed variables.
| muglug wrote:
| > The Hack type system, particularly the ability to express
| nullability, is just vastly superior.
|
| I agree the type system is superior, given the language was
| created to _have_ a type system in the first place (PHP was
| not).
|
| But PHP has allowed nullable types in syntax since PHP 7.1.
|
| > Named parameters are an interesting one. The Hack equivalent
| is to use shapes
|
| Hack shapes are not Hack's answer to named parameters. Instead
| they're a way to specify dict contents on a more granular
| level. A comparable array shape type, expressed in docblock
| form, is now supported by all major PHP static analysis
| software.
|
| > Take match expressions plus enums. Incredibly useful. You
| know what's even more useful? When it's a type error to leave
| out one of the values.
|
| Most PHP static analysis tools give you this information.
|
| > I also find the Hack collection types (vec, keyset, dict) to
| be superior to PHP's array with more obvious semantics and less
| weird type coercion.
|
| Absolutely agree with this, but for now (and maybe in
| perpetuity) we'll have to settle for the swiss-army-knife array
| type.
| yurishimo wrote:
| I don't think we need static typing as a requirement. For folks
| who want to opt in, it's probably fine.
|
| The divide could be catastrophic and for me, would be a major
| turn off. Look at JS and TS. Some projects go all in, but then
| others half ass it with `any` return types all over the place.
| If the JS ecosystem can come together around TS, it's probably
| still a decade out until it becomes the default used
| everywhere. That gap creates confusion and chaos.
|
| If people want similar languages with more/less features, they
| can create those communities. Erlang and Elixir are good
| examples.
| cletus wrote:
| I don't think there's an alternative to optional static type
| checking at this point. Like you say, there's a bunch of
| untyped code out there.
|
| I'd actually hate to see a JS/TS divide in PHP. The typing
| needs to really be a superset of existing PHP and backwards
| compatible. Such a typechecker should cover at least the
| following:
|
| 1. Point it to a codebase and spit out a bunch of
| errors/warnings; and
|
| 2. Run it at runtime where type checks are logged or a strict
| mode where they're fatal.
| krick wrote:
| All these features have been discussed countless times in "new
| release" threads and such, but I don't think I ever asked public
| opinion on the "spaceship" operator, so I want to raise the
| question this time. I always ignored it as a feature that I
| personally don't need, but somebody else does, so ok, whatever.
|
| You see, I actually don't think I ever used usort in about 10
| years (or how long is it since anonymous functions were
| introduced). Instead, in all of my projects there is an
| implementation of https://underscorejs.org/#sortBy
|
| The difference is that the callback maps the value to something
| that is already sortable using other native PHP functions, like
| an integer or a string. I find it way more intuitive than writing
| these function($a, $b) {/* try to remember which of [-1,0,1] it
| is supposed to return */} abominations. So as a solutions to
| remembering "which of [-1,0,1] should it be" I'd expect just
| natively implementing in C _sane_ sortBy function to replace this
| pre-historic PHP bullshit. But whatever, it 's a matter of
| taste...
|
| ...Or so I thought until now. Now that I think about it, I see
| [-1,0,1] callback as something really fucked up. PHP usort (and
| basically all PL ordering functions I know) can order only linear
| sequences, i.e. it returns an ordered list. Not even a lattice.
| Basically this means real numbers (or, more comfortable to use in
| a PL: strings). And with [-1,0,1] I can define whatever the fuck
| I want. There's nothing to stop me from implementing
| "paper/scissors/rock" (or even something much more convoluted) in
| it, and I have no idea how usort will behave then. That doesn't
| sound good.
|
| So I'd like somebody to persuade me that I personally need
| [-1,0,1] comparison model for some use case I apparently never
| encountered. The only reason I can think of why [-1,0,1] might be
| better is performance (or RAM, actually), but I don't accept it
| as a valid argument: somehow even my non-optimal sortBy PHP
| implementation always turns out to be enough, and if I really
| should worry about sorting performance, PHP probably isn't the
| right language for my use-case anyway.
| afiori wrote:
| Technically they are equivalent, meaning that theoretically you
| can implement one with the other. The main advantage of sorting
| with [-1,0,1] is if you are sorting by multiple parameters
|
| Convoluted example: sort some cars by year then by weight
| except with all Toyota first
|
| In general it is easy to simulate multiple SQL `order by`
| clauses with [-1,0,1].
|
| Using primitives you can map each car to something like
| "0t-1994y-0300kg" (remembering to left pad numbers) and sort by
| that.
|
| In practice they are equivalent (when used correctly) but it is
| easier to implement primitive sorting with [-1,0,1] than
| viceversa.
|
| Sometimes I wish languages would have native equality and order
| operators on (immutable) arrays, so that
| [1,1]<[1,2]<[2,0]<[2,0,-1] would work...
| krick wrote:
| They are not "technically equivalent", as I've shown above.
| You can implemnt papre/scissors/rock with [-1,0,1], which is
| not linear ordering function.
|
| And you didn't show anything for which ordering cannot be
| defined by mapping objects (with any number of parameters) to
| strings, which is kind of the whole purpose of sortBy anyway.
| lastangryman wrote:
| Used PHP for many years for high volume web applications. My
| biggest gripe is you (at least had to) run php behind another
| server (nginx, Apache) which meant your "scope" is always
| restricted to serving the current request.
|
| If you want to do something like share some heavily read data
| across processes you need to then introduce memcahe/redis in to
| your stack, whereas in something like Go this can be done in your
| application code. This also means PHP is a nightmare for
| connection management to others resources like your database - if
| you autoscale your API you are in a very vulnerable place for
| maxing out connections on your database as every client request
| needs to create it's own. You can solve this with something like
| Envoy I think, but again it's adding more complexity to your
| stack, more tools to configure and deploy.
|
| This was my main issue with PHP. I found the language itself fine
| to be honest. Not the most elegant but hardly as bad as people
| make out.
| rvr_ wrote:
| Next time you need to take a look at PHP, those two problems
| can be solved by php-apcu for caching and proxysql running
| side-by-side with php-fpm on each server.
| lastangryman wrote:
| Nice, thanks for the heads up on these.
| mhitza wrote:
| With apcu you're going to pay the cost of
| serializing/deserializing the data.
|
| If you dump your read heavy data into a PHP file on disk,
| that just has a return of your generated data, you can be
| benefit from having that bytecode compiled data stored in
| opcache for free (for the entire lifetime of the php-fpm
| service, or until you reach the maximum opcache
| allocateable memory).
|
| I think that PHP gives you a few nice utilities to handle
| sharing, but they are problem specific. For example you
| might also spawn threads within a background PHP task, and
| there is shared memory functionality you can use in that
| case as well which is going to be faster than apcu or
| opcache.
| datalopers wrote:
| check out the swoole extension. async server and faster
| throughput than any other php setup.
|
| [1] https://openswoole.com/
| lastangryman wrote:
| This looks really interesting and seems like it would offer a
| similar programming model to node/go/etc. Will check it out,
| thanks.
| megous wrote:
| Latency just connecting to PostgreSQL (in my case) sucks
| anyway, so I end up having a connection pooler between PHP and
| the database in production just for the latency's sake, even if
| I don't care about scaling.
|
| And that solves both issues at once.
| makeitdouble wrote:
| A small addition from 7.3 that was long awaited, indentation
| preserving heredoc/nowdoc:
| https://www.php.net/manual/en/language.types.string.php#lang...
| kingdomcome50 wrote:
| I've probably written some version of this comment over dozen
| times throughout the years when discussion about PHP rears its
| head (note that I'm fond of PHP):
|
| PHP as a _language_ is... okay. It 's been modernized to include
| many of the faculties a developer would expect of a language in
| 2022. But honestly, I'm ready for the "improvements" to the
| language to stop. The closer you get to C# or Java the more
| obvious it is that PHP will _never catch up_! It 's not that it
| has to catch up, rather, that few people actually choose PHP
| _because_ the language is so great. If you were choosing a your
| stack based on "which language offers us the most features or
| highest ability to express our problem" you wouldn't be choosing
| PHP!
|
| Here's the secret: PHP is probably the best language for server
| side webdev because of the _runtime_! It 's so dead simple to
| develop and deploy PHP. I mean the language itself is basically a
| web framework right? How many other languages _automatically_
| parse an HTTP request and hand it to you by default? Or offer
| _built-in_ templating semantics for composing HTML? Or have
| request routing by default? I don 't know of another one. _That
| 's_ why I, and many others, choose PHP!
|
| You know what I'd like to see? The trajectory of PHP's
| development change to _lean in_ to the above -- to focus
| development on improving the reasons why it is chosen in the
| first place! I don 't need a C# with slightly different syntax
| (or named parameters). I'd like:
|
| - Improved templating semantics
|
| - A better module system
|
| - A way to bake routing into each file (overwriting the default
| semantics)
|
| - Adding a built-in service-locator pattern/DI
|
| - A way to make PHP scripts more testable
|
| What I'm saying is just make it a _better framework_ by default.
| I know I know... "Laravel this, Symfony that, have you heard of
| Slim?". Yes... I get it. There are community-made solutions to
| the above problems. And you know what? They won't be as
| performant or integrated as if the runtime itself was upgraded to
| make them obsolete. It's not like routing and DI are that
| complicated (the two most obvious reasons frameworks are
| employed).
|
| I _like_ that I can write a simple API in PHP without pulling in
| a single dependency! It makes so many things easier (the right
| things too). Now let 's just extend that to all of the basic
| facets a modern web framework offers!
| kiwidrew wrote:
| I used to look down on PHP, but after being forced to use it
| for a while I begrudgingly came to admire it for all the
| reasons that you've pointed out. And I started using PHP by
| choice, generally for writing small scripts (no frameworks or
| libraries) that I could "deploy" simply by copying the .php
| file into /var/www. It's a very productive language when used
| as intended.
|
| PHP scripts on shared webhosting was the original "serverless"
| and you didn't have to be too careful about object lifetimes
| and leaking database connections because as soon as the request
| was finished the entire process was nuked from orbit.
|
| But "modern PHP" is the complete antithesis of everything that
| I grew to admire about PHP because it's just another Java or C#
| with awful syntax and weird equality rules and gigantic
| frameworks with thousands of classes and interfaces.
|
| I would very much like to see a version of PHP that dropped all
| the nasty namespace and object-oriented misfeatures and just
| focused on cleaning up the language semantics and enhancing the
| built-in framework features...
| lekevicius wrote:
| Does any other language require to use a special notation,
| similar to PHP's "$", any time a variable is referenced? I can
| only think of CSS, using "--".
| toastal wrote:
| This is called a "sigil"
| todotask wrote:
| It's more than what most of us know, Rosetta Code is a good way
| to find. https://rosettacode.org/wiki/Variables
| icedchai wrote:
| Basic uses them at the end for string variables... A$...
| jansommer wrote:
| jsoniq uses the same notation https://www.jsoniq.org/
| dylan604 wrote:
| jquery, lodash, etc all added prefixes (or TIL: sigil) of
| somesort
| nobleach wrote:
| jQuery's $ and lodash's _ are not prepended to a symbol to
| denote a variable. Both are objects actually. In the case of
| jQuery, $ === jQuery (the root jQuery object). The case that
| the parent is talking about is PHP's requirement that all
| variables are denoted as such `$variable_name`. (Perl and
| Bash also do this)
| dylan604 wrote:
| i forget that's what's actually being done under the hood.
| graftak wrote:
| That's just (part of) the variable name and not really the
| same.
| throw_m239339 wrote:
| > jquery, lodash, etc all added prefixes (or TIL: sigil) of
| somesort
|
| This is false they are not sigils at all. _ and $ are legal
| variable names in Javascript.
| tyingq wrote:
| These all use sigils on variables in one way or another: Unix
| Shells, AWK, Perl, Ruby, Tcl, Basic, PowerShell, DOS batch
| scripts
| markkrj wrote:
| -AWK
| tyingq wrote:
| Ah, yeah, I suppose it's more of a "field operator" for
| things like $1, $2, etc.
| draw_down wrote:
| Eric_WVGG wrote:
| Back in the eighties, my father taught me that the "$"
| character in BASIC meant "string," so when I later picked up
| PHP in '98 I mentally thought of $someVar as "string-someVar"
| (regardless of the actual type, which was of course no problem
| for PHP), kept that habit for well over a decade... I think it
| was partially my self-disgust over such silly and technically
| incorrect thinking that led me to bail for Node as soon that
| was a feasible alternative.
|
| The dollar sign does kinda look like a loose piece of
| shoestring, though
| agumonkey wrote:
| I can't remember all details but in Lisp in small pieces,
| author describes variable handling with a table { creation,
| reference/access, modification, [deletion] }
|
| with each category had it's own optional syntax, many language
| will avoid this through context in which the symbol is, thus (+
| a 1) equates (+ (deref a) 1), but he meant that it was a choice
| and not an obligation and some systems used $ or other
| syntactic constructs.
| krapp wrote:
| PHP got that from Perl AFAIK. Bash does it too, and TCL.
| ZeroGravitas wrote:
| Ruby also has $ for global variables, which I assume it also
| got via Perl. And @ for instance variables, and @@ for class
| variables.
| chubot wrote:
| I'm pretty sure that historically shell is the common
| influence of PHP, Perl, and Tcl.
|
| PHP also inherits shell's here doc syntax, e.g. <<EOF . Not
| sure if Perl has that.
|
| Actually PHP started out as a bunch of cgi-bin scripts, if I
| recall. It was very much "a shell for the web".
|
| It kind of annoys me that they all require $ on the left,
| whereas shell only requires it on the right, which somehow
| makes more sense to me, e.g. a=$b # shell
| $a = $b # PHP and I think Perl
| pweezy wrote:
| > It kind of annoys me that they all require $ on the left,
| whereas shell only requires it on the right
|
| Interesting - it makes it look like Bash uses $ to "read"
| from the variable, while in PHP/Perl $ only indicates that
| the rest of the symbol _is_ a variable.
| tyingq wrote:
| >>PHP also inherits shell's here doc syntax, e.g. <<EOF .
| Not sure if Perl has that.
|
| It does.
|
| >>It kind of annoys me that they all require $ on the left
|
| Larry Wall says he went that direction to make namespace
| clashing between $dog, @dog, %dog, and "sub dog {}"
| (scalar, array, hashtable, function) a non-issue.
|
| http://www.wall.org/~larry/natural.html ("Disambiguation")
| [deleted]
| ainar-g wrote:
| krapp has already mentioned the Unix stuff. BASIC had a thing
| with a $ at the end of a string variable, iirc. Windows'
| CMD.EXE used %VAR% notation (and later !VAR! notation).
| yurishimo wrote:
| PHP is probably the best language for server side webdev today.
| Still insanely easy to deploy, lots of features at the language
| level, and the frameworks that are available are very
| sophisticated. Whether you like Laravel or not, it's influence is
| spreading to other frameworks within PHP and other languages.
| Also, Laravel has some of the best docs in OSS, period.
|
| I think WordPress is pushing other projects forward as well. The
| tech stack over there doesn't move nearly as fast, but the UX is
| still pretty good out of the box and with the enterprise clients
| I work with on a daily basis, they all still love WP.
|
| Back to PHP proper for a minute, the language is fast. There are
| efforts being made to run PHP on Serverless infrastructure or
| with continuous process environments. New features are added to
| the language on a regular basis as evidenced by this post and
| others. The defacto package manager, Composer, is also world
| class.
|
| It's a good time to be a PHP dev!
|
| As a final point, I'll throw out some of my worries. I've been
| writing PHP since 2010~ as a high schooler fooling around.
|
| The "Java-fication" of PHP is real. There is a push for more
| types and type related features. These aren't bad in isolation,
| but as they move deeper into the core of the language, there is a
| risk of breaking legacy apps. Historically, backwards
| compatibility has been excellent and allows older apps to upgrade
| PHP versions and take advantage of performance improvements
| without a rewrite. I'm not advocating keeping 100% compatibility
| forever, but recent versions have played more fast and loose with
| breaking changes. We've done a decent job of carrying the entire
| community onto new versions and that will be important for
| continued adoption.
|
| Take a look at the open RFCs for more details. I think there is
| value for pulling good ideas from other languages, but we don't
| need every idea from every language.
|
| Here's to another 20 years of PHP!
| dgb23 wrote:
| > Historically, backwards compatibility has been excellent and
| allows older apps to upgrade PHP versions and take advantage of
| performance improvements without a rewrite.
|
| This has not been my experience at all. Updating PHP versions
| _and_ some even fundamental libraries has been very painful and
| anxiety inducing, you had to be very careful and patient. It's
| similar to JS in that regard and in some cases worse.
| sdoering wrote:
| Just anecdata. My SO is currently working for a very small
| regional dairy producer (think 18 people total). Naturally
| they have a website no one really knows how to handle. My SO
| needed to update stuff, received the login info and the first
| thing we saw was WordPress stating that php5.6 is too old and
| should be updated.
|
| After some arguing with the company that is payed to manage
| their IT environment she got them to finally update the php
| version and now the server is running 8.1.
|
| I was glad that at least wp was up to date. Current wp
| running on quite old php version and exactly nothing broke
| with the update.
|
| I was positively surprised. Would have expected more problems
| from my experience with other projects in other languages.
| mjrpes wrote:
| Are you tracking warnings/deprecations in logs? Usually PHP
| gives ample warning time (at least one major version) before
| producing errors.
| ceejayoz wrote:
| A good test suite does wonders, too.
| dgb23 wrote:
| The tests are there to give us confidence about _our_
| code. They can help in those situations, but they don't
| protect us from others pulling the rug from under us.
| pc86 wrote:
| Unless you're upgrading production before lower
| environments, you'll still find out exactly what you need
| to fix, won't you? And unless you're waiting until the
| last possible moment to upgrade core infrastructure I
| don't see how anyone is getting any rug pulled out from
| anywhere.
| dgb23 wrote:
| I tracked the warnings and I keep up with changes out of
| necessity. But that's the least they can do - anything else
| would be insanity. However it does not make me feel any
| better when debugging version/compatibility/configuration
| issues between the language, different libraries and the
| environment.
|
| I'm not saying there aren't good reasons for _some_ of the
| changes, including historical error prone baggage. I'm also
| not in any way try to disrespect the maintainers. But to
| say PHP is a stable language and ecosystem still does not
| reflect my experience with it.
| unfocussed_mike wrote:
| > The defacto package manager, Composer, is also world class.
|
| Composer suddenly got good, didn't it! Composer 1.x was one of
| my pain points I think.
|
| I can't think of many things that really bug me much anymore.
|
| Null coalescing operators and named parameters are the kinds of
| things that make me happy.
|
| I also adore Laravel (and particularly Lighthouse).
|
| But what I really like about PHP is the humility and maturity
| of the whole endeavour. It's really typified by Rasmus Lerdorf
| who openly critiques his own abilities and seeks out smart
| people.
| esistgut wrote:
| Lighthouse is an hidden gem. I moved some projects from
| Node/Typescript to Laravel/Lighthouse after discovering it.
| cies wrote:
| > PHP is probably the best language for server side webdev
| today.
|
| What are your credentials with non-PHP, non-JS/TS languages?
| Have you written some Rust, Kotlin, Swift,
| ReasonML/ReScript/OCaml, Haskell, Elm or Clojure? Those
| languages are different to some extend, they take fresh
| approaches, they contain new ideas and are _scrape throat_ well
| designed.
|
| I find most cheering for PHP and JS have very little exposure
| to other camps of software development.
|
| > PHP is probably the best language for server side webdev
| today.
|
| I'm telling you (opinion ahead), it most likely is not. And
| most likely will never be. It simply has too many fundamental
| design errors that have long known solutions, are near
| impossible to fix in PHP/JS and are fixed-by-design in other
| languages that also have good tooling for web-dev.
|
| This is not just PHP/JS. But since we are looking at "the best
| lang for webdev" I limit myself the these and this use case.
| mmcnl wrote:
| Why do you treat PHP and JS as similar languages? They're
| worlds apart, have different purposes and have almost nothing
| in common.
| cies wrote:
| > Why do you treat PHP and JS as similar languages? They're
| worlds apart, have different purposes and have almost
| nothing in common.
|
| Because (1) both very often used in webdev, (2) both have
| many "adherents" that totally love the language yet have
| little exposure to languages of different paradigms, (3)
| are (opinion alert) not very well designed.
|
| I'm aware of the differences between JS and PHP.
| ipaddr wrote:
| I have and to suggest replacing php/js with haskell as the
| best server side tool in general is signs that someone may be
| living in a bubble.
|
| I understand you have invested time in other languages, we
| all have but lets focus on facts not fears of your choice of
| language seeming less popular.
| peter422 wrote:
| What does a modern high performance php serving stack look
| like?
| supz_k wrote:
| We handle 50-60 million monthly page views (comments embed
| requests) in our commenting system using PHP/Laravel, NGINX
| (2 load balanced servers), Redis (for queues and caching),
| and MYSQL.
|
| All performance issues we have ever encountered were always
| related to the database - never had an issue with PHP or
| Laravel.
|
| However, we use Node.js for websockets. Though there are some
| improvements in PHP for event-driven development (like
| ReactPHP [1]), it was quite hard to find proper documentation
| and help to build a production-ready WebSocket server. So, we
| ended up using Node.js for that.
|
| The new features added to PHP in the latest versions are
| great. Type hinting and return types are really helpful in
| writing better code. I hope there will be an addition to type
| hint advanced data structures (ex: Arrays of Objects) in a
| future version.
|
| [1] https://reactphp.org/
| donatj wrote:
| We handle a couple million daily users, educational online
| reading product used by K12 schools worldwide.
|
| Internal framework PHP monolith, nginx, Aurora MySQL, redis,
| Memcache, internally developed message queue, handful of
| small Go microservices.
|
| While we're largely hosted on AWS, some countries require us
| not to be, namely China, where are product lives on servers
| run by the government. We've kept are infrastructure non-AWS
| compatible.
|
| For our US installation, monolith scales up to 50+ servers
| during the day and down to a minimum of 2 at night.
| jjeaff wrote:
| Just curious, have you calculated what it would cost to
| have the equivalent of those 50 servers as dedicated bare
| metal servers?
| charrondev wrote:
| At $WORK we serve billions of requests a month on with
| nginx, php-fpm, and Percona.
|
| In total I think it's something on the order of ~1000
| application servers (nginx/PHP) that are specced to handle
| 28 concurrents, and 200 Percona instances of varying sizes.
| A big HAProxy cluster sits in front of the whole thing and
| cloud flare in front of that.
|
| A whole bunch of memcached servers spread around too. By
| far the biggest bottleneck is the MySQL servers at the
| moment, so we rely heavily on memcached to keep requests
| away from the DBs.
| hu3 wrote:
| Not OP but I have seen web apps with 1 million MAU (Monthly
| Active Users) using:
|
| - Laravel
|
| - Redis
|
| - PostgreSQL
|
| - Nginx+ php_fpm
| unfocussed_mike wrote:
| I am deploying considerably smaller applications but I've
| had good results lately with Caddy and PHP-FPM [0]. I tend
| to use MySQL 8 but I've made use of both Redis and
| Memcached where appropriate.
|
| I don't even use any of the JIT stuff, but I will soon.
|
| _[0] Once I figured out how to configure Caddy, that is.
| (Laravel vs Caddy documentation ease of use is night-and-
| day territory.)_
| francislavoie wrote:
| FWIW, a Caddy config for a Laravel app is just the
| following (which you can find here in the docs
| https://caddyserver.com/docs/caddyfile/patterns#php):
| example.com { root * /srv/public
| encode gzip php_fastcgi localhost:9000
| file_server }
|
| Do you have any specific comments regarding Caddy's docs?
| What exactly did you find difficult? I'm a Caddy
| maintainer, and I'm always looking to find ways we can
| improve.
| unfocussed_mike wrote:
| _(Thank you for your reply! I 'm using some of that
| pattern. It wasn't enough for my requirements,
| unfortunately. What I have now works fine; I use the
| handle directive a fair bit and that makes sense to me.
| This is not a problem now)_
|
| The main problem with Caddy's documentation is that it is
| a maze of twisty tunnels! Lots of terse fragments of
| documentation that bounce you on to other terse fragments
| of documentation. It feels fractured and impermanent. I
| lose my place.
|
| Part of the problem is inherent to very flexible packages
| like this, and it is going to be difficult to solve.
|
| I think you possibly overestimate how many people have
| time to learn about the JSON syntax or API configuration,
| how many people want Caddy outside of a package manager
| installation, etc.
|
| It almost seems to me that you need entire documentation
| guides -- "Caddy for Nginx users", "Caddy for Apache
| users", "Caddy for people who need an API-driven server"
| -- that have much more narrative flow to them.
|
| (IMO, configuration file adapters are a hiding to
| nothing. Just explain to me why Caddy is better and help
| me make the switch)
|
| I _love_ Caddy for what it is now doing for me -- please
| don 't get me wrong, I think it's an impressive project
| -- but after 28 years of configuring web servers I really
| need migration documentation that I can read in detail
| without clicking from link to link and lots of emoji
| people.
|
| Small observation: the mid-blue text on a pale blue
| background for your code examples and monospaced text is
| difficult to read if your eyes are over 40 years old and
| it's been a long day.
| francislavoie wrote:
| Thanks! I appreciate that feedback.
|
| I do want to work on improving the "Tutorials" section to
| make it apply to more installation methods (i.e. running
| in Docker requires additional setup to use the admin API,
| running as a service means you may need to turn off the
| service before playing with the tutorial, etc)
|
| "Caddy for X users" pages are complicated to get right
| IMO, and I'm not sure it's worth the effort - those are
| also general purpose servers, and can be used an infinite
| amount of different ways. Comparing them is difficult and
| I'd argue that it's not that useful. Take for example
| https://statamic.com/vs/wordpress to get a sense of what
| I mean.
|
| > I think you possibly overestimate how many people have
| time to learn about the JSON syntax or API configuration
|
| I definitely don't; I spend a lot of my time improving
| and polishing the Caddyfile adapter since it's definitely
| the easiest way to use Caddy. The tutorials do put too
| strong a focus on JSON in my opinion (Matt wrote them).
| But on the other hand I think it's pretty important to
| understand that the Caddyfile _is_ an adapter to JSON and
| not the native config language. It's key to knowing how
| to debug and inspect how Caddy actually runs.
|
| > how many people want Caddy outside of a package manager
| installation
|
| I'm not sure I understand this point though, what are you
| trying to say here? You can definitely just download the
| caddy binary and run it wherever, you don't need to use a
| package manager. I'm not sure what this is trying to
| point to.
| unfocussed_mike wrote:
| > The tutorials do put too strong a focus on JSON in my
| opinion (Matt wrote them).
|
| I don't mean to start a fight between friends! :-)
|
| > But on the other hand I think it's pretty important to
| understand that the Caddyfile _is_ an adapter to JSON and
| not the native config language. It's key to knowing how
| to debug and inspect how Caddy actually runs.
|
| Agreed.
|
| > I'm not sure I understand this point though, what are
| you trying to say here? You can definitely just download
| the caddy binary and run it wherever, you don't need to
| use a package manager. I'm not sure what this is trying
| to point to.
|
| Sorry, I mangled that with a run-on sentence, didn't I!
| What I mean is, I think more users are likely to want the
| package manager, systemd-configuration deal. The
| automatic-HTTPS thing is such a strong sell that I think
| a lot of people will seek to replace nginx just for that.
|
| I could totally be wrong here but this is where I think a
| sort of narrative document for Nginx users at least is
| perhaps worth it.
|
| Some of this is always going to be a challenge because
| Caddy is a fascinating, category-straddling project;
| you've made a product that is somewhere between a magical
| automatic appliance, a Golang web dev framework and a
| traditional configurable server, that avoids the
| downsides of all of those things as far as is really
| possible.
|
| Documenting that is definitely a unique challenge.
|
| I'm prattling on now but thank you again for Caddy; it
| really is a great contribution.
| francislavoie wrote:
| > I don't mean to start a fight between friends! :-)
|
| Nah it's fine ^_^ we both know we have a difference of
| opinion there, and we balance eachother out on that.
|
| > Sorry, I mangled that with a run-on sentence, didn't I!
|
| Hah, maybe a bit! Thanks for clarifying, that helps.
| We'll definitely take those comments into consideration
| when we work on updates to the docs!
|
| Thanks for the kind words <3
| mholt wrote:
| This is valuable feedback, thank you. A lot of people
| just say that the docs suck and we can't do anything
| about that. This is more helpful. I'll see what we can do
| to improve cohesiveness and clarity/accessibility.
| unfocussed_mike wrote:
| Thanks -- I'm glad it didn't come across too whiny,
| because to be honest you've saved me from so much HTTPS
| pain so far I really will put up with a _lot_! :-)
| [deleted]
| tmpz22 wrote:
| There is so much variety in web development that to crown any
| language as "the best" is at best unproductive.
|
| This attitude of "what is the best" promotes cargo culting and
| should stop.
| unfocussed_mike wrote:
| > This attitude of "what is the best" promotes cargo culting
| and should stop.
|
| The terse certainty in your response is ironic, is it not?
|
| Considering the parent post frames that as opinion with the
| word "probably" and then makes a case for the opinion.
| pc86 wrote:
| The truth is whatever one's personal list of "must haves"
| and "should haves" are for a given language, there are
| probably at least 2 or 3 major languages that fit the bill
| in a given domain, and probably more if you're willing to
| use stuff like Haskell or Racket or Clojure (all fine
| languages but compare their popularity to JS or PHP to
| Python).
|
| For every person who is vehemently in favor of one language
| over all others, it's _usually_ pretty easy to point out
| another language that will get you 99% of what that other
| language will. So it 's not a very tenable position to
| think one language is the be all end all.
|
| But on the flip side, and in part because of the points
| above, "language cargo culting is stupid and should be
| avoided in almost every instance" can make a great deal of
| sense.
| sieabahlpark wrote:
| chockchocschoir wrote:
| > There are efforts being made to run PHP on Serverless
| infrastructure
|
| This is very interesting, I didn't know this. This is a perfect
| fit for PHP, as it was always designed with this model in mind,
| and the programmers that use PHP are already used to this way
| of developing, as that's exactly how php-fpm and mod_php
| already work and always have.
| francislavoie wrote:
| For example: https://bref.sh/
| throw_m239339 wrote:
| > This is very interesting, I didn't know this. This is a
| perfect fit for PHP, as it was always designed with this
| model in mind, and the programmers that use PHP are already
| used to this way of developing, as that's exactly how php-fpm
| and mod_php already work and always have.
|
| Yes, but now you have to pay for every requests made to your
| app instead of just paying $4 a month for a shared Apache
| server and I also have to architecture my PHP app in a rigid
| way to fit whatever "serverless" execution model the SAAS
| runs with.
| francislavoie wrote:
| Which may be much cheaper than $4/month if you have very
| low traffic numbers.
| ipaddr wrote:
| A fixed cost of $4 dollars that can host hundreds of
| websites or a variable pricing model where any traffic
| level would end up costing you more with no ceiling.
|
| Choosing serverless would be a bad game theory strategy
| choice.
| throw_m239339 wrote:
| > Which may be much cheaper than $4/month if you have
| very low traffic numbers.
|
| A big IF. My $4/month stay $4/month without the added
| complexity of "serverless" deployment nor every stupid
| constraints this business model imposes. If serverless
| actually didn't make money, this business model wouldn't
| exist or wouldn't be pushed, mainly by Amazon employees
| here.
| jjeaff wrote:
| It's php, so your architecture by nature is already
| serverless unless you are using some newer plugin like
| swoole.
|
| For most projects, that $4 server is great and what I
| would prefer. But where serverless can excel is an
| application that has very spikey usage.
|
| If your $4 server gets hit with spikes of usage that
| would require a $500 server for an hour once or twice a
| month, you might be better off with serverless, rather
| than paying $500/month to have a server that big all the
| time.
| [deleted]
| dehrmann wrote:
| Something I pick on with PHP is because requests are _so_
| isolated, it doesn 't have a good story for pooling SQL and
| HTTP connections. Its model really limits you when it comes to
| sharing resources between requests.
| francislavoie wrote:
| It's possible to have persistent MySQL connections, but
| there's all kinds of caveats; MySQL connections are stateful,
| so bad things can happen, and the performance benefits are
| only very slight.
| https://www.php.net/manual/en/features.persistent-
| connection...
| hermanradtke wrote:
| I spent a decade writing PHP. I think the language is fine, but
| the lack of a real concurrency model (event loop or threads)
| pushed me to other languages for web dev.
| gremlinsinc wrote:
| Swoole a php extension has solved this mostly, and has
| coroutines like golang.
| teddyh wrote:
| See also: https://phptherightway.com/
| jimmaswell wrote:
| The match statement is nice, but in JS it's easy enough to just
| index a map.
|
| {'abc': 2, 'def': 3}[x] ?? 'default';
| francislavoie wrote:
| You can do the same in PHP, but again, not as nice to read:
|
| ['abc' => 2, 'def' => 3][$x] ?? 'default';
| unfocussed_mike wrote:
| Easy to write. Less easy to read.
| fermentation wrote:
| Plus you have to actually allocate and evaluate the whole map
| right? Like if the values are FromASlowComputation() you'd
| have to do something else.
| idoubtit wrote:
| The example in the article is poorly chosen, because an
| associative array (map) would be more suitable. What you wrote
| is almost the same with PHP: ['abc' => 2,
| 'def' => 3][$x] ?? 'default';
|
| PHP's `match` is a kind of functional `switch`. For instance,
| in the following example, an associative array would induce
| several useless function calls, and `match` is more readable
| than a sequence of if+returns: return match
| ($key) { "id", "ID" => unique_id(),
| "UUID" => generate_uuid(), default =>
| findExternalId($key), };
| mekster wrote:
| With PHP 8.1 I can easily map database JSON column as an array in
| a model class by setting the property type as array and the
| database abstraction runs json_decode on array typed properties
| when fetching and json_encode when saving. Quite handy.
| dvh wrote:
| Which linter supports these?
| francislavoie wrote:
| psalm, phpstan, and phpstorm all support all these features as
| a static analysis level.
| nolok wrote:
| Look at phpstan
| jasonjei wrote:
| The only thing stopping me from using PHP is just I've been
| burned in the past by massive breaking changes going up in major
| and even minor versions. Granted they are major releases, but the
| amount of work to bring existing code up to "code" is a
| gargantuan amount of work. I've dealt with similar issues in Ruby
| as well as Rails, but it wasn't too hard to fix and even older
| syntax is happily accepted without deprecation messages. With
| PHP, I've had to cleanup very verbose code (often from older
| open-source packages or software) and spent hours and hours
| cleaning up breaking changes.
| NorwegianDude wrote:
| Not sure how long ago you used PHP, but backwards compatability
| has in my opinion been excellent for at least 15 years. A ~500k
| LOC PHP project has basically been effortless to keep up to
| date with the latest versions. From what I can remember I've
| only done search and replace a couple of times in that period.
| ec109685 wrote:
| The backwards compatibility story has been much better lately
| in php, including across major versions. There were some bad
| practices with previous versions that had to be cleaned up,
| unfortunately.
| ransom1538 wrote:
| Compared to phython2 vs phython3? What are you comparing it to?
| I can run php4 apps just fine. Good luck managing a phython2
| app.
| megous wrote:
| Well, code I wrote in 2006 still runs in production today, with
| very minor changes. I can't really be happier about backwards
| compatibility story. :)
|
| I guess I started writing PHP when PHP 5 was already a thing,
| didn't depend on any third party code, and used PDO from the
| start, so... I guess I was lucky to pick the right
| abstractions.
| Minor49er wrote:
| This sounds like an issue with your upgrade process and not so
| much with PHP itself
| mwcampbell wrote:
| How widely is modern PHP deployed on the super-cheap shared
| hosts? Being able to write robust web applications that can be
| deployed on any cheap shared host in the world seems like a
| superpower.
| francislavoie wrote:
| Very widely, for things like WordPress.
|
| But shared hosting is a security nightmare. VPSes are super
| cheap nowadays, it's way better to go with that if you're
| trying to start/run a business.
| Tijdreiziger wrote:
| Some hosts do per-customer containerization now.
|
| For tech businesses, I agree wrt VPSes; but for businesses
| that run a couple of WordPress sites and where tech isn't a
| core competency, you can't beat traditional shared hosting
| from an ease-of-administration perspective.
| jeroenhd wrote:
| I've never seen an affordable shared host that _didn't_ offer
| at least PHP support. They may be a version or two behind (the
| cheaper they get, the further behind) and they may have some
| functionality disabled for security (system(),
| file_get_contents HTTP calls, etc.) but for about half a dollar
| a month you can get a reasonably competent web host with enough
| storage to run a blog for years.
|
| That said, if you care about performance, be wary of shared
| hosts. Some frameworks, like Symfony, need quite a bit of CPU
| and IO to build a up a cache to get acceptable execution
| speeds. Nothing too dramatic, but shortly after setting up a
| website it may be slow on shared hosts with strict CPU and
| memory limits.
___________________________________________________________________
(page generated 2022-03-27 23:01 UTC)