These are things in PHP which make me sad • Hacker News Board

Re: These are things in PHP which make me sad

#141

Post by eli » Fri, May 27, 2011, 8:59 PM UTC

randallsquared wrote: post #132

generalk wrote: post #64

Earlier quoted context omitted.

> It's WAY more useful than "Illegal operation" or "Syntax error". Wut. "Syntax error on line 14" -- Okay, time to look at line 14 for a mistyped semicolon or something. These two words Mean Something. "Unexpected T_PAAMAYIM_NEKUDOTAYIM on line 14" -- means absolutely nothing unless you've already looked it up. It's essentially easily-googleable nonsense. It might as well say "Error 0x444F808E". You can google that,…

You would prefer, when encountering an incorrectly used double colon operator, PHP said "Syntax error"? Even when I'm directed to look only at the surrounds of the double colon, it has been difficult to understand the problem in some cases... it looks like valid syntax. Now, you might say that this is a problem with PHP's syntax, and I have no defense against that, but rolling this into "invalid syntax" with no furth…

Uh, how about "Double colon error" ?

Re: These are things in PHP which make me sad

#142

Post by jalpino » Fri, May 27, 2011, 9:01 PM UTC

PaulHoule wrote: post #91

rmason wrote: post #89

Earlier quoted context omitted.

I am getting a 404 with the link right now. Railo is a JBOSS project that is an open source version of CFML. Here's what they say about Railo in comparison to PHP: • Simplicity More powerful tags for simple file, email, database and other common operations. • Best Practices Support If you want to build OO apps using TDD, you can do so. If not, you can still hack out working scripts in minutes. • Frameworks A wide ran…

you've got to be kidding; PHP is a better Cold Fusion than Cold Fusion ever was

Haha! Having developed with both languages I can honestly say that Coldfusion (one word) simplifies 90+% of the tasks that you would need to use on a regular basis. Is PHP more feature rich, perhaps, but you're not land locked with CF. It allows you to delegate to any other jvm runnable language(in the same execution context, ie. Pass variables between) if need be.

You (and others) should give it a try, you will be pleasantly surprised by its simplicity.

Re: These are things in PHP which make me sad

#143

Post by MostAwesomeDude » Fri, May 27, 2011, 9:12 PM UTC

dexen wrote: post #39

MostAwesomeDude wrote: post #17

What makes me sad is that people will defend this horrible language to the death, regardless of how many problems there are with it. I don't get it; we know how bad PHP is, so why do people fight so hard? Oh, and to demonstrate: "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." This true statement, composed of three observations about deficiencies in the langua…

> "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." ... gets me flamed every time I mention it. Why? perhaps because statement of of fact (``PHP has pluggable Unicode support'') beats wrong statement of oppinion (``PHP is bad because has no support for it''). It's borderline trolling to insist PHP does not, when people have been using it successfully in product…

I knew you were going to point out mbstring. I am talking about an actual Unicode string type. I am talking about using regular string functions on Unicode strings without caring whether or not they contain characters not in ASCII or Latin-1. I expect you'll next talk about how the function overloading "feature" is the correct thing to do, and you'll conveniently ignore how the documentation recommends against it and warns of undefined behavior.

Here's a fun question: How do you strtok(), implode(), or explode() mbstrings?

Re: These are things in PHP which make me sad

#144

Post by wvenable » Fri, May 27, 2011, 9:16 PM UTC

simonw wrote: post #138

wvenable wrote: post #80

Earlier quoted context omitted.

> public/protected/private is a dumb idea in dynamic languages. PHP is mostly a static language; it has more in common with Java than with say Ruby. > prefix it with an underscore Oh god, really. Next you'll be telling us we don't need namespaces, we can just use an underscore as a separator! > and say "the results are undefined if you call methods that start with an underscore". Done. Easier to maintain, easier to t…

"PHP is mostly a static language; it has more in common with Java than with say Ruby." Can you expand on that point a bit? I see PHP as far more similar to Ruby than Java when it comes to dynamic vs static.

A few things about PHP, Java, and Ruby: PHP, Java, and Ruby are all compiled to byte code before executed. Java and Ruby are strongly typed languages. PHP and Ruby are dynamically typed languages (no explicit variable declarations). Ruby and PHP are compiled when run but Java is compiled ahead of time.

But significant to my point: Ruby classes are created at runtime but PHP and Java classes are created at compile time. This is why you can't, with runtime code, alter the structure of a class in PHP or Java.

Re: These are things in PHP which make me sad

#145

Post by wvenable » Fri, May 27, 2011, 9:22 PM UTC

unfletch wrote: post #129

jwatzman wrote: post #102

My favorite PHP design misfeature: what does the following code do? The "&" is a foreach-by-reference, for those not familiar with the language. When you think you've figured it out, you can execute the code at http://www.contrib.andrew.cmu.edu/~jwatzman/foreach.php

I filed that bug 7 years ago and they wouldn't fix it: http://bugs.php.net/29992 I had it a little wrong in the initial report, but it was cleared up in the comments. The reluctance to fix stuff like this because "people might use this for some weird reason" is one of the reasons I'm glad I don't write much PHP anymore.

It's not a bug though, it's how references work. The code is exactly right. You might not expect the output but that doesn't mean it's logically incorrect.

Re: These are things in PHP which make me sad

#146

Post by samdalton » Fri, May 27, 2011, 9:40 PM UTC

steve-howard wrote: post #134

larrik wrote: post #28

What makes ME sad is no keyword arguments. Helper/wrapper functions either get an annoying and difficult-to-grok-at-glance associative-array for it's params (bad), or a huge list of rarely-used parameters (worse), or a huge set of wrapper functions to set their own paramters (even worse), or outright duplicated functions for similar-but-not-quite tasks (worst). This happens to me while producing something like a jqGr…

You can use the @ symbol to suppress errors when you're aware that the variable may be empty and you've considered the possible effects. When I used to write PHP, I'd often write something like do_something(@$_GET['foobar']); There are ways to suppress PHP notices without just turning off the E_NOTICE output.

It shouldn't be ok to write code that is known to throw an error, and handle it by suppressing that error. Silently failing code is just a bug waiting to happen.

It's also making the interpreter do unnecessary error handling work when a simple "if ($_GET['foobar'])" would suffice.

Re: These are things in PHP which make me sad

#147

Post by PaulHoule » Fri, May 27, 2011, 9:40 PM UTC

rmason wrote: post #105

PaulHoule wrote: post #91

Earlier quoted context omitted.

you've got to be kidding; PHP is a better Cold Fusion than Cold Fusion ever was

I need more than a simple fan boy boast. Download it first and then tell me why.

I've done my time in Cold Fusion hell, I know what I need to know.

Perhaps I've got a negative attitude about the intelligence of developers because I've been a maintenance programmer for too long. I've seen so many apps that almost work in ColdFusion because some guy didn't know if he was using a session scope or an application scope or request variable in CF.

I worked at a place where there was a ColdFusionMafia that existed just to bamboozle management into shelling out $8000 for server licenses. They'd go blah blah blah about how Cold Fusion was a great force multiplier but most of them couldn't code their way out of a paper bag they just knew a bunch of tricks that almost worked but couldn't be bothered to get HTML and SQL escaping right.

To be fair you can write pretty decent code in CF if you know how to code but if you knew how to code why would you be coding in CF?

The ColdFusionMafia ultimately got the organization to spend upwards of $500k worth of software licenses and people's time to implement a commercial CMS product that was ultimately abandoned. They pulled me off a project that was really worthwhile and it ended up in a project failure that caused my whole group and everybody above it all the way to the top of the organization to get fired.

Some recruiter called me the other day wanting to know if I want to code ColdFusion in Ohio and I'm like I'd rather be shuffling punched cards....

Re: These are things in PHP which make me sad

#148

Post by dexen » Fri, May 27, 2011, 9:43 PM UTC

MostAwesomeDude wrote: post #143

dexen wrote: post #39

Earlier quoted context omitted.

> "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." ... gets me flamed every time I mention it. Why? perhaps because statement of of fact (``PHP has pluggable Unicode support'') beats wrong statement of oppinion (``PHP is bad because has no support for it''). It's borderline trolling to insist PHP does not, when people have been using it successfully in product…

I knew you were going to point out mbstring. I am talking about an actual Unicode string type. I am talking about using regular string functions on Unicode strings without caring whether or not they contain characters not in ASCII or Latin-1. I expect you'll next talk about how the function overloading "feature" is the correct thing to do, and you'll conveniently ignore how the documentation recommends against it and…

For background:

- I've seen the Python (2.x) way (separate `unicode' and `str' type and no way to set own conversion defaults per whole process -_-') and found it unwieldy. Lotsa boilerplate to keep around I/O.

- I've seen the GNU way (messy pile depending on LC_* environment vars and files in /usr/, with hierarchy of precedence) and disliked it.

- I've seen the Plan 9 way (char * / char[] for UTF-8 and Rune * / Rune[] for UTF-32) and it fits me. I see and use (non-PHP) software built on that, works reliably. I'm happy :)

implode() and explode() work with UTF-8. I hope you know the techicalities of why -- UTF-8's been designed that way and the functions take complete string as the glue/separator. No idea about about UTF-7, -16 or -32 (nor the April Fool's -18 and -36); guess some of those would break terribly. I don't care at this moment. My sites run polish, english, russian and in near future czech language based on UTF-8.

Your point is just strtok(). You are right. I lost. PHP lost. Have a nice day -- and kudos for bringing up that cool function :-)

EDIT: now that I think about it, it seems I've abused explode() for that job -- the output array, with empty strings removed, is equivalent of calling strtok() repeatedly till it returns FALSE. Seems a bit brute-force-ish.

AS for that warning against, and undefined behavior, I'll assume you're refering to the following passage:

  It is not recommended to use the function overloading option in the per-directory context, because it's not confirmed yet to be stable enough in a production environment and may lead to undefined behaviour.

Reading comprehension: don't re-configure it per directory (in this case, of your project, not whole server). Having that minded, you get reliable site.

Re: These are things in PHP which make me sad

#149

Post by unfletch » Fri, May 27, 2011, 9:48 PM UTC

wvenable wrote: post #145

unfletch wrote: post #129

Earlier quoted context omitted.

I filed that bug 7 years ago and they wouldn't fix it: http://bugs.php.net/29992 I had it a little wrong in the initial report, but it was cleared up in the comments. The reluctance to fix stuff like this because "people might use this for some weird reason" is one of the reasons I'm glad I don't write much PHP anymore.

It's not a bug though, it's how references work. The code is exactly right. You might not expect the output but that doesn't mean it's logically incorrect.

Yeah, I understand the cause. Just because those steps make logical sense doesn't mean it's not a bug.

My real point was about the WONTFIX tendencies of the PHP dev team at the time (I've been gone a while; maybe it's better now). It's absolutely the thing I miss least about that community. I mean, when I filed that bug PHP 5 -- the first version to support foreach with references -- was less than 2 months old. The "people might be relying on it" argument doesn't hold much weight with me today, but it certainly didn't hold any for a 2-month-old feature.

Re: These are things in PHP which make me sad

#150

Post by rjh29 » Fri, May 27, 2011, 9:49 PM UTC

tzs wrote: post #38

gergles wrote: post #20

Earlier quoted context omitted.

Wow, a downvote within 30 seconds of posting? "php" == 0 returns true, and this makes sense how?

It makes sense for the same reason it makes sense in Perl: use a string as a number and you get the number that is at the start of the string. E.g., "12" == 12, and "12php" == 12.

Perl recognises that it is a bad practice.

  perl -we ' print "true\n" if "12" == "12php"'
  Argument "12php" isn't numeric in numeric eq (==) at -e line 1.
  true

  perl -w -e 'my $foo = "12php"; $foo = $foo + 1; print $foo, "\n";'
  Argument "12php" isn't numeric in addition (+) at -e line 1.
  13

(an exception seems to be made for $foo++ though... that's Perl for you).