− 080 −

A History of Computing with Dr. Drang

October 24th, 2014

Internet Archive

Dr. Drang returns to explore his background in computing from the late 1970s to today. Along the way we discover what happens when you mess up a punchcard, what Linux was like in the early days, why he uses a Mac today, and his perspectives on the near future of computing.

Our Favorite Internet Snowman

Listen to this section on SoundCloud: 0:00

Dr. Drang is the pseudonymous and occasionally cranky genius-snowman-engineer behind And Now It’s All This. You can also find him on Twitter: @drdrang. We asked him to join us to discuss his personal computing history and share his thoughts on the future of Apple’s desktop and mobile platforms.

NASA

Dr. Drang didn’t begin using a computer until he went to college in the early 1980s. The lone computer at his high school was tied up by a data processing class, which was focused on teaching data entry via punchcards in a vocational setting.

The computing world was at the dawn of a revolution. While the Apple II had been for sale for a short while at this point, the Commodore 64 wouldn’t be released until 1982. Popularization of home computing had just begun, and the Xerox Star offered one of the first commercially available graphical user interfaces for a cool $75,000 ($195,000 in today’s dollars).

It was in this environment that Dr. Drang began his computing journey.

Punch Cards and FORTRAN

Listen to this section on SoundCloud: 3:35

Dr. Drang’s first exposure to computers was learning FORTRAN in an Introduction to Programming course his Freshman Year of collge. He believes he was one of the last people to learn computing via punch cards and Keypunch Machines. Wikipedia has a thorough write up of the IBM style punched cards.

Autopilot

Punch cards were quite unforgiving, and if you made a mistake on the keypunch machine you had to go back and re-punch the whole card from the beginning. The top section of the card would print what you were punching in ink, and below that the rectangular holes punched into the card would allow it to be read when pulled into the computer. Often the ink would run out and you couldn’t tell what you’d punched. For some advanced students that didn’t matter because they could read the holes.

A Punchcard Before

A Fortran Punched Card After

One card was used per line of FORTRAN code, and they’d stack up in a bin. Then the cards would be taken to a special window where they’d be taken and run. Later (an hour or more later) you’d get the output back in stacks of folded printer paper.

“You’d take them to the High Priests of the Mainframe Computer”

If you discovered that there was a bug in your program, you had to go find it and repeat the process. As you’d probably guess, this process took a significant amount of time.

“So you’d only get about eight mistakes a day?”

Drang thinks that this process has possibly caused him to be more deliberate than he would if he learned computing in an interactive, terminal-based environment. He tends to write more before he tests.

Since time on the Keypunch Machine was almost as limited as time on the mainframe, students purchased special pads of paper to write programs out by hand first. Dr. Drang used them for a while before realizing that they weren’t much more helpful than normal paper.

Make Mistakes Faster

Rich Siegel (of BBEdit fame) used to work for a company called Think Technologies, which made Lightspeed Pascal and LightspeedC for early Macs. They ran an ad with a tagline “Make mistakes faster”, because it was one of the first interactive IDEs that gave you feedback when it experienced a bug.

There’s a nice interview with Rich on episode 36 of Debug in which he talks about his days with Think.

Thanks to Doreen Howell, who served as Marketing Communications Manager during Think Technologies’ merger with Symantec, Rich was able to find the original ad for us.

Enter the Terminal

Listen to this section on SoundCloud: 17:30

Programming languages at the time were much less helpful and fluid than today. They had to be “closer to the metal” due to the limitations of the machines involved. Statements were closer in syntax to how a computer “thinks” about problems than how people think about them.

When Dr. Drang began working in a terminal in his second programming course later in his undergraduate years (1980-1981). The terminals available to students were “dumb” timesharing terminals that were either hardwired or modem-connected to the mainframe, and they were scattered around campus. He even had one in his dorm building. These terminals did have screens, but he could only edit one line of code at a time using ICE (Illinois Central Editor).

Line editors (like the better known ed) are the ancestors of more modern visual editors like vi. You could view up to 24 lines at a time and move back and forth in the program from the terminal, but you couldn’t easily edit multiple lines of code at once.

The DEC LA36 DECwriter II Terminal

DEC made some printer terminals at the time that used fan-fold paper instead of a screen. While wasteful, it at least allowed you to see all your code at once. They were also helpful for turning in programming assignments.

Programs and Languages

Listen to this section on SoundCloud: 23:49

Dr. Drang was an engineering student rather than a computer science major, which influenced the kind of programming he was doing and languages he was using at the time. He started with elementary FORTRAN, learning loops and other basic programming tasks. CS students learned other languages that are dead now, but FORTRAN has remained in use.

At the time he took programming courses simply because he had to, but in his senior year he had a technical elective class available and decided to take a course in Pascal. That was the course where he feels he first learned programming, partially because his professor was young, energetic and interested in teaching the craft of structurecd programming.

The capstone project of the class was to write their own line editor, then use it to edit its own source code. This is called “dogfooding” which is an expression that has risen to popular culture out of nerd culture at Microsoft. It generally means using your own creation for real work and not just as a QA target. The expression represents something that is fairly commonplace now in software development. Dogfooding can often reveal bugs and awkward interactions models that scripted testing may not.

The Computer as Tool and Toy

Listen to this section on SoundCloud: 30:43

The first time Dr. Drang remembers using a computer as a tool rather than an end in itself was during graduate school. He was assisting his professor in teaching a masters-level class, and wrote a program to do reliability calculations to help create assignments for the students.

“If you really want to know a topic… sign up to teach the class”

What this experience helped him realize is that he had to first teach the computer to do the problem, and discover all the corner cases the problem could encounter. This is the best way to really understand how a process works. It makes you get past all the hand-waving and get to the core of the process and all its exceptions.

“The key with programming is that you have an absolutely unforgiving student”

Dr. Drang’s first personal computer was a Commodore 64 he bought in graduate school, but his first Mac was a 512K in spring of 1985.

Drang’s First Mac

He wrote his PhD thesis and many of the supporting programs for it on the 512K using Mac Pascal. It was the machine that started him down the road of playing with computers for fun and work.

My First Computer

My first computer was a calculator. It was a Texas Instruments TI-74 pocket computer. It was hard to call it a computer even then. But it was programmable using BASIC and it was the first time I could write down logic and have it repeatedly executed with different input. It was a computer.

Programming that little piece of plastic was not fun. It displayed one line at a time and forget any reasonable stack trace. But it made me think and plan my programs carefully because for that exact reason. Dumb mistakes were even less fun than now.

Fun with UNIX

Listen to this section on SoundCloud: 35:38

In 1996 Dr. Drang was getting tired of the Mac OS and its multitasking limitations. It used cooperative multitasking which was nearly the same as no multitasking at all. Programs had to grant time for multitasking explicitly in the code, which was inconvenient at best and unstable at worst. Crashes were common.

At the time Apple was looking for another company to purchase. It ended up being Steve Jobs’s NeXT with its NeXTSTEP operating system, but was rumored to be Be, founded by Jean-Louis Gassee’s and the maker of BeOS. Regardless, Drang took that as a sign that Apple was aware that they didn’t know how to write a good OS and wouldn’t for a few years. He started looking at alternatives.

He chose Linux, which was as informative an experience as his first class in Pascal. He enjoyed returning to the command line, as well as the UNIX philosophy where single purpose tools are strung together to do more powerful tasks. That philosophy has stuck with him to this day.

Red Hat Linux 4.2

In the late 1990s, Linux was young but tremendously stable. His first distribution was Red Hat 4.1 or 4.2. While it was stable, it wasn’t incredibly user friendly, and when he switched back to a Mac in late 2004 it was because he’d grown tired of being his own system administrator. At that point OS X had reached a point where he could keep his UNIX workflow while being freed of the “fiddly” parts of running Linux as a primary OS.

Nevertheless, the pain of managing his own Linux system taught him a great deal about how to work in the UNIX environment. Those skills have helped him through the present day, both personally and professionally. Most of his report generating workflows rely on the command line and they’ve been stable for more than a decade.

Back to the Mac

Listen to this section on SoundCloud: 45:30

After returning to the Mac, Dr. Drang’s workflow has evolved a greater balance between command line and GUI programs. He started using BBEdit alongside his terminal, and could work with those programs to get his day-to-day work done. He used to make graphics directly in PostScript, but now uses OmniGraffle. Acorn is his go-to image editor for photographs if he needs something more capable than Preview.

BBEdit
Specifically crafted in response to the needs of Web authors and software developers, BBEdit provides an abundance of high-performance features for editing, searching, and manipulation of text.
Price: $49.99
Developer’s Page

OmniGraffle
Need a diagram, process chart, quick page-layout, website wireframe or graphic design? OmniGraffle can help you make eye-popping graphic documents quickly.
Price: $99.99
Developer’s Page
App Store

Acorn
Everyone needs to edit images at some point, but not everyone has the time to learn complicated super pricey image editing programs. This is why we created Acorn.
Price: $29.99
Developer’s Page
App Store

All that being said, Dr. Drang still keeps the Terminal app alive so he can get one at a moment’s notice. He’s a Mac user not just because it’s a Mac, but because it’s UNIX plus.

“If the terminal is no longer available I have to leave”

The Near Future and Recent Past of the Mac and iOS

Listen to this section on SoundCloud: 55:10

Gabe, Erik and Dr. Drang proceed to discuss the near future of the Mac and iOS platform in light of the history of Apple and the Mac platform.

Mea Culpa

It’s been a tough summer for the Technical Difficulties team, and while the show was recorded in early August it’s taken a ~~little while~~ few months to get it out the door. This discussion took place before the Fall 2014 Apple product announcements, so we hadn’t yet seen the iPhone 6 and 6 Plus, not to mention the Apple Watch, iPad Air 2 and Retina iMac.

While I think the discussion is timeless and still highly relevant, we’d like to apologize to our listeners and (most especially) Dr. Drang for our laziness.

“I have no idea when you’re going to put this out”

“Neither do we”

They continue by discussing the difficulties Apple has experienced with network applications and syncing, and how that’s made it tough for developers historically to rely on their infrastructure. This put Mac-first developers of applications like Yojimbo in a tough spot, and allowed the rise of cross-platform competitors like Evernote.

What would you miss most?

Listen to this section on SoundCloud: 77:12

Next Dr. Drang talks briefly about the applications, services, and toolkits he’d miss the most if he did have to leave the Mac (something he himself admits is extremely unlikely). Highest on the list are BBEdit and AppleScript (the functionality, not the language itself).

“If Apple isn’t supporting AppleScript itself, then why should you as a third-party-developer do it?”

On top of all that, the Mac still is the only platform that works right out of the box. It’s an extremely consistent platform that has no parallel in the Windows or Linux world.

Audio Engineer’s Note

If you have – or hear – any feedback, let me know on Twitter @takitapart, or email bob at vanderclay dot com.

Producer’s Note

Well, that’s it for this week. If you have anything that you’d like to add to or correct in the show notes you can find me on Twitter @potatowire, or feel free to send an email to me at potatowire dot com.

080 - A History of Computing with Dr. Drang

TechnicalDifficulties