I was just starting out as a programmer (professionally) myself, and once I was finished doing whatever I was sent to their office to accomplish, they would pull me to the side and show me their applications and pick my brain about ideas and ways to improve them or if it made sense to try a "more serious" programming language.
I was always completely floored by how much they had accomplished with every-day tools that people generally slog through out of necessity. Some of these guys were selling their applications for a solid slice of monthly income and support as well. "Normal" people building real, and truly useful applications with real domain knowledge are an absolute inspiration for me.
It reminds me a lot of web development, actually. Because everyone in their potential client-base had Excel, just as we all have browsers now. So building in Excel made perfect sense. I see the same thing happen with Wordpress or Shopify these days. Building these amazing applications that extend far beyond the purpose of the underlying application.
My early interactions with those people them helped me immensely when I went on my own full time, where I would walk into a small business and see this complicated app built upon - something - by an overworked "tech person of the office", who was clearly a bit sad that their creation was about to be replaced by some stranger. That was the person I was going to get to know and work with daily to get the application right, and I made sure they were part of every conversation.
Most of my projects are greenfield these days, but I still hold those programmers - in the truest sense - in the utmost highest regard. I still love to discuss their projects with them in the rare cases that I get the opportunity.
I think John Ohno does a good job of articulating what's so great about these tools in his article "Big and small computing" [0].
[0] https://hackernoon.com/big-and-small-computing-73dc49901b9a
Rarely ever do I find myself programing for the sake of programming, it's always to serve some goal, to make some thing, fix some problem. If I write the worst code, in the worst way, and it still makes the light flash or the robot arm move, etc, then i succeeded.
I make heavy usage of the MIT Android app maker thing in my arduino and esp32 projects, and I'll be the first to admit that I use it so heavily because I have some minimal grasp of it and I've wrapped my head around most of its paradigms.
I'll admit that because I've only got a hammer, every problem is a nail, but taking away my hammer because im using it wrong just means I cant build anything.
Also, if people can build computers in Minecraft that don't achieve anything and get praise for it, people who solve real problems with creative (ab)use of something really should get kudos, too. You're not even using anything "wrong".
Actually, the perceived need for "dumb" DSLs is sprung from the same misconceptions as mentioned in the article and the end result is inevitably that simple problems are made somewhat simpler and complex problems turn into impossible problems.
A proper DSL extension in an unobtrusive host language is another thing but also hard to find. If a Lisp syntax is acceptable then that's the canonical example.
I don't want to get depressed overe all misconcieved excuses for test automation languages, process automation, configuration templating systems, etc, so I'll just stop here.
With regard to LaTeX or HTML, you could even argue that their goals could be better accomplished with some sort of graphical interface, which sounds a lot like… visual programming!
It should be possible for implementation language programmers to create new primitives, that visual language programmers can easily use without learning the implementation language.
And that extension interface should be part of the visual programming language from day one, good enough for the visual language to use itself for most of its built-in primitives, not an afterthought nailed onto the side.
A good professional programmer will feel (and in fact be) constrained and slower by a VPL. That’s frustrating and likely a misuse of resources. I just think the author missed the point that VPLs generally aren’t for “us”, they are for people who something else for a living.
It makes sense to use a visual programming language to create basic CRUD applications. A central task list with fields that are specific to the business process can go a long way in improving operational efficiency in a business unit. Beats an excel spreadsheet.
You cannot implement a system for every idea because you will not have enough developers and you will waste time implementing ideas that sound good but are useless. Visual Programming applications like Access allow less technical users to implement their ideas. Some of these ideas will go nowhere. This is fine because you will not have wasted developer resources. Some of these Access applications will solve genuine business problems. It may be difficult to decipher them but it is no more difficult than trying to figure out what users want. At least in this instance, you have an application you can test against.
I also understand why people dislike this idea. In many cases, it's really hard to extend something created by non-professional-programmers. I'm one of the founders of Luna ( http://luna-lang.org ), which is a visual programming language blending the boundaries between visual data-flow designing and conventional textual programming.
As a contrast to the mentioned article in this topic, I'd encourage people to also read our blog post about why visual programming could actually be very useful: https://medium.com/@luna_language/luna-the-visual-way-to-cre...
In my career I’ve often been asked to rewrite Access DBs, InfoPath forms, or SharePoint sites developed by amateurs into something more usable. My early reactions where along the lines of “what insane person tried to do this in Access.” I realized at some point that was the wrong approach in my thinking. These systems are working software delivering value. I now say “wow, congrats on doing so much on your own. Let me help you take this further.”