PHP: A fractal of bad design • Hacker News Board

Re: PHP: A fractal of bad design

#201

Post by vivekprakash » Tue, Apr 10, 2012, 9:35 AM UTC

ez77 wrote: post #182

vivekprakash wrote: post #68

I had a one-to-one talk with Rasmus Lerdorf a few weeks ago. This is one of the few things he said: " I wrote PHP as a hammer to do my stuff. Around 1993, the only way to write web apps was by hacking C and Perl. This was extremely painful, and you would have to do the same thing over and over again. So I started writing a tool which would make my work easier. " " I never thought while writing PHP that someday millio…

Do you have this in audio/video? It would be nice to hear/see this exchange.

Sorry, there is no audio/video of it. This was supposed to be just a casual chat, but it turned out to be an incredible exchange of more than one hour. I wasn't prepared to record the conversation, but I wish I had.

Re: PHP: A fractal of bad design

#202

Post by hm2k » Tue, Apr 10, 2012, 9:35 AM UTC

http://en.wikiquote.org/wiki/Rasmus_Lerdorf

Re: PHP: A fractal of bad design

#203

Post by eru » Tue, Apr 10, 2012, 9:43 AM UTC

dalore wrote: post #156

fragsworth wrote: post #142

Earlier quoted context omitted.

What is the problem with eval? Even Python lets you do that. There are legitimate uses for it.

It easier to write an optimizer if you don't use eval since the eval code needs an interpreter.

> [...] since the eval code needs an interpreter.

Or a compiler at run-time.

Re: PHP: A fractal of bad design

#204

Post by rjknight » Tue, Apr 10, 2012, 9:45 AM UTC

emilw wrote: post #177

human_error wrote: post #170

Earlier quoted context omitted.

No, not all of us. I've never coded anything with PHP. I don't even know how to write hello world with it.

<? echo "Hello World";

Actually, you just need this:

Hello world

If all you want to do is print some text, just put some text outside the <?php delimiter. If you want to do nothing else, you don't even need the <?php delimiter.

Re: PHP: A fractal of bad design

#205

Post by jhuni » Tue, Apr 10, 2012, 9:54 AM UTC

JavaScript was rushed to the market in a few weeks so it is also a fractal of bad parts, for example, the == operator sucks just like in PHP, the + operator is used for both addition and concatenation, semicolon insertion has an unintuitive behaviour, etc. See JavaScript the bad parts for more detail. The entire web is built on a terrible foundation with languages like JavaScript and PHP that it is a wonder how it got to be as advanced as it is today.

Re: PHP: A fractal of bad design

#206

Post by Roccos » Tue, Apr 10, 2012, 10:22 AM UTC

Enough with all these Bullsh!t..., I have already seen too many articles against PHP, If you want developers to switch to other languages, Write an Article on that

If you don't like PHP, Just don't fuc_ing use it.. Nobody is forcing you to use it..

Let developers make their own decisions on Which language they want to use.

As long as WWW exists developers will use PHP, Get over that.

Re: PHP: A fractal of bad design

#207

Post by djmdjm » Tue, Apr 10, 2012, 10:31 AM UTC

anthonyb wrote: post #172

patio11 wrote: post #134

Earlier quoted context omitted.

Most applications developed by professionals in Big Freaking Enterprise Languages working in regulated industries will also have game over security vulnerabilities. Most applications developed by the cool kids in Ruby/Python working for startups will have game over security vulnerabilities. The current state of information security: basically, we're screwed.

PHP sites will have a hell of a lot more of them, though. You're not shielded against CSRF, XSS or SQL injection attacks unless you use a framework - at which point you're back to being a programmer with no "empowered amateur" in sight...

Hell, for most of then you aren't even protected against remote code execution. Google for "PHP arbitrary script execution" and weep.

Re: PHP: A fractal of bad design

#208

Post by johnx123-up » Tue, Apr 10, 2012, 10:37 AM UTC

eevee wrote: post #163

wvenable wrote: post #143

Earlier quoted context omitted.

> Operators are very fragile in the parser; foo()[0] and foo()->method() are both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t find mention of a fix for the latter. The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works? > == is useless. Actually, it's not useless. It does have a few stupid edge-cases and I will admit that. But in mo…

Only a couple of these things are outright wrong; I removed the offending bullet points earlier tonight. A few things I listed because they're weird, not outright wrong, and I stand by those. For the most part you've defended PHP's behavior as design decisions or offered workarounds. Workarounds just demonstrate that the language is Turing-complete. Design decisions are only okay if they actually make a useful tradeo…

So, do you want the PHP to be a clone of python? PHP works for some and python works for others. Do we really need a FUD to convert people? Hint: read python sucks articles from Ruby rockstars.

Re: PHP: A fractal of bad design

#209

Post by jasonlotito » Tue, Apr 10, 2012, 10:41 AM UTC

eevee wrote: post #74

robomartin wrote: post #45

I can't really fault anything that was said in the article. What left me wanting was the ending. I was expecting the equivalent of the main character happily walking into the sunset. In other words, something akin to: "And now that we have established why PHP sucks let me tell you what I use and why. I use . Here are all the reasons for making these choices:"... To me at least, an equally thorough treatment of what h…

Ha, I actually avoided doing this so as to not sound like a shill for better-thing-X :) I namedropped Python a couple times, and I do enjoy it for webdev. I've been considering writing something about getting into Python webdev from a purely PHP background; might do that sooner rather than later.

As someone who goes to PHP when he needs to program for the web, and has been doing so for some 13 years now, seeing the horse beaten again didn't move me. I can't say I spent much time on your article, mostly because at this stage of my life, focusing on the negative doesn't earn you anything.

I say that because, while it's clear you spent a lot of time on this, it's not really useful precisely because you don't provide any direction. Who is this article for? New people? They aren't going to understand half of what you wrote, but more importantly, they don't know where to turn to for the next step. You mention Python. And that's cool! Python is an awesome language. Your target audience (new programmers or new web developers) aren't going to read through that entire thing. The only people who will are PHP developers who want to respond and people already hate a programming language.

What would be valuable is if you took a look at why people pick up PHP, and instead of trying to destroy it's existence with a single post, you actually show them how they can use Python to do what PHP does. You've clearly done the research, so you know where PHP's strengths are, and why people still navigate toward it.

Anyone can destroy. It takes actual effort to create. Help create. =)

Re: PHP: A fractal of bad design

#210

Post by stiff » Tue, Apr 10, 2012, 10:43 AM UTC

ericd wrote: post #88

Meh, I've written a lot of PHP code. I also work in Ruby and Python. All three have problems, but I like all three. With PHP, you have to develop a coding style that naturally avoids PHP's weird areas. It's not really that hard to avoid the mines, but you do have to be aware of them. In exchange, you get a scalable web server and a language that requires minimal babysitting. Instead of automatically throwing a 500 on…

Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine.

And how precisely does PHP "know" which exceptions are important and which are not? In my experience of 6 years as a web developer, the faster and the more explicitly something fails the better. If the user gets a 500, that's a pretty clear sign of a problem, I get an email notification about it, including user id, session data etc. Then, in most cases, I can easily see what the problem was, decide what the correct behaviour is and create a fix immediately and even notify the user after releasing it if I wish to do it. If there is no exception there is a case in the code I was not aware of when writing it and it will still not be brought to my attention. In the best case, the user will report some problem with the functionality and I will have to spends hours trying to find the logs for this user and reproduce the problem, which will now be much harder, quite some time could have passed since the error, the database entries for the user could have change meanwhile (including corruption caused by the system continuing to operate despite an error) and so on. In the worst case, the bug will continue to affect users (which might not even know what the intended behaviour was) and I will learn about it a year from now, accidentally.

Reproducing bugs is hard enough in web applications due to their distributed nature, some of the applications I worked on had serious business-affecting bugs that went unnoticed for months and failure to clearly signal errors is one of the common cases. It doesn't matter whether you are in banking or just building another social CMS/CRM "kind of thing", if you have bugs you loose users and with them money.