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

371–380 of 673 posts

Re: Taking PHP Seriously

#371

Post by justinhj »

peteretep wrote: post #223
ux-app wrote: post #183

Earlier quoted context omitted.

and miss out on all the awesome aspects of the language/environment?

What are "all the awesome aspects"? The being embedded in the web server and the benefits that brings I understand. The rest?

Disclaimer I worked on a large php app server that ran on about 50 servers and I miss it.

The documentation is really good. A model for programming language documentation.

Process per request is really simple to understand and scale. Your servers almost never crash completely, you don't get threads silently dying or run out of memory or thrash the CPU doing garbage collection.

It runs like a tank. It will, for better or worse, just keep running when more fussy languages would have seg faulted or shut down

The tooling, framework and libraries are very advanced and in active development

It's easy to train a programmer in php

It's close to the c library

The combination of a very flexible array/map and functional programming tools like map and reduce let you write pretty declarative code and development can be very fast

Php storm

Facebooks replacement runtime

I work with Java and Scala now which I also love but development is much slower and more expensive, whilst deployment is cheaper (less hardware for same request throughout)

Re: Taking PHP Seriously

#372

Post by justinhj »

Aldo_MX wrote: post #202
wyager wrote: post #153

Earlier quoted context omitted.

It's not just about the obvious "warts"; it's about the fact that PHP is not a well-designed language on the first place. A wart-free pig is still a pig.

Which of the top languages is actually well designed? All of them have their area of opportunity.

Look at c++ as a counter example. Once immensely popular and yet I don't think many people would say it was well designed

Re: Taking PHP Seriously

#373

Post by eyelidlessness »

jwatte wrote: post #358
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…

Delivering enough value to users, faster and cheaper than the competition, wins. The language you use pay second- and third order dividends, but most battles are fought and won on first order. I'm a C++ developer, have shipped Java and C# and Haskell and Python and a bunch of other code in production. If a friend asks me to spin up a website for him/her quickly, I'd still do it in PHP. Horses for courses.

What does PHP offer, now, that a static site generator doesn't? I'm going to guess Wordpress, WYSIWYG editor, simple uploads. But if that's not it, I'm genuinely curious.

Re: Taking PHP Seriously

#374

Post by tensor »

labrador wrote: post #239
mrmagooey wrote: post #218

I'm surprised no one has posted this fairly thorough criticism of PHP from a few years ago https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

There was a time I thought Toyotas were beautiful cars and American cars were crap. Then some years later I had two occasions to rent a car. The first time I got a Toyota. Absolute crap. The transmission couldn't stay in the same gear with even slight inclines. The next time I rented a Chevy Malibu. An absolute dream. Loved that car. I learned a lesson to not let my prejudices prevent me from taking another look.

A sample of two very short term rentals is an awful way to judge cars on long term traits like reliability.

Re: Taking PHP Seriously

#375

Post by nostrademons »

tluyben2 wrote: post #342
brlewis wrote: post #102

Earlier quoted context omitted.

I do think certain languages are more conducive to the "just write it quick" mindset. I find it easier to enter this mindset when I write a bash script.

I find this interesting because I feel that is true and if it is true, then there must be some definable reason for it. So what is it? I have this with Perl, PHP, Bash, C(!), Lua and pure (browser) JS with Jquery (not npm, CSS and HTML though => those keep me from even starting something when I think too long about them). I would think I like Lua & C to just write it quick because they are so limited; I remember thei…

Opportunity cost - mental energy you spend thinking about which frameworks you're going to string together or how you're going to make the perfect abstractions or how you can make your life as a programmer easy is mental energy that doesn't go in to solving your problem.

There's a balance, too - if you spend zero mental energy thinking about how to make your life easier, you tend to get spaghetti-code monstrosities that PHP (and Visual Basic before it) are known for. The trick is to live with some discomfort and some suboptimal solutions so that you can finish the job you set out to do, and only worry about how to do it better when it becomes apparent that you're going to be doing it a lot.

Re: Taking PHP Seriously

#376

Post by rahul286 »

We are mostly (95%) a PHP company but going by trends; we did some projects in Python, NodeJS and Rails a few years ago.

Now I look back; I see the projects which have technical debt were flawed in design and did not get maintenance they needed. Most of them did not get traction to the point where scalability issue came into the picture.

So this year, we started moving that 5 % non-PHP projects to PHP counterparts. Again, we are miles away from any real-world scalability issue, but at least we are now able to maintain projects as we have a large PHP team.

At a small to mid-size organization level, it is more important to use one language for all projects.

I believe technical debt is not related to the choice of language but anticipating direction a project might take and picking up right design patterns to support that.

Which programming language is better is a highly overrated question!

I wish I had learned this few year ago.

Re: Taking PHP Seriously

#377

Post by eyelidlessness »

userbinator wrote: post #241
toast0 wrote: post #120

Earlier quoted context omitted.

> If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. This is exactly right. The right philosophy for PHP is to embrace the garbage. When you're done with a request, and have spit out all the HTML to the client, the server is going to throw everything away. So don't build a…

Indeed it's very much a "worse is better" philosophy throughout.

Not really. It's just a "worse is" philosophy.

Re: Taking PHP Seriously

#378

Post by lost953 »

ddw wrote: post #356
hondo77 wrote: post #288

Earlier quoted context omitted.

If I wanted to embrace garbage every day I would have skipped college and went straight to being a bum. Life is too short to "embrace the garbage" every day.

This. Developer happiness matters.

Not nearly so much as customer happiness does.

Re: Taking PHP Seriously

#379

Post by skarap »

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…

In fact you can create a "daemonized" webserver in PHP and handle each request in a special handler function. For async case there is ReactPHP (http://reactphp.org/), don't know any product for sync case, but creating one is certainly possible.

And you can also set up Ruby, Python, Rust, Haskell, Java, etc to create a new interpreter/vm/whatever for every request. All of those languages have libraries to support CGI. Using the same OS process but restarting the interpreter/vm will be a bit more complex, but absolutely possible. You can even implement the "every file is an entry point" approach for at least Python and Ruby.

The difference is what is the intended use for each platform. E.g. creating a new OS process, loading the PHP interpreter, bootstrapping Wordpress, getting some data from the DB and rendering a page is possible under 600ms while creating a new OS process, loading the CPython, bootstrapping Django, getting some data from the DB and rendering a page will easily take you 4 seconds. This is because Django developers didn't expect you'll be doing that, so they put a lot of stuff in the initialization step (system checks, creating db connections, setting up logging, ...).

Re: Taking PHP Seriously

#380

Post by bbcbasic »

eyelidlessness wrote: post #373
jwatte wrote: post #358

Earlier quoted context omitted.

Delivering enough value to users, faster and cheaper than the competition, wins. The language you use pay second- and third order dividends, but most battles are fought and won on first order. I'm a C++ developer, have shipped Java and C# and Haskell and Python and a bunch of other code in production. If a friend asks me to spin up a website for him/her quickly, I'd still do it in PHP. Horses for courses.

What does PHP offer, now, that a static site generator doesn't? I'm going to guess Wordpress, WYSIWYG editor, simple uploads. But if that's not it, I'm genuinely curious.

Dynamic content.
Post reply on HN