Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP in 2019

stitcher.io

Post reply on HN
Print view View original

361–370 of 489 posts

Re: PHP in 2019

#361

Post by codesushi42 »

wvenable wrote: post #218
hguhghuff wrote: post #41

The thing that matters is language consistency... A language with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the language adheres. Nothing here says PHP has been fixed in this regard. Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further…

> The thing that matters is language consistency. To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented ab…

That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.

The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.

Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.

If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.

Re: PHP in 2019

#362

Post by chc »

thanatropism wrote: post #339
mmccaff wrote: post #224

Earlier quoted context omitted.

"Clever" "marketing" language like this is not unique to Laravel, most frameworks use language like it for tag-lines on their homepage. Pyramid, a framework for Python, even goes with the same "artisan" language. They're just trying to be fun, inspiring, etc From the home page of a few other frameworks: Django: "The web framework for perfectionists with deadlines." Flask: "Web development, one drop at a time" Express…

It’s not funny. People who have bought in something have (1) to rationalize their choice and (2) cheer so the project remains alive and a major contender.

That's not my experience at all. Most developers I know have worked with technologies before and come out saying, "I would rather use something else next time."

Re: PHP in 2019

#363

Post by simion314 »

DCoder wrote: post #349
simion314 wrote: post #338

Earlier quoted context omitted.

I am not trying to say PHP > TS, just wanted to let you know in case you still work with PHP codebase that you can get good enough type checks with PHPDoc, here is a good example for the case you mentioned , in Intellij the built in linter will mark as warnings when you use types wrong https://i.imgur.com/NqlAsTd.png (zoom a bit out and sorry for the bad crop) About the array issue don't we have same situation with J…

IntelliJ will detect cases like that, yes. But it is difficult and slow to get IntelliJ to inspect your whole project like `tsc` does. With PHPStan or such tools you can do that more easily, but they still have interop problems due to non-standard annotation syntax. Having native support for such type expressions would be much better. ES6 has Map and Array, which are perfectly sufficient and distinguishable from each…

>ES6 has Map and Array,

Bue ES6 is new, I never seen APIs that use Map , I often had to use an Object as dictionary and had to Google how to properly do it not to get extra keys and values from the Object.prototype.

I am not trying to say that PHP is better then TS, but as far as type safety my PHP code with PHPDoc is better type checked then JS code with JSDoc (we are using ES5).

I don't have experience with PHP rendering, but I assume you only have to escape unsafe input, don't have to escape markuup, have you tried twig, is it not safe https://twig.symfony.com/doc/2.x/filters/escape.html ?

I admit I like rendering with react, but I admit that reading a twig template is much simpler then reading JSX code (but I am condemned to use angular :-( ).

Re: PHP in 2019

#364

Post by ppeetteerr »

runin2k1 wrote: post #311
ppeetteerr wrote: post #296

Earlier quoted context omitted.

Have you ever tried building, deploying and maintaining Java? There is more to a language than the syntax

I'm not one to proselytize since I use a handful of languages every day, but when my Java hat is on, I double click a build target, my software is tested, built, deployed side-by-side with my current production build. New users are automatically pushed to the new build, and users with existing sessions remain on the previous build. When I undeploy the previous build, the rest of the users start seeing the new build a…

What's your setup?

Re: PHP in 2019

#365

Post by sputr »

I'm more and more surprised that Laravel is so often mentioned over Symfony in this types of debate.

I've worked with both and done professional projects in both. While both are great, I would have to sing some praise for Symfony's developer experience and tooling. But realistically the're neck and neck.

PS: It's really funny seeing people seriously discuss PHP when they themselves have not tried it since the 5.* days.

Re: PHP in 2019

#366

Post by codesushi42 »

momokoko wrote: post #294
ilmiont wrote: post #281

Writing with PHP is better than ever... and getting better and better. And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion , going in the right direction with a stronger slant towards OOP and types. Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in an…

My issue with modern PHP is that it's essentially becoming Java. And with the JVM and the Java ecosystem, what is the compelling reason to not just pick Java at this point? With Java you are basically writing exactly what you would be writing with PHP, except with more language features and the ability to opt into other languages on the JVM like Kotlin and Scala. The modern additions are fantastic for projects and te…

Except PHP is not Java, and it never can be.

What is PHP's multithreading model again? Hotspot VM? NIO?

I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.

Re: PHP in 2019

#367

Post by no_wizard »

owenwil wrote: post #2

I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues. A great examp…

I hear you on composer being slow. One thing I found that works extremely well to speed up composer installs:

https://packagist.org/packages/hirak/prestissimo

Give this package a try, it really worked for me to speed up package management with composer.

Re: PHP in 2019

#368

Post by wvenable »

codesushi42 wrote: post #361
wvenable wrote: post #218

Earlier quoted context omitted.

> The thing that matters is language consistency. To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented ab…

That's irrelevant. When talking about language consistency, we should also be including the language's standard library. The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl. The draw of…

> That's irrelevant. When talking about language consistency, we should also be including the language's standard library.

As you said, PHP was merely an interface to (many already existing) modules written in C. When people complain about mysql_real_escape_string() in PHP they don't realize that that is the actual name of the function in the MySQL C API. Same with the image functions (imagemagik). And so on. Some are named directly after the corresponding C standard library function.

This was actually part of the huge success of PHP -- it made available, for the web developer, a huge library of existing open source technology. This did not exist, in a scripting language, before PHP. The open source community wasn't as large.

But PHP does have high-level abstractions and, like with other languages, you would also use a framework that has high-level abstractions.

If you compare PHP to JavaScript, PHP's standard library is far superior. But it's a ridiculous comparison there as well.

> The problem is that PHP wasn't designed as language-first but a tool to make web development more accessible.

Yes, but all the ways that PHP as-a-language were less than ideal most of those have been solved now. So unless you're complaining about the standard library, there isn't much left.

> Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.

Nowadays there really just isn't that much difference in design or performance between PHP and the majority of languages you would suggest.

Re: PHP in 2019

#369

Post by bufferoverflow »

ljm wrote: post #337
owenwil wrote: post #2

I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues. A great examp…

I cut my teeth as a developer on PHP, back in the 4.3 days before they'd really placed their bets on OOP, and we were dealing with mysql_real_escape_string, needles and haystacks, and haystacks and needles. No PDO, XSS and SQL injections up the wazoo. I can't say I enjoyed working on any of those projects compared to the kind of stuff I do now (and how much I've learned since), but I've been remarkably surprised by s…

Modern PHP is light years ahead of 4.3. Not just the ecosystem, but the language itself, the performance. It's really not bad.

Re: PHP in 2019

#370

Post by marcosdumay »

isaacremuant wrote: post #221
marcosdumay wrote: post #148

Earlier quoted context omitted.

Laravel has a Java-like problem of too many indirections, and has a really complex application model that breaks a lot of things. For that you gain an end of 00's quality templating system and ORM. I understand that PHP developers love it. It's orders of magnitude better than doing everything by hand. But no, thanks.

Just out of curiosity. What type of comparable work are you doing and what languages/frameworks are you using? How do they compare?

I've created reasonably complex projects on Django (with late 00's capabilities), I've done things in Flask, Asp.Net, Java (with very out of date components), very simple things on Rails, and also used some non-OOP frameworks like snap, I've also used some newer templating systems. I have never created anything in Laravel, but I have done some maintenance.

Compared to Django and Rails, Laravel has those two problems I said. I don't think I ever saw a benefit of Laravel compared to them, except for the easy to deployment of PHP (that is a mixed bag anyway).

The ASP.Net and Java frameworks are so different that any comparison could join Django, Rails, and Laravel as a single point. Everything on those languages is more bureaucratic and stable, easier to compose more complex projects, but harder to create simpler ones.

Compared to snap (I've used very little of Yesod, but looks like it's alike here), the trio Laravel, Django, and Rails compose pages much better (it's a shame really since "compose" and FP go hand to hand, and I expect that to change in the future), but the FP frameworks are much better for creating data services.

Post reply on HN