It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
PHP's a language people love to hate. It's messy, it's clunky, the standard library uses inconsistent nomenclature, it lends itself to a multitude of sins particularly in larger application architectures. It is often not taken seriously as a language, mostly for bad reasons, but the faults it does have do tend to make people who have used both PHP and other languages prefer those other languages to it (I among this number).
As with other things people love to hate its objective badness is often performatively overplayed. Eventually this becomes part of the legend, as it were, and people with no hands-on experience begin to immediately dismiss what worth it does have and what it's possible to accomplish with it. I hear PHP 7 fixed a lot of the real problems with previous versions, which is great, but I am also sure that this will do little short- and medium-term to stem the tide of PHP hate.
Modern web development is pick-your-poison. There's lots of interesting stuff happening with Node.js right now, to the point that the scene has become quite fragmented, but that process seems to be approaching stability as communities coalesce around a few major web and frontend frameworks. Ruby is also a substantial presence thanks to Rails' popularity, Elm is a thing, and there are of course still popular web frameworks in other languages like Python and Elixir. More server-centric web applications may still use a .Net or Java stack.
I get everything you say! I've made those same observations. I do like your point in which you said people who haven't even coded in it already dismiss it.
NodeJs is the new nice and shiny everyone is falling in love with. But ES5 currently doesn't even support classical OOP. So if the argument is that a language is fundamentally bad because it has faults, then why aren't languages like Javascript and NodeJS being looked at in the same light? Because they certainly do have their issues. Proven by the point that we needed to create Typescript.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Many people don't take JavaScript seriously either thanks to its checkered history and common usage on the frontend. PHP is just lower on the totem pole.
For what it's worth, I consider prototypal inheritance and a lack of type safety reasons for using JavaScript. If I wanted classical OOP and static types, I'd use a language built around classical OOP and static types.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
Many! Composability is a really powerful technique with a host of applications, and it's much, much easier to accomplish with a prototypal model than it is with classic object orientation.
For a concrete example, I maintain a data access library which introspects a database to build an API over it. A database contains tables, views, functions, and schemas. Tables can be read and written; views can be read; functions can be executed; schemas act as namespaces and contain objects of the other three types. The first three object types have certain attributes in common: a name, a schema they belong to, et cetera.
A classic OO approach would be to create an Entity class which centralizes the common attributes, and have each of Table, View, and Function inherit Entity. A method may act on any "real" database object (omitting schemas, which just contain things) as long as it takes an Entity and either only references Entity properties and methods or performs the appropriate checks and casts.
Then you get into the "building an API" stage. The goal is to return a Database tree that lets you issue a statement like db.things.stuff.find(), where things is a schema and stuff a table, determining the query target by navigating the tree. This isn't so hard: simply ensure that you create namespaces and attach Entities at the appropriate path.
However: the default schema is unnamespaced, so what happens when it also contains a table named things? What do you do now? Classic OOP has no easy answer. Do you create classes for TableWhichIsAlsoASchema and TableWhichIsAlsoAFunction and all the other possible collisions? Do you cross-contaminate your three base classes and gate alternative logic behind introspection checks? Good luck!
With prototypal inheritance, resolving these collisions isn't just possible, it's easy: just keep applying prototypes as they come in! If you already have a Table at a path which turns out to resolve to a schema as well, you can just hang the new stuff on the existing object. The only collisions that can't be resolved are due to (small-f) functions being overridden or becoming ambiguous, not due to simple pathing.
But ES5 currently doesn't even support classical OOP.
I hate to break it to you, but many of us consider this a feature, not a bug.
If you value Composition over Inheritance then Javascript is for you. In any case I don't think it is fair to consider this a "fault", and many people (myself included) think that introducing class in ES5 was a big mistake.
This isn't to open a flame war about OOP vs. Functional programming. Just that if your language is good at functional programming, you should double down on that, rather than adding functionality for OOP-driven developers who don't understand why Javascript is a powerful functional language, and how to leverage that.
So you get people using classical inheritance patterns in a language that's meant for prototypal inheritance.
The thing with Javascript is, you have no real choice about using it on the front end. I think a lot of the server-side momentum is driven by this fact. The thinking being that a dev can leverage the knowledge that already have for the server side too.
I consider Javascript far worse than PHP (and I don't care for PHP that much after writing a lot of things in it). But that does not alter my lack of choice about whether to use Javascript. If I were coming at this thing fresh, I would be tempted to try to use the same non-optional language across the board too.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
PHP's a language people love to hate. It's messy, it's clunky, the standard library uses inconsistent nomenclature, it lends itself to a multitude of sins particularly in larger application architectures. It is often not taken seriously as a language, mostly for bad reasons, but the faults it does have do tend to make people who have used both PHP and other languages prefer those other languages to it (I among this number).
As with other things people love to hate its objective badness is often performatively overplayed. Eventually this becomes part of the legend, as it were, and people with no hands-on experience begin to immediately dismiss what worth it does have and what it's possible to accomplish with it. I hear PHP 7 fixed a lot of the real problems with previous versions, which is great, but I am also sure that this will do little short- and medium-term to stem the tide of PHP hate.
Modern web development is pick-your-poison. There's lots of interesting stuff happening with Node.js right now, to the point that the scene has become quite fragmented, but that process seems to be approaching stability as communities coalesce around a few major web and frontend frameworks. Ruby is also a substantial presence thanks to Rails' popularity, Elm is a thing, and there are of course still popular web frameworks in other languages like Python and Elixir. More server-centric web applications may still use a .Net or Java stack.
I get everything you say! I've made those same observations. I do like your point in which you said people who haven't even coded in it already dismiss it.
NodeJs is the new nice and shiny everyone is falling in love with. But ES5 currently doesn't even support classical OOP. So if the argument is that a language is fundamentally bad because it has faults, then why aren't languages like Javascript and NodeJS being looked at in the same light? Because they certainly do have their issues. Proven by the point that we needed to create Typescript.
Many people don't take JavaScript seriously either thanks to its checkered history and common usage on the frontend. PHP is just lower on the totem pole.
For what it's worth, I consider prototypal inheritance and a lack of type safety reasons for using JavaScript. If I wanted classical OOP and static types, I'd use a language built around classical OOP and static types.
Interesting. What scenario would you say a developer might want a prototype model over plain-old OOP?
Many! Composability is a really powerful technique with a host of applications, and it's much, much easier to accomplish with a prototypal model than it is with classic object orientation.
For a concrete example, I maintain a data access library which introspects a database to build an API over it. A database contains tables, views, functions, and schemas. Tables can be read and written; views can be read; functions can be executed; schemas act as namespaces and contain objects of the other three types. The first three object types have certain attributes in common: a name, a schema they belong to, et cetera.
A classic OO approach would be to create an
Entityclass which centralizes the common attributes, and have each ofTable,View, andFunctioninheritEntity. A method may act on any "real" database object (omitting schemas, which just contain things) as long as it takes anEntityand either only referencesEntityproperties and methods or performs the appropriate checks and casts.Then you get into the "building an API" stage. The goal is to return a
Databasetree that lets you issue a statement likedb.things.stuff.find(), wherethingsis a schema andstuffa table, determining the query target by navigating the tree. This isn't so hard: simply ensure that you create namespaces and attachEntitiesat the appropriate path.However: the default schema is unnamespaced, so what happens when it also contains a table named
things? What do you do now? Classic OOP has no easy answer. Do you create classes forTableWhichIsAlsoASchemaandTableWhichIsAlsoAFunctionand all the other possible collisions? Do you cross-contaminate your three base classes and gate alternative logic behind introspection checks? Good luck!With prototypal inheritance, resolving these collisions isn't just possible, it's easy: just keep applying prototypes as they come in! If you already have a
Tableat a path which turns out to resolve to a schema as well, you can just hang the new stuff on the existing object. The only collisions that can't be resolved are due to (small-f) functions being overridden or becoming ambiguous, not due to simple pathing.I hate to break it to you, but many of us consider this a feature, not a bug.
If you value Composition over Inheritance then Javascript is for you. In any case I don't think it is fair to consider this a "fault", and many people (myself included) think that introducing
classin ES5 was a big mistake.This isn't to open a flame war about OOP vs. Functional programming. Just that if your language is good at functional programming, you should double down on that, rather than adding functionality for OOP-driven developers who don't understand why Javascript is a powerful functional language, and how to leverage that.
So you get people using classical inheritance patterns in a language that's meant for prototypal inheritance.
The thing with Javascript is, you have no real choice about using it on the front end. I think a lot of the server-side momentum is driven by this fact. The thinking being that a dev can leverage the knowledge that already have for the server side too.
I consider Javascript far worse than PHP (and I don't care for PHP that much after writing a lot of things in it). But that does not alter my lack of choice about whether to use Javascript. If I were coming at this thing fresh, I would be tempted to try to use the same non-optional language across the board too.