in a recent blog entry where i wrote about successful open source code bases from the perspective of development (not usage; you can have god-awful code but very happy users, and vice versa), i just knew someone would say that $PET_LANGUAGE was the solution. in this case, it was a fellow named jonas and the pet language was python (who i assume hasn't read the bittorrent code).
like any tool, the quality and appropriateness of the tool impacts the quality of the product. writing large desktop libs and apps in C is really very silly in this day and age. writing apps in C++ is a lot better but can still be challenging, which is one reason Qt is such a god send (it makes using C++ really quite nice). and so we have languages like python, ruby, java and c# (plus 18 million other ones) that provide a more abstracted view of the landscape. for instance, often they won't make you (or, for that matter, allow you to) deal with memory management.
however, as the millions of horridly written visual basic apps out there attest to, giving people an easy language does not guarantee good code. not even enforcing white space usage like i'm a 3 year old who needs hand holding (yeah, i dislike that "feature" in python) is enough. because good code comes less from syntax and more from design and clarity of purpose.
a friend of mine was asked to take a look at a web app written in a modern high level language recently (no, not php) and was aghast to discover that it consisted of over 1,700 files. now this app is not that complex. i could maybe understand 100 files with a few hundred lines of code each for this particular app ... but ... 1,700?! holy crap batman!
so while it's easier (and therefore more likely) to fug things up with a harder to use tool (e.g. C) or a poorly chosen tool for the job (e.g. trying to write a web browser in bash script), having a nice tool to work with does not save the user from poor practice on the part of the craftsman.
(p.s. i'm also a proponent of moving to higher level languages for application development. but not because it means more easily maintained code. because it means fewer LOC, fewer opportunities for implementation errors, quicker devel turn around due to not having a compile/link stage and makes distribution easier as there is no platform-specific end product)