

The dumbing-down of programming (1998) - silentbicycle
http://www.salon.com/21st/feature/1998/05/cov_12feature.html

======
mathgladiator
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.

------
wccrawford
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.

~~~
zeraholladay
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.

~~~
wccrawford
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.

~~~
zeraholladay
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.

------
JohnnyBrown
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).

~~~
1337p337
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.

~~~
davnola
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!

~~~
1337p337
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.

~~~
epochwolf
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.

------
ndaiger
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/>

------
1337p337
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.

------
dlnovell
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.

------
silentbicycle
And, part two: <http://www.salon.com/21st/feature/1998/05/13feature2.html>

------
russellallen
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.

~~~
silentbicycle
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>

~~~
russellallen
Maybe, but your link is about how increased hardware capacity has made life
easier. Which is true, but not the same.

~~~
silentbicycle
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.)

~~~
russellallen
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!

~~~
silentbicycle
Salute!

Also: For people reading the codebase, any place you recommend starting?

~~~
russellallen
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.

------
diN0bot
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).

------
tsotha
I missed the date initially and was thinking "Slackware? Whaaaa?"

------
zoudini
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?

~~~
icegreentea
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".

