|
|
posted: July 7, 2018
tl;dr: I wasn’t immediately a fan, but I’ve matured in my thinking...
Occasionally there arises a technology which is so innovative and such a radical break with the past that you end up vividly remembering your first experience with it. I’ve already written about one such technology in my life: the first true web application I ever used: Hotmail, back in 1997. There are many others: I can remember my first floppy drive, hard drive, GUI, mouse, cellphone and smartphone. Another impactful technology was the first Integrated Development Environment I ever used, back when I was a student at Cornell.
I was not too far removed from the punchcard era; my class at Cornell was the first that did not have to use punchcards for any required Computer Science classes. I can’t recall exactly what text editors I used in my college years, but I am pretty sure that they were line editors. In a line editor just one line of code could be edited at a time; you couldn’t cursor around and edit across multiple lines. In that sense line editors were just a screen-based analogue to punchcards: each punchcard was one line of code; you wrote and edited one punchcard at a time; and when you finished with one punchcard you moved onto the next punchcard/line.
The line editor had no concept of what the characters being edited meant; they were just sequences of bytes (no Unicode in those days). So as you typed a program in whatever language you were using, there was zero feedback from the editor on the correctness of your code. If you made a typo or a spelling error, you wouldn’t learn about that until you submitted your program to the compiler, perhaps after hours of typing.
While this complete lack of feedback from the editor created a challenge for those prone to typos, it also forced programmers to master the syntax of the language. If a semicolon was required at the end of a statement, you learned pretty quickly to always make sure you typed a semicolon; same thing with closing braces and parentheses. Those who couldn’t master the details of the language’s syntax were left behind, and for the rest of us, mastering those syntactic subtleties became a badge of honor.
A Terak computer
I used line editors in the computer science classes I took, but while I was there Cornell introduced small desktop computers known as the “Teraks” for the large introductory computer science class. I didn’t take the intro class, as I already had programming experience when I got to college, but I did get exposed to the Teraks when I got a job with the CS department helping tutor students in the computer labs and grading assignments. At the time Cornell taught its lower level CS courses using a variant of IBM’s PL/I language called “PL/C”, for “Programming Language/Cornell”. One of the CS professors, Tim Teitelbaum, had written a PL/C editing program for the Teraks called the “Cornell Program Synthesizer” to be used by the intro CS students to type in their programs. It was the first IDE that I ever saw.
I was blown away, as it was such a radical advance from line editors. It definitely knew you were entering a PL/C program, as it provided all sorts of help and error checking to maximize the chances of the beginner creating a program that would at least run. As soon as you typed keystrokes to indicate you were entering an “if” statement, on the screen would appear, across several lines, places where you could type the Boolean expression to be evaluated (I think it even made sure you entered an expression that would produce a Boolean result, as opposed to gibberish), a block of code for the true case, and a block of code for the false/else case. After you finished with one of the required sections the cursor moved to the next. The IDE program took care of code formatting, indentation, and styling; it was hard to make a syntax error while using it.
It was amazing, stunning even, and yet it also felt like cheating. As a grizzled 19 year-old veteran programmer who had learned programming the hard way, with line editors, I wondered how these beginning students were going to master syntax when it was spoon-fed to them by the IDE? My attitude towards it then was similar to the attitude that many teachers had towards calculators: how were kids going to learn to do arithmetic by hand and in their heads, if all they did was press numbers and symbols on a calculator? I took pride in my ability to properly type in a large program and get it to compile without an error the first time, and feared that the Cornell CS department was lowering its standards.
Early in my post-collegiate career my attitude started to change. I saw firsthand the power of lint and other static code analysis tools. I started using more powerful editors such as Emacs, which improved my productivity. I learned and used more programming languages, and started to appreciate the help that could be provided by a sophisticated editor. For curly brace languages, an editor which could help close braces and indent code became a must have.
Code bases became bigger, languages gained more features and syntactical subtleties, and more third-party and open source code started to be pulled into the projects I worked on. I completely changed my attitude towards IDEs. For many years now I’ve been a big believer in IDEs with language-specific intelligence, because they help produce better code faster, and free the programmer to focus on solving algorithmic problems rather than worrying about the details of syntax and style. For the past couple of years I’ve been primarily using Atom because of its excellent integration with git/GitHub and its Python plug-ins, but I am now experimenting with Visual Studio Code.
While I am now a huge believer in IDEs, I’ll never forget the first one that I ever saw, the Cornell Program Synthesizer, and the initial skepticism I had.
Other links: