I am an older programmer who started his working life writing assembler on a 1MHz 8 bit microprocessor with 256 bytes of RAM.
At the other end of the technology scale recently I wrote a C#, WinForms, ASP.Net, Web Forms, WCF system creating and fronting an SQL Server databases with 500 million plus rows, which was used to manage email marketing campaigns of millions of emails per month.
People who needed the power and flexibility had a desktop app, others who only wanted to see “results on an iPad” had a web app and some people who needed to access to the raw data has WCF web REST services (APIs).
In the middle size wise, I wrote a full cycle EDI administration and quotation system for household and motor insurance using MS Access/VBA to provide a front end to an SQL Server database and a C++ quotation engine.
The important point of mentioning these systems is that they show that a lot can be achieved using a variety of tools and that I am happy to go with the ones that you want.
There is of course the caveat that the choice must make a reasonable amount of sense.
The assembler background is important as it teaches a programmer an awful lot about what has to go on to achieve anything even vaguely useful.
So when you write a high level command you have an understanding of the computing resources that you are asking for and it makes you think. Should I really use that library function or write some code that will achieve the same thing using far fewer resources but take a lot longer write?
The modern trend is the opposite off this, trust the programmers less and force them to uses design patterns, things like MVC (model/view/controllers), blindly follow SOLID principles and use javascript libraries (Angular, React etc) to form the basis of a system.
The problem with these patterns and libraries is that although they have sensible roots all to often they have taken good ideas too far.
It's only once you get deep into your project they you realise that they leave you restricted in how you develop your applications and often result in fragmented and difficult to maintain source code as well as being resource hungry.
Even worse than all of the above is that all to often they also leave the project owner stuck 10 years down the line when they are abandoned by their creators in favour of another new "best way" of doing things.
And whilst neither
PerBI or
IPL have been commercial successes they are complete standalone Visual C++ applications that exist in the market place. One where users can send in emails saying that
It doesn't work, please fix it.