lynx-dev lynx: off subject, part two:

lynx-dev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev lynx: off subject, part two:

From:	David Combs
Subject:	lynx-dev lynx: off subject, part two:
Date:	Thu, 14 May 1998 04:32:58 -0700 (PDT)

continued from prior email.

[1]Citibank Platinum SelectSM Card

[INLINE] [2][ISMAP]-[3][USEMAP]
. [INLINE]

[4]

Salon

A L S O__T O D A Y

[5][LINK]
[6]When you just can't stop clicking
By Lori Leibovich
"Caught in the Net" offers melodramatic tales from "Internet addicts"

- - - - - - - - - -

T A B L E__T A L K

Should companies be allowed to track their employees' Web surfing?
Weigh in on employee privacy vs. corporate rights in the Digital
Culture area of [7]Table Talk

- - - - - - - - - -

R E C E N T L Y

[8]The dumbing-down of programming
By Ellen Ullman
Part one: Rebelling against Microsoft and its wizards, an engineer
rediscovers the joys of difficult computing
(05/12/98)

[9]Maximum confusion
By Janelle Brown
On the Web, a typo throws frat boys and feminists onto each other's
turf
(05/08/98)

[10]Let's Get This Straight
By Scott Rosenberg
Now that they're sundered from the magazine, whither Wired's Web
sites?
(05/08/98)

[11]Wired nests with Condé Nast
By Lori Leibovich
But will the magazine's new owners dull its edge?
(05/08/98)

[12]Let's Get This Straight
By Scott Rosenberg
Gates tells the world that what's good for Microsoft is good for the
country
(05/07/98)

- - - - - - - - - -

BROWSE THE
[13]21ST FEATURE ARCHIVES

- - - - - - - - - -

The dumbing-down of programming
P A R T_T W O:
RETURNING TO THE SOURCE. ONCE KNOWLEDGE DISAPPEARS INTO CODE, HOW
DO WE RETRIEVE IT?

21st image

[EDITOR'S NOTE: This is the second of two parts. If you missed Part
One, you can find it [14]here.]

BY ELLEN ULLMAN
I used to pass by a large computer system with the feeling that it
represented the summed-up knowledge of human beings. It reassured me
to think of all those programs as a kind of library in which our
understanding of the world was recorded in intricate and exquisite
detail. I managed to hold onto this comforting belief even in the
face of 20 years in the programming business, where I learned from
the beginning what a hard time we programmers have in maintaining our
own code, let alone understanding programs written and modified over
years by untold numbers of other programmers. Programmers come and
go; the core group that once understood the issues has written its
code and moved on; new programmers have come, left their bit of
understanding in the code and moved on in turn. Eventually, no one
individual or group knows the full range of the problem behind the
program, the solutions we chose, the ones we rejected and why.

Over time, the only representation of the original knowledge becomes
the code itself, which by now is something we can run but not exactly
understand. It has become a process, something we can operate but no
longer rethink deeply. Even if you have the source code in front of
you, there are limits to what a human reader can absorb from
thousands of lines of text designed primarily to function, not to
convey meaning. When knowledge passes into code, it changes state;
like water turned to ice, it becomes a new thing, with new
properties. We use it; but in a human sense we no longer know it.

The [15]Year 2000 problem is an example on a vast scale of knowledge
disappearing into code. And the soon-to-fail national air-traffic
control system is but one stark instance of how computerized
expertise can be lost. In March, the New York Times reported that IBM
had told the Federal Aviation Administration that, come the
millennium, the existing system would stop functioning reliably.
IBM's advice was to completely replace the system because, they said,
there was "no one left who understands the inner workings of the host
computer."

No one left who understands. Air-traffic control systems,
bookkeeping, drafting, circuit design, spelling, differential
equations, assembly lines, ordering systems, network object
communications, rocket launchers, atom-bomb silos, electric
generators, operating systems, fuel injectors, CAT scans, air
conditioners -- an exploding list of subjects, objects and processes
rushing into code, which eventually will be left running without
anyone left who understands them. A world full of things like
mainframe computers, which we can use or throw away, with little
choice in between. A world floating atop a sea of programs we've come
to rely on but no longer truly understand or control. Code and
forget; code and forget: programming as a collective exercise in
incremental forgetting.

________________

Every visual programming tool, every wizard, says to the programmer:
No need for you to know this. What reassures the programmer -- what
lulls an otherwise intelligent, knowledge-seeking individual into
giving up the desire to know -- is the suggestion that the wizard is
only taking care of things that are repetitive or boring. These are
only tedious and mundane tasks, says the wizard, from which I will
free you for better things. Why reinvent the wheel? Why should anyone
ever again write code to put up a window or a menu? Use me and you
will be more productive.

Productivity has always been the justification for the prepackaging
of programming knowledge. But it is worth asking about the sort of
productivity gains that come from the simplifications of
click-and-drag. I once worked on a project in which a software
product originally written for UNIX was being redesigned and
implemented on Windows NT. Most of the programming team consisted of
programmers who had great facility with Windows, Microsoft Visual C++
and the Foundation Classes. In no time at all, it seemed, they had
generated many screenfuls of windows and toolbars and dialogs, all
with connections to networks and data sources, thousands and
thousands of lines of code. But when the inevitable difficulties of
debugging came, they seemed at sea. In the face of the usual weird
and unexplainable outcomes, they stood a bit agog. It was left to the
UNIX-trained programmers to fix things. The UNIX team members were
accustomed to having to know. Their view of programming as
language-as-text gave them the patience to look slowly through the
code. In the end, the overall "productivity" of the system, the fact
that it came into being at all, was the handiwork not of tools that
sought to make programming seem easy, but the work of engineers who
had no fear of "hard."

And as prebuilt components accomplish larger and larger tasks, it is
no longer only a question of putting up a window or a text box, but
of an entire technical viewpoint encapsulated in a tool or component.
No matter if, like Microsoft's definition of a software object, that
viewpoint is haphazardly designed, verbose, buggy. The tool makes it
look clean; the wizard hides bad engineering as well as complexity.

In the pretty, visual programming world, both the vendor and
programmer can get lazy. The vendor doesn't have to work as hard at
producing and committing itself to well-designed programming
interfaces. And the programmer can stop thinking about the
fundamentals of the system. We programmers can lay back and inherit
the vendor's assumptions. We accept the structure of the universe
implicit in the tool. We become dependent on the vendor. We let
knowledge about difficulty and complexity come to reside not in us,
but in the program we use to write programs.

No wizard can possibly banish all the difficulties, of course.
Programming is still a tinkery art. The technical environment has
become very complex -- we expect bits of programs running anywhere to
communicate with bits of programs running anywhere else -- and it is
impossible for any one individual to have deep and detailed knowledge
about every niche. So a certain degree of specialization has always
been needed. A certain amount of complexity-hiding is useful and
inevitable.

Yet, when we allow complexity to be hidden and handled for us, we
should at least notice what we're giving up. We risk becoming users
of components, handlers of black boxes that don't open or don't seem
worth opening. We risk becoming like auto mechanics: people who can't
really fix things, who can only swap components. It's possible to let
technology absorb what we know and then re-express it in intricate
mechanisms -- parts and circuit boards and software objects --
mechanisms we can use but do not understand in crucial ways. This
not-knowing is fine while everything works as we expected. But when
something breaks or goes wrong or needs fundamental change, what will
we do but stand a bit helpless in the face of our own creations?

- - - - - - - - - - - -
N E X T__P A G E .|. [16]An epiphany on unscrewing the computer box:
Why engineers flock to Linux

- - - - - - - - - - - -
DETAIL OF ILLUSTRATION BY SCOTT LAUMANN

________________________________________________________________

References

Visible links:
1.
http://www.salonmagazine.com/event.ng/Type=click&ProfileID=359&RunID=1263&AdID=861&GroupID=3&FamilyID=27&TagValues=514.626&Redirect=http:%2F%2Fwww.citibank.com%2Fus%2Fcards%2Fbanner%2Fplatinum%2Fplatcard.cgi%3Fpage%3D3%26adid%3D01%26sid%3DSAL
2. http://www.salonmagazine.com/21st/nav/1998/src/21st_nav.map
3.
LYNXIMGMAP:http://www.salonmagazine.com/21st/feature/1998/05/13feature.html#21st_nav
4. http://www.salonmagazine.com/
5. http://www.salonmagazine.com/21st/books/1998/05/13books.html
6. http://www.salonmagazine.com/21st/books/1998/05/13books.html
7. http://tabletalk.salonmagazine.com/webx/webx.dll?13@@.ee820d4/8
8. http://www.salonmagazine.com/21st/feature/1998/05/cov_12feature.html
9. http://www.salonmagazine.com/21st/feature/1998/05/08feature.html
10. http://www.salonmagazine.com/21st/rose/1998/05/08straight.html
11. http://www.salonmagazine.com/21st/feature/1998/05/08featureb.html
12. http://www.salonmagazine.com/21st/rose/1998/05/07straight.html
13. http://www.salonmagazine.com/archives/to/21_feature.html
14. http://www.salonmagazine.com/21st/feature/1998/05/cov_12feature.html
15. http://www.salonmagazine.com/21st/books/1998/03/cov_02books.html
16. http://www.salonmagazine.com/21st/feature/1998/05/13feature2.html
17. http://www.salonmagazine.com/
18. http://www.salonmagazine.com/archives/
19. http://www.salonmagazine.com/search/
20. http://www.salonmagazine.com/contact/
21. http://www.salonmagazine.com/services/
22. http://www.salonmagazine.com/promo/hgg/
23. http://tabletalk.salon1999.com/webx
24. http://www.salonmagazine.com/21st/
25. http://www.salonmagazine.com/ent/glow/
26. http://www.salonmagazine.com/books/
27. http://www.salonmagazine.com/col/
28. http://www.salonmagazine.com/comics/
29. http://www.salonmagazine.com/ent/
30. http://www.salonmagazine.com/feature/
31. http://www.salonmagazine.com/mwt/
32. http://www.salonmagazine.com/news/
33. http://www.salonmagazine.com/wlust/

Hidden links:
34.
http://www.salonmagazine.com/event.ng/Type=click&ProfileID=358&RunID=1136&AdID=19&GroupID=6&FamilyID=7&TagValues=513.626&Redirect=http:%2F%2Fwww.salonmagazine.com%2Fnews%2Fnewsreal.html

[1]Spring sale on colognes and perfumes at www.fragrancecounter.com

[INLINE] [2][ISMAP]-[3][USEMAP]
. [INLINE]

[4]

Salon

A L S O__T O D A Y

[5][LINK]
[6]When you just can't stop clicking
By Lori Leibovich
"Caught in the Net" offers melodramatic tales from "Internet addicts"

- - - - - - - - - -

T A B L E__T A L K

Should companies be allowed to track their employees' Web surfing?
Weigh in on employee privacy vs. corporate rights in the Digital
Culture area of [7]Table Talk

- - - - - - - - - -

R E C E N T L Y

[8]The dumbing-down of programming
By Ellen Ullman
Part one: Rebelling against Microsoft and its wizards, an engineer
rediscovers the joys of difficult computing
(05/12/98)

[9]Maximum confusion
By Janelle Brown
On the Web, a typo throws frat boys and feminists onto each other's
turf
(05/08/98)

[10]Let's Get This Straight
By Scott Rosenberg
Now that they're sundered from the magazine, whither Wired's Web
sites?
(05/08/98)

[11]Wired nests with Condé Nast
By Lori Leibovich
But will the magazine's new owners dull its edge?
(05/08/98)

[12]Let's Get This Straight
By Scott Rosenberg
Gates tells the world that what's good for Microsoft is good for the
country
(05/07/98)

- - - - - - - - - -

BROWSE THE
[13]21ST FEATURE ARCHIVES

- - - - - - - - - -

THE DUMBING-DOWN OF PROGRAMMING | PAGE 2 OF 2

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Linux won't recognize my CD-ROM drive. I'm using what should be the
right boot kernel, it's supposed to handle CD-ROMs like mine, but no:
The operating system doesn't see anything at all on /dev/hdc. I try
various arcane commands to the boot loader: still nothing. Finally
I'm driven back to the HOW-TO FAQs and realize I should have started
there. In just a few minutes, I find a FAQ that describes my problem
in thorough and knowledgeable detail. Don't let anyone ever say that
Linux is an unsupported operating system. Out there is a global
militia of fearless engineers posting helpful information on the
Internet: Linux is the best supported operating system in the world.

The problem is the way the CD-ROM is wired, and as I reach for the
screwdriver and take the cover off the machine, I realize that this
is exactly what I came for: to take off the covers. And this, I
think, is what is driving so many engineers to Linux: to get their
hands on the system again.

Now that I know that the CD-ROM drive should be attached as a master
device on the secondary IDE connector of my orphaned motherboard --
now that I know this machine to the metal -- it occurs to me that
Linux is a reaction to Microsoft's consumerization of the computer,
to its cutesying and dumbing-down and bulletproofing behind dialog
boxes. That Linux represents a desire to get back to UNIX before it
was Hewlett-Packard's HP-UX or Sun's Solaris or IBM's AIX --
knowledge now owned by a corporation, released in unreadable binary
form, so easy to install, so hard to uninstall. That this sudden
movement to [14]freeware and open source is our desire to revisit the
idea that a professional engineer can and should be able to do the
one thing that is most basic to our work: examine the source code,
the actual program, the real and unvarnished representation of the
system. I exaggerate only a little if I say that it is a reassertion
of our dignity as humans working with mere machine; a return, quite
literally, to the source.

In an ideal world, I would not have to choose between the extreme
polarities of dialog box and source code. My dream system interface
would allow me to start hesitantly, unschooled. Then, as I used the
facility that distinguishes me from the machine -- the
still-mysterious capacity to learn, the ability to do something the
second time in a way quite different from the first -- I could
descend a level to a smarter, quicker kind of "talk." I would want
the interface to scale with me, to follow me as my interest deepened
or waned. Down, I would say, and it would let me get my way, however
stupid or incomprehensible this seemed to it, a mere program. Up, I
could say, so I could try something new or forgotten or lost just now
in a moment of my being human, nonlinear, unpredictable.

________________

Once my installation of Linux was working, I felt myself qualified,
as a bona fide Linux user, to attend a meeting of the Silicon Valley
Linux User's Group. Linus Torvalds, author of the Linux kernel and
local godhead, was scheduled to speak. The meeting was to be in a
building in the sprawling campus of Cisco Systems. I was early; I
took a seat in a nearly empty room that held exactly 200 chairs. By
the time Torvalds arrived half an hour later, more than twice that
many people had crowded in.

Torvalds is a witty and engaging speaker, but it was not his clever
jokes that held the audience; he did not cheerlead or sell or
sloganize. What he did was a sort of engineering design review.
Immediately he made it clear that he wanted to talk about the problem
he was just then working on: a symmetrical multiprocessing kernel for
Linux. For an hour and a half, the audience was rapt as he outlined
the trade-offs that go into writing an operating system that runs on
multiple processors: better isolation between processes vs.
performance; how many locks would be a good number, not too many to
degrade response, not so few to risk one program stepping on the
memory area of another; what speed of processor should you test on,
since faster processors would tend to minimize lock contention; and
so on through the many countervailing and contradictory demands on
the operating system, all valid, no one solution addressing all.

An immense calm settled over the room. We were reminded that software
engineering was not about right and wrong but only better and worse,
solutions that solved some problems while ignoring or exacerbating
others. That the machine that all the world seems to want to see as
possessing some supreme power and intelligence was indeed
intelligent, but only as we humans are: full of hedge and error,
brilliance and backtrack and compromise. That we, each of us, could
participate in this collaborative endeavor of creating the machine,
to the extent we could, and to the extent we wished.

The next month, the speaker at the Silicon Valley Linux User's Group
is Marc Andreesen, founder of Netscape. The day before, the source
code for Netscape's browser had been released on the Internet, and
Andreesen is here as part of the general celebration. The mood
tonight is not cerebral. Andreesen is expansive, talks about the
release of the source code as "a return to our roots on a personal
level." Tom Paquin, manager of Mozilla, the organization created to
manage the Netscape source code, is unabashed in his belief that free
and open source can compete with the juggernaut Microsoft, with the
giants Oracle and Sun. He almost seems to believe that Netscape's
release of the source isn't an act of desperation against the
onslaught of the Microsoft browser. "Technologists drive this
industry," he says, whistling in the dark. "The conventional wisdom
is it's all marketing, but it's not."

Outside, a bus is waiting to take the attendees up to San Francisco,
where a big party is being held in a South of Market disco joint
called the Sound Factory. There is a long line outside, backed up
almost to the roadway of the Bay Bridge. Andreesen enters, and he is
followed around by lights and cameras like a rock star. In all this
celebration, for just this one night, it's almost possible to believe
that technologists do indeed matter to technology, that marketing is
not all, and all we have to do is get the code to the people who
might understand it and we can reclaim our technical souls.

Meanwhile, Andreesen disappears into a crush of people, lights flash,
a band plays loudly and engineers, mostly men, stand around holding
beer bottles. Above us, projected onto a screen that is mostly
ignored, is what looks like the Netscape browser source code. The
red-blue-green guns on the color projector are not well focused. The
code is too blurry, scrolling by too quickly, to be read.
SALON | May 13, 1998

[15]Ellen Ullman is a software engineer. She is the author of
[16]"Close to the Machine: Technophilia and its Discontents."

- - - - - - - - - - - - - - - - - - - - - - -
T A B L E_.T A L K

Is programming being "dumbed-down"? Are "easy" programming tools and
wizards changing the nature of programming? Is knowledge disappearing
into code? Come to Table Talk's [17]Digital Culture area and talk
about Ellen Ullman's "The Dumbing-Down of Programming."

- - - - - - - - - - - - - - - - - - - - - - -
R E L A T E D_.S A L O N_.S T O R I E S

[18]Disappearing into the code: A deadline brings programmers to the
place of no shame. Excerpt from "Close to the Machine."
By Ellen Ullman
Oct. 9, 1997

[19]Sliced off by the cutting edge: It's impossible for programmers
to keep up with every trend even when they're eager and willing. What
happens when they despair? Excerpt from "Close to the Machine."
By Ellen Ullman
Oct. 16, 1997

[20]Elegance and entropy: An interview with Ellen Ullman.
By Scott Rosenberg
Oct. 9, 1997

[21]A trusted source for today's information junkies. Click now for a
Britannica Online FREE TRIAL.

[22]Click here to get your guide!

________________________________________________________________

References

Visible links:
1.
http://www.salonmagazine.com/event.ng/Type=click&ProfileID=482&RunID=1287&AdID=878&GroupID=3&FamilyID=43&TagValues=626.646&Redirect=http:%2F%2Fwww.fragrancecounter.com
2. http://www.salonmagazine.com/21st/nav/1998/src/21st_nav.map
3.
LYNXIMGMAP:http://www.salonmagazine.com/21st/feature/1998/05/13feature2.html#21st_nav
4. http://www.salonmagazine.com/
5. http://www.salonmagazine.com/21st/books/1998/05/13books.html
6. http://www.salonmagazine.com/21st/books/1998/05/13books.html
7. http://tabletalk.salonmagazine.com/webx/webx.dll?13@@.ee820d4/8
8. http://www.salonmagazine.com/21st/feature/1998/05/cov_12feature.html
9. http://www.salonmagazine.com/21st/feature/1998/05/08feature.html
10. http://www.salonmagazine.com/21st/rose/1998/05/08straight.html
11. http://www.salonmagazine.com/21st/feature/1998/05/08featureb.html
12. http://www.salonmagazine.com/21st/rose/1998/05/07straight.html
13. http://www.salonmagazine.com/archives/to/21_feature.html
14. http://www.salonmagazine.com/21st/feature/1997/11/cov_20feature.html
15. mailto:address@hidden
16. http://www.salonmagazine.com/21st/feature/1997/10/cov_09ullman.html
17. http://tabletalk.salon1999.com/webx/webx.dll?13@@.ee8b3e2
18. http://www.salonmagazine.com/21st/feature/1997/10/cov_09ullman.html
19. http://www.salonmagazine.com/21st/feature/1997/10/cov_16ullman.html
20. http://www.salonmagazine.com/21st/feature/1997/10/09interview.html
21.
http://node48.salonmagazine.com/event.ng/type=click&profileID=461&runID=$runID&adID=903&redirect=http:%2F%2Fwww.eb.com:193/owa_bol/owa/adbanner?p_ad=tftextsalon
22.
http://www.salonmagazine.com/event.ng/Type=click&ProfileID=484&RunID=1022&AdID=427&GroupID=3&FamilyID=28&TagValues=626.648&Redirect=http:%2F%2Fpersonal.lycos.com
23. http://www.salonmagazine.com/
24. http://www.salonmagazine.com/archives/
25. http://www.salonmagazine.com/search/
26. http://www.salonmagazine.com/contact/
27. http://www.salonmagazine.com/services/
28. http://www.salonmagazine.com/promo/hgg/
29. http://tabletalk.salon1999.com/webx
30. http://www.salonmagazine.com/21st/
31. http://www.salonmagazine.com/ent/glow/
32. http://www.salonmagazine.com/books/
33. http://www.salonmagazine.com/col/
34. http://www.salonmagazine.com/comics/
35. http://www.salonmagazine.com/ent/
36. http://www.salonmagazine.com/feature/
37. http://www.salonmagazine.com/mwt/
38. http://www.salonmagazine.com/news/
39. http://www.salonmagazine.com/wlust/

Hidden links:
40.
http://www.salonmagazine.com/event.ng/Type=click&ProfileID=483&RunID=1136&AdID=19&GroupID=6&FamilyID=7&TagValues=626.647&Redirect=http:%2F%2Fwww.salonmagazine.com%2Fnews%2Fnewsreal.html

You have reached the Information
Page

Lynx Version 2.8.1dev.2

File that you are currently viewing

Linkname: Salon 21st | The dumbing-down of programming
URL: http://www.salonmagazine.com/21st/feature/1998/05/13feature2.html
Charset: iso-8859-1 (assumed)
Server: Netscape-Enterprise/3.0I
Date: Thu, 14 May 1998 23:11:13 GMT
Owner(s): None
size: 227 lines
mode: normal

Link that you currently have selected

Linkname: Ellen Ullman
URL: mailto:address@hidden

[Prev in Thread]

Current Thread

[Next in Thread]

lynx-dev lynx: off subject, part two:, David Combs <=

Prev by Date: lynx-dev lynx: off subject, bug VERY good
Next by Date: Re: lynx-dev set proxy
Previous by thread: lynx-dev lynx: off subject, bug VERY good
Next by thread: lynx-dev 2.8.1dev.12
Index(es):
- Date
- Thread