Pain we forgot
I also wish that programming were a lot different today than it was when I started learning it. That being said, a lot of this article's points are things I've heard before. They led to the development of Visual Basic & co., mostly by people who had no contact with the Smalltalk and Lisp environment in the 80s, while people who <i>did</i> were shrugging and throwing tantrums like WHY THE FUCK DIDN'T YOU FUCKING LIKE IT TEN YEARS AGO?<p>IMHO, all these things went down to the bottom of history because things like these:<p>> Anon the intern needs to be able to open up Programmingâ„¢ and click 'New Web Form'<p>are adequate for people who usually don't program, and extremely inadequate for people who usually do. Generally, and for good reasons, programmers will dislike a tool that hides implementation details for ease of operation. Past a certain level of complexity, the time spent manually doing the <i>right</i> cruft becomes significantly smaller than the time spent manually cleaning up after a smart tool.<p>I sympathize with Anon the intern, but perhaps he should rethink his expectations about complexity; if discoverability is a problem, perhaps he could switch to something that's better documented?<p>And at the risk of sounding like an elitist schmuck who rants about how things were back in his day, <i>maybe</i> he ought to start with something other than web programming. The size and complexity of that tech stack is humongous, to the extent that a large proportion of those who <i>use</i> it don't understand it more than two layers of abstraction down. Programs are also hard to pack and the environment that runs them is hard to setup. Because it involves at least two servers, possibly with several add-ons in order to allow the server-side languages to run, learning at least three languages (assuming server-side JS is an option), two of which (HTML and CSS) aren't quite being used for their original purpose. This is a beginner's nightmare and it has exactly nothing to do with the development tools.<p>And then there are things that are far harder to solve than they originally seem:<p>> I want to just type 'email' and see a list of functions and libraries relating to email.<p>Related how :-)? Should MIME-related functions, needed to reason about attachments, also come up here? HTML parsing/converting, in case you need to deal with HTML email? Information cluttering does nothing to alleviate the opposite problem of information breadth: if Anon the intern's problem is he doesn't know how to Google for libraries or how to make efficient use of documentation, an IDE that presents him with a gazillion of possibly related things won't help him. <i>Especially</i> when, like all beginning programmers, one of his main difficulties is correctly defining the problem he's working on which, in turn, makes it likely for the solutions presented by the IDE to be nowhere even <i>close</i> to the one he needs, because the IDE (like Anon himself) thinks Anon is trying to solve another problem.<p>There is, on the other hand, a lot more truth in this:<p>> Tightening the feedback loop between writing code and seeing the results reduces the damage caused by wrong assumptions, lightens the cognitive load of tracking what should be happening and helps build accurate mental models of the system.<p>I do think that the real resolution to this problem is writing simpler programs whose state is easier to track. On the other hand, programming tools today suck considerably at presenting program meaning. Things like evaluating what an expression comprising entirely of constants, or at least evaluating it based on the default values of the variables involved, are well within reach for today's tools, and yet programmers' calculators are still employed because 99% of the available IDEs couldn't evaluate ADDR_MASK & IO_SEGMENT if the life of every kid in Africa depended on it.<p>This is wicked cool: <a href="http://repository.cmu.edu/cgi/viewcontent.cgi?article=1165&context=hcii" rel="nofollow">http://repository.cmu.edu/cgi/viewcontent.cgi?article=1165&c...</a> . However, I also find myself thinking that the very fact that <i>we need</i> debuggers that are this smart is proof enough that we don't reason about our programs well enough. Except for the fringe case of having to quickly debug a (possibly horrible) codebase I haven't written, I'd much rather prefer being good enough a programmer to avoid the need for a debugger that can tell me <i>why</i> foo is not 8 despite the fact that I fucking said foo = 8 ten lines above, than being a programmer with good enough tools to help me when I'm stupid.