Visual Studio Magazine - Guest Opinion - Save the Hobbyist Programmer
An older, but interesting article that points to an important problem: hobby programmers are increasingly being excluded from creating small hacks and simple solutions by ever more complex system interfaces and constant changes to APIs and programming tools in the Windows world. And it's not just the Windows world that suffers from this. Linux and OS X suffer from it in part as well.
Of course, there are still small utilities with simple programming capabilities. Or scripting languages that are easy to learn and use - for example, Python. But that's not really a solution for these tinkerers. What was once the omnipresent Basic for hobby tinkerers, or for example the - admittedly problematic - language in dBase, is missing today. Hardly any programming environment that doesn't come with an object-oriented approach. Hardly any solution approaches that don't try to be a general development environment for complete programs right away.
There are still some nice exceptions - FileMaker on the Mac still tries to appeal to the hobby hacker. But it's still true: the simple entry points are becoming fewer.
Even AppleScript on the Mac has become so complex and bloated in the meantime that it's hardly possible for a newcomer to just get started with it. Some corners of AppleScript are obscure and complicated even for old programming veterans like me. And of course, while there are many great integration possibilities for all these scripting languages, the documentation for precisely these parts is downright terrible.
To stick with the AppleScript example: while there are application dictionaries that document an application's AppleScript capabilities, nearly all the descriptions I've read in them have assumed that the user already has complete and extensive knowledge of AppleScript and AppleScript structures (what are objects in AppleScript, how do you work with containers, etc.). Although these dictionaries could serve as a starting point for the hobby programmer, their creators (professional programmers in software companies) design them in such a way that often even they themselves can make sense of them.
It's similar in the Linux world. TCL was once the standard scripting language for simple entry with simple structure, an almost primitive extension interface, and the ability for even non-programmers to quickly arrive at solutions. Today, TCL in the standard distribution (which is then nicely called "Batteries Included" - only unfortunately the understandable instructions are missing) already consists of mountains of packages, many of which deal with metaŃŹĐ·Ń‹age aspects (e.g., incrTCL and the widget libraries built on it and on TK - good grief, in just this brief mention of the content there are more incomprehensible words for a beginner than filler words), which a beginner will never understand.
And I don't need to go into the dismal situation under Windows with the scripting host and the OLE Automation interfaces (or whatever they're called these days) - anyone who has experienced a version change of an application and had to completely rewrite their entire solution due to a total change in the scripting model of, say, Access, knows what I'm talking about.
Ultimately, we (we == professional programmers) are taking a piece of freedom away from end users - the freedom to tinker around and yes, also the freedom to shoot themselves in the foot. And I think that precisely in the world of free software, programmers should start spending some thoughts on this again. It's nice that almost every larger program embeds some scripting language. But what's not so nice is that hardly any of these embeddings have decent documentation of their capabilities, and only the most primitive examples and complete solutions for very complex applications are available as starting points for learning. Hobby programmers in particular learn most easily by reading existing tools. And yes, I'm not exactly a good example myself, because the Python Desktop Server has a number of extensibilities that are also intended for end users - but I also wrote far too little documentation for it. Somehow a shame, because that's how many projects become incestuous affairs, because the actual end users are left out. No, I don't have a real solution - because especially with free projects, documentation creation is often an annoying and unpopular part of the project and is therefore treated like a stepchild. Besides, most programmers aren't able to create generally understandable documentation anyway. But maybe that's also an opportunity for projects that try to increase activity in large open source community projects that have had lower participation so far. debian-women comes to mind spontaneously (since Jutta is currently working on it). Because greater participation by women would certainly also be helpful for documentation and information that doesn't necessarily require a fully trained master hacker. After all, not everyone has the desire to spend their entire life learning new APIs and tools ... Here's the original article.
