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
did were shrugging and throwing tantrums like WHY THE FUCK DIDN'T YOU FUCKING LIKE IT TEN YEARS AGO?
IMHO, all these things went down to the bottom of history because things like these:
> Anon the intern needs to be able to open up Programmingâ„¢ and click 'New Web Form'
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 right cruft becomes significantly smaller than the time spent manually cleaning up after a smart tool.
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?
And at the risk of sounding like an elitist schmuck who rants about how things were back in his day, maybe 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 use 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.
And then there are things that are far harder to solve than they originally seem:
> I want to just type 'email' and see a list of functions and libraries relating to email.
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. Especially 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 close to the one he needs, because the IDE (like Anon himself) thinks Anon is trying to solve another problem.
There is, on the other hand, a lot more truth in this:
> 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.
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.
This is wicked cool: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1165&context=hcii . However, I also find myself thinking that the very fact that we need 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 why 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.
If I select a function from autocomplete, its dependencies should be automatically added to the project without any fuss.
For the point, that that post makes, this one is at least available if you use IntelliJ with Java or Scala.
Every file in a large project starts with dozens of redundant import lines. Why don't we have imports go the way of the inferred type?
What if tomorrow I add another library which implement his own foo()? (this is trickier)
When I read the code, what is foo()? (here the IDE may be smart and show me the right documentation).
All that said, I feel that the pythonic "Explicit is better than implicit" is better.
It's also true that when I see a file whose first 30 lines are used for including dependencies it doesn't sound right.
The problem lies with the fact that we use text to store structured data. If we were to save source code as binaries we could have the source code in a "file|object|item" and the dependencies in another item, linked to the source code (I'm not advocating this, source code in text files has many advantages, but also his drawbacks).
This has the neat side-effect that ids are globally unique so you can figure out what libraries you need to pull down just by looking up ids in your package repository.
That and the odd namespace clash that a compiler can't really resolve, but that is more due to implementation and system issues, not programming proper.