On Mon, Apr 15, 2013 at 2:06 AM, Uday S Reddy <u.s.re...@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 -- http://mail.python.org/mailman/listinfo/python-list
