I think the "dumbing-down of programming" is the sign of a maturing discipline where the generation before us did a lot of good work to enable more people to enter the field at a fresh level of difficulty.
That being said, there is typically a fear that people hold that secrets used to build the present will be lost to time. I had this fear because I've spent a lot of time educating myself in how to do everything from how to build a CPU to how to build user interfaces.
The key to not worrying about the fear is as follows.
There were always be artists that preserve the beauty of old school.
There will always be people that love to know history and study the engineering efforts involved; this will create a labor pool. (people build catapults due to their beauty, people will probably build x64 emulators in the future quantum computer just for fun... Or in the future minecraft variation)
Even if these people didn't exist, we have books and smart people for the occasion if the problems arise again.
What about when systems try so hard to make our lives easier that they actually get in the way? And, when people become so used to it that they don't see when things would be straightforward without that assistance?
Automated help is good, but who needs incompetent automated help?
You realize you rallying against an article that is primarily about installing Linux and the joys of figuring things out. You realize you are on a site called hacker news right?
Your life has been made easier: 70,500,000,000 dollars has been deposited into your bank account.
"There's plenty of challenge for anyone who wants to find it."
There are problems that haven't been solved yet and problems that can't be solved. Most problems can't be solved, since the majority of (our) problems are psychological (i.e. there are no axioms, assumptions, systems, etc to define this class of problem) -- the rest are impossible.
The problems that haven't yet been solved are actually interesting tho. The knowledge systems for these classes of problems are heuristic; i.e. a process of discovery and experience. The intention is often not to keep everything difficult but to keep everything knowable, which is contrary to the "don't make me think" principle of design.
You can always re-solve a problem, if you want that challenge. The fact that someone else has solved it shouldn't stop you, if your goal is to have a challenge.
Consider the difference between math and engineering (at the undergrad level). Math majors learn to solve solved problems, since the solutions are instructive; that is, they could accept a solution as truth but proving it is true has a greater value. However, engineers need to accept a lot of mathematical truths since the occupation applies these truths.
Either way, both of these systems are instructive. You should be able to reverse a process and discover its discrete parts, if that's your goal.
I feel this way sometimes about using Rails. It's not the same thing as visual studio but there is a nagging feeling of dependence that goes along with writing a webapp without knowing how a server works, why all the generated code looks like it does, or even knowing what TCP/IP is. ( I know the IP stands for Internet Protocol).
And if you decide to delve into the details of Rails' implementation, you're often greeted with 100-line string evals and incomprehensible hacks. I doubt this effect was the intention, but it made me cargo-cult a lot when I was doing Rails full-time because I was afraid of finding out what was really going on. I was technically writing Ruby, but Rails never felt like Ruby to me.
I don't recognise the current Rails codebase from this comment.
There's certainly nothing incomprehensible about it if you grok common Ruby metaprogramming idioms. I wish the idea of "Ruby magic" would die in flames!
It's not that I don't understand "Ruby magic" or "metaprogramming"; it's that the Rails codebase is spaghetti.
> I wish the idea of "Ruby magic" would die in flames!
Me, too. I think Giles Bowkett had an article on this; it was the only article on his blog that I liked. Superstitions and fear about Ruby's higher-level features remind me of people that are afraid of macros in Lisp or function pointers in C.
I found this to be true years ago. Rails 1.2 had really gnarly stack traces. I have yet to see Rails 3 throw up in such creative ways.
The current codebase is far from the spaghetti you claim. Active Record is probably the closest to it but it's been greatly changed internally from the original.
I (at the risk of getting horribly off-topic) attribute this to Rails' origins, namely a team that moved to Ruby from PHP, and brought too much PHP with them. Not to take a position on PHP itself, but it's a very different language, and what makes sense in PHP can be very ugly in Ruby.
Huge, ugly string evals (just one of the horrors lurking in the Rails codebase; their copious abuse of BasicObject comes to mind) are bad enough, but the code-generating is responsible for most Rails applications, too. The inherent ugliness of generating application code from templates in Ruby is one thing, but it would be ugly in any object-oriented language: you use inheritance, and defer to the superclass (or, in languages that have mixins or prototypical inheritance, you add a class/exemplar to defer to). You don't take the behavior you expect these objects to exhibit, stuff it into a template, and write a script that fills in the blanks and dumps the result into a file. It's automated copy-paste, an optimized version of something that was a bad idea to begin with.
(I've heard good things about Rails 3.0, but I've not looked. My heart has been broken too many times, and I don't see Yehuda Katz as substantially more insightful than DHH.)
As for code-generation, I think you misunderstand their role in Rails. Can I ask you, in your editor of choice do you have any kind of snippet/template functionality (e.g. yas for emacs)? Same deal.
The number of times the string "BasicObject" or "BlankSlate" shows up in the codebase is not representative of the times an instance of a class that inherits from this class shows up in data I am passing around. And the number of times an instance shows up is not representative of the pain I have gone through with these misapplied patterns. Between these, HashWithIndifferentAccess, the liberal use of :nodoc: tags (to the non-Rubyist: these--distressingly--suppress the API documentation generator from generating documentation for a given piece of code), and other "quirks" of the framework, I have had a hell of a time debugging in Rails.[1]
> I think you misunderstand their role in Rails.
I seriously doubt that, but I'm more than willing to hear what they are if not essentially copypasta generated for developers to tweak. It's a case where inheritance and mixins would have done nicely and resulted in cleaner code. If you don't believe me, try taking one of these generated controllers, stuffing it into lib/, renaming it appropriately ("GenericController", for example), and having most of your controllers inherit from it instead of ActionController::Base directly. The result is a lot of mostly empty controllers where behavior that varies from the GenericController is easy to spot, because it's the only behavior that needs to be specified.
> in your editor of choice do you have any kind of snippet/template functionality
As bloated as my favorite editor is, I am sure there is some functionality like that, but I don't know where it is or how to use it. Not that I don't generate code ever; it's a fine technique for a dirty hack, a script that needs to just be done and cleanliness be damned. It is not how I would engineer an application that I expected to have to maintain, and it's undesirable for that to be the main pattern of development in a framework.
1. Please do not think that this is because I am new to Ruby or to Rails. I have been doing Ruby professionally since before Rails was released, and spent a few years doing Rails almost exclusively, starting before Mongrel came out and our choices were WEBrick or FastCGI. I still occasionally have to interact with Rails codebases, although I have been trying to avoid it for a long time.
I love this article. I understand that this mode of interaction is sort of an outlier, but I have come to personally resent being prevented from doing anything by a computer.
A lot of friends of mine ridicule my choice of Linux distribution and tell me I'm crazy for saying that it's "easier", but I find that a stripped-down version means less arguing with the machine, and far less than one of the two more popular desktop OSs. I was eventually driven to doing a Linux-from-scratch install when, one night at 4 a.m., my pre-packaged Linux distribution started doing something, and I didn't (at the time) know what it was doing or why. I've moved back to a distribution, but one that has the same philosophy of doing exactly and only what I tell it to.
I don't know why it's so uncommon for coders to feel this way; most of my friends and coworkers think I ought to just use OSX, but I don't want to have to convince a computer to do what I told it, I want it to just do what I told it. My usual explanation for my peculiar taste in interfaces to the computer is that "I was not put on this earth to be sassed by machines." I now have a well-written article to point them to.
I wish we could dumb down programming! That would mean that we knew how to program easily and safely... The problem with wizards, code generators etc isn't that they dumb down programming but that they fail to dumb down programming.
I'm Self's general maintainer, facilitator, janitor etc. It's a great language but once Sun dumped it, it suffered a little from lack of tender loving care. But we're fixing that!
The codebase for the C++ based VM is on Github. I find it scary :)
The actual Self code is best read inside Self: the Self code on Github is sort of human readable like html is sort of human readable: you can do it but it's easier to use a web browser.
There's a handbook/manual and a tutorial on the http://selflanguage.org site. I'd recommend starting with them.
it's hard to pin down what "programming" is. there are a variety of things that "programmers" must do, from designing algorithms and system abstractions, to writing implementations in quirky languages under real-world constraints.
if programming was a single skill, being on team wouldn't be so awesome (and working with other programmers is definitely awesome).
Layers and layers of compatibility layers, reaching back to IBM system/360 mainframes, with function calls commented "this works for now, but Bob should take a look at this whenever he's free, it seems there might be some problems with edge cases".
That being said, there is typically a fear that people hold that secrets used to build the present will be lost to time. I had this fear because I've spent a lot of time educating myself in how to do everything from how to build a CPU to how to build user interfaces.
The key to not worrying about the fear is as follows.
There were always be artists that preserve the beauty of old school.
There will always be people that love to know history and study the engineering efforts involved; this will create a labor pool. (people build catapults due to their beauty, people will probably build x64 emulators in the future quantum computer just for fun... Or in the future minecraft variation)
Even if these people didn't exist, we have books and smart people for the occasion if the problems arise again.