
These are things in PHP which make me sad - johnkary
http://www.phpsadness.com/
======
larrik
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 jqGrid, or other
javascript/html hybrid stuff that need a few extra options sometimes.

Django/Python? No problem! Just use the keywords you need.

(More Info: The difference between a single associative param standing in for
keywords arguments, or a huge list of regular arguments is a choice in
complexity/readability IN the function vs. calling it.

For the single dictionary approach, you lost the built-in parameter defaults
nicety, which means you need to handle the case of a missing parameter
manually. This kind of sucks, especially if you hate seeing PHP Notices during
development (which kill JSON/XML output anyway). This makes your function
often twice as big (or more) than it needs to be.

For the other approach, you wind up with calling

    
    
      foo("","","","real value", true, true, 2, false, false, "option I want");*
    

which just about invites all sorts of hard-to-find bugs, and you have to look
at the function definition every time you want to change an option. Also, it's
flat-out rude if you aren't the one calling the function.)

~~~
steve-howard
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.

~~~
samdalton
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.

~~~
philjackson
It should be ok (the poor PHP implementation aside). Auto-vivification is
something that's very useful in Perl and I miss it greatly in the languages I
program in now. Being able to do this:

    
    
        $one->{ two }->{ three } = [ $four ]
    

Without having to check every link for definedness makes for cleaner code,
IMO. Making it optional "suppressing that error" would be a good middle-
ground.

Coffeescipt has the existential operator, not quite on a par with Perl's
autovivification, which allows:

    
    
        zip = lottery.drawWinner?().address?.zipcode

~~~
samdalton
The Coffeescript ? operator is certainly quite handy. I suppose it's explicit
nature is what helps, as information on the error you're trying to mask is
built into the syntax. With @ in PHP however, you simply don't know what it's
trying to stop, and what undesirable affects it may cause, which I think is
the main objection to it.

------
pornel
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!

~~~
jrockway
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.

~~~
Tomek_
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

~~~
mryall
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>

~~~
ryan-allen
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.

------
programminggeek
Before everyone goes all "why don't you switch to language X or platform Y or
lisp variant Z" I just want to say good job on this.

These all seem to be sane critiques of PHP without being all doomsday world-
ending inflamatory. Kudos.

Also, I think that this is another example of how hard it is to build up a
large and widely-used language/framework without having lots of warts.
Especially since PHP wasn't originally designed with the intention of powering
everything from a simple blog/cms to facebook.

~~~
iphoneedbot
yeah.. php really has gotten a bad rap.. nearing ASP proportions

~~~
lmz
By ASP you mean VBScript, right? Because ASP pages can be written in JScript
as well, and I remember JScript was quite nice.

------
thinkcomp
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.

~~~
qeorge
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?

~~~
rudiger
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.

~~~
generalk
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.

------
gergles
The ridiculously terrible behavior of == is what makes me the saddest.

<http://www.php.net/manual/en/types.comparisons.php>

We then have === which does what == is really supposed to do, but even that
still sometimes does the Wrong Thing.

~~~
gergles
Wow, a downvote within 30 seconds of posting?

"php" == 0 returns true, and this makes sense how?

~~~
tzs
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.

~~~
rjh29
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).

~~~
btilly
$foo++ isn't an exception. It has documented behavior on strings. That is
sometimes very useful.

~~~
rjh29
I meant it's an exception because it does not throw a warning, even though you
are treating a string as a number. (This is contrary to $foo = $foo + 1). The
DWIM string auto-increment doesn't even kick in unless the variable matches
/^[a-z]/i.

------
wvenable
As usual, when one of these lists comes out about PHP there are some real
issues, some non-issues, some have been fixed, and a few things that are just
_different_. I'm surprised these sorts of posts keep getting voted up here;
haven't we seen it all before?

I do a lot of PHP development but not exclusively and rarely does these sorts
of deficiencies in PHP ultimately matter.

------
jwatzman
My favorite PHP design misfeature: what does the following code do?

    
    
      <?php
      $foo = array("a", "b", "c");
      foreach ($foo as &$bar)
        echo $bar;
      echo "\n";
      foreach ($foo as $bar)
        echo $bar;
      echo "\n";
    

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>

~~~
unfletch
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.

~~~
wvenable
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.

~~~
unfletch
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.

~~~
wvenable
It's not a bug because it's not a bug. How would you propose they fix this
non-bug anyway?

At the end of the first loop, $item contains a reference to the last item in
the array. Just as $item would contain the value of the last item in the array
if you weren't using references. In the next loop, $item still contains that
reference so now you're overwriting the value of that reference. You can't
assume the second loop knows anything about the first loop.

People might actually be relying on this behavior but not in the way that
you're expressing here. References are not just assigned in foreach loops.

~~~
jessedhillon
The fix for this is that foreach should create a new iterator variable which
overwrites the existing one. That would preserve expected behavior.

I think you should pause for a minute and summarize all of the WTFs you've
rationalized on this post. Just the volume of it makes me incredulous that you
don't think PHP == FAIL (or perhaps === if you like).

~~~
wvenable
> The fix for this is that foreach should create a new iterator variable which
> overwrites the existing one.

That would be very strange behavior though that has no equivalence in any
other part of the language. I'm sure if it did that, somebody would put on the
list of things that PHP does weirdly!

> That would preserve expected behavior.

I'm afraid the behavior it has is the expected behavior. The problem isn't the
language in this case.

> Just the volume of it makes me incredulous that you don't think PHP == FAIL
> (or perhaps === if you like).

Clearly you haven't been paying attention to my posts. I might be
rationalizing some of these sort of ridiculous ones but I certainly don't
think PHP is full of win. I'm just pragmatic. These problems just aren't
_that_ bad.

~~~
jessedhillon
> _That would be very strange behavior though that has no equivalence in any
> other part of the language._

How is it strange? When you declare your iteration variable, it unsets any
existing definition of that variable if there is one, before it inserts the
new variable. Why would anyone enter a loop and expect the iteration variable
to have a value defined outside the loop?

Moreover, even if someone can find a reason why -- why make define the
language around a need to support such badly designed programs.

> _I'm afraid the behavior it has is the expected behavior._

Fine. s/expected/intuitive/g

> _The problem isn't the language in this case._

Agreed. It's the people who designed it.

> _These problems just aren't that bad._

This is my point: the individual issues are all workable. The real problem is
that the language is maintained by people who have no idea how to design a
language, frankly.

~~~
wvenable
> How is it strange? When you declare your iteration variable

You're not declaring anything; PHP doesn't have variable declarations. In this
case, you're either creating a new variable or using an existing one -- just
like everywhere else. But I'll concede the point. While the code is
technically correct, unsetting the loop variable might be a nice addition. But
I fully understand why they wouldn't want to make this change.

------
jrockway
I hate PHP, but this article isn't very good. It's strange that there is an
"implications for the internals" reason. Guess what, you can just read the
internals. It's open source.

The parser emits weird error messages because it is a very simple yacc
grammar. (And because they turn off yacc's "produce better error messages"
mode.) If you want good error messages, it's going to cost you -- just read
perl's toke.c if you don't believe me. Good error messages cost _a lot_.

~~~
generalk
You _can_ just read the internals, but that doesn't mean that the criticism is
wrong. Certain problems do suggest deeper internal issues.

"Good error messages cost a lot" and "They turned off yacc's 'produce better
error messages' mode" seem to contradict one another.

And no, in a lot of cases the parser emits weird error messages because the
internal variables are named weird things. If you're telling me it's
unreasonably difficult for PHP to produce a better error message than
"Unexpected CONSTANT_NAME" than why name your constants unintuitively?

------
ckoning
While it doesn't detract from the point of your post, the behavior of private
is correct and intended. If you wish to override an internal method of a class
in PHP, like Java, you must declare it protected, not private. This is the
difference between private (completely internal, not inherited) and protected
(internal, but inherited by subclasses).

------
cgranade
I'd love to see similar lists for other languages. I've been coding in MATLAB
as of late, for instance, and rediscovered my hatred for the fact that you
can't index the output of a function without assigning to a temporary
variable. For instance, `foo(args)(:)` causes an error. You have to use `X =
foo(args); X(:)` instead. That makes me just as sad as some of these PHP
sadnesses.

~~~
nimrody
MATLAB does get _one_ thing right: Function arguments are always passed _by
value_. This "referential transparency" really makes it easier to reason about
functions and test them.

It's the one thing I hate about SciPy.

Passing by reference for performance reasons should be automatically handled
by the compiler. I.e., A=sort(A) should be handled in-place without requiring
a new function sort!(A).

~~~
cgranade
I'm not so sure I agree. Python in general is very consistent about pass-by-
value versus pass-by-reference semantics, whereas MATLAB infers things in ways
that are far from transparent. Look at, for instance, the way the `parfor`
loop construct differentiates between "broadcast," "sliced" and other such
variables, and how fragile that inference is. Maybe I haven't thought clearly
enough about this particular issue, but I don't think of MATLAB as being
transparent.

------
ars
So how do I contact the author with updates?

I clicked on a random item - the complaint that explode() doesn't take the
empty string and return an array of each letter. But of course you can just
use the str_split() function to do that (which is way more logical than
passing an empty string).

So how do I contact the author and reduce his sadness level?

Or is this one of those websites that don't want to remove items, even if they
are wrong?

------
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>

------
betageek
PHP's single greatest advantage is ubiquity - would love to see a CoffeeScript
compiler for PHP that smooths out these issues.

~~~
PaulHoule
you could say that all other web platforms are blub because they don't see the
value that PHP brings to the table.

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.

tomcat, mod_perl, the ten different ways people host Ruby sites and all that
make a lot more trouble for you. I've run PHP-based web servers for hundreds
of sites that have served billions and billions of hits over the years and
never once had to restart Apache because an application server got lodged.
read that again because if you skip it, you're sysadminning blub.

every other system requires that you make choices, and the truth about choices
is that faced with a binary choice there are two common outcomes: (i) a person
freezes up like a deer in the headlights or (ii) a person makes a random
choice that they're 50% likely to get right. (i)'s probably the better option.

i can complain about things wrong with PHP forever and i've got plenty of
reasons to get off the PHP train. however, if you want to kill PHP, it's not
enough to attack what's wrong with PHP, you've got attack what's right with
PHP... You've got to make a better PHP than PHP.

~~~
jrockway
_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 there will be a
thunderstorm, and then your house collapses, killing your entire family. Good
engineering requires good implementation. PHP makes good implementations too
hard.

 _every other system requires that you make choices, and the truth about
choices is that faced with a binary choice there are two common outcomes: (i)
a person freezes up like a deer in the headlights or (ii) a person makes a
random choice that they're 50% likely to get right. (i)'s probably the better
option._

Theoretically, this is why you hire people with experience. They picked
randomly the first time, and then gathered data. Their random choice either
worked or it didn't. Repeat a few times and you have "senior system
administrator" and "senior engineer" instead of "random dumbass we found on
the street corner", and then this part of the equation goes away.

Now, if your goal is to produce something that sometimes works with the least
amount of money possible... yes, you should outsource your development and
deployment to some high school kids in India. If your goal is to produce
something that works...

(Also, the days of PHP's deployment superiority are nearly over. With
mongrel2, I can restart my app instances without losing a single request!)

~~~
randallsquared
_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 the creators of your framework
wanted to do, and as long as you're willing to stop by and maintain your app.
PHP is more of a fire-and-forget language for apps... you can write it and
then ignore the app for years without worrying about memory leaks or crashes
or that it's taking up resources on your virtual server...

 _With mongrel2, I can restart my app instances without losing a single
request!_

Wow, what an achievement! This is the one thing that PHP really, seriously got
right: no application server. There are applications out there that need the
extra efficiency of not starting up on every request, but the vast majority of
webapps do not. The additional robustness and sanity provided by not having to
wonder why your app server fails after 292744 requests, or what went wrong
when it just stopped responding, or whether, indeed, you might lose requests
when restarting -- that helps me sleep at night. Few webapp-oriented languages
have this, preferring instead to try over and over to get the application
server paradigm right, this time, for sure! We just have to add a little shim
here, and build another layer over these layers to interface with that one...

~~~
ryan-allen
> 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.

~~~
randallsquared
Well, if you're considering Apache+plugin to be an application server, then I
guess I need to say: no _additional_ application server other than the web
server. Most modern systems have a web server and a separate process for the
application server (proxied to over HTTP or fed by FastCGI or WSGI or a neat
otherwise unused protocol). The standalone application server (back when I was
mostly using those languages) always seemed to have a bunch of quirks and to
fail at every insult. Compared to the Rube Goldberg nature of some of these
stacks of servers and protocols, PHP is delightfully simple, conceptually.

~~~
ryan-allen
> Compared to the Rube Goldberg nature of some of these stacks of servers and
> protocols, PHP is delightfully simple, conceptually.

I agree that what you could call it's deployment API (or whatnot), that it is
very simple. I think the reason for it's success is it allowed HTML/CSS
'programmers' to progress to simple scripting within their existing deployment
metaphor (upload via FTP, use a PHP file extension, wrap PHP in <?php tags).

However, there's no reason that you couldn't design a similar thing in say,
Ruby or Python, where people upload files with a specific extention FTP and it
runs some templating language (like ERB or Pythons equivalent). You'd need
some web api to allow triggering reloads of files (or reloads on every request
if the server is being used for development).

PHP out of the box re-parses _every single script on every single request_,
which is what you'd expect a development environment to do, but 'in
production' that's what PHP has always done.

Hence were born the optcode caches (which work rather well now), like APC. But
still, on every request, every file that is required has a stat performed on
it (you can turn this off, though).

It's all very lowest common denominator, and the high end stuff is severely
lacking and poorly documented. It's possible to have the best of both worlds
(well designed language, pragmatic libraries and toolset out of the box,
simple deployment AND well defined high end high traffic considerations), but
PHP ain't it.

~~~
PaulHoule
However, PHP was designed from the outset to run in this mode so the
interpreter is an order of magnitude faster than Perl, which is what competed
with PHP back in 2001 -- PHP was ~designed~ through and through to do what it
does, and that's why it does it so well.

------
DCoder
Missed one:

    
    
        foobar() is the same as FOOBAR()
        $foobar is completely separate from $FOOBAR

------
sparkygoblue
This horse has been beaten, mutilated, and buried.

~~~
ryan-allen
Obviously not quite buried yet.

------
jessedhillon
#40 is a major WTF. They are outright removing the ability to create a length
1 buffer, so that someone who wants to create a 4096 unit buffer can save 3
keystrokes?

(Also, what if the length argument is dynamically generated, say from the size
of a file?)

------
Androsynth
Programming languages are tools. Some tools are better than others, some are
better for certain situations. For all non-contractors, no one is forcing you
to write in one language over another (or stay employed at a php shop).

It seems like the only point of having threads like this is for the leet
programmers to look down on php. What's the point? This isn't constructive,
its condescending and back-patting.

(the reason this makes me mad is that the sadness list is just a bunch of
minor gripes. Every language has minor problems. PHP has fundamental flaws and
that causes sadness, not this crap.)

------
SeoxyS
What makes me sad is that even though I feel affronted by PHP's crudeness,
inelegance and inconsistencies… I keep using it for a lack of another language
that suits me personally.

I hate PHP's runtime and core libraries. But I really like the C-inspired
syntax. I use Objective-C as my main other language, and something about Ruby
and Python's syntaxes seem to rub me the wrong way. I'm giving Node.JS a whirl
these days—and while I might be able to get used to closures everywhere, I
don't know how to feel about the lack of true object orientation.

------
gburt
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?

~~~
PaulHoule
there's something wrong with the == and coercion in the if() statement in any
language.

making the switch in if() be a boolean only pushes the problem off to the
programmer, who will often choose the wrong function or expression to do the
conversion

~~~
seabee
> making the switch in if() be a boolean only

What exactly is the alternative?

If there's any problem here it's automatic coercion.

~~~
PaulHoule
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 other) Scala introduces it's own collections that
provide more confusion when you're working with Java. The .NET framework has a
great implementation of generics (makes Java and Scala look like a joke) but
there are still many legacy APIs in the .NET framework that use non-generic
collections.

One result is that it's not always obvious what the right way to test for
"empty" is. One of the worst of them is that pretty frequently APIs will give
you a null when they ought to be sending you an empty collection, so you need
to check for null.

~~~
samfoo
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).getOrElse(List()).isEmpty) { ... }
    

Or more likely:

    
    
        Option(someListThatMightBeNull) match {
            case Some(list) => // do something...
            case None => // do something else...
        }
    

More than likely if you're dealing with scala libs, things that can be "null"
are returning options anyway.

~~~
PaulHoule
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.

~~~
smcj
You have never looked more than 5 seconds at Scala, right?

Option[X] is only a crock if you haven't understood it. Stop thinking of it as
a "null check", start as thinking of it as a collection which can either hold
0 or 1 elements and then you are on the right track.

null in Scala mostly exists for Java compatibility.

Re: Collections ... you haven't looked even _once_ at it. All collections
return an empty collection or None, based on the operation. There are maybe 2
methods in the whole Scala standard library which return null, and both are
_not_ in the collection framework.

This is so unbelievable misinformed... I can't believe it you have no problem
showing this level of ignorance publicly.

"type inference system in Scala is always doing strange things behind my back"
... Example please.

"Automatic conversions" WTF?

"The trouble I see [...]" this is so much pure bullshit.

------
jcampbell1
php -r 'array("a","b")[0];' results in a parse error.

~~~
gburt
Resolving arrays like that causes parse errors in a range of contexts.
Anything that is a "function" cannot also pick one array key... leaving a lot
of XML-parsing code that looks like

$xml = getXpathWhatever(); $xml = $xml[0];

Stranger yet, is that it works perfectly fine with resolving objects... for
example

$xml = funct()->something->somethingelse()->a

Works fine...

~~~
birken
Array brackets after function calls are fixed in PHP 5.4:

~/php_source/php-src-5.3$ ./sapi/cli/php -r "function a() { return array(1,2);
} print a()[0];"

Parse error: syntax error, unexpected '[' in Command line code on line 1

~/php_source/php-src-5.4$ ./sapi/cli/php -r "function a() { return array(1,2);
} print a()[0];"

1

------
kalleboo
Where are the links to his bug reports for these so we can vote on them to be
fixed?

~~~
ryan-allen
The PHP bug report tool is at <http://python.org>. To file a bug, click
'Download Python'.

------
mikey_p
Related: <http://www.phpwtf.org/>

------
EamonLeonard
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.

~~~
dexen
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=121142259100001&r=1&w=2)
[http://marc.info/?t=119995974300003&r=1&w=2](http://marc.info/?t=119995974300003&r=1&w=2)

~~~
philolson
This is being revisited as per the PHP 5.4 TODO. My guess is it'll happen this
time around, and I voted against it previously (but changed said vote).
<https://wiki.php.net/todo/php54>

------
voidr
> Standard libc process control (fork/exec/etc) > The libc fork() and exec()
> functions are not present in PHP by default. >
> <http://www.phpsadness.com/sad/17>

Why would anyone writing a PHP app need those? The page just calls it a
missing feature without explaining why this is a bad thing.

------
winestock
Don Hopkins gave a thorough list of things which are wrong with PHP.

[http://www.jwz.org/blog/2011/05/computational-
feces/#comment...](http://www.jwz.org/blog/2011/05/computational-
feces/#comment-90658)

------
fauigerzigerk
The function chaining issue (#21) has to be the single most idiotic thing I
ever encountered in any language (other than maybe t-sql).

------
chernevik
I grok none, but of Python they make me glad

------
Topaz2078
By popular demand, I've added a discussion board to phpsadness.com. Join the
discussion!

------
BruceForth
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

~~~
snorkel
I often find that PHP coders lack a total understanding of the LAMP stack.
"Apache configuration? Huh? I don't know, our admins do that." "MySQL? I don't
know, I'm not a DBA. I'm a developer." "UNIX commands?!! I don't like going in
the terminal. I'm a developer." No, sorry, you're not a developer. You're a
glorified web page editor.

~~~
ceejayoz
Bullshit. You don't have to be a sysadmin to be a developer. Web devs often
know the whole stack, but you're still a web dev if someone else in your
company handles those parts..

~~~
andos
You missed the point: they are talking about people who do not know those
aspects of the LAMP stack, not the ones who can afford delegating them to DBAs
and sysadmins. The first group are indeed glorified web page editors.

~~~
ceejayoz
Again, bullshit. I've had PHP projects that were entirely command-line with no
Apache and MySQL. If you want to argue that those projects weren't
development, that's absurd.

Systems and database administration are hugely complimentary skills, but
someone who doesn't know anything about setting either one up is still
developing.

~~~
count
I agree with you in a literal sense. I'd add the adjective 'extremely poorly'
to 'developing' for any developer who doesn't have a thorough grasp of the
system for which they are developing.

~~~
ceejayoz
An artist can make great art without knowing the details of how the dyes in
their paint are manufactured. The same is true for development.

~~~
count
Can an artist make great art without knowing to use oil paint on canvas,
instead of watercolor (or whatever - I'm not an artist)?

How about knowing the difference between types of brushes and what effect they
have on the canvas? Is it 'great art' if it's accidental?

~~~
ceejayoz
Yes, and yes.

That said, this is more like arguing that you can't be a great artist if you
don't know how to make the canvas yourself.

------
MostAwesomeDude
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 language, gets me
flamed every time I mention it. Why?

~~~
dexen
_> "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 production for years now.

<http://pl2.php.net/manual/en/book.mbstring.php> in case your google is
broken.

~~~
MostAwesomeDude
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?

~~~
dexen
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.

------
snorkel
Mandatory function arguments:

    
    
        function foo($arg1,$arg2) { return; }
        foo('bar');
    
        Warning: Missing argument 2 for foo()
    

Lame. But omitting arg2 is allowed if you give it a default value:

    
    
        function foo($arg1,$arg2=FALSE) { return; }
    

Blah. Instead I'd rather make arg2 truly optional just by testing if it's
defined.

~~~
rokhayakebe
What would the ideal language return for your function call foo('bar'). It
would seem to me that missing an argument should return some sort of notice,
like in the case where someone else is using it.

~~~
snorkel
I prefer Javascript for example: JQuery's calling conventions would not be
possible if function args were mandatory.

~~~
nawariata
You can always use func_get_args() if you truly want it that way.

~~~
ryan-allen
Or you could just use a real programming language that has some kind of
design.

