IEEE Consumer Electronics Magazine - July 2016 - 119

What could be simpler and more
readable? Stored program computers
could do their own programming! The
program was the Formula Translator or,
more familiarly, the Fortran language.
To today's programmers, Fortran is just
another language, and it still has a community of users [1].
Fortran solved the problem of programming. Actually, it solved one problem with programming. It was just the
start of a process of developing vocabularies that bridged our understanding
and the descriptions computing devices
can understand. What does it mean to
understand? That's part of the challenge. By the time I took a class in the
history of programming languages in
1967, our professor, Saul Rosen, had
published a thick collection of papers
Programming Systems & Languages as
people experimented with many
approaches to programming. We started
out with languages specialized for various purposes such as COBOL for business and Lisp for AI. Today's languages
are more general purpose, but we continue to develop vocabularies appropriate to classes of applications.

The ArT of ProgrAmming
I've remained fascinated by programming languages over the years as we
better understood the art of programming. I say art because deciding how to
tell a story is indeed an art. This is why
I chose the name Software Arts for the
company Dan Bricklin and I founded in
1979. An important part of the art of
programming is an articulate understanding of technique. One of the big
challenges is understanding how to
express concepts in terms that the
machine can understand. Even harder,
perhaps, is understanding what the
code is really doing as the number of
interactions increases. As I write this,
I'm trying hard to avoid jargon, but
there are limits, as the very concepts
require their own language. We tend to
use anthropomorphic language to
describe programs, but doing so runs
the risk of inferring too much understanding on the part of the computer.
Object-oriented programming is an
important concept, but stories and engi-

neering don't work if you lose perspective or, more to the point, perspectives.
Objects are useful in organizing programs, but it's important that we're working with representations. A number is a
number that we may interpret as a temperature in Celsius or Fahrenheit depending on the context. Ambiguity is essential
and fundamental. This is why we don't
do serious programming by drawing diagrams. Instead we use words to represent
concepts not just operations. We might
ask a program to print out a date, but the
details depend on the context. Programming can be tedious and error prone,

One of the big challenges
is understanding how to
express concepts in terms
that the machine can
understand.
and in the 1970s, we longed for a programmer's assistant that could keep track
of all the housekeeping tasks. Today's
integrated development environments
(IDEs) are a realization of that dream.
The growth of languages, such as
Python and JavaScript, with a more
relaxed view of objects has demonstrated the value of flexibility. Personally,
I like the approach taken by languages
such as TypeScript, which adds type
annotation to JavaScript. This allows
my assistant, the IDE, to help me. This
works well with my personal style of
kneading code or, to use more common
term, refactoring code, by helping warn
me about conflicts as I evolve the code.
Programs aren't just for web pages.
They also do creative tasks on our
devices (i.e., smartphones) to turn them
into sensors, cameras, or whatever. We
need to do more than continue to
improve on the idea of automatic programming. Software is more about
ideas than putting together programs.

ProgrAmming And
ProgrAmmers
Today, there is a burgeoning demand
for programmers who can take business
rules and represent them in code. Programmers are also needed to handcraft

websites. It is a very labor-intensive
practice and recalls the early days of
automatic programming. We still face
the challenge of translating the concepts into working code. A lot has
changed. Programs have to continue to
evolve over time. It's not so much that
they are written as that they are constantly being rewritten and evolve as
the requirements evolve. As with any
new technology, we start out by substituting programs for older technologies.
Today, much of programming is a
new form of manual labor, building
websites or making things smarter. The
focus is on creating products and the
use cases. To get more of the benefit of
software, we need to provide interfaces,
application program interfaces [2], that
enable users to create their own solutions. This shifts where value is created. We can see this with the Internet,
which changes the business of networking from providing solutions (voice and
reliable delivery) to enable technologies (best efforts packet transport).
We're still navigating the transition.

symbiosis And emPowermenT
In the 1950s, John McCarthy proposed
the idea of multiple people sharing a
single computer-time sharing [3]. He
recognized that there was a key difference between writing a program and
submitting it to run and actively interacting with the computers. The idea of
a man/machine symbiosis continued to
evolve at Massachusetts Institute of
Technology's Project MAC, which was
cofounded by an acoustic psychologist,
JCR Licklider. Licklider played a key
role in ARPA's funding of computer
science research which gave us the
Arpanet and, eventually, the Internet.
My first job, in 1966, was helping to
build an online service that would
allow analysts to explore financial data.
The system, an SDS-940, was developed at Berkeley, and one of its developers, Butler Lampson, consulted for
us and helped develop a tool, First Financial Language, intended for use by
people who didn't consider themselves
programmers. Users would specify
rows and columns. The rows might be
company names (like General Motors)
JULY 2016

IEEE Consumer Electronics Magazine

119

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - July 2016