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

[Mark Janssen]

On Mon, Apr 15, 2013 at 2:06 AM, Uday S Reddy <u.s.reddy at cs.bham.ac.uk> wrote:
> In programming language theory, there is no law to the effect that
> "everything" should be of one kind or another.  So, we would not go with
> Alan Kay's ideal.

I understand.  I state Kay's points to show how the evolution of (this
part of) the programming language world *in practice* has gone in its
explorations.

> 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.

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?

>  Bare storage types
> have predefined operations for 'getting' and 'setting' whereas classes allow
> user-defined operations.  So, the distinction made between them in typical
> programming languages is artificial and implementation-focused.  C and C++
> are especially prone to this problem because they were designed for writing
> compilers and operating systems where proximity to the machine architecture
> seems quite necessary.  The higher-level languages such as Java are moving
> towards abolishing the distinction.

Right, same with Python, but IMO this is where the evolution of
programming languages is going awry.  As languages move away from the
machine, they're getting more based in different and disparate notions
of types.   From a practical standpoint, this makes interoperability
and OOPs desire for "re-useability" recede.

> Here are a couple of references in theoretical work that might be helpful in
> understanding these connections:

Thank you for those references.  I will look into them.

-- 
MarkJ
Tacoma, Washington