PHP in 2019 • Hacker News Board

Re: PHP in 2019

#431

Post by wyqydsyq » Thu, May 16, 2019, 2:41 AM UTC

strictfp wrote: post #277

gwbas1c wrote: post #257

Earlier quoted context omitted.

The thing that I like about PHP is that I can mix HTML, code, and database queries into a single file. This is incredibly useful when learning basic web development, even though it doesn't scale for more complicated applications. It's also incredibly useful when trying to bang out a simple experiment.

It also allows you to utilize and extend the full http protocol, something which most "serious" frameworks hinder.

PHP doesn't have anything to do with the HTTP protocol, Apache/Nginx/etc handle HTTP and simply call your PHP script with some global variables set to values parsed from the HTTP request

Re: PHP in 2019

#432

Post by int_19h » Thu, May 16, 2019, 2:42 AM UTC

simion314 wrote: post #354

ken wrote: post #345

Earlier quoted context omitted.

The complexity still has to exist somewhere, right? By avoiding this, they're just keeping it in all the developers' heads, rather than a legacy mode in the compiler. I'm not sure that's the wrong decision, but it's not a great one, either. Too much complexity in the implementation can kill the project. Too much complexity in the language can kill a person's hope of learning it.

Many complaints are about the PHP standard libraries and not about the language itself, so you can learn the language just fine and just don't learn the old deprecated functions at all unless you hit such a function in a codebase and tehn you research it. . Is not equivalent to compare PHP+ standard library with JS core , PHP included function to read and write files, streams, databases,json,XML, run executables(if e…

The libraries can also be treated in a similar manner.

Re: PHP in 2019

#433

Post by int_19h » Thu, May 16, 2019, 2:45 AM UTC

benp84 wrote: post #308

joemaller1 wrote: post #245

I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating. The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards. For whatever reason, I often feel clu…

I hear this complaint a lot but I find those argument orders completely intuitive. You filter (1) an array with (2) a function. You map (1) a function over (2) an array. You reduce (1) an array with (2) a function. It follows exactly what I'm thinking when I type it. To reverse the orders would be, what? "Mapping an array with a function?" "Filter a function on an array?"

This sounds a lot like the arguments used in favor of Perl 5 sigils.

Re: PHP in 2019

#434

Post by wyqydsyq » Thu, May 16, 2019, 2:47 AM UTC

StevePerkins wrote: post #104

On one hand, I do see that HN (and probably Reddit) live in a bubble. Where most of the darling languages and tools have very low use in the real-world. And where most of the languages and tooling that actually run the real-world go un-discussed, or simply dismissed, because they're boring and don't appeal to students and entry-level devs working on side projects. I realize that the perspective most rookies get from…

There's still lots of small-fish web development agencies who specifically hire PHP developers.

That's about it though, I think the web development industry is specifically tied to PHP because of their excessive dependence on WordPress, Drupal etc, this also produces developers who are overly specialised in niches using these platforms at the expense of general capability. Think back to the mid-2000's where there was a big difference between a JavaScript developer and a jQuery developer - while they both wrote JS the latter was generally incapable of using vanilla JS proficiently because their use of jQuery's abstractions as a crutch impaired their learning of the underlying fundamentals. A lot of "WordPress developers" are so heavily specialised in using WordPress they probably can't even remember how to write a vanilla PHP site.

Re: PHP in 2019

#435

Post by nikdaheratik » Thu, May 16, 2019, 2:49 AM UTC

StevePerkins wrote: post #104

On one hand, I do see that HN (and probably Reddit) live in a bubble. Where most of the darling languages and tools have very low use in the real-world. And where most of the languages and tooling that actually run the real-world go un-discussed, or simply dismissed, because they're boring and don't appeal to students and entry-level devs working on side projects. I realize that the perspective most rookies get from…

Well I've been gainfully employed for pretty much my entire career using PHP and I've never had a problem with recruiters. It really depends on the city, the companies in that city, and the overall market in your region.

Big business runs on Java/.NET, but small-midsized businesses run on a variety of different platforms partially based on the history of their IT department and their development needs.

The bottom line is that you can write a good greenfield web application for a midsized business faster, with less overhead, and with fewer headaches using PHP and a good framework than you can with Java or any of those other tools you mentioned. The tradeoff is that they don't integrate as easily with the huge backend software packages and may not scale as well as Java and .NET. Which is why huge businesses don't run with them as much.

Re: PHP in 2019

#436

Post by wyqydsyq » Thu, May 16, 2019, 2:59 AM UTC

jtreminio wrote: post #429

wyqydsyq wrote: post #427

I respect the leaps PHP has come as a language and runtime in recent years, however I still can't understand why anyone would elect to use it for greenfields projects. The developer experience might be better than it's ever been, but even as pointed out in this article, it still has all the old issues like inconsistent core API, vague global context, and way too much implicit magic and guesswork. Not to mention it st…

> it still has all the old issues like inconsistent core API Seriously, people keep bringing this up. Why? Are you a machine? Did you memorize the API to every single language you write in? I type `strst` and my IDE autohints `strstr()` and the argument order. > vague global context What's vague about it? What does global context even mean in this sentence? Do you mean like super variables? Static properties? Can you…

> Did you memorize the API to every single language you write in?

No, that is my point. Languages with consistent core APIs are more easily discoverable, less error-prone and result in developers being less reliant on editor hinting. Writing PHP requires to you memoize random shit like the fact that json_encode() accepts options via bitmasks, inconsistent with the rest of the language for no apparent reason.

> What's vague about it?

- Imports/namespaces are not explicit (no intuitive way to know what methods are being provided by a given import without diving into it's file)

- All HTTP input (remember, PHP basically exists to script HTTP responses) is magically provided through vague superglobals that are set to wildly different values depending on what HTTP server you use and how it is configured

- Variables are all declared in global scope by default

> You _can_ run your website using only the built-in webserver for those languages, but are you really going to do that?

Yes. Unlike with PHP, running a single-process HTTP server does not result in thread locking for most other languages as their HTTP implementations are asynchronous by nature. There are currently some PHP community projects to implement async i/o, but there isn't even really any point trying to use them given PHP is meant to be having native libuv support eventually which will more or less make them redundant. And even then, why would you go to all this extra effort reinventing the wheel if not just to be stubborn and avoid having to learn a new language which is better suited to the task at hand?

> Or are you going to put Nginx or Apache in front

I hope you realise that other than for traditionally CGI-executed runtimes like PHP, Ruby and Perl, external HTTP servers like Nginx and Apache are almost exclusively used as a reverse proxy for things like load-balancing and SSL termination and have little to no involvement in processing and responding to the actual HTTP requests, which is typically left up to a HTTP server implemented in the application code.

Sounds more like you have little to no experience with web services outside the PHP world.

Re: PHP in 2019

#437

Post by nikdaheratik » Thu, May 16, 2019, 3:04 AM UTC

reallydude wrote: post #273

foobarandgrill wrote: post #171

Earlier quoted context omitted.

What's wrong with Laravel or Symfony?

Laravel and Symphony, in particular, have the terrible code smell of elongated toolchains, that are specific to the frameworks. > php artisan serve # laravel > symphony server:start # symphony Same poor thinking that NodeJS introduced, albeit less offensively integrated. If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to…

I can't speak for symphony, but that's just not the way it works in laravel. The "artisan serve" action is used when you want to make a quick demo (maybe). The actual deployment is in an apache server like everything else.

The rest of the actions that use artisan, for the most part, are for creating boilerplate code like database models or empty controllers quickly. They aren't a requirement to use the framework, but are faster and less error-prone than copy/pasting an old empty class file.

The last class of actions that call artisan are for things like cron jobs which you setup once and forget about. Their use case is pretty obvious once you read the manual.

> These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.

That's nice to hear, but it's probably not true for the majority of people. The entire point for these projects is to allow programmers to create a rapid prototype for design purposes that can then be iteratively developed into a final product. If they don't make sense to you, maybe it's because you aren't working in that space, and not because the tools themselves are lacking.

Re: PHP in 2019

#438

Post by wvenable » Thu, May 16, 2019, 3:17 AM UTC

codesushi42 wrote: post #425

wvenable wrote: post #421

Earlier quoted context omitted.

Honestly nobody uses the SPL. PHP's array type is more than powerful enough for the vast majority of data structure tasks and the standard library has functions for treating it as a stack, a list, etc. Coroutines are not necessary in PHP. In fact, the share nothing architecture of the LAMP stack is one of it's advantages if that suits your needs. The setup of a Java web stack alone is painful enough to make PHP a via…

Thanks. Again, I am asking out of ignorance: What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed? Does the VM enforce a GIL? I'm assuming there is some kind of threading API? Can you run an event loop using epoll, and is the standard library well supported in that execution model? FYI, I was a PHP developer from 2003-2011. I did enjoy it back then. I never…

> What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed? > Does the VM enforce a GIL? I'm assuming there is some kind of threading API?

As far as I'm aware PHP is still mostly run PHP-FPM. It also does have a threading API: https://www.php.net/manual/en/class.thread.php

> But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.

I haven't done PHP seriously in a very long time. I currently work in C# and ASP.NET for web and I do C++, Python, and JavaScript. Personally, I'm doing work in Python right now and I don't enjoy it very much -- I'd much rather work in PHP for web development over Python. I prefer a good strongly typed language.

> I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.

I don't know. PHP has Lambdas. It has generators. It was strong typing. From a CS perspective, there isn't much PHP does not have for the purposes of web development. It's limitations, in my opinion, mostly come from being a dynamic scripting language but those same issues befall Python and Nodejs as well.

If I had to code in PHP again, my code wouldn't look much different from my code in any other language.

Re: PHP in 2019

#439

Post by jv22222 » Thu, May 16, 2019, 3:24 AM UTC

Aeolun wrote: post #424

beezischillin wrote: post #408

Earlier quoted context omitted.

I used both Laravel and Symfony but I ended up with the second. I didn’t like the way Laravel’s ORM has its models structured plus the Symfony PHPStorm plugin is a miracle. Your mileage may vary and this is just me but I never quite understood why people ended up loving Laravel so much vs. Symfony.

I feel Laravel is fantastic for Junior and medior programmers, while Symfony appeals more to seniors.

I’m a senior programmer and love Laravel. But maybe I’m a junior at heart ;)

Re: PHP in 2019

#440

Post by kamranjon » Thu, May 16, 2019, 3:31 AM UTC

codesushi42 wrote: post #413

gremlinsinc wrote: post #405

Earlier quoted context omitted.

I'm not a concurrency expert (haven't had to do much high-performance stuff), but php does have coroutines like go's --if you use swoole, the performance is actually higher than node in some benchmarks and other multi-threaded / parallel programming paradigms, which comforts me to know that if I have the use case it's there, so I don't necessarily need to drop everything and pick up rust or java or go or another lang…

Coroutines do not mean that you get parallel execution. Concurrency is not the same as parallelization. If PHP does not have JIT, then it's nowhere near the speed of Java. Even if it did, Java would likely beat it significantly. I would encourage you to read about Java's Hotspot VM and its adaptive optimizations.

Multithreading is not strictly parallelism, typical discussions of multithreading regard concurrency, and multithreading is what you initially asked about. PHP 7.4 will ship with a JIT as an experimental feature and PHP 8 will ship with it built in standard.