Live data from Hacker News

Taking PHP Seriously

slack.engineering

511–520 of 673 posts

Re: Taking PHP Seriously

#511

Earlier quoted context omitted.

> True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. The OP's question wasn't scoped to the mid-90s. > PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Like I said, the same holds true even for an OS thread. Anyway, if it's not a new OS process, then some sort of GC is needed, contrary…

To clarify, I didn't say that no GC would be needed, just that it can be much less robust, use quicker algorithms, and in many cases is simpler to actually implement.

This isn't true. A shared memory server doesn't require special, complex garbage collection algorithms--any generational GC will due, because request state lives in the youngest generation where collection is virtually free.

Re: Taking PHP Seriously

#512

Earlier quoted context omitted.

Why would that be surprising? NaN as a result definitely means that you cannot multiply array by object in JS either. JavaScript uses IEEE 754 special values, not exceptions on arithmetic errors (eg 1/0 returns Infinity instead of throwing). If you bother to learn the language, it doesn't surprise you.

The problems start when you notice that your untyped key-value store has a bunch of NaNs where you were expecting a number. At this point, all you can do is pray that those numbers weren't very important, in the grand scheme of things.

So when you do calculations with important numbers, you just push the results to the store without checking them and hope for the best? NaNs can happen in any language with floats, it's just that some languages also use exceptions in some situations.

Re: Taking PHP Seriously

#513

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…

Brian, do you have any examples of companies that failed using PHP that you think would have succeeded with another interpreted language, and what problems did they run into that gave you this judgment? Asking as I've developed in a slew of languages and never found the PHP-bashing credible. Most of the complaints seem to come from Rails people, but there are no shortage of MVC frameworks in PHP, including at least o…

I think it would be hard to provide such an example. Mostly because most companies that fail don't do it because of technology but rather because of the nature of their product itself, people, or money. And language plays a part in it but not a particularly noticeable one. Another reason is that failures tend to be silent and we don't pay attention to silent things.

Re: Taking PHP Seriously

#514
post #466

Earlier quoted context omitted.

Developers care about cognitive load, and people care about security. Sure, they'll be some guy who's memorised all of PHPs quirks, but for most of us the inconsistencies make it hell to program, because you're always looking up stuff. As a result, writing secure PHP is possible, but far harder than it should be. IMO the laughable security track record of e.g. Wordpress have damaged PHP's reputation more than anythin…

As a counterpoint, Facebook, one of the most secure companies in the world, is also the largest single PHP deployment in the world. C is also a language with a frankly horrific security track record; at least an order of magnitude more so than PHP. But C continues to be used because it is a useful and relatively simple language despite its warts and pitfalls.[1] Security is just as much a business process as it is a…

Or Etsy.

I think your comment about C is right, however in many cases mercifully the C code isn't facing the internet :) When it does, it can go very wrong, e.g. OpenSSL.

The extra cognitive load doesn't guarantee failure, it just makes it easier to slip up. Even with Python or Rust, you can put insecure code in there (e.g. with Python's subprocess.call(..., shell=True)). Realistically, strict modes and linters are always a good idea and can catch most of these pitfalls.

Re: Taking PHP Seriously

#515
Thank you for writing this - very eye-opening. One sentence doesn't seem right to me though:

> Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the cost.

Python 3 allows you to do that, too: https://docs.python.org/3/library/typing.html

Re: Taking PHP Seriously

#516
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…

Maybe it's just me but I do find a certain elegance in PHP. It's not beautiful by any stretch but it's extremely functional. You get the impression the Borg would use PHP. It's not pretty and it's not shiny but it works every time and it's extremely easy to work with.

Re: Taking PHP Seriously

#517
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…

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 think you are expressing some legitimate opinions about what kind of languages you like. Ruby, like Perl, embraces more than one way to do it. Some people like that, others find it irritating. Neither reaction is wrong. I think the same thing goes for your reaction to Ruby's lack of explicit interfaces. I find it liberating, you may not.

However what I find incorrect is the claim that Ruby is a garbage language. Then again, maybe that is best treated as hyperbole, as an exaggerated expression of your dislike for it.

Re: Taking PHP Seriously

#518

Earlier quoted context omitted.

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 obs…

Good questions.

Well firstly phpstorm is a very high quality. I can work with php code in various contexts such as running test suites, normal development and connecting to a live server. It definitely has good support for running and debugging test suites including unit, integration and functional. There is support for vagrant and docker as well.

The tooling is good because there are lot of users willing to pay for good tooling, but at the same time it can only exist if the underlying language supports the features needed.

I wouldn't say the libraries and tools give it a significant advantage over other languages actually, but it's a notable factor of php development that there is likely a framework and library for your needs.

Regarding training, once we had a reliable application and we'd figured out as a team some best practises regarding avoiding php's bad parts, how to avoid or detect and handle runtime errors and how to organize and layout code, it's a fairly simple matter to point a new programmer at these documents and code samples.

There's really not much to the language and a smart and/or experienced programmer can be productive in days. I'm not sure that's the case if you move someone from say c to Python or from Ruby to Scala.

Re: Taking PHP Seriously

#519

Thank you for writing this - very eye-opening. One sentence doesn't seem right to me though: > Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the cost. Python 3 allows you to do that, too: https://docs.python.org/3/library/typing.html

That sentence stood out to me as well.

Javascript has Typescript and Flow, both of which are very popular and allow you to gradually transition.

Re: Taking PHP Seriously

#520
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…

> A successful project needs to be started by someone that cares just enough, but not too much.

I'm going to frame these words and hang them on my desk.

Post reply on HN