PainOfProgramming
ThoughtStorms Wiki
Increasingly, I think this is one of the biggest pains of programming.
Why are all programming languages difficult to configure with its appropriate environment?
Because that's actually one of the hard problems.
There are two conflicting requirements :
1) in order for the program to do real work, it needs to be able to access the machine's resources : memory, disk, mouse and keyboard, networking, sound-card, USB, GPS etc. etc.
2) in order to be relatively platform independent, (which allows programmers to be reuse their knowledge across platforms and operating systems etc.), the language has to be fairly self-contained and loosely coupled to the platform.
To satisfy both requirements you need some kind of mapping between the resources represented virtually within the programing language, and the underlying machine and operating system.
And that mapping is done via a configuration which is external to the main program. (It has to be external, if the program could see the machine resources directly it wouldn't be portable between different platforms.)
Because the configuration is external it's not very visible to the programmer. It's necessarily outside the world of the programming language, and usually outside the programmer's comfort zone. And, naturally, you can't really write portable tooling to help manage it. So tooling for managing and debugging this configuration is usually somewhat inferior to other libraries and resources (like editors).
BTW : this is a universal principle, equally applicable for "virtual machine" languages like Java, and for compiled languages like C that just have a portable standard library.
The only languages that are "plug'n'play" are languages which don't have the two requirements.
Either they're tied to a single platform : Visual Basic on Windows or in Office. Perhaps Objective-C for iOS.
Or they're languages that don't offer much access to the underlying platform : Javascript in the browser. Perhaps Smalltalk most of the time. And other languages that stick to their "toy" environments.
The moment you want portability as well as access to the full range of machine resources, you are stuck with having a mapping layer that needs to be configured independently of your actual program, using obscure and non-standard tools and knowledge.
Previously
Ken Arnold says "Programmers are People" (http://www.artima.com/weblogs/viewpost.jsp?thread=4414) and we should see programming languages as user interfaces to the deeper model.
I totally agree. And from a usability perspective, the tools and languages we have suck!
However, I'm not sure I agree with the human factors principles he highlights or the conclusions he draws from them. Sounds like this is going to lead to the exhaustive clarity I mentioned in DocumentationIsImportant.
DanBricklin talks about what programming is and why it's difficult : http://www.bricklin.com/wontprogram.htm
Compare: AnEasyInterface
See also :