zlacker

[parent] [thread] 96 comments
1. user39+(OP)[view] [source] 2022-12-08 13:16:18
The worst part about PHP is constantly hearing from its detractors, who are often people who haven’t used the language in many years. Haystack needle order, $, fractal of bad design, it just gets old.

The language isn’t perfect but I love working with it, these 8.1 and 8.2 improvements have really made it sweet.

My biggest gripe at the moment is the (very old) behavior of e.g. preg_match() and sort(). You’ve got a small handful of these common functions that operate on their input by reference/in place which is gross. A new version of these would be welcome.

replies(14): >>cies+v2 >>nathel+03 >>sebste+P4 >>osrec+E5 >>porker+J6 >>bawolf+F8 >>felipe+ah >>vanill+jj >>pmarre+ru >>evo_9+bP >>trolli+eS >>36amxn+hY >>gosuki+oY >>yrgula+WV3
2. cies+v2[view] [source] 2022-12-08 13:35:17
>>user39+(OP)
> I love working with it

Great! Keep using it! Ignore us. We (detractors) also had to use it and have since learned (hopefully several) other languages that (not looking at you JS) we like much better... :)

replies(2): >>zmxz+53 >>sbarre+e3
3. nathel+03[view] [source] 2022-12-08 13:38:17
>>user39+(OP)
Is there still a php.ini that allows you to alter the language’s semantics? To me, that’s the biggest can of worms that PHP used to have. I haven’t touched it in years, so am not up to date.
replies(2): >>trilli+z4 >>nolok+55
◧◩
4. zmxz+53[view] [source] [discussion] 2022-12-08 13:38:29
>>cies+v2
What was the motive behind this post? What do you hope to gain?

If it's recognition for learning <insert-language>, how do I provide it to you?

replies(1): >>sdiaco+0R
◧◩
5. sbarre+e3[view] [source] [discussion] 2022-12-08 13:39:14
>>cies+v2
Curious about something.

If you've long moved on and are no longer using PHP, why do you still consider yourself a "detractor"?

replies(1): >>IgorPa+95
◧◩
6. trilli+z4[view] [source] [discussion] 2022-12-08 13:46:32
>>nathel+03
Yes. Looks like the canonical use if for ENV vars though?

https://www.php.net/manual/en/configuration.file.php

7. sebste+P4[view] [source] 2022-12-08 13:47:28
>>user39+(OP)
There's less and less wrong with it as we go along, but seriously there's still so much crap... You could list so many other than preg_match

>sleep(int $seconds)

>returns zero on success.

>If the call was interrupted by a signal, sleep() returns a non-zero value. On Windows, this value will always be 192. On other platforms, the return value will be the number of seconds left to sleep.

I've used it for 2 years 2 years ago and I'm not at all interested in starting a project with it again

replies(4): >>mgkims+z6 >>donatj+U7 >>xxpor+ki >>within+Bp1
◧◩
8. nolok+55[view] [source] [discussion] 2022-12-08 13:48:53
>>nathel+03
Not really. You have a php.ini that can configure some behavior, but most of what was horrible is either deprecated or straight up removed (register globals, ...)
replies(1): >>lazka+Ie
◧◩◪
9. IgorPa+95[view] [source] [discussion] 2022-12-08 13:49:11
>>sbarre+e3
For me PHP 4 and 5 was an experience that left me feeling gross. I had to go home and work on personal projects trying to figure out a way to write beautiful code to offset the ugliness I encountered every day at work.

I still occasionally work with PHP for WordPress and it is still mostly not great. The mess of abstractions, the JS-like library installation system, the lack of any kind of concurrency, the mess with errors vs exceptions.

It just isn’t a language that makes me happy. Then again, I dread opening a .php file so maybe it’s a preconceived notion.

replies(1): >>mgkims+q6
10. osrec+E5[view] [source] 2022-12-08 13:57:39
>>user39+(OP)
The truth is, no language is perfect.

PHP just happens to be good at getting stuff done fast, so it's found all over the place, and thus has a lot of eyeballs on it. The negativity is a byproduct of it's usefulness and staying power - the price of popularity, if you will.

I love PHP, especially with the new event loop based modules that let you do things asynchronously, much like Node or Go.

If you know how to use it well, PHP is awesome, and it's getting better with each release.

replies(2): >>PaulHo+x6 >>msla+dz
◧◩◪◨
11. mgkims+q6[view] [source] [discussion] 2022-12-08 14:03:24
>>IgorPa+95
It's the 'wordpress' part of PHP that is 'mostly not great'. Projects started in the past few years with any major framework will generally be cleaner and easier to understand, and easier to extend with composer/psr interop.
replies(1): >>motogp+Ba
◧◩
12. PaulHo+x6[view] [source] [discussion] 2022-12-08 14:04:01
>>osrec+E5
PHP was the first open source language in which just anybody could write server-side web applications without terrible management problems for the sysadmin. First people wrote cgi-bin scripts in Perl, which were not efficient because they forked a process for each request. There was mod-perl which was more efficient but prone to memory leaks. A few people wrote cgi (or fast-cgi or Apache module) programs in C/C++ but that was insane since a return after a 𝚜𝚝𝚛𝚌𝚙𝚢 is Turing complete in C and there weren't any mitigations for this in the 1990s.

PHP opened the door to cheap web dynamic web hosting and in turn you had self-hosted applications like Wordpress. It was a few years later that languages like Java and C# became really attractive for back end work, you also had Ruby, Node, etc.

I wrote a lot of PHP in the early 2000s because that is were the work was, that’s what you could write open source code that people would use in, and it was really straightforward to build apps (like a social network for a secret society) without an ‘ops’ team watching your every move.

replies(4): >>davesl+Gu >>tyingq+mE >>giantr+gP >>bzzzt+kR2
◧◩
13. mgkims+z6[view] [source] [discussion] 2022-12-08 14:04:05
>>sebste+P4
You must have more than just 'sleep' bothering you. What would you start a project in today?
replies(1): >>sebste+ye
14. porker+J6[view] [source] 2022-12-08 14:05:11
>>user39+(OP)
For the order of function arguments: sounds like you'd enjoy https://github.com/azjezz/psl.

Yes it's a userland workaround and not a fix for the language, but it's thinking about these issues and a PHP extension (offering better performance) is being talked about.

replies(2): >>user39+zb >>zmxz+Rp
◧◩
15. donatj+U7[view] [source] [discussion] 2022-12-08 14:13:23
>>sebste+P4
A little weird, but it was documented.

PHP is nothing if not amazingly well documented. This is more than I can say for a lot of languages I have worked in cough Ruby cough. I work pretty heavily in Go these days and even it’s docs leave me wanting in comparison sometimes.

replies(2): >>apocal+R9 >>sebste+6e
16. bawolf+F8[view] [source] 2022-12-08 14:18:04
>>user39+(OP)
> My biggest gripe at the moment is the (very old) behavior of e.g. preg_match()...

Do you mean how you can have an optional out parameter to get more detail than what the return parameter gives for which group matched?

Personally i dont see anything wrong with that, but to each their own.

◧◩◪
17. apocal+R9[view] [source] [discussion] 2022-12-08 14:24:31
>>donatj+U7
It is well documented but the comments in the documentation are seriously bad most of the time. I really wish they would at least designate the primary release at the time of the comment, if not purge old ones (the comments from 2005 don't often offer much value nearly 20 years later)
◧◩◪◨⬒
18. motogp+Ba[view] [source] [discussion] 2022-12-08 14:29:29
>>mgkims+q6
I think you're putting too much faith in frameworks there. My employer's large PHP application is written in a framework that was once popular but then was abandoned years ago. Since that framework defines every aspect of the application, down to the directory layout, migrating away from it towards a more recent framework is largely impossible at this point. While it's true that the framework is "easy to understand", it's also true that it encases the application like a concrete coffin.

Libraries are infinitely preferable to frameworks if you want your application's life cycle to be independent of $POPULAR_FRAMEWORK's.

Even with Laravel, which is the current thing in the PHP world, I've worked in multiple teams where their application is written in a very old version of Laravel and there's no desire to attempt an upgrade to the most recent version.

replies(2): >>mgkims+Vd >>tored+MV
◧◩
19. user39+zb[view] [source] [discussion] 2022-12-08 14:36:43
>>porker+J6
Yep that's a great library, I'd like to see some of it in core. Same with this: https://github.com/lstrojny/functional-php which overlaps somewhat.

The no-brainers to me are the missing array_some()/array_any() array_every()/array_all() and an array_search() that takes a predicate and iterable. I do these now in userland but an optimized native version would be nice.

◧◩◪◨⬒⬓
20. mgkims+Vd[view] [source] [discussion] 2022-12-08 14:49:59
>>motogp+Ba
Outside of 'frameworks', I've tied projects to specific libraries that also were abandoned, and it's no better. Having every single query/dataaccess go through an abandoned library is not all that much different from an abandoned framework, imo.

For better or worse, there's some degree of 'upkeep' that has to be done with any code, if only to take advantage of some newer tooling (even ignoring security and performance concerns).

> and there's no desire to attempt an upgrade to the most recent version

That seems to be a problem there. I would not want to be using, say, Laravel 4 in 2022. Nor early Symfony, or any other framework (or library) that is years out of date.

What's been interesting to watch in Symfony and Laravel is to see an ecosystem grow around them which amplifies the value of using that framework (laravel shift springs to mind, based on your example above).

The danger seems to be in being complacent, regardless of tool choice. I've had to go back to Java/Spring code I wrote 10 years ago, and it's... challenging to make some things run again.

replies(1): >>johnch+If1
◧◩◪
21. sebste+6e[view] [source] [discussion] 2022-12-08 14:50:53
>>donatj+U7
If documenting was enough band saws would still just have warnings about fingers in their manuals instead of guard rails. "Weird functions" need to have big yellow warnings at the top of their doc with a link to fixed versions of the func
◧◩◪
22. sebste+ye[view] [source] [discussion] 2022-12-08 14:54:18
>>mgkims+z6
When I was using it, I had a novel's worth. Now I mostly forgot my rant

The projects I start today got the php replaced by typescript

◧◩◪
23. lazka+Ie[view] [source] [discussion] 2022-12-08 14:55:01
>>nolok+55
assert() is still broken if it's disabled in php.ini.
replies(2): >>nolok+2V >>hakre+0y6
24. felipe+ah[view] [source] 2022-12-08 15:08:36
>>user39+(OP)
Have you considered that these "detractors" might just be former users of the language themselves, who felt liberated once they tried something else, and want to help other people not feel stuck as well?
replies(2): >>giraff+Pm >>thevag+HI1
◧◩
25. xxpor+ki[view] [source] [discussion] 2022-12-08 15:16:10
>>sebste+P4
Wait, what's wrong with that?
replies(2): >>KMag+rN >>xigoi+c21
26. vanill+jj[view] [source] 2022-12-08 15:20:58
>>user39+(OP)
I feel the same, but for Java.
replies(1): >>cogman+Ak
◧◩
27. cogman+Ak[view] [source] [discussion] 2022-12-08 15:26:58
>>vanill+jj
Yeah, the `InternalFrameInternalFrameTitlePaneInternalFrameTitlePane MaximizeButtonWindowNotFocusedState` jokes get a bit old.

Non-java devs think of java as Java 6 when in reality it has pretty significantly evolved in the last decade. I dare say that it's one of the most rapidly evolving mainstream languages on the market at this point.

replies(1): >>pie_fl+VH
◧◩
28. giraff+Pm[view] [source] [discussion] 2022-12-08 15:37:27
>>felipe+ah
Right but if someone stomped in here talking shit about for example javascript's verbose function notation, poor linting tools, and lack of type checker we'd be like what year are you from? We all got burned by that stuff, we all hated it circa 2016, it's all been addressed now. Javascript still has problems but those aren't it and any conversation about it includes that nuance.

Php is in a very similar situation, the difference is you can't escape javascript so we all to some extent keep up with its developments. People who leave php left it at a certain point and their understanding of its issues is frozen there. It's very predictable and boring honestly.

replies(1): >>xigoi+i11
◧◩
29. zmxz+Rp[view] [source] [discussion] 2022-12-08 15:49:37
>>porker+J6
PHP 8.0.0 introduced named arguments which allow for arbitrary argument order. That was nearly 2 years ago exactly to date.

What does that lib do that PHP doesn't?

replies(1): >>within+1p1
30. pmarre+ru[view] [source] 2022-12-08 16:07:46
>>user39+(OP)
> The worst part about PHP is constantly hearing from its detractors

Does it deterministically pass ALL tests in its own test suite yet? 100% of the time? This was the state just a few years ago, where a lot of tests were simply disabled because they were "flagging". <insert eyeroll emoji> (I'm not even going to touch the Boolean chart showing the different behaviors of single, double, and triple-equals on results. I know a lot of that has been fixed, at least by "convention".)

Nondeterminism is literally the worst trait of a computer language, because it leads to the worst kinds of bugs- the ones that are NOT a result of your lack of understanding of how the code is supposed to work at the PHP level. I've literally burned months away in my career in tracking down bugs like this (in Ruby and other languages), which ended up being framework or language bugs. There comes a point when you say "never again". Unfortunately, it comes too late in most people's careers to realize they've made a mistake, and switching to another language/community becomes too expensive/risky a proposition for them. (In my case I've been fortunate in that I was able to switch from .NET, to Ruby, to Elixir... each one of these was a difficult transition, both intellectually and socially (I really miss the Ruby community!), but in the end, completely justified in my case.)

◧◩◪
31. davesl+Gu[view] [source] [discussion] 2022-12-08 16:08:38
>>PaulHo+x6
This is a refreshingly nice, informed, and balanced perspective.

I've only done PHP for small personal projects and some wordpress hacking, and that was years - so my experience is limited. But it seems to me that one of the great and tragic things to PHP is the low barrier to entry. As you put it: "first open source language in which just anybody could write server-side web applications without terrible management problems for the sysadmin".

This made it extremely easy for anyone in the early 2000s who signed up for a web hosting account on godaddy/hostmonster/hostgater/etc... to fire up a text editor of their choice and start slinging code and FTP'ing up to a server. Didn't have to worry about installing, configuring, all the dependencies, build tools, etc... just edit, upload, refresh -- lather, rinse, repeat until it works. Lowered the barrier to entry, and got a lot of people into the field. Really powerful stuff.

It also made sloppy, hacked-together, copy-pasta code very prevalent. In my limited perspective, I suspect that this prevalence of sloppy spaghetti-code has contributed to PHP's bad reputation. It's not that you can't do good code (totally can!), but a PHP environment can be forgiving of some pretty bad practices.

replies(2): >>osrec+GB >>PaulHo+aD
◧◩
32. msla+dz[view] [source] [discussion] 2022-12-08 16:26:08
>>osrec+E5
> PHP just happens to be good at getting stuff done fast, so it's found all over the place, and thus has a lot of eyeballs on it. The negativity is a byproduct of it's usefulness and staying power - the price of popularity, if you will.

I don't like arguments like these because they're a tu quoque without even bothering to point out flaws in a different thing. It implicitly states that progress is impossible, that all languages will always be as bad, and nothing can ever improve because once a technology is widely-used, design flaws will magically appear. If you really believe that, write your next website backend in FORTRAN IV.

It was lazy argumentation when it was people saying Linux was just as buggy as Windows Me and it's lazy argumentation now.

replies(2): >>osrec+z41 >>antifa+0p2
◧◩◪◨
33. osrec+GB[view] [source] [discussion] 2022-12-08 16:37:11
>>davesl+Gu
The thing is, I've seen sloppy, hacked-together code in finance, in a variety of languages, including Java and C, where the barrier to entry is relatively high, and the language fairly strict. You just don't hear about the coding fiascos, as they're mostly behind closed doors.

PHP has a low barrier to entry, but that's a great thing in my opinion. It's something that should be celebrated, and at the very least, it shouldn't be a criticism!

Bad developers exist in every language, and no language is completely wart-free. People just like to zero in on PHP to criticise it because it's easy, and it bugs me a bit (especially if they're simultaneously singing the praises of another less than perfect language such as JS or Python or Go).

replies(1): >>PaulHo+oE
◧◩◪◨
34. PaulHo+aD[view] [source] [discussion] 2022-12-08 16:43:18
>>davesl+Gu
In my mind the great thing about PHP was packaged application software like PHPNuke, Wordpress, etc. that would let you make a highly capable dynamic site with little or no coding.

At that time you could have made similar software for JSP, ColdFusion or ASP.NET but hosting would have been much more expensive and a big hassle. With PHP it was feasible to offer a $5 a month hosting plan good enough for blogs and simple web application.

I wrote a lot of PHP because it was a great way to deliver products to customers, particularly ones that didn't have a lot of resources for "ops" but also a place where I could write open source software which might really get used and have an impact.

◧◩◪
35. tyingq+mE[view] [source] [discussion] 2022-12-08 16:48:42
>>PaulHo+x6
"First people wrote cgi-bin scripts in Perl, which were not efficient because they forked a process for each request"

I don't recall the sequence of events that way. That is, there was regular cgi, then mod_php with problems similar to mod_perl...then later fastcgi options existed for both.

replies(1): >>torste+IF
◧◩◪◨⬒
36. PaulHo+oE[view] [source] [discussion] 2022-12-08 16:48:44
>>osrec+GB
PHP had the advantage of having built-in resource limits and little contention over locks and other shared resources that meant sloppy coding wouldn't crash your server. Providers could offer low cost hosting plans because you could put a lot of customers on the same server and have very little trouble. It was a big plus that it was open source and didn't have the crazy high license costs of early dynamic web hosting solutions such as ColdFusion, WiTango, Netscape's application server, etc.
◧◩◪◨
37. torste+IF[view] [source] [discussion] 2022-12-08 16:54:46
>>tyingq+mE
Wait. Isn't fastcgi essentially the same as mod_php? IPC with a long-running process rather than forking and capturing stdout?

What's the newer fastcgi php method that isn't mod_php?

replies(2): >>dysarr+WF >>tyingq+jG
◧◩◪◨⬒
38. dysarr+WF[view] [source] [discussion] 2022-12-08 16:56:21
>>torste+IF
FastCGI and mod_php are both ways of running PHP on a web server, but they differ in how they achieve this.

FastCGI is a protocol that allows a web server to communicate with external programs that provide dynamic content, such as PHP scripts. In FastCGI, the web server launches an external program, called a FastCGI process manager, which is responsible for starting and managing a pool of long-running PHP processes. When a request for a PHP script comes in, the FastCGI process manager assigns one of these processes to handle the request, and the process generates the dynamic content and sends it back to the web server.

mod_php, on the other hand, is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that PHP scripts are executed directly within the Apache process, without the need for an external process manager.

While both FastCGI and mod_php are ways of running PHP on a web server, they differ in their implementation and how they handle requests for PHP scripts.

replies(1): >>torste+6N
◧◩◪◨⬒
39. tyingq+jG[view] [source] [discussion] 2022-12-08 16:58:25
>>torste+IF
The mod_* meant apache modules managing the process pool without a socket connection to a separate pool manager. Which meant issues there could affect the webserver, which was typically also serving static assets, etc.
replies(1): >>torste+OJ
◧◩◪
40. pie_fl+VH[view] [source] [discussion] 2022-12-08 17:05:30
>>cogman+Ak
Most Java devs are on Java 8, because of how much Java 9 broke reflection, classloading, etc.
replies(1): >>cogman+BJ
◧◩◪◨
41. cogman+BJ[view] [source] [discussion] 2022-12-08 17:13:47
>>pie_fl+VH
That's something that will likely change pretty rapidly. Springboot 3 is forcing Java 17 which is going to force a lot of conversations once 2 is fully retired. (free support for 2 ends next year)

The Java 8->11 transition was rough but honestly after that we've not really experienced a whole lot of pain. 16 has been a little bit of a pain as well since it closed some more unsafe holes. I think that's the last release, however, that's going to cause major headaches with migrations.

replies(1): >>no_wiz+vT
◧◩◪◨⬒⬓
42. torste+OJ[view] [source] [discussion] 2022-12-08 17:15:04
>>tyingq+jG
You're right, I guess I misremembered how I set my web server up. I'm using mod_proxy_fcgi with php-fpm, not mod_php.
◧◩◪◨⬒⬓
43. torste+6N[view] [source] [discussion] 2022-12-08 17:30:30
>>dysarr+WF
Is there no rule about GPT/bot responses on HN?
replies(1): >>dang+x01
◧◩◪
44. KMag+rN[view] [source] [discussion] 2022-12-08 17:32:20
>>xxpor+ki
There are 2 issues they might be complaining about: (1) cross-platform issues that seem so trivial that documenting them was probably more work than fixing them and (2) high-level language leaking low-level implementation details.

As for the second part, I understand why system calls are interruptible, particularly before the implementation of many syscall-level asynchronous operations. However, too many languages require too much boilerplate in the much, much more common case where the developer wants the appearance of an uninterruptable system call in a multi-threaded and/or multi-actor program.

I've written plenty of interruption-safe sleep and I/O code in C. It's disappointing that same C boilerplate needs to be used in PHP, Java, etc. If you want to expose the interruptiblity of a C sleep(), call it interruptible_sleep(), and make sleep() a wrapper that contains the boilerplate you want 99% of the time in C. I dare say 90+% of programmers don't properly deal with interrupted sleep system calls, and exposing the interruptions should be opt-in.

In retrospect, at the syscall level, the C library interface to interruptible syscalls should take a function pointer to an interruption handler that returns a boolean as to whether the syscall should be transparently resumed. Passing a null handler should result in the syscall appearing uninterruptable to the calling code. Most programmers are blissfully ignorant of interrupted syscalls and are perplexed by seemingly random resultant bugs. The default interface to these calls should protect the programmer.

  // sleep(int sec) should look more like:
  void sleep(int sec) {
    sleep_interruptible(null, sec);
  }

  void sleep_interruptible(bool (*handler)(int), int sec) {
      struct timespec ts = {sec, 0};
      int prev_errno = errno;
      errno = EOK;
      while (nanosleep(&ts, &ts) != 0 && errno == EINTR) {
        if (handler != null && ! handler(errno))
          break;
      }
      errno = prev_errno;
  }
replies(1): >>xxpor+n21
45. evo_9+bP[view] [source] 2022-12-08 17:40:58
>>user39+(OP)
Learn SugarCRM which is built on PHP; SugarCRM devs are rare, in high demand, and very highly paid (I just hired a full remote sr php dev at 145k with full benes/10% starting bonus).

We’re always looking btw.

replies(4): >>boredt+IR >>xkcd19+OR >>skoski+HT >>arunix+5d3
◧◩◪
46. giantr+gP[view] [source] [discussion] 2022-12-08 17:41:21
>>PaulHo+x6
I think the big thing PHP offered was people could easily deploy their project just by copying files to a directory. A link directly to the file got dynamic content. Most shared hosting also put index.php in the default indexes to check for directories. So it was simple to have clean looking links without using a rewrite module.

Deploying to the cgi-bin directory was more convoluted and error prone for end users. Even when you did it right all of your URLs had an "ugly" cgi-bin component.

The easy deployment and cheap shared hosting with their managed MySQL instances really helped boost PHP's usage.

◧◩◪
47. sdiaco+0R[view] [source] [discussion] 2022-12-08 17:50:54
>>zmxz+53
Something that is extremely common in the PHP community, and pretty much absent in any other programming community, is this knee-jerk aversion to the idea of learning another language, and this sort of derision to those who do.

Have you consider that people who learn other programming languages are not doing so in order to claim that they're better than PHP programmers, but for their own intrinsic reasons?

It's such a weird, fragile ego situation. Does everyone else have to pretend that PHP is the only language that exists in order to placate your sense of inferiority?

replies(2): >>zmxz+CW2 >>tored+bQ4
◧◩
48. boredt+IR[view] [source] [discussion] 2022-12-08 17:54:55
>>evo_9+bP
That's lowish to mid $$ for a senior dev (at least in the US).
replies(2): >>tomnip+Ac1 >>evo_9+cK7
◧◩
49. xkcd19+OR[view] [source] [discussion] 2022-12-08 17:55:18
>>evo_9+bP
hi
replies(1): >>user39+Oc2
50. trolli+eS[view] [source] 2022-12-08 17:57:53
>>user39+(OP)
People don’t realise that it powers the majority of sites on the internet. It’s got a bad rep from security flaws in the late 1990s. Things have moved on since then. It does the job.
◧◩◪◨⬒
51. no_wiz+vT[view] [source] [discussion] 2022-12-08 18:04:52
>>cogman+BJ
I think Kotlin will see a nice rise in adoption, as the refactoring seems big enough to warrant moving to a language that embraces certain semantics and remove some magic.

I'm speculating though.

replies(1): >>cogman+b61
◧◩
52. skoski+HT[view] [source] [discussion] 2022-12-08 18:05:42
>>evo_9+bP
Can I work remotely?
◧◩◪◨
53. nolok+2V[view] [source] [discussion] 2022-12-08 18:12:35
>>lazka+Ie
I mean yes php.ini allows you to disable any function you want, and if you do that then this function doesn't work like expected, I can hardly blame php for that.
replies(1): >>hakre+ey6
◧◩◪◨⬒⬓
54. tored+MV[view] [source] [discussion] 2022-12-08 18:16:45
>>motogp+Ba
What you should always do is to write your own code outside of the framework and pass in values or plain class objects from the framework to your code to avoid that the framework taints the entire project. One of the most common polluter is the ORM becuase it often passed to every layer of the application. And it is never too late to start.
55. 36amxn+hY[view] [source] 2022-12-08 18:28:34
>>user39+(OP)
PHP is simply awesome, so much so that I have to make a huge effort to remember that other backend languages even exist.
56. gosuki+oY[view] [source] 2022-12-08 18:29:01
>>user39+(OP)
There are two types of programming languages: Those everyone complains about, and those nobody uses :)
◧◩◪◨⬒⬓⬔
57. dang+x01[view] [source] [discussion] 2022-12-08 18:41:42
>>torste+6N
We don't allow bots on HN and ban such accounts.
replies(1): >>torste+8i1
◧◩◪
58. xigoi+i11[view] [source] [discussion] 2022-12-08 18:45:10
>>giraff+Pm
Since when does PHP not have $?
replies(1): >>nerdbe+D51
◧◩◪
59. xigoi+c21[view] [source] [discussion] 2022-12-08 18:49:08
>>xxpor+ki
Why 192? Why only on Windows?
replies(1): >>xxpor+Vb2
◧◩◪◨
60. xxpor+n21[view] [source] [discussion] 2022-12-08 18:49:57
>>KMag+rN
>I've written plenty of interruption-safe sleep and I/O code in C. It's disappointing that same C boilerplate needs to be used in PHP, Java, etc. If you want to expose the interruptible of a C sleep(), call it interruptible_sleep(), and make sleep() a wrapper that contains the boilerplate you want 99% of the time in C. I dare say 90+% of programmers don't properly deal with interrupted sleep system calls, and exposing the interruptions should be opt-in

I get where you're coming from, I think the way I'd think about it would be a little different. The interruptible part is semi-specific to sleep. I'd want predicable naming for syscalls first and foremost. So something like libc_sleep(). (libc_open(), etc would follow too) This makes is more obvious you're dealing with a pretty raw api. But otherwise agree. I haven't written any PHP in nearly 20 years, so I completely forget: is sleep() pretty typical of how PHP treats these syscalls?

◧◩◪
61. osrec+z41[view] [source] [discussion] 2022-12-08 19:00:01
>>msla+dz
I accept PHP has flaws, as do other languages. But I feel PHP gets an unfair amount of criticism, given that it's "flawed" implementation of a programming language happens to run a big chunk of the web today.

> Progress is impossible

Huh? My very last sentence implies quite the opposite.

◧◩◪◨
62. nerdbe+D51[view] [source] [discussion] 2022-12-08 19:04:41
>>xigoi+i11
What's the problem with '$'?
replies(1): >>xigoi+D71
◧◩◪◨⬒⬓
63. cogman+b61[view] [source] [discussion] 2022-12-08 19:06:37
>>no_wiz+vT
Kotlin, IMO, is experiencing the Ruby on rails effect. It's getting strongly associated with android development which has somewhat stifled general uptake of the language.

Java has been slowly adding the best kotlin features (such as data classes, records) which also makes it a bit harder to sell.

That said, I've introduced kotlin on a few teams and pretty much everyone that's worked with it has complimented it.

◧◩◪◨⬒
64. xigoi+D71[view] [source] [discussion] 2022-12-08 19:12:25
>>nerdbe+D51
For me, it makes code harder to read because my brain can't stop pronouncing it as “s”, so something like `f($x, $y, $z)` reads like “eff sex, swy, szee”. And for writing, requiring a shifted key before every identifier is a lot of pinky strain. Not to mention that it's completely useless noise.
replies(3): >>within+Fo1 >>antifa+pp2 >>dncorn+zoc
◧◩◪
65. tomnip+Ac1[view] [source] [discussion] 2022-12-08 19:36:00
>>boredt+IR
FAANG-level pay is the exception.
replies(1): >>boredt+NL1
◧◩◪◨⬒⬓⬔
66. johnch+If1[view] [source] [discussion] 2022-12-08 19:51:00
>>mgkims+Vd
> Outside of 'frameworks', I've tied projects to specific libraries that also were abandoned, and it's no better. Having every single query/dataaccess go through an abandoned library is not all that much different from an abandoned framework, imo.

Isn't it better to tie projects to specific libraries rather than frameworks because it should be easier to swap/replace a library than the whole framework ?

(Or is that OOP kool-aid I still taste ?)

replies(1): >>mgkims+dp1
◧◩◪◨⬒⬓⬔⧯
67. torste+8i1[view] [source] [discussion] 2022-12-08 20:01:39
>>dang+x01
One ChatGPT reponse to:

> Write an explanation for the user who posted the following comment: "Wait. Isn't fastcgi essentially the same as mod_php? IPC with a long-running process rather than forking and capturing stdout? What's the newer fastcgi php method that isn't mod_php?"

is:

> FastCGI and mod_php are similar in that they both use a long-running process to handle PHP requests, rather than creating a new process for each request. However, they differ in how they are implemented and how they interact with the web server.

FastCGI is a protocol that allows a web server to communicate with external programs, such as PHP, to handle dynamic content. It is typically used with web servers such as Apache or Nginx. In the case of PHP, the web server uses FastCGI to send PHP requests to a PHP-FPM (FastCGI Process Manager) process, which then executes the PHP code and returns the result to the web server. This allows the web server to handle multiple PHP requests simultaneously, improving performance.

On the other hand, mod_php is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that Apache can handle PHP requests itself, without the need for external programs or FastCGI.

◧◩◪◨⬒⬓
68. within+Fo1[view] [source] [discussion] 2022-12-08 20:30:09
>>xigoi+D71
But it lets you do things that are absolutely wild without weird syntax or setting up reflection. $obj->$dynamic_var. Or $$dynamic_obj->$dynamic_fun().

Whether or not you should be doing that is another matter… but it’s useful in some cases and easier to grok than using reflection or using array syntax on an object (like JavaScript).

After awhile, you don’t even notice the $ to be honest.

◧◩◪
69. within+1p1[view] [source] [discussion] 2022-12-08 20:31:33
>>zmxz+Rp
That lib probably makes any seasoned php dev really confused or think everything is backwards and somehow still works.
◧◩◪◨⬒⬓⬔⧯
70. mgkims+dp1[view] [source] [discussion] 2022-12-08 20:33:28
>>johnch+If1
using an ORM "library" was just as problematic, because data access is something that gets fairly deep in to a project. Had we tied the project to, say, symphony, there would have been a better upgrade path (but that brought its own set of challenges). We adopted a few libraries instead of "a full framework" but when the libraries are abandoned... you still have a lot of work to refactor.
replies(1): >>johnch+Di2
◧◩
71. within+Bp1[view] [source] [discussion] 2022-12-08 20:35:40
>>sebste+P4
In my experience, this is a highly useful feature. I’m not sure what you’re complaining about here, but if the server is shutting down, what’s the point in sleeping?
◧◩
72. thevag+HI1[view] [source] [discussion] 2022-12-08 21:56:33
>>felipe+ah
I did php and moved to other languages. I don't feel liberated.

In fact php with composer and tooling is really good these days. Most people I've met (in person) who hate on php can't say why. They tend to equate php with wordpress.

I've picked up their projects and see many problems but I don't go blame the language they chose.

◧◩◪◨
73. boredt+NL1[view] [source] [discussion] 2022-12-08 22:08:50
>>tomnip+Ac1
FAANG level pay is well over $200 for a senior, easy. There's plenty of companies offering senior comp in the 150-200 range that aren't faang.
replies(1): >>tomnip+n03
◧◩◪◨
74. xxpor+Vb2[view] [source] [discussion] 2022-12-09 00:48:06
>>xigoi+c21
Because that's how the underlying syscall works?
◧◩◪
75. user39+Oc2[view] [source] [discussion] 2022-12-09 00:56:33
>>xkcd19+OR
Hello!
◧◩◪◨⬒⬓⬔⧯▣
76. johnch+Di2[view] [source] [discussion] 2022-12-09 01:52:41
>>mgkims+dp1
I believe we are talking about the same thing but I lack the experience of projects big/complicated enough to really grasp the difficulties.
◧◩◪
77. antifa+0p2[view] [source] [discussion] 2022-12-09 02:47:29
>>msla+dz
> It implicitly states that progress is impossible

PHP has made huge strides in progress over the last decade.

◧◩◪◨⬒⬓
78. antifa+pp2[view] [source] [discussion] 2022-12-09 02:49:51
>>xigoi+D71
It must be embrassing when you read outloud "S-S-SWone thousand dollars".
◧◩◪
79. bzzzt+kR2[view] [source] [discussion] 2022-12-09 07:15:02
>>PaulHo+x6
Fact that PHP was built-in on virtually every Linux distribution and hosting was dirt cheap since one server could easily host hundreds of customers helped too I guess. Java and .NET never were after the $5/month hosting market.
◧◩◪◨
80. zmxz+CW2[view] [source] [discussion] 2022-12-09 08:07:41
>>sdiaco+0R
Let's recap: post about PHP, ex-PHP user posts completely false info.

Your reaction: "why do PHP devs get upset when ex-PHP users write false things about the language? Also, none of you know any other languages".

Thanks for the ad-hominem, that concludes this discussion.

Also, plenty of people who use PHP know so many other languages. You don't appear to be a professional in this industry, especially not with this kind of discourse.

Take care.

replies(1): >>sdiaco+hi3
◧◩◪◨⬒
81. tomnip+n03[view] [source] [discussion] 2022-12-09 08:46:38
>>boredt+NL1
Total comp yes, not salary like OP is talking about. Only a handful of companies have total comp that doubles base thanks to RSU and stock, which a vast majority of the worlds ~25MM programmers do not participate in.
replies(1): >>boredt+4A4
◧◩
82. arunix+5d3[view] [source] [discussion] 2022-12-09 10:43:58
>>evo_9+bP
How would you learn it though? It seems to no longer be open source as of 2013(?)
replies(1): >>evo_9+VI7
◧◩◪◨⬒
83. sdiaco+hi3[view] [source] [discussion] 2022-12-09 11:37:27
>>zmxz+CW2
To be clear, I never said that PHP developers don't know any other languages, and I don't believe that is true.

My comment was in response to you asking whether the other user (who as far as I can tell was not posting any false information about PHP, just pointing out that they personally preferred other languages?) wanted _recognition_, from you personally, for having learned some other language.

This is such a weird reaction to have to the idea that someone has learned, and/or would rather use, some other language. I hope you can see that.

Of course, it's not just you. I have never seen any programming language community that feels _threatened_ by the idea of other languages existing and being learned, in the way that the PHP community does.

Fundamentally, this is a learned social behaviour, which means that whether or not individual PHP developers know other languages does not matter. A community that treats acquiring additional knowledge as a _threat_, seeing learning from the outside world as a _betrayal_, will not be able to learn _from_ other languages.

As bringing new ideas and thoughts into the community is socially discouraged, it will only be possible for learning to flow in one direction: away from the PHP community.

replies(1): >>zmxz+cj3
◧◩◪◨⬒⬓
84. zmxz+cj3[view] [source] [discussion] 2022-12-09 11:49:35
>>sdiaco+hi3
> who as far as I can tell was not posting any false information about PHP

I asked what prompted the person to type that kind of reply. Had you read the entire topic, you'd see plenty of false info being posted, but my point remains: you used PHP, you moved on, what prompts you to be active in topic about PHP where all you contribute with is "I moved on."

> This is such a weird reaction to have to the idea that someone has learned, and/or would rather use, some other language. I hope you can see that.

And we're in territory of mental gymnastics now :)

You think the reaction is to learning another language? You're obviously a programmer. Can you tell me how many possible outcomes exist and how come you chose this one in particular?

Reaction was not to learning another language, it's ridiculous.

> I have never seen any programming language community that feels _threatened_

You never read linux mailing list and c vs c++? I can't take you seriously, you talk as if there exists de-facto "community". There isn't one, it's just a bunch of people who use various forums and there's no coherent community. You interacted with several people and you label that community and then you purposely shove words that haven't been written only to challenge them.

It's a straw man argument.

You persist in labeling PHP devs so narrow-minded that they chase away people who learn other languages. I don't know which (human) language I need to use, but it's apparent that this is becoming multiplayer monologue. I write one thing, you claim I wrote something else and then you generalize based on it.

Notice: I haven't tried to provide my "credentials" by listing what languages I know or what I do. I never even stated I'm a PHP dev.

You, on the other hand, labeled me and entire PHP community as weak-ego, tribalists who frown upon other languages and that the PHP community, which apparently you researched somehow, is different to all other communities - which you also apparently researched. In this whole wall of text you wrote, you have't asked a single question. You merely stated something and then you proceeded to take up the higher moral ground and then demean people. Do you think such discourse is productive?

> Fundamentally, this is a learned social behaviour, which means that whether or not individual PHP developers know other languages does not matter. A community that treats acquiring additional knowledge as a _threat_, seeing learning from the outside world as a _betrayal_, will not be able to learn _from_ other languages.

In this very topic, I wrote about features I'd like to see in PHP - one being generics. Something I learned in C# and something that changed my entire stance to JS because of having used in TypeScript.

That's just _one_ example of how you assume without zero facts to go by. I won't bother listing what we do for feature suggestions in PHP, which languages have great features and what we do to bring them in. You're just incapable of reading and you merely recognized me as a "bad guy" because I called someone out. I seriously doubt you'll read this, it would take more than 13 seconds of attention and that's something hard to acquire these days.

TL;DR: nice gaslighting and straw man, thanks for ad-hominem, I wish you well in the new year :)

replies(1): >>sdiaco+qG4
85. yrgula+WV3[view] [source] 2022-12-09 15:54:15
>>user39+(OP)
The biggest issue with php is the developers. Many of whom are totally oblivious to engineering practices and just reinvent the wheel. 1 in 5 still debate setter and getters while the rest still argue over using spaces over tabs. All in all a very toxic culture.
◧◩◪◨⬒⬓
86. boredt+4A4[view] [source] [discussion] 2022-12-09 19:00:30
>>tomnip+n03
Nope, I mean base salary not total comp.
replies(1): >>tomnip+qc5
◧◩◪◨⬒⬓⬔
87. sdiaco+qG4[view] [source] [discussion] 2022-12-09 19:33:43
>>zmxz+cj3
I'm done with replying to this, but just to be clear, none of this is an ad hominem, and a generalization is not a straw man. You should probably look up what those words mean, they're not just magical words you sprinkle on a sentence to win an argument on the internet.

> Had you read the entire topic, you'd see plenty of false info being posted

I've honestly looked through all of the original poster's comments and couldn't find any misinformation. Except for referencing r/lolphp, which is indeed mostly wrong about everything.

> You think the reaction is to learning another language? [...] Can you tell me how many possible outcomes exist and how come you chose this one in particular?

I thought so, although I see now that I was wrong. I still don't understand what else your response, saying "Do you want recognition for learning other languages?" to a comment saying "I no longer use PHP and I have learned other languages that I actually like", was supposed to be reacting to, but I take it that there are other possible interpretations that I'm not grasping here.

> you talk as if there exists de-facto "community". [...] it's just a bunch of people who use various forums and there's no coherent community

Obviously a community as big as the PHP community is always going to be, in turn, fragmented into smaller communities. Symfony is not Laravel is not WordPress. But that doesn't mean that you can't draw generalisations from it, like how you would say "the Python community is scared of big breaking changes". This doesn't mean that every single member of that community is personally scared of big breaking changes. It's a generalisation about the behaviour of a group that doesn't extend into a judgement of each and every one of its members.

> You, on the other hand, labeled me and entire PHP community [...] which apparently you researched somehow

I thought there was no such thing as a PHP community. I described a general vibe that I perceive from a given community, which I have extensively interacted with and been a part of. Unless it doesn't exist, in which case I suppose I haven't.

I then compare it to other communities, which I have also interacted with and been a part of, if they indeed exist. My perception nonetheless may be flawed, and it does not need to apply to you specifically.

> I wrote about features I'd like to see in PHP

It's great that what I said above does not apply to you. Your personal appreciation of other programming languages' features, in turn, does not change what I perceive as the broader community's culturally enforced commitment to willful ignorance.

◧◩◪◨
88. tored+bQ4[view] [source] [discussion] 2022-12-09 20:33:46
>>sdiaco+0R
> extremely common in the PHP community?

If I'm going to guess is that you have interacted with non-professional and/or beginner level PHP programmers, they could feel threatened becuase the only development skill they have is rudimentary PHP and you are asking them to replace that with something much more difficult. I have seen some of it myself, and it has always come down to lack of skill.

And this makes sense why you have encountered this within the larger PHP community, becuase PHP is an easy to learn beginner friendly language that is used by the majority of blog and forum systems, zero setup web frameworks, and all of it can be set into production on almost every server on earth. Thus there are many low skilled PHP developers, probably more than moth other languages.

And this is the lessons, it is important to understand that every community consist of large variety of disparate groups, especially within the PHP community, and it is up to you to learn to distinguish them. Unfortunately many are blind to this when it comes to the PHP community, outsiders may think the work I do professionally is the same as someone setting up blog for the first time, just because we use the same language. It would be same to think that the result of a first grader learning to write is the same thing as Tolkien's writings becuase both are in English.

◧◩◪◨⬒⬓⬔
89. tomnip+qc5[view] [source] [discussion] 2022-12-09 22:56:16
>>boredt+4A4
It's amazing how skewed the HN crowd is on developer comp. You'll find that $140-150k is senior range for a vast majority of the U.S. software engineering market.
replies(1): >>boredt+QTr
◧◩◪◨
90. hakre+0y6[view] [source] [discussion] 2022-12-10 14:07:27
>>lazka+Ie
> assert() is still broken if it's disabled in php.ini.

Care to explain what you mean it's broken if disabled? That it is disabled (noop in runtime) so you're missing it? AFAIK that's the production setting. You should be able to enable it in build/test/ci/development, just how you want it.

replies(1): >>lazka+sT7
◧◩◪◨⬒
91. hakre+ey6[view] [source] [discussion] 2022-12-10 14:08:50
>>nolok+2V
Yes, that's fully true, but does specifically assert() falls into that category?
◧◩◪
92. evo_9+VI7[view] [source] [discussion] 2022-12-10 21:52:29
>>arunix+5d3
SugarCRM provides online training but it's not public.

How we train our dev's is to use those courses and to have our current PHP/Sugar dev mentor them on the differences.

◧◩◪
93. evo_9+cK7[view] [source] [discussion] 2022-12-10 22:00:13
>>boredt+IR
Can you share a FAAANG job ad for a PHP guy - fully remote - at $200k or more? I'm genuinely curious if that is a thing.

Or even which of those companies even hire PHP devs anymore?

◧◩◪◨⬒
94. lazka+sT7[view] [source] [discussion] 2022-12-10 22:52:30
>>hakre+0y6
Sure. (1) it is a global setting so I can't decide if I want it on a per application basis, with Docker that is less of an issue though (2) it is disabled by default, so hardly anyone uses it from what I see (3) I'd like to have it always enabled, also in production, so my code doesn't end up in states that I didn't expect and I get notified.

But that might just be me and/or my particular use case.

◧◩◪◨⬒⬓
95. dncorn+zoc[view] [source] [discussion] 2022-12-12 14:51:00
>>xigoi+D71
Life is too short to care about stuff like this. It's like saying you don't like the color blue.
replies(1): >>xigoi+Myc
◧◩◪◨⬒⬓⬔
96. xigoi+Myc[view] [source] [discussion] 2022-12-12 15:40:51
>>dncorn+zoc
Carpal tunnel syndrome is nothing to take lightly.
◧◩◪◨⬒⬓⬔⧯
97. boredt+QTr[view] [source] [discussion] 2022-12-16 14:27:20
>>tomnip+qc5
Now you're just moving goalposts. 140k is not "very high" pay for a senior software engineer anywhere in the US.
[go to top]