Computing is too easy | Hacker News Reader

Computing is too easy

aeon.co

49 pointsjgrahamc60 comments

Computing isn't too easy, it's too hard, and modern systems aren't contributing a solution, they are just glossing it over with their crippled tools. Not just crippled tools for office workers, also crippled tools for programmers and artists.

Some things might not be possible to fix. Teaching people to RTFM, for instance. No search engine will be able to replace consistent and comprehensive documentation written by the people who know the system intimately, but it's hard to convince most users, many developers, even, that this is actually worth the effort it takes, both to read and write.

Being able to model data and reason about complexity, even for non-programmers, is a something else you can't really get around. Ever had people in your organization with outlandish ideas that just don't compute, right up there with "why don't you just write a program that writes programs". I've had to explain that yes, I can write a program that does what you want, but it's not going to finish before the heat death of the universe. During all of this arguing a whole bunch of computers are sitting idle when they could be doing useful work if only their operators knew how to tell them to.

I too cut my teeth on HyperCard, and the best thing about it really focused on doing things people really needed. Organizing and reasoning about people's data, whether it was appointments, contacts, orders, stock, notes, things that are hard to do on paper, but easy for a machine to handle. It went straight to the core of the issue. How to best tell the computer to do useful work. Of course it failed in many respects, but the real tragedy is that they seemed to stop trying after that.

This is compounded by the trend toward instant gratification in pretty much everything.

- In your normal day-to-day work, you're likely to have productivity pressures that limit your ability to do freeform thinking and learning, so you're pressured to solve small problems in a local way.

- Search engines make it possible to find the answer to almost any question you might think of, and that makes it feel less necessary to do a deep dive into some topic.

- ...and trends in technology make it far easier for consumers (and yes, even producers are consumers) to treat every problem with a "single-serving solution"

However, the larger problem is that we naturally do not know what we do not yet know. A deep R into TFM is quite likely to teach something necessary that I didn't already know.

Think, for example, of a beginning programmer who quite successfully builds all the functional requirements of a simple web app, but fails to consider the non-functional requirements because he didn't know that he had to. SQL injection is something orthogonal to the application's actual purpose, so I won't actually think about it until either I'm stung by it, or someone else tells me about it. I wouldn't know to ask otherwise.

The problem is: there's too many manuals. We don't have time to read them all.

In fact, I think one of the skills you learn as you gain experience in software development is choosing your moments. When you can just google it, and when you need to get a cup of coffee and RTFM.

...which suggests that computing is not too easy at all, as per grandparent comment.

During my first Microsoft internship, I wrote string libraries to run on the Macintosh... Everything I did was right from K&R -- one thin book about the C programming language.

Today, to work on CityDesk, I need to know Visual Basic, COM, ATL, C++, InnoSetup, Internet Explorer internals, regular expressions, DOM, HTML, CSS, and XML. All high level tools compared to the old K&R stuff, but I still have to know the K&R stuff or I'm toast.

This is why Common Lisp is such a godsend for me. It covers a much wider gamut from low to high level than most languages. The Lisp Machines were really on to something, users didn't really have to know a lot of languages or competing systems. They also ensured good access to documentation.

This is also two areas where the Macintosh failed (perhaps intentionally). Though Hypercard was extensible through XCMDs and XFCNs, It was a huge leap from HyperCard to the Macintosh Toolbox, not just in difficulty, but also because of the tools and documentation simply didn't exist on most people's Macintoshes, and was very expensive to buy.

What was the price of a Macintosh, though, compared to that of a Lisp Machine?

$49,900 for a Symbolics 3620 [1], $9,995 for a Lisa [2], $2,495 for a Macintosh 128k [3]. Affordability was a big priority with the Macintosh, and I'm thoroughly impressed what they managed to do with so little resources. So obviously, a Lisp Machine environment was far out of reach of even most experts at the time. However things progressed and I wouldn't be surprised if a PPC 604 box could run circles around a 3620. (If there's an actual Symbolics user here, please correct me if I'm wrong) So while impossible for consumers in the 80s it was certainly possible in the 90s.

It's interesting to think about what if things had happened differently. Perhaps we would be sitting here posting from Copland and programming in Dylan today. Or probably not since in that case they would be bankrupt by now. But that reminds me, I think I have a pirated Copland beta laying around somewhere that I never got around to try. I seem to remember you needed two PowerMacs connected by serial cable, with one running a debugger, for it to work.

1. http://www.computerhistory.org/collections/catalog/102713428 2. http://www.apple-history.com/lisa 3. http://www.apple-history.com/128k

The only problem: you could not do anything with a Mac 128k. Especially not development.

Things looked much brighter with the Mac II. But even there you needed expensive 32MB or more RAM, a disk with VM, a large screen, an Ethernet card, a graphics card, for a useful setup. Plus a license of MCL. In sum that was cheaper than a Symbolics, though. Performance was okay for the time, but started to look better with 68040 machines - given that they had lots of memory.

The PPC 604 was appearing when Lisp Machines were already long dead. I don't think in real life single CPU 604s machines were that great.

Yes, early Mac development was done on Lisas. I think the later more capable Macs were similarly priced.

What I meant when I brought up the PPC 604 is that by the mid-90s cost of hardware was no longer a big issue in providing users with powerful computing environments. But it's clear that power isn't really what sells. Not even to developers, if you look at some of the more brain-dead environments and languages out there.

> Some things might not be possible to fix. Teaching people to RTFM, for instance. No search engine will be able to replace consistent and comprehensive documentation written by the people who know the system intimately, but it's hard to convince most users, many developers, even, that this is actually worth the effort it takes, both to read and write.

People will RTFM if it isn't boring, dry, and useless.

There's a fine balance to be struck between nice-to-read prose and giving people exactly what they need, quickly enough for them to actually read your stuff. But the thing is, if your documentation is difficult to read and doesn't flow well, it might as well not have been written. Everybody will give up before they learn.

And vice-versa, if your documentation is TOO nice to read and does too much hand-holding. People will gloss it over and miss important details.

Teaching is hard. Much harder than people give it credit.

And because there are no unicorns who can both intimiately understand the system and be good at documenting it, you should do the next best thing - have a person with enough technical background to be able to talk to the experts, but is also good at writing about it write your docs.

This seems to be the approach taken by most self-published tech writers these days. They're good enough to understand the system, but also decent enough at writing about it.

I really RTFM when back against the wall, otherwise I only SkimTFM. I wish embedded manuals, instead of disconnected words, having a REPL, a failing test suite to see how the pieces work together. Brett Victor style.

Maybe it's an overly lazy desire, and nothing will replace the fact that you're willing to focus on reading what people wanted to express about a program. Also, embedded/repl would avoid outdated documentation drift.

The problem is sweeping all the complexity (and power) under the rug in pursuit of "easy". Modern computing hides all the cool stuff. We should expose the difficult and powerful side, even if it's less easy.

> Our laptops are sleek and polished. Our operating systems are fluid and intuitive.

This is clearly a joke. And a cruel one.

Laptops are just two steps away from overheating and falling apart no matter how much glue they put in these days.

And operating systems are laggy and messy. They have still 50% of laggines and 90% of messiness of what was the standard two decades ago.

"fluid and intuitive" I must laugh at this too. I need a search tool to find my installed programs and settings. Most of the time i need google to find out, if a changeable setting exists ;)

Operating systems are stupid since many years, on every new Version i think "god, please change not too much", cause on every new Version things not getting better and not easier and not smoother.

Yes, they look nicer, they have more "blink" and more animations, but all of this not help me to work better or faster.

>I need a search tool to find my installed programs and settings.

as if simply typing the name of or keywords for what you want to find into a search bar isn't fluid and inuitive?

Assuming that you know the name of your volume manager is "gigolo" and that your remote desktop client is "remmina," etc. If you're lucky the program might have a reasonable name, but still your OS decides the most likely thing you're looking for is ancient manuscripts... http://i.imgur.com/0ePB9sT.png

For some reason, when I search "mount and blade"; dracula.txt and equator.txt show up. For some reason processing comes with several books from project gutenberg by default, and they show up when I look up some programs.

If I type "add printer" into the search on Fedora (Gnome Shell), the first item in the list is "Printers" with helpful text letting me know that this is the tool for adding printers. It's much easier than it used to be, IMO.

Well there is always the Gnome way, where the menu entry has one name (Archive Manager) but the command has a very different one (file-roller).

You still found "Printers" which is probably it.

And if you not know the exactly name?

Example i type "browser" -> nothing found. And i am absolutely sure i have installed chrome, seamonkey and ie. ;)

That's why the applications are supposed to have relevant tags that are looked at by the search.

Animations help a lot of people to better understand what is going on in the machine.

You are viewing the world through rose-tinted glasses if you think OSes were better twenty years ago.

OSes were better twenty years ago because they were more predictable and stable because they couldn't do as much, especially if there was no multithreading. Limitations ensured stability and reliable performance. Today, it's too easy to overload your system.

Except now I just realized that 20 years ago was Windows 95. Dang, I'm getting old. :(

They were neither more predictable nor more stable. Twenty years ago, if an application crashed, so did the entire OS. Twenty years ago, applications and the OS were very tightly coupled and they would both deliberately and unintentionally trample on eachother, often with disastrous consequences.

As an OS/2 user twenty years ago, I disagree. Really, it was about twenty years ago that I switched to Linux which didn't crash due to a simple application crash either.

Stop making me feel old. :)

Maybe not stable, but perhaps predictable (at least outside of the MS sphere) because there was not as many interconnected processes bouncing around in the background.

Windows 95 sucked so bad. Not missing multiple bluescreens a day.

I'm conflicted. On the one hand, as a developer, it frustrates the hell out of me when people don't have the slightest idea how computers work on the level of the "just write a program that writes programs" point from the article. On the other hand, I don't know how a car works in any sort of detail, and I'm sure mechanics feel the same about me.

I (like to) think the difference is that I have some idea how to reason about cars, because I am at least familiar with the basic laws of physics and get the idea of internal combustion. The "it should just work" crowd aren't just incompetent as creators, they're incompetent as users, because there's no basis for reasoning.

Indeed, the car/mechanic analogy is quite flawed. The driver is the user of the car, the mechanic isn't. Whereas the developer is also a user of the computer in the most fundamental ways. People who don't know how to use computers are merely along for the ride. Someone without a driver's license might have a tremendous benefit from a car. A lot of the time they even have a say in deciding where to go (especially if they pay), but ultimately it's the person behind the wheel that's calling the shots.

And for people who spend their whole working life riding around in cars (as so many do with computers) it's well worth the trouble and effort to get a driver's license and get that extra bit of autonomy. The same should be true of computing.

Another thing is that even with more and more electronics coming into play, a car is still a mechanical system. As such, if a driver (user) complains about a new rattle or sound, the mechanical links can be traced back to the source.

And that touches on another thing. Computers are deeply visual. Yes, it can output sound and such. But most of the interaction is done by text and images. This means that when it is just sitting there with the screen off, you don't know if it is idle or transferring your porn collection of the NSA headquarters.

From time to time i wonder what would come out of putting a sniffer on the network and have it play some tones based on the packets picked up and their metadata.

All too often i find myself likening computers to small children. When they are noisy you can relax, but when they become quiet you really need to worry. This in particular when exposed to Windows, and its habit of announcing new USB devices with plings and popups.

There's one of these articles every few weeks. I'd argue that the response has been the "maker" movement, built around Arduino and Raspberry Pi.

People also need to distinguish between "you have to tinker in order to use the thing" and "you can tinker if you need to". Old cars were more tinkerable and less reliable.

Old cars were more tinkerable and less reliable.

Reliability is a curve; a function of how much maintenance is spent on it.

No question at all that a modern car with zero maintenance will be more reliable than an old car was with zero maintenance. But with a surprisingly small amount of maintenance, an old can can be more reliable than a modern car with the same amount of maintenance. Sure, it'll take a while before one of them fails, but I can (and do) keep a thirty year old car running with maintenance that probably averages to about ten minutes a week. I suspect very strongly that if I spent ten minutes a week maintaining a modern car (which, from what I can tell, would be me looking at the lights on the dashboard to see if the car is asking for more water or oil), it would fail before the old car did.

I think you are looking at a strong case of survivorship bias. The sample of 30 year old cars that still work represent some of the best made and most reliable cars made 30 years ago. Most of the unreliable and badly made cars from 30 years ago have died and been turned to scrap.

What proportion of modern cars will still be running in 30 years? I suspect it will be less than the proportion of 30 year-old cars that are running now. Some modern cars, I swear, almost feel like disposable items.

There where some truly terrible cars in the 70's and 80's. The Chevy Vega and Ford Pinto are just two classic American examples. Britain had a bunch of disastrous Morris and Austins. Alfa Romeo and Lancia also had some legendarily unreliable cars in that time period. And let's not even begin to talk about the brands from east of the Iron Curtain. At the end of the day I'll happily take the worst cars of today over the worst cars of the 70's and 80's.

I suspect that the proportions will be similar. There are plenty of amazingly reliable vehicles being built today.

For certain cars, yes; there are plenty around that have been round their odometers a few times. But we've forgotten the higher proportion of cars that were lemons straight from the factory or suffered early rust or electrical failures (this may be a more British thing).

When I got my RPi 2, the first thing I did was to make it to boot headlessly in debian and skip all the X window crap. It is a joy to play with it via ssh on a sleek Macbook Air from anywhere in my house. Now I can study how redis works by compiling it in a docker container. Wish I had it in 1980s.

Except that commercial offerings, both in terms of cars and computers, are "Contact a certified technician" these days.

I agree with the article. The differences between 10 year old me on my Commodore 64 and my currently 10 year old son on his Windows 7 computer are astronomical. When I turned my 64 on it was "READY" for me to make it do something. I spent days typing in BASIC and 6502 Assembly source code into it just to play a game. My son has a seemingly infinite supply of videos on YouTube to entertain him. Near infinite supply of free-to-play ready made games (with in-app purchases). There is no natural incentive for him to learn how to produce anything on computers.

I also agree. Today we need people who can miss the forest for the trees! I can't believe the lack of basic computer skills that people have coming into the workforce and someone that can use Word is considered a computer person. Even the new IT people only know GUI and Microsoft with no experience with Mac OS or Linux, and no idea about anything but the silo they are working in.

I was one of those kids who had to program games at 7 on a Sol20 in 1977 and than de-bug since every basic was different. When I found out if I could learn Assembly I could play more game I learned that. The day I got the 300 baud modem was life changing and I had to pay for a second line due to everyone else in the house being mad they couldn't use the phone.

Time to complain about my school. Our "computer" classes consisted of learning to: type, format word, type in a spreadsheet, format powerpoint (in a way that I think powerpoint is unnecessary for), one week total of messing around in garage band, one week of typing out the exact lines of html, copying instructions for dreamweaver.

EDIT: And then we do 'job' stuff in that class. Including making resumes that include our ability to use basic microsoft/adobe programs. I could have learned to do that without a manual or internet before the class. I can learn way more with internet just messing around in photoshop/gimp every once in a while.

It is time to put the science back into Computer Science and have it in Middle School and High School. My school district computer classes are business classes and the teachers need business degrees.

There are many more distractions these days, but I'm not sure that it's as clear cut as you suggest.

It's really not that hard to get kids into some form of coding today. I've run a Scratch[1] club for 8-10 year olds at my daughter's school and every single one of the kids there loved it. By the end of the first hour, they were all producing some form of animation that they could control and all were desperate to come back for the following week.

Compare that with the steep learning curve of BASIC on an 80s 8-bit machine. It would take days to get anything more exciting than "Hello World!" out of it. Most of the people I know who had Spectrums (I'm British) as kids never went near programming. Their entire use of the command line was LOAD "".

[1] https://scratch.mit.edu/ - just in case anyone's never seen it.

In my personal opinion everyone should learn the basics of programming for the same reason everyone claims that everyone needs four years of English classes and science classes and history classes, because it helps you look at the world in a different way. In addition, I personally have found that if I try to make a program to do math for me, I understand the math way better.

So thank you for teaching some people, because learning is fairly hard, though if you have a good teacher it doesn't seem like it would be as hard to me.

What is Spectrums though?

Spectrums is plural of Spectrum, as in Sinclair ZX Spectrum, the computer that 90% of British kids had in the 80s (http://en.wikipedia.org/wiki/ZX_Spectrum).

Your point is solid, but your experience with Scratch is different than mine. My 10 year old son had very little interest in Scratch. I'm not entirely sure of the reason for this but I think it is related to:

1) It was hard to distribute his creations

2) Lack of natural aptitude / ability

3) Too easy to consume without producing

We had a little more success with Construct 2. The main difference being that the games could be distributed to an iPad or any other HTML 5 web browser effortlessly. Maybe Scratch addressed that already in the 18 months since we've used it?

You can easily distribute Scratch apps via their web site, but it's not really designed as a language to build full iPad apps etc. Its main purpose is to make learning the basics (control blocks, variables etc) easy and fun. By the time you're anywhere near something that you can distribute, you would have had to learn most of those basics. If something else, like Construct 2, works for you that's great.

I obviously don't know your kid, but I doubt that aptitude/ability is going to be a blocker from getting simple Scratch programs running. I know several others who've run classes to a wide range of ages and abilities and not one of the kids has failed to get to grips with the basics.

I can accept that attitude/interest (wanting to consume rather than produce) is going to be an issue for some children, but that's always been the case. And no matter how easy or hard it is to make things, those children aren't going to want to program.

My point was less about Scratch specifically - there's a few similarish programs out there that can be used instead. It's more that the incentive to learn and availability of distractions hasn't really changed in the 30 years since I was a kid, and if anything the barriers to getting into some form of programming have dropped drastically since those days.

May I suggest that you're starting from the premise that your kid is willing/able to learn programming and that programming is for everyone?

As your parent suggested, not everyone who had computers back than had or felt the need to program them.

Right. I think the next step would be to try and find a programming exercise that his son could make his own. Something that would self motivate him to solve a problem. I think this is one of the hardest parts of diving into any high level thinking skill or hobby: finding the motivation to take the first step on a years long journey.

May I suggest that you're starting from the premise that your kid is willing/able to learn programming

That is precisely why I put #2 in my list.

I think about this a lot, there are a lot of distractions now days but when I am actually being productive I'm working on distractions for others. Sometimes I wonder if that's all computers are is a massive distraction?

Cassette loading was probably what piqued my curiosity.

I distinctly remember being baffled by how playing special "music" could turn into something on the screen and spent along time forcing a poor spectrum to listen to my "Rave 92" tape.

It's not. Everything is disconnected from everything, everything requires me to learn a new GUI, my devices are actively preventing me from doing things I want, using data gives me a headache, my tools don't tell me what they can do, making apps is complex, I need to use a 1970s interface to do anything remotely, my Chrome tabs crash all the time, my Android apps crash all the time, iOS is too slow to know whether it's crashed. Computing has become a little superficial in the way we use it, superficial is easy, but anything else is way too hard.

Computing doesn't lead well, in its current form, to the development of coevolutionary mastery. That's the thing, I suspect. For example: Your text editor, with the exception of emacs et al, probably isn't particularly programmable in a form that the average user is likely to discover. There's probably not a way to right click on a button and see what function it's calling, or to right click on a transformed bit of text and see what's been done to it.

The program itself isn't built for that. And the economic interest in not building it for that is obvious - if you let users have access to the full power of the machine, even worse to share their modifications, what do they need you for any more? How are you going to convince people to buy version 15 when they've got version 14 set up the way they want it?

Your options have become increasingly strongly contrasted: Become a programmer or live in user-land. As if a programmer isn't just a more knowledgeable class of user and as if that's not a spectrum. It's nothing special about typing white text into a black screen. Even if we still lived in command line land, I don't think that we'd be better off. I don't feel like it has anything to do with how hard the computer is to use - at least not at a surface level. It seems to me more to do with how programmable your programs are and how easily you can start doing useful things with that power.

Evolution, progress, the march of the human race has fundamentally been enabled by our ability to efficiently abstract and encapsulate complexity into building blocks that form the next leap forwards in the advancement of science, knowledge etc. Complexity should only be by necessity not forced on everyone. its just progress

I started out programming with a Commodore 64 and having instant access to BASIC when I turned on the machine was really awesome. As a professional developer now, I appreciate the low level knowledge that learning on the C64 provided, but the more important thing was low barrier of entry to development tools.

There is a currently a very low barrier of entry access point for programming on everyone's computers currently in the form of the web browser. You can view the source for any web page and change things around in the dev tools and console.

Too many people yearn for the good old days of low level access yet are quick to dismiss Javascript as "toy" language. In the old days BASIC was just a toy too. The "real" programmers wrote their code in assembly.

Yes.

And so is buying cheap unhealthy food. Talking long distance. Hooking up. Being entertained (or at least, finding entertainment). etc etc...

My point being, humanities entire push to modernity is nothing but step after step of making things "too easy."

We are supposed to stop now?

Reply on news.ycombinator.com