[HN Gopher] My PHP Problems
___________________________________________________________________
My PHP Problems
Author : gempir
Score : 59 points
Date : 2024-02-19 10:22 UTC (12 hours ago)
(HTM) web link (www.dantleech.com)
(TXT) w3m dump (www.dantleech.com)
| hiAndrewQuinn wrote:
| I finally had a chance to write some PHP that (a) wasn't
| WordPress and (b) actually did something useful a few weeks ago
| at $DAYJOB.
|
| Going from zero to functional web backend in less than 3 hours
| for a language I'm almost totally unfamiliar with made me
| understand just why this got so gosh darn popular. I thought
| building out a Flask application was fast, but PHP's initial
| experimentation loop is just on another level, criticisms be what
| they may.
| kingofthehill98 wrote:
| It's such a perfect match for the HTTP protocol. You drop a
| file on a server and you're good to go. My toy VPS is full of
| useful scripts that I use on a daily basis. Most of them are
| literally one big file with all of the code, no external
| dependencies. Caddy proxy the request into PHP-FPM and send
| back the response, no bullshit.
|
| Of course this is not what we see at production-grade software,
| but I really enjoy the fact that the language was designed with
| the HTTP protocol in mind. It's really unique in this sense.
| tsukurimashou wrote:
| yes, and the fact that you can just put inline HTML outside
| of PHP tags is so useful and convenient
| zer00eyz wrote:
| LOL
|
| The fact that I can't tell if this comment is sarcasm or
| snark or serious says a lot.
|
| PHP mixed with HTML was one of the "bad ideas" that hurt
| PHP. It was a bad practice that got out of hand.
|
| Now why no one bats an eye at node/react doing this very
| thing and calling it JSX is beyond me but...
| mschuster91 wrote:
| > PHP mixed with HTML was one of the "bad ideas" that
| hurt PHP. It was a bad practice that got out of hand.
|
| So what, JSPs are just the same. In the end what matters
| is the speed to Get Things Done, and there's utterly
| _nothing_ competing with PHP, closely followed by
| Tomcat+JSP as you can use the insane amount of interfaces
| with just about everything that the Java world has.
| bemusedthrow75 wrote:
| > Now why no one bats an eye at node/react doing this
| very thing and calling it JSX is beyond me but...
|
| In _deed_.
| FriedrichN wrote:
| Why is it a "bad idea"? I'm genuinely curious.
|
| It works great, it's fast and you don't have to learn a
| new templating language or dialect every 2-3 years. Or
| try to figure out how to do trivial things like loops in
| loops.
|
| I don't quite get the use of templating engines in PHP
| because PHP _is_ a templating engine itself.
| zer00eyz wrote:
| A few reasons:
|
| 1. It's a loaded foot gun. PHP was notorious for 1000
| line files with HTML and SQL all mixed together. (I speak
| from personal experiences on this)
|
| 2. Templating languages are "portable" (In theory). Have
| a mixed env of PHP and Java... there were templating
| languages that would work for both teams, it took a step
| out of scalability.... XML and XSLT were the promise land
| on this one, but we fucked all that up. Portability is a
| big deal. We're still slinging CSV files for a good
| reason.
| FriedrichN wrote:
| 1. I've seen enough terrible things in my time, but you
| can make a mess in any language using any number of
| frameworks. And it's been a hot minute since I've seen
| one of those 1000+ line PHP+SQL+HTML+JS+CSS monstrosities
| in any serious environment.
|
| Improper use of templating engines or trying to use
| templating engines that aren't up to the task can give
| you headaches just as well. Sadly no amount of frameworks
| or templating engines can stop a bad programmer from
| writing bad code, in the end we're craftsmen who need to
| learn how to use our tools.
|
| 2. This could be a valid use case, but a rather rare one.
| XML+XSLT is something that sounds fantastic on paper, but
| as anyone who actually worked with it knows it ranges
| from a big disappointment to an absolute nightmare.
| rezonant wrote:
| > Sadly no amount of frameworks or templating engines can
| stop a bad programmer from writing bad code,
|
| It's not a matter of whether the code is bad or not, but
| _how bad_.
|
| The entire point of frameworks is to add guard rails to
| help you stay disciplined and avoid cutting corners on
| separation of concerns.
|
| Using PHP as a template language tempts developers to
| violate SOC every day.
| FriedrichN wrote:
| If you need guard rails to keep you from performing
| database manipulations in your views you have other
| problems to worry about. And if anything people are
| cutting corners on SOC in the M and C part of MVC, not
| the V part.
|
| Also I don't see how using a loop or conditional in PHP
| is any different from using one in a templating engine,
| aside from the overhead of the engine and added annoyance
| of debugging another language in your project.
| rezonant wrote:
| > If you need guard rails to keep you from performing
| database manipulations in your views you have other
| problems to worry about.
|
| Those problems are called "junior developers", and I
| think we'd all like to avoid them, but that's not very
| sustainable.
|
| Perhaps we can fix the education problem, but given that
| folks just do a boot camp and head into the market,
| prospects aren't looking good.
|
| > Also I don't see how using a loop or conditional in PHP
| is any different from using one in a templating engine,
| aside from the overhead of the engine and added annoyance
| of debugging another language in your project.
|
| The problem is convention, or lack thereof. Without
| convention, who's to say where that database call should
| live? Frameworks, which tend to use templating languages
| for this reason, tend to make that convention clear to
| all teammates.
|
| I want to mention that this doesn't mean you can't use
| PHP as the programming language for your templates as
| long as the conventions are clear, but PHP is poorly
| suited to being a template language for reasons I've
| posted elsewhere in this thread.
| zer00eyz wrote:
| >>> If you need guard rails to keep you from performing
| database manipulations in your views you have other
| problems to worry about.
|
| Its a one off... Its just an internal tool... This is a
| prototype... It's a hot fix...
|
| I know better, I have done it. It is only with dumb luck
| that they didn't end up as products. Some people dont
| know that they should not or that it isnt a place they
| should try to "get away" with it. These things grow and
| then turn into products and someone has to clean them up.
|
| Source: I made a lot of money turning PHP "projects" into
| "software".
|
| > Also I don't see how using a loop or conditional in PHP
| is any different from using one in a templating engine
|
| One of these things is Turing complete. The other is not.
|
| Templating languages have their own laments: see yaml
| configs used to create "workflows", "environments" and
| "servers" via templating.
| rezonant wrote:
| Templating systems produce output based on a template and
| a set of data. PHP produces output based on imperative
| code that can do anything. While you can certainly adhere
| to your templates only consuming data (ie some kind of
| view model), it's actually awkward to do, as PHP files
| don't take parameters, so you need to use a convention of
| having your "template" files provide functions and call
| them, but functions are global so you now need to name
| them uniquely to avoid collisions. If templates are meant
| to be pluggable, this is much more difficult because you
| have two templates that are supposed to be
| interchangeable, with identifiers for calling them that
| are different[1]. There are a lot of properties of
| template systems that PHP does not actually have.
|
| [1] It's so much worse than this... You can use some
| horrible hacks like undefining a well-known function that
| each template implements, but this would only work one
| level deep without also adding a mechanism for "calling"
| a template, and at that point you are making a template
| system on top of PHP.
| flir wrote:
| > as PHP files don't take parameters
|
| $_SERVER, $_POST, $_GET.
|
| The rest is not the PHP3 I recognize to be honest, let
| alone the modern stuff. Remember include() literally just
| included the code right there, inline, so you could
| include in functions and gain the function's scope:
| function render($data) { switch
| ($data['foo']) { case 'bar':
| include('bar.inc'); break; case 'baz':
| include('baz.inc'); break; } }
|
| That's your template router with all the template's data
| pre-loaded in the template's scope, be it ever so filthy.
| rezonant wrote:
| All of those variables are global, there's no way to
| establish an interface between the caller and the callee
| without using functions. You could certainly have a
| shared understanding of what variables have been injected
| into a global, but this is awkward, and requires you to
| do cleanup after each template instantiation to avoid
| leaking values between templates, which can cause subtle
| bugs.
|
| > Remember include() literally just included the code
| right there, inline, so you could include in functions
| and gain the function's scope:
|
| I've talked about this approach elsewhere in thread, it
| is not nestable without building a way to "call"
| templates on top of require/include, and when you do that
| you'll need to undefined the render function to do it as
| well, which creates additional complexity. At that point,
| the original premise of just using raw PHP isn't very
| true, because you are now building a framework or
| templating system around it.
|
| Also, you have to contend with the magic "render"
| function not being globally defined by something. It's
| messy.
| flir wrote:
| > there's no way to establish an interface between the
| caller and the callee without using functions
|
| Um. Can you give me an example to pad that out a bit?
|
| > and requires you to do cleanup after each template
| instantiation to avoid leaking values between templates
|
| In my render() example, isn't that "reaching the end of
| the function"? (Edit: Wait, you're only talking about the
| superglobals, right?)
| rezonant wrote:
| > Um. Can you give me an example to pad that out a bit?
|
| Your example of using a render() function is already an
| example of this. You can parameterize render() to provide
| data to the template from the caller without utilizing
| untyped globals, and without having to clean the globals
| up after the template has rendered.
|
| > Wait, you're only talking about the superglobals,
| right?
|
| Yes. Globals are globals. PHP's super global distinction
| isn't really relevant to whether you are tainting the
| execution environment when you pass data to a script.
|
| The point is, as I elaborate elsewhere, PHP is very
| awkward to use as a proper templating system.
| JodieBenitez wrote:
| > I don't quite get the use of templating engines in PHP
| because PHP is a templating engine itself.
|
| Do you write _safe_ templates in PHP ?
| pintxo wrote:
| It did make total sense at the time. Consider we are
| talking a time where you had static html.
|
| It is obviously good to be able to automate generating
| web pages based on say the state of a database. As this
| gives you up-to-date pages without someone having to
| manually build them.
|
| And if that - automatically build web-pages from a
| database - is your goal and your current state of the art
| is static pages, then creating a language you can
| interject into your static pages, to build the page
| dynamically is a no brainer.
| rezonant wrote:
| In defense of the PHP community, things like Symfony
| attempt to create some sanity when it comes to separation
| of concerns. Unfortunately, when people talk about PHP
| they inevitably talk about raw, framework less PHP and
| act like it's as sensible as something structured and
| disciplined like Ruby on Rails or ASP.NET MVC.
| rezonant wrote:
| > Now why no one bats an eye at node/react doing this
| very thing and calling it JSX is beyond me but...
|
| Hey don't drag Node into this, you aren't forced to do
| any of that.
|
| React to me feels like SPA developers discovering the
| idea of PHP and thinking they invented it. This shouldn't
| be surprising, since React came from Facebook, and
| Facebook historically is a PHP shop.
|
| Mixing your business logic and presentation is a bad
| idea, but it's very attractive when you don't have the
| informative scars
|
| You might say, doesn't Facebook have the scars to avoid
| designing React? Well, when you have a hammer, everything
| looks like a nail.
|
| PS: I would suspect the down voting is just the "LOL",
| otherwise it's a fair comment.
| zer00eyz wrote:
| > You might say, doesn't Facebook have the scars to avoid
| designing React? Well, when you have a hammer, everything
| looks like a nail.
|
| This is accurate, and I never thought of it that way.
|
| > PS: I would suspect the down voting is just the "LOL",
| otherwise it's a fair comment.
|
| I did laugh out loud because I did not know WHAT to make
| of the comment. As someone who buttered my bread on PHP
| when everyone hated it, it was a sign of how times have
| changed!
| mrkeen wrote:
| > PHP mixed with HTML was one of the "bad ideas" that
| hurt PHP. It was a bad practice that got out of hand.
|
| PHP receives its share of criticism, and HTML lives on
| relatively unscathed.
|
| So if mixing PHP/HTML is a problem, you'd probably throw
| out the PHP and keep the HTML.
|
| Also, isn't this use case PHP's origin? A dev wanted some
| programmable HTML?
| flir wrote:
| You're getting downvotes, but that genuinely puzzled me
| the first time I saw JSX. ("This looks a lot like
| 'include("form.php")' in old-school PHP. What am I
| missing?")
|
| Turns out I wasn't missing much. I've mentally pegged it
| as an example of "the pendulum swings" - thin client vs
| thick client, centre vs edge, tight coupling vs loose
| coupling, etc.
| rezonant wrote:
| Discerning developers avoid PHP for the reasons you
| mention, and yet it powers a frightening percentage of
| the Web.
|
| React is popular for the same reason as PHP. I can only
| hope the industry corrects for this soon, because I
| challenge you to find a startup building raw PHP in 2024,
| yet nearly all of them build with React.
| Shish2k wrote:
| > react doing this very thing and calling it JSX
|
| In PHP, "HTML" is string concatenation; in React, "HTML"
| is an HTML-flavoured bit of syntax sugar over HTML-
| generating functions (and you are still welcome to call
| the functions yourself, if you want your HTML-generation
| code to avoid looking like HTML). Aside from looking
| kind-of similar if you squint, I'd say the differences
| and pros and cons are fairly significant (For example the
| IMO _worst_ thing about the PHP approach, the ease of
| shooting yourself in the foot with XSS holes, is a non-
| issue in JSX).
| withinboredom wrote:
| I built the Swytch Framework to exactly hit these spots.
| As far as I know, it's the only templating system out
| there with contextual escaping (you write html, it parses
| the html using a streaming parser, escapes output, then
| writes it out).
|
| I use it exactly for rapid dev of stupid ideas. I'm not
| sure if I'd use it in a production environment because it
| is quite slow.
| foul wrote:
| > PHP mixed with HTML was one of the "bad ideas" that
| hurt PHP. It was a bad practice that got out of hand.
|
| If you think of PHP as prototype-only, mixing tags and
| HTML is very convenient, like it is with the other
| thousand templating tools. And obviously it's more a
| problem of XSS through badly sanitized inputs more than
| the mix in itself, blah blah blah
|
| It's PHP in production a bad practice that got out of
| hand.
| crabmusket wrote:
| > Now why no one bats an eye at node/react doing this
| very thing and calling it JSX is beyond me but...
|
| Because it's not "this very thing". HTML around PHP is
| output directly to stdout. JSX is just syntax for
| literals.
| jdpedrie wrote:
| On the other hand, vanilla PHP effectively "hides" HTTP from
| the programmer. I taught myself PHP in middle school and high
| school as my first programming experience, and had no concept
| of a thing called "HTTP" for a very very long time. I knew
| the pieces of it that PHP gave me. I knew what $_POST, $_GET,
| $_SERVER, $_HEADER, set/getcookie(), were and how to
| manipulate them, and I knew the rules (setting a header after
| "echo" made it complain), but I didn't understand how that
| all hung together as a thing outside PHP called HTTP.
|
| When I did learn about HTTP, it was very easy, since I
| already knew it without knowing I knew it, so maybe that's in
| favor of your point, but there's much to be said for the
| actual understanding that I didn't have at first. When I
| started interviewing people for PHP entry-level jobs, asking
| about HTTP was one of the ways I gauged how well applicants
| understood their work at a conceptual level.
| dijit wrote:
| I upvoted you and vouched u/rizky05 because I think they raised
| an important point.
|
| > It is powerful indeed. But PHP syntax feels unelegant and
| making me write unnecessary ceremony. It feels different when I
| write typescript code, every character I type fits like lego.
|
| > Especially when my codebase grows so much. Navigating PHP
| project is like thrown in forest without a map, you can always
| look up the sun to find your way.
|
| "Elegance" is something that gives people warm fuzzies, I think
| this is why there are so many Rust advocates (I am one), when
| pieces fit together nice or can be refactored cleanly and tests
| are first-party it is _nice_.
|
| However there have always been "hacky" and "proper" languages,
| because doing something hacky that works _also_ feels great.
|
| Python is a hacky language, it's easy to go to 0-100 very
| quickly. C++ however requires time and precision to make things
| proper, so people avoid it and few things are made
| comparatively in C++ unless it's infrastructure software that
| people spent a lot of time writing.
|
| Maintainability be damned, sometimes you really just need to
| throw something together.
|
| The curse of things that work is that they will be expanded
| upon and kept around for too long.
|
| Unfortunately: PHP _works_ , and is an _excellent_ hack-
| language for the web. Which means there's a lot of code that
| becomes "production grade" that should really have never been
| intended to live forever in the first place.
| smarkov wrote:
| > when pieces fit together nice or can be refactored cleanly
|
| This is a trade-off that makes sense to embrace in some
| contexts, and I do believe that web is one of them. The more
| nicely your pieces fit together the harder it'll be to break
| them apart. You can only refactor cleanly once you are aware
| of all the requirements, but those requirements are usually
| constantly changing in the context of web and so your pieces
| fitting together a little too nicely means that you now have
| to refactor a lot more code.
| thinkindie wrote:
| PHP can be super hacky and super structured, within the same
| file, and it's your choice. You can have tests, static
| analysis, etc etc, or not. Or you can start without and then
| adding it as the project mature, without having to
| necessarily switch to another language.
|
| I'm working on my own startup that started as a side project
| and it was super hacky at the beginning, but by sticking to
| PHP (and thanks to PHP continuous improvements) I was able to
| refactor little by little and make the codebase way more
| structured and easier to maintain.
| Shish2k wrote:
| As a vaguely-related anecdote, I wrote a super-hacky PHP
| script in highschool 20 years ago, it gained some
| popularity based on being open-source and easy-to-install
| (PHP's #1 strength for sure) - and to this day I am still
| spending a significant chunk of development time
| refactoring based on ideas that eg Typescript and Rust have
| out of the box (eg using PHPStan to emulate a language with
| typed arrays)
|
| (I keep wishing that I could rewrite it in a "better"
| language, but there is no other language that is even in
| the same ballpark when it comes to "any random user can
| upload this .php file to any random web host and expect it
| to work")
| penteract wrote:
| This matches my experience of PHP. The questions/advice on
| stackoverflow and blog posts are also geared towards people who
| just want to get something done, which helps a lot if that's
| your goal.
|
| Go is the only other programming language I've had this
| experience with - picking it up with a goal in mind and
| succeeding in doing something more quickly than I might have
| with a familiar language.
| hiAndrewQuinn wrote:
| I remember someone on SO saying "Go isn't a programming
| language, it's a DSL for writing networked services", and,
| well, if we can squint and call Go that, we can definitely
| call PHP a DSL for dynamic webpages.
| ChrisMarshallNY wrote:
| I've been writing PHP for a quarter century, but I've never
| become a "whiz" at it.
|
| But I regularly write fast, robust, secure backends, in a day
| or less (less, if possible. I don't actually _like_ working in
| PHP).
|
| Despite the torrents of hate from this community, it is still
| pretty much the backend king.
|
| Here's the "Fishtank Graph."[0] It kind of puts things in
| perspective.
|
| [0]
| https://w3techs.com/technologies/history_overview/programmin...
| kingofthehill98 wrote:
| Loved this article, those were all great points that I have faced
| on my daily job at a PHP shop.
|
| A breath of fresh air in amids of thousands of "ew, such a bad
| language" and "a fractal of bad design", the latter being
| incredibly outdated and still referenced from time to time.
|
| I love PHP, it was my first language and it's one hell of a
| productive ecosystem to be in. Laravel is an excellent choice for
| rapid prototyping and Symfony is probably one of the best web
| frameworks for enterprise projects. Paired with coroutines
| extensions such as Swoole/OpenSwoole/Swow it puts one hell of a
| fight performance wise with more modern languages.
| begueradj wrote:
| I agree. Also Laravel is one of the best web frameworks for
| rapid prototyping :)
| bemusedthrow75 wrote:
| Indeed.
|
| Also, I have been looking for GraphQL implementations for
| other server-side languages recently and I have yet to
| encounter a schema-first implementation that comes close to
| what the Lighthouse layer for Laravel can do.
|
| That is really productive.
| withinboredom wrote:
| Why would you want to use graphql? In my experience, it's
| pretty terrible for real-world use-cases.
| bemusedthrow75 wrote:
| Lighthouse is sophisticated and productive. I only use it
| in fully-authenticated contexts but because it is schema-
| first with good ORM bindings and excellent annotation
| support, I barely write any logic that isn't a mutation,
| an accessor or a permissions gate. The occasional top-
| level query resolver. Beyond that it is the graphql
| schema and the models.
|
| And it gives me the opportunity to separate out the front
| end concerns in a way I could explain to someone else.
|
| Apollo has been a bit of a pickle on the front-end, mind
| you. That's a decision I'd revisit.
|
| But generally it has meant a flexible API interface and
| leads to nice low latency UIs.
|
| Check it out:
|
| https://lighthouse-php.com
|
| And these really good third-party auth mutations for
| Passport:
|
| https://lighthouse-php-auth.com
| withinboredom wrote:
| Ah cool! I hadn't seen this before!
|
| I'd only seen fairly raw GraphQL from like 4-5 years ago,
| when you had to write your own auth, resolvers, deal with
| n+1 queries, etc. This is actually really nice and solves
| a lot of the issues I was thinking of.
| bemusedthrow75 wrote:
| Right. People keep telling me that code-first is better
| but there is no way all those complex APIs are easier to
| use than just spitting out some JSON from an endpoint.
|
| Schema-first feels more manageable.
|
| I'm not going to say I haven't had to do that a _bit_
| here, when I've got into quite advanced things.
|
| (e.g. sometimes you might want to dynamically provide the
| values from an enum, or write your own decorators, or you
| might want a custom top-level resolver.)
|
| It's built on the WebOnyx reference implementation, so
| there's some help out there.
|
| But it's amazing how much code I _haven 't_ had to write,
| and being the sort of person I am with difficulties
| controlling focus, I absolutely _love_ the schema-first
| approach. It interacts well with Eloquent scopes, with
| the ordinary API gate system, with policies and
| validations.
|
| It's actually weird how good it is. You still have all
| the same issues you have with GraphQL generally (like
| limiting graph traversals to things a user is authorized
| to see), but you have so many tools.
| withinboredom wrote:
| Another nice thing about schema-first is that clients can
| start interacting with a mock server from day-0, and both
| sides can build out the implementation independently
| according to the spec. It really speeds things up on
| larger projects (IMHO).
|
| Working on FrankenPHP, we get a lot of issues from the
| Laravel people (mostly in regards to octane + worker
| mode), and I've been getting into more and more Laravel
| to support these folks and understand what is going on in
| the SAPI. I've really started to understand the
| attraction lately. Previously, I worked at Automattic for
| quite a while and learned the WordPress side of PHP, then
| worked with Symfony in a corporate setting, so I've yet
| to get into Laravel in the commercial world, but I'm
| thinking I probably will for my next job.
| bemusedthrow75 wrote:
| Also: I have removed the little bit of snark in my reply
| above -- it shouldn't have been there and I apologise.
| Rough brain-day making me jumpy but there's no excuse!
| withinboredom wrote:
| Dude. We've all been there, no offense taken. I probably
| could have taken a few seconds to explain my experience
| instead of just assuming everyone else has had the same
| experience.
| viraptor wrote:
| Huh? This article is talking about very similar issue to the
| fractal of bad design. Down to repeating specific ones like
| json_decode(null). Most of the fractal post still applies. The
| themes of surprises and consistency are strong in both.
|
| I agree that the language evolved since then, but the main
| categories are still not solved in the language. Nice
| frameworks just hide those well.
| bemusedthrow75 wrote:
| The thing that I think PHP developers hate most about the
| Fractal of Bad Design article is hearing it from full-stack
| JS developers. They really do not have the moral high ground.
|
| PHP has improved since in a way that is rarely considered
| when reposting it, but JS has some deep language horrors of
| its own still, and many novel JS horrors like NPM have
| emerged largely since the Fractal article was published.
|
| As the King sang, so eloquently: o/~ clean up your own
| backyard o/~
| crabmusket wrote:
| As someone who writes PHP and JS professionally every day,
| I think they're leagues apart.* Sure, people love to look
| down on JS, but its fundamentals are much stronger than
| PHP's.
|
| PHP is no longer a _terrible_ language- recent editions
| have made leaps and bounds on language features, and the
| ecosystem around Symfony is great. But on a weekly or
| monthly basis I run into something that makes me want to
| head-desk.
|
| JS's recent(ish) language improvements like `let` and ESM
| have been much more fundamentally significant than PHP's
| IMO, where we're still stuck with bad scoping and Java-
| brained class autoloading.
|
| *Not leagues apart in terms of productivity. I can
| certainly get a lot done with PHP. I mean leagues apart at
| their foundation, the basic concepts at work in the
| language. Most of that can be ignored until it rears up to
| harass you. Here's a great example of something similar to
| an issue that bit me last month:
|
| https://stackoverflow.com/q/3307409
| kingofthehill98 wrote:
| Honestly I don't see it that way.
|
| The blog author makes solid points that I agree. Meanwhile
| AFOBD just make fun of stdlib inconsistencies and of language
| quirks, most of which were fixed throughout the years.
|
| AFOBD is so incredibly outdated that this paragraph is still
| there: "PHP is naturally tied to Apache. Running it
| separately, or with any other webserver, requires just as
| much mucking around (possibly more) as deploying any other
| language.".
| zanellato19 wrote:
| Some of the points are outdated, but the soul of the
| article, that those stdlib inconsistencies and language
| quirks as you called it, lead to terrible design and a lot
| of surprising footguns, is still quite true. Laravel is a
| good framework and it is because it hides a lot of PHP from
| the user.
| otabdeveloper4 wrote:
| Nitpicking on trivialities is pointless.
|
| Rather, point out the fact that Symfony is a framework that
| relies entirely on all sorts of magic behavior, and at the
| same time it is _entirely undocumented_.
|
| One of the most horrible programming experiences I've ever
| experienced.
|
| PHP is a nice language, but the community is insane.
| kingofthehill98 wrote:
| Just out of curiosity, when was the last time you worked
| with Symfony?
|
| The framework has changed massively after the earliest
| versions (1~3). These days it's very similar to Java's
| SpringBoot. After scaffolding all you get is a thin layer
| with the HTTP abstraction, configuration support,
| reflection-based Dependency Injection and a testing
| framework (PHPUnit).
|
| Since the framework is component-based you pull
| dependencies as you need them. I find the documentation
| really good and honestly I don't see much magic in it, it's
| an event-based web framework. Laravel and it's facades on
| the other hand is very magical.
| withinboredom wrote:
| Symfony is not great, but most people utterly misuse it
| so you end up with spaghetti and ground mud. That being
| said, Symfony is the most popular framework I know of
| that liberally uses goto statements.
| conradfr wrote:
| It is actually documented, surely you must be confused?
|
| You have the docs with extensive examples, you have a free
| book, and the whole framework is typed and all
| configuration options and the individual components
| referenced: https://symfony.com/doc/current/index.html
|
| And if you use PhpStorm with the Symfony plugin almost
| everything gets intellisense.
| otabdeveloper4 wrote:
| I don't use PhpStorm.
|
| Also, random code snippets that may or may not work is
| not documentation, much less is it a reference.
| conradfr wrote:
| I don't get it, what more from the docs do you need?
| yurishimo wrote:
| In php 8.3, there is a new json_validate function! Stuff
| changes, it just takes a bit of time. Luckily, the core
| maintainers have been putting out steady releases every year
| and old versions are being deprecated on a rolling 3 year
| cycle. It doesn't solve the historical problem, but hopefully
| it enforces better habits for the ecosystem moving forward.
| esquire_900 wrote:
| This is a bit too much of an apples vs oranges. Use cases for PHP
| (easy to develop, maintain websites) are different from those for
| Go and Rust.
|
| Obviously, PHP came from a place of great inconsistency, and the
| remains are still there, including the popularity to rant on it.
| PHP is getting significantly better though, and while a long one,
| I hugely prefer this route over something more abrupt like python
| 2-3. The first 3 or so points are valid, but annoyances at best.
| For the points about closures, statements, inline classes etc.,
| they are just features from other languages that aren't in PHP.
| amne wrote:
| I can't for async/await to reach PHP and see code that awaits 5
| queries and 3 http requests in a row. Perfection.
| fHr wrote:
| I see the advancements in php and I think I could go back by now
| but I know that 90% of comapnies recruit you to fix some
| wordpress 4/php 5 bugy and custom plugin infested site that
| should just be made from scratch but because there is no money
| and "just quickly fix it in 1 workday" gives me php ptsd once
| again.
| hiAndrewQuinn wrote:
| PHP is probably like Excel, in that is is really helpful from a
| raw productivity standpoint to be good at it, but you really
| don't want other people to _know_ that you 're good at it.
| bemusedthrow75 wrote:
| Mmm. It really depends on whether you have the scope to start
| your projects and stay in control.
| mschuster91 wrote:
| IME, that also makes PHP worth it for shell scripts. It's
| miles better than the common baseline that's bash/perl... but
| once word gets out, people will ask you to rewrite their 30
| kLOC sh monstrum into something readable...
| naranha wrote:
| idk, when I want productivity I go with nodejs these days.
| lodash for some quick data crunching and pg or mariadb for db
| access using promises simply beats native php functions. with
| express you can spawn a http server in under 10 lines, while
| with php you need to setup apache/nginx or docker.
|
| at some point in the past PHP was the most productive tool
| for some quick & dirty coding, but not anymore for me.
| withinboredom wrote:
| I recommend checking out FrankenPHP, where you can spin up
| a production php server with a single cli command, or
| compile your php into a self-executable binary.
|
| I'm a contributor over there.
| bemusedthrow75 wrote:
| This is absolutely a problem.
|
| It's now a powerful, fast, flexible platform with a load of
| amazing libraries and tools -- graphql, webhooks, databases,
| all sorts. There's an amazing level of recent PHP support out
| there you can host on.
|
| And then there are the terrible applications, written from
| inadequate specs, in a hurry, by people who just aren't
| developers. And they are embedded, and people want them fixed.
|
| You have to have a knack for, and some enjoyment from, that
| work.
|
| The worst I have encountered is a Wordpress site built by some
| people who did not know Wordpress could do several important
| things, so they'd subverted the loop, ignored where they could
| hook, and embedded wordpress outside the loop to do stuff,
| which was a nightmare.
|
| The second worst was, it must be said, a Laravel app, but that
| problem wasn't the PHP so much (though it had been written in a
| hurry with an awful lot of duplication that we could have
| refactored out), it was the unreliable assumptions made about
| MySQL default result ordering.
|
| Which is actually the secondary problem here: people who make
| bad PHP decisions usually make bad SQL, email and HTTP
| decisions too.
|
| If building your own thing from scratch, or starting a new
| project, etc., PHP is a blast now, actually. But the very old
| things... not so much.
| cardanome wrote:
| Not my experience. You will see some legacy code but that is to
| be expected in any coding job.
|
| Wordpress is kind of it's own ecosystem. I have been a PHP dev
| for years and never touched any Wordpress code.
|
| Most jobs recruit for specific frameworks like symfony or
| laravel.
| zer00eyz wrote:
| PHP buttered my bread for over a decade. I bear it no ill will,
| and this article was a lot of nostalgia.
|
| The "living on a prayer" comment on serialization brought back
| memories. It made me acutely aware that I use this pattern in go,
| and there it "just works". I now have a note to go see what
| Valinor, PHPStan, Psalm, Serde are because they sound godlike.
| timw4mail wrote:
| The first point is kind of silly: You can make rust-style
| constructor functions if you want, and have a private constructor
| to enforce the behavior.
|
| Although it does require some boilerplate, which may seem like
| pointless extra work.
| bandrami wrote:
| I still have contracts in Cold Fusion. PHP is not remotely the
| worst web templating language out there in active use...
| user3939382 wrote:
| I respond to every point below.
|
| In sum, the native functions should take iterators anywhere it
| can take arrays.
|
| Every other valid criticism he makes and many more I can wrap in
| the simple statement that: psalm needs to become the runtime type
| system which is hopefully and appears to be the (maybe distant)
| future.
|
| In the meantime you have 40% and quickly growing of those
| features in your IDE and 100% in your CI so it's not a huge deal.
|
| Main takeaway for people who haven't looked at PHP in 10-15 years
| or since the fractal article and would take the length of this
| post, which they don't understand, to say "yep dumb php again"
| no.
|
| ----------
|
| Constructors Only had this confusion once with my UUID library
| and it took me 3 seconds to remember the formula.
|
| "In attribute land this becomes:" I've never seen any code or
| library that uses attributes like this nor do I understand why
| you would. The only purpose would be static analysis, let's say
| with psalm, and that's just not how you use attributes in psalm.
| He says generics are tricky: in psalm they're trivial. The real
| problem is the best IDEs are still working on getting the
| integration right.
|
| Nested attributes strikes me as an extreme edge case that would
| only come up in some meta-level tooling you're making for the
| language which is the provided example. However in this special
| case presumably this can be accomplished through an extension,
| xdebug for example does this.
|
| Serialization he says is a problem then says, it's a solved
| problem (there are many such accepted ways to solve this) but
| then says it still annoys him so not sure?
|
| "No Variadic Promoted Properties" I'd like to hear the use case
| for. I've done very complex things in PHP and never needed this
| construction. A property can't have a static single type but then
| also consist of a collection of random types, in this case it
| would just be an array. It looks like another feature that is
| solved by psalm.
|
| Iterator to Array: Preserve Keys he says he doesn't know if it's
| wrong.
|
| Iterators vs. Arrays this is easily fixed by using the popular
| Functional library versions of these functions which I agree
| should be the default.
|
| Short closures cannot have statements" I have to convert between
| them so I kind of get it but would say this is an intentional
| choice. You can substitute a method call if you really want this.
|
| "Statement Blocks in General" That would be nice when and if it's
| very simple though having them anywhere could turn the language
| into kind of a mess to read considering what those blocks could
| contain.
|
| Functions that return false - basically everyone agrees on this,
| it's a conversion that's iterated on with each release and will
| just take time. The specific example he provides I have wrapped
| with an exception thrower for just this reason and never use the
| default.
|
| Inline Classes - he says he doesn't know if it's a good idea. I'd
| say no, having a reliable file system convention between
| codebases is a plus not a minus.
| sourcecodeplz wrote:
| Good for PHP that it's getting more and more traction (attention)
| lately. Bad press is still press & PHP is quite not bad nowadays,
| when you start from scratch.
| reactordev wrote:
| "Langauges such as Rust and Go do not have this problem, mainly
| because they don't have the new keyword!"
|
| Oh but they do. You should spend some time with those languages
| so you can do a proper comparison.
|
| Go has had _new_ for a while now.
___________________________________________________________________
(page generated 2024-02-19 23:01 UTC)