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

PHP: A fractal of bad design

me.veekun.com

Post reply on HN
Print view View original

401–410 of 514 posts

Re: PHP: A fractal of bad design

#401

Post by jtc331 »

maratd wrote: post #346
guccimane wrote: post #343

Earlier quoted context omitted.

Oh, you mean as opposed to the usefulness of calling people snobs because they understand that PHP is terribly designed? Fuck outta here.

You don't like it? Don't use it. You're the kind of asshole that'll walk up to somebody in McDonalds and tell them that the food they're eating isn't healthy. You know what? Mind your own business.

The thing is we need to stop advising people to use it in the first place. That's what we're advocating.

That is, we're not telling people to stop after they've gone into McDonalds, we're decrying the fact that so-called health experts are telling people that McDonalds is actually just fine for you. That's a better analogy.

Re: PHP: A fractal of bad design

#402

Post by jtc331 »

pratyksp wrote: post #375
obituary_latte wrote: post #274

Earlier quoted context omitted.

It seems that many people disregard the fact that PHP is a very accessible language to a programming newcomer. You can quickly and easily install LAMP or MAMP and in minutes have a working, dynamic web page (albeit local) along with a plethora of examples and tutorials. This is huge. This shows the newcomer that this mysterious code stuff is actually accessible; that they can create something that works. That's a nic…

Very low barrier to entry is also one of the reason why PHP ecosystem sucks. More than 95% of PHP programmers never grow up from beginner(at least what I've seen) even after more than few years of use. And those who grow up starts to use other language. The PHP crowd is mostly filled with "Internet Programmers" [A person who copies code from the internet and pastes in one's codebase, without even reading it, and expe…

Exactly. I don't actually agree that low barrier to entry is a good thing. Languages should be easy for people who've learned them, not necessarily easy for newbies.

That's the real idea with the principle of least surprise. It shouldn't surprise experts. But programming is hard. It's modeling real world processes in the abstract. That's hard. It isn't going to be simple for people who don't know how to program.

Re: PHP: A fractal of bad design

#403

Post by scott_s »

loganlinn wrote: post #326
rplnt wrote: post #311

Earlier quoted context omitted.

From the very (very) long article you picked somewhat weird collection to defend. > So your complaint is that when you use @ to suppress an error it... suppresses the error? This was one bullet-point from a 7-item list. Also it didn't say that @ is bad in any way (perhaps its use is), it was there only to demonstrate error configuration which is clear by the bullets after it. > > There is no threading support whatsoe…

> But letting users write code that appears to work (yet it does not) is not a good property of a language. I still don't see the point that's trying to be made here. Whether it returns -1, FALSE, or you need a try/catch, the programmer still needs to check. To successfully program in any language with an 'index of' function, a check needs to exist regardless...

To make explicit the design problem: the "not found" sentinel is automatically converted to a valid index. That's dangerous.

Re: PHP: A fractal of bad design

#404

Post by scott_s »

jerf wrote: post #302
colanderman wrote: post #259

Earlier quoted context omitted.

Name one. I can't think of any that aren't better served by other constructs. eval does have one huge, honking problem though: it permits text to be interpreted as code. This is just asking for code injection attacks. If you really need incremental/multi-stage evaluation, see MetaOCaml ( http://www.metaocaml.org/ ) for the proper way to do it (without exposing yourself to injection vulnerabilities). It's a consequenc…

"Name one. I can't think of any that aren't better served by other constructs." User input of code. It's hard to implement a REPL without it. Even if you do implement without it there's still an "exec" implementation hiding in there somewhere. Also, on rare occasions, it is actually an optimization when used carefully, like the Python nametuple example mentioned nearby. I'm just answering your challenge. I totally ag…

User input of code.

I use this in my Python data processing scripts. That is, when I generate data, I generate it as Python literals, either lists or dictionaries. When I have to process it, minimal parsing needed, I just eval it into my code.

  def parse_and_append(line, seq, str):
    if str in line:
        seq.append(eval(line[line.find(str) + len(str):]))

  nums = []
  mappings = {}
  for line in data_file:
    parse_and_append(line, nums, "nums: ")
    parse_and_append(line, mappings, "mappings: ")
Terribly insecure for webpages, sure, but very efficient use of my time.

Re: PHP: A fractal of bad design

#405

Post by wvenable »

zaphar wrote: post #136
wvenable wrote: post #111

I can't believe this article is on the top of this site. At least 50% of what's written in there is totally wrong/false. Other information is terribly out of date. And even more information is merely half-truths and lack of understanding of the language. Even pure supposition like "PHP was originally designed explicitly for non-programmers" is incorrect. This article is garbage -- don't be taken by it. I'm not going…

Having used php and run across many if not all of the issues the article lists personally I can pretty confidently say it's as close 1o 100% correct as anything I've read on the subject.

The article lists "E_ACTUALLY_ALL" as if it's really a PHP constant. I'm not sure the author has even used PHP -- this is just a bunch of information culled together from different blog posts with very different levels of understanding. There are many things that are just factually wrong with it.

I could complain about PHP all day but at least I know what I'm talking about!

Re: PHP: A fractal of bad design

#406

Post by sedev »

wvenable wrote: post #289
eevee wrote: post #163

Earlier quoted context omitted.

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…

> A few things I listed because they're weird, not outright wrong, and I stand by those. But a few things are weird to you but not some objective view of weird. Many of your points I didn't comment on are not unique to PHP at all (such as octal numbers) > For the most part you've defended PHP's behavior as design decisions or offered workarounds. You could say that unifying PHP error codes and exceptions is a "workar…

Let me put it this way: Lisp hackers think that one of the major problems with Emacs Lisp is that it basically uses one big namespace for everything, forcing awkward naming conventions and contortions to avoid collisions. That is possibly the one part of any Lisp that works like PHP ... and the Lisp community pretty much universally agrees that it's a bad idea, not because it's like PHP, but because it's a bad idea.

Also you should check out what Alan Storm has to say about this: http://alanstorm.com/python_imports_for_php_developers

Mr. Storm is a crackerjack PHP developer: perhaps you will listen to him.

Re: PHP: A fractal of bad design

#407

Post by HerroRygar »

astrodust wrote: post #55
Deinumite wrote: post #41

I completely agree with all of the author's points, but my day job is still PHP and I actually don't hate it so much now. That being said, it's nice to be able to sit on the most version of PHP and use awesome frameworks like FuelPHP and Laravel. I would not really consider doing anything besides nice CRUD app's in PHP though.

They say eventually you learn to love your captor. Frameworks can help a lot, but what PHP really needs is an equivalent to CoffeeScript that fixes all of these glaring issues with PHP. Although there's issues with the PHP language implementation, the biggest problems are the enormous number of functions with quirky argument ordering that need to be understood by a developer before they're operating at full efficienc…

There's a CoffeScript-ification of PHP called Snow. You can see it here:

http://code.google.com/p/php-snow/

Frameworks definitely help a lot. I've done a little work with FuelPHP, and I found that to be pretty pleasant.

Re: PHP: A fractal of bad design

#408

Post by sedev »

methodin wrote: post #240

Developers really do complain a lot, don't they? PHP offers unparalleled flexibility if you have any notion whatsoever of how to properly develop things. Those who think otherwise are most likely stalwart proponents of some other language, engulfed in functional programming or have read the latest post by _____ that explains a concept that should be used only rarely and will use it as an attack to state why another l…

"It also does not get in your way if you are a competent developer..."

Actually about half of the article was about how it does exactly that by being inconsistent, having action-at-a-distance effects, and not having real hashes/arrays/tuples.

Also you appear to have skipped the "Don't comment with these things" portion of the article, which anticipates all of your arguments.

Re: PHP: A fractal of bad design

#409

Post by sedev »

tnash wrote: post #254

Wow, this article is unnecessarily harsh. You get the feeling that one of his immediate relatives was crushed in a freak industrial machine accident and that he later found out that the machine was programmed in PHP. I work with PHP everyday, and it's a fine tool. It does what I ask of it, at least. If the objective is to drive a nail into a board, you can do it with a hammer or a rock, and it doesn't really matter w…

From the article:

>Don’t comment with these things

>>I’ve been in PHP arguments a lot. I hear a lot of very generic counter-arguments that are really only designed to halt the conversation immediately. Don’t pull these on me, please. :(

>>>Do not tell me that “good developers can write good code in any language”, or bad developers blah blah. That doesn’t mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.

>>>Do not tell me that it’s the developer’s responsibility to memorize a thousand strange exceptions and surprising behaviors. Yes, this is necessary in any system, because computers suck. That doesn’t mean there’s no upper limit for how much zaniness is acceptable in a system. PHP is nothing but exceptions, and it is not okay when wrestling the language takes more effort than actually writing your program. My tools should not create net positive work for me to do.

That's not even deep in the article! By spouting off exactly the arguments that the author anticipates, you're making yourself look like a jerkhole who didn't even do basic reading before spouting off a reflexive, unthought, and worthless opinion.

Re: PHP: A fractal of bad design

#410

Post by sedev »

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…

Every time someone does that, the argument gets derailed into talking about the other language and into a not-actually-related argument about its problems and the relative merits of the two languages and so on. You've seen it happen a zillion times. When the article is just a headshot on PHP, it's easier to get the point of "don't use PHP, use anything else" and PHP ... "apologists," like folks upthread, can't derail it into talking about the problems with Python/Ruby/whatever.
Post reply on HN