The dumbing-down of programming (1998)
salon.com
salon.com
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.
Machines are not here to challenge us. They are created to make our lives easier. And that's what they do.
There's plenty of challenge out there for anyone who wants to find it. There's no need to keep everything difficult for those who want challenge.
Automated help is good, but who needs incompetent automated help?
$ make life easier
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.
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.
$ man life
if I have a problem.
$ man life
No manual entry for life
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!
> 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.
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.
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.)
Used a total of 4 times in the 2.3.10 codebase.
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.
Learn about servers. Writing a simple webserver really isn't hard, and it will teach you a lot about HTTP performance tuning.
It's called The Bug, and I'd recommend it much more than I would this Salon article.
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.
> We build our computers the way we build our cities -- over time, without a plan, on top of ruins.
See e.g. http://prog21.dadgum.com/29.html
What's your involvement with Self, PS? Brilliant language.
(Also, there is a LOT of good content on James Hague's blog. Highly recommended.)
Also: For people reading the codebase, any place you recommend starting?
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.
if programming was a single skill, being on team wouldn't be so awesome (and working with other programmers is definitely awesome).