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

661–670 of 673 posts

Re: Taking PHP Seriously

#661

Post by vancouverwill »

palerdot wrote: post #495
gopalv wrote: post #323

Earlier quoted context omitted.

> It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. PHP didn't succeed because of the "language" part. It succeeded because it was limited and focussed to just being a tool to write small web-apps in a short time. It did one thing and did it better than anything else of the same era (I built CGI apps in C, Perl and Python before discovering PHP). It was just f…

This comment just nails it. It is perfectly possible to have a well written code base in php. I don't understand whatever written in php is shit. Some good programmers genuinely point out some of the pain points of php, but most programmers paint php as shit just to show off as a good programmer.

Most definitely you can write good code in soho like anything it is a language which you are free to write in however you like.

However Php allows for really sloppy code (not failing on index misses, undefined variables still running, each core part of the language handling errors completely differently) which unfortunately often gets pushed out when not ready because of business pressures. This often creates insurmountable technical debt later on. The amount of confuaing, messy code I've seen in PHP that would not even run on other languages is shocking. The fact it has a super easy initial learning curve but progressively harder is not a benefit on big apps it just hides how many headaches it will cause you later trying to figure out the inconsistent core library once you are trying to do more than hack WordPress templates together

Re: Taking PHP Seriously

#662

Post by abritinthebay »

qaq wrote: post #47
abritinthebay wrote: post #37

Earlier quoted context omitted.

It's extremely mature, stable, reliable, and easy to reason about. Personally I wouldn't choose it but, for a larger company, if you already have engineers that know it - and trust me many will - it's not a bad choice. This is especially true if you are just serving a simple website for a product or service, even basic e-commerce. 90% of websites out there don't need Rails, or Python, or Go, or Node.

Y but it's so slow to evolve it's just sad. We've being using hacked on "traits solution" since 2006 (via build script) and PHP only got traits in 2012 and on and on. A lot of things that could make it more modern get shutdown.

Modern for the sake of modern isn't needed for a good app.

Especially a web app.

Stability, availability of developers, and ease of debugging however are important. PHP has those. Granted it's not the only one, and I think there are better alternatives, but it's really easy to write a good app in PHP.

Bad coding practices and bad application design will make ANY app have bad code. PHP just historically had a lot of that.

Re: Taking PHP Seriously

#663

Post by mastazi »

mrmondo wrote: post #422
mastazi wrote: post #335

Earlier quoted context omitted.

I have worked on both (among many other languages) and I too prefer PHP, but I guess my opinion on Ruby is unfairly distorted by Rails, which I dislike a lot. I hear that Sinatra is nice, for example.

Could not agree with your statement enough, just like Django really is a heavy burden for python when you could use flask etc... for most things.

Yes, Django is in some ways similar to Rails but, at least, in Django I know how to exclude some parts of the framework (e.g. if I don't want to use Django forms, I'll just go on and use vanilla HTML forms, if I need raw SQL, I'll go for that rather than Django queries). I suspect that the same kind of thing is, at least to a certain degree, possible in Rails as well, however it seems harder to achieve because in Rails the components that make up the framework seem very tightly coupled. Obviously the opinion that I have formed may be distorted by the fact that I know Django/Python quite well, whereas I know little about Rails/Ruby.

EDIT: obviously I agree with you that, if you want more freedom and if you are not using many of the features that Django offers, then it would make more sense to use something light-weight like Flask, which is a very nice framework.

Re: Taking PHP Seriously

#664

Post by gregormck »

bartread wrote: post #490
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…

So much this. So, so much. So much time wasted talking about the "right" way to build software, and the best technologies to use, taking positions to bolster your CV or make a name for yourself, and nowhere near enough emphasis on shipping useful, working software. It drives me slightly nuts. Many people don't realise that technical debt is often a great problem to have because it means you've succeeded. They also wa…

Well said

Re: Taking PHP Seriously

#665

Post by dpcx »

cagataygurturk wrote: post #614
dpcx wrote: post #255

Earlier quoted context omitted.

IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"

> IMHO, developer time is more expensive than CPU time I see that you've never worked on a project where the CPU time needed to handle the traffic with crappy code is much more expensive than developer time to write efficient software.

I have. And one of my first steps after starting to clean things up is to switch to composer and autoload; because then I can start ripping things out much more easily, and still make improvements to both code quality and performance.

Re: Taking PHP Seriously

#667

Post by niutech »

nrser wrote: post #406
justinhj wrote: post #366

Earlier quoted context omitted.

It is easy if you are just willing to spend more money on servers. Often it's worth it.

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…

Why didn't you choose Python/Django instead of PHP then?

Re: Taking PHP Seriously

#668

Post by niutech »

greggman wrote: post #348
gopalv wrote: post #323

Earlier quoted context omitted.

> It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. PHP didn't succeed because of the "language" part. It succeeded because it was limited and focussed to just being a tool to write small web-apps in a short time. It did one thing and did it better than anything else of the same era (I built CGI apps in C, Perl and Python before discovering PHP). It was just f…

I'd argue it succeeded because it didn't require you to run a server. All those cpanel lamp ISPs mean sign in and upload code. All other solutions, java, .net, node, python, Haskell, etc require you to run and maintain your own servers. A minor exception for CGI based solutions but those were all too heavy.

I think this is the main selling point - PHP is everywhere, almost for free.

Re: Taking PHP Seriously

#669

Post by igouy »

ransom1538 wrote: post #496
ddw wrote: post #353

Earlier quoted context omitted.

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks. https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...

Perhaps the problems are with the way the Java program is written and run?

Back in 2012:

"5) The idea is to help you understand that you aren't comparing what you say you're comparing.

If your intention is to compare time taken to grow a list, then shouldn't you start with lists that are the same size, and start with program heap that's the same size, and use the same max heap size?

        user+sys for your Java program = 20.56s
But change

        ArrayList s = new ArrayList();
to

        ArrayList s = new ArrayList(8192);
and run with

        java -Xms1G PrimeNumbersBenchmarkApp

        user+sys  = 6.9s
I don't think you're comparing what you say you're comparing."

http://www.famzah.net/download/langs-performance/java-discus...

Re: Taking PHP Seriously

#670

Post by igouy »

Shanea93 wrote: post #606
pritambarhate wrote: post #561

Earlier quoted context omitted.

This benchmark shows things a little bit differently. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... But I think, what's important to note is that PHP 7 has improved in speed department by a great deal.

It's probably worth mentioning that the regex-dna test time is kind of incorrect and provides an inaccurate view of what's happening. Java-8 is using java.util.regex which is written in Java, PHP is passing the regex requests to it's own regex process which is actually a C package and performs a lot faster. What we're actually comparing here is: time(java.util.regex) > time(php compilation + c regex package)

> Java-8 is using java.util.regex No, the fastest Java program shown does not use java.util.regex

The fastest Java program shown uses com.basistech.tclre

> a C package and performs a lot faster You're welcome to contribute a Java program that uses the PCRE library --

http://benchmarksgame.alioth.debian.org/play.html

Post reply on HN