Yes, absolutely, let's take the "mystique" out of coding.
Right now, I have software (written in Forth - because it's the ultimate language for DSL, I found), deployed for 6.000 patients that we use everyday, to churn out patient's prescriptions. In our public health system, patients get their free medicines for diabetes, hypertension, depression, hypothyroidism, asthma, etc (whatever is the "continuous" medicines the municipality pays for). They have a legal right to get them renovated. Doctors used to go crazy with renovating them by hand. It's no fun when you care for, say, 900 people with hypertension. Of course, this is not the U.S. (it's Brazil).
Why did I write in in Forth? Because it was so fast to write a mini-DSL. I could not even believe it. I got that for *free*, in Forth - I got a free "readline", a free parser, strings whatever size they come (Forth strings are better and safer than C's), a database for free, etc. Concatenative stack-oriented programming is very restrictive. If your stack is wrong, the Forth compilers will bork right back at you. Since you' re doing concatenative programming, it's basically like a functional programming paradigm: you fit Lego blocks of code on other Lego blocks. Since you must do a lot of stack-testing, unit testing is immediate and obligatory, instead of a "practice" or "discipline" that you must incorporate to your workflow. If your stack ain't right, you break things now, so you know pretty soon if your code is ok or not. And keeping track of the stack might become burdensome, so you automatically start refactoring code (everybody's heard of Leo Brodie's refactoring masterpiece Thinking Forth, right?). You keep it simple. Basically, everything I read about how awesome Forth is, is true. As a matter of fact, I first got turned on to Forth when I saw a guy who'd written his very own CAD software (which blew my mind). When I asked him what language he'd written it in, he said: "Forth, because you can go from very low level (in his case - graphic primitives directly on the screen - no OpenGL, etc.) to a very abstract high level (Forth words that concatenate in a DSL)". I understand now that it wasn't so much that he was a genius (although he did have a degree from MIT...), but that he got the tools he needed (after all, you can get projective geometry "recipes" from a book).
Initially, the software was in C (C and Forth can be deployed to any old trashy piece of hardware around, right? - this might actually be relevant, if you're financially constrained - which I don't expect anyone form a rich country to really understand), but then pointer indirection, parsing, data structures, file I/O in C, etc., just bored me out of my mind. Obviously, I understand people feel smart when they can write C-oid code with pointers to pointers but I found that to be stupid. This has to do with the fact that I met better languages (Common Lisp, for instance), before I met C, so I stand largely nonplused whenever I see someone claiming to perform advanced magic in, say, Java. Really? Java is a broken Smalltalk semantics with a C-oid syntax.
Having no strings attached (meaning: no managers breathing down my neck, me being a physician), I decided to scratch the C code and just go all Forth (because I actually think that Forth, Smalltalk, ML(s) and Lisp(s) are the best languages out there). I used win32forth because it's public-domain, but the price for Forth compilers are very cheap (and just go look at the benchmarks...) and I might change to a proprietary Forth (better documentation would be the reason, and support). The code is ANS-Forth, 99% (and the part that isn't is easily changed) - by which I mean "portable".
Although we're already deploying it in Real Life, I keep perfecting it (addicted to Forth). Right now, I',m fiddling with the Forth black magic - turn the compiler on, or off, etc. Stuff you really can't do in C/C++/Java without a huge amount of tools. Only in Lisp. But Forth is kinda of easier than Lisp, actually, I found (the model is simpler - throw things on the stack, then consume the stack). As a matter of fact, I barely know Forth. I recommend reading the tutorials out there and the Forth books from Forth, Inc (Forth Application Techniques and the Forth Programmer's Reference).
Forth (and other "weird" languages) force you to re-think your problems. Do you really need object-orientation, string-based stuff, regexes, etc? Maybe not... Maybe you have a hammer, and you think everything is a nail...Maybe u r doin' it rong.
I taught the doctors to alter key files in Forth. Like "in the old days", they don't *exactly* know they're coding. It doesn't matter *at all*. All they care is that they can customize the software, and feed the database with the mini-language I developed that's so intuitive for them. Actually, I did it for me, but then other colleagues became interested. I had to do this, since the contract for the EMR hasn't come through yet ;-) When the purchased software finally arrives, it'll probably suck compared to my little Forthy thing - it'll probably have no DSL for prescriptions. Printing is delegated to more competent software, such as office packages.
Here's an example of the DSL we use. For doctors, it's very intuitive - as a matter of fact, I just show them snippets of code in the database, like the one bellow, and they immediately get it:
UC6
hctz25 30cp 1cpm
simva20 30cp 1cpn
L\D
This expands to (may seem strange, I don't know how doctors prescribe in the US):
[ Patient's name goes here]
Internal use - continuous - 6 months
Hydrochlorothiazide 25mg ----------- 30 pills
Take 1 (one) pill VO* 1x/morning
Simvastatin 20mg -------------------- 30 pills
Take 1 (one) pill VO* at night (before bed)
[ Town, date ]
*[VO = per oris. i.e, orally]
So, if I, a physician, can code in Forth to solve my problem, why shouldn'teveryone? I think everybody should learn to code, as it helps people with real problems. That's what computers are for: for coding .