Hacker News Reader

Comment by laszlokorte | Hacker News Reader

Php was my first language I learned 15 years ago. On that way I really started to hate it because of all it's quirks. Many of those have been fixed and nowadays I really enjoy it again and it's my goto language for any web project.

It really hits a pragmatic sweetspot. It's really easy to deploy and frameworks like symfony give you all the power like rails but without the magic.

View on HN

I must be very picky, because to this day I still don't like it at all. It sucks less than it used to maybe, but if I compare it to other languages, I still would rather use anything else.

Curious if that's a general aversion to dynamic typing, or specifically PHP.

The problems with PHP aren't really with the concept of dynamic typing as such, but rather with the somewhat curious semantics and really awkward standard library. These are relics from the past that are, unfortunately, very hard to fix without a "Python 3000 moment", and all the problems that brings. Although PHP 8 does fix a bit of it (various comparisons and operators are a bit better now) there's still a lot of it remaining, especially in the standard library IMHO.

That's what I was trying to make sure I understood. There are people that just don't like dynamically typed languages.

PHP offers some type checking (and has for a long time, albeit very limited) which is getting expanded all the time, including in this release.

They're a bit overblown now I feel, and I wouldn't throw out the language and ecosystem just because a comparator got fussy. You probably won't win any "Code is Art" contests, and if you want to do computer science work then why even waste the time hating PHP, it was never for that. PHP is a web application workhorse, and it's really exceedingly good at that task.

It's not just the comparison that's fussy; if that would be it then that would be fine. It's mostly the really messy, inconsistent, and difficult to use standard library that turns me off personally. And this isn't about inconsistent argument order or naming, I can deal with that as well, but stuff like not being able to create temporary files well, or not being able to check for specific errors in fopen(), and a long list of similar things. These are things that make writing simple, correct, and elegant programs very hard, or sometimes even impossible.

Nothing in their comment suggests anything about typing. They might love JavaScript or Python for all we know.

I think you have to do webdev to really enjoy it, I never write PHP unless it's something with laravel.

As usual, it really comes down to personal preference. In the past year, I have managed a few things in Wordpress, wrote my own PHP, Flask and node sites; and after all that I would 100 % choose Flask or node over PHP.

Node has the advantage of same language back and front, "asynchronous" execution and having both dynamic typing and static typing with TypeScript. And huge ecosystem obviously helps as well.

Python also has pretty sizeable community and Django is probably a huge reason why a lot of people choose python over anything else. And the syntax, at least to me, feels much less cumbersome than PHP. But I have not tried PHP 8 at all.

I like flask and express, there are simpler than php franeworks like laravel so I can see why one would prefer using them, but django is weird and I could never get used to it. I always felt like there was too much magic.

Same here, started off with PHP around a decade ago and couldn't wait to move to another server-side language. Nowadays it's much nicer to work with (as long as you avoid the warts) and PHP 8 looks to deliver another slew of welcome upgrades.

Only downside is that there does seem to be quite a lot of (non-trivial) deprecations which is understandable but I wonder how long it'll take for 8 to percolate into production...

Every single deprecation is a wart being removed, none of them are a python 2->3 kind of issue (it worked just fine but now I need to work to move it to the new stuff !), and it's all easily fixable in your code with minimal effort (but decent amount of time ... if you've not bothered to clean up warnings for the past decades).

The cases that are not replacable easily are things that should never have been written ever.

Same here, I started at the same time also with PHP.

But I never found back to PHP after switching to JavaScript in 2011. If something new comes out it usually runs JS.

One nice thing about php compared to Js is that you are not allowed to write async code. (except you use some extensions) So everything is simpler by design.

True.

On the other hand, most systems I worked with were async, so they fit really well into the JS model of programming.

Same as many web languages, PHP's heyday has a reason as many toolkits at that time were far less powerful and complicated for even simple things. Perl+CGI + all the server setup for a simple dynamic page? It's just unimaginable to many today's developer.

I started off with PHP3 and have a very great and hated time with it till v5. PHP for sure is difficult to maintain and very painful to debug, but it's not my reason leaving it. It's because JS began to pick up and started to do many tasks that requires no server rendering. The server sides started to become just API server, which no longer generate html on the fly. It's much scalable and easy to maintain.

Time flies, now I see the release of PHP 8 and I realise I have ditched it for a decade. Do I miss you? No.

> Perl+CGI + all the server setup for a simple dynamic page? It's just unimaginable to many today's developer.

TBH, I'm still not aware of any truly simple/easy way to get a dynamic HTML page.

Recently, I had to make a dumb utility app to render some dynamic data, and I wound up writing a Golang server with the HTML specified as a Go Template. But making it accessible on the publc internet still required spinning up a server, installing nginx, configuring SSL with Let's Encrypt (at least it was free) and futzing around with nginx `proxypass` directives for several hours.

It works, and I guess it's conceptually simple, but it was still an all-day ordeal to get it up and running from scratch.

Azure Static Web Apps and then a bit of AJAX to pull in the data from a function (all deployed automatically in one go)

https://azure.microsoft.com/en-us/services/app-service/stati...

Not a dynamic HTML page per-se but a page with dynamic data.

I deployed one of my old hackathon apps with it, works well - https://memorylane.benbristow.co.uk/

Have you tried Caddy as your reverse proxy? It's much simpler compared to nginx and it has very robust, integrated LE support. It's also packaged for Debian and CentOS now.

Write a systemd unit file for your golang service, put Caddy in front of it and you are good to go. It's not a PaaS, but it's simple and shouldn't be too difficult to maintain.

> Write a systemd unit file for your golang service

Oh yeah, I forgot I had to do that, too! Another step.

I'll take a look at Caddy!

But now you know it. I do all that stuff for all my personal projects, but it is much faster because I already have servers and I have done it a couple dozen times now. I'm getting to know proxypass and caching directives very well. My first time took hours and much futzing. Once it becomes routine, I automate. I wrote my own build server in JS and bash, it handles webhooks, roll-back on fail and notifications. I've been meaning to mess with ansible.

It has even come in handy at work. I'm primarily a front-ender, but a start up I worked for had me continuously deploy my application to my own personal infra so it could be used immediately.

It is an ordeal at first, but nginx is so darn powerful it makes me feel like a wizard. If you want to avoid the arcane incantations, I'm sure Caddy would be a simpler option.

That’s PHP’s wheelhouse.

If you don’t want to just use some shared hosting, grab any server and use the package manager to install Apache + PHP.

Drop HTML in the web root.

Whatever part of the page is supposed to be dynamic, you can literally just start throwing code in the middle of the HTML, mixing it all together freely.

It won’t be beautiful, but you can go from nothing to this in like 30 minutes or an hour.

What do you mean without the magic?

Ruby is extreme flexible in terms of metaprogramming in rails uses that very much. And ruby is not statically typed.

So if in rails you declare an active record model with belongs_to etc it's hard to keep track of what is really happening under the hood.

In php you have almost no runtime metaprogramming so the things that could happen if you read a piece of code are reduced to a smaller set of options that are easier to understand. well you have reflections but at least they are used in a more static way.

Ruby also raises an exception for a string coercion to an int when the string isn't an obvious int.

That's a local effect that can be avoided once you know the sematincs of the language. The issue with abused metaprogramming and monkey patching is that it results in global effects that are hard to track.

I would prefer to review a messy 50kloc php project over a messy 50kloc ruby project.

I was citing it as a good thing versus PHP's (and Perl's) "foo" == 0;// true behavior. I believe that still to be the right thing despite other issues Ruby has.

Then I agree of course!

I think they mean stuff in Laravel framework and Ruby on Rails. Like database access where you can just use it as an object without worrying about queries and such. This is great, gets projects up fast.... until you need to do something different. It generally comes at the expense of flexibility.

Most ORMs allow you drop down into RAW for all or part of the query, so you haven't really lost any flexibility.

Reply on news.ycombinator.com