Live data from Hacker News

These are things in PHP which make me sad

phpsadness.com

191–200 of 217 posts

Re: These are things in PHP which make me sad

#191

Earlier quoted context omitted.

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

Your point about class definitions being frozen is apt — but much of the nomenclature you're using to describe languages is meaningless. Please read the classic What To Know Before Debating Type Systems : http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wro...

Not meaningless, just debated. And even then, the web has helped to reduce the confusion around the terms.

http://en.wikipedia.org/wiki/Type_system#Static_typing

That article you linked to is useless. If we just called them alpha, beta, gamma, and delta type systems would a rose by any other name smell sweet?

Re: These are things in PHP which make me sad

#192

Earlier quoted context omitted.

> Why couldn't they reuse the same resolution operator for all three, even if it's not the period character? It may have been possible to do that when the language was originally designed but PHP has taking the long road to getting real OOP. PHP3 had objects but no inheritance; they were really just structs with functions. PHP4 added a lot more ability but, for reasons of compatibility, left a few things unchanged th…

> This is a poor argument. I use and enjoy many other languages. Not suggesting that you don't use good languages (unless you use and enjoy PHP). Just saying where other people are coming from. > Of course, but hindsight is always 20/20. Perhaps Python should have had unicode to start with and should have never made print a statement instead of a function. Perhaps templates were not the best way to add generics to C+…

> unless you use and enjoy PHP

I use an enjoy PHP. I assume that you don't use PHP because if you did, you wouldn't be arguing over such trivial things. For example, the inconsistency of namespace/class/member access looks terrible in theory but in practice it hardly makes any difference. It's not like you get confused as to which one to use and having them look different is somewhat helpful in understanding what the code actually says.

I used to think the backslash was the worse possible thing that could ever been done to PHP but after using it extensively for a while, eh, it's not so bad. At this point, I'd gladly change a whole bunch of other stuff before I'd change that.

> Just saying where other people are coming from.

Hey, I know where other people are coming from. I think I might be more qualified to bitch about the language than those who don't use it day to day.

Re: These are things in PHP which make me sad

#193

Earlier quoted context omitted.

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.

It's true. The problem is it's often the only PHP code they know. Many people do assume it's an example of good code, since it's so popular and essentially works.

WordPress is really an excellent companion to PHP itself - created by beginners who had no idea about how to design a language or framework. They have each since become somewhat respectable, but are shackled by the attempts they made to preserve backwards compatibility in the early days.

Re: These are things in PHP which make me sad

#194

Earlier quoted context omitted.

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

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

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

Re: These are things in PHP which make me sad

#195

Earlier quoted context omitted.

> This is a poor argument. I use and enjoy many other languages. Not suggesting that you don't use good languages (unless you use and enjoy PHP). Just saying where other people are coming from. > Of course, but hindsight is always 20/20. Perhaps Python should have had unicode to start with and should have never made print a statement instead of a function. Perhaps templates were not the best way to add generics to C+…

> unless you use and enjoy PHP I use an enjoy PHP. I assume that you don't use PHP because if you did, you wouldn't be arguing over such trivial things. For example, the inconsistency of namespace/class/member access looks terrible in theory but in practice it hardly makes any difference. It's not like you get confused as to which one to use and having them look different is somewhat helpful in understanding what the…

I use it every day at work, and have been a PHP programmer for years -- however, I don't suffer from the Stockholm syndrome that requires you perform the mental gymnastics involved in rationalizing away sheer volume of fail.

We both work daily with a horrible language, but at least one of us realizes it.

Re: These are things in PHP which make me sad

#196

Earlier quoted context omitted.

> unless you use and enjoy PHP I use an enjoy PHP. I assume that you don't use PHP because if you did, you wouldn't be arguing over such trivial things. For example, the inconsistency of namespace/class/member access looks terrible in theory but in practice it hardly makes any difference. It's not like you get confused as to which one to use and having them look different is somewhat helpful in understanding what the…

I use it every day at work, and have been a PHP programmer for years -- however, I don't suffer from the Stockholm syndrome that requires you perform the mental gymnastics involved in rationalizing away sheer volume of fail. We both work daily with a horrible language, but at least one of us realizes it.

I don't think we're having the discussion you think we're having; I'm well aware of how "horrible" PHP is. But I program in plenty of languages and there is very little difference in code size, code organization, or pain between my code across those languages. I could translate my current PHP project in Python and the differences wouldn't be that great.

I imagine you haven't experience any real pain: programming large projects in VBScript, C++, or doing any work in COBOL. The minor irritations of PHP is just that.

I suspect your problem isn't so much PHP but the code that you have to work with written in PHP. Most PHP code is embarrassingly bad. I'm lucky that, for the most part, I don't have to deal with a lot of terrible PHP code. I bend PHP to my will, not the other way around. A lot of people fault the language design for the insane way people use it -- it doesn't have to be that way.

Re: These are things in PHP which make me sad

#197

Earlier quoted context omitted.

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's inefficient to do that, as from what I understand PHP actually sets the error level to none, processes that line, sets it back, and continues. Also it would suppress any other warnings from that line, which could be unrelated to the supplied argument value. Instead, I use a 'get or else' function, as in some functional languages. For arrays, it goes function get_or_else($array,$key,$default=null) { return isset(…

I wasn't aware of that implementation detail. Hey, now I respect PHP even less than I did before.

Your solution makes for some good boilerplate, but things like that are exactly why I use Python for everything it makes sense for: these things are baked into the language (in Python it would be array.get(key, default) ).

Re: These are things in PHP which make me sad

#198
post #87
post #18

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.

Except when you're comparing objects! I want to make sure that object A and object B are instances of the same class. Also, I want to make sure that they are equal i.e. that every attribute is equal. Also, since I'm now used to always using === instead of == for such comparisons, I use === to make the comparison. I would think that == would perform an == comparison on every attribute, whereas === would perform an ===…

Object equality is non-trivial matter and subjective. Java delegates the consideration of object equality to Object.equals(), intended to be implemented by yourself as required.

That PHP chooses not to try and provide a means of determining object equality is not a poor choice. Using the === operator to test whether two variables are references to the same object is then also not a poor choice.

Re: These are things in PHP which make me sad

#199

Earlier quoted context omitted.

I use it every day at work, and have been a PHP programmer for years -- however, I don't suffer from the Stockholm syndrome that requires you perform the mental gymnastics involved in rationalizing away sheer volume of fail. We both work daily with a horrible language, but at least one of us realizes it.

I don't think we're having the discussion you think we're having; I'm well aware of how "horrible" PHP is. But I program in plenty of languages and there is very little difference in code size, code organization, or pain between my code across those languages. I could translate my current PHP project in Python and the differences wouldn't be that great. I imagine you haven't experience any real pain: programming larg…

We're mostly on the same page.

I indict the language designers for making it easy to write bad code. I agree it doesn't have to be that way, people can write good(-ish) code in PHP. It's just that the language team seems to go out of their way to make a language that doesn't appeal to a programmer's sense of symmetry, elegance, consistency, flow, and ease.

All of these things are easily worked around. As a sum though, they contribute to the overwhelming sense that the tool is created by -- and by extension, for -- dumbasses :)

Thankfully, the amount of PHP I have to maintain is decreasing and the time I spend on my own projects is increasing, which is when I get to use better languages.

In previous lives I have had to maintain/develop C++ as well, and I understand that it's painful. All pain is relative, I suppose. I'm sure a woman who has given birth to quadruplets would scoff at this notion of pain.

Re: These are things in PHP which make me sad

#200

Earlier quoted context omitted.

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…

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

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.
Post reply on HN