Live data from Hacker News

Hack Isn't PHP

marco.org

61–70 of 71 posts

Re: Hack Isn't PHP

#61
post #7

> This is exactly what the PHP world needed: making its already-fast performance many times faster (amplifying one of PHP’s biggest advantages over other common web languages) I think PHPs speed is largely exaggerated here. The interpreter always used to be slow, and before the bytecode cache it was plain awful. Im pretty sure it only ever got away with it because so much of the standard library is thin wrapping. Is…

PHP is fast - I've been there, made ~4k RPS websites in PHP & memcache.

There's one big, primary reason for it.

PHP is dumb.

You can't do clever things in PHP with the language, you have to all the clever things in how you design with it.

You can't overload functions or redeclare them later.

You can pretty much resolve a function at call-time, without worrying about decorators around it or about any meta-programming.

This makes for a fast VM in PHP, because it can make assumptions about function call-order much more than something like python.

Re: Hack Isn't PHP

#62
post #5

Zend the organisation, is probably what Marco meant when referring to poor stewardship, instead of the OS project Zend Framework. I like Hack because it explicitly doesn't support[0] a bunch of cruft from PHP. It feels a lot to me like the BC-breaking PHP.next people want - easy to switch to for modern applications, but not hindered by supporting PHP 4 code. Bit early to start pointing fingers at it's future though.…

> Writing list(, $b) = array(3,4) is not allowed. Instead use $_, i.e.: list($_, $b) = array(3, 4). Not that I think the former is good practice at all, but isn't the latter a kind of weird use of what is a valid variable name?

It is a variable, not a language construct. The docs are just recommending `$_` as a convention over something like `$temp`.

Re: Hack Isn't PHP

#64

>It’s developed and supported exclusively by one huge web company, and they may decide to deprecate and replace it in a few years as their technical needs change or its core engineers move on to new projects. Thats an interesting sentiment. The exact same could be said for languages like Go (Google), C# (Microsoft), Rust (Mozilla) and platforms like NodeJS (Joyent). In any case it doesn't seem like too much of a worr…

Objective-C as well.

Nitpick, C# is an ECMA standard that has a non proprietary implementation (Mono). I realize the best implementation is the CLR provided by Microsoft, but is feasible that should Microsoft abandon C#, others could pick it up.

Re: Hack Isn't PHP

#65

>It’s developed and supported exclusively by one huge web company, and they may decide to deprecate and replace it in a few years as their technical needs change or its core engineers move on to new projects. Thats an interesting sentiment. The exact same could be said for languages like Go (Google), C# (Microsoft), Rust (Mozilla) and platforms like NodeJS (Joyent). In any case it doesn't seem like too much of a worr…

Objective-C as well.

I'm pretty sure that I remember Objective-C (under gcc) from way back.

Re: Hack Isn't PHP

#66
post #57
post #25

> PHP isn’t a great language, but it is a good language. So what is a great language? If it runs the largest active user app on the planet (FB), the most widely used CMSes (WP,Drupal,EE), message boards, MVPs, etc. Why continue the hate, then end the article on how you've chosen it as the greatest option to run some of your systems.

Sure, FB, wikipedia, phpbb, wordpress. But when were those started? If you look at what's created today in startups and open source, PHP isn't a very popular language IMO

Lots of startups use PHP (with frameworks like Laravel4, CodeIgniter, Symfony) for their API and sexy new front end JS frameworks that they promote. On our current codebase, started in 2013, we decided to use PHP and have Ruby, JS, Python apps, where appropriate, that run on top.

Twitter, famously known as a Rails, now Scala, shop, has used php throughout its life (I know several php coders that have worked there). Their developer/documentation area is Drupal (acquia).

But moreover, as web architectures have become more distributed and JSON heavy, PHP has held onto its language position, especially with International devs.

As a CTO, not a employee, its also important to consider the salaries, roles of the people you need to build the platform.

SF Rails http://www.indeed.com/jobs?q=rails&l=San+Francisco,+CA&rbt=R...

SF PHP http://www.indeed.com/jobs?q=php&l=San+Francisco,+CA&rbt=Sen...

Then look at Non-US prices. Can't find a recent blog post where someone reported on salaries by language.

Re: Hack Isn't PHP

#68
This is hilarious because he was the lead developer at Tumblr.

I saw Tumblrs 'original' code base and it's a giant cluster fuck that is full of horrible design decisions.

They are still in tons of technical debt because of it. So it's funny to see him give an insight on PHP. Kind of ironic.

Either way, Facebook’s HHVM is not for 99% of PHP developers. Most PHP developers need better cache coverage and proper SQL architecture and approach.

Execution speed is not a problem for most of them.

Re: Hack Isn't PHP

#69
It not just the performance or code snippets available on internet for a particular language that matters to a programmer. The community around the stacks you are using to build the product is equally important.

Re: Hack Isn't PHP

#70
post #31

Earlier quoted context omitted.

> node is different, in that bizarre though js may be, if you have to use it in the browser, there is a kind of logic to using it on the server as well. I don thinkt that makes any sense. Should we also use js to implement the OS for the server? If js is good for server-side use it, if not use something else. My main issues with php is that I dont trust the language and standard libraries to behave as I expect. There…

> I don thinkt that makes any sense. Should we also use js to implement the OS for the server? We don't normally develop the OS ourselves, so what language it was written in is irrelevant. Same goes for runtimes, libraries, etc. If we're not responsible for maintaining it, it should not matter what language it was written in. Naturally, the "same language on client and server" argument can only apply to code we devel…

My argument was badly put.

What is the benefit of using the same language on the client and server? That the developer only needs to know one language?

The server-side code you write has to interact both with the client and the underlying OS. So you should consider how language X interacts with both client and OS, in addition to the intrinsic qualities of the language.

If we adopt a modular approach to software development, then I don't see any universal benefit to using the same language for all modules.

js might be a good server-side language, but choosing it because it works on the client is the wrong reason.

Post reply on HN