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

441–450 of 489 posts

Re: PHP in 2019

#441

Post by jtreminio »

wyqydsyq wrote: post #436
jtreminio wrote: post #429

Earlier quoted context omitted.

> 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…

> Writing PHP requires to you memoize random shit like the fact that json_encode() accepts options via bitmasks

Several other functions use bitmaps. It's a convenient way to string multiple options together without needing to pass key:value arrays. It's in the manual. My IDE typehints this for me. It's well documented. If you're surprised by this it's because you're using a text editor. Do folks write c# outside of Visual Studio? I can imagine some people might enjoy writing Java in notepad.exe but that's simply not for me. Why would I subject myself to this? Why make programming harder than it need be?

> - 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)

So you need to know ... what you're importing. This is difficult for you? If you don't want your IDE to typehint on the namespace, you need to open the stuff you imported. Honestly, you're reaching.

> - Variables are all declared in global scope by default

I don't understand why you would think this is unique? Any variable declared in the global scope is ... global scoped?

https://playcode.io/317387?tabs=console&script.js&output

If you look at RoR, running `rails server` spins up a webserver using Puma. Why wouldn't RoR use whatever built-in webserver Ruby ships with? I admit I am not as knowledgeable in Ruby or Python as I am in PHP, but what I do know is that a 5 minute Google search shows me that very few places on the internet recommend exposing Ruby or Python directly to the internet, and instead Unicorn, Passenger, etc are recommended.

Why is this even a point of contention for you? Why would you think doing this, or being able to do this, would be a positive?

Re: PHP in 2019

#442

Post by slenk »

chx wrote: post #418
blowski wrote: post #379

Earlier quoted context omitted.

We run about 1,000 simple websites off the same Drupal codebase. Custom forms, page layouts, etc.

So your argument is that a multisite project running a thousand sites off the same codebase containing custom forms and layouts is simplistic? Then, I pray, what do you call complex?

Maintaining 1000 servers

Re: PHP in 2019

#443

Post by lugg »

alunchbox wrote: post #157
lugg wrote: post #136

Earlier quoted context omitted.

If laravel is the best we have were fucked. Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.

Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?

Yes, they are supposed to.

The problem is that it gets taken to extremes when it's done at the framework level.

The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around.

Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful.

If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting.

IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem.

The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC.

Within modules usual namespacing and new constructors were used liberally.

Re: PHP in 2019

#444

Post by lugg »

dpcx wrote: post #151
lugg wrote: post #136

Earlier quoted context omitted.

If laravel is the best we have were fucked. Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.

Can you share some of the BC breaking changes you've seen? I personally haven't seen any in quite a while, but I'm not using all parts of the framework.

Read the migration notes for the last few releases. Anything that requires you to change your code is a breaking change and the reason you can't skip versions.

Re: PHP in 2019

#445

Post by Zarel »

DCoder wrote: post #320
simion314 wrote: post #45

Earlier quoted context omitted.

Unfortunately this is true and it can't be changed, the functions are named and parameters are soemtimes inconsistent like strpos and str_replace, I would have to use the docs all the time if my IDE wouldn't show me the param names. But after you get productive with PHP there is no feature that I think I am missing from other similar languages.

Features that I miss in PHP: - expressive type system with generics, union types, literal types, basically TypeScript. I can say "this function returns a string" or "this function returns an array", but not "this function returns an array of strings". - specialized collection/hashmap data structures with good support across third-party libraries. Having one array() structure acting as both a sequence and an associati…

It looks like Facebook had your exact problem; you want Hack:

https://hacklang.org

It's based on PHP, but adds:

Expressive type system with generics:

https://docs.hhvm.com/hack/types/generic-types

Specialized collections: vec, dict, keyset

https://docs.hhvm.com/hack/types/arrays

Templating solution similar to JSX: XHP

https://docs.hhvm.com/hack/XHP/some-basics

Re: PHP in 2019

#446

Post by verbify »

n42 wrote: post #317
cbdumas wrote: post #275

Earlier quoted context omitted.

Often when there is a post about PHP I read over these treads sort of subtly trying to figure out how a language with such a large user base has remained basically invisible to me. And I don't think I live in the HN bubble, though I do use a lot of Python, in my consulting work I've also done plenty of work with .NET, JVM to a lesser extent and other "boring" tech. But PHP has literally never come up, even as a sugge…

ever heard of Facebook? Slack? Etsy? WeWork? Box? Yelp? just to name a few.

Or mediawiki

Re: PHP in 2019

#447

Post by stunt »

Most of the people defending PHP are talking about PHP7+, and most of the people hating PHP are talking about PHP5-.

Both groups didn't experience what the other group did and they are not talking about the same thing. So it is kind of pointless discussion.

The language itself has improved a lot. It is easy to find decent PHP7+ code now. It is also easy to find bad code.

And that is the same for all major programming languages in terms of usage. As Java got more popular, it was easier to find crappy code everywhere from people that only learned inheritance from OOP. More projects mean more technical debt for the future. So you always find more critics against most popular ones.

Re: PHP in 2019

#448

Post by chriswarbo »

rob74 wrote: post #198
chriswarbo wrote: post #123

Earlier quoted context omitted.

> 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/quicke…

To understand that, you have to take a closer look at its origins. For me, this talk by Rasmus Lerdorf (creator of PHP) was a real eye-opener: https://www.youtube.com/watch?v=SvEGwtgLtjA He mentions that what we now refer to as the "PHP language" was originally intended to be only the templating system, and you were supposed to write your business logic in a "real language" such as C. However, as PHP got more popular…

> what we now refer to as the "PHP language" was originally intended to be only the templating system, and you were supposed to write your business logic in a "real language" such as C

I did get a little perverse amusement at writing HTML files containing nothing other than single `<?php` element; where that PHP's job was to generate HTML; and it did so via a templating language (e.g. Twig or Smarty)...

Re: PHP in 2019

#449

Post by richardwhiuk »

mgkimsal wrote: post #89
pilif wrote: post #62

Earlier quoted context omitted.

> 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.

There's already been a degree of that with php.ini flags, and some of the behaviours available via those flags have been deprecated then removed over a period of years. It's not impossible. Yes, it's complex, but the process for dealing with that complexity has already existed and worked out ... relatively smoothly. The bigger issue is getting people to upgrade - I'm still dealing with a couple of projects - one star…

That's why you want to do it on a per file basis, not on a per interpreter basis, which allows a project to incrementally move.

You also want a single version, not a gigantic pile of things to opt in to.

Re: PHP in 2019

#450

Post by pdimitar »

simion314 wrote: post #242
pdimitar wrote: post #74

Earlier quoted context omitted.

Those legacy applications won't ever be upgraded to that theoretical and slimmed down PHP anyway, so I don't see a problem.

Old PHP projects can be upgraded in the present because backwards compatibility exists, as i metnioend in other comment I done such a small upgrade and I hat to change only 1 deprecated function with a different one. If this would not have been possible the project would have still be running on an old version without security fixes and slower(eating more electricity so bad for environment)

If you say so. ~5 years ago I had to work a full week, 8h a day, to fully upgrade a medium-sized website from PHP 5.2 to 5.4, and eventually gave up. Most of the time was spent trying to cope with different datetime parsing idiosyncrasies.
Post reply on HN