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

481–490 of 673 posts

Re: Taking PHP Seriously

#481

Post by spdionis »

qwertyuiop924 wrote: post #266
codedokode wrote: post #236

Earlier quoted context omitted.

I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. Ruby libraries use approaches like monkey-patching classes in other modules. And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?

Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system. There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.

And npm doesn't even have a lock file!

Re: Taking PHP Seriously

#482

Post by apotheon »

justinhj wrote: post #371
peteretep wrote: post #223

Earlier quoted context omitted.

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…

Can you describe for me how the tooling, framework(s), and libraries are so advanced and excellent?

How easy is it to train a programmer to use PHP in a way that results in fairly secure, reliable, bug-free code? (Note my use of the word "fairly", knowing that there's no such thing as perfect security, reliability, or freedom from bugs.)

I do know that, for instance, TDD is possible with PHP. In my experience and observation, though, the available developer tooling does not even come close to that of (for instance) Ruby, so I figure I must be missing something if "the tooling, framwork[s,] and libraries" constitute a major advantage to PHP over other options.

Re: Taking PHP Seriously

#483

Post by dfsegoat »

ryanlm wrote: post #331
tyingq wrote: post #21

Earlier quoted context omitted.

>>Why are there no other "competitors" in this space? There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples. Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexit…

Can you set up Python to have the same pattern as PHP? I've always had to proxy the web server to the Python process running HTTP.

Yeah, I run new django apps right alongside my php5 code. It does definitely take a bit more "muss and fuss" than php5 to configure (mod_wsgi, etc) but is just as easy.

You also need to restart apache or change the wsgi loader file, (or set up explicit hoooks to do so) to get your new code to appear when debugging / after uploading changes. This is where I'd say php is superior (upload file, refresh browser).

Re: Taking PHP Seriously

#484

Post by sbarre »

bradleyjames wrote: post #458

My assumption is they already knew PHP before setting out on this (if not I'd be interested in hearing about that). What you know is a huge part of these decisions. I doubt many of the sites noted truly picked PHP after sitting down and doing a comparison of all the popular languages across the board. Their systems grew out of what they knew and there was no time to rewrite or maybe there wasn't a need either. If you…

> Regardless of their findings I wouldn't recommend anyone learn PHP if starting out.

This is bad advice.

If you are a new programmer starting out, first of all you should learn a few languages, not just one, but also, why would you not want to learn one of the most popular and prolific languages in the industry you are trying to enter?

If you want to work in the web world, not knowing PHP will close lots of potential doors. They may not be the coolest of the cool but not everyone has the luxury of being that picky when looking for work.

Of course if you are an exceptional developer and/or you live in one of the insular startup hubs (SF, NYC, etc), then you can get away with being picky and sticking to the bleeding edge or the du-jour tech stacks and you'll probably get hired, but for the majority of people entering the web development world, that may not be the case, and they should be more pragmatic.

Even if you don't specialize or focus on PHP, knowing how to code in it will help you land jobs and advance your career.

Re: Taking PHP Seriously

#485

Post by [deleted] »

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…

[deleted]

Re: Taking PHP Seriously

#486

Post by raarts »

bartl wrote: post #430
haimez wrote: post #361

Earlier quoted context omitted.

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.

"fork" is not a major problem in PHP. In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. That is what slows it down. It's remarkable that PHP still manages to do that in just 100ms. In Zend Framework it's slightly better because it includes an autoload option, which implies only PHP files that are actually used by athe request, get loaded. That way the overhead is…

> In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code.

This only proves Drupal is slow.

Re: Taking PHP Seriously

#487

Post by cakeinblue »

mastazi wrote: post #335
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…

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.

Sinatra is good, in the last few months, I use grape a lot.

Re: Taking PHP Seriously

#488

Post by raarts »

NMDaniel wrote: post #272
ux-app wrote: post #183

Earlier quoted context omitted.

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

There are plenty of great server-side languages and environments. C#,Java,Scala,Python,Ruby,Haskell. If this was about JavaScript and Front-End I might've agreed with you (there are transpilers but interoperability with JS modules can be tricky), however in the realm of servers there's so much freedom.. so why choose PHP out of them all?

C#: windows or mono-on-linux

Java: keyboard wear

Scala: not enough programmers

Python: not bad

Ruby: too slow

Haskell: math grad required

Re: Taking PHP Seriously

#489

Post by avisser »

dpcx wrote: post #255
toast0 wrote: post #157

Earlier quoted context omitted.

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing…

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"

> I don't want or need to have to write out all of those requires. That's the job of the autoloader.

Or the IDE. IntelliJ or ReSharper does that for me. And I like dealing with any naming conflicts right then and there, which those tools allow me to do.

Re: Taking PHP Seriously

#490

Post by bartread »

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 want to live in this reality distortion field where they ignore the fact that the code they write today is tomorrow's technical debt because, for reasons I don't fully grasp, they think they're going to do it "right" this time. To quote from Garth Marenghi's Darkplace: "Uh-huh? Bye." In 5 years' time our successors will be wandering around moaning about the crappy code we wrote today, but only if we succeed.

If PHP is the fastest route you know to releasing something worthwhile then more power to you.

(Just to be clear though: I'm not advocating an end justifies means approach to all areas of life.)

Post reply on HN