Earlier quoted context omitted.
I'll offer an alternate hypothesis. Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to cherry-pick the winners and miss all of the t…
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.
Taking PHP Seriously
311–320 of 673 posts
Re: Taking PHP Seriously
#312Earlier quoted context omitted.
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).
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
Welcome to prototypical inheritance.Re: Taking PHP Seriously
#313Re: Taking PHP Seriously
#314Earlier quoted context omitted.
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".)
Luck. Timing. Culture. Team. Etc. All have a greater impact than language. Anyone who says otherwise doesn't understand history.
Re: Taking PHP Seriously
#315Re: Taking PHP Seriously
#316Earlier quoted context omitted.
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…
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()Re: Taking PHP Seriously
#317Earlier quoted context omitted.
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…
"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.
Re: Taking PHP Seriously
#318I 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…
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 t…
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.
Re: Taking PHP Seriously
#319Earlier quoted context omitted.
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…
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.
Re: Taking PHP Seriously
#320I'm surprised no one has posted this fairly thorough criticism of PHP from a few years ago https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
That thing was parroted a thousand times already and it really boils down to a personal rant about tons of legacy features rather than a properly worded criticism of the language itself.
The author is also really confused about type coercion in PHP.
It's been almost 5 years. Let it go.
Use this:
www.phpsadness.com