Comment by MAGZine | Hacker News Reader

Comment by MAGZine | Hacker News Reader

A quick dive into any PHP-related topic on HN should yield significant answers. Part of the hatred comes from the fact that the way people know PHP is from 2005, when it was essentially one really long procedural program. It's not so much that people ignore the recent upgrade in tooling/modern language constructs so much as people aren't familiar that they exist.

However, these is still a lot of vitrol for PHP. Because it is so easy to use, many people are able to pick it up without any prior SE experience--these people tend to create poorly-designed, slow-running, and, perhaps worst of all, dangerous (vis a vis security) code.

The other major complaint that exists has to do with inconsistency/insanity in PHP's function signatures/naming/evolution. For example: mysql_escape_string and it's sister, mysql_real_escape_string. Although, anyone working with modern PHP probably will never touch these functions.

What is overlooked is that it has an extensive base of developers, it DOES scale (this is proven), and the language is improving (as well as the tooling (PHPUnit, XHProf, CI tools), frameworks, package management etc). And although Facebook does use it, it's important to note that, AFAIK, PHP only exists as a thin layer in between "display HTML" and "communicating with backend servers which are going to handle the majority of the work, save for presentation-layer type stuff."

There are a few alternatives to PHP, but they each have their warts too. Ruby is hilarious slow, for example.

I'm surprised people aren't quicker to mention the fact that PHP was (and still is!) responsible for many simple SQL injection database dumps/hacks. A simple string termination was all it took. That I felt gave PHP a massively bad rap as they spent versions after that trying to figure out a way to prevent/deter it.

Nowadays with wrappers it's thankfully less of a problem.

Having just come off a Drupal project myself but having looked at the latest PHP additions as well as Laravel though, it seems to me that many languages are converging and borrowing from each other, which I love. Latest PHP is pretty sweet.

And anybody who learnt of their own accord probably had Google rapidly lead them to w3schools, and if they were really unlucky they might have noticed they have PHP tutorials. Their database query code used to use mysql_query with absolutely no protection, the basic sql injection disaster scenario. It now uses non-prepared mysqli_query, which a quick Google tells me still isn't safe. I'm sure everyone here knows it, but w3schools is seriously dangerous and seems like it will indefinitely damage the image of PHP.

This really has been one of the cancers at the heart of PHP development. Most of the reasons people give for hating the language amount to semantic issues which make it different than the language they'd prefer it to be, or syntax which, while annoying, can be dealt with, or edge cases no one is ever likely to encounter in actual practice (although I just recently saw an example of someone's PHP where they were including php files using shell_exec so the rabbithole of 'actual practice' can get pretty deep.)

The way SQL is implemented and executed still primarily is one of the primary arguments against, at the very least, not learning PHP properly. And it's definitely a point in the column of any framework in any language which can say that SQL injection and remote code execution are impossible in frameworks written in that language.

Basically PHP is the America of programming languages.

> Ruby is hilarious slow, for example.

[citation needed]. Also, relevant Stack Overflow debate is available. [1] TL;DR: yes, of course Ruby is slower than, say, C, but today's bottleneck isn't hardware, it's developer productivity. (Developer time costs way more than hardware.)

[1] https://stackoverflow.com/questions/2529852/why-do-people-sa...

Depends on the task. Most of my programming is on the sysadmin side. So automation and log processing are two of the biggest things I deal with. I love Ruby to death. I'd program in it all the time if I could. And it works really well for automation. But for processing massive amounts of data? Not so much.

I even did some tests a year or so ago when I was writing a script to merge together data from multiple log files and a couple of databases, including data transformations, merging/collation and sorting of, oh 100GB or so of raw log data a day.

My first tests with Ruby were running pretty slow, so I decided to write the script out as I'd planned in both Ruby and Perl and compare the results on subsets of the data.

I used none of Ruby's OO features, I just did straight simple data structures, hashes and arrays, etc. Ruby has far better infrastructure for dealing with these things built in, and so I wrote the Ruby script in a couple of hours. The Perl script took me a couple of days--admittedly my Perl is rusty, but I wasn't doing anything complicated. But the language just doesn't have as much stuff built in.

Anyway, at the end I had two scripts with exactly the same logic, and I'd even had to implement some things (like Ruby's Array#uniq, which I assume (but don't know) is written in C) from scratch in Perl. So yeah I wasted 16 hours on the Perl script, but you could follow them line by line and they were identical.

Run them one after the other to compare, and the Perl script is literally 100 times faster and uses a tenth of the RAM. I told my Python-loving friends about this and they guffawed at the silly Ruby guy, but it was depressing.

So yeah, Ruby is slow at runtime compared to other languages. Usually that doesn't matter, but sometimes it matters a lot.

As an aside, Perl's uniq is in List::MoreUtils [1].

[1] https://metacpan.org/pod/List::MoreUtils

Developer Productivity in Rails means having a self-righteous excuse for hard-coding vital, tunable elements of your app and pretending you didn't just do that. A rails app is constantly under "development" because so much of it is just plain hard-coded in place under the guise of MVC and its single model of persistence: Active Record. Down-vote all you want. We've reached the turning point where you hear far more about big companies moving from rails, than switching to it.

I don't think there's enough attention on the fact that the strict MVC approach of big old school web frameworks like Rails is an increasingly glaring architectural dead-end. The "model" part of an MVC application is invariably far too complex to crowbar inside a couple of dozen Active Record subclasses. And you can't prescribe a one-size-fits-all architecture for the model from a framework level. That part has to emerge from the business and technical constraints of the specific application in order to be correct.

What you're overlooking here is the "model" part of an MVC application is not limited to being an Active Record object. Indeed, many experienced Rails developers are also major proponents of the use of service objects and "domain models" which can exist outside of the database.

The misunderstanding of when an MVC architecture is appropriate, and when to (and not to) use the framework, is the mark of someone who has not yet really understood how to use Rails effectively.

> We've reached the turning point where you hear far more about big companies moving from rails, than switching to it.

A lot of this is because 1) they jumped on the rails bandwagon without understanding it or if it suited their needs 2) after using rails to prototype their site, they now understand what their architecture should look like and want to start fresh 3) because they've joined the next circle jerk such ask nodejs

All the rest of your post is overly vague, or simply untrue. People pick rails because it has sane defaults eg. ActiveRecord but there are plenty of other gems for other database persistence layers.

Been a Ruby programmer for 5 years now and I find that this is dodging the issue. Sure the productivity is higher but what happens when you're finished developing and your code is now running in production? What happens when it's slow at serving requests, slow at any form of computations, slow when a rake task is starting?

Talking about productivity is a good thing because raw "power" doesn't mean anything, but I really wish we could admit publicly that Ruby is really not a race horse. It does other things awfully well and I wouldn't trade language for the world, but man, I wish it could get a free speed jump like Javascript got a few years ago.

There have been some steps in that direction, it seems. At my company, we made a graphics rendering engine in Ruby (haven't released it yet). In testing, it ran steadily, but consumed a lot of resources. But in each new version of Ruby, we saw that resource usage go down. Given that same level of innovation, we will see this graphics engine reach similar speeds as our current, more performant C and Lua implementation eventually.

Ruby 2.0 and 2.1 made incredible improvements to the garbage collector, a major source of our problem. We determined that it was the speed at which we were creating and destroying objects that was causing the GC to work on overdrive, which drove up CPU usage. So with the new GC improvements, we saw that usage go further and further down.

> I really wish we could admit publicly that Ruby is really not a race horse.

Ruby isn't a race horse.

It just turns out that when you're just plowing fields, harnessing up your prize stallion is a waste of resources.

> but today's bottleneck isn't hardware, it's developer productivity.

That's until you try to scale things.

Care to point folks to an example of a more modern PHP script that shows off improvements since the state of things in 2005?

http://laravel.com/

Laravel is a great framework and has really helped push the community towards writing tests and producing packages that can be easily shared via composer. Of course Symfony has a big part to play in Laravel's success to.

2013 was a good year for PHP. Most of the time when I hear people complaining about the language, it's as if things haven't changed since 2005.

There's a lot of horrible, badly written spaghetti code out there in PHP that doesn't exist in other languages, but there's also probably much more decent code written in PHP and I think that trend is only set to continue.

The only thing I think I don't like about Laravel is that it doesn't use Twig as the default template engine.

Fully agree. Check out twig bridge though.

Already using it. Autoescape and a function whitelist are beautiful things...

Thanks so much for your time! I was wondering whether you would suggest using PDO or mysqli for connecting to mysql via PHP?

From my personal experience I would suggest working with PDO. It is easy to implement, supports multiple drivers if needed and has named parameters in your prepared statements. The difference in terms of performance should be insignificant - although I think in some cases mysqli tends to execute faster.

It also has the merit for Perl developers of being more or less like Perl's DBI.

Reply on news.ycombinator.com