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

371–380 of 514 posts

Re: PHP: A fractal of bad design

#371

Post by maratd »

taytus wrote: post #361
maratd wrote: post #344

Earlier quoted context omitted.

> have error reporting turned off (which you should) No, you should not. You should never have error reporting turned off. You should certainly have it set to not display errors to the client, but all errors should be sent to a log, preferably syslog, and they should be reviewed. Your code shouldn't generate any errors.

"You should never have error reporting turned of" Sorry bro, if you have ever put code on production with error reporting on...you are doing it wrong.

I have and since I write the code, I expect zero errors. And that's what I get. When there are errors, that code needs to be fixed. Tell me more, bro.

Re: PHP: A fractal of bad design

#372

Post by maratd »

TylerE wrote: post #364
maratd wrote: post #344

Earlier quoted context omitted.

> have error reporting turned off (which you should) No, you should not. You should never have error reporting turned off. You should certainly have it set to not display errors to the client, but all errors should be sent to a log, preferably syslog, and they should be reviewed. Your code shouldn't generate any errors.

I'm just calling it what php.ini calls it. The settings related to displayed errors in the page are error_reporting and display_errors. The error logging is a totally sperate group of keys starting with log_

Yes, I know. Like I said, error_reporting on (set to E_STRICT) and display_errors off. And yes, where the error goes is a completely different question.

Re: PHP: A fractal of bad design

#373

Post by maratd »

aGHz wrote: post #348
maratd wrote: post #340

Earlier quoted context omitted.

> The article tries to be a comprehensive list of problems with PHP and @ is a notorious one Nonsense. The @ error suppression is a tool, just like any other. It should be used sparingly, but it does have its uses. I have been writing in PHP for over a decade and I have used it exactly one time. And yes, it irritates me when I see it in other's code all over the place ... which is why I refactor all external PHP code…

Ok, let me fix that: "The article tries to be a comprehensive list of problems with PHP and @ is an error suppression tool that is notorious for being misused throughout the community". > I refactor all external PHP code before I place it inside of mine > You don't like a feature of PHP? Don't use that feature. Simple as that. I don't know anything about you, but judging from that attitude you haven't worked in many…

> I don't know anything about you, but judging from that attitude you haven't worked in many teams.

I haven't worked on any teams. I've always written software solo. What of it?

> You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.

Refactoring is not a luxury, but a necessity. Not only do I refactor other peoples' code, but I refactor my own. That's the only way to get to a quality code base.

Re: PHP: A fractal of bad design

#374

Post by encoderer »

vital101 wrote: post #268
cletus wrote: post #264

If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery. A selection from the OP: > Because of the @, the warning about the non-existent file won’t be printed. So your complaint is that when you use @ to suppress an error it... suppresses the error? > The language is full of global and implicit state. "Global" is one of those dogmatic points. Nothing is truly "global" in PHP. The "global" in PHP j…

> There is no threading support whatsoever. >> That's a good thing. It forces you to use async HTTP programming or something like beanstalk, both of which are better than the complexity of threading. While there isn't multi-threading in PHP, you can in fact multi-process which provides similar functionality. http://php.net/manual/en/function.pcntl-fork.php

While there aren't many cases where you should run PHP as a daemon or cron job, there are _some_. Like, for example, you've got dozens of models and helpers written in PHP and you want to use them in queue workers or aggregation jobs.

I've run into these a few times and acquired a bit of mastery of PHP's PCNTL, POSIX and Semaphore/SHM/IPC extensions.

I don't do much PHP work anymore, but I do maintain an OSS library for other people in that situation: PHP Simple Daemon -- https://github.com/shaneharter/PHP-Daemon

This is half-plug, half +2 to your point.

Re: PHP: A fractal of bad design

#375

Post by pratyksp »

obituary_latte wrote: post #274
cletus wrote: post #264

If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery. A selection from the OP: > Because of the @, the warning about the non-existent file won’t be printed. So your complaint is that when you use @ to suppress an error it... suppresses the error? > The language is full of global and implicit state. "Global" is one of those dogmatic points. Nothing is truly "global" in PHP. The "global" in PHP j…

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 expects it to work.] And this also applies to all the javascript programmers who can download a jquery plugin and successfully use it in a website.

They even don't know that you can install PHP, apache and mysql separately and use it. For them XAMPP is all there it is, armed with dreamweaver and a ftp client. Most of them will be lost without cpanel.

I've tried teaching a few but all I get is :"go away don't try to be smart in front of me, I know what I'm doing."

Most of you here are smart people. But out there this is what you get from most of the PHP programmers.

Re: PHP: A fractal of bad design

#376

Post by crag »

obituary_latte wrote: post #316
acdha wrote: post #298

Earlier quoted context omitted.

I agree with the general point but this seems more of an indictment of other languages than a plus for PHP: with PHP, it's easy to get started with the most simple features - and then it takes years to learn how to cope with the language quirks and inconsistencies, deal with outright bugs, and learn a number of non-obvious ways in which your “working” site might be hacked due to a hidden language feature. There are t…

Yes, that would be great. An alternative intro would be most welcome. It should, though: - Be able to start and serve in minutes, across most platforms - Allow for portable code e.g. the code you create locally should be able to be ported over to an actual webhost with only [S]FTP. - Not require the command line to "work". At all. I tried to learn django ~a year ago, and it was an experience wrought with frustration…

"The main trouble was getting all the packages/dependencies correct. "

This is the one big problem python has; terrible package management. I can think of 3 different package management systems for python. All of them barley work and the various libraries all require different mangers and different python versions.

This package requires python 2.6. This other package requires 2.5. And now we have separate python 3.x packages. Ridiculous.

Re: PHP: A fractal of bad design

#377

Post by tjogin »

hardy263 wrote: post #304
ceol wrote: post #293

Earlier quoted context omitted.

> So your complaint is that when you use @ to suppress an error it... suppresses the error? From your edit, you've only been working with PHP for about 6 months, so you may not have seen some of the code most others have. Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on eve…

> Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything. You've turned something that's a person's fault into something that's the language's fault. Other languages have some sort of warning suppression as well, like Java's @SuppressWarnings or C#'s #pragma warning di…

> You've turned something that's a person's fault into something that's the language's fault.

PHP programmers have only one single thing in common. PHP.

Re: PHP: A fractal of bad design

#378

Post by encoderer »

corford wrote: post #360
KaeseEs wrote: post #192

Earlier quoted context omitted.

PHP is not a good tool for quickly getting a minimum viable product. Despite its flaws it is a good weapon for fighting 'the last war' - that is to say, it makes it quick and easy to make what are essentially the CGI pages of 1996 - but if you're doing anything more complex than that (for instance interacting in any way with a database), and I would suggest that even relatively non-technical people looking to use com…

Sorry but that is quite hard to swallow. How are any of these not fit for building an MVP in 2012? http://silex.sensiolabs.org/ http://twig.sensiolabs.org https://github.com/nrk/predis There are also modern libraries for a plethora of other RDBMS and NoSQL systems (I think PHP is even going to support mongodb natively soon i.e. no third party client library required).

I've done quite a bit of PHP development, a lot of more advanced stuff (Earlier in this topic I linked to a PHP Daemon library of mine on Github).

But PHP has either missing or NOTORIOUSLY inferior Memcached/Redis/Mongo/Cassandra/HBase/Riak/etc clients. They get the job done, but they underperform, say, Python or Java versions in benchmarks and introduce far more bugs and quirks than I've experienced in other languages.

This has actually been a positive thing, because when you're using these data stores/queues/etc at scale and you need bulletproof client libraries, you naturally are led to a SOA. You end up with Python/Erlang/Clojure/Java services that interact with the datastore, that you consume from PHP using Thrift et al.

But being so bad that it pushes you into building a better architecture is kinda a preverse benefit

Re: PHP: A fractal of bad design

#379

Post by ericd »

stiff wrote: post #210
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…

I understand fail fast, and errors do still get logged and made visible (New Relic is great like that). I would rather fail a bit slower, silently, though. It's much less jarring to users, and therefore you lose fewer.

Re: PHP: A fractal of bad design

#380

Post by corford »

encoderer wrote: post #378
corford wrote: post #360

Earlier quoted context omitted.

Sorry but that is quite hard to swallow. How are any of these not fit for building an MVP in 2012? http://silex.sensiolabs.org/ http://twig.sensiolabs.org https://github.com/nrk/predis There are also modern libraries for a plethora of other RDBMS and NoSQL systems (I think PHP is even going to support mongodb natively soon i.e. no third party client library required).

I've done quite a bit of PHP development, a lot of more advanced stuff (Earlier in this topic I linked to a PHP Daemon library of mine on Github). But PHP has either missing or NOTORIOUSLY inferior Memcached/Redis/Mongo/Cassandra/HBase/Riak/etc clients. They get the job done, but they underperform, say, Python or Java versions in benchmarks and introduce far more bugs and quirks than I've experienced in other languag…

I haven't used a PHP nosql client library at serious scale so I will bow to your better experience (although in the case of Redis clients, some links would be nice as I wasn't aware that the two major PHP clients had any performance/reliability problems - I'm very surprised that https://github.com/nicolasff/phpredis under performs given it's a C extension).

Having said all of that, if you are building a site that uses NoSQL and needs to scale to millions of simultaneous hits you'd be insane not to develop it with SOA in mind. Using just PHP (or any other single language) wouldn't make sense.

Post reply on HN