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 u…
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 Py…
Taking PHP Seriously
571–580 of 673 posts
Re: Taking PHP Seriously
#572Earlier quoted context omitted.
it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be. i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale. everyone is tearing away adding features, and t…
I think I sat next to you at zynga back in 2008 and remember your php struggles vividly.
Re: Taking PHP Seriously
#573Earlier quoted context omitted.
But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.
> 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…
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.
Re: Taking PHP Seriously
#574Earlier quoted context omitted.
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…
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 wo…
def __call__(self, request):
client_ip = request.META['REMOTE_ADDR']
self.last_visitors.append(client_ip)
...
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.
Re: Taking PHP Seriously
#575I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…
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.
Re: Taking PHP Seriously
#576Earlier quoted context omitted.
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). 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 comp…
> 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")…
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.[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: Taking PHP Seriously
#577Earlier quoted context omitted.
>PHP isn't quick. As of PHP7... it actually is quicker than other languages in it's domain.
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.
See an older counter-point with the much slower PHP 5.5:
https://philsturgeon.uk/php/2013/11/12/benchmarking-codswall...
Re: Taking PHP Seriously
#578Earlier quoted context omitted.
Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.
> Yeah, but you also have to fork a whole process per request to do it. Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.
Re: Taking PHP Seriously
#579I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…
Re: Taking PHP Seriously
#580Earlier quoted context omitted.
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 ar…
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.