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

25 Years of PHP

jetbrains.com

Post reply on HN
Print view View original

421–426 of 426 posts

Re: 25 Years of PHP

#421

Post by cutler »

ChrisMarshallNY wrote: post #404
cutler wrote: post #379

Earlier quoted context omitted.

I never got the "write-only" criticism. If you understand a language thoroughly code is always readable. What's with the insane double param naming? And why do I have to escape and opening paren? No other language requires this.

It’s designed to allow functions to have “two faces.” One face is the one presented to the caller, and the other to the function, itself. The idea is to maximize grokability. The function’s purpose and argument list is clear to the caller. It’s an attempt at that old “philosophers’ stone” of “self-documentation.” Almost all the code I encounter has little to no method interface documentation. This is supposed to addr…

The fact that most devs use _ to work around it surely suggests that it was a pointless idea in the first place. Of all the barmy ideas to make a programming language unique this surely tops the list. As for escaped opening brackets you have to ask why no other language found this necessary. Is the Swift parser really so dumb? These 2 language features prove that however clever a language creator may be he/she can end-up producing features which are frankly absurd.

Re: 25 Years of PHP

#422

Post by wlll »

simion314 wrote: post #420
wlll wrote: post #375

Earlier quoted context omitted.

There are edge cases in many languages, there are more in PHP. It would be better to not have the edge cases than to have an IDE that tried to pretect you from them.

I agree with you in most part, just it seems you imply PHP is the worse, I assume you mean is worse then Go,Python ,JS etc. As I said earlier if PHP If you disagree I am curious of a really example of something that is super hard to do in PHP compared to Python/Ruby/Go , some real world thing. I am aware of the weak points of PHP but I think you can do your job with it, the language is not dragging you down.

I absolutely believe that PHP is worse than many, if not most, other langauges. I have programmed (in a non-trival way) close to 10 programming languages (and fiddled with more) over more than 20 years. Of all those, there are only two that I hate, PHP and Javascript.

PHP (and to a lesser extent JS) are the only languages (that I have experience of) that it seems actively work against the developer writing bug free programs.

Tools reach a point where they can be considered to be dull, and they're not dull before that. PHP in my experience and opinion has crossed that boundary.

> it does not mean PHP is a dull tool and not suitable for some projects.

I think it depends. Should you use PHP for small stuff? one-off's that you run on your home network? I mean, you could, right? No-one's going to access it other than you, so you don't have to worry about user supplied data. But should you use it for Internet facing stuff? Shopping carts, user data? The difficulty is going to be ensuring that you've not coded bugs or security problems into your code, so I would say the answer there is no. I looked, there's been a study (there might be more than one, this was the first result) that has found that PHP is more prone to defects than a lot of other languages (beaten only by c and c++): https://www.i-programmer.info/news/98-languages/11184-which-...

The interesting quote:

"The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits."

This is my experience both writing PHP (lead developer for over a year on a 300k line plus app), and reading it. PHP is hard to write well.

So if you have decided it's not for you with the big projects, why bother with the small ones? They might after all become big projects, but even it they don't, the other languages aren't really that hard. I wrote a Go program yesterday that reads temp and humidity off an i2c bus connected sensor on a Raspberry Pi and writes the data to an influx DB. It is less than 100 lines. It can run from systemd, it uses threads, it's damn fast, and it was even easier to deploy than PHP necause it's just a binary.

It's also far far less likely to have bugs in it.

> If you disagree I am curious of a really example of something that is super hard to do in PHP compared to Python/Ruby/Go , some real world thing. I am aware of the weak points of PHP but I think you can do your job with it, the language is not dragging you down.

You can pretty much do anything in PHP that you can in other languages, it's turing complete after all, but then again, so is the sendmail configuration language.

The issue with PHP is that it makes the task of writing bug free software so so hard.

Re: 25 Years of PHP

#423

Post by ChrisMarshallNY »

cutler wrote: post #421
ChrisMarshallNY wrote: post #404

Earlier quoted context omitted.

It’s designed to allow functions to have “two faces.” One face is the one presented to the caller, and the other to the function, itself. The idea is to maximize grokability. The function’s purpose and argument list is clear to the caller. It’s an attempt at that old “philosophers’ stone” of “self-documentation.” Almost all the code I encounter has little to no method interface documentation. This is supposed to addr…

The fact that most devs use _ to work around it surely suggests that it was a pointless idea in the first place. Of all the barmy ideas to make a programming language unique this surely tops the list. As for escaped opening brackets you have to ask why no other language found this necessary. Is the Swift parser really so dumb? These 2 language features prove that however clever a language creator may be he/she can en…

Not “most.” Just “many.” I do feel that "most" Swift programmers try to stay within the philosophy; even if only by rote.

I tend to eschew argument labels for the first argument; relying on the function name to provide context. That's a pattern that Apple also uses, and comes from ObjC, which came from Smalltalk, so Swift is actually informed by Smalltalk; a venerable OO language.

I’m sure that you can do amazing stuff in Perl, and I apologize for my "write-only" crack. It was not conducive to the conversation (which was about PHP). One of the reasons that I don’t use it, is that I guess I never got good enough with it to really sing.

The best tools can be misused.

Ever see a great musician play a beat-up old Univox, and sound like a chorus of angels, then someone buys a PRS, and sounds like a cat being tortured?

We can get hung up on the tools, and forget that the tool is secondary to skill and experience.

Well, toe-MAY-toe/toe-MAH-toe. No matter. I’ll keep programming in Swift, and limp along.

Re: 25 Years of PHP

#424

Post by jbboehr »

BiteCode_dev wrote: post #391
jbboehr wrote: post #358

Earlier quoted context omitted.

php-fpm uses a worker pool. How is this true unless you corrupt the shared memory segment?

I haven't checked it, but I think the worker stays up, and deal with several requests during its life time, not just one then die. Hence, there is pesistence.

As long as there is nothing broken in internals (a very big if, to be fair), user code crashing will not affect subsequent requests.

Re: 25 Years of PHP

#425

Post by atgreen »

Minor49er wrote: post #364
atgreen wrote: post #108

I first met Rasmus during my pre-internet BBS days in Toronto, and reached out to him shortly after moving to the Bay Area in '95 when he told me about his pet "Personal Home Page" project. What an amazing trajectory!

Very cool. How did you cross paths?

He was just another dude on the Zooid BBS, which I dialed up on my 300 baud modem. https://en.wikipedia.org/wiki/Zooid_BBS

Re: 25 Years of PHP

#426

Post by pak9rabid »

watermelon0 wrote: post #219
pak9rabid wrote: post #182

Earlier quoted context omitted.

What's wrong with using session variables for maintaining state?

Session variables are tied to user sessions (like name suggests), so they cannot be used to persist application state (e.g. cached content, compiled templates, metrics, etc.)

Ah, derp. Yeah you're right.
Post reply on HN