Speaking as the primary author of a book in one of the popular perl web frameworks (who is having difficulty doing stuff other than perl because a. my skills in perl are too much in demand, and b. Because for most of my normal work I haven't found anything perl can't do as easily or easier than other tools yet) here's my semi-considered opinion.
Meh, all the dynamic languages are basically the same. They're all basically things that manpipulate strings and C pointers. For perl/python/ruby/js here's what I'd sort of recommend:
* Pick from your team's strength, unless:
* Lots of turnkey logic, code quality and debug tools are not a priority, and you want to be able to hire fast and cheap: PHP.
* Lots of turnkey logic, per-performance isn't a problem and you want some higher order programming capability: Ruby.
* You want to manage a java-like large team for not so trivial logic, and you prioritise uniformity over expressivity. Python. Also python is a good environment for academic work as it helps the academic programmers not shoot themselves in the foot so much and academic code is a mess. Which is why python is such a good extension language for other tools.
* Async greenfield stuff where you don't need to worry about external libraries much: javascript. Also the only game in town for web front ends (plus its transpiling friends). Javascript is like a syntatically impoverished perl in this regard.
* You've got a whole bunch of mess in business logic and/or systems logic that you need to encapsulate, and you've got a small highly capable team who want to prioritise expressivity over uniformity. Perl excels here. So does python, but it'll make you do even more horrible things papering over the mess.
Regarding the last point, I believe if it reaches a tipping point perl 6 will be a good thing for async, multicore and parsing related stuff, and should be long-term productive and reduce the requirement for having as highly capable and a disciplined team that is really a requirement for non-trivial perl5 code bases.
Also perl5 is second to none for programming language back compat. I had a decent sized non-trivial project I'd written for internal (research) purposes, then neglected for several years. Then I had to look at the running code again. I'd been through several minor OS upgrades, moved to a completely different OS and gone through at least three major versions of perl. Aside from a couple of missing CPAN modules that I had forgotten about in the Makefile.PL, everything was fine out of the box.
I have a nagging feeling that server side JavaScript will soon become the new PHP. It is getting more and more popular among not-so-good programmers, and given its loose syntax I think it will lead to disastrous code. Not to mention that ECMA is working toward ADDING new feature to the language instead of deprecating some obscure ones, which would make the language easier to use.
Of course, PHP makers made their share of mistakes with their decisions - register_globals, safe_mode (which was not), inconsistent function naming in standard libs, myriad of weird bugs (like syntax error (still) throwing HTTP response 200),...
> Not to mention that ECMA is working toward ADDING new feature to the language instead of deprecating some obscure ones, which would make the language easier to use.
We'll see what happens longer-term. Certainly until recently the focus has been on the web (and deprecating features on the web is rather pointless: the web still supports things that were deprecated two decades ago, as dropping support breaks sites which makes users change browser or stick with an older version).
There's plenty of things listed in Appendix B of the spec, "Additional ECMAScript Features for Web Browsers", which contains much of the worst parts. Perhaps more will move there in the future, or to some separate section of previously-standardised-but-now-optional features.
As a fan of node.js, I'm afraid you are probably right... and not just front end guys. Some of the most horrific JS code tends to come from (imho) "enterprise" C# and Java devs... there are some patterns you just do not need to do in a dynamic language environment... and only complicates things for no real gain.
There are some really beautiful patterns emerging in the JS community though. React (mercury and others), Redux, RxJS, Koa, etc... But it takes a different kind of discipline to break up modules, and write pure functions instead of relying on typical OO paradigms for systems development. I cringe every time I see a senseless/useless DI/IoC system in JS that adds nothing but indirection and complexity (looking at you Angular).
If you're doing node-style (cjs) modules, you can use something like proxyquire[1] with testing to inject dependencies without complicating your modules, or creating logical indirection. If the only reason you have DI is for testing in a scripted platform, you're probably doing something wrong.
You can write, compose and composite plain objects and pure functions in JS modules that can be tested very easily without resorting to complex DI systems (with naming disconnects even).
> debug tools are not a priority, and you want to be able to hire fast and cheap: PHP.
The only debug tools that we found that were better than XDebug or NuSphere were Studio And C#. Perl, Python and Ruby were all a bit rubbish in comparison.
I can't compare to the tools you mentioned since I haven't done much PHP in the last 10 years, but for Perl, I would strongly recommend you check out the following (Most are from the CPAN):
* For a graphical IDE: Komodo or Padre or Eclipse with EPIC (great debugger support in those, since Perl 5's built-in debugger is pretty old-skool, requiring significant skill and experience to use effectively)
* For code quality/standards static analysis: Perl::Critic
* For performance profiling: Devel::NYTProf (seriously one of the best profilers I've used in any language)
* For test coverage analysis: Devel::Cover
* For benchmarking: Benchmark (core module) and friends
* A REPL: Devel::REPL or Reply
* On-demand debugging: Enbugger and Devel::Trepan
* Unit testing: Test::More (and there are many, many other Test::* modules for anything you can think of that use the same general testing framework as the basic Test module that comes with Perl 5)
And there are so very many others out there that to mention them all would take all day, but these are the ones I use and like the most. Of course, others may have their own preferences and I'm sure there's even better stuff I haven't yet discovered TIMTOWTDI and all
I had a quick squizz at XDebug, and I'll try to remember it's existence next time I need to do some php debugging. On the other hand it looks quite high friction what with the extra config required.
For the normal use case I use `perl -d myscript.pl` as my goto debug tool, and I use the amazing test infrastructure to try to ensure that I'm debugging tests rather than interactive code. For web front end interactions I'm usually looking at:
perl -d `which plackup` dev_server.psgi
Usually using LWP::Protocol::PSGI to get that server process management running inside my test.
For old codebases that have never run aside from inside apache, usually it's a matter of up to a day to decouple from the web server, although botched incrementally accreted mod_perl codebases can be much harder to tame (couple of months).
I'd have to disagree with code quality in regards to PHP. While the way it's traditionally done can have code quality problems, that isn't something which is inherent in the language. I've had great results working with Laravel. At least for my use case, it's basically just been a better Rails that happens to be in PHP. It's also compatible with HHVM and Hack, which can be useful depending on your needs.
Meh, all the dynamic languages are basically the same. They're all basically things that manpipulate strings and C pointers. For perl/python/ruby/js here's what I'd sort of recommend:
* Pick from your team's strength, unless:
* Lots of turnkey logic, code quality and debug tools are not a priority, and you want to be able to hire fast and cheap: PHP.
* Lots of turnkey logic, per-performance isn't a problem and you want some higher order programming capability: Ruby.
* You want to manage a java-like large team for not so trivial logic, and you prioritise uniformity over expressivity. Python. Also python is a good environment for academic work as it helps the academic programmers not shoot themselves in the foot so much and academic code is a mess. Which is why python is such a good extension language for other tools.
* Async greenfield stuff where you don't need to worry about external libraries much: javascript. Also the only game in town for web front ends (plus its transpiling friends). Javascript is like a syntatically impoverished perl in this regard.
* You've got a whole bunch of mess in business logic and/or systems logic that you need to encapsulate, and you've got a small highly capable team who want to prioritise expressivity over uniformity. Perl excels here. So does python, but it'll make you do even more horrible things papering over the mess.
Regarding the last point, I believe if it reaches a tipping point perl 6 will be a good thing for async, multicore and parsing related stuff, and should be long-term productive and reduce the requirement for having as highly capable and a disciplined team that is really a requirement for non-trivial perl5 code bases.
Also perl5 is second to none for programming language back compat. I had a decent sized non-trivial project I'd written for internal (research) purposes, then neglected for several years. Then I had to look at the running code again. I'd been through several minor OS upgrades, moved to a completely different OS and gone through at least three major versions of perl. Aside from a couple of missing CPAN modules that I had forgotten about in the Makefile.PL, everything was fine out of the box.