(Also, PHP isn't perfect, but it's really good at allowing clear readable code, while also allowing terrible code, also the performance is terrible... Basically, don't waste your breath on why PHP is terrible - it isn't, it's a decent language - you're just using it wrong)
Imperative programming has no future IMHO. Rust is going to the ends of the earth to make it "safe" but my gut feeling is that it will never be fully statically analyzable. Today I only see needless complexity that distracts from the underlying logic. I lost interest in this style of programming around a decade ago.
Functional programming via templates is an admirable endeavor, and I went all the way to the ends of the earth to make something of it. I was left with code that wasn't reusable (wasn't salable) so in the end, just wasted years of my life on needless complexity.
And both of the above only make sense from a performance perspective. An argument that becomes weaker with each passing year as processing speed improves.
I think the future will be something more like reactive functional programming, written in a high level language like Javascript and only dropping down to bare metal optimizations with something like Rust when necessary. It will work like the UNIX shell (which is the only proven model that's endured). So something like the Actor model where a series of black boxes are wired together with pipes and as much FP as possible, and any IP sections are treated like monads and flagged as having unknown side effects. ClojureScript does something like this, running its FP code to completion and then yielding until more input/output happens on the Javascript side. Another way of thinking about this is a spreadsheet with some imperative code within the cells where needed.
PHP is my favorite language currently because it has some notion of constness and fairly decent higher order functions (but who are we kidding, map and reduce give us everything else). PHP is a conceptually simple language that has some longstanding flaws with naming conventions that make it not as easy as it could be. It's largely succeeded in moving away from object-oriented programming, favoring a fairly simple interface implementation instead. I've never run into the implicit context problems that plague languages like Ruby (where convention over derivation is written into its DNA).
And PHP is fairly fast, on the order of 200 times slower than C++ but probably within the same order of magnitude as the newer C++ methods mentioned in the article. My gut feeling is that proper string handling, with every contingency accounted for, runs approximately the same speed in any language. I'm not willing to spend time and effort trading safety for performance anymore.
Uhm, how are cell functions in spreadsheets an example of imperative programming?
I'd like to see a spreadsheet that uses something like Elixer or Clojure though because then any cells that don't have monads could be fully statically analyzed and form a purely declarative solution.
In other words, the cells could be decomposed further into cells containing individual functions instead of composed statements. That way the spreadsheet could be transpiled into lisp or a syntax tree. I'm using all these terms loosely, but they are equivalent.
https://www.aerospike.com/blog/php7_php5/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
That said, I think it's too complex for a portion of our team to grasp. So now what - do we use it, and alienate them? Or stay in the "dark ages"?