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

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

441–450 of 673 posts

Re: Taking PHP Seriously

#441

Post by stevesun21 »

agentgt wrote: post #332

It is not entirely clear if the author aka Slack chose PHP with these reasons in mind apriori or did they choose PHP first and are now justifying why their choice of PHP is not bad. I'm going to guess they picked PHP because they knew PHP and not because of the nice reasons mentioned in the article. That is the article should be "why slack is sticking with PHP". Almost all the major languages are actually (despite lo…

Agreed, and only thing I want to mention is that 'Productive' which people normally think about how fast to develop rather than measure it within the whole system development life cycle – code easy to read and maintain, tools for test/profiling, logging, deploying etc.

Re: Taking PHP Seriously

#442

Post by SideburnsOfDoom »

Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

> you don't need to worry about async IO or multi-threading

Isn't there a downside to that? If you want to do multi-threading, you can't just do `ThreadPool.StartNew(() => doSomething())`. You're SOL.

Re: Taking PHP Seriously

#443

Post by mtberatwork »

haimez wrote: post #361
jwatte wrote: post #359

Earlier quoted context omitted.

The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model. You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!

Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.

> Yeah, but you also have to fork a whole process per request to do it.

Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.

Re: Taking PHP Seriously

#444

Post by SideburnsOfDoom »

akie wrote: post #399
menelaus35 wrote: post #364

Write an API for my client app which returns user's data as JSON (or render HTML page for profile); You: { mysql_connect("host", "pass"); mysql_select_db("users"); $uid = $_GET[ "uid" ]; $res = mysql_query( "select * from users where uid = $uid" ); $ar = mysql_fetch_assoc( $res ); echo "name: " . $ar["name"] . ","; echo "location: " . $ar["location"]; ?> } Just call it http://domain.com/api.php?uid=USER_ID ( Yeah I k…

Not sure if intentional or not, but your code has an SQL injection vulnerability.

Relevant and crushingly obvious XKCD: https://xkcd.com/327/

If it was an intentional joke in the grandparent post's code, then it's not one that came across well.

Re: Taking PHP Seriously

#445

Post by nrser »

dakull wrote: post #415
nrser wrote: post #406

Earlier quoted context omitted.

it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be. i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale. everyone is tearing away adding features, and t…

>php's performance was an order-to-two or magnitude better than rails Again PHP (the language) vs. Rails (the framework). What framework was that `big php app` using?

as the other commenter said, php is a web framework... and it's what we were using. it's actually more of a web framework than a language in my opinion (or at least was at that point). it's centered around receiving http requests and writing http responses. the article mentions this in fact.

it was a huge pain to try and get php to do anything else. it was totally unpractical to do the kinds of back end processing that we needed (since the database was pretty much off limits during a http request)... long running processes with hundreds of millions of objects were a no-go. believe me, we tried. which meant you had to sync all your logic into Java or something else that could handle the job. which is really error prone when you have a bunch of people moving fast on something.

one of the greatest things about php is that it's a super minimal focused framework. it's also one of it's major short-comings when that model no longer suffices.

you can layer something else on top of it, but the stuff available at the time certainly didn't help the performance or memory characteristics.

Re: Taking PHP Seriously

#446

Post by nsomaru »

regularfry wrote: post #416
cakeinblue wrote: post #333

Earlier quoted context omitted.

After I use both php and ruby for the same employer over more than a year. I would rather say Ruby is more like a garbage language -- 1) twist syntax to allow people write the same function into different ways is not a cool feature, it is disaster feature which causes more for a team to sync. 2) Duck typing is not interface, don't kidding yourself. they are totally two different thing. 3) ruby attract a lot of master…

> good luck with writing a unit test against an API not created by you Is that a good idea?

why not, if the function is untested and plays an important role in your application?

Re: Taking PHP Seriously

#447

Post by arenaninja »

codedokode wrote: post #429
hiou wrote: post #329

Earlier quoted context omitted.

Actually it throws an E_NOTICE. Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE? $a = notice_there_are_no_quotes; echo $a; // $a gets assigned the string 'notice_there_are_not_quotes' This is super fun when you attempt to use a constant and misspell it. $b = MY_CONSTANTT; echo $b; // $b is now the string 'MY_CONSTANTT' instead of whatever the correct MY_CONSTANT was…

> Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE? That is true only for low quality legacy code. I have always developed with all kinds of errors enabled and converted to exceptions (that means single E_NOTICE terminates the program with exception as it is done in Java). Modern frameworks like Symfony 3 or Slim use the same approach. If you write a project using Sym…

IIRC PHP3 didn't even have objects

PHP4 introduced objects and is the language people shit on when they say PHP doesn't have real OOP

PHP5 introduced Java-like objects PHP5.3 introduced namespaces

Re: Taking PHP Seriously

#448

Post by __s »

increment_i wrote: post #336
brian-armstrong wrote: post #98

Earlier quoted context omitted.

I'll offer an alternate hypothesis. Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to cherry-pick the winners and miss all of the t…

It would be an outlier company indeed who held an 'all hands on deck' meeting and said, "We're succeeding in spite of PHP everyone!" Only engineers care about programming languages. Seriously. That's it. No one else cares about them. I work in a large public university alongside a revolving door of student interns who are always 19. In 10+ years of work, I've still yet to meet the person who talked about their favour…

I work at a company that use to do PHP, but now only does asp.net for web projects. We dread having to maintain our legacy PHP code

Re: Taking PHP Seriously

#449

Post by bluetwo »

I just want to use whatever tools we will be using in 5 years. While the underlying technologies of css, html, and javascript have gotten cleaner, powerful, and more cross-compatible, everything that sits on top seems to have gotten bloated.

Re: Taking PHP Seriously

#450

Post by frostymarvelous »

swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

This is why I first build my projects in PHP and only move them to ASP when they succeed!
Post reply on HN