There are two comments of mine that I think are worth enough to put up on the blog, even if it is for being bashed by the internet, as it adds more substance to my opinion.
“pinnr” reminded me that both languages has lot of flaws, and I agree. But why no substitute won so far? That’s my comment for it:
That’s a good point. PHP and JS are full of “gotchas”. It makes me wonder, why no other languages have replaced them already?
Maybe if a new language can be as permissive and flexible as JS and PHP are, use an easy to understand flow (both are basically an infinite interactive loop) and adds more “sanity” to it, then it could win. The problem could be that new languages tries to be saner and stricter at the same time, and the web doesn’t like the stricter part. Does it make sense?
From “aslate” comments, I believe some people thinks that WordPress plugin system is just an example of a well defined API, and has no relation to PHP itself, as it could be made in any other language. I do believe that almost any high level language can be used to build a plugin system, but not as flexible as PHP would (or other languages that uses the “Assumption Inversion Principle”). That’s my answer to it:
Types, imports and modules enforce too much for the web. That’s my point of view.
By using only assumptions in your code, you don’t care how those assumptions are met, you just believe they will be somehow. It is like Dependency Injection, but at a more granular level.
Writing a single piece of plugin code that works on multiple versions of WordPress, leveraging new functionality when available is as simple as checking if a function exists (inspecting the environment) and adapting.
Imagine that JS used modules from the very start. A lot of libraries would have
require('jquery')to only ever use a minor subset of it. This is where “assumptions” shine, you only pay for the exact subset of assumptions you make, and your code believes they would be fulfilled somehow.
jQuery has alternatives, underscore.js has alternatives, Backbone.js has alternatives. If each module selected one that better fits its need and you end up using those modules, you would end up with a bunch of duplicated JS functionality in your final product.
That’s the main point: when you require/import/etc something. You are locking your code with a preset selection that you made for whatever reason, and you are forbidding others to change that. There are plenty of reasons that other developers would want to change that selections (e.g. add a cache layer, only use a subset for space constraint reasons, completely mock it out for testing, use a proxy pattern to delegate things for a remote service, …).
Coming up with an API that fits every need is completely impossible. IMHO it is better that each code use assumptions about its dependencies, the same way a JS or a PHP function use assumptions about its arguments.
So, what I’ve called as Assumption Inversion Principle may have a 1:1 relation with duck typing of variables, but taken to the module level.
If you are an advocate of duck typing, why not advocate a “duck typing of dependencies”? What is the fundamental differences that I am missing here?