6 ms·
The dumbing-down of programming (1998)
- silentbicycle 16y agoAnd, part two: http://www.salon.com/21st/feature/1998/05/13feature2.html http://www.salon.com/21st/feature/1998/05/13feature2.html
- wccrawford 16y agoThat 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.
- silentbicycle 16y agoWhat 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?
- sofuture 16y agoDid we read the same article? It wasn't about challenge nor was it a tirade against making things easy.
- zeraholladay 16y agoIt 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.
- Mithrandir 16y agoI always run $ man life if I have a problem.
- wazoox 16y ago$ man life No manual entry for life That's what I was afraid of.
- wccrawford 16y agoYou 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.
- zeraholladay 16y agoConsider 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.
- angrycoder 16y agoYou 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?
- ndaiger 16y agoThe 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/ http://www.amazon.com/Bug-Ellen-Ullman/dp/1400032350/
- zoudini 16y agoI've always wondered, if we ever reach the Singularity or a cliched Minority Report like reality, what would the layers of software look like?
- icegreentea 16y agoLayers 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 16y ago[deleted]
- diN0bot 16y agoit'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).
- mathgladiator 16y agoI 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.
- russellallen 16y agoI 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.
- silentbicycle 16y agoWhen 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 http://prog21.dadgum.com/29.html
- russellallen 16y agoMaybe, but your link is about how increased hardware capacity has made life easier. Which is true, but not the same.
- silentbicycle 16y agoYou'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.)
- russellallen 16y agoI'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!
- silentbicycle 16y agoSalute! Also: For people reading the codebase, any place you recommend starting?
- 16y ago
- JohnnyBrown 16y agoI 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).
- silentbicycle 16y agoThe 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.
- 1337p337 16y agoAnd 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.
- jpr 16y agoIt seems that Rails is doing something horribly wrong. There should be no reason to use code-generating or evaluate strings in a dynamic language.
- 1337p337 16y agoI (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.)
- 1337p337 16y agoI 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.
- tsotha 16y agoI missed the date initially and was thinking "Slackware? Whaaaa?"
- dlnovell 16y agoI 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.