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

These are things in PHP which make me sad

phpsadness.com

Post reply on HN
Print view View original

71–80 of 217 posts

Re: These are things in PHP which make me sad

#71

Post by code_duck »

user24 wrote: post #46
thinkcomp wrote: post #6

I've definitely run into #1 on the list. "Paamayim Nekudotayim" is a transliterated version of פעמיים נקודתיים‎, which means "double colon" in Hebrew. Zeev and Andi are Israeli, which kind of explains it, but the error message is still pretty useless.

> the error message is still pretty useless. not at all. A google search for "Paamayim Nekudotayim" gives you thousands of pages relating to exactly the error you're experiencing. It's WAY more useful than "Illegal operation" or "Syntax error".

Right, because there are thousands of people going to ask on mailing lists WTF that means. Given the small fraction of developers worldwide who speak Yiddish or Hebrew or whatever, 'double colon' might be a better phrase to use.

Re: These are things in PHP which make me sad

#72

Post by generalk »

rudiger wrote: post #35
qeorge wrote: post #22

Earlier quoted context omitted.

Its only a "bug" because there's an unspoken rule that all programming languages should be written in English, and English doesn't have a proper word for this symbol. Pretend that English had no representation of an ellipsis, but Hebrew did. Should the language author say "Expected: dot-dot-dot" in the error message to appease native English speakers, or should (s)he use the unambiguous form?

In this case, the Hebrew word literally is T_DOUBLE_COLON, so not much is gained by its use. Perhaps reporting an "unexpected scope resolution operator" error would be better.

Or, even better:

"Unexpected '::' on line 14."

I wouldn't want to see "Unexpected key/value delimiter" (=>) or "Unexpected opening of new scope" ({). Just show the character(s) you found you weren't expecting.

Re: These are things in PHP which make me sad

#73

Post by encoderer »

jerf wrote: post #68
encoderer wrote: post #58

Earlier quoted context omitted.

Are you serious? You can't figure out why this is? Seems logical to me. These defenders are presumably professional PHP developers. They're presumably supporting their families by coding PHP. The more widely-spread the language is, the more it's used for new projects, the more lucrative and interesting their work will be. And here you are, making a fuss, and many of these people may know ONLY PHP. And you're trying t…

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.

Re: These are things in PHP which make me sad

#74

Post by code_duck »

gburt wrote: post #2

This is by far my (least?) favorite: http://ca.php.net/empty ----- The following things are considered to be empty: - "" (an empty string) - [...] --> "0" (0 as a string) - [...] - var $var; (a variable declared, but without a value in a class) ----- Why the heck is "0" considered empty?

You should check out JavaScript - the type coercion is similar but even worse.

Re: These are things in PHP which make me sad

#75

Post by code_duck »

BruceForth wrote: post #50

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.

Re: These are things in PHP which make me sad

#77

Post by PaulHoule »

samfoo wrote: post #59
PaulHoule wrote: post #31

Earlier quoted context omitted.

in statically typed languages like Java, C#, Scala and C++ people are always screwing this up most languages have some screwed-uppedness about collections, both intrinsic to the language and that gets introduced by people who make APIs that aren't well designed. for instance, arrays and Lists are often not quite perfectly uniform (and it's often a thoughtless arbitrary choice if people decide to return you one or the…

How does scala make this more confusing? Either the types that are returned are scala collections, or they're java collections. If you want to treat java collections like scala collections you can always `import JavaConversions._` and huzzah, shallow conversions and collection uniformity. Finally, if something has the possibility of being null, you can use the option construct, e.g. if (Option(someListThatMightBeNull…

Option[X] is a crock. It's forcing you to write same bulky if-statements that you need to write for null checks.

I want something like NOT NULL in SQL. Can't static typing make it completely impossible that I'll get a null in a situation where it should be completely impossible?

For instance if something is typed as a collection, I'd like to never see null, I'd rather always get an empty collection. If I have to test for None, I'm just adding more bulky code where errors can hide, particularly when the type inference system in Scala is always doing strange things behind my back.

In my mind, automatic conversions make the problem worse in Scala, not better. Code "just works" for the programmer in certain situations no matter how inconsistent people are in the types they use.

The trouble I see is that Scala programmers seem to be pretty random if they're going return an Array, a java.util.List or a scala.util.List. This is really a pain in the ass when I'm trying to access some Scala objects from Java and I don't have automatic conversion available. I'm also sure that these different choices have all kinds of effects when you consider inheritance, variance, type inference and all that. It adds to the problem of spooky action at a distance in Scala.

Re: These are things in PHP which make me sad

#78

Post by dexen »

EamonLeonard wrote: post #70

PHP is Open Source. Compiling a list like this is nice, but contributing something back, and getting involved in making improvements to PHP, would be nicer.

There's an outstanding request for better array syntax. It's been out there for over 3 years and received a lot of support from the community. At least one implementation has been submitted. But the core dev team rejected the idea, as they are convinced having second syntax available would harm ease of use (and thus popularity) of the language.

In general, some aspects of PHP will not be fixed/improved for reasons of either:

* backward compatibility, or

* incompatibility with the vision of the language by the core dev team.

http://marc.info/?t=121142259100001&r=1&w=2 http://marc.info/?t=119995974300003&r=1&w=2

Re: These are things in PHP which make me sad

#79

Post by stevep98 »

For an illustration how PHP is 'different' from other languages, consider 'implode':

implode — Join array elements with a string

string implode ( string $glue , array $pieces )

Note:

implode() can, for historical reasons, accept its parameters in either order.

WTF! What other library has a major function which doesn't care about the parameter order? It goes against every notion of good design.

http://us.php.net/manual/en/function.implode.php

Re: These are things in PHP which make me sad

#80

Post by wvenable »

jrockway wrote: post #60
pornel wrote: post #16

There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation. Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!

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.

> 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 test, less code to type in.

Or you could just build that all into the language itself so it's self documenting and provides a nice concise error message when used incorrectly!

I'm amazed that people would argue for naming conventions over actual features. Hell, nobody is saying you have have to use it; if you'd rather use underscores the languages will let you.

Post reply on HN