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

Taking PHP Seriously [pdf]

raw.github.com

Post reply on HN
Print view View original

121–130 of 155 posts

Re: Taking PHP Seriously [pdf]

#121

Post by theOnliest »

duskwuff wrote: post #78
bilalq wrote: post #74

Earlier quoted context omitted.

I don't think bringing up deprecated functions is valid criticism. Everyone uses PDO these days.

Everyone should be using PDO these days. Whether they are is another matter. :(

I work in a large educational institution, using PHP and MS SQL Server, and I can't convince the sysadmins to install PDO because the SQL Server PDO bindings have a big red EXPERIMENTAL sign on the page (http://php.net/manual/en/ref.pdo-dblib.php). So I'm stuck using 'mssql_' functions, I'm afraid.

Re: Taking PHP Seriously [pdf]

#124

Post by jasonlotito »

sergiosgc wrote: post #116
jasonlotito wrote: post #37

Earlier quoted context omitted.

Ever notice how everyone who complains about PHP are usually complaining about WordPress, Joomla, or other such apps?

Because these apps exist . WordPress, for example, is unparalleled in other language domains. What is the WordPress of Ruby? And in python? Is it Django? Where's the plug-in directory for Django, equivalent to [1]? I work with WP, I'm the first to recognize it's an old codebase with all defects this entails, but popularity has value. Value that PHP critics dismiss too lightly. [1] http://wordpress.org/plugins/

I'm not dismissing WordPress's value. Rather, I'm dismissing those that dismiss PHP out-of-hand and their lists of reasons include WordPress.

Re: Taking PHP Seriously [pdf]

#125

Post by jasonlotito »

justinhj wrote: post #69
jasonlotito wrote: post #42

Earlier quoted context omitted.

It's PHP. Unfortunately, enough developer got bit by the fact that PHP doesn't prevent you from shooting yourself in the foot, and shot themselves in the foot. So, you'd probably be pretty ornery too when other people had more discipline to use the language without shooting their foot and were also employing it successfully. You'd probably want to make assumptions, and word hard to belittle them. Insult them. And the…

PHP may have a bunch of ways to shoot yourself in the foot, but you get a new foot back right away. IMHO the oddities in PHP rarely hit you, and when they do you'll pick it up right away in PHPUnit, fix it, and walk away.

Sorry, maybe it wasn't clear, but the professional using PHP was the one walking away. =)

Re: Taking PHP Seriously [pdf]

#126

Post by jasonlotito »

dkhenry wrote: post #44

At this point we almost need to stop saying facebook programs in PHP. I know this was defending PHP, but look at what is happening. Facebook ( big engineering firm, lots of developers and resources ) could not get php to work for them short of rewriting the core (HPHP ) and then adding on features to the language that most other languages have determined are useful enough to be baked into the language. Here is my TL;…

Tell Facebook that. They are the ones talking about it still.

Also, your TL;DR is a flat out lie.

Re: Taking PHP Seriously [pdf]

#127

Post by PeterisP »

TazeTSchnitzel wrote: post #58
harshreality wrote: post #14

Earlier quoted context omitted.

$productid = "0x4zz5"; print $productid + 4; If printing "8" is your idea of a working interpretation of that code, then PHP is the language for you. If not, then PHP doesn't work. End of story.

8 is sane here. The + operator adds numbers. It converts the string to a number implicitly in the process. it takes "0x4zz5" and tries to parse as much as possible. Since "z" is not a valid hexadecimal digit, it stops at z, and reads it as 0x4. Of course, it is better to manually convert.

Well, I'd say it's never better to "try to parse as much as you can" and when encountering such an error simply silently give out a nonsense answer.

It's the computer equivalent of a bozo worker who does something random everytime they don't know how to do their job, and then tries to hide any consequences while whistling innocently.

Re: Taking PHP Seriously [pdf]

#128

Post by FMJaguar »

wanderr wrote: post #63
jtreminio wrote: post #45

Earlier quoted context omitted.

You are unable to properly mock static methods. So, for example, if you have a AuthorizeNet class that has a static method ::submit(), if you test the code then every single time you run it you're pinging Authorize.net's servers, which opens you up to a world of hurt. Properly mocking methods allows you to get rid of this unknown and say, "The submit() method will return an array of this specified data" without Autho…

Perhaps I'm missing something, what about static methods prevents you from having a mock AuthorizeNet class implementing the same interface but with a submit() method that just returns fake data? Perhaps there is something specific to the testing framework you use that makes this clunky? As far as static properties go, if you're mucking with those you're back into the world of storing state, which OO is more suitable…

In this case, you are probably just using classes to emulate namespaced functions [1], the use of 'class' is confusing to oop programmers, the code does not have classes, just the word class.

Like php code, php itself is often confusing and hard to decipher, currently I think it of it as a C dsl for web stuff that people mistake for a high level application framework.

Like C, many people learn basic syntax and functionality in school or as a side project. Unlike C, people believe that that their skillset is the one required to build a complex server side application combined with a web ui.

If you realize the mismatch and account for it, you can build great php websites. The problem arises when people assume they are getting a 'faster/cheaper' .Net/Java stack and start to hire programmers into that structure.

The net result is a clash between people that are using PHP as intended, and people that have been subjected to the misuse of the php.

1. http://stackoverflow.com/questions/5647598/cannot-import-use...

Re: Taking PHP Seriously [pdf]

#129

Post by dham »

Corrado wrote: post #102
badclient wrote: post #35

Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django or RoR. As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many aweso…

I think it is fair to contrast PHP with RoR or Django, because it was built specifically for generating HTML. Ruby and Python are general purpose languages that do many more things than generate web pages. No one writes iOS apps in PHP but they do in RubyMotion. No one writes high performance Math routines in PHP but they do in Python.

This is my biggest gripe. PHP just does one thing. You can't really use it for much more then building web pages. Yes, you can use it for scripting but Ruby and Python are much better at this.

You have things like Rubymotion(to build iOS and Mac apps), which I'm really liking. Opal which translates Ruby to Javascript. You can build Android apps with Ruboto. You can run Ruby the JVM and call Java libraries. You can run Ruby on the .NET runtime(Iron Ruby). You have a really good Web framework called Rails. Most other PHP frameworks just copy Rails, so why not just use the source. You can build games for iOS using Joybox(library for Rubymotion).

So from a business prospective we chose Ruby because we can do pretty much everything in Ruby. We rarely have to use anything else. From command line applications, to web, to iOS, to Android, to reporting, etc.

PHP, well, you can output HTML, or JSON.

Re: Taking PHP Seriously [pdf]

#130

Post by TazeTSchnitzel »

PeterisP wrote: post #127
TazeTSchnitzel wrote: post #58

Earlier quoted context omitted.

8 is sane here. The + operator adds numbers. It converts the string to a number implicitly in the process. it takes "0x4zz5" and tries to parse as much as possible. Since "z" is not a valid hexadecimal digit, it stops at z, and reads it as 0x4. Of course, it is better to manually convert.

Well, I'd say it's never better to "try to parse as much as you can" and when encountering such an error simply silently give out a nonsense answer. It's the computer equivalent of a bozo worker who does something random everytime they don't know how to do their job, and then tries to hide any consequences while whistling innocently.

It's not equivalent at all. It is an expected, clearly-defined behaviour - automatic, silent type conversion, with clear rules on how that type conversion works.
Post reply on HN