Live data from Hacker News

These are things in PHP which make me sad

phpsadness.com

161–170 of 217 posts

Re: These are things in PHP which make me sad

#161
post #68

Earlier quoted context omitted.

I fight against technologies I perceive as bad choices in an attempt to convince younger developers with less of an experience base that they should pick up something else that will give them the same or better capabilities for much less pain. My contribution to the community, as it were, as I have in turn benefited in my career from such signposting. You can carve out a decent subset of PHP, but there's this painful…

And you know, none of that offends me. But to act incredulous that professionals who have spent thousands of hours mastering a skillset might actually defend it publicly seems naive.

The implication is that anyone who has spent thousands of hours mastering PHP should be well aware of its bad points, and can only contend that its "good enough for the job".

Re: These are things in PHP which make me sad

#162
post #140

Earlier quoted context omitted.

public/protected/private is a dumb idea in dynamic languages. If you don't want someone calling your method, prefix it with an underscore and say "the results are undefined if you call methods that start with an underscore". Done. Easier to maintain, easier to test, less code to type in. Come to think of it... public/protected/private is a dumb idea in C++ and Java, too.

Recently at my company we're writing a lot of JS and its' lack of "public/protected/private" doesn't make it easier to maintain or test. Actually, it's quite frustrating because you know you can't test it properly - everything public? it's a ticking timebomb, someone at some point will simply override your method somewhere and hell will broke loose

I wrote a simple library based off of Crockford's writings to make creating reusable constructor functions that supported public/protected/private simple (and without resorting to silly "if it's preceded with an underscore don't touch it!" business). It was written mainly with Node.js in mind, but you could strip out the CommonJS package stuff and use it that way.

https://github.com/zoips/Gizmo

Re: These are things in PHP which make me sad

#163

things about php that make me sad: 1. it exists 2. it's used 3. many of its users make more money than me 4. it has poisoned the market, clients have learned to expect and even demand php-braindeath

I can't even imagine how many developers out there started with WordPress and think the ramshackle way it's put together is normal.

Probably the same type of developer that assumes WordPress is an example of professional PHP code.

Re: These are things in PHP which make me sad

#164

Earlier quoted context omitted.

I've been programming in PHP for a long time and I've never ever accidentally used an octal anywhere. Does such a non-problem really need this much attention?

Perhaps you ask a user to enter the month of their CC expiration date, which is shown as 08/14 on their card. $v = validated_integer($user_input); // the user input 08 if($v == 0 || $v === 0) { // let's just be safe // the Wrong Thing happens } This is a contrived example, sure. But you've never checked to see if a user input the number 0? Or a non-zero, positive integer?

That's not a PHP issue. It's a programmer issue. Validate the bloody input properly! e.g if someone types in a phone number with hyphens or a credit card number which may contain spaces, don't blindly check it for a number...

Re: These are things in PHP which make me sad

#166
post #69

Earlier quoted context omitted.

You don't get it. In my mind the important thing about "blub" is that there's a valuable feature a language has and the blubbers don't understand the valuable feature. For instance, ALGOL-type languages use Chomsky's generative grammar to define a syntax that people find intuitive. LISP is blub because it rejects this major innovation. Languages that are !PHP are blub because they don't recognize that "ease of instal…

Everybody understands PHP's ease of already-existing-installation is just about the only thing keeping it going. The idea that this is news is a strawman, I've seen this discussed for years and years. The thing that makes it win though is not that PHP is intrinsically that much easier to install or run, what makes it win is that it comes pre-installed on most hosts. That's not a problem a language community can solve…

But, it didn't used to come pre-installed. On many hosts in the 1996-1998 range, Perl was the default, and sometimes only, option for dynamic apps. But typically you had to only put files in /cgi-bin, futz with permissions, remember to include content-headers, etc. PHP 'won' because it was genuinely more straightforward than the competition in most use cases.

Re: These are things in PHP which make me sad

#167
post #160
post #140

Earlier quoted context omitted.

Recently at my company we're writing a lot of JS and its' lack of "public/protected/private" doesn't make it easier to maintain or test. Actually, it's quite frustrating because you know you can't test it properly - everything public? it's a ticking timebomb, someone at some point will simply override your method somewhere and hell will broke loose

Even though JS doesn't have language constructs for public/private, there are a number of different ways to write modules with hidden members by use of closures. Crockford explains with some examples here: http://javascript.crockford.com/private.html

I'd say that using closures and functions to create public apis with internal private structure does qualify it to have 'language constructs for public/private'.

It just took programmers collectively over 10 years to figure it out. I blame the 'new' keyword in JS, it feels completely grafted on after the fact.

Lua has been using this method of designing modular programs for years.

Re: These are things in PHP which make me sad

#170

Earlier quoted context omitted.

a total idiot can install PHP and get a system that will meet the performance and reliability needs of 99.5 of web sites out there. This is like living in a house where the builders were "total idiots" and hammered in all the screws with a hammer instead of screwing them in with a screwdriver. Sure, it holds together. It might not even collapse in a light breeze. But one day, you'll want to reshingle the roof, or the…

Also, the days of PHP's deployment superiority are nearly over. So I've been hearing since 2000 or so, when I chose RXML/Pike over PHP because PHP was a complete mess. PHP has gotten considerably better since then; now it's only painfully messy, rather than unusable. Sometimes it seems like every competitor has been busy building castles in the sky full of magic and wonder -- as long as you want to do exactly what th…

> Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server.

I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends.

The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defaults to 1000 I believe), after a backend has served that many requests the process is recycled (an expensive and non-ideal operation on high load applications).

If you do a look around on Google you'll find this behaviour ships with PHP because of 'known memory leaks'. Rather than fix memory leaks the authors have opted to restart on an arbitrary number of requests. Does this sound like good design to you?

You think there's no application server because you've likely never worked on anything substantial enough to notice the silly string holding the whole mess together.

Post reply on HN