Having programmed in not less than four different assembly languages, FORTRAN II and IV, BASIC (at least 8 different flavors), ALGOL, PASCAL, PL/1, Ada, and a couple of scripting languages, I have to say that I have seen a bunch of ways to get from point A to point B in programming. It is my experience that FROM THE OUTSIDE, no end-user will probably have any clue as to which language was used to make the product as long as it was well debugged before release.
You can achieve the same end result in any compiled (or assembled) language as in any other language. The differences are solely internal. Sure, this one can do true inheritance, polymorphism, abstraction, reflection, ... you name it. And that one can't do ANY of them. All it means is said in the old song: "You take the high road and I'll take the low road and I'll reach Loch Lomond before you."
We talk about features in a language. Or in a programming / development environment. Or an Integrated Development Environment. Or whatever you are selling these days. If you have a lot of stuff in your tool kit AND it applies, you'll work faster and be more productive. If you have to invent the tools to make the tools, you'll take a lot of time. If you have the tools but have to customize them first for this job, you are somewhere in the middle of the two extremes. But what did that difference do to/for you?
The difference probably changed your speed of coding and composition, which changes your flow time which changes your costs. But here is where it stops making a difference.
For any project worth its development cost, the boss already knows what will be used. If this boss is worth a toot, s/he will have already obtained a work-flow estimate and will know how much the project will cost. So if the project got approved using language XYZ, every last one of the "language features" arguments was just made moot because they were folded into an approved project that assumed their existence. And it has been that way since project-oriented programming was a "thing" to discuss.
An author named Barry K Boehm wrote some books on project management and software project engineering from an economic viewpoint. In a research-based work from the 1960s or 1970s using data from not less than 60 different projects, he estimated that language feature differences contributed 10% to at most 15% of the cost of a project and maybe less in some cases. The far more important language factor was whether the programmers were familiar with the language being used, whatever it was.
The design phase, testing phase, and documentation phases were all far more expensive because testing and documentation were labor intensive but not language dependent. Design was expensive because it was a "choke point" on project flow that idled workers waiting for approved designs. And it was not language-dependent, either. Only the coding/implementation phase was language dependent.
OK, granted, when you are a one-man project team, a LOT of that stuff is off-the-cuff done catch-as-catch-can (or not at all). Documentation is often scrimped upon in that case. Testing is limited due to limited imagination of what your end-users will do to the project to break it. Design is often shot from the hip. But EVERY ONE of those phases has nothing to do with what language you used and what language features you used.
The referenced article makes it clear if you read through it: Bad programming shouldn't be laid on VBA, it goes strictly to bad programmers.
And regarding the "corrupted minds" quote: As important a person as Dijkstra was, I would have told him to his face that his comments about corrupting the mind of the programmer were based on narrow modes of thought. He and Nicklaus Wirth condemned GOTO statements and a few other things. But those condemnations on purely theoretical grounds ignore the fact that most projects don't operate in a theoretically pure environment. Insensitivity to environmental factors was one of the things that Barry Boehm listed as being MORE important than language features in terms of final program cost.
In other words, their condemnation was based on looking purely at the mathematical theory of the project but not about the financial reality of the project. Tunnel vision. Folks who worry about whether a language has feature X or Y or Z? Dealing with tunnel vision.
I must have lucked out in that regard. What do you mean by "Pearl's"? I'm not following. Like PHP code snippets? Sort of like Javascript fiddles?
