I've had to do some PHP work recently, on a fairly old school PHP codebase for a high traffic website, after spending most oy my career working in Java and C# (and I still do most of my work in those languages).
I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major updates, and they've proven to be far less painful than I had expected based on the amount of PHP attacks I'd read online.
Maybe the snobbery toward PHP is a good thing? There are some really big PHP-based communities out there, Wordpress being probably the largest. And in these communities, there appears to be a large demand for paid consulting and plugins. Sure, there's a ton of competition on the low end, but it's an area where a really great developer could stand out from the crowd and do very well financially, especially for more complex consulting and dev work since so many good developers turn their noses up at PHP.
As long as you don't mind working on "boring" projects, there is TONS of small businesses in need of custom work to be done. It's very lucrative, because most people like you said, turn their noses up at the thought of it.
Boring isn't always bad. Last time I tried to create an interesting project, I ended up with a couple hundred MB of node modules before I'd even done much. :)
That's a fair criticism in node... I wouldn't want to work on it without an SSD (deployment is a different story)... the spinup and even npm install time on an HDD is dramatically slower than SSD.
It's also not that hard to roll your own system and avoid many of the modules and frameworks in the space. The first API I wrote using node wasn't bad at all, and in the end actually simpler than the rewrite using express... And by the time you get to Hapi with a few addon modules for your needs, it'll get pretty big.
All of that said, I still prefer it to just about everything else I've worked in... though I haven't done anything on Go or rust, but would like to.
Yeah, the size of my node_modules directory doesn't bother me that much. I've worked on some large Node projects in the past, and didn't care too much about how many modules I had installed because I wasn't exactly running out of disk space.
It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after running Webpack or Browserify bother me a lot more. Since we're using npm for pulling in front end dependencies, and CommonJS modules aren't statically analyzable, tools like the Closure Compiler and Rollup can't perform a lot of their advanced optimization and tree shaking. We'll get to a better place soon enough, though.
Yeah, the migration to ES6-style modules, Webpack2 etc will help a lot. There's still some bits to work out... about ready to do a new version of a few module in NPM and just declare that said module need to be used with babel+es6, async functions and decorator transforms... I'm tired of waiting, and it'll make the modules themselves cleaner not having to transform before publishing to npm in the end.
It's funny that a lot of this stuff is finally making it into the browsers and platform, when I've been using it for almost 2 years now. Looks like async is going in behind a flag in node 7.
The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Python, Ruby and even Node.
The Wordpress codebase [plugin api included], though, is utter garbage.
> The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C.
It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3])
You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. The most the PHP devs have done is deprecate methods and add features. That's great. I think that changing something, that has been there since the beginning, to a new behavior is stupid. Much much much worse then having ternary work backwards.
> The Wordpress codebase [plugin api included], though, is utter garbage.
> On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it.
If you read the thread, no one could actually recall having ever seen code that relies on the current behavior. It has been discouraged in the docs for years. The stop-gap proposal was to have PHP7 deprecate it with a warning rather than silently changing the behavior. Then change the behavior in a future version (say php 8).
Disregarding any of that, this is an admitted language bug. It was not ever meant to work this way. Do you have a list of languages where ternary works backwards? PHP devs don't just work in PHP. Having one C-style language work this way and another C-style language (js) in another editor tab work the opposite way is a major PITA.
> It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?
It is also internally inconsistent in so many ways.
Half the array functions take arrays as the first arg, the other half the last.
explode and implode have different argument order requirements (one is strict, the other works either way).
Functions have a grab-bag of errors from returning null to false to 0 to strings to requiring error\_get\_last to even requiring an object specific error function (DateTime::getLastErrors).
Functions were named to make them have more randomly distributed hashes (http://news.php.net/php.internals/70691). Functions randomly do or don't have underscores, sane order, etc.
Some apis are in terms of objects (DateTime), some are not (getdate).
The whole thing is far less consistent than C. Some inconsistencies are from C. Most are PHP shit layered on top.
> You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
It's a C-like language. Every c-like language does it the other way. I will totally judge a language that makes a decision that makes programmer's lives terrible with no justification. In this case, it's different in a way that often leaves to bugs and surprises.
That's not the same thing and you know it. C++ didn't just randomly change the associativity of one of the operators. PHP screwed up ternery in a way that makes zero sense (ie, it's wrong in 99.99999% of use cases). It still catches me (and my colleagues) off guard even though we have years of collective PHP experience.
It doesn't matter, we're talking about php not C++. But yeah, "<<" and ">>" are at fairly internally consistent within C++ and don't generally confuse programmers or cause significant bugs in my experience, so I don't find them problematic. They did seem a bit weird at first, but they didn't cause significant problems.
Perhaps they do for you, and I accept your complaint about those operators as valid actually, but it's on a whole different level of badness than php, and again, we're talking about php. Just because "other languages suck" doesn't mean php doesn't, so that's not a valid argument against anything I said.
I'm saying neither of them suck. They both have small things "Wrong" with them that are only "Wrong" because I don't like them.
>they didn't cause significant problems
That's not a valid criticism of any feature. I'd say that the worst feature of any programming language yet has been pre and post -- and ++. Some of the nastiest bugs I've seen have come from there.
In both cases I avoid them. I only really use -- and ++ if I need to, just like ternary operators.
> Just because "other languages suck" doesn't mean php doesn't,
Ok what about other languages that are good? Python's ternary operator isn't the same as C-style languages but I still think of Python as being good.
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps
Well, breaking backwards-compatibility comes at a cost. Avoiding another PHP 4/5 or Python 2/3 situation is the goal. It doesn't mean nothing gets changed: PHP 7 has a long list of backwards-compatibility breaks.
> The Wordpress codebase [plugin api included], though, is utter garbage.
I've always heard this and never actually used Wordpress myself. Has anyone ever studied WHY its garbage? and how did it get to that state? is it getting better or are the latest additions and changes still garbage code?
WordPress is popular, php is accessible (you need notepad and an ftp client to start hacking) - combine the two, and you get a lot of "scratches my itch"-code.
It probably doesn't help that WordPress is an ancient code Base with a goal of running on the cheapest webhosts (who are slow to update to newer php releases).
So you get a lot of beginners that learn from messy old code, that generate more of the same.
It's a mess of global and file-wide variables, an unholy mix of poorly structured procedural code married with the odd "OO" abstraction.
There are good, even great php code bases - WordPress - and its plugins are not that.
To be fair, WordPress itself, and the core plugins are at least somewhat consistent, and after years of security holes follow a somewhat reasonable defensive coding practice. The terror lurks in popular third-party plugins, inspired/forked from older hacks. As is evidenced by a quick look at full-disclosure where seemingly every week someone's managed to make a plugin that's broken in some novel manner.
I've not been following closely lately, but for a plain php cms, one could do worse that cmsmadesimple. It's (was) pretty old-school simple php, but much simpler than something like Drupal.
The part that I didn't really understand is people accepting pull requests should be gate keepers for code quality, so amateur or not hopefully this shouldn't pollute the codebase. But you've touched on the core being reasonably decent and the real mess being with third party plugins so that makes more sense.
PHP was the first programming language I ever used, so it holds a special place in my heart. And I use it daily at my current job.
I have to disagree with this article. PHP is a heavily flawed language. It's very easy to get started with PHP, but there are too many pitfalls that are too easy to fall into.
Most of the "Virtues of PHP" are available in other web languages if you use the right framework. And if you use those languages you'll benefit from the consistency and predictability that come from having a clear design philosophy from the start.
I don't think PHP is a bad language. It's possible to write good software in PHP, and it's possible to work around the flaws if you really know what you're doing. If your software is already written in PHP, it's probably not worth it to throw it out and rebuild it in something else. But I don't think it's worth the trouble if you have a choice, and I think writing new software in PHP should be avoided.
I'll admit I'm not familiar with HHVM and Hack. Maybe they alleviate PHP's problems.
P.S. Most of the points under "The Case Against PHP" are also issues with Javascript. But the difference is that if you're developing a web application, you have to use Javascript. You don't have to use PHP.
Zero startup time and a serious JIT aren't actually available in Python or Ruby even after all these years.
I would be hesitant to dismiss the significance of those - although I'm admittedly biased, having worked with Keith previously as well as on an erstwhile "competitor" to HHVM (talariatech.com).
My pretty heavy Django app takes about half a second for Gunicorn to boot 6 workers then it's off to the races. That might as well be zero startup time.
Similarly many of the node apps I've worked with have about a half second or less of startup (unless pre-warming database connections, that takes more time).
Well this is seriously making me rethink my opinion on the PHP workflow, if Hack is as much of a game changer as the article claims? Could anyone here comment on their experiences with it, and its pitfalls?
Well HHVM is quickly losing ground to PHP v7 in terms of speed. I'm not sure which is "fastest" any more, but IIRC it's close enough that if you want to switch for the "speed boost" I'd argue it's not worth it.
In terms of Hack as a language, it's very similar to the JavaScript->TypeScript relationship. It's still mostly PHP, but it doesn't quite get the new PHP features as quickly, and there is the chance that there could be incompatibilities in the future which could cause new PHP code to start looking and acting differently than Hack code.
You're asking about Hack, and the only response I see so far is about HHVM. So!
I've seen Hack used in a multi-tens-of-MLOC codebase to gradually insert types. It made huge differences in the kinds of changes that were possible; you can, e.g., rename a class or method, or change the order of its arguments, with confidence comparable to that in a C++ codebase. Most developers hack-ified everything they could get their hands on, and did all new work in Hack, without any external encouragement.
Yup, this. I work on (the original?) multi-tens-of-MLOC PHP-cum-Hack codebase, and writing new code is every bit as safe type-wise as C++, with none of the compile time. It's pretty great.
Dealing with the parts that aren't Hackified, though, is horrific. Complex codebases with no types are just ridiculous.
I've been playing around with Hack in Vagrant in my spare time, messing with an experimental HN clone, so all of my experience is in terms of being an amateur, and certainly not on the bleeding edge of anything, but for what it's worth:
The XHP plugin[0] (which you can include as a Composer dependency, but you have to be able to run Composer directly under the HHVM daemon and not PHP) allows XML to act like a first-class citizen. No more interpolating between HTML strings and having to escape all of your variables, you can now just do
echo <b>{$possibly_evil}</b>;
and it just works (and auto-escapes.) You can even extend the XML root object to create your own tags[1]. Combined with Hack's native autoloader[2] (which allows whitelisting constants, functions, tags and types) Hack provides a lot of the features PHP developers will find standard in most templating frameworks, without the overhead of the actual framework.
Another benefit (possibly) is that improperly formatted XML will break with an error, so it's guaranteed that if your document renders, it's correct.
Hack allows generics, type hinting and aliasing[3-5]. These only apply when running the typechecker, however, when the code is running, everything decays to basic PHP primitives. I've been bitten a couple of times by this, because you might expect that you could use an aliased type as a typehint - you can't. You can define it as a return type, though.
Collections, like Maps and Vectors (oh, it has maps and vectors), can have immutable types[6].
Hack also supports "async" functions[7], which really aren't asynchronous. I found it a bit difficult to get this to work with curl and SQL the way I want to, but anything that helps remove the bottlenecks of database and network requests is welcome.
To me, Hack just feels like a better more sane PHP. All of the strictness is optional, but it still feels very good to have it there, and it has features users of more modern languages would certainly find welcome.
My pitfalls, so far, are mostly the result of my own ignorance of Vagrant and what the best practices for a workflow should be. I'm still debugging stuff in nano because I don't know any better.
Also, it seems OpenShift has a HHVM module, but you can't run Composer through HHVM on it, and as a result can't run a Hack project with XHP, because of Composer dependencies that require being run under HHVM. I asked StackOverflow what to do three months ago and just got utter silence an...
For greenfield project main question would be why? It's not horrible but what do you exactly gain? With so many options around it's actually hard to make a case for PHP (and I have being using it since 2000).
I'm currently hesitating between PHP and Node.js for a new side project and I'm leaning towards PHP simple because I could do it 50% faster due to my experience with it.
Node is actually one case where depending on the project it could be very easy to make a case for PHP :) if you need a simple API backend you can use PHP and not deal with whole async thing.
For "real time" node def. will beat PHP :) But Elixir/Phoenix will destroy either one and thanx to BEAM it's actually can be considered soft real time system.
Node's intrinsic ability to "speak" JSON makes for some very clean code when dealing with that sort of data. If you're doing a simple API back-end in Express with JSON in, JSON out, it's extremely light-weight.
PHP, Ruby and Python here are at a disadvantage. JSON is JavaScript's home turf.
PHP isn't at much of a disadvantage - it has its own native JSON encode and decode functions. Granted, actually using javascript is better but it's not as if you have to import a library or write your own JSON parser.
well nicer syntax vs not dealing with event loop for me it's nicer to use more verbose syntax. (I guess I am getting tired of Node too :) all thanx to getting spoiled by Elixir.
We run Nginx in front of both node and PHP so can't say it takes significantly less time to setup node then PHP for production use. Composer is a reasonable take (reapoff? :)) of npm. Yarn seams really nice though.
Agreed, barring an outside force, or other members with experience or a strong voice/drive, experience will be what drives most technology decisions, and should.
I'd say the opposite, I can get a node project up and running pretty quick these days... as to peer comments on APIs, I don't think it's hard at all to spin up a react + node api project once you've done it before... and starting with a boilerplate for react+redux and express is very straight forward as well.
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.
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 route of using an event loop or daemonizing your "server" to serve up requests? I can understand why Node.js does it (otherwise the async nature would just be an annoyance for no gain), but why haven't there been any other server-side languages that not only work well like this, but actively target it?
It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
http://elixirforum.com is a good place to check out. There are a few excellent books out there to help you get started with OTP, which makes Elixir beastly, and Phoenix (a web framework) as well. The forums are an excellent place to find deals on books, too.
This is my least favorite part. As soon as your program gets more complicated the amount of repeated parsing, compilation and setup you need to do for every request causes massive speed and structural issues.
I can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into PHP7.
There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens.
In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality
But in most languages http requests should be stateless. Even in node or Java you should be hitting the db to pull that info anyway, as sharing the last info in the process leads to scaling issues as well as big problems if the application crashes.
The alternative is crazy sharding systems which are becoming more and more difficult as devices are less and less "static"
if you need to persist some data/state between requests, php has a mature memcached extension. it's a fast memory store, but i'm not certain of the security implications since i dont think it has any kind of built-in isolation.
Sure, but that means I have to either run a memcached instance on every server (which I've actually had to do before just for the sake of PHP) or I have to make network calls for something I shouldn't have to, and then also do serialization/deserialization. That's fine for plenty of things, but certainly isn't optimal for all sorts of stuff.
Not to mention, all the other languages out there memcached just as well.
I'm not referring to per-user sorts of things. You can't cache those locally in a sane way in any language. I'm talking about what would usually be memoizable sorts of things.
There are memoization libraries for PHP but really it's just another cache implementation. Put it in RAM, put it on disk, put it in memcached or redis, I don't really see too much a difference between $cache->set($key, $value) in PHP vs cache[key] = value in node for instance.
You can add a ReactPHP based HTTP server to your app to avoid reinitializing, but you'll have to deal with memory leaks between requests and process management yourself.
About 2-3 orders of magnitude in performance. That’s the catch.
And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc.
And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framework.
Unless you're writing in pure hand-optimized assembly language, 3 orders of magnitude in performance is way more than you could claim. PHP web requests commonly execute in hundreds of ms (of course, here I generalize mercilessly, but that covers most of cases I know of and that's what most sites aim for). So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I have very hard time believing it.
> And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons
You make it sound as if the idea of caching was invented by PHP programmers to address language deficiencies. Nothing can be further from the truth. Everybody uses caches, because it's faster. If you don't use DB cache, there's no way in the universe you can make you app fast under any significant load.
> And hacking those things on top of PHP make your program even worse to reason about
You have very strange view of performance design if you think using caches is "hacking something on top" and has to be avoided.
> than just using a daemonized system with actor framework.
This looks like a complete non-sequitur - you could use actor framework and still use all the things described above, and do it in PHP, and thousands of people do exactly that. On not in PHP, if you'd like - this pattern is completely orthogonal to the language used.
The system now used to serve GoDaddy's Website Builder content is written in node, deployed to clusters behind load balancers, and from there connecting to Cassandra clusters for the data... iirc, the average turn around time for a given request (including dynamic ones) is less than 12ms from the node server receiving the request to delivering the response, under a load of many millions of requests per second to the system.
Disclosure, I worked at GD in Website Builder when this was being developed, but haven't been there for over 2 years now.
I think his main issue is that the cache has to operate outside of the application process, adding overhead. Languages with shared state can have much simpler and more efficient caching, no io, no de/serialisation.
> So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds?
I had a side project written in Elixir/Phoenix make it onto the front page of HN and it indeed was the case that the majority of requests were in hundreds of microseconds. The default log messages actually use "µs" which is kind of cute.
I wrote about it here[0] and extracted a random sample of my logs and you'll see that most of them were in the hundreds of microseconds.
> So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I have very hard time believing it.
Yes, they do. Phoenix/Elixir is a nice way to get below the millisecond, and even with Java you can for most requests go below a few milliseconds.
And you can obviously handle far more requests at once, as you have all the code already loaded in RAM, and just need to jump into it, instead of reparsing it, or copying it back from a cache.
That 2-3 orders of magnitude difference is in an area that runs pretty quickly however.
People go to a lot of trouble to optimize the front end system, but tie it all to the same database that bottlenecks well before the web server. There are certainly times where PHP or CGI aren't fast enough for the job, but I think people tend to unfairly blame them in situations where the underlying problem is more systematic.
And yet it turns out that those 2-3 orders of magnitude don't really matter for the vast majority of products you could develop. Your DB queries no matter the language are several orders of magnitude slower than the interpreting time.
If you need to process thousands of requests per second per thread then don't use PHP, but that's a rare situation. I wouldn't build RTC in PHP. But web or enterprise applications, which are by far more common, don't really suffer that issue.
And pretty much everyone caches database results...
Compared to the other offerings, it's on par or faster (Python and Ruby really have a lot to be desired). You're talking about an actor framework, which is more performant at a cost of using that model and the myriad of issues with managing a more complicated system. The market favors simplicity and less sophisticated developers, in most projects.
Compare Symfony2 with Spring, for example (~500 vs. ~22'000 responses per second).
Or if you want to only use the raw language itself, php-raw with ulib-postgres (~90'000 vs. ~300'000 responses per second)
And with PHP, the larger the codebase, the slower it always responds, because even with opcaches loading it into RAM is a major bottleneck.
That’s exactly the issue at hand here.
And compare actual performance, for example JSON serialization, that’s not even fair anymore, symfony2 reaches around ~2'000 a second, gemini, the fastest fullstack framework, reaches ~970'000 a second.
Raw PHP reaches still ~170'000, but the fastest non-PHP raw language is still at ~2'200'000 compared to that.
These are actual performance issues that will cost you actual money. Even saving 20% of hardware and server costs can be the difference between your company being cost-effective and dead.
>>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 complexity down, but at scale, the applications I've worked with have to use a shared cache (like acpu) to avoid that rework and meet performance goals.
I mean more of languages that actually "target" this kind of setup.
I know it can result in a lot of "extra work", but I really feel like most of the pain of that could be abstracted away by the runtime.
Nginx/apache setup a PHP process before the request comes in, so why couldn't you expose that point to your language and let the programming language do work before that point, even "snapshot"ing it to avoid re-doing that work for each request?
It just seems like there are better ways of solving this problem, because an event loop is such a "hammer" solution to the problem.
I think python has exactly that with WSGI. With this protocol you make a module containg an "application" function object which is called by the server when a request arrives. On module load time you can do any required setup work.
(On my systems, by default there is some reuse of the loaded module, so you can leak state between requests. However it should be possible to avoid reused processes).
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).
Back in the day, mod_python also supported PSP (Python Server Pages), which was similar to PHP/ASP in that it allowed you to write a file as a mix of HTML and Python code inside delimiting tags.
The startup time can be pretty extreme -- although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything.
And even if you cache everything, you still have the code necessary to setup the runtime environment of you application which runs on every request and does the same thing.
But still, I do actually like that model and it does have many advantages for development. But it's really hard to work in PHP, the language, after using something better.
> although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything.
For the conversion to bytecode, that is what apc is for.
There are plenty of competitors in this space, they just don't use the CGI model of spawning a new _OS_ process for every request. You have Erlang/Elixir that have their own lightweight processes that don't share memory and have independent GC. And you can build similar systems on Java/Go. The difference is that in those language you have a choice. There are certain types of applications that you just can't reasonably make in PHP.
What do you mean exactly? I mean yeah, it's a bit different with FastCGI when you have a pool of persistent processes. But you still basically boot up your whole application every time a request comes in. Opcode caching helps with loading code, but not execution. And you're still working with OS processes for concurrency, which is not ideal.
The catch is overhead. There are things you need at the start of each request - global configuration, database connections etc - that other systems do once at startup. PHP has to do this every request.
Probably because allocating a thread to every request is less efficient then a bunch of event loops with async. Ideally you do both, but a lot of languages choose to make concurrency something done at the process level and are event driven asynchronous web servers which are deployed as multiple processes, which adds a lot of overhead compared to threads. I think Golang has a nice balance with goroutines, as I understand things.
> PHP is perhaps one of the easiest technologies to scale horizontally, because of its statelessness.
PHP is no more stateless than any other language out there. Statelessness is a design choice, not something PHP gives you for free. If your app write things on the local disk or use the default PHP session handler then it is not scalable by default. In order to write code that scales you need to make it scalable, it's not something automatic and certainly not special to PHP.
I would argue that PHP is more stateless than Node, for instance. Things that happen in previous requests do not affect following requests in PHP, unless you're explicitly using shared state. That's not the case in node, it isn't the case with most Java HTTP server implementations, and it wasn't the case in Rails back in the day (don't know how it is now).
Any language is stateless until you explicitly share state; the other languages just make it easier to share state. It’s not a bad design decision – makes them more versatile, or at least more cleanly usable outside of serving webpages – but is something to avoid in similar applications for sure.
Exactly. The "shared nothing lifecycle" really lets the programmer (knowingly or unknowingly) embrace RESTful design. Too bad the language doesn't have strict typing like Java. Otherwise it'd be even more convenient and safer in my eyes.
Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.
You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.
> Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.
You are running it from RAM. PHP's OPcache, and HHVM, will both compile the code only once (well, HHVM will compile it multiple times due to JIT, but it only touches the disk once) and cache it.
> "reasoning about" (boy do I hate that phrase...)
A bit tangential, but I find myself disliking it too, for no good reason that I can think of.
Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.
I like the old hacker term for "reasoning about". Grok. It's much easier to grok a program when everything just runs from top to bottom and doesn't jump to a different third party library every 3 lines or have 15 layers of indirection and frameworks.
Interesting! I have somehow developed the opposite opinion. The phrase "to reason" is plain English and uncomplicated. Grok, by comparison, is arcane and to the uninitiated is semantically opaque. The latter strikes me as a more suitable vehicle for demonstrating pretension.
Fair enough. I never claimed my dislike of "reasoning about" things was rational! 'Grok' definitely has a context, that likely does not include talking to non-hacker types like clients, board members, or whatever.
I understand your situation :) I keep a long list of seemingly innocuous words which, through no fault of their own, are repugnant to my ears. It's utterly irrational.
It's a pretty nuanced phrase and difficult to replace. I might make the case that "easy to reason about" <=> "simple" in the sense that Rich Hickey uses it[1] but that doesn't do anything for the verb itself.
The phrase has a high correlation with subjects that are themselves highly correlated with smug proponents; functional programming is one of the greater ones of these.
Personally I like the phrase. Then again I self-identify as a (non-smug) SmugLispWeenie[2] so of course I like it.
> You wouldn't need much of a GC when the process is killed every time
Yes, you do. You'd be surprised how easily memory balloons out of control unless you regularly run a GC. Log minor collections sometime in Java or JS engines if you don't believe me…
Even worse, if you don't run GC regularly, you will suffer terrible locality as execution continually grows the heap (not to mention the overhead of continually requesting free pages from the OS).
It may seem that way at first, but space leaks during individual requests are way too easy otherwise. Think about something as simple as, say, parsing Mustache templates. The parser is probably internally making lots of little substrings to record the names of directives as it comes to them. You would think that this is O(1) in space, since you only need one (or a small number) of strings at a time, but without a GC the space requirements balloon to O(size of input). Being able to dump the memory at the end of a request doesn't help you if you keep blowing out your cache during each one.
I speak from experience: there have been many attempts to mandatorily delay collection until the end of the event loop in browsers, to achieve greater responsiveness. It has always failed. You can add heuristics to try to preferentially collect at the end of the event loop, but you really need to be able to GC anytime.
I'm not completely disagreeing... I've worked on pipeline transformers in node where I exposed gc and ran it after each item in the pipeline was done. It would grow insane without it... likewise I can see that if you're transforming a lot of records for delivery in PHP it could bloat as well.
However, if you're handling requests well within a given memory threshold, it isn't always something you should worry about until it becomes a problem. In which case, you'll probably want to look at something like go, rust, erlang or others to handle improvements, or break off heavy parts into sub/micro-services.
The idea here is that the webserver forks & execs a new process for every request, allocates a bunch of pages, and then runs to completion, at which point the process finishes and the memory is returned to the OS. It's essentially using the OS as an arena, where you can allocate memory at will just by bumping a pointer and then the whole thing is freed at once at the end of the request.
It's not an insane idea - CGI worked exactly like this, as do most command-line shells. And the overhead is often less than most people expect, since most pages are COWed on fork() and the files it touches will likely be in the filesystem cache. Still, I think people found that the overhead from process creation (and in particular, keeping all those processes around & task-switching them while they make DB/network/filesystem calls) was greater than that from GC, and so most frameworks - PHP included, these days! - use a more lightweight mechanism.
Yes, I know what the idea is. I highly suspect it won't be practical due to the reasons given in my other reply. We tried this with JavaScript in a very similar domain and the memory usage was unacceptable.
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialized before a request starts. Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. You can cache that stuff, but it's still overhead that isn't central to handling a request.
There's actually work being done to build PHP frameworks that get around this with ReactPHP, ZeroMQ, Photon, etc. Essentially this is what HHVM does as well, by at least keeping your compiled bytecodes in memory (similar to APC/eAccelarator/ZendOptimizer, etc).
> 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 connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.
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.
> IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires.
Every wasted millisecond on the server side matters. It impacts scalability, customer experience (and revenue) etc. You should take every easy win you can get there.
Not doing full includes is just ridiculously lazy. It doesn't take that long to write them out, and your IDE can help you out there. I bet you spend more time on social media during office hours than you'd ever save from not having to type out those import statements.
Except you still need autoloading configured for most libraries in the ecosystem to work, unless you want to manually chain absolutely huge quantities of requires.
> 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.
Is machine computation mostly responsible for your revenue? If so, would it make more sense to measure web server responses in terms of cpu cycles and such instead of time?
>Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc.
All the magic you ever need can be dynamically created in __get, __set and __call. It works, it works well, and it makes not only reasoning, but also deployment an order of magnitude simpler.
>Code paths, auto-loaders, database connections, config files, etc.
Use a single code path, a single autoloader and a single database connection. Cache the opcodes of stuff you load. Write config files and templates in pure PHP, so they're cached as well. Done.
I've never, ever had problems with bringing PHP page generation time below .1 seconds. Usually it took something like .03 seconds on crappy hardware. And that was without extensive caching of DB results or anything else that's particularly clever.
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request.
Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means.
There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.
Starting new, regardless of caching data/bytecode, still means you have to spend time bootstrapping the application.
Other languages, whether directly or indirectly manage cleanup via GC or recycle processes, like UWSGI for Python.
I also don't find any particular benefits over other languages with "reasoning about". As a PHP application grows and a team restructures it into something more mature it ends up looking the same minus the event loop (which just lives somewhere else).
The real question is why does PHP depend on globals or thread locals for request state at all? PHP's "new process per request" is a solution to a problem that PHP created for itself. In other languages, the request handler receives the request state as an argument, so when the request completes there is no state to reset.
> It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
Firing up a new process (or even a new thread) for each request is very expensive--much more so than a generational GC. Async IO also mitigates this (why have 10K parked threads consuming memory all your memory if all of them are stalled, waiting for database)? Services that spawn a thread for each request run into the C10K problem--they can only serve 10K simultaneous clients. Regardless of your concurrency model, you can't ignore errors--you still need to dispatch the right status codes and error information (not to mention logging, etc).
You should check out Go. You write concurrent code and the runtime effectively manages a thread pool under the covers so you get all of the performance benefits of async programming with the developer-friendliness of synchronous programming. In the case of a web app, you just need to write your request handlers--the web server manages the request concurrency for you, and the language's runtime manages the parallelism.
>>PHP's "new process per request" is a solution to a problem that PHP created for itself
True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
> 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 the OP's statement.
> Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
Again, these are all solutions to problems PHP invented for itself. Other languages don't require special caching mechanisms; they get by on normal scoping rules and shared memory.
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.
I don't think so. You either keep state between requests and therefore get problems like memory leaks (which often happen in large Ruby or NodeJS apps written by not very experienced developers) or you keep no state and have to do initialization on every request.
This is only true if your framework depends on global variables to manage request state. If your framework passes request state in as an argument to the request handler, then there is no state to reset. Don't use global variables and you don't have any of these problems.
How do you know whether other components (objects, modules) do not keep state between requests? Unless you 1) use language with pure stateless functions like Haskell or 2) delete everything after each request you cannot guarantee that. PHP uses latter approach.
With PHP you can see your program as a pure function whose result depends only on arguments. You don't have to care about memory leaks like you don't have to do memory management when you have a GC. And if you want more performance and less convenience you can always opt into running your own web server.
> Don't use global variables
If you have an object that is persisted between requests you already have some state that is saved.
Programming 101: scope your objects appropriately. If you have an object whose state is bound to the scope of the request handler, initialize it in that context ("don't use global vars" is just a special case of this rule). In other words, everything initialized outside your request handler's scope should have its state reused across requests. The PHP community never entirely learned this, so you guys are building workarounds. This isn't intended to be PHP bashing; just objective criticism.
I do not see how scopes are related to a problem of memory leak. Let's say you have a Django middleware that is initialized outside the scope of a request. Let's say you decided to add some stats counter in that middleware and wrote a code like this:
This code follows your scoping rules but still leaks memory. So it looks like you don't understand why memory leaks occur. I explained somewhere in ancestor comment that to prevent leaks you either need a language with pure functions or reset environment on each request, none of which is possible in Python yet the latter is available for PHP users.
With Django processing model any array can become the source of a memory leak. I have heard that Ruby and NodeJS developers often have to restart their applications every several hours because they even have no tools to find the source of a leak. The problem that does not exist in PHP by design.
You're conflating application state with request state. Updating application state based on a request is a perfectly reasonable thing to do, but it necessarily invites the possibility of a memory (or database, file, etc) leak. Either PHP can't update application state at all or it can and necessarily suffers from the same potential to leak memory (I suspect the latter, since an application without side-effects would be worthless).
I may be waaay off base here, but wouldn't amazon's lambda function architecture sort of mirror the benefits of shared-nothing? It doesn't necessarily work like that under the hood, at least if I remember correctly your lambda function may live on past one request, but you must code as if that were the case
It does, but it comes with deep tie-in to AWS as well.
But also, you don't typically use lambda to serve pages or a full application, more commonly it's used for specific processing tasks, individual endpoints, and generally code that can run standalone.
I worked on a large-scale (30m+ users, tons of concurrent sessions and high request rates) site + online service + native client setup in PHP for years.
This was never actually an asset. Startup times were huge, lack of shared state meant extra requests to database servers (and to memcache instances to avoid database round trips) to get the same data per-request. Each request got longer and a given page or api call might issue many duplicate requests in a short period of time.
Plus since PHP doesn't have viable threading or async (definitely didn't at the time) each memcache or sql request had to be synchronous, resulting in even more wasted time. At the very least memcache had good support for batch operations so we could manually batch our queries.
Overall though this is not an asset. It's only the 'best' part of PHP if you don't want to think about writing good software that manages shared state.
To be fair, many applications don't actually benefit from being good code, so PHP is probably a good fit for those.
> Why are there no other "competitors" in this space?
You can do the exact same thing with any language that supports CGI. You can compile a Go binary, put it on an Apache server and you'll get the "shared nothing lifecycle" just like PHP.
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, ...).
It's interesting that so little know what is Cgi here. It's the Common Gateway Interface and it uses environment variables to communicate to the Cgi scripts and thus the Cgi script can be in whatever language you wish. You don't even need a lib, reading env is enough. Its possible to write your Cgi scripts in assembly.
So this process-per-request thing is not exclusively a Php thing.
I know of CGI scripts (and the newer faster alternatives), I was wondering why more languages don't specifically target that kind of setup, playing to its benefits and trying to minimize the downsides.
Oh, sorry. I guess it's two-fold then: a) it's not as popular and cool, and then b) not much needs to be done to target it anyways, as most often being a good unix citizen suffices, you get the input and write the output to stdout, what's in between is application realm and whatever you do is up to you.
I completely understand the "trendy" part. Sadly even language/frameworks need marketing, and doing things in a "wasteful" and "slower" way but simpler is gonna be a tough sell even if it might be the best move.
I just feel that there is a space for a "better PHP". One that uses a better base language, but still keeps the benefits from the language like the simplicity of the "think edit reload" cycle, the shared nothing architecture that makes programs easier to write and simpler to test, and the horizontal scaling.
I've not worked on many CGI stuff (other than little things I use myself) but Python has all the housekeeping done. See this other post of mine that has an example of an interactive hello-world: https://news.ycombinator.com/item?id=12712067 . And then, Perl is used for all sorts of CGI stuff. Both have good database support. CGit [1] is a git web interface written in C.
That example of "Surprise type conversions" is crazy.
Did not know that.
While i do not think PHP is a perfect programing language. There is one think i LOVE about PHP, it is that the PHP "community's" default way of documenting code behavior is to make a small example.
When i read most other languages documentation i read it. Then i need to make a small test to verify that i understood it.
All those tests takes a long time to make and i have to make them over and over again, every time i forget the way a function behaves.
In my experience code examples as documentation are far more common than actual documentation (e.g. guides, user manuals), but perhaps I just haven't worked in a language where the opposite is true.
You can take a look at the node api docs... there are some areas (particularly in crypto), where it's really hard to understand what you need to do, as there are pretty much no examples of actually exercising said code. So you go searching via google, find a similar example, look at the docs again, and hope that you got it right.
It's harder still when you're trying to en/decrypt data from multiple programming languages... Java is particularly painful as well, since a lot of the things that are "standard" are abstracted behind class structures with naming that differs from the standards.
I worked in PHP at Box for about 3 years. This article does a great job of reflecting my sentiments on the language. In particular, I'm glad to see that the author recognizes that there are some glaring issues with PHP that aren't tradeoffs in favor of something else - they're just warts.
That said, PHP is really good at what it does - providing a framework and environment for serving web requests efficiently and easily. I find developing in it very fluid once you know how to avoid the warts. A lot of the flak that PHP receives as a language revolves around the fact that it doesn't actively discourage developers from doing bad things, and sometimes the language itself does some crazy stuff (as shown in the article with the divide-by-zero behavior). I think this is a huge shortcoming of the language, especially as code bases and teams grow and your organization needs to depend on the language more and more for safety. That said, I still don't hate working with it. Sometimes I rather enjoy how quickly I can develop in PHP, and how reliable it can be if you know how to operate it.
I think in all, it was a bit of a slog to get to the point where I am with PHP today - to the point where I understand its strengths and flaws, but ultimately I think it does have a place in modern webapp development. I think Hack and HHVM are excellent spiritual successors to what PHP tried to (is trying to?) accomplish, and that they do a great job of hiding or eliminating some of the warts of their parent language.
Kudos to the Slack team for being pragmatic about their approach to the technology, and hey again to all of my former colleagues working there!
It is interesting that author does not mention the performance improvements of PHP 7. I have read with PHP 7, HHVM does not have the performances any more. I wonder author cared to test that in their codebase.
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 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. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.
Not everything can or should be well engineered. People that always chase this are worshipping false gods. Does anyone have experience working on something that at one point actually met with the high ideals a certain mindset strives for?
I've worked on enough projects to have covered both sides of the equation. The pristine codebase that belonged on a museum yet took way too much time to ship a feature. The other side of the coin with the codebase that somehow worked (no one knew how) and brought in millions because people would keep piling stuff on top of it. Have also worked with a codebase that started off awfully and was cleaned up enough to reduce the amount of time lost on stupid bugs and and thus increased how effective the team was delivering new features (with a direct financial improvement as a result because sales picked up significantly). It all boils down to finding a balance. Sadly, people confuse technical perfection with a product that works.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Me too. My first language was PHP, I wonder what that's done to me. :) I still appreciate it, and kind of wish other languages had a "from webdevstuff import *" feature that would just bring everything I might need for the purpose of web dev into the namespace, rather than many lines of imports from sometimes obscure paths. I can't get on the hate wagon with the rest of the community. I'll avoid using it to start anything new, of course, but I'd take it over any other mainstream option. Give me Clojure or Lisp and I'll be happiest though.
My first language was Pascal.
The concept of combining strings and integers in PHP without any conversion was scary and magical to me at first, but the damn thing worked, as long as you were careful. I still get mad at people who complain about type coercion because they expect their programming language of choice to read their minds and wipe their ass.
And Dijkstra was kidding. As is Rasmus when he says he'll restart Apache every 10 requests. Hyperbole. Learn languages instead of a language and it'll click. It has to.
I think this is great comment, and I can really relate to a lot of it.
I especially liked this:
> Learn languages instead of a language and it'll click.
I started at 5 or 6 with Basic, then progressed to Object Pascal early on, then C, C++, PHP, Java and finally Javascript and C# - I believe this wide experience has served me well over my almost 30 years' of programming (Christmas I'm getting old!).
I think there is a time and a place for 'just get shit done, fast', as well as spending time building 'elegant' code. But, if anything, the compromise between these 2 is possibly the thing I struggle with most.
Scores of developers that were raised on BASIC assert that knowledge of BASIC gives you brain damage. Presumably, they do not consider themselves to be brain-damaged. Similar things happen with, say, products of public schooling.
Which isn't to advance an, "I was spanked and I turned out fine..." kind of argument. Even if that's true, we can establish higher floors than "fine." It's the self-defeating hysterics around the presentation that make it come off the wrong way to me.
Uh, the early versions of PHP was written in Perl running under mod_perl, which was not CGI.
Also, e.g. fastcgi was around the same time frame.
(In order not to end up in a flame war regarding the first point I checked wikipedia -- see second paragraph of the intro here. :-) https://en.wikipedia.org/wiki/Mod_perl )
PHP got traction because it was easier for hosting companies to set up shared PHP hosting and it was easier for non developers to add basic code to HTML pages. PHP was also at the right moment at the right time,just like MySQL and some people made it easy to install it on Windows, a platform too often ignored by language maintainers (try to write Ruby on windows, a (slow) pain in the ass).
There are a number of successful startups and very large companies using Haskell. It's understandable why it isn't a common choice, of course; the potential employee base is fairly small.
But business success is largely orthogonal to language choice. I.e. when you buy a paid Github plan do you check what language they write the site in?
Of course a strongly typed languages should tend to have less bugs and that will save money. But saving money is only useful for those with revenue to being with.
> "The next guy to join the company will clean up your shit"
Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter.
Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately.
The world of difference between balancing trade-offs in technical debt, tradeoffs in long-term/short-term goals, and deliberatively sabotaging the company by leaving technical debt for other people to clean.
You are a liability to the company and its culture. And you want people like you and your language to be taken seriously? that's why nobody wants to work with people like you.
Finance has a bad rep, but there are actually lots of rules and regs surrounding ethics in finance and a practitioner can easily end up with massive fines or in jail for failing to follow those rules. Even if his boss told him to do it.
Those rules may not be the right ones and they may not be enforced well enough, but there's at least some nominal level of assumed professional responsibility.
> But suddenly because you are an "engineer" this is acceptable?
No, it's acceptable precisely because you aren't an engineer.
We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legally responsible -- independent of our employers -- for defects in our product that arise from incompetence or otherwise failing to follow best practices.
So, you're wrong and your parent is right. He's not independently responsible for his work, and he has no formal ethical obligations prior to his employment contract.
And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY.
Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted.
You don't, because you have you keep this to yourself because you know it is wrong and not in the best interest of your employer... Who is wrong now?
> Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY.
Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT:
> because you know it is wrong and not in the best interest of your employer
Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employer. There is no prior obligation (aside from not literally breaking the law).
And within the structure of the company, the engineer has no legal or professional obligation prior to manangement. So, if parent's boss tells him "get this shit out the door ASAP maintainability and quality be damned", and then parent does exactly that, I think he'd probably be OK from an employment perspective. In fact, insisting on some modicum of security or readability might even get him in trouble!
Contrast that with the situation of a PE, who would be much more likely to answer "no" on the basis of professional ethical obligations which are prior to his obligations to his employer/immediate manager. And, when answering no, would be much more likely to have the leverage and respect necessary to survive an encounter with middle management.
Do your job in the interest of your employer, to the best of your ability, without ripping off your customer.
That's the meaning of professionalism. That's the meaning of living in a society. If you need to say no, then do it. Your job is not to say yes to everything.
What if everyone ripped off everyone all the time? It would be a world of shit.
Ripping off the customer is not in the best interest of the employer, and is being hostile towards society. Think about contributing to society not taking what you can.
Adding customer value is different to adding apparent value with no real substance.
Your responses seem to boil down to "but I believe everyone has a moral responsibility to act like an engineer."
When is perfectly fine, and I agree with you. As I've said multiple times.
But realize that, in the US, programmers have no such legal obligation. They also have no formally codified and enforced professional ethical obligation.
Any such obligation is purely within the realm of personal ethics. Particularly obligations to the customer which go beyond or contradict with obligations to management (the latter are at least captured in the form of a contract).
So your moral stance, while admirable, isn't representative of actual enforced social norms among programmers.
The next sentence tells you where I'm coming from, but to expand a bit... here's my theory of software development in the point of view of a new company. If you have an existing product, you're already in phase 3...and sometimes phase 3 rebuilds the product. This does not apply... you already know what the software is.
There are 3 phases:
Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it.
Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it.
Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.
That's what I said: there's a difference between calculated trade-offs between short term and long term and "I got no time for that, let the next guy clean it up, haha!!".
If you are rational you will understand that technical debt is a cost, and unless you are sabotaging the project you won't add cost without a good reason.
Prototyping and iteration is fine. Throwing away prototypes might be fine. But selling a functional prototype as a finished product IS NOT FINE. It's morally wrong. And unless you want to be lynched like the Theranos people you better not get caught doing this.
I can sign below your post as experience of PHP developer who "fights" each day with bad code written by PHP devs. There are a lot of frameworks like Laravel, Symfony or Zend which introduces a lot of conventions (folder structure, naming, PSR autoloading built-in functions, resources) but it is so often skipped to "get shit done". I would complain on many aspects of daily PHP-development like not using tools like the PHP-MessDetector (one of the rarest tool used by PHP programmers), PHP-CodeBeautifier (phpcbf) or PHP-CodeSniffer - Hopefully some open-source projects started using a StyleCI. Another things is database-related code. PHP developers tends to use ORM lately, but on five projects with Doctrine in 4 developers used it improperly messing with a 1000+-lined classes and storing annotation above the fields instead of file or even using Doctrine to get native database-connection via PDO driver to use query db with SQL only instead of DQL for any case. In google there is enormous list of articles about PHP optimization - the interesting thing is, that almost any touches the fact the PHP application should be "compiled" (cached) (e.g. for Laravel [1]).
Whatever I would say about PHP - how good or bad is - I am almost forced to use it - In central/eastern europe almost any company uses it to develop web-backend... but I really would love to jump to Node/Go/Golang-based development team (maybe even remotely).
- You sit in a dining table with 50 different utensils. White wine glass, red wine glass, water cup, salad fork, dinner fork, dinner knife, teaspoon, soup spoon, bread plate with knife...
- When the food is served, you take the food, drop it on the floor, eat it with your face (not even using your hands).
"get shit done"... use spoon as a knife and knife as a fork, or try to sniff your food through your nose instead of eating it.
To be fair, as a Python dev, I have inherited some real crap in Python as well. Though recently I had to import some data from a PHP website we have - boy that was another level of crapness (though the main problem was the database design, or lack of it).
I used to be this guy, ie, who cares but not too much. A big reason why I switched to node. Let's me think less about code (JS everywhere), and more about the problem at hand.
You can have the same mentality in many languages that suck less than PHP, though. Python, for example, tends to get out of your way and just let you write your algorithm. Go, as well. Or various JVM languages, particularly Java 8 and Kotlin.
The one thing you want to avoid are communities that argue about "the best" way to do things. Even then, you can use the fruits of their labors, as long as they're willing to package it up in something that gets out of your way and lets you get work done. You just need to take the language but not the community.
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 their syntax, core functions and core libs, so I can, without internet or documentation, write things in it immediately.
I'm not sure why those others give me that feeling; probably because it's easy to just start instead of having to set up dev environments etc. Most is already on your computer and they are forgiving (a bit too much I agree) about sloppy coding.
It would be interesting to try to dive into details of why the brain finds some languages more conductive to 'just write it quick' and try to mix that with languages which do not have that feeling at all.
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.
This sounds like to me you are mistaking the popularity of PHP with the proficiency of the developers. PHP has been around a long time and is used by lots of people. Even if PHP projects only have a 1% success rate and haskell projects have a 20% success rate, guess which one will have more "successful projects".
But that assumes this is the goal. The real goal is to get a nice looking CV with all the "advanced" entries, not to actually have a useful product or -god save us from this evil- an actual business.
Right, but the point I was making is that it isn't necessarily true that PHP is any better at getting to MVP based on number of successful projects alone.
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 tremendous losers who picked php and got nothing for it.
Precisely. This is classic base rate fallacy. If tons of people use PHP because PHP devs are cheap, there are bound to be a ton of successes despite the fact that it's a horrible technology in many respects.
Perhaps. But that rather begs the question. PHP has horrible bits, but in fact from what I've observed in the last year or so is that whilst it has in the past been fairly horrible, much of what made it awful can be entirely avoided.
If you aren't following the PHP Framework Interop Group (http://www.php-fig.org) then you really should. I'd hazard that most of the warts in PHP can now be avoided pretty much altogether, and those that can't quite possibly can be worked around through configuration.
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)
It has everything I need to know about the function clearly laid out. The behaviour of sort when elements are the same. A list at the side of related functions that I may want to look at instead.
I also like documentation that includes user contributions as these often add useful caveats and usage examples that don't fit well in the general documentation.
Php documentation is the worst. Some of the reasons..
1. They have exactly one set of documentation pages for all the php versions.
2. Another thing is that documentation can be quite wrong for even the fundamental stuff. I have seen a core developer blast out in reddit that "The documentation is wrong!", when the other party pointed them towards a piece of documentation.
3. Incomplete or shallow description. Go check out the documentation page for Exceptions in php and try to find information regarding the behavior of return statements in a 'finally' block. Now go an see the respective page in Python documentation and see how in depth the documentation is.
And having code samples is not exclusive to Php's documentation..
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?
> plenty of great server-side languages and environments
Depending on the type of project, I would choose PHP over at least some of the languages you mentioned; I guess "great" is not a significant quality when making architectural choices.
Just to be clear: I was thinking about factors like performance, choice of servers, how easy it is to hire good developers, library ecosystem etc.
EDIT: obviously the "awesome aspects" mentioned by GP are a similarly unsubstantiated claim ;-)
If you are building software that will be deployed by a large number of users, having PHP provided by every $3.99 & up hosting company can't be underestimated. Languages like Haskell are nonstarters.
The .NET CORE is now open source and cross platform. Cross platform compatibility with the exact same source code, and the killer features/speed of C# makes its my personal choice for a server-side language. I would like to add that C# devs are not cheap and also seem to be slightly more limited in today's market compared to PHP devs.
If you are running .NET code in production on a non-Windows platform today, then you and your team are probably braver and more willing to work around issues than most. I hope that running .NET code on Linux becomes the common case, but I suspect that we are still a couple of years away from that.
It might not be exactly what you had in mind as 'in production', but it's probably worth noting that Unity uses Mono as a core component, and it seems to be fairly popular on non-Windows platforms.
It's easier to reroll in another language and retrain or recruit? No. So you probably mean for a new project. So now you've more maintenance and learning curve unless you just happen to have enough skilled in $NEWTHING. Not really easier.
PHP is an inconsistent mess, everyone knows that, but it's cheap, widely understood, and it's perfectly possible to write decent maintainable code. There's ways to mitigate the chaos.
True, I have seen one startup fail early because he couldn't find any (cheap) Django devs. He might have stayed around another year with the funding he had if he had gone PHP.
Lesson Learned: If you can't do it yourself, start with PHP (or something else with incredibly cheap devs, I suppose) until you get VC funding, then rewrite it using something other than PHP.
Money past a certain point is not an incentive. Retraining takes time. It's harder to land jobs for which one does not have relevant work experience. The PHP job market is larger than most other web programming segments, so work is easier to find. But sure, if you're hiring, I'd certainly prefer working with Ruby.
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.
Rust and Haskell are both extremely well designed. Most of the "top languages" by percentage usage are 20+ years old, so I can't fault them that much for being badly designed, but we should definitely stop using them.
Rust looks very complicated to me because there are "lifetimes" and you need to think where to put those single quotes properly. Not a language for a beginner.
Haskell doesn't support OOP if I remember correctly. And it is complicated too.
Due to lifetime elision, you rarely need to explicitly write lifetimes. I participated in the last Ludum Dare game competition, my game never used an explicit lifetime.
That said, it is true that Rust has tricky parts. The domain is inherently complex.
I never said it was for a beginner, just that it was well designed. Lifetimes are no more complicated than stuff you regularly run into in C++, though.
Python is a great beginner-friendly language, but that doesn't mean it's well-designed in other respects or appropriate for large software projects.
It wouldn't really make sense for Haskell to "support OOP" in the usual since. The OOP paradigm is mostly useful when you have mutability. Another way of looking at it is that you don't need OOP in Haskell because it exposes better ways of interacting with data that aren't present in most OO languages, like ADTs and Typeclasses.
That will never happen, you can't write code like this in Rust:
<!-- Snippet taken from an example of tightly-coupled and unmaintainable code in the Clean Architecture in PHP book[1] -->
<body>
<?php $results = mysql_query('SELECT * FROM customers ORDER BY name'); ?>
<h2>Customers</h2>
<ul>
<?php while ($customer = mysql_fetch_assoc($results)): ?>
<li><?= $customer['name'] ?></li>
<?php endwhile; ?>
</ul>
</body>
Even when the previous code is an abomination, it is absolutely easy to write, this is why languages like PHP are a success, the barrier to entry is definitely low.
The issue comes when the whole industry buys the idea that PHP equals bad code, fail to appreciate the progress the language has had in the last years, fail to appreciate the effort behind projects like Symfony, and become completely foreign to the current best practices.
I don't know if you can do that in Rust (I suspect you can with some effort), but you can certainly do it in Haskell (with slightly different syntax, of course) using a library like Blaze-HTML5.
Your argument is a bit spurious; you're right insofar as you can't write PHP in a language that's not PHP.
That is my point. You require effort in an order of magnitude greater than with PHP in order to achieve the same result, which in the case of a beginner, is the difference between continuing their journey in programming or abandoning the ship.
You are failing to see the big picture and are taking for granted the plethora of initial setup you have to do to begin working with a language like Rust (ex. generating bindings for a database driver written in C if it doesn't exist in cargo), you were just nitpicking in the syntax of the previous example (which BTW, I took care to clarify it was an example of bad code to avoid people not familiar with PHP from getting the wrong idea).
It was my fault to say "you can't" in my previous message (see Atwood's Law), I really meant "it requires too much effort".
When I say "with some effort" I mean "with a bit of initial effort to create a combinator library and zero effort after that". I'm not familiar enough with Rust to be confident of that though. It's certainly the case with Haskell.
>You require effort in an order of magnitude greater than with PHP in order to achieve the same result..
An order of magnitude? Really? I don't think so.
Rust has a library (probably among others) called Horrorshow[1], that exports macros to do html templating.
You claim that it is easy in Php to do html templating. But you miss the fact that it provide zero sanity/security checks while doing so. You need to sanitize every one of those variables before inserting into the html stream.
You see, Php just trades off every bit of sanity and security for a little bit of ease of use. It is that simple.
Yes, an order of magnitude, in PHP we're talking about _minutes_ in Rust we're talking about _hours_ or even _days_ for a beginner programmer, ever tried to install Homebrew in a Mac to name an example? It adds at least a few hours to the equation with its dependency on Xcode unless you already know to just install the command line tools.
Remember that a beginner programmer doesn't always have a background in Computer Science, maybe it's a child, maybe a graphic designer, maybe an elder person or a housewife. Are you really expecting from a person foreign to CS to stop tinkering just because they can't write secure and performant code in your favorite language?
Again, stop taking for granted the initial process setup and all the gotchas that you already know, stop nitpicking in the example of templating and see the big picture: A beginner programmer being able to get instant feedback with little effort in their browser of choice. No initial project or repository set-up, no install for external libraries, no huge development environments (like Xcode or Visual Studio), no build process or compilation, no command line, just an app like WAMP (on Windows) or MAMP (which people accustomed to homebrew avoid) and a browser pointing to http://localhost.
PHP is not a perfect language, but it's neither the abomination people like you describe, too many people judge PHP by its former state of the art and are unaware of the progress it has had in the last years, many of the most popular issues are already gone or at least are too difficult to trigger, to name an example, PHP stopped having register_globals since version 5.4, and PHP 7 added strict type hinting, which throws an error instead of doing unexpected type coercions.
That doesn't mean that PHP is a better choice than properly-designed alternatives, just that it's less worse than before. I agree with the sentiment of using a well-designed language like Rust, but only when a project really requires that degree of security and performance (ex. writing a browser like Servo).
A bakery website written by the kid of a patissier doesn't require that degree of security and performance... Or are you really going to demand that child to use your favorite language just because you despise PHP?
So, you are saying Php is like LEGO and BASIC for web development. I have got no problem with that. Problem is that people using that in a professional setting and uses it to put stuff online.
>A bakery website written by the kid of a patissier doesn't require that degree of security and performance...
I don't think so. Everything that is put online need to be secure. One day it is just a bakery website. Next day it is accepting credit card numbers. And the kid who did this can get employed as a php developer based on this experience, and might build stuff like that for years, with out a clue in the world that they are using a toy language.
> I don't know if you can do that in Rust (I suspect you can with some effort)
You can, using some web framework crates, but PHP is many many years ahead from Rust in making web apps. And I'm not sure if its the right language for the web. You'd probably be fighting with the borrow checker and type system most of the time while the php dev is busy cranking out new features for his/her web app. There is also the problem of compiling huge websites.
Why would I ever want to access the database from the presentation layer?
That you cannot write that abomination in rust for me it is a clear advantage, not a disadvantage.
And still I can't understand how can you compare php with rust.
A much more apple to apple comparison would have been with WebSharper.
Because when you're just some guy that wants an answer to the question "how do I get some things from a database into a web page", the answer that starts "Well first go set up a VPS..." and hits "There's this thing called MVC" somewhere in the middle is not something someone who just wants to put a list of things into a web page is going to listen to.
Then a month later that guy that pulled those couple things into a web page is going to go "Hey, maybe I could make a thing to manage those.". And he's going to learn more.
Then a month later he's going to have another bright idea.
And suddenly someone with no programming background is a PHP programmer, and he's putting together ugly but functional websites and everyone is looking and going "MAN PHP IS AN AWFUL LANGUAGE".
There's a huge contingent of people that are maybe moderately technically savvy but are not programmers and are not necessarily interested in deliberately becoming one. These are the people that end up setting up entire businesses in some Lovecraftian Excel sheet. PHP is a language with a learning curve (even for a non-programmer), not a learning cliff, and it makes it really easy for these people.
I've gone one step further and created a template:
Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], 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 tremendous losers who picked [insert language] and got nothing for it.
Your template is far less interesting than the original statement. PHP spent a pretty long time as basically the lingua franca outside the enterprise world (and even some places in it), and there are still domains where it holds that title (e.g. WordPress alone outweighs many languages' ecosystems), so the phenomenon the parent was describing applies more to PHP than to some arbitrary language you could insert into this template.
I actually agree with the original statement. PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail.
"and miss all of the tremendous losers who picked php and got nothing for it"
certainly applies equally across all languages in my opinion.
The grandparent of your comment suggested that, yes, these projects were lifted up by PHP's un-fancy nature giving them focus. The parent of your comment was suggesting that, basically, the companies that have succeeded using PHP aren't any more numerous than we would expect to have come out of the massive PHP userbase even if PHP doesn't offer any advantages at all.
The observation that "PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail" seems to be responding to a nonexistent conversation in which people were positing that startups based on other languages don't fail. Nobody here is saying that other languages magically make your business succeed.
I know you're making a parody, but I think I agree with your parody.
I mean, essentially all you're saying is "startup success is largely uncorrelated with the programming language used to implement those startups' products". That seems like not at all an unreasonable position.
(It's not, by the way, equivalent to the statement "choice of language doesn't matter".)
I completely agree with this. There were a host of similar services when Facebook appeared in my radar, I was signed up to a couple of them. Its only because more friends signed up for facebook that it seemed to have a snowballing effect. It didn't seem in any way superior (well except compared to myspace).
In Germany, we used to have a VK-like social network aimed exclusively at university students that was big before Facebook even appeared. To this day I have no idea how that died so fast and hard, and how Facebook managed to overtake it when it hadn't even translated the interface. Ze English izn't zecond nature to all ze Germans.
Ah yes, the * VZs. From my perspective, there's a few reasons. One, my friends were very privacy conscious and would often either not sign up or use a weird name (like some people do). This made it hard to find people. Two, the user experience sucked hard. Third, they had different domains for different subgroups (I remember one for school children and one for students).
Finally, if you went travelling to any other country (except Austria or Switzerland maybe), the rest of the world had Facebook. So to keep in touch, you also needed Facebook, which had a better user experience. Why bother with both?
It's a testament to the poor state of the art in user experience for early social networking sites that Facebook had a (relatively) "good" user experience. It has always been horrible, except relative to most of its competitors.
All three of the above communities (PHP, Ruby, and FnProg) are diverse enough that a PHP meetup in location A could be culturally similar to an FnProg meetup in location B, and so on.
you could definitely argue that a company using PHP nowadays would find it harder to find good engineers because the best ones who care about quality, performance etc don't want to work on a PHP app
Mind, I agree with you, but given the Holy Documents Handed Down By Our Lord and Savior, Paul Graham, HN... might not be the safest place to say it.
Edit: so, I'm clearly getting a lot of downs on this... maybe sarcasm in reference to PG was going a bit too far. Oh well. I'm not deleting or editing any of it, because that's sort of dishonest.
True. But they might have failed with any other choice. Technology is overrated. Yeah, it matters, Yeah it helps. But the right foundation won't save a shite product.
A truly good idea will generally find a way to succeed despite the technology it is built on, though. Look at Facebook, Slack, and countless others running PHP or Minecraft running Java and its apparently horrible code base (I've never seen it, so that is secondhand)
A number of things actually follow more logically than tech doesn't matter which is counter intuitive and counter to most other endeavors in life.
- We aren't very good at judging the relative virtues of tech
- Most tech is good enough to express most concepts even if not equally well. If its possible to express it even if it takes 3 times as much work and is only 70% as good you wont notice from the outside how much the tech mattered.
- Good ideas are worth enough money to throw enough time/money at them to be moderately successful
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 favourite website or app, but lamented that it was written in Php or JavaScript or Go or Java. It's only us (the HN'ers) who fret about this.
Don't believe me? Imagine the look on everyone's faces at the tech publishing houses around 2009 when books about Objective-C sold a few hundred copies a year to doing tens of thousands per month when the iPhone rocked the world. This happened without a proper language hot stove on Hacker News, no?
People care about outcomes. People care about products. People care about being dazzled. People care about showing their friends this incredible thing they saw on the web/this new app.
Doesn't it stand to reason that the people that actually know how things work under the hood are the people that care about such things.
You could say the same thing about cars people don't care about what sort of engine is under the hood or how it works they just want to go places! It doesn't then follow that all cars are the same and you are just as well getting any one of the millions of cars or even any one of the models out there.
You have a logical point for sure. I think it might be an apples to oranges comparison in this case though. I just don't know that building cars is the same as building websites and apps. I know Php and JavaScript can respond to an HTTP request. I don't know how to optimize an internal combustion engine. There's probably parallels in terms of expertise with software developers, but I can't be sure.
> I just don't know that building cars is the same as building websites and apps.
Indeed it isn't. "Maintenance" has opposite meanings in those worlds: maintaining a car means keeping its original functionalities still available; maintaining an application means letting it evolve.
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.
At this point, I would have no problem arguing with a straight face that your choice of technology stack might be the least important factor in whether your business succeeds or fails. I don't mind if I get torched for this, it's just my current, non-Silicon Valley, non-substantiated opinion at this time (though I don't think it's without merit).
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.
Only if you extract a ton of value per user or can serve a huge number of users per machine. Otherwise, upping the number of servers by an order of magnitude will start requiring an operations team to maintain.
That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.
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 the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok.
php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box.
memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails.
because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit.
cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind.
but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some.
but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure.
what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.
PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.
In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails.
I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core.
So comparing PHP to Rails is a bit apples and oranges.
it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.
In this case it was a technical comparison; the original poster stated, "php's performance was an order-to-two or magnitude better than rails".
If you are making a technical comparison then it needs to be at the correct layer of abstraction. If we were to compare performance of Laraval and Rails that would be a fair comparison.
If we are comparing on performance then PHP should be probably be compared to Ruby+Rack since that is sort of the lowest common denominator.
I'm not dogging on PHP here either. Even comparing at the correct level; PHP is still faster, but lets make sure we are making the right comparisons.
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.
I feel your pain, I also worked on a large MMO style mobile game backend, but my situation was a lot better because as you say AWS is a lot more mature at this point.
Dealing with limited resources such as MySQL and Redis is a problem you still have to fix when you move away from PHP though.
As for the Facebook runtime, for us it was a case of drop in HHVM, fix a handful of issues and get a 4x or 6x speed increase for free. You only need to change the way you write if you move to Hack, but I think I agree with you that's probably getting to the limit of the effort reward tradeoff before you rewrite in a different language.
"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 "only" 50ms.
And even whey they were not over yet there was no fork for each request. A pool of workers was forked beforehand, and each worker could handle requests one by one without restarting (only PHP environment is cleared, OS level process is not restarted).
The whole reason your Apache was (kind of) expensive to fork was PHP. You've only moved that forking to the PHP-FPM process.
But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though.
It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)
Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.
Looking at things from the other side: being a manager and trying to sell projects to reduce technical debt is really freaking hard in a world of short-term outlooks and revolving door of CEOs that want to improve numbers this quarter or the next, not a few years down the road.
This is entirely true, but I have never worked with someone beyond the leader of my immediate who though the same. Most managers don't care what cruft is in there when it ships.
They don't until things break, your app can't handle the amount of requests coming in, can't insert and fetch data in a reasonable amount of time, etc.
It's at this point that shit falls apart and the manager starts to care about these technical choices and all of the time and money that will be needed to be spent to rewrite.
Call it maintenance costs if you want but those costs are directly affected by the technology decisions you make.
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.
Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.
Looks like you're reading that wrong? Java 8 is listed twice. Java 8, when using the non-standard library version of the program is second only to C++. This is pretty much as expected.
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)
PHP's execution performance is highly dependent on whether you are piggybacking the C implementations, or pure-PHP ones. That said, this is still a correct benchmark, if your use case involves a lot of regex.
I don't care about performance.
Unless we are speaking about orders of magnitude and my use case has an absolute need for performance.
If I only cared about performance I would write everything in assembly optimised for every specific architecture.
But strangely I'm much, much, much more productive writing in c#, Java, groovy, f#, ruby and whatever language is appropriate for what I need to do at a certain time.
For sure I won't start a new project using a language in which writing such abominations as accessing the database in the presentation layer is not even discouraged, but it is actually encouraged and taken as an example on HN in this thread.
Enjoy your marvellous php.
But please stop the bullshit that pushed a lot of people to use that franken-language rather than using a better approach.
Most professional PHP developers I've anecdotally worked with use a Model-View-Controller pattern these days, where the SQL is abstracted away in the model under something like Doctrine2-DBAL, Propel2 or PDO. If I was hiring for a developer and they suggested putting raw SQL in the view layer, I would reject them. If I received a pull request from my team which did the same, I would reject it.
You seem unnecessarily argumentative about this, almost like you're angry and I really don't understand why. There really isn't that much difference between languages like Ruby and PHP to warrant this and almost anything can be expressed in almost the same way, the only real differences are syntactic sugars and the "flexible" type system.
This exactly. Never been a PHP developer, but I did get handed a PHP webapp to copy some functionality out of for a replacement C# webapp. I was a little surprised to find out that it was written in a rather Rails-like architecture using some PHP MVC library, I think it was CakePHP. Rails was a hit, and a great step forward in web development, so naturally every other language copied as much of it as possible, including PHP. There may be plenty of weird quirks about the language still, but at least the architecture is much improved.
Many/most PHP platforms these days do claim to be either MVC or Rails-based or both. CakePHP is not a bad example there. There are however a few other very large projects whose take on MVC is lacking to some degree. Drupal is not bad, Joomla is worse, and of WordPress the less said the better. Note also that those projects are listed in order of increasing popularity.
Modern PHP frameworks and tools are good, perhaps even excellent. Composer and the PSR-# efforts have spurred a renaissance in code quality and interoperability, and PHP7 brings some truly impressive speed improvements. For those of us who aren't stuck supporting legacy code, that is. One of these days I will be working with a language whose syntax I enjoy, but until then the language that puts the "sin" in "syntax" will (for better or worse) keep getting the job done.
plus like you say PHP might be faster to get started with but becomes much slower on larger projects due to inconsistent error handling and language design.
Don't trust everything you read on the internet, run the benchmark yourself and see if that result is actually reproducible. (Depends on the heap size.) There is also a "non-std lib" java test case, which doesn't generate as much garbage and, of course, performs much better.
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<Integer> s = new ArrayList<Integer>();
to
ArrayList<Integer> s = new ArrayList<Integer>(8192);
> But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right?
Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.
I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"
I'd upvote this many time if I could. I am in the same boat--my team helps maintain a ten year old web application that is used by the largest companies in our domain. The application is literally the backbone of data used by these companies to make money. We have reliability issues, and sometimes clients get a little upset, but every year it is the same thing: how much do we need to budget for support?
> Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.
This. In my previous job, I was literally told by my boss, that they'd consider switching from PHP to something like Ruby or whatever, but PHP programmers are cheaper so that's why they stick with it.
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 anything else.
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 technical feature.
______________________
1. Granted, one of the major design goals of Rust is replacing C, but you get the point.
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.
At which point did you decide not to read the comments properly?
The gist was that PHP was designed for web use, so it's almost always facing the internet. C on the other hand is very much multi-purpose. Both can be made secure, but maybe it's less effort using something that helps you with security (Hack, Rust, etc.).
(BTW, your comment contains a huge fallacy: Just because a majority of packets touches something written in C, that doesn't mean a majority of C code written is exposed to the internet. This is arguably the entire point of e.g. iptables.)
> Only engineers care about programming languages. Seriously. That's it. No one else cares about them.
So what? Who else could care for something apart from those professionals using it?
Maintenance is the biggest part of software development. A wrong technological choice can turn my nice job into my worst nightmare. Why shouldn't I care?
I think the intention is: While they are important to us, languages are frequently distorted to the point that we believe that company success as a whole is dependent on it. Companies like Facebook flatly contradict that. I agree with you in spirit: Facebook would obviously prefer not PHP. But if the choice is: Learn something other than PHP or use language I know to test some idea, I think the latter is an obvious choice.
Runaway successes like FB are outliers. Failed businesses OTOH are quite common and usually have a number of causes where bad technology choices can be at least a factor.
You call it poor management in retrospect, but it's succeeding in spite of the tools when you're still doing ok. There's a lot of companies that exist in between failure and "Facebook" who don't have hockey stick growth curves who also can't afford needlessly higher technology costs, whether that's in infrastructure or staffing or opportunity costs in getting features to market. If PHP does't incur a higher cost personally, go for it, but it might be a strategic disadvantage later if you don't hit it big.
"Only engineers care about programming languages."
It's sadly quite common for non-engineers to make technical decisions such as what language, tool, or hardware will be used, and everyone else just has to live with it.
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.
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.
To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.
> large often-changing content. This is where PHP is still king of the web.
PHP is still widely used, but there's a myriad of other contenders: Java, ASP.NET, Python (Django,Flask,etc), Ruby (Rails), Perl, Javascript (Node,etc) and others.
I'm not sure about PHP being the "king". PHP might be the most widely deployed thanks to either FB or the huge number of legacy bulletin boards and wordpress sites, but in terms of new deployments does it still dominate? Probably not. (For novices, a static site generator is definitely the way to go, until you run into it's limitations.)
All of the languages you listed have a way steeper learning curve than PHP. PHP creates a lot of really small steps you can take getting from "I roughly understand HTML" to "I can build a full 3-tier MVC buzzword-of-the-day app.". For anyone not intending to become a full-fledged programmer, but instead just to add a little bit of interactivity/dynamism to their website, it's still the path of least resistance.
I'd argue that Javascript (sans all the frameworks and bullshit) will also get you there quicker, because of the intrinsic DOM connection. But yes, backend JS sucks.
I also made a start with PHP. Still, PHP has been slow to learn from other languages and frustratingly refused to change established behaviour. I found PHP to be far more "dangerous" for the amateur programmer than other languages. Finally, I switched and never looked back.
From teaching beginners, I actually think Python + Flask has a similarly shallow learning curve, but more room to grow and to "do it correctly" (e.g. the templating is much cleaner and the routing much more powerful). I recommend it.
echo "<h1>hello</h1>" vs... damn, how do you even print a line in Javascript (Node, to be fair)? console.log()? Wait no, that prints to a terminal. Response.write? Oh, wait, I have to implement the http.createServer callback? Yeah ok, oh and it's ... response.print? No, no it's response.write. Oh what it's not working? Oh I need response.end() as well.
Hopefully you get the point.
(I do agree that PHP without something like Symfony, Yii, ... Laravel, even Cake could be very dangerous, or at least, counter-productive for amateurs trying to learn though)
> It falls apart when you have a large often-changing content.
Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?
I haven't tried jekyll so I can't really comment on it. Im guessing it only generates the changed files everytime you push to git, no? As for your question, it depends on other factors too. Who are your users, what is your web app, is it an ecommerce site? Is the jekyll/git/CI workflow easier than just pressing a few buttons on the screen everyday? Those are the questions you should ask. jekyll might be obvious for us devs but we are a minority compared to the rest of the population.
Take HN as an example. This can't be done as a static site.
Or a simple guestbook or hit counter.
Where the lines may blur is JS front end talking to a BaaS... This may make it possible to glue up impressive sites using just HTML and JS with no custom backend requirement.
For many use cases, this is not relevant to the end result.
For many use cases where it is relevant, static site generators like Jekyll can actually imitate "dynamic content" from the perspective of the people running the site.
The most important use cases for dynamic content these days are web applications, as distinct from "websites". On the other hand, web applications are also the most important use cases for better development ecosystems than are easily attained with PHP.
In my experience and observations, the cases where PHP's easy provision of dynamic content capabilities make the most difference are websites (as distinct from "web applications") on shared hosting platforms or bootstrapped by existing content management systems like WordPress and Drupal (which are, in turn, often easily used because of either hosting platforms specifically for those CMSes or shared hosting providers).
NOTE: I'm not sneering at "websites", as distinct from "web applications", as many people who draw such distinctions do. I'm just pointing out there is a distinction to be made between two different types of projects involving deployment of a codebase to a web server. Speaking only of the technology's proximate purpose: in one of these, the primary purpose of it is to make content accessible to the public; in the other, the primary purpose is to make functionality accessible to a userbase.
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 one that is a direct clone of Rails.
I've seen plenty of companies fail (or at least stall) because of technical debt. PHP certainly isn't to blame for that but it doesn't exactly lead by example either.
I to have seen plenty of companies flail and get bogged down because of technical debt and a just get it done culture. It's really hard to begin with a "yes it's a mess, but it works" culture and transition to anything else.
Plenty of A rounds have been spent trying to make a sand castle taller.
This is not unique to php - I'm sure you can do it right - but it's more common to it.
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.
I like to call myself a "biztech" entrepreneur and these are the reasons I stick with PHP. Specifically using Yii2 I've been able to whip up MVP's and simply just focus on getting traction. In my experience that is all that matters for a startup.
> 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 beautiful object tree to describe everything, just do the minimum amount of work to take the garbage input and generate the garbage output, and be done. Don't worry too much about your code being beautiful, because it lives in a dump.
This may sound negative, but working in a dump means you don't have to worry about appearances while you do what you came to do. You can always take a shower on the way out :)
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.
Not sure about that. Most companies biggest problem is finding talent employees and most experienced engineers will not want to work on a Php codebase especially one full of technical debt due to the variety of other options in languages which compile and miss out on a huge percentage of php problems before you even run basic tests.
Accumulating bad code is like pushing your company from a plane without a parachute and hoping that the next guy creates enough cushion in time before the landing destroys the company (not the fall that kills you)--you survive because you are likely moved on and are busy pushing some other company to its doom.
It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).
When someone (maybe me) comes and rips out my bad code later, they're going to have the benefit of future knowledge. I don't know how my code will be used in 2 years and what the requirements are, but they will, because they'll be there.
I do my part today by acknowledging all of my code is bad, therefore I don't invest a lot of time or ego in it. I try to make it in reasonably sized pieces so it's easier to rip out later (this may make it slightly less bad). If someone comes and tells me my code is terrible, I say yes it is, you might want to consider these things when you replace it.
EDIT: my opinions on this would change if I were shipping code to run on other people's machines: it's generally easy and quick to fix my code on machines I run, but updating code on other people may never update, you need to try harder to get it right the first time.
PHP isn't quick. It isn't faster than other languages. It's just a tool, and if you know how to use it well, it will be faster for you.
If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.
For anything with a server-side component, PHP might be fast if you know a lot about how to get PHP up and running properly.
Node, as a counter-example, runs on Windows and POSIX systems indifferently, and with very little effort can be a self-hosted web server for development that can be deployed to production almost effortlessly.
If you have a favorite hosting provider which better supports some tools than others, certain things will be faster, but that's because of preference and familiarity rather than any factual differences.
I think you're overestimating how much effort it is to get a PHP dev or deploy environment up and running. This isn't preference and familiarity, it's 20 years more knocking the corners off to lower the barrier to entry.
There's zero work involved in getting a static page up and running. There's minimal effort in getting Node up and running, and I'd put it forward as the new "path of least resistance" especially because of the heroic work done to make Node run properly on Windows.
Getting WAMP or whatever configured and installed, or loading the PHP module into Apache or Nginx and getting that working is a giant pain in the ass compared to either of those two things, even if you've done it a dozen times before.
Compared to Ruby, sure, but pretty much everything is at this point. Compared to Node JavaScript? Not even close.
They've made some impressive gains in PHP7 that others should take note of. Ruby's particularly out of shape here compared to the competition, though Python isn't exactly a speed demon either.
Yes it is comparable to Node. Most benchmarks show PHP with blocking calls against async Node calls. PHP has the tools to do async no problem. I use ReactPHP all the time to do this stuff; it works great for fast scraping.
See an older counter-point with the much slower PHP 5.5:
Amen. The ironic thing is most people believe that the fashionable language/framework du jour they're using in their project is "high quality code" that will be maintained like that forever, while turning their nose up at PHP code that is "disposable" but in reality more likely to outlast.
So people who don't care make successful projects and PHP is a garbage language that is responsible for more successful projects than any other server side scripting language. LOGIC.
My point is that the people don't care about the tech. They're worrying about the problem they're trying to solve. New companies that priotitize tech over finding and pleasing their customers don't live long enough to see the benefits. Just my observation. I've been through the "but if you don't build it right today you'll have to build it again tomorrow... that makes no sense" phase. I made some great code, but very few people are running it. My worst code is the code the most amount of people are running... it's because I got it done, and I got it rught before my budget ran out.
The primary objective of programming is to 'provide a solution to a given problem'. Everything else is secondary. If PHP is capable of providing that solution faster and cheaper than its competitors, it will always be the winner. PHP is a practical language and its success demonstrates that fact.
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.
I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class.
And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.
That's because many dislike prototypical inheritance. It's perfectly usable.
As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.
In fact what's the difference between prototypical and conventional inheritances? I think python has exactly the inheritance model of JavaScript, and statically typed languages differ only in that they make the class=type, object=value distinction (so you can't dynamically change classes).
It's not. In python, classes are entities like any other object. In JS, classes literally don't exist. Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword.
JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say:
var Person = function(){};
Person.prototype = {name:"bill", addr:"foo"};
var charlie = new Person();
charlie.name = "charlie";
charlie.addr = "baz";
var NewPerson = function(){};
NewPerson.prototype = charlie;
var bill = new NewPerson();
This code is totally valid. bill's prototype chain looks like this:
bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype
> A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype.
A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`.
Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them.
Consider your example, translated:
class Person:
name = 'bill'
addr = 'foo'
class Charlie(Person):
name = 'charlie'
addr = 'baz'
class NewPerson(Charlie):
pass
bill = NewPerson()
That looks the same, but conceptually (and actually, code-wise), that's not what JS is doing. Here's what's actually happening, in psudo-python:
class Person({name:"bill", addr:"foo"}):
#there's no syntax for object literals in Python
#such a thing doesn't even make sense: so I'm improvising.
pass
charlie = Person()
charlie.name = "charlie"
charlie.addr = "baz"
class NewPerson(charlie):
#note charlie is an object, not a class
pass
bill = NewPerson()
In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
Classless object literals actually don't make sense in the Python model. It seems like you're the one who needs to brush up.
In any case you're not actually providing any links or facts, so unless I dig through long articles on metaclasses in python, I can't verify anything you say. Please prove your point, or at least provide I link so I can verify.
> In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
Right; this is actually why I like Python's way a bit better: it makes a more formal distinction between the two. In Python, Charlie is also an object, and you can change all its properties and everything, just like most¹ other objects.
Most of what you try to use to distinguish JS from Python applies just as well to Python. No, it isn't exactly the same, and I think the semantically equivalent code in Python will often contain more information than the JS. E.g., in my conversion of your JS, the class is an instance of `type`, whereas — as you correctly note — it's "just" an object in JS. It's not really though; in most JS that devs will write, the object is a type, but that distinction isn't explicit in the code. It's implicit in the dev's intentions, expressed only in the general sense that the code is being used.
e.g., if I saw, in JS,
var Person = function(){};
Person.prototype = {name:"bill", addr:"foo"};
var charlie = new Person();
while it is true, technically, that `Person` is a function and `Person.prototype` is an object, the semantic meaning being expressed in this manner by the author of this setup is that `Person` is a type, and that charlie is an instance of that type. It's just explicit in Python. (To some degree, JS is aware of this fact too; `charlie instanceof Person` is `true`, after all.)
In a single-inheritance class in Python, during attribute lookup, Python will attempt to look the attribute up on the object's __dict__; if it doesn't exist, then it looks up the parent type (by looking at __class__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".²
In JS, during attribute lookup, JS will attempt to look the attribute up on the object's internal list of attribute (I don't believe this is exposed like __dict__ in Python); if it doesn't exist, then it looks up the parent type (by looking at __proto__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".
What material difference exists here?
¹objects in Python can forbid attributes from being set, or limit the available attributes. I'm not sure to what extend JS lets you do that. e.g., `object` in Python is very restrictive about allowing additional objects.
²I'm explicitly ignoring multiple inheritance here, so I'm vastly simplifying. Python will actually use the MRO for this procedure, but in the case of simple inheritance, that's equivalent to following __class__. I'm also ignoring __slots__ for simplicity.
Yes, but it's (roughly speaking) an instance of a "Class" class. In the "Person" example, the prototype of a "Person" object is another "Person" object (until the chain reaches an "Object", at least).
This code doesn't look good to me. What is the benefit of inheriting objects from objects instead of inheriting classes?
When we have distinct functions, classes and objects we can easily understand how they are supposed to be used: you can call a function, create an instance of a class, call a method of an object. With Javascript you cannot easily see whether you have a plain function or a constructor and how you should use it. And interpreter won't tell you anything if you forget to put a `new` keyword.
(And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Your code can easily cause a bug. Imagine Person's constructor looks like this:
function Person() {
this.friends = [];
}
...
var NewPerson = function() {};
NewPerson.prototype = charlie;
Do you see the problem here? To fix the problem you have to rewrite the code using Object.create() and call parent constructor with Person.call(...).
I have written applications in Javascript and I think that Java-style classes are the best for readable and maintainable code. All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Your code example proves that because adding a single field to a Person's constructor requires you to find and modify all of the objects inherited from it and this task is not easy too.
It sounds like you're trying to write Javascript as if it were Java. I've worked with developers who did this (e.g. http://chriswarbo.net/blog/2014-03-12-trolled.html ) and I would advise that you instead try to write more idiomatic Javascript, or else use some kind of Java-to-Javascript compiler.
Your critique of Javascript is basically "it's not Java". I could make a similar critique of Java not being StandardML, but it would be about as meaningless:
When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used: you can open a structure, create an implementation of a signature, apply a functor to a structure.
> (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Personally, I prefer "var Person = function Person(...) {...}" since it makes the code more symmetric (the second "Person" makes stack traces more informative). The "function Person(...) {...}" style makes an artificial dinstinction between functions and everything else.
> All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications.
Javascript is a dynamic language; there is no ahead-of-time compilation. Things can only be done at runtime, including adding properties to objects. If you mean that mutating values should be avoided, then I would emphatically agree. That's certainly not a Javascript-specific issue though, and Java is just as riddled with mutability as anything else.
I haven't had enough experience with prototypical inheritance to comment on it vs class-based inheritance; I've been burned enough by class-based inheritance that I tend to avoid inheritance in all forms (and OO too, these days).
I am trying to write a code that is readable and maintainable instead of building complex abstractions. That is where Java classes fit perfectly (unless you are a beginner who had just read a book on patterns and tries to use every one).
I do not see any benefit in prototypes. It just makes code more complicated and buggy. I would happily use them if I knew a way to do it while keeping code simple.
> When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used
Yet Javascript has neither of those.
> If you mean that mutating values should be avoided
> I am trying to write a code that is readable and maintainable instead of building complex abstractions.
My point is that what's "readable and maintainable" depends on the language; especially on what facilities it provides, and to some extent community consensus (what's 'idiomatic').
Javascript's main facilities are first-class functions with lexical scope, lightweight key/value mappings (which it calls "objects") and prototypical inheritance between those objects.
Java's main facilities are classes with properties and methods; whilst it's recently gained first-class functions, most Java code has been written without them, and they'll always be in competition with classes+methods (e.g. look at all of the APIs which use single-method classes, like "Comparator").
These are very different, so what's readable/maintainable will differ in each. For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'.
In idiomatic Java, such objects should be instances of a class, which should either be global or else implement a global interface. Since global class/interface declarations require standalone files, our declarations end up very far away from the use site; this prevents us accessing the use-site's scope and puts us under more pressure to make it descriptive, generic, reusable, etc.
> Yet Javascript has neither of those.
ES6 has a module system, Java has its "package" system. Trying to apply SML practices to either is a bad idea, just as trying to apply Java OO practices to JS is a bad idea, or trying to apply Lisp macro practices to C is a bad idea.
> For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'.
Idiomatic doesn't mean maintainable and scalable. Imagine you are working on a project in a team, not alone. How do you understand what kind of "lightweight" object you should pass to this function:
function foo(data) { .. }
When you have thousands of such functions you'll spend most time reading through their code to understand what type of argument they need. This means "idiomatic" javascript code works only when it is small in size. Once it gets larger you'll have to resort to old school non-idiomatic Java-like classes and a static typing system.
Regarding prototypal inheritance I don't understand how it is supposed to be used. Let's say we have constructors for objects User(name) and SuperUser(name, privileges). I understand if `SuperUser` is inherited from `User` (class-based ineritance), but I don't understand what is the meaning of SuperUser being inherited from some user charlie. Why `charlie` and not `john`? Why do I need an instance of common `User` to create a `SuperUser`? And as I haven't seen the explanation in above comments I guess you don't understand it too yet evangelize about it.
I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all. As an argument I can say that a helper method `Object.create()` that is required for object inheritance was only added in ES5 [1] and haven't existed in earlier versions. This is how you create objects from objects without classes and even without constructors:
var person = { name: null, greet: function () { ... } };
var john = Object.create(person, { name: 'John' });
var charlie = Object.create(person, { name: 'Charlie' });
var superCharlie = Object.create(charlie, { isSuperUser: true });
I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.
>How do you understand what kind of "lightweight" object you should pass to this function
...and this is where well-documented interfaces come in.
>but I don't understand what is the meaning of SuperUser being inherited from some user charlie.
That was merely an example to express the difference: the idea is, instead of writing a class and doing things that way, objects are cloned from one another. If you want to create a user with special powers, you clone the user object (usually running a constructor function along the way) and give it whatever new functions you want. If you want to create more of these special users, you make them all have that one as a prototype. Typically, the prototype object is never actually used or altered from the defaults, as this would be confusing, and is given a constructor function to instantiate state. But it doesn't have to be.
>I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all.
Wrong. Object.create may be new, but prototypical inhertance is an important par of how the constructors you claim to be the way objects were meant to be created work. Function.prototype, the property which determines the prototype of objects created by a constructor, dates back to ES1.
>I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.
Also complete nonsense. Prototypical inheritance was originally implemented in Self, a system developed my Sun Microsystems, and a descendant of Smalltalk-80, which certainly was designed for large applications. JS may have been built for writing simple for validation scripts, and it may be a deeply flawed language in some respects, but the fundamentals of the language, prototypical inheritance, true first-class functions, and lexical scoping, are all things that Eich got right. And given first class functions and lexical scope are still things that language designers have trouble getting right (I've got nothing against class-based OO, so I'm not including it here), it's even more remarkable that Eich did it properly in 1997.
> 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 Symfony you won't miss a notice.
I think default PHP error handling system is wrong - there should be no warnings or notices, only exceptions. Sadly OOP was not very popular among PHP devs in the beginning.
I would imagine your doSomething JS function will fail and produce an error in the logging console because doSomething is probably not expecting to receive an undefined. Unless you've written it to handle that scenario and fail gracefully which is probably a good thing to do anyway.
Your whole example is silly. Stuff like this is why you write your PHP/JS/Python/Ruby code in a tool like WebStorm/PyCharm/RubyMine which does enough code analysis to realise you've made a typo and flag it.
It doesn't help to find a misspelled property (and doesn't prevent you from dividing by zero too). You need a static typing system like TypeScript to detect such kind of bugs.
> And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?
I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all
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.
This seems to assume that a developer necessarily hits an MVP in PHP faster than in other languages. This might be true when comparing with the tooling/dependency nightmares of JS/NPM, but a half decent Python dev can get a Flask app up and running in about 15 minutes.
I read the post as saying that PHP self-selects the kind of developer that is great at making an MVP, thus why so many companies and projects are written in this garbage language. I don't think the post intends to implies that other languages are slow to develop, just that their developers are.
> 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 files, that you ftp-d in and it just worked.
99% of the friction is in writing the first thousand lines of code and PHP meant that nearly all of those lines was business logic, not unescaping POST data or parsing GET parameters.
PHP doesn't remove your ability to think clearly. It is true that it does not provide helpful additions for algorithmic work, but it does not put challenges in your way when writing web-apps. And yet, it does not force you into too much magic about how it works - just enough abstraction for a messy coder.
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.
> It did one thing and did it better than anything else of the same era
I would argue that it still does. It's not a great language, but to just get something working I still can't think of anything better that doesn't require lots of planning or infrastructure
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
PHP also has IDEs, tons of tools, tests, and gets deployed with many services and scripts. It's an inconsistent language, it's used by newbies in a very bad manner without even understanding the bare fundamentals of HTTP, but I really wouldn't call it a garbage language. If it were, it would have been dropped ages ago.
But I see what you're getting at... if you need to whip up something quick, don't start experimenting with the "flavor of the day" language or library.
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 level people try to make the community better, however, the whole community filled with mediocre developers who cannot even understand Rail != Ruby, and also they believe ActiveRecord is the only persistence layer they can use, and stop learning write native database query script.
Finally, good luck with writing a unit test against an API not created by you because, you have to go through deep into the source code just for figuring out what data structure return and give.
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.
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.
I agree with this as well, although this is about Rails. I still have a legacy project to maintain in Rails (a big project) but that is (hopefully) the last I see of it up close in my life time.
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.
Products fail. Languages solve problems. Business domains have different problems. PHP won't solve a telecommunication challenge at scale. I believe in polyglot development. Choose the language and framework that suits the challenge. Not all shoes fit.
The problem with your argument is that most php sites fail when I/We use them(throwing exceptions on the site - really?!), they've the worst security on average and php is also a slow and hardly maintainable development platform. Yeah, you can create crap fast but that's all. With this "fast iteration" bs you'll live in an illusion that you make money for the company but actually it's the opposite and you're contributing to the deterioration of IT - if there would be only php, the internet would be far worse and we'd have the same technology level as in the 90s.
Edit: guess why everyone will need to rewrite their stack in another language when they've bigger traffic on a php platform
Eh, you can do rapid prototyping-type garbage code in any language you are proficient in, as you can do the endless-architeture-meeting, special snowflake beautiful code, enterprise-level everything documented and automatically tested continuos integration and deployment to the most popular containerized/virtualized environment for a reasonable price of $millions in PHP or even bash or powershell.
V1 is usually shit in any language and if it does what it's supposed to do, it remains shit forever. I've seen shit in C#, Java, and ROR. I've seen stored procedures stringed together inside MSSQL Server vomiting HTML snippets and PS shells giving birth to Excel files to be consumed via network share by some poor soul pressing a button in Excel. I've seen systems written in "enterprise" style, by "enterprise" developers without a single automated test and 20+ levels of abstraction with cross-dependencies running like spider web among 10-some "sub-projects".
I'm not even talking about time-tested shell scripts you can find included by default in your favorite distro or the widely beloved ./configure.
I guess the point is, the language has nothing to do with the attitude of the developer / project manager / product owner. It's easy and convenient to just dump your problems on the tool you're using, but the reality is more deeply rooted in the whole approach to software development (just get shit done), project management (the requirements have just changed, dude!) and the general "i need it done last week" attitude of the product owners.
But sure, let's collectively shit on PHP, just because it's easier. Just like writing shit code is.
I work in C# every day. I love the language, I love Visual Studio, I love the application lifecycle management features of the ecosystem. There's very little I don't like, or at least understand.
I started my career as a PHP developer. Any web project you prototype in C# could be prototyped in PHP in a small fraction of the time.
And any PHP thing could be easily prototyped in C# using MVC framework or such. 0 to http-response time is easily comparable if not even faster to what you'd have with PHP. You don't even need IIS. C# is a fine language and I have enjoyed it thoroughly before returning to PHP after some years, but you also can breed monsters with it. Cheers!
touch public_html/foo.php gets me to a http 200 with a valid php file (with the assumption that i already have a public_html directory with mod_php or the like enabled), how fast can you get a C# to http 200 ? :)
I have IIS running with c:\inetpub online (just like you have apache with mod_php). I put a valid foo.ashx up there and voila - the field is level. Okay, the invocation is a bit heavier,
<%@ WebHandler Language="C#" Class="Handler" %>
using System;
using System.Web;
public class Handler : IHttpHandler {
public void ProcessRequest (HttpContext context) {
... code ...
versus just
<?php
but, come on, it's not that bad/difficult, is it?
on an tangential note - I never had imagined i'd be defending the point that C# is as simple as any other language... Funny how life sometimes takes you to unexpected places.
I think this overly dismissive/elitist approach is part of the reason why alternatives failed. Couple that with the ridiculous claim that a developers' time does not matter.
This is so true from my experience working for companies using PHP. You can advocate all you want to clean up code, but in the end, if it doesn't create a new feature its not going to happen.
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.)
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.
I would never have agreed with you before, but I just came from a place where the fear of using something that was not sexy just paralyzed most of the developers at the company. They spent more time talking about new tech than implementing it. I've sworn off PHP, but at one point there I would almost have preferred they suggest we use it, if only to get something shipped.
Now I don't fret as much about unsexy tech. I do still advocate for new things when they make the team more productive, but I hope I never have to work at a place again where the latest and greatest stuff is used and people get nothing done.
Most of the cited successes were savvy early movers — every company mentioned aside from Slack itself is at least 10 years old. In the more mature, more varied tech space of today PHP seems like a non-starter.
> 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.
My perception of the Clojure crowd is the exact opposite. They seem to be a bit too in love with the process and craft and not enough with the end results. That being said, I'd much rather code Clojure as a day job (I promise to be market focused!) than PHP. Right now I am almost all Python. There are definitely a lot of Python folks who are too much enamored with the craft, but the crowd is so big there's plenty of room for the GTD folks.
I think this also could be that founders don't care about tech and Php developers are relatively cheap. Engineer experienced with different technology could easily get MVP of high standard in comparable amount of time but that costs money.
I can agree that php might not be the nicest or the fastest language, and I like to say choose the right tool for the job, but writing it off just because it's php is stupid.
A couple of months back there was this php sucks article about being looked down upon because you do php for a living. Php is the language people bitch about to feel better about themselves. Even within the php community symfony developers don't take drupal developers seriously. It's sad really and even I'm guilty of doing that. A little more respect for your fellow developers is all we need. It's like judging a book by it's cover. How would you feel if <insert your fav lang> was treated that way.
Php has a lot going for it. The community is very active and passionate, new things come out at a rate you can keep up with. You can easily get passionate about it if you engage in it.
A lot of interesting projects are (being) build with it and it is obvious that php won't disappear anytime soon.
If you have to work with php and bitch about it, make the effort and solve the problem you have with it. Contribute back to the community and experience the gratitude. You'll enjoy your work more.
So there are php people that care and they try to make the best of it. I don't think they consider it to be a garbage language. They are the ones that made php what it is today which is something totally different compared to what it was years ago.
Up until the mid-2000s, if you wanted an easy up-and running web application environment without paying Microsoft, PHP plus MySQL was the only game in town. There were alternatives, but they invariably involved maintaining your own server and doing quite a bit of legwork yourself. The was no Heroku, no AWS, and tooling for python, ruby, and other environments required much more expertise to simply get an app responding on port 80.
Almost any big app you can point to that is built in PHP today was bootstrapped in this environment.
I did a lot of PHP from the late '90s up until 2008. Maybe things have changed in the intervening eight years, but I cant say I miss it.
The shared-nothing model works great... if either you're just one developer or you've got a semi-competent Ops/DevOps setup. My first job out of college used PHP with one of the Rails-a-likes PHP has. During our user onboarding process, we'd poll the server to see if a data import finished, but since the requests shared _nothing_ and the Ops guy didn't understand PHP, it would load/run millions of lines of framework code for every single tiny polling request. On launch our site crashed because two people used it at the same time. Bananas.
There's a way to make Apache fork after some code has already been run, but boy howdy if you don't do that and love those mega-frameworks.
If people would focus more on usability, comprehensibility, clear algorithms and project structure and precise requirements we could probably skip debating over languages altogether, because programs would look beautiful in any language.
Hack is awesome, but we decided to go with PHP 7 and this choice was primarily made because of lack of tooling on the Hack side. Things like New Relic are not available and these type of things do matter a lot when it comes down to choosing the programming language.
I must say that PHP 7 is a great language nowadays. Most of the modern concepts are baked into a language or are about to be developed.
At some point, I wish Hack and PHP merge into a single language in the future, somewhat similar to what happened to Node and iojs. I'm not sure if Hack is going to be around in 5 years, but I'm pretty confident about PHP.
I'd definitely love to see more articles about Hack and people's experience with using it in production.
With the changes in PHP 7.0/7.1 & the powerful frameworks (Laravel & Symfony), PHP has made a dramatic turn for the better in the past ~3 years. I work with Laravel daily and it is actually an enjoyable experience using PHP.
Most of the hate for PHP comes from the PHP 4 days, but we are well past that and charging ahead with featureful yearly releases.
I've used both Rails and Laravel in production, and while I equally love both, the amount of hassles you face with rails in prod is an order of magnitude more.
That's not a fair comparison though. For any non-trivial app, most people deploy PHP using a CGI, PHP-FPM being the standard. Even the cheap, shared hosts provide FastCGI these days.
That being said, getting RoR or Django up and running is really no more difficult than getting Laravel setup and running via PHP-FPM.
>I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound
this is certainly what got me started with PHP and what makes its so easy for beginners
> Almost all languages these days let programmers compare, e.g., integers and floats with the >= operator; heck, even C allows this.
The implication that C is an especially strict language for type conversions is strange. C is actually one of the loosest languages for type conversions. It's even legal to do things like compare pointers to integers (though most compilers warn you)!
PHP is great for HTTP requests. It's not that good for listening on sockets, running an event loop, etc, which is what you're likely going to do with real time messaging.
Unless you are using ReactPHP, PHP doesn't handle Http requests in any serious production configuration, the server fronting PHP does( Apache ,Nginx). But PHP wasn't design with Async programming in mind so using ReactPHP is more than tricky since most operations are blocking.
That wasn't my point. PHP is great at HTTP because it doesn't have to do HTTP, and with php-fpm and mod_php it has first class support with Apache and Nginx. Node isn't very good at HTTP, Python doesn't have first class support with HTTP servers, Java has great HTTP libraries but is stateful, etc.
If you want to handle HTTP requests quickly, reliably, repeatably, with minimal setup and maintenance, I still argue that PHP is one of the best. And yes, because of Apache and Nginx, but that doesn't nullify the point.
"Node isn't very good at HTTP" is just blatantly false.
Most languages don't "have to do HTTP" and those that do often do a pretty terrible job. Somehow Node not only does it, but does it well, where a bare Node process behind some load balancers is often enough to get the job done. PHP on the other hand needs all sorts of hand-holding to work properly.
Node is stateful and not threaded, but yes you're right that it serves http out of the box. Http was a module in the early days but I see now it's core API and has been for a while. My mistake.
Node isn't a pure functional language, and neither is PHP. I'm not sure what you mean by "stateful" otherwise.
JavaScript does have threading facilities like WebWorkers, but they're often largely overlooked since the code complexity that comes with it isn't worth it and the multi-process model generally works fine. A single Node process can do a lot of work because of the aggressively asynchronous approach to processing it takes.
Node + Express is actually a pretty slick package.
WebWorkers have nothing to do with threading. They will not let you share memory, and this means that you waste time on seriazlizing/deserializing anything you pass to them, so from optimization point of view, they are more like processes. This makes js completely unsuitable for things that are data-heavy and cpu-bound (just cpu-bound may work, but it still not the best choice).
They do have a lot to do with concurrency, which is often what threads are used for. They do have limitations to fit in with the JavaScript model.
JavaScript is generally a lot better at compute intensive tasks than contemporaries like Ruby, Python, PHP and Perl due to the incredible performance of the V8 engine and others like it. The language is ugly, but it's more easily optimized by the JIT compiler.
If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.
> If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.
Java and Go work just fine here and both are used for webdevelopment.
My point is that js in not suitable for many cpu-bound operations and neither webworkers nor multiple processes are enough to help it with that. In the browser you don't have other option, but on the server you can (and in practice people do) use other languages like java or go (not to mention C/C++). This is were things like image processing or full-text search goes.
> a typical Python application server, e.g., the debugging
> cycle will look something like “think; edit; restart the
> server; send some test requests.”
the "most typical" Python stack (wouldn't call it a application server) is probably built with Django where you don't reason about the Server restart, it's as fast as changing something in PHP.
P.S.: I don't use Python that much anymore. Other people would say that the thing I'm using now takes endlessly long to compile and has some wierd operators.
FWIW PhpStorm handles property type hints via docblock annotations and it works quite well, I've found myself not truly caring if the language enforces it as long as my IDE does.
PHP 7's type declarations are enforced at runtime, rather than Hack's compile-time types.
This has its pros and cons. This means these declarations are always enforced, even when calling between typed and untyped code. However, there's no compiler to catch you out, at least not just from using the interpreter. Your IDE, or an external type checker (e.g. Phan) can check them for you, though.
PHP 7 also gives you a choice between weak and strict type coercion modes, whereas Hack lets you choose between enforced type declarations and unenforced type declarations.
As for the specific things you can type in PHP 7.0, there's parameter and return type declarations for `int`, `float`, `string`, `bool`, `array`, any class or method, and `callable` (a function name, method reference or closure). PHP 7.1 brings nullable types (prefix any type name with `?`), `iterable` (an array or an object implementing `Traversable`) and the `void` return type (enforces that a function doesn't use `return` with a value).
Notable omissions are generics (even for arrays), and property types. There was a proposal for the latter, but it was rejected, for better or worse. As bkanber mentions, however, IDEs can still check property types if they're annotated using docblocks. Hack also has a few extra special types that PHP lacks.
I find the virtues quite uncompelling, take for example
>First, state. Every web request starts from a completely blank slate.
Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once.
>I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound.
I cannot disagree enough with the conclusion he draws from the quick feedback loop in PHP. I do PHP in my day job, because that's what our codebase is in, but recently I finally got the opportunity to use Haskell for a side project. The feedback-loop might be slower (honestly not by much, automatic reloading is a thing in almost any framework), but I'm a zillion times more confident in my code, because you are able to encode so much logic in the type system, meaning the compiler will catch whatever. Contrast this with PHP, where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours. Particularly when refactoring code, which you often end up doing while hasing something out.
Also, PHP works at a quite coarse granularity of concurrency. A thread per web request only? As soon as you want to do something more advanced, you are forced out into the many patchwork solutions (wanna do async? queue that shit).
Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry - heck PHP was my first language and I made a CMS from scratch without even knowing much of what I was doing.
That said, it has come a long way, and something like HHVM/Hack definitely helps a bunch! I just think the pros in this blog post are quite weird and IMHO incorrect.
> Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once.
I mean, you're not reinitializing it, and it's not exactly slow. And when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere.
> where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours
I'm not really sure what you mean by that. Write a method, write tests for that method. Just because PHP has weird type coercion issues doesn't mean you can't be diligent about the types that you use. And of course tools like PhpStorm understand docblocks, annotations and PHP types and classes and basically does the same thing that a compiler does, it'll show you big honking type errors if you ask it to, it'll even stop you from committing broken code if you use that option.
> Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry
I don't know about that. Low barrier to entry gets you a lot of crummy projects. In my experience PHP is a lot easier to manage and maintain in production, and that's a huge advantage to companies and products with small teams.
>when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere
It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted, like resource pooling, memoization, config loading etc.
> > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours
>Write a method, write tests for that method
Exactly, I need to write tests for things that are trivially verifiable by a compiler. And I'm not just talking about type coercion (which is a bad thing), but also missing function parameters, wrong parameters, missing initialization of variables etc etc. These are runtime errors and you either have to write tests to catch them (hence visit very code block) or manually try and reach them.
Some IDEs, like PHPStorm, can you get pretty far though.
>Low barrier to entry gets you a lot of crummy projects
As someone else mentioned in another comment, 1% of PHP projects succeeding is still a lot more than 20% of Haskell projects.
>PHP is a lot easier to manage and maintain in production
Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory for a PHP site to really run performant, adding quite an overhead to any production setup you'll get into.
Look, if you want to use something other than PHP, don't let me get in your way. However, if PHP is one thing, it is fast and always has been.
> Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory
We don't use any of that. We don't even use database connection pooling. Every request has to reopen the database. Every request has to reopen an LDAP connection to Active Directory for authentication. We are still on PHP 5.3 and we aren't using an opcache. We are using the memory-hungrier mod_php instead PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead of its newer event MPM. We are also running PostgreSQL on the same server. And yet PHP is connecting to the database over the slower network instead of UNIX domain sockets.
Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database.
All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.
More importantly, said virtues don't have anything to do with PHP as a language, and everything with request handling in the server and the framework. Yes, in case of PHP, the latter is basically built-in, but you can (and we do) have equivalent functionality with all other languages out there. So if these are virtues, they also apply to Python, Ruby etc. And then - again - why PHP?
> 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.
JavaScript and Python both have systems that allow you to do this: JavaScript has the Google Closure Compiler, and, more recently, TypeScript. Python has a number of projects that use a common syntax [1], including PyChecker.
I say this not to "well, actually" the post, but just to be a gradual typing cheerleader. It's great! We should all be using it! All the time! Please!
> First, state. Every web request starts from a completely blank slate.
> Second, concurrency. An individual web request runs in a single PHP thread.
> Finally, the fact that PHP programs operate at a request level
Isn't this just "virtues of Apache modules"?
There's mod_python, mod_perl, and mod_ruby. Are state, concurrency, and global requests virtues of these languages too?
---
Even if you do somehow convince me that these virtues are specific to PHP, you can't convince me it does it well. Hence, MaxRequestsPerChild.
To quote Radmus Lerdorf,
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
Many amazing products have been built with PHP, Python, .NET, Node.js, etc. etc.
The reality is these (above) and many other good languages/frameworks exist out there for building web apps today. we live in the time with a ton of choice, and the rest is in our hands.
I for one love the new .NET Core, but I am a little biased being a long-time .NET developer and a Microsoft employee as of late.
I've been doing consulting for several years now, as well as a MSc thesis that involved me looking at a number of open source codebases. I am generally in the "PHP is garbage" camp, but I keep hearing people say that nice codebases in PHP are possible. I've never seen one, but I am perpetually open to the idea that they exist.
Does anyone have a good example of an open-source PHP project that will enlighten me?
Sure, but most of the OSS for Python and Ruby is frameworks and libraries too... If you want an application check out phabricator, though I'm not a fan of their DB schema design.
I think there is a needless air of elitism especially here that can only come when people take themselves too seriously, seek validation for their choices, and are always on 'display'. This is also now fuelling a full scale culture of complexity as nobody wants to do things simply lest they be judged as 'unsophisticated' and lose career and other opportunities.
This cannot lead to real conversations or good software. There are far too many naysayers always eager to jump in with their 2 bits of negativity with the same cliched talk points and links most of whom I am sure would never be seen near php and may not even have used it.
The criticism goes silent when HN favourites like Slack show up on discussion. Ignoring the sheer number of high traffic websites and successful startups using PHP is just another way to deny it its due.
Most PHP apps are a breeze to install and use compared to just about any Ruby or Node app. Try installing Discourse to understand just how user hostile it has become. The respect for users and simplicity comes through in PHP. NPM and Ruby with their dependency hell expect a full dev environment even on user machines and nobody thinks this is ridiculous. There is no denying PHP warts but Node, Ruby and Python I think have their fair share of issues.
I really do like Python but for a web project that needs to scale and not get mired in other issues I would choose PHP every single time. For a library or SAAS app maybe, but for an installable app I would never expose users to the Ruby or Node ecosystem.
669 comments
[ 4.7 ms ] story [ 352 ms ] threadI've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major updates, and they've proven to be far less painful than I had expected based on the amount of PHP attacks I'd read online.
Maybe the snobbery toward PHP is a good thing? There are some really big PHP-based communities out there, Wordpress being probably the largest. And in these communities, there appears to be a large demand for paid consulting and plugins. Sure, there's a ton of competition on the low end, but it's an area where a really great developer could stand out from the crowd and do very well financially, especially for more complex consulting and dev work since so many good developers turn their noses up at PHP.
It's also not that hard to roll your own system and avoid many of the modules and frameworks in the space. The first API I wrote using node wasn't bad at all, and in the end actually simpler than the rewrite using express... And by the time you get to Hapi with a few addon modules for your needs, it'll get pretty big.
All of that said, I still prefer it to just about everything else I've worked in... though I haven't done anything on Go or rust, but would like to.
It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after running Webpack or Browserify bother me a lot more. Since we're using npm for pulling in front end dependencies, and CommonJS modules aren't statically analyzable, tools like the Closure Compiler and Rollup can't perform a lot of their advanced optimization and tree shaking. We'll get to a better place soon enough, though.
It's funny that a lot of this stuff is finally making it into the browsers and platform, when I've been using it for almost 2 years now. Looks like async is going in behind a flag in node 7.
The Wordpress codebase [plugin api included], though, is utter garbage.
[1] http://www.phpsadness.com/
[2] http://php.net/manual/en/language.expressions.php
[3] https://www.mail-archive.com/internals@lists.php.net/msg7196... (yes, i asked for this in 2014)
It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3])
You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. The most the PHP devs have done is deprecate methods and add features. That's great. I think that changing something, that has been there since the beginning, to a new behavior is stupid. Much much much worse then having ternary work backwards.
> The Wordpress codebase [plugin api included], though, is utter garbage.
Yes, yes it is. That's not the language's fault.
If you read the thread, no one could actually recall having ever seen code that relies on the current behavior. It has been discouraged in the docs for years. The stop-gap proposal was to have PHP7 deprecate it with a warning rather than silently changing the behavior. Then change the behavior in a future version (say php 8).
Disregarding any of that, this is an admitted language bug. It was not ever meant to work this way. Do you have a list of languages where ternary works backwards? PHP devs don't just work in PHP. Having one C-style language work this way and another C-style language (js) in another editor tab work the opposite way is a major PITA.
Also it's not a bug, more like a design oversight that doesn't cause any problem if you rtfm
unfortunately, that's PHP's mantra for unexpected/inconsistent behavior (of which there is a plethora)
It is also internally inconsistent in so many ways.
Half the array functions take arrays as the first arg, the other half the last.
explode and implode have different argument order requirements (one is strict, the other works either way).
Functions have a grab-bag of errors from returning null to false to 0 to strings to requiring error\_get\_last to even requiring an object specific error function (DateTime::getLastErrors).
Functions were named to make them have more randomly distributed hashes (http://news.php.net/php.internals/70691). Functions randomly do or don't have underscores, sane order, etc.
Some apis are in terms of objects (DateTime), some are not (getdate).
The whole thing is far less consistent than C. Some inconsistencies are from C. Most are PHP shit layered on top.
> You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
It's a C-like language. Every c-like language does it the other way. I will totally judge a language that makes a decision that makes programmer's lives terrible with no justification. In this case, it's different in a way that often leaves to bugs and surprises.
Do you support that? No one will ever be able to convince me that "<<" and ">>" make sense to be read and write.
Perhaps they do for you, and I accept your complaint about those operators as valid actually, but it's on a whole different level of badness than php, and again, we're talking about php. Just because "other languages suck" doesn't mean php doesn't, so that's not a valid argument against anything I said.
>they didn't cause significant problems
That's not a valid criticism of any feature. I'd say that the worst feature of any programming language yet has been pre and post -- and ++. Some of the nastiest bugs I've seen have come from there.
In both cases I avoid them. I only really use -- and ++ if I need to, just like ternary operators.
> Just because "other languages suck" doesn't mean php doesn't,
Ok what about other languages that are good? Python's ternary operator isn't the same as C-style languages but I still think of Python as being good.
Well, breaking backwards-compatibility comes at a cost. Avoiding another PHP 4/5 or Python 2/3 situation is the goal. It doesn't mean nothing gets changed: PHP 7 has a long list of backwards-compatibility breaks.
I've always heard this and never actually used Wordpress myself. Has anyone ever studied WHY its garbage? and how did it get to that state? is it getting better or are the latest additions and changes still garbage code?
WordPress is popular, php is accessible (you need notepad and an ftp client to start hacking) - combine the two, and you get a lot of "scratches my itch"-code.
It probably doesn't help that WordPress is an ancient code Base with a goal of running on the cheapest webhosts (who are slow to update to newer php releases).
So you get a lot of beginners that learn from messy old code, that generate more of the same.
It's a mess of global and file-wide variables, an unholy mix of poorly structured procedural code married with the odd "OO" abstraction.
There are good, even great php code bases - WordPress - and its plugins are not that.
To be fair, WordPress itself, and the core plugins are at least somewhat consistent, and after years of security holes follow a somewhat reasonable defensive coding practice. The terror lurks in popular third-party plugins, inspired/forked from older hacks. As is evidenced by a quick look at full-disclosure where seemingly every week someone's managed to make a plugin that's broken in some novel manner.
I've not been following closely lately, but for a plain php cms, one could do worse that cmsmadesimple. It's (was) pretty old-school simple php, but much simpler than something like Drupal.
I have to disagree with this article. PHP is a heavily flawed language. It's very easy to get started with PHP, but there are too many pitfalls that are too easy to fall into.
Most of the "Virtues of PHP" are available in other web languages if you use the right framework. And if you use those languages you'll benefit from the consistency and predictability that come from having a clear design philosophy from the start.
I don't think PHP is a bad language. It's possible to write good software in PHP, and it's possible to work around the flaws if you really know what you're doing. If your software is already written in PHP, it's probably not worth it to throw it out and rebuild it in something else. But I don't think it's worth the trouble if you have a choice, and I think writing new software in PHP should be avoided.
I'll admit I'm not familiar with HHVM and Hack. Maybe they alleviate PHP's problems.
P.S. Most of the points under "The Case Against PHP" are also issues with Javascript. But the difference is that if you're developing a web application, you have to use Javascript. You don't have to use PHP.
I would be hesitant to dismiss the significance of those - although I'm admittedly biased, having worked with Keith previously as well as on an erstwhile "competitor" to HHVM (talariatech.com).
My pretty heavy Django app takes about half a second for Gunicorn to boot 6 workers then it's off to the races. That might as well be zero startup time.
In terms of Hack as a language, it's very similar to the JavaScript->TypeScript relationship. It's still mostly PHP, but it doesn't quite get the new PHP features as quickly, and there is the chance that there could be incompatibilities in the future which could cause new PHP code to start looking and acting differently than Hack code.
I've seen Hack used in a multi-tens-of-MLOC codebase to gradually insert types. It made huge differences in the kinds of changes that were possible; you can, e.g., rename a class or method, or change the order of its arguments, with confidence comparable to that in a C++ codebase. Most developers hack-ified everything they could get their hands on, and did all new work in Hack, without any external encouragement.
Dealing with the parts that aren't Hackified, though, is horrific. Complex codebases with no types are just ridiculous.
The XHP plugin[0] (which you can include as a Composer dependency, but you have to be able to run Composer directly under the HHVM daemon and not PHP) allows XML to act like a first-class citizen. No more interpolating between HTML strings and having to escape all of your variables, you can now just do
and it just works (and auto-escapes.) You can even extend the XML root object to create your own tags[1]. Combined with Hack's native autoloader[2] (which allows whitelisting constants, functions, tags and types) Hack provides a lot of the features PHP developers will find standard in most templating frameworks, without the overhead of the actual framework.Another benefit (possibly) is that improperly formatted XML will break with an error, so it's guaranteed that if your document renders, it's correct.
[0]https://docs.hhvm.com/hack/XHP/introduction
[1]https://coderwall.com/p/3leegq/getting-stuck-in-with-xhp
[2]https://docs.hhvm.com/hack/other-features/autoloading
Hack allows generics, type hinting and aliasing[3-5]. These only apply when running the typechecker, however, when the code is running, everything decays to basic PHP primitives. I've been bitten a couple of times by this, because you might expect that you could use an aliased type as a typehint - you can't. You can define it as a return type, though.
Collections, like Maps and Vectors (oh, it has maps and vectors), can have immutable types[6].
[3]https://docs.hhvm.com/hack/generics/introduction
[4]https://docs.hhvm.com/hack/types/type-system
[5]https://docs.hhvm.com/hack/type-aliases/introduction
[6]https://docs.hhvm.com/hack/collections/introduction
Hack also supports "async" functions[7], which really aren't asynchronous. I found it a bit difficult to get this to work with curl and SQL the way I want to, but anything that helps remove the bottlenecks of database and network requests is welcome.
[7]https://docs.hhvm.com/hack/async/introduction
To me, Hack just feels like a better more sane PHP. All of the strictness is optional, but it still feels very good to have it there, and it has features users of more modern languages would certainly find welcome.
My pitfalls, so far, are mostly the result of my own ignorance of Vagrant and what the best practices for a workflow should be. I'm still debugging stuff in nano because I don't know any better.
Also, it seems OpenShift has a HHVM module, but you can't run Composer through HHVM on it, and as a result can't run a Hack project with XHP, because of Composer dependencies that require being run under HHVM. I asked StackOverflow what to do three months ago and just got utter silence an...
But currently I only care about a fast MVP.
PHP, Ruby and Python here are at a disadvantage. JSON is JavaScript's home turf.
$data['key']['value'][0] is a lot messier than data.key.value[0]. Ruby has ways of mitigating this, but you pay a performance penalty.
but you'll probably spend a few hours stuck with npm the first inevitable time a package doesn't work as expected
I'd say the opposite, I can get a node project up and running pretty quick these days... as to peer comments on APIs, I don't think it's hard at all to spin up a react + node api project once you've done it before... and starting with a boilerplate for react+redux and express is very straight forward as well.
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.
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.
Why are there no other "competitors" in this space? Why do most other languages go with the alternative route of using an event loop or daemonizing your "server" to serve up requests? I can understand why Node.js does it (otherwise the async nature would just be an annoyance for no gain), but why haven't there been any other server-side languages that not only work well like this, but actively target it?
It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
So what's the catch?
Any recommended places to start with?
Which should be near 0 if you can be bothered to enable OPcache in php.ini. Not only parsing/disk reading but also bytecode generation are bypassed.
In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality
The alternative is crazy sharding systems which are becoming more and more difficult as devices are less and less "static"
Not to mention, all the other languages out there memcached just as well.
apc_fetch/apc_store hardly seems painful.
About 2-3 orders of magnitude in performance. That’s the catch.
And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc.
And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framework.
> And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons
You make it sound as if the idea of caching was invented by PHP programmers to address language deficiencies. Nothing can be further from the truth. Everybody uses caches, because it's faster. If you don't use DB cache, there's no way in the universe you can make you app fast under any significant load.
> And hacking those things on top of PHP make your program even worse to reason about
You have very strange view of performance design if you think using caches is "hacking something on top" and has to be avoided.
> than just using a daemonized system with actor framework.
This looks like a complete non-sequitur - you could use actor framework and still use all the things described above, and do it in PHP, and thousands of people do exactly that. On not in PHP, if you'd like - this pattern is completely orthogonal to the language used.
Disclosure, I worked at GD in Website Builder when this was being developed, but haven't been there for over 2 years now.
I had a side project written in Elixir/Phoenix make it onto the front page of HN and it indeed was the case that the majority of requests were in hundreds of microseconds. The default log messages actually use "µs" which is kind of cute.
I wrote about it here[0] and extracted a random sample of my logs and you'll see that most of them were in the hundreds of microseconds.
[0] http://gabe.durazo.us/tech/ephemeral-p2p-project/
Yes, they do. Phoenix/Elixir is a nice way to get below the millisecond, and even with Java you can for most requests go below a few milliseconds.
And you can obviously handle far more requests at once, as you have all the code already loaded in RAM, and just need to jump into it, instead of reparsing it, or copying it back from a cache.
People go to a lot of trouble to optimize the front end system, but tie it all to the same database that bottlenecks well before the web server. There are certainly times where PHP or CGI aren't fast enough for the job, but I think people tend to unfairly blame them in situations where the underlying problem is more systematic.
that's not true. especially not in the DaaS space.
If you need to process thousands of requests per second per thread then don't use PHP, but that's a rare situation. I wouldn't build RTC in PHP. But web or enterprise applications, which are by far more common, don't really suffer that issue.
And pretty much everyone caches database results...
Compared to the other offerings, it's on par or faster (Python and Ruby really have a lot to be desired). You're talking about an actor framework, which is more performant at a cost of using that model and the myriad of issues with managing a more complicated system. The market favors simplicity and less sophisticated developers, in most projects.
A rewrite I worked on, from PHP to C++, had an improvement of 20 times better performance.
That's only one (1) order of magnitude.
Compare Symfony2 with Spring, for example (~500 vs. ~22'000 responses per second).
Or if you want to only use the raw language itself, php-raw with ulib-postgres (~90'000 vs. ~300'000 responses per second)
And with PHP, the larger the codebase, the slower it always responds, because even with opcaches loading it into RAM is a major bottleneck.
That’s exactly the issue at hand here.
And compare actual performance, for example JSON serialization, that’s not even fair anymore, symfony2 reaches around ~2'000 a second, gemini, the fastest fullstack framework, reaches ~970'000 a second.
Raw PHP reaches still ~170'000, but the fastest non-PHP raw language is still at ~2'200'000 compared to that.
These are actual performance issues that will cost you actual money. Even saving 20% of hardware and server costs can be the difference between your company being cost-effective and dead.
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 complexity down, but at scale, the applications I've worked with have to use a shared cache (like acpu) to avoid that rework and meet performance goals.
I know it can result in a lot of "extra work", but I really feel like most of the pain of that could be abstracted away by the runtime.
Nginx/apache setup a PHP process before the request comes in, so why couldn't you expose that point to your language and let the programming language do work before that point, even "snapshot"ing it to avoid re-doing that work for each request?
It just seems like there are better ways of solving this problem, because an event loop is such a "hammer" solution to the problem.
(On my systems, by default there is some reuse of the loaded module, so you can leak state between requests. However it should be possible to avoid reused processes).
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).
And even if you cache everything, you still have the code necessary to setup the runtime environment of you application which runs on every request and does the same thing.
But still, I do actually like that model and it does have many advantages for development. But it's really hard to work in PHP, the language, after using something better.
For the conversion to bytecode, that is what apc is for.
Which isn't what PHP does, fwiw.
PHP is no more stateless than any other language out there. Statelessness is a design choice, not something PHP gives you for free. If your app write things on the local disk or use the default PHP session handler then it is not scalable by default. In order to write code that scales you need to make it scalable, it's not something automatic and certainly not special to PHP.
It’s really interesting, last time I worked with PHP was a few years ago, then recently I wrote something in PHP 7, and it is a lot safer.
(But still no compile time type checking because there is no compile time).
You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.
Define "very". Because for me it's more like "a few hundred microseconds per request".
You are running it from RAM. PHP's OPcache, and HHVM, will both compile the code only once (well, HHVM will compile it multiple times due to JIT, but it only touches the disk once) and cache it.
A bit tangential, but I find myself disliking it too, for no good reason that I can think of.
Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.
The phrase has a high correlation with subjects that are themselves highly correlated with smug proponents; functional programming is one of the greater ones of these.
Personally I like the phrase. Then again I self-identify as a (non-smug) SmugLispWeenie[2] so of course I like it.
[1] https://www.infoq.com/presentations/Simple-Made-Easy [2] http://web.archive.org/web/20160709054130/http://c2.com/cgi/...
Yes, you do. You'd be surprised how easily memory balloons out of control unless you regularly run a GC. Log minor collections sometime in Java or JS engines if you don't believe me…
Even worse, if you don't run GC regularly, you will suffer terrible locality as execution continually grows the heap (not to mention the overhead of continually requesting free pages from the OS).
Not that I feel cgi is the most efficient way to handle requests... but not needing the complexity of GC could be one advantage of that approach...
I speak from experience: there have been many attempts to mandatorily delay collection until the end of the event loop in browsers, to achieve greater responsiveness. It has always failed. You can add heuristics to try to preferentially collect at the end of the event loop, but you really need to be able to GC anytime.
However, if you're handling requests well within a given memory threshold, it isn't always something you should worry about until it becomes a problem. In which case, you'll probably want to look at something like go, rust, erlang or others to handle improvements, or break off heavy parts into sub/micro-services.
It's not an insane idea - CGI worked exactly like this, as do most command-line shells. And the overhead is often less than most people expect, since most pages are COWed on fork() and the files it touches will likely be in the filesystem cache. Still, I think people found that the overhead from process creation (and in particular, keeping all those processes around & task-switching them while they make DB/network/filesystem calls) was greater than that from GC, and so most frameworks - PHP included, these days! - use a more lightweight mechanism.
There's actually work being done to build PHP frameworks that get around this with ReactPHP, ZeroMQ, Photon, etc. Essentially this is what HHVM does as well, by at least keeping your compiled bytecodes in memory (similar to APC/eAccelarator/ZendOptimizer, etc).
See: http://reactphp.org http://www.photon-project.com https://gnugat.github.io/2016/04/13/super-speed-sf-react-php...
Even the idea of an alternative runtime for PHP (ala HHVM) is nothing new: http://quercus.caucho.com
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 connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.
Burning cpu and maybe i/o looking for code all over the place is going to make it really hard to make it fast later.
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.
Every wasted millisecond on the server side matters. It impacts scalability, customer experience (and revenue) etc. You should take every easy win you can get there.
Not doing full includes is just ridiculously lazy. It doesn't take that long to write them out, and your IDE can help you out there. I bet you spend more time on social media during office hours than you'd ever save from not having to type out those import statements.
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.
Or that, you know. There is an extremely powerful language feature and the developers are taking advantage of it.
So? If it takes < 1ms, what's the harm? And opcode cache comes out of the box and most PHP DB drivers can use connection pooling.
We serve most of our requests in < 10ms, and we're not even on PHP7 yet.
All the magic you ever need can be dynamically created in __get, __set and __call. It works, it works well, and it makes not only reasoning, but also deployment an order of magnitude simpler.
>Code paths, auto-loaders, database connections, config files, etc.
Use a single code path, a single autoloader and a single database connection. Cache the opcodes of stuff you load. Write config files and templates in pure PHP, so they're cached as well. Done.
I've never, ever had problems with bringing PHP page generation time below .1 seconds. Usually it took something like .03 seconds on crappy hardware. And that was without extensive caching of DB results or anything else that's particularly clever.
Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means.
There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.
Here is an example in C: https://www.cs.tut.fi/~jkorpela/forms/cgic.html
Php was born out of trying to reduce a lot of that cruft and blending code and html output easily. And that's what initially made it a winner.
Actually I have never seen that this was a problem in practice with the application server model. I therefore don't think this is a relevant argument.
Other languages, whether directly or indirectly manage cleanup via GC or recycle processes, like UWSGI for Python.
I also don't find any particular benefits over other languages with "reasoning about". As a PHP application grows and a team restructures it into something more mature it ends up looking the same minus the event loop (which just lives somewhere else).
> It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
Firing up a new process (or even a new thread) for each request is very expensive--much more so than a generational GC. Async IO also mitigates this (why have 10K parked threads consuming memory all your memory if all of them are stalled, waiting for database)? Services that spawn a thread for each request run into the C10K problem--they can only serve 10K simultaneous clients. Regardless of your concurrency model, you can't ignore errors--you still need to dispatch the right status codes and error information (not to mention logging, etc).
You should check out Go. You write concurrent code and the runtime effectively manages a thread pool under the covers so you get all of the performance benefits of async programming with the developer-friendliness of synchronous programming. In the case of a web app, you just need to write your request handlers--the web server manages the request concurrency for you, and the language's runtime manages the parallelism.
True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
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 the OP's statement.
> Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
Again, these are all solutions to problems PHP invented for itself. Other languages don't require special caching mechanisms; they get by on normal scoping rules and shared memory.
With PHP you can see your program as a pure function whose result depends only on arguments. You don't have to care about memory leaks like you don't have to do memory management when you have a GC. And if you want more performance and less convenience you can always opt into running your own web server.
> Don't use global variables
If you have an object that is persisted between requests you already have some state that is saved.
With Django processing model any array can become the source of a memory leak. I have heard that Ruby and NodeJS developers often have to restart their applications every several hours because they even have no tools to find the source of a leak. The problem that does not exist in PHP by design.
But also, you don't typically use lambda to serve pages or a full application, more commonly it's used for specific processing tasks, individual endpoints, and generally code that can run standalone.
This was never actually an asset. Startup times were huge, lack of shared state meant extra requests to database servers (and to memcache instances to avoid database round trips) to get the same data per-request. Each request got longer and a given page or api call might issue many duplicate requests in a short period of time.
Plus since PHP doesn't have viable threading or async (definitely didn't at the time) each memcache or sql request had to be synchronous, resulting in even more wasted time. At the very least memcache had good support for batch operations so we could manually batch our queries.
Overall though this is not an asset. It's only the 'best' part of PHP if you don't want to think about writing good software that manages shared state.
To be fair, many applications don't actually benefit from being good code, so PHP is probably a good fit for those.
You can do the exact same thing with any language that supports CGI. You can compile a Go binary, put it on an Apache server and you'll get the "shared nothing lifecycle" just like PHP.
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, ...).
The catch are couple.
First Concurrency is _hard_ and relying on the OS scheduler would have been really har don ressource until recently, which is why nearly noone did it.
That used ot be a wart of php, only hidden by Moore's Law and recent work on OS schedulers.
But yeah. Erlang do this since the 80s
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.
So this process-per-request thing is not exclusively a Php thing.
I completely understand the "trendy" part. Sadly even language/frameworks need marketing, and doing things in a "wasteful" and "slower" way but simpler is gonna be a tough sell even if it might be the best move.
I just feel that there is a space for a "better PHP". One that uses a better base language, but still keeps the benefits from the language like the simplicity of the "think edit reload" cycle, the shared nothing architecture that makes programs easier to write and simpler to test, and the horizontal scaling.
[1] https://git.zx2c4.com/cgit/about/
P.S. An important thing that contributes to the success of PHP is the amount of hosting services that support it.
While i do not think PHP is a perfect programing language. There is one think i LOVE about PHP, it is that the PHP "community's" default way of documenting code behavior is to make a small example.
When i read most other languages documentation i read it. Then i need to make a small test to verify that i understood it.
All those tests takes a long time to make and i have to make them over and over again, every time i forget the way a function behaves.
It's harder still when you're trying to en/decrypt data from multiple programming languages... Java is particularly painful as well, since a lot of the things that are "standard" are abstracted behind class structures with naming that differs from the standards.
That said, PHP is really good at what it does - providing a framework and environment for serving web requests efficiently and easily. I find developing in it very fluid once you know how to avoid the warts. A lot of the flak that PHP receives as a language revolves around the fact that it doesn't actively discourage developers from doing bad things, and sometimes the language itself does some crazy stuff (as shown in the article with the divide-by-zero behavior). I think this is a huge shortcoming of the language, especially as code bases and teams grow and your organization needs to depend on the language more and more for safety. That said, I still don't hate working with it. Sometimes I rather enjoy how quickly I can develop in PHP, and how reliable it can be if you know how to operate it.
I think in all, it was a bit of a slog to get to the point where I am with PHP today - to the point where I understand its strengths and flaws, but ultimately I think it does have a place in modern webapp development. I think Hack and HHVM are excellent spiritual successors to what PHP tried to (is trying to?) accomplish, and that they do a great job of hiding or eliminating some of the warts of their parent language.
Kudos to the Slack team for being pragmatic about their approach to the technology, and hey again to all of my former colleagues working there!
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 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. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.
I do care about my code though. I think you can write niceish code, even with a shitty language.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
And Dijkstra was kidding. As is Rasmus when he says he'll restart Apache every 10 requests. Hyperbole. Learn languages instead of a language and it'll click. It has to.
I especially liked this:
> Learn languages instead of a language and it'll click.
I started at 5 or 6 with Basic, then progressed to Object Pascal early on, then C, C++, PHP, Java and finally Javascript and C# - I believe this wide experience has served me well over my almost 30 years' of programming (Christmas I'm getting old!).
I think there is a time and a place for 'just get shit done, fast', as well as spending time building 'elegant' code. But, if anything, the compromise between these 2 is possibly the thing I struggle with most.
Scores of developers that were raised on BASIC assert that knowledge of BASIC gives you brain damage. Presumably, they do not consider themselves to be brain-damaged. Similar things happen with, say, products of public schooling.
Which isn't to advance an, "I was spanked and I turned out fine..." kind of argument. Even if that's true, we can establish higher floors than "fine." It's the self-defeating hysterics around the presentation that make it come off the wrong way to me.
That said, all environments will be one of three:
1 Have warts. 2 Not be used. 3 Be in denial and claim to be perfect.
The GP had a point, perfection is the enemy of good. Something delivered is better than nothing.
Also, e.g. fastcgi was around the same time frame.
(In order not to end up in a flame war regarding the first point I checked wikipedia -- see second paragraph of the intro here. :-) https://en.wikipedia.org/wiki/Mod_perl )
But business success is largely orthogonal to language choice. I.e. when you buy a paid Github plan do you check what language they write the site in?
Of course a strongly typed languages should tend to have less bugs and that will save money. But saving money is only useful for those with revenue to being with.
I'm overwhelmed by how rich of a statement that is.
Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter.
Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately.
The world of difference between balancing trade-offs in technical debt, tradeoffs in long-term/short-term goals, and deliberatively sabotaging the company by leaving technical debt for other people to clean.
You are a liability to the company and its culture. And you want people like you and your language to be taken seriously? that's why nobody wants to work with people like you.
Those rules may not be the right ones and they may not be enforced well enough, but there's at least some nominal level of assumed professional responsibility.
No, it's acceptable precisely because you aren't an engineer.
We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legally responsible -- independent of our employers -- for defects in our product that arise from incompetence or otherwise failing to follow best practices.
So, you're wrong and your parent is right. He's not independently responsible for his work, and he has no formal ethical obligations prior to his employment contract.
And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY.
Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted.
You don't, because you have you keep this to yourself because you know it is wrong and not in the best interest of your employer... Who is wrong now?
Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT:
> because you know it is wrong and not in the best interest of your employer
Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employer. There is no prior obligation (aside from not literally breaking the law).
And within the structure of the company, the engineer has no legal or professional obligation prior to manangement. So, if parent's boss tells him "get this shit out the door ASAP maintainability and quality be damned", and then parent does exactly that, I think he'd probably be OK from an employment perspective. In fact, insisting on some modicum of security or readability might even get him in trouble!
Contrast that with the situation of a PE, who would be much more likely to answer "no" on the basis of professional ethical obligations which are prior to his obligations to his employer/immediate manager. And, when answering no, would be much more likely to have the leverage and respect necessary to survive an encounter with middle management.
That's the meaning of professionalism. That's the meaning of living in a society. If you need to say no, then do it. Your job is not to say yes to everything.
What if everyone ripped off everyone all the time? It would be a world of shit.
Ripping off the customer is not in the best interest of the employer, and is being hostile towards society. Think about contributing to society not taking what you can.
Adding customer value is different to adding apparent value with no real substance.
When is perfectly fine, and I agree with you. As I've said multiple times.
But realize that, in the US, programmers have no such legal obligation. They also have no formally codified and enforced professional ethical obligation.
Any such obligation is purely within the realm of personal ethics. Particularly obligations to the customer which go beyond or contradict with obligations to management (the latter are at least captured in the form of a contract).
So your moral stance, while admirable, isn't representative of actual enforced social norms among programmers.
There are 3 phases:
Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it.
Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it.
Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.
If you are rational you will understand that technical debt is a cost, and unless you are sabotaging the project you won't add cost without a good reason.
Prototyping and iteration is fine. Throwing away prototypes might be fine. But selling a functional prototype as a finished product IS NOT FINE. It's morally wrong. And unless you want to be lynched like the Theranos people you better not get caught doing this.
Whatever I would say about PHP - how good or bad is - I am almost forced to use it - In central/eastern europe almost any company uses it to develop web-backend... but I really would love to jump to Node/Go/Golang-based development team (maybe even remotely).
[1]: http://laravel-recipes.com/recipes/60/optimizing-the-framewo...
- You sit in a dining table with 50 different utensils. White wine glass, red wine glass, water cup, salad fork, dinner fork, dinner knife, teaspoon, soup spoon, bread plate with knife...
- When the food is served, you take the food, drop it on the floor, eat it with your face (not even using your hands).
"get shit done"... use spoon as a knife and knife as a fork, or try to sniff your food through your nose instead of eating it.
The one thing you want to avoid are communities that argue about "the best" way to do things. Even then, you can use the fruits of their labors, as long as they're willing to package it up in something that gets out of your way and lets you get work done. You just need to take the language but not the community.
I would think I like Lua & C to just write it quick because they are so limited; I remember their syntax, core functions and core libs, so I can, without internet or documentation, write things in it immediately.
I'm not sure why those others give me that feeling; probably because it's easy to just start instead of having to set up dev environments etc. Most is already on your computer and they are forgiving (a bit too much I agree) about sloppy coding.
It would be interesting to try to dive into details of why the brain finds some languages more conductive to 'just write it quick' and try to mix that with languages which do not have that feeling at all.
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.
If PHP gets you to first base (MVP) in 10% of the time than NiceLangX then you get 10 X more chances to throw shit at the wall and see what sticks.
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 tremendous losers who picked php and got nothing for it.
If you aren't following the PHP Framework Interop Group (http://www.php-fig.org) then you really should. I'd hazard that most of the warts in PHP can now be avoided pretty much altogether, and those that can't quite possibly can be worked around through configuration.
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)
Not sure whether this is your real opinion or you are just making fun of people who say that.
http://php.net/manual/en/function.usort.php
It has everything I need to know about the function clearly laid out. The behaviour of sort when elements are the same. A list at the side of related functions that I may want to look at instead.
I also like documentation that includes user contributions as these often add useful caveats and usage examples that don't fit well in the general documentation.
1. They have exactly one set of documentation pages for all the php versions.
2. Another thing is that documentation can be quite wrong for even the fundamental stuff. I have seen a core developer blast out in reddit that "The documentation is wrong!", when the other party pointed them towards a piece of documentation.
3. Incomplete or shallow description. Go check out the documentation page for Exceptions in php and try to find information regarding the behavior of return statements in a 'finally' block. Now go an see the respective page in Python documentation and see how in depth the documentation is.
And having code samples is not exclusive to Php's documentation..
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?
Depending on the type of project, I would choose PHP over at least some of the languages you mentioned; I guess "great" is not a significant quality when making architectural choices.
Just to be clear: I was thinking about factors like performance, choice of servers, how easy it is to hire good developers, library ecosystem etc.
EDIT: obviously the "awesome aspects" mentioned by GP are a similarly unsubstantiated claim ;-)
Java: keyboard wear
Scala: not enough programmers
Python: not bad
Ruby: too slow
Haskell: math grad required
https://github.com/Unity-Technologies
It's easier to reroll in another language and retrain or recruit? No. So you probably mean for a new project. So now you've more maintenance and learning curve unless you just happen to have enough skilled in $NEWTHING. Not really easier.
PHP is an inconsistent mess, everyone knows that, but it's cheap, widely understood, and it's perfectly possible to write decent maintainable code. There's ways to mitigate the chaos.
Would'nt the good ones logically move to a different language ( JS/Ruby etc ) where they could bill more?
Haskell doesn't support OOP if I remember correctly. And it is complicated too.
That said, it is true that Rust has tricky parts. The domain is inherently complex.
Python is a great beginner-friendly language, but that doesn't mean it's well-designed in other respects or appropriate for large software projects.
It wouldn't really make sense for Haskell to "support OOP" in the usual since. The OOP paradigm is mostly useful when you have mutability. Another way of looking at it is that you don't need OOP in Haskell because it exposes better ways of interacting with data that aren't present in most OO languages, like ADTs and Typeclasses.
That will never happen, you can't write code like this in Rust:
Even when the previous code is an abomination, it is absolutely easy to write, this is why languages like PHP are a success, the barrier to entry is definitely low.The issue comes when the whole industry buys the idea that PHP equals bad code, fail to appreciate the progress the language has had in the last years, fail to appreciate the effort behind projects like Symfony, and become completely foreign to the current best practices.
[1] https://leanpub.com/cleanphp
Your argument is a bit spurious; you're right insofar as you can't write PHP in a language that's not PHP.
That is my point. You require effort in an order of magnitude greater than with PHP in order to achieve the same result, which in the case of a beginner, is the difference between continuing their journey in programming or abandoning the ship.
You are failing to see the big picture and are taking for granted the plethora of initial setup you have to do to begin working with a language like Rust (ex. generating bindings for a database driver written in C if it doesn't exist in cargo), you were just nitpicking in the syntax of the previous example (which BTW, I took care to clarify it was an example of bad code to avoid people not familiar with PHP from getting the wrong idea).
It was my fault to say "you can't" in my previous message (see Atwood's Law), I really meant "it requires too much effort".
An order of magnitude? Really? I don't think so.
Rust has a library (probably among others) called Horrorshow[1], that exports macros to do html templating.
You claim that it is easy in Php to do html templating. But you miss the fact that it provide zero sanity/security checks while doing so. You need to sanitize every one of those variables before inserting into the html stream.
You see, Php just trades off every bit of sanity and security for a little bit of ease of use. It is that simple.
[1] https://stebalien.github.io/horrorshow-rs/horrorshow/
Remember that a beginner programmer doesn't always have a background in Computer Science, maybe it's a child, maybe a graphic designer, maybe an elder person or a housewife. Are you really expecting from a person foreign to CS to stop tinkering just because they can't write secure and performant code in your favorite language?
Again, stop taking for granted the initial process setup and all the gotchas that you already know, stop nitpicking in the example of templating and see the big picture: A beginner programmer being able to get instant feedback with little effort in their browser of choice. No initial project or repository set-up, no install for external libraries, no huge development environments (like Xcode or Visual Studio), no build process or compilation, no command line, just an app like WAMP (on Windows) or MAMP (which people accustomed to homebrew avoid) and a browser pointing to http://localhost.
PHP is not a perfect language, but it's neither the abomination people like you describe, too many people judge PHP by its former state of the art and are unaware of the progress it has had in the last years, many of the most popular issues are already gone or at least are too difficult to trigger, to name an example, PHP stopped having register_globals since version 5.4, and PHP 7 added strict type hinting, which throws an error instead of doing unexpected type coercions.
That doesn't mean that PHP is a better choice than properly-designed alternatives, just that it's less worse than before. I agree with the sentiment of using a well-designed language like Rust, but only when a project really requires that degree of security and performance (ex. writing a browser like Servo).
A bakery website written by the kid of a patissier doesn't require that degree of security and performance... Or are you really going to demand that child to use your favorite language just because you despise PHP?
>A bakery website written by the kid of a patissier doesn't require that degree of security and performance...
I don't think so. Everything that is put online need to be secure. One day it is just a bakery website. Next day it is accepting credit card numbers. And the kid who did this can get employed as a php developer based on this experience, and might build stuff like that for years, with out a clue in the world that they are using a toy language.
You can, using some web framework crates, but PHP is many many years ahead from Rust in making web apps. And I'm not sure if its the right language for the web. You'd probably be fighting with the borrow checker and type system most of the time while the php dev is busy cranking out new features for his/her web app. There is also the problem of compiling huge websites.
Then a month later that guy that pulled those couple things into a web page is going to go "Hey, maybe I could make a thing to manage those.". And he's going to learn more.
Then a month later he's going to have another bright idea.
And suddenly someone with no programming background is a PHP programmer, and he's putting together ugly but functional websites and everyone is looking and going "MAN PHP IS AN AWFUL LANGUAGE".
There's a huge contingent of people that are maybe moderately technically savvy but are not programmers and are not necessarily interested in deliberately becoming one. These are the people that end up setting up entire businesses in some Lovecraftian Excel sheet. PHP is a language with a learning curve (even for a non-programmer), not a learning cliff, and it makes it really easy for these people.
Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], 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 tremendous losers who picked [insert language] and got nothing for it.
"and miss all of the tremendous losers who picked php and got nothing for it"
certainly applies equally across all languages in my opinion.
The grandparent of your comment suggested that, yes, these projects were lifted up by PHP's un-fancy nature giving them focus. The parent of your comment was suggesting that, basically, the companies that have succeeded using PHP aren't any more numerous than we would expect to have come out of the massive PHP userbase even if PHP doesn't offer any advantages at all.
The observation that "PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail" seems to be responding to a nonexistent conversation in which people were positing that startups based on other languages don't fail. Nobody here is saying that other languages magically make your business succeed.
I mean, essentially all you're saying is "startup success is largely uncorrelated with the programming language used to implement those startups' products". That seems like not at all an unreasonable position.
(It's not, by the way, equivalent to the statement "choice of language doesn't matter".)
Finally, if you went travelling to any other country (except Austria or Switzerland maybe), the rest of the world had Facebook. So to keep in touch, you also needed Facebook, which had a better user experience. Why bother with both?
You can go to any Ruby meetup and you will see it's different than PHP meetup which both are quite different from Functional Programming meetups.
Thus I would say that it's not about the technology but about people whom you attract (i.e. culture).
I skip luck & timing, these are mostly random and one has very little power to influence them.
Mind, I agree with you, but given the Holy Documents Handed Down By Our Lord and Savior, Paul Graham, HN... might not be the safest place to say it.
Edit: so, I'm clearly getting a lot of downs on this... maybe sarcasm in reference to PG was going a bit too far. Oh well. I'm not deleting or editing any of it, because that's sort of dishonest.
A truly good idea will generally find a way to succeed despite the technology it is built on, though. Look at Facebook, Slack, and countless others running PHP or Minecraft running Java and its apparently horrible code base (I've never seen it, so that is secondhand)
- We aren't very good at judging the relative virtues of tech
- Most tech is good enough to express most concepts even if not equally well. If its possible to express it even if it takes 3 times as much work and is only 70% as good you wont notice from the outside how much the tech mattered.
- Good ideas are worth enough money to throw enough time/money at them to be moderately successful
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 favourite website or app, but lamented that it was written in Php or JavaScript or Go or Java. It's only us (the HN'ers) who fret about this.
Don't believe me? Imagine the look on everyone's faces at the tech publishing houses around 2009 when books about Objective-C sold a few hundred copies a year to doing tens of thousands per month when the iPhone rocked the world. This happened without a proper language hot stove on Hacker News, no?
People care about outcomes. People care about products. People care about being dazzled. People care about showing their friends this incredible thing they saw on the web/this new app.
You could say the same thing about cars people don't care about what sort of engine is under the hood or how it works they just want to go places! It doesn't then follow that all cars are the same and you are just as well getting any one of the millions of cars or even any one of the models out there.
Indeed it isn't. "Maintenance" has opposite meanings in those worlds: maintaining a car means keeping its original functionalities still available; maintaining an application means letting it evolve.
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.
That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.
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 the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok.
php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box.
memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails.
because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit.
cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind.
but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some.
but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure.
what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.
Again PHP (the language) vs. Rails (the framework).
What framework was that `big php app` using?
PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.
I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core.
So comparing PHP to Rails is a bit apples and oranges.
If you are making a technical comparison then it needs to be at the correct layer of abstraction. If we were to compare performance of Laraval and Rails that would be a fair comparison.
If we are comparing on performance then PHP should be probably be compared to Ruby+Rack since that is sort of the lowest common denominator.
I'm not dogging on PHP here either. Even comparing at the correct level; PHP is still faster, but lets make sure we are making the right comparisons.
i was clarifying the compassion.
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.
Dealing with limited resources such as MySQL and Redis is a problem you still have to fix when you move away from PHP though.
As for the Facebook runtime, for us it was a case of drop in HHVM, fix a handful of issues and get a 4x or 6x speed increase for free. You only need to change the way you write if you move to Hack, but I think I agree with you that's probably getting to the limit of the effort reward tradeoff before you rewrite in a different language.
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 "only" 50ms.
This only proves Drupal is slow.
http://php.net/manual/en/intro.opcache.php
https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
You need a lot more than a "Sieve of Eratosthenes" code snippet to back that up :-)
Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.
But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though.
It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)
It's at this point that shit falls apart and the manager starts to care about these technical choices and all of the time and money that will be needed to be spent to rewrite.
Call it maintenance costs if you want but those costs are directly affected by the technology decisions you make.
https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
"Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" ;-)
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.
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)
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
You seem unnecessarily argumentative about this, almost like you're angry and I really don't understand why. There really isn't that much difference between languages like Ruby and PHP to warrant this and almost anything can be expressed in almost the same way, the only real differences are syntactic sugars and the "flexible" type system.
Modern PHP frameworks and tools are good, perhaps even excellent. Composer and the PSR-# efforts have spurred a renaissance in code quality and interoperability, and PHP7 brings some truly impressive speed improvements. For those of us who aren't stuck supporting legacy code, that is. One of these days I will be working with a language whose syntax I enjoy, but until then the language that puts the "sin" in "syntax" will (for better or worse) keep getting the job done.
plus like you say PHP might be faster to get started with but becomes much slower on larger projects due to inconsistent error handling and language design.
Don't trust everything you read on the internet, run the benchmark yourself and see if that result is actually reproducible. (Depends on the heap size.) There is also a "non-std lib" java test case, which doesn't generate as much garbage and, of course, performs much better.
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?
But change to and run with I don't think you're comparing what you say you're comparing."http://www.famzah.net/download/langs-performance/java-discus...
Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.
I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"
This. In my previous job, I was literally told by my boss, that they'd consider switching from PHP to something like Ruby or whatever, but PHP programmers are cheaper so that's why they stick with it.
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 anything else.
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 technical feature.
______________________
1. Granted, one of the major design goals of Rust is replacing C, but you get the point.
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.
The gist was that PHP was designed for web use, so it's almost always facing the internet. C on the other hand is very much multi-purpose. Both can be made secure, but maybe it's less effort using something that helps you with security (Hack, Rust, etc.).
(BTW, your comment contains a huge fallacy: Just because a majority of packets touches something written in C, that doesn't mean a majority of C code written is exposed to the internet. This is arguably the entire point of e.g. iptables.)
So what? Who else could care for something apart from those professionals using it?
Maintenance is the biggest part of software development. A wrong technological choice can turn my nice job into my worst nightmare. Why shouldn't I care?
I think the intention is: While they are important to us, languages are frequently distorted to the point that we believe that company success as a whole is dependent on it. Companies like Facebook flatly contradict that. I agree with you in spirit: Facebook would obviously prefer not PHP. But if the choice is: Learn something other than PHP or use language I know to test some idea, I think the latter is an obvious choice.
You call it poor management in retrospect, but it's succeeding in spite of the tools when you're still doing ok. There's a lot of companies that exist in between failure and "Facebook" who don't have hockey stick growth curves who also can't afford needlessly higher technology costs, whether that's in infrastructure or staffing or opportunity costs in getting features to market. If PHP does't incur a higher cost personally, go for it, but it might be a strategic disadvantage later if you don't hit it big.
That's not a reason to use horses instead.
It's sadly quite common for non-engineers to make technical decisions such as what language, tool, or hardware will be used, and everyone else just has to live with it.
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.
To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.
PHP is still widely used, but there's a myriad of other contenders: Java, ASP.NET, Python (Django,Flask,etc), Ruby (Rails), Perl, Javascript (Node,etc) and others.
I'm not sure about PHP being the "king". PHP might be the most widely deployed thanks to either FB or the huge number of legacy bulletin boards and wordpress sites, but in terms of new deployments does it still dominate? Probably not. (For novices, a static site generator is definitely the way to go, until you run into it's limitations.)
I also made a start with PHP. Still, PHP has been slow to learn from other languages and frustratingly refused to change established behaviour. I found PHP to be far more "dangerous" for the amateur programmer than other languages. Finally, I switched and never looked back.
From teaching beginners, I actually think Python + Flask has a similarly shallow learning curve, but more room to grow and to "do it correctly" (e.g. the templating is much cleaner and the routing much more powerful). I recommend it.
Hopefully you get the point.
(I do agree that PHP without something like Symfony, Yii, ... Laravel, even Cake could be very dangerous, or at least, counter-productive for amateurs trying to learn though)
Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?
Or a simple guestbook or hit counter.
Where the lines may blur is JS front end talking to a BaaS... This may make it possible to glue up impressive sites using just HTML and JS with no custom backend requirement.
For many use cases where it is relevant, static site generators like Jekyll can actually imitate "dynamic content" from the perspective of the people running the site.
The most important use cases for dynamic content these days are web applications, as distinct from "websites". On the other hand, web applications are also the most important use cases for better development ecosystems than are easily attained with PHP.
In my experience and observations, the cases where PHP's easy provision of dynamic content capabilities make the most difference are websites (as distinct from "web applications") on shared hosting platforms or bootstrapped by existing content management systems like WordPress and Drupal (which are, in turn, often easily used because of either hosting platforms specifically for those CMSes or shared hosting providers).
NOTE: I'm not sneering at "websites", as distinct from "web applications", as many people who draw such distinctions do. I'm just pointing out there is a distinction to be made between two different types of projects involving deployment of a codebase to a web server. Speaking only of the technology's proximate purpose: in one of these, the primary purpose of it is to make content accessible to the public; in the other, the primary purpose is to make functionality accessible to a userbase.
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 one that is a direct clone of Rails.
Plenty of A rounds have been spent trying to make a sand castle taller.
This is not unique to php - I'm sure you can do it right - but it's more common to 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 beautiful object tree to describe everything, just do the minimum amount of work to take the garbage input and generate the garbage output, and be done. Don't worry too much about your code being beautiful, because it lives in a dump.
This may sound negative, but working in a dump means you don't have to worry about appearances while you do what you came to do. You can always take a shower on the way out :)
I'm not going to make any customers happy working on a product if I hate the codebase and the language I'm working in so much I just DGAF.
It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).
Bad code isn't Technical Debt, it's an unhedged Call Option http://higherorderlogic.com/2010/07/bad-code-isnt-technical-...
I do my part today by acknowledging all of my code is bad, therefore I don't invest a lot of time or ego in it. I try to make it in reasonably sized pieces so it's easier to rip out later (this may make it slightly less bad). If someone comes and tells me my code is terrible, I say yes it is, you might want to consider these things when you replace it.
EDIT: my opinions on this would change if I were shipping code to run on other people's machines: it's generally easy and quick to fix my code on machines I run, but updating code on other people may never update, you need to try harder to get it right the first time.
If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.
For anything with a server-side component, PHP might be fast if you know a lot about how to get PHP up and running properly.
Node, as a counter-example, runs on Windows and POSIX systems indifferently, and with very little effort can be a self-hosted web server for development that can be deployed to production almost effortlessly.
If you have a favorite hosting provider which better supports some tools than others, certain things will be faster, but that's because of preference and familiarity rather than any factual differences.
Getting WAMP or whatever configured and installed, or loading the PHP module into Apache or Nginx and getting that working is a giant pain in the ass compared to either of those two things, even if you've done it a dozen times before.
As of PHP7... it actually is quicker than other languages in it's domain.
They've made some impressive gains in PHP7 that others should take note of. Ruby's particularly out of shape here compared to the competition, though Python isn't exactly a speed demon either.
See an older counter-point with the much slower PHP 5.5:
https://philsturgeon.uk/php/2013/11/12/benchmarking-codswall...
If you consider Wordpress a success then yes PHP is successful. The thing is, a CMS isn't an interesting project to work on.
Theres a lot of raise ArgumentError.new unless foo.kind_of? Bar
Going on in my code these days.
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 JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.
As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.
JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say:
This code is totally valid. bill's prototype chain looks like this: Welcome to prototypical inheritance.A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`.
Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them.
Consider your example, translated:
Brush up on your Python skills before talking rubbish.
In any case you're not actually providing any links or facts, so unless I dig through long articles on metaclasses in python, I can't verify anything you say. Please prove your point, or at least provide I link so I can verify.
It should be interesting to see if I can actually abuse Python's meta-programming enough to make it work :-)
Right; this is actually why I like Python's way a bit better: it makes a more formal distinction between the two. In Python, Charlie is also an object, and you can change all its properties and everything, just like most¹ other objects.
Most of what you try to use to distinguish JS from Python applies just as well to Python. No, it isn't exactly the same, and I think the semantically equivalent code in Python will often contain more information than the JS. E.g., in my conversion of your JS, the class is an instance of `type`, whereas — as you correctly note — it's "just" an object in JS. It's not really though; in most JS that devs will write, the object is a type, but that distinction isn't explicit in the code. It's implicit in the dev's intentions, expressed only in the general sense that the code is being used.
e.g., if I saw, in JS,
while it is true, technically, that `Person` is a function and `Person.prototype` is an object, the semantic meaning being expressed in this manner by the author of this setup is that `Person` is a type, and that charlie is an instance of that type. It's just explicit in Python. (To some degree, JS is aware of this fact too; `charlie instanceof Person` is `true`, after all.)In a single-inheritance class in Python, during attribute lookup, Python will attempt to look the attribute up on the object's __dict__; if it doesn't exist, then it looks up the parent type (by looking at __class__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".²
In JS, during attribute lookup, JS will attempt to look the attribute up on the object's internal list of attribute (I don't believe this is exposed like __dict__ in Python); if it doesn't exist, then it looks up the parent type (by looking at __proto__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".
What material difference exists here?
¹objects in Python can forbid attributes from being set, or limit the available attributes. I'm not sure to what extend JS lets you do that. e.g., `object` in Python is very restrictive about allowing additional objects.
²I'm explicitly ignoring multiple inheritance here, so I'm vastly simplifying. Python will actually use the MRO for this procedure, but in the case of simple inheritance, that's equivalent to following __class__. I'm also ignoring __slots__ for simplicity.
Yes, but it's (roughly speaking) an instance of a "Class" class. In the "Person" example, the prototype of a "Person" object is another "Person" object (until the chain reaches an "Object", at least).
When we have distinct functions, classes and objects we can easily understand how they are supposed to be used: you can call a function, create an instance of a class, call a method of an object. With Javascript you cannot easily see whether you have a plain function or a constructor and how you should use it. And interpreter won't tell you anything if you forget to put a `new` keyword.
(And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Your code can easily cause a bug. Imagine Person's constructor looks like this:
Do you see the problem here? To fix the problem you have to rewrite the code using Object.create() and call parent constructor with Person.call(...).I have written applications in Javascript and I think that Java-style classes are the best for readable and maintainable code. All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Your code example proves that because adding a single field to a Person's constructor requires you to find and modify all of the objects inherited from it and this task is not easy too.
Your critique of Javascript is basically "it's not Java". I could make a similar critique of Java not being StandardML, but it would be about as meaningless:
When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used: you can open a structure, create an implementation of a signature, apply a functor to a structure.
> (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Personally, I prefer "var Person = function Person(...) {...}" since it makes the code more symmetric (the second "Person" makes stack traces more informative). The "function Person(...) {...}" style makes an artificial dinstinction between functions and everything else.
> All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications.
Javascript is a dynamic language; there is no ahead-of-time compilation. Things can only be done at runtime, including adding properties to objects. If you mean that mutating values should be avoided, then I would emphatically agree. That's certainly not a Javascript-specific issue though, and Java is just as riddled with mutability as anything else.
I haven't had enough experience with prototypical inheritance to comment on it vs class-based inheritance; I've been burned enough by class-based inheritance that I tend to avoid inheritance in all forms (and OO too, these days).
And I am not only person who needs classes in JS: https://github.com/search?l=JavaScript&q=class&type=Reposito...
I do not see any benefit in prototypes. It just makes code more complicated and buggy. I would happily use them if I knew a way to do it while keeping code simple.
> When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used
Yet Javascript has neither of those.
> If you mean that mutating values should be avoided
No, I am ok with mutable values.
My point is that what's "readable and maintainable" depends on the language; especially on what facilities it provides, and to some extent community consensus (what's 'idiomatic').
Javascript's main facilities are first-class functions with lexical scope, lightweight key/value mappings (which it calls "objects") and prototypical inheritance between those objects.
Java's main facilities are classes with properties and methods; whilst it's recently gained first-class functions, most Java code has been written without them, and they'll always be in competition with classes+methods (e.g. look at all of the APIs which use single-method classes, like "Comparator").
These are very different, so what's readable/maintainable will differ in each. For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'.
In idiomatic Java, such objects should be instances of a class, which should either be global or else implement a global interface. Since global class/interface declarations require standalone files, our declarations end up very far away from the use site; this prevents us accessing the use-site's scope and puts us under more pressure to make it descriptive, generic, reusable, etc.
> Yet Javascript has neither of those.
ES6 has a module system, Java has its "package" system. Trying to apply SML practices to either is a bad idea, just as trying to apply Java OO practices to JS is a bad idea, or trying to apply Lisp macro practices to C is a bad idea.
Idiomatic doesn't mean maintainable and scalable. Imagine you are working on a project in a team, not alone. How do you understand what kind of "lightweight" object you should pass to this function:
When you have thousands of such functions you'll spend most time reading through their code to understand what type of argument they need. This means "idiomatic" javascript code works only when it is small in size. Once it gets larger you'll have to resort to old school non-idiomatic Java-like classes and a static typing system.Regarding prototypal inheritance I don't understand how it is supposed to be used. Let's say we have constructors for objects User(name) and SuperUser(name, privileges). I understand if `SuperUser` is inherited from `User` (class-based ineritance), but I don't understand what is the meaning of SuperUser being inherited from some user charlie. Why `charlie` and not `john`? Why do I need an instance of common `User` to create a `SuperUser`? And as I haven't seen the explanation in above comments I guess you don't understand it too yet evangelize about it.
I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all. As an argument I can say that a helper method `Object.create()` that is required for object inheritance was only added in ES5 [1] and haven't existed in earlier versions. This is how you create objects from objects without classes and even without constructors:
I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
...and this is where well-documented interfaces come in.
>but I don't understand what is the meaning of SuperUser being inherited from some user charlie.
That was merely an example to express the difference: the idea is, instead of writing a class and doing things that way, objects are cloned from one another. If you want to create a user with special powers, you clone the user object (usually running a constructor function along the way) and give it whatever new functions you want. If you want to create more of these special users, you make them all have that one as a prototype. Typically, the prototype object is never actually used or altered from the defaults, as this would be confusing, and is given a constructor function to instantiate state. But it doesn't have to be.
>I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all.
Wrong. Object.create may be new, but prototypical inhertance is an important par of how the constructors you claim to be the way objects were meant to be created work. Function.prototype, the property which determines the prototype of objects created by a constructor, dates back to ES1.
>I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.
Also complete nonsense. Prototypical inheritance was originally implemented in Self, a system developed my Sun Microsystems, and a descendant of Smalltalk-80, which certainly was designed for large applications. JS may have been built for writing simple for validation scripts, and it may be a deeply flawed language in some respects, but the fundamentals of the language, prototypical inheritance, true first-class functions, and lexical scoping, are all things that Eich got right. And given first class functions and lexical scope are still things that language designers have trouble getting right (I've got nothing against class-based OO, so I'm not including it here), it's even more remarkable that Eich did it properly in 1997.
No. This code causes an error in PHP:
This code doesn't raise an error in JS: So with JS you learn about errors later and spend more time on debugging.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 Symfony you won't miss a notice.
I think default PHP error handling system is wrong - there should be no warnings or notices, only exceptions. Sadly OOP was not very popular among PHP devs in the beginning.
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
Your whole example is silly. Stuff like this is why you write your PHP/JS/Python/Ruby code in a tool like WebStorm/PyCharm/RubyMine which does enough code analysis to realise you've made a typo and flag it.
You should try "use strict" sometime. If you write sloppy JS, you'll find out in no time.
Javascript will still have most of its warts, mind you. But some of the most obvious errors should at least be catchable.
I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all
Type casting in PHP gets fixed gradually: https://wiki.php.net/rfc/invalid_strings_in_arithmetic .
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 files, that you ftp-d in and it just worked.
99% of the friction is in writing the first thousand lines of code and PHP meant that nearly all of those lines was business logic, not unescaping POST data or parsing GET parameters.
PHP doesn't remove your ability to think clearly. It is true that it does not provide helpful additions for algorithmic work, but it does not put challenges in your way when writing web-apps. And yet, it does not force you into too much magic about how it works - just enough abstraction for a messy coder.
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 would argue that it still does. It's not a great language, but to just get something working I still can't think of anything better that doesn't require lots of planning or infrastructure
If you think it's not then there's something else going on you're not addressing...
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.
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
But I see what you're getting at... if you need to whip up something quick, don't start experimenting with the "flavor of the day" language or library.
Finally, good luck with writing a unit test against an API not created by you because, you have to go through deep into the source code just for figuring out what data structure return and give.
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.
Is that a good idea?
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.
Edit: guess why everyone will need to rewrite their stack in another language when they've bigger traffic on a php platform
V1 is usually shit in any language and if it does what it's supposed to do, it remains shit forever. I've seen shit in C#, Java, and ROR. I've seen stored procedures stringed together inside MSSQL Server vomiting HTML snippets and PS shells giving birth to Excel files to be consumed via network share by some poor soul pressing a button in Excel. I've seen systems written in "enterprise" style, by "enterprise" developers without a single automated test and 20+ levels of abstraction with cross-dependencies running like spider web among 10-some "sub-projects".
I'm not even talking about time-tested shell scripts you can find included by default in your favorite distro or the widely beloved ./configure.
I guess the point is, the language has nothing to do with the attitude of the developer / project manager / product owner. It's easy and convenient to just dump your problems on the tool you're using, but the reality is more deeply rooted in the whole approach to software development (just get shit done), project management (the requirements have just changed, dude!) and the general "i need it done last week" attitude of the product owners.
But sure, let's collectively shit on PHP, just because it's easier. Just like writing shit code is.
I started my career as a PHP developer. Any web project you prototype in C# could be prototyped in PHP in a small fraction of the time.
versus just
but, come on, it's not that bad/difficult, is it?on an tangential note - I never had imagined i'd be defending the point that C# is as simple as any other language... Funny how life sometimes takes you to unexpected places.
> They just don't care.
> It's a garbage language.
I think this overly dismissive/elitist approach is part of the reason why alternatives failed. Couple that with the ridiculous claim that a developers' time does not matter.
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.)
Painful to read. I've struggled with this my whole career.
Reminds me of Alistair Cockburn's seminal essay about methodologies.
Characterizing people as non-linear, first-order components in software development
http://bit.ly/1eDUNlE
Money quote:
"Problem 1. The people on the projects were not interested in learning our system.
Problem 2. They were successfully able to ignore us, and were still delivering software, anyway."
I'm going to frame these words and hang them on my desk.
Now I don't fret as much about unsexy tech. I do still advocate for new things when they make the team more productive, but I hope I never have to work at a place again where the latest and greatest stuff is used and people get nothing done.
My perception of the Clojure crowd is the exact opposite. They seem to be a bit too in love with the process and craft and not enough with the end results. That being said, I'd much rather code Clojure as a day job (I promise to be market focused!) than PHP. Right now I am almost all Python. There are definitely a lot of Python folks who are too much enamored with the craft, but the crowd is so big there's plenty of room for the GTD folks.
A couple of months back there was this php sucks article about being looked down upon because you do php for a living. Php is the language people bitch about to feel better about themselves. Even within the php community symfony developers don't take drupal developers seriously. It's sad really and even I'm guilty of doing that. A little more respect for your fellow developers is all we need. It's like judging a book by it's cover. How would you feel if <insert your fav lang> was treated that way.
Php has a lot going for it. The community is very active and passionate, new things come out at a rate you can keep up with. You can easily get passionate about it if you engage in it. A lot of interesting projects are (being) build with it and it is obvious that php won't disappear anytime soon.
If you have to work with php and bitch about it, make the effort and solve the problem you have with it. Contribute back to the community and experience the gratitude. You'll enjoy your work more.
So there are php people that care and they try to make the best of it. I don't think they consider it to be a garbage language. They are the ones that made php what it is today which is something totally different compared to what it was years ago.
Almost any big app you can point to that is built in PHP today was bootstrapped in this environment.
I did a lot of PHP from the late '90s up until 2008. Maybe things have changed in the intervening eight years, but I cant say I miss it.
There's a way to make Apache fork after some code has already been run, but boy howdy if you don't do that and love those mega-frameworks.
I must say that PHP 7 is a great language nowadays. Most of the modern concepts are baked into a language or are about to be developed.
At some point, I wish Hack and PHP merge into a single language in the future, somewhat similar to what happened to Node and iojs. I'm not sure if Hack is going to be around in 5 years, but I'm pretty confident about PHP.
I'd definitely love to see more articles about Hack and people's experience with using it in production.
Most of the hate for PHP comes from the PHP 4 days, but we are well past that and charging ahead with featureful yearly releases.
"PHP is garbage language!", "PHP is a shitty language!"
That is the antiquated view of course. The old days.
Now with Laravel and PHP7 it is a pleasure to use.
I'd go further.
Working in Laravel is BETTER than ROR IMHO.
rails + unicorn/passenger v/s apache + mod_php.
That's not a fair comparison though. For any non-trivial app, most people deploy PHP using a CGI, PHP-FPM being the standard. Even the cheap, shared hosts provide FastCGI these days.
That being said, getting RoR or Django up and running is really no more difficult than getting Laravel setup and running via PHP-FPM.
this is certainly what got me started with PHP and what makes its so easy for beginners
The implication that C is an especially strict language for type conversions is strange. C is actually one of the loosest languages for type conversions. It's even legal to do things like compare pointers to integers (though most compilers warn you)!
That's not mentioned in the blog why they didn't use PHP for this.
If you want to handle HTTP requests quickly, reliably, repeatably, with minimal setup and maintenance, I still argue that PHP is one of the best. And yes, because of Apache and Nginx, but that doesn't nullify the point.
Most languages don't "have to do HTTP" and those that do often do a pretty terrible job. Somehow Node not only does it, but does it well, where a bare Node process behind some load balancers is often enough to get the job done. PHP on the other hand needs all sorts of hand-holding to work properly.
JavaScript does have threading facilities like WebWorkers, but they're often largely overlooked since the code complexity that comes with it isn't worth it and the multi-process model generally works fine. A single Node process can do a lot of work because of the aggressively asynchronous approach to processing it takes.
Node + Express is actually a pretty slick package.
JavaScript is generally a lot better at compute intensive tasks than contemporaries like Ruby, Python, PHP and Perl due to the incredible performance of the V8 engine and others like it. The language is ugly, but it's more easily optimized by the JIT compiler.
If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.
Java and Go work just fine here and both are used for webdevelopment.
My point is that js in not suitable for many cpu-bound operations and neither webworkers nor multiple processes are enough to help it with that. In the browser you don't have other option, but on the server you can (and in practice people do) use other languages like java or go (not to mention C/C++). This is were things like image processing or full-text search goes.
the "most typical" Python stack (wouldn't call it a application server) is probably built with Django where you don't reason about the Server restart, it's as fast as changing something in PHP.
P.S.: I don't use Python that much anymore. Other people would say that the thing I'm using now takes endlessly long to compile and has some wierd operators.
And the subcycles are literally "Change -> [run test | send test request]".
It looks like generics aren't yet in the core language (https://wiki.php.net/rfc/generics), but I believe return type hints work. I think we're also still missing property/field type hints (https://wiki.php.net/rfc/property_type_hints).
This has its pros and cons. This means these declarations are always enforced, even when calling between typed and untyped code. However, there's no compiler to catch you out, at least not just from using the interpreter. Your IDE, or an external type checker (e.g. Phan) can check them for you, though.
PHP 7 also gives you a choice between weak and strict type coercion modes, whereas Hack lets you choose between enforced type declarations and unenforced type declarations.
As for the specific things you can type in PHP 7.0, there's parameter and return type declarations for `int`, `float`, `string`, `bool`, `array`, any class or method, and `callable` (a function name, method reference or closure). PHP 7.1 brings nullable types (prefix any type name with `?`), `iterable` (an array or an object implementing `Traversable`) and the `void` return type (enforces that a function doesn't use `return` with a value).
Notable omissions are generics (even for arrays), and property types. There was a proposal for the latter, but it was rejected, for better or worse. As bkanber mentions, however, IDEs can still check property types if they're annotated using docblocks. Hack also has a few extra special types that PHP lacks.
>First, state. Every web request starts from a completely blank slate.
Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once.
>I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound.
I cannot disagree enough with the conclusion he draws from the quick feedback loop in PHP. I do PHP in my day job, because that's what our codebase is in, but recently I finally got the opportunity to use Haskell for a side project. The feedback-loop might be slower (honestly not by much, automatic reloading is a thing in almost any framework), but I'm a zillion times more confident in my code, because you are able to encode so much logic in the type system, meaning the compiler will catch whatever. Contrast this with PHP, where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours. Particularly when refactoring code, which you often end up doing while hasing something out.
Also, PHP works at a quite coarse granularity of concurrency. A thread per web request only? As soon as you want to do something more advanced, you are forced out into the many patchwork solutions (wanna do async? queue that shit).
Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry - heck PHP was my first language and I made a CMS from scratch without even knowing much of what I was doing.
That said, it has come a long way, and something like HHVM/Hack definitely helps a bunch! I just think the pros in this blog post are quite weird and IMHO incorrect.
</rant>
I mean, you're not reinitializing it, and it's not exactly slow. And when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere.
> where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours
I'm not really sure what you mean by that. Write a method, write tests for that method. Just because PHP has weird type coercion issues doesn't mean you can't be diligent about the types that you use. And of course tools like PhpStorm understand docblocks, annotations and PHP types and classes and basically does the same thing that a compiler does, it'll show you big honking type errors if you ask it to, it'll even stop you from committing broken code if you use that option.
> Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry
I don't know about that. Low barrier to entry gets you a lot of crummy projects. In my experience PHP is a lot easier to manage and maintain in production, and that's a huge advantage to companies and products with small teams.
It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted, like resource pooling, memoization, config loading etc.
> > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours
>Write a method, write tests for that method
Exactly, I need to write tests for things that are trivially verifiable by a compiler. And I'm not just talking about type coercion (which is a bad thing), but also missing function parameters, wrong parameters, missing initialization of variables etc etc. These are runtime errors and you either have to write tests to catch them (hence visit very code block) or manually try and reach them.
Some IDEs, like PHPStorm, can you get pretty far though.
>Low barrier to entry gets you a lot of crummy projects
As someone else mentioned in another comment, 1% of PHP projects succeeding is still a lot more than 20% of Haskell projects.
>PHP is a lot easier to manage and maintain in production
Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory for a PHP site to really run performant, adding quite an overhead to any production setup you'll get into.
Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database.
All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.
JavaScript and Python both have systems that allow you to do this: JavaScript has the Google Closure Compiler, and, more recently, TypeScript. Python has a number of projects that use a common syntax [1], including PyChecker.
I say this not to "well, actually" the post, but just to be a gradual typing cheerleader. It's great! We should all be using it! All the time! Please!
[1] https://www.python.org/dev/peps/pep-0484/.
> First, state. Every web request starts from a completely blank slate.
> Second, concurrency. An individual web request runs in a single PHP thread.
> Finally, the fact that PHP programs operate at a request level
Isn't this just "virtues of Apache modules"?
There's mod_python, mod_perl, and mod_ruby. Are state, concurrency, and global requests virtues of these languages too?
---
Even if you do somehow convince me that these virtues are specific to PHP, you can't convince me it does it well. Hence, MaxRequestsPerChild.
To quote Radmus Lerdorf,
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
Clean slate, my eye.
They're cattle not pets. (/semi-sarcastic)
Also, most folks serve PHP applications in production under PHP-FPM/FastCGI.
The reality is these (above) and many other good languages/frameworks exist out there for building web apps today. we live in the time with a ton of choice, and the rest is in our hands.
I for one love the new .NET Core, but I am a little biased being a long-time .NET developer and a Microsoft employee as of late.
Does anyone have a good example of an open-source PHP project that will enlighten me?
This cannot lead to real conversations or good software. There are far too many naysayers always eager to jump in with their 2 bits of negativity with the same cliched talk points and links most of whom I am sure would never be seen near php and may not even have used it.
The criticism goes silent when HN favourites like Slack show up on discussion. Ignoring the sheer number of high traffic websites and successful startups using PHP is just another way to deny it its due.
Most PHP apps are a breeze to install and use compared to just about any Ruby or Node app. Try installing Discourse to understand just how user hostile it has become. The respect for users and simplicity comes through in PHP. NPM and Ruby with their dependency hell expect a full dev environment even on user machines and nobody thinks this is ridiculous. There is no denying PHP warts but Node, Ruby and Python I think have their fair share of issues.
I really do like Python but for a web project that needs to scale and not get mired in other issues I would choose PHP every single time. For a library or SAAS app maybe, but for an installable app I would never expose users to the Ruby or Node ecosystem.