[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages

[Uday S Reddy]

Mark Janssen writes:

> > Having said that, theorists do want to unify concepts wherever possible
> > and wherever they make sense.  Imperative programming types, which I
> > will call "storage types", are semantically the same as classes.
> 
> I like that word "storage type", it makes it much clearer what one is
> referring to.

Indeed.  However, this is not the only notion of type in imperative
programming languages.  For example, a function type in C or its descendants
is not there to describe storage, but to describe the interface of an
abstraction.  I will use Reynolds's term "phrase types" to refer to such
types.  Reynolds's main point in "The Essence of Algol" was to say that
phrase types are much more general, and a language can be built around them
in a streamlined way.  Perhaps "Streamlining Algol" would have been a more
descriptive title for his paper.  Nobody should be designing an imperative
programming language without having read "The Essence of Algol", but they
do.

Whether storage types (and their generalization, class types) should be
there in a type system at all is an open question.  I can think of arguments
both ways.  In Java, classes are types.  So are interfaces (i.e., phrase
types).  I think Java does a pretty good job of combining the two
in a harmonious way.

If you have trouble getting hold of "The Essence of Algol", please write to
me privately and I can send you a scanned copy.  The Handout 5B in my
"Principles of Programming Languages" lecture notes is a quick summary of
the Reynolds's type system.

  http://www.cs.bham.ac.uk/~udr/popl/index.html

> I feel like I'm having to "come up to speed" of the academic
> community, but wonder how and why this large chasm happened between
> the applied community and the theoretical.   In my mind, despite the
> ideals of academia, students graduate and they inevitably come to work
> on Turing machines of some kind (Intel hardware, for example,
> currently dominates).  If this is not in some way part of some
> "ideal", why did the business community adopt and deploy these most
> successfully?  Or is it, in some *a priori* way, not possible to apply
> the abstract notions in academia into the real-world?

The chasms are too many, not only between theoretical and applied
communities, but within each of them.  My feeling is that this is
inevitable.  Our field progresses too fast for people to sit back, take
stock of what we have and reconcile the multiple points of view.

There is nothing wrong with "Turing machines".  But the question in
programming language design is how to integrate the Turing machine concepts
with all the other abstractions we need (functions/procedures, modules,
abstract data types etc.), i.e., how to fit the Turing machine concepts into
the "big picture".  That is not an easy question to resolve, and there isn't
a single way of doing it.  So you see multiple approaches being used in the
practical programming languages, some cleaner than the others.

The abstract notions of academia do make it into the real world, but rather
more slowly than one would hope.  Taking Java for example, the initial
versions of Java treated interfaces in a half-hearted way, ignored
generics/polymorphism, and ignored higher-order functions.  But all of them
are slowly making their way into Java, with pressure not only from the
academic community but also through competition from other "practical"
languages like Python, C# and Scala.  If this kind of progress continues,
that is the best we can hope for in a fast-paced field like ours.

Cheers,
Uday Reddy

-- 
Prof. Uday Reddy                Tel: +44 121 414 2740             
Professor of Computer Science   Fax: +44 121 414 4281
School of Computer Science      
University of Birmingham        Email: U.S.Reddy at cs.bham.ac.uk      
Edgbaston                       
Birmingham B15 2TT              Web: http://www.cs.bham.ac.uk/~udr