The dumbing-down of programming (1998)(salon.com)
salon.com
The dumbing-down of programming (1998)
http://www.salon.com/21st/feature/1998/05/cov_12feature.html
11 comments
That article should have been left back in 1998.
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.
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.
Did we read the same article? It wasn't about challenge nor was it a tirade against making things easy.
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?
Automated help is good, but who needs incompetent automated help?
It doesn't work that way (inspire by Voltaire):
$ 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.
$ 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.
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.
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 always run
$ man life
if I have a problem.
$ man life
if I have a problem.
$ man life
No manual entry for life
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?
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!
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 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.
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.
It seems that Rails is doing something horribly wrong. There should be no reason to use code-generating or evaluate strings in a dynamic language.
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.)
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.)
> copious abuse of BasicObject
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.
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.
> Used a total of 4 times in the 2.3.10 codebase.
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.
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.
The problem is when handling all those lower layers gets brushed off as "magic", rather than just recognized as a big pile of tedious details.
Learn about servers. Writing a simple webserver really isn't hard, and it will teach you a lot about HTTP performance tuning.
Learn about servers. Writing a simple webserver really isn't hard, and it will teach you a lot about HTTP performance tuning.
The author wrote the only novel I'm aware of that really illustrates what it's like to debug software.
It's called The Bug, and I'd recommend it much more than I would this Salon article.
http://www.amazon.com/Bug-Ellen-Ullman/dp/1400032350/
It's called The Bug, and I'd recommend it much more than I would this Salon article.
http://www.amazon.com/Bug-Ellen-Ullman/dp/1400032350/
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.
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 really love the last line and it's equally valid for how a lot of enterprise software is built.
> We build our computers the way we build our cities -- over time, without a plan, on top of ruins.
> We build our computers the way we build our cities -- over time, without a plan, on top of ruins.
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.
When wizards, etc. actually work, it often just means we can move on to the next interesting problem.
See e.g. http://prog21.dadgum.com/29.html
See e.g. http://prog21.dadgum.com/29.html
Maybe, but your link is about how increased hardware capacity has made life easier. Which is true, but not the same.
You're right, and quite quick to respond. I'll wait to post until I'm done editing next time. :)
What's your involvement with Self, PS? Brilliant language.
(Also, there is a LOT of good content on James Hague's blog. Highly recommended.)
What's your involvement with Self, PS? Brilliant language.
(Also, there is a LOT of good content on James Hague's blog. Highly recommended.)
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!
Salute!
Also: For people reading the codebase, any place you recommend starting?
Also: For people reading the codebase, any place you recommend starting?
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.
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).
if programming was a single skill, being on team wouldn't be so awesome (and working with other programmers is definitely awesome).
I missed the date initially and was thinking "Slackware? Whaaaa?"
I've always wondered, if we ever reach the Singularity or a cliched Minority Report like reality, what would the layers of software look like?
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".
[deleted]
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.