Live data from Hacker News

PHP in 2019

stitcher.io

121–130 of 489 posts

Re: PHP in 2019

#121
post #73
post #51

As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…

> Is performance that much of a big deal for most people? For most people outside VC-funded startups, yes it is. It is also an environmental concern, imagine if 80% of the web was running on ruby.

Well if 80% of the web was running on ruby there wouldn't be any difference.

Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers.

Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)

Re: PHP in 2019

#122
Here's the thing that always grates a little bit for me about these posts:

I don't have a choice.

I've worked at a couple of organisation where there are hundreds of thousands of lines of code written in PHP. It's been there for years. It does its job and - from a business perspective - it does its job pretty damn well. And I get paid to keep it ticking, and to improve it. Not to rewrite it to fit my personal tastes.

In my spare time I've played with Haskell, Rust, C, Lisp, assembly languages, and I enjoy them. I dearly miss some of the more functional aspects from these languages every time I write PHP.

I work with a large PHP codebase right now (amongst others) and while there are a great many technical benefits I could wring from it in another language, runtime, or environment, a lot of the changes needed to get there would be prolonged, painful, and would provide no noticeable business value.

I'm somewhat reminded of Python, where there is the concept of a "pythonic way" of doing things. There is very much a "PHP way" of doing things, a "${LANGUAGE} way" of doing things, and of course an "${ORG-SPECIFIC} way".

I'm also somewhat amused at Rails as a frequent comparison. I've also worked with Rails, and I hated it. It was quite some time ago, I'd probably enjoy it if I tried again. But I will try to remember in future that opinions formed from bad experiences need to be reviewed in light of the time elapsed since then, and my own personal/professional growth as well.

More generally, when I hear a developer (in my own office ;P) espousing the view that "${LANGUAGE} is garbage", I assign more meaning to the fact that they choose to make that statement than I do to any particular view of the language in question.

Re: PHP in 2019

#123
post #51

As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…

> ven assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?

I think the "path of least resistance" is important: developers are time-constrained, understanding-constrained, lazy (if they're virtuous), etc. There's a big incentive to do whatever is easiest/quickest.

When I last used PHP, about 5 years ago, there were OOP APIs cropping up to replace many of the standard global functions; namespaces had just been introduced; closures had become useful; frameworks like Symfony (and Drupal 8) were becoming established, rather than the old "plugin" approach of throwing around arbitrary code and hoping for the best; dependencies were being managed by composer; files could be autoloaded from sensible locations; testing frameworks like PHPUnit and PHPSpec had become best practice; etc.

Yet all of those things were opt-in and verbose. The path of least resistance was still:

    
      
        Hello 
      
    
(For non-PHP programmers, this is appending a GET parameter straight into the page, which is an XSS vulnerability). Doing things "properly" took a great deal of effort and discipline.

Compare this to something like Java: it favours class-based OOP so much that even "hello world" needs a class. The path of least resistance is to do things "right" (from Java's perspective). Haskell's path of least resistance is simultaneously easier ("hello world" is just `main = putStrLn "hello world"`) and harder (`main` uses the `IO` type, whose API enforces certain conventions).

Deprecation warnings, linters, etc. can help with this; but PHP's only real strength is its installed base of code and developers; changing the language too much would throw away this advantage (akin to being a new language, see Python 3 and Perl 6); not changing it enough prevents the more serious and/or systemic issues from being dealt with.

I wish the language designers and users luck, but I'm really hoping to never use it again ;)

Re: PHP in 2019

#124
post #92

Earlier quoted context omitted.

> Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? One of the most understated pros of PHP (IMHO) is that it's so easy to get setup with. You can start hacking on something so quickly. In my experience, Go has not been like that. Node.js also was never as quick.

But other languages like Python and Ruby are even easier to get started with than PHP.

I worked with rails in the 1.x and 2.x days. Deployment was a joke and you had to restart the whole Ruby server to update scripts.

PHP you simply refresh your browser page to see the changes. This has all changed in recent years and rails deployment/debugging is much smoother.

Re: PHP in 2019

#126
post #62

Earlier quoted context omitted.

It can be changed. You have some syntax to opt into a later release (e.g. doing ` In a major release, you then get rid of a load of cruft.

> You have some syntax to opt into a later release (e.g. doing ` imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.

I would see it as javascript's strict mode, and I think most devs would ok with a binary switch.

The only fear I'd have is a lack of big entity committed to PHP. In the heydays there was Yahoo, facebook and other giant companies relying on PHP and guaranteeing that there would be enough man power to weather any type of changes. Now I wonder how many people are left to push through breaking changes and rewrite/modernize the libraries and the ecosystem.

Re: PHP in 2019

#127
post #27

Earlier quoted context omitted.

There are comparable things with other frameworks too. For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/ It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really. The course comes with the source code along wi…

Every time I try out Flask, Aiohttp or even Express.js I appreciate more the stuff Django normally does for me.

Django abstracts away a bit too much, if you ask me. For a simple REST API it's complete overkill. I prefer Flask or Falcon[0], in which you don't just get better performance[1] but also a lower level of control.

[0] https://falconframework.org/

[1] https://klen.github.io/py-frameworks-bench/ or https://github.com/the-benchmarker/web-frameworks

Re: PHP in 2019

#128

Earlier quoted context omitted.

Yep. Laravel is basically PHP on Rails. They do a great job with it too.

I dunno... Their home page looks like something out of the Panera Bread playbook looking at the homepage. 'Web artisans'? Why is it 'clean' because it has an absurd amount of whitespace and comments of platitudes for the code example?

Lol, I agree their packaging looks a bit different but the contents of the package are basically the same.

Working with both Laravel and Rails will make it clearer that they try to follow the same principles of convention over configuration and programmer happiness :).

Re: PHP in 2019

#130
Ah yes, PHP, the garbage fire of the Software Engineering world which like the cancer that it is, just refuses to die.
Post reply on HN