Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Uday S Reddy於 2013年4月17日星期三UTC+8下午5時10分58秒寫道： 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. The imperative part is supported in Python by tuples only. The name binding assignment of an object is perative in Python. Anyway it is not so difficult to mimic the behaviors and to gain the benefits of imperative languages at least in the c-python implementation by those who can play with the Python language in programming. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Thu, Apr 18, 2013 at 11:31 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: I don't quite think I understand what you are saying. Are you saying that mathematical models are not a good foundation for computer science because computers are really made out of electronic gates? No, I'm really trying to point out that models based on Digital Logic vs. models based on Symbolic Logic are completely different -- they have different basiis. They are both types of Maths, and that you can interchange them as a demonstration doesn't actually help the practical issue of keeping the two domains separate -- they have differing logics. It's like the domain of Natural numbers vs. the Complex, or perhaps the Natural and the Real. Yes you can translate back and forth, but they are for all practical purposes distinct and can't be mixed. All I need to do is show that my model reduces to some basic physical implementation (with perhaps some allowances for infinity) and then I can promptly forget about that messy business and proceed to use my clean mathematical model. If that's all you want to do, you can stick with Boolean Logic. The reason any model of computation exists is that it is easier to think about a problem in some terms than in others. By showing how to transform one model to another you make it possible to choose exactly how you wish to solve a problem. Yes, and I'm attempting to provide an argument that the (historically?) dominant model of symbolic calculus is misinforming the practical domain of working out differences and arguments within my own domain of the programming community. Unfortunately, my inexperience with the literature is actually betraying the validity of my point. The reason we do not work directly in what are called von Neumann machines is that they are not convenient for all kinds of problems. However we can build a compiler to translate anything to anything else so we I don't see why anybody would care. I'm trying to say that *I* care, because I can't seem to find the common ground that affects 1000's of people in the applied C.S. domain with the 1000's of people in the theoretical C.S. domain. MarkJ Tacoma -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
I think there is some misunderstanding here. Being mathematical in academic work is a way of making our ideas rigorous and precise, instead of trying to peddle wooly nonsense. I'm sorry. I am responsible for the misunderstanding. I used the word math when I really mean symbolic logic (which, historically, was part of philosophy). My point is that the field is confusing because it seems to ignore binary logic in favor of symbolic logic. Is binary logic not rigorous and precise enough? -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Ned Batchelder於 2013年4月20日星期六UTC+8上午12時41分03秒寫道： On 4/19/2013 12:16 PM, Steven D'Aprano wrote: On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith wrote: PS: a great C++ interview question is, What's the difference between a class and a struct? Amazing how few self-professed C++ experts have no clue. I'm not a C++ expert, but I am an inquiring mind, and I want to know the answer! The only difference between a class and a struct is that classes default to private access for their members, and structs default to public. --Ned. In python even a class can be decorated. Also features of instances can be added at run time from programs by different programmers or even programs from machines by the code generation scheme used in many CAD tools. Nowadays the concept of a structure is not clear without specifying the language used in programming. A list is a structure of non-homogeneous types of items in LISP, PERL and PYTHON. But the cases are different in C++, PASCAL, ADDA, JAVA -- http://mail.python.org/mailman/listinfo/python-list
RE: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Date: Thu, 18 Apr 2013 15:53:15 -0700 From: dreamingforw...@gmail.com To: types-l...@lists.seas.upenn.edu Subject: Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages I am very thankful for the references given by everyone. Unfortunately my library does not have the titles and it will be some time before I can acquire them. The official version of my PhD thesis is available at https://scholarship.rice.edu/handle/1911/70199 (A version more suitable for electronic browsing and online distribution is available at http://sdrv.ms/15qsJ5x ) -Moez -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
I don't quite think I understand what you are saying. Are you saying that mathematical models are not a good foundation for computer science because computers are really made out of electronic gates? All I need to do is show that my model reduces to some basic physical implementation (with perhaps some allowances for infinity) and then I can promptly forget about that messy business and proceed to use my clean mathematical model. The reason any model of computation exists is that it is easier to think about a problem in some terms than in others. By showing how to transform one model to another you make it possible to choose exactly how you wish to solve a problem. The reason we do not work directly in what are called von Neumann machines is that they are not convenient for all kinds of problems. However we can build a compiler to translate anything to anything else so we I don't see why anybody would care. On Thu, Apr 18, 2013 at 5:53 PM, Mark Janssen dreamingforw...@gmail.comwrote: [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list] On Mon, Apr 15, 2013 at 2:53 AM, Moez AbdelGawad moeza...@outlook.com wrote: I'm not quite sure I understand your question, but I'll give it a shot. :-) I'm in this same camp too :) I am very thankful for the references given by everyone. Unfortunately my library does not have the titles and it will be some time before I can acquire them. I hope it not too intrusive to offer a few points that I've garnered from this conversation until I can study the history further. The main thing that I notice is that there is a heavy bias in academia towards mathematical models. I understand that Turing Machines, for example, were originally abstract computational concepts before there was an implementation in hardware, so I have some sympathies with that view, yet, should not the Science of Computer Science concern itself with how to map these abstract computational concepts into actual computational hardware? Otherwise, why not keep the field within mathematics and philosophy (where Logic traditionally has been)? I find it remarkable, for example, that the simple continued application of And/Or/Not gates can perform all the computation that C.S. concerns itself with and these form the basis for computer science in my mind, along with Boolean logic. (The implementation of digital logic into physical hardware is where C.S. stops and Engineering begins, I would argue.) But still, it seems that there are two ends, two poles, to the whole computer science enterprise that haven't been sufficiently *separated* so that they can be appreciated: logic gates vs. logical calculus and symbols. There is very little crossover as I can see. Perhaps the problem is the common use of the Greek root logikos; in the former, it pertains to binary arithmetic, where in the latter, it retains it's original Greek pertaining to *speech* and symbols, logos). Further, one can notice that in the former, the progression has been towards more sophisticated Data Structures (hence the evolution towards Object-Orientation), where in the latter (I'm guessing, since it's not my area of expertise) the progression has been towards function sophistication (where recursion seems to be paramount). In any case, I look forward to diving into the books and references you've all offered so generously so that I can appreciate the field and its history better. Mark Janssen Pacific Lutheran University Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Mark Janssen writes: The main thing that I notice is that there is a heavy bias in academia towards mathematical models. I understand that Turing Machines, for example, were originally abstract computational concepts before there was an implementation in hardware, so I have some sympathies with that view, yet, should not the Science of Computer Science concern itself with how to map these abstract computational concepts into actual computational hardware? I think there is some misunderstanding here. Being mathematical in academic work is a way of making our ideas rigorous and precise, instead of trying to peddle wooly nonsense. Providing a mathematical description does not imply in any way that these ideas are not implementable on machines. In fact, very often these mathematical descriptions state precisely how to implement the concepts (called operational semantics), but using mathematical notation instead of program code. The mathematical notation used here is usually no more than high school set theory, used in a stylized way. In contrast, there are deeper mathematical models (called denotational semantics and axiomatic semantics) which are invented to describe how programming language features work in a deep, intrinsic way. This is similar to, for instance, how Physics invents mathematical models to capture how the nature around us works. Physicists don't need to implement nature. It has already been implemented for us before we are born. However, to understand how it works, and how to design systems using physical materials in a predictable way, we need the mathematical models that Physics has develeped. Similarly, the mathematical models of programming languages help us to obtain a deep understanding of how languages work and how to build systems in a predictable, reliable way. It seems too much to expect, at the present stage of our field, that all programmers should understand the mathematical models. But I would definitely expect that programming language designers who are trying to build new languages should understand the mathematical models. Otherwise, they would be like automotive engineers trying to build cars without knowing any Mechanics. Cheers, Uday Reddy -- Prof. Uday ReddyTel: +44 121 414 2740 Professor of Computer Science Fax: +44 121 414 4281 School of Computer Science University of BirminghamEmail: u.s.re...@cs.bham.ac.uk Edgbaston Birmingham B15 2TT Web: http://www.cs.bham.ac.uk/~udr -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
The main thing that I notice is that there is a heavy bias in academia towards mathematical models. I understand that Turing Machines, for example, were originally abstract computational concepts before there was an implementation in hardware, so I have some sympathies with that view, yet, should not the Science of Computer Science concern itself with how to map these abstract computational concepts into actual computational hardware? I prefer to think of Turing machines as an attempt to model existing and imagined hardware (at the time, mostly human computers, or groups of them with comparatively simple tools). See sections 1. and 9. in Turing, On computable numbers, with an application to the Entscheidungsproblem, http://web.comlab.ox.ac.uk/oucl/research/areas/ieg/e-library/sources/tp2-ie.pdf Modeling existing systems, in order to be able to reason about them, is essential for science, as is translating models into experiments, in order to compare predictions to reality. Claus -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Thu, 18 Apr 2013 17:14:13 -0400, Robert Harper wrote: In short, there is no such thing as a paradigm. Of course there is. A paradigm is a distinct way of thinking, a philosophy if you will. To say that there is no such thing as a paradigm is to say that all ways of thinking about a topic are the same, and that's clearly nonsense. OOP is a distinct paradigm from procedural programming, even though the distinctions are minor when compared to those between imperative and functional programming. Java's everything in a class style of programming is very distinct from Pascal's functions and records style of programming, even though both are examples of imperative programming. They lead to different styles of coding, they have different strengths and weaknesses, and even taking into account differences of syntax, they differ in what you can do simply and naturally without the language getting in the way. I agree fully. This term is a holdover from the days when people spent time and space trying to build taxonomies based on ill-defined superficialities. See Steve Gould's essay What, If Anything, Is A Zebra?. You'll enjoy learning that there is, in fact, no such thing as a zebra---there are, rather, three different striped horse-like mammals, two of which are genetically related, and one of which is not. All life on earth is genetically related. Even if the so-called tree of life doesn't have a single common ancestor, it has a single set of common ancestors. In the case of the three species of zebra, they are all members of the genus Equus, so they are actually *extremely* closely related. The argument that zebra is not a genealogical group (which is very different from the false statement that there is no such thing as a zebra!) is that one of the three species of zebra is in fact more closely related to non-zebras than the other two species of zebra. Something like this tree: Common ancestor of all Equus | +-- Common ancestor of Burchell's Zebras and Grevy's Zebras | +-- Burchell's Zebra | +-- Grevy's Zebra | +-- Common ancestor of horses and Mountain Zebras +-- Horse +-- Mountain Zebra (I've left out asses and donkeys because I'm not sure where they fit in relation to the others.) There's no natural genealogical group that includes all three species of zebra that doesn't also include horses. But that doesn't mean that there's no reasonable non-genealogical groups! For example, all three species of zebra have fewer than 50 chromosome pairs, while all other Equus species have more than 50 pairs. Based on physical characteristics rather than ancestry, zebras make up a perfectly good group, distinct from other members of Equus. To put it another way, the three species of zebra may not make up a natural group when considered by lines of descent, but they do make up a natural group when considered by other factors. The propensity to be striped, like the propensity to have five things (fingers, segments, whatever) is a deeply embedded genetic artifact that expresses itself in various ways. Zebra is not a classification of thing that is striped, but a specific subset of such things, and stripes are only one of many distinguishing features. Cladistics is an important classification scheme, but it is not the only valid such scheme. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
In article 517131cd$0$29977$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 18 Apr 2013 17:14:13 -0400, Robert Harper wrote: In short, there is no such thing as a paradigm. Of course there is. A paradigm is a distinct way of thinking, a philosophy if you will. To say that there is no such thing as a paradigm is to say that all ways of thinking about a topic are the same, and that's clearly nonsense. This thread has gone off in a strange direction. When I said: One of the nice things about OOP is it means so many different things to different people. All of whom believe with religious fervor that they know the true answer. I was indeed talking about the ways people think about programming. For example, OOP in C++ is very much about encapsulation. People declare all data private, and writing setter/getter functions which carefully control what access outside entities have to your data. Often, when you talk to C++ people, they will tell you that encapsulation is what OOP is all about. What they are doing is saying, C++ isa OOPL, and C++ has encapsulation, therefore OOPL implies encapsulation. When they look at something like Python, they say, That's not object oriented because you don't have private data. I suppose people who grew up learning Python as their first language look at something like C++ and say, That's not OOP because classes aren't objects, or something equally silly. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith r...@panix.com wrote: I was indeed talking about the ways people think about programming. For example, OOP in C++ is very much about encapsulation. People declare all data private, and writing setter/getter functions which carefully control what access outside entities have to your data. The funny thing about that notion is that, even in C++, it's completely optional. I've subclassed someone else's class using a struct and just left everything public. In fact, I've gotten so used to the Python way of doing things that now I'm quite happy to run everything public anyway. Is OOP truly about X if X is optional? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
In article mailman.821.1366378384.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Fri, Apr 19, 2013 at 11:07 PM, Roy Smith r...@panix.com wrote: I was indeed talking about the ways people think about programming. For example, OOP in C++ is very much about encapsulation. People declare all data private, and writing setter/getter functions which carefully control what access outside entities have to your data. The funny thing about that notion is that, even in C++, it's completely optional. Well, yeah: #define private public #define protected public #include whatever.h Not to mention all sorts of horrible things you can do with pointers and const_cast, etc. But that doesn't stop people from thinking that somehow they've built some uber-protected cocoon around their data, and that this is part and parcel of what OOPL is all about. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith r...@panix.com wrote: #define private public #define protected public #include whatever.h And: #define class struct But what I mean is that, _in my design_, I make everything public. No getters/setters, just direct member access. The theory behind getters and setters is that you can change the implementation without changing the interface... but I cannot remember a *single time* when I have made use of that flexibility. Not one. Nor a time when I've wished for that flexibility, after coding without it. No no, not one! ChrisA (He's telling the truth, he is not Mabel.) -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
In article mailman.824.1366386029.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sat, Apr 20, 2013 at 1:31 AM, Roy Smith r...@panix.com wrote: #define private public #define protected public #include whatever.h And: #define class struct I suppose, while we're at it: # define const (I think that works, not sure). PS: a great C++ interview question is, What's the difference between a class and a struct? Amazing how few self-professed C++ experts have no clue. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith wrote: PS: a great C++ interview question is, What's the difference between a class and a struct? Amazing how few self-professed C++ experts have no clue. I'm not a C++ expert, but I am an inquiring mind, and I want to know the answer! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Fri, 19 Apr 2013 09:07:15 -0400, Roy Smith wrote: Often, when you talk to C++ people, they will tell you that encapsulation is what OOP is all about. What they are doing is saying, C++ isa OOPL, and C++ has encapsulation, therefore OOPL implies encapsulation. When they look at something like Python, they say, That's not object oriented because you don't have private data. I suppose people who grew up learning Python as their first language look at something like C++ and say, That's not OOP because classes aren't objects, or something equally silly. You might say that, but I find in my experience that Python users don't tend to fall for the No True Scotsman fallacy anywhere near as often as (say) Java or C++ users. I'm not sure what the reason for this is. Perhaps it is that the Python community as a whole is more open to other languages and paradigms, and less stuffed to the gills with code monkeys who only know how to copy and paste code from StackOverflow. The Python community frequently tosses around references to other languages, compares how Python would do something to other languages, or relates how certain features were borrowed from language X (e.g. list comprehensions are taken from Haskell; map, filter and reduce are taken from Lisp). But when I read forums and blogs about (say) Java, it's nearly always about Java in isolation, and one would be forgiven for thinking it was the only programming language in existence. I don't think that there is One True Way to design an OOP language, but I do think there are *degrees* of OOP. Java, for instance, I would say is only moderately OOP, since classes aren't objects, and it supports unboxed native types. I think the first part of that is a weakness, and the second is a pragmatic decision that on balance probably is a strength. Yes, Python's everything is an object is a cleaner design, but Java's unboxed types leads to faster code. It also depends on what you mean by OOP. If we judge Python by the fact that everything is an object, then it is strongly OOP. But if we judge Python by its syntax and idioms, it is only weakly OOP, even less than Java. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On 4/19/2013 12:16 PM, Steven D'Aprano wrote: On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith wrote: PS: a great C++ interview question is, What's the difference between a class and a struct? Amazing how few self-professed C++ experts have no clue. I'm not a C++ expert, but I am an inquiring mind, and I want to know the answer! The only difference between a class and a struct is that classes default to private access for their members, and structs default to public. --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Fri, Apr 19, 2013 at 4:16 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith wrote: PS: a great C++ interview question is, What's the difference between a class and a struct? Amazing how few self-professed C++ experts have no clue. I'm not a C++ expert, but I am an inquiring mind, and I want to know the answer! C++ class members are private by default; struct members are public by default. That's the only difference as I recall. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
I wrote: I suppose people who grew up learning Python as their first language look at something like C++ and say, That's not OOP because classes aren't objects, or something equally silly. In article 517172e7$0$29977$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: You might say that, but I find in my experience that Python users don't tend to fall for the No True Scotsman fallacy anywhere near as often as (say) Java or C++ users. Now that I think about it, I suspect relatively few people learned Python as their first programming language. Java, for example, is very popular as a teaching language in colleges and universities. There are lots of people who go through a 4-year program, do all of their coursework in Java, and come out as one-trick ponies. There aren't many schools who teach Python as a first (and only language), but I suppose it's starting to catch on. 5 years from now, we may see waves of kids graduating from college knowing nothing but Python, with a similarly narrow view of the universe. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
In article mailman.843.1366412626.3114.python-l...@python.org, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Fri, 19 Apr 2013 12:02:00 -0400, Roy Smith r...@panix.com declaimed the following in gmane.comp.python.general: PS: a great C++ interview question is, What's the difference between a class and a struct? Amazing how few self-professed C++ experts have no clue. It's been 15+ years but... class defaults to private; struct defaults to public... (very simplified G) You were doing well until you added the very simplified part :-) That is indeed the only difference. Many people are surprised that you can write member functions for structs. Or that you can subclass (substruct?) them. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Fri, 19 Apr 2013 19:37:38 -0400, Roy Smith wrote: There aren't many schools who teach Python as a first (and only language), but I suppose it's starting to catch on. 5 years from now, we may see waves of kids graduating from college knowing nothing but Python, with a similarly narrow view of the universe. Send the young whipper-snappers here, we'll soon learn 'em better! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Warning, this is a bit of a rant. That paragraph from Wikipedia seems to be confused. It gives the fourth paradigm as declarative but then says first order logic for logic programming. It seems somebody did an incomplete replacement of declarative for logic. Wikipedia is often schizophrenic like that. Personally, I think that object oriented and logical programming only became official paradigms because there was a certain level of hype for them in the 1980s and nobody has thought to strike them off the list after the hype died down. Object-oriented, as constituted today, is just a layer of abstraction over imperative programming (or imperative style programming in functional languages, because objects require side-effects). What object-oriented language actually in use now isn't just an imperative language with fancy abstraction mechanisms? The problem with having declarative languages as a paradigm (which logical languages would be a part) is that it feels like it should be a miscellaneous category. Being declarative doesn't tell you much except that some machine is going to turn your descriptions of something into some kind of action. In logical programming it is a set of predicates, but it could just as easily be almost anything else. In a way all languages are declarative, it is just that we have some standard interpretations of what is declared that are very common (imperative and functional). My wish is that the idea of there being four paradigms would be abandoned the same we the idea of four food groups has been abandoned (which may surprise some of you). We have more than four different modes of thinking when programming and some are much more important than others and some are subsets of others. We should teach students a more sophisticated view. Ironically Wikipedia also shows us this complexity. The programming language paradigm side bar actually reveals the wealth of different styles that are available. There is simply no clean and useful way to overlay the four paradigms over what we see there, so it should be abandoned because it gives students a false idea. On Wed, Apr 17, 2013 at 9:42 AM, Andreas Abel andreas.a...@ifi.lmu.dewrote: [ The Types Forum, http://lists.seas.upenn.edu/** mailman/listinfo/types-listhttp://lists.seas.upenn.edu/mailman/listinfo/types-list] On 17.04.2013 11:30, Uday S Reddy wrote: Mark Janssen writes: From: en.wikipedia.org: Programming_paradigm: A programming paradigm is a fundamental style of computer programming. There are four main paradigms: object-oriented, imperative, functional and declarative. Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming. I removed the second sentence relating paradigms to computation models and put it on the talk page instead. It does not make sense to connect imperative programming to Turing machines like functional programming to lambda calculus. A better match would be random access machines, but the whole idea of a connection between a programming paradigm and a computation model is misleading. While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? And, 2) If so, shouldn't a theory of types announce what model of computation they are working from? These distinctions are not fully valid. - Functional programming, logic programming and imperative programming are three different *computational mechanisms*. - Object-orientation and abstract data types are two different ways of building higher-level *abstractions*. The authors of this paragraph did not understand that computational mechanisms and higher-level abstractions are separate, orthogonal dimensions in programming language design. All six combinations, obtained by picking a computational mechanism from the first bullet and an abstraction mechanism from the second bullet, are possible. It is a mistake to put object-orientation in the first bullet. Their idea of paradigm is vague and ill-defined. Cheers, Uday Reddy -- Andreas AbelDu bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.a...@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ http://www2.tcs.ifi.lmu.de/~abel/ -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
In short, there is no such thing as a paradigm. I agree fully. This term is a holdover from the days when people spent time and space trying to build taxonomies based on ill-defined superficialities. See Steve Gould's essay What, If Anything, Is A Zebra?. You'll enjoy learning that there is, in fact, no such thing as a zebra---there are, rather, three different striped horse-like mammals, two of which are genetically related, and one of which is not. The propensity to be striped, like the propensity to have five things (fingers, segments, whatever) is a deeply embedded genetic artifact that expresses itself in various ways. Bob Harper On Apr 18, 2013, at 2:48 PM, Jason Wilkins wrote: [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ] Warning, this is a bit of a rant. That paragraph from Wikipedia seems to be confused. It gives the fourth paradigm as declarative but then says first order logic for logic programming. It seems somebody did an incomplete replacement of declarative for logic. Wikipedia is often schizophrenic like that. Personally, I think that object oriented and logical programming only became official paradigms because there was a certain level of hype for them in the 1980s and nobody has thought to strike them off the list after the hype died down. Object-oriented, as constituted today, is just a layer of abstraction over imperative programming (or imperative style programming in functional languages, because objects require side-effects). What object-oriented language actually in use now isn't just an imperative language with fancy abstraction mechanisms? The problem with having declarative languages as a paradigm (which logical languages would be a part) is that it feels like it should be a miscellaneous category. Being declarative doesn't tell you much except that some machine is going to turn your descriptions of something into some kind of action. In logical programming it is a set of predicates, but it could just as easily be almost anything else. In a way all languages are declarative, it is just that we have some standard interpretations of what is declared that are very common (imperative and functional). My wish is that the idea of there being four paradigms would be abandoned the same we the idea of four food groups has been abandoned (which may surprise some of you). We have more than four different modes of thinking when programming and some are much more important than others and some are subsets of others. We should teach students a more sophisticated view. Ironically Wikipedia also shows us this complexity. The programming language paradigm side bar actually reveals the wealth of different styles that are available. There is simply no clean and useful way to overlay the four paradigms over what we see there, so it should be abandoned because it gives students a false idea. On Wed, Apr 17, 2013 at 9:42 AM, Andreas Abel andreas.a...@ifi.lmu.dewrote: [ The Types Forum, http://lists.seas.upenn.edu/** mailman/listinfo/types-listhttp://lists.seas.upenn.edu/mailman/listinfo/types-list] On 17.04.2013 11:30, Uday S Reddy wrote: Mark Janssen writes: From: en.wikipedia.org: Programming_paradigm: A programming paradigm is a fundamental style of computer programming. There are four main paradigms: object-oriented, imperative, functional and declarative. Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming. I removed the second sentence relating paradigms to computation models and put it on the talk page instead. It does not make sense to connect imperative programming to Turing machines like functional programming to lambda calculus. A better match would be random access machines, but the whole idea of a connection between a programming paradigm and a computation model is misleading. While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? And, 2) If so, shouldn't a theory of types announce what model of computation they are working from? These distinctions are not fully valid. - Functional programming, logic programming and imperative programming are three different *computational mechanisms*. - Object-orientation and abstract data types are two different ways of building higher-level *abstractions*. The authors of this paragraph did not understand that computational mechanisms and higher-level abstractions are separate, orthogonal dimensions in programming language design. All six combinations, obtained by picking a computational mechanism from the first bullet and an abstraction mechanism from the second bullet, are possible. It is a mistake to put object-orientation in the first bullet.
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
The term declarative never meant a damn thing, but was often used, absurdly, to somehow lump together functional programming with logic programming, and separate it from imperative programming. It never made a lick of sense; it's just a marketing term. Bob Harper On Apr 18, 2013, at 2:48 PM, Jason Wilkins wrote: [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ] Warning, this is a bit of a rant. That paragraph from Wikipedia seems to be confused. It gives the fourth paradigm as declarative but then says first order logic for logic programming. It seems somebody did an incomplete replacement of declarative for logic. Wikipedia is often schizophrenic like that. Personally, I think that object oriented and logical programming only became official paradigms because there was a certain level of hype for them in the 1980s and nobody has thought to strike them off the list after the hype died down. Object-oriented, as constituted today, is just a layer of abstraction over imperative programming (or imperative style programming in functional languages, because objects require side-effects). What object-oriented language actually in use now isn't just an imperative language with fancy abstraction mechanisms? The problem with having declarative languages as a paradigm (which logical languages would be a part) is that it feels like it should be a miscellaneous category. Being declarative doesn't tell you much except that some machine is going to turn your descriptions of something into some kind of action. In logical programming it is a set of predicates, but it could just as easily be almost anything else. In a way all languages are declarative, it is just that we have some standard interpretations of what is declared that are very common (imperative and functional). My wish is that the idea of there being four paradigms would be abandoned the same we the idea of four food groups has been abandoned (which may surprise some of you). We have more than four different modes of thinking when programming and some are much more important than others and some are subsets of others. We should teach students a more sophisticated view. Ironically Wikipedia also shows us this complexity. The programming language paradigm side bar actually reveals the wealth of different styles that are available. There is simply no clean and useful way to overlay the four paradigms over what we see there, so it should be abandoned because it gives students a false idea. On Wed, Apr 17, 2013 at 9:42 AM, Andreas Abel andreas.a...@ifi.lmu.dewrote: [ The Types Forum, http://lists.seas.upenn.edu/** mailman/listinfo/types-listhttp://lists.seas.upenn.edu/mailman/listinfo/types-list] On 17.04.2013 11:30, Uday S Reddy wrote: Mark Janssen writes: From: en.wikipedia.org: Programming_paradigm: A programming paradigm is a fundamental style of computer programming. There are four main paradigms: object-oriented, imperative, functional and declarative. Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming. I removed the second sentence relating paradigms to computation models and put it on the talk page instead. It does not make sense to connect imperative programming to Turing machines like functional programming to lambda calculus. A better match would be random access machines, but the whole idea of a connection between a programming paradigm and a computation model is misleading. While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? And, 2) If so, shouldn't a theory of types announce what model of computation they are working from? These distinctions are not fully valid. - Functional programming, logic programming and imperative programming are three different *computational mechanisms*. - Object-orientation and abstract data types are two different ways of building higher-level *abstractions*. The authors of this paragraph did not understand that computational mechanisms and higher-level abstractions are separate, orthogonal dimensions in programming language design. All six combinations, obtained by picking a computational mechanism from the first bullet and an abstraction mechanism from the second bullet, are possible. It is a mistake to put object-orientation in the first bullet. Their idea of paradigm is vague and ill-defined. Cheers, Uday Reddy -- Andreas AbelDu bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.a...@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ http://www2.tcs.ifi.lmu.de/~abel/ -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Mon, Apr 15, 2013 at 2:53 AM, Moez AbdelGawad moeza...@outlook.com wrote: I'm not quite sure I understand your question, but I'll give it a shot. :-) I'm in this same camp too :) I am very thankful for the references given by everyone. Unfortunately my library does not have the titles and it will be some time before I can acquire them. I hope it not too intrusive to offer a few points that I've garnered from this conversation until I can study the history further. The main thing that I notice is that there is a heavy bias in academia towards mathematical models. I understand that Turing Machines, for example, were originally abstract computational concepts before there was an implementation in hardware, so I have some sympathies with that view, yet, should not the Science of Computer Science concern itself with how to map these abstract computational concepts into actual computational hardware? Otherwise, why not keep the field within mathematics and philosophy (where Logic traditionally has been)? I find it remarkable, for example, that the simple continued application of And/Or/Not gates can perform all the computation that C.S. concerns itself with and these form the basis for computer science in my mind, along with Boolean logic. (The implementation of digital logic into physical hardware is where C.S. stops and Engineering begins, I would argue.) But still, it seems that there are two ends, two poles, to the whole computer science enterprise that haven't been sufficiently *separated* so that they can be appreciated: logic gates vs. logical calculus and symbols. There is very little crossover as I can see. Perhaps the problem is the common use of the Greek root logikos; in the former, it pertains to binary arithmetic, where in the latter, it retains it's original Greek pertaining to *speech* and symbols, logos). Further, one can notice that in the former, the progression has been towards more sophisticated Data Structures (hence the evolution towards Object-Orientation), where in the latter (I'm guessing, since it's not my area of expertise) the progression has been towards function sophistication (where recursion seems to be paramount). In any case, I look forward to diving into the books and references you've all offered so generously so that I can appreciate the field and its history better. Mark Janssen Pacific Lutheran University Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Thu, Apr 18, 2013 at 4:53 PM, Mark Janssen dreamingforw...@gmail.com wrote: The main thing that I notice is that there is a heavy bias in academia towards mathematical models. I understand that Turing Machines, for example, were originally abstract computational concepts before there was an implementation in hardware, so I have some sympathies with that view, yet, should not the Science of Computer Science concern itself with how to map these abstract computational concepts into actual computational hardware? Why? You seem to have a notion that theoretical computer science is ultimately about programming. It's not, any more than theoretical physics is ultimately about how to build skyscrapers. Theoreticians don't discuss complicated languages like Python because it would be difficult to prove anything about computation using them. Programmers don't use constructs like Turing machines because they're not practical or useful for doing actual programming with. We're talking about two different groups of people who use different tools because they have very different objectives. Otherwise, why not keep the field within mathematics and philosophy (where Logic traditionally has been)? Well now, that's an age-old debate. Ultimately what we call computer science does not encompass one single discipline. But I think they are generally kept under one academic umbrella because they are closely related, and there is value in working with colleagues in separate sub-fields. Certainly there is value in being passingly familiar with the theory side of things if one is going to be designing languages and writing parsers. Less so if one is primarily occupied with building inventory systems. But still, it seems that there are two ends, two poles, to the whole computer science enterprise that haven't been sufficiently *separated* so that they can be appreciated: logic gates vs. logical calculus and symbols. There is very little crossover as I can see. Perhaps the problem is the common use of the Greek root logikos; in the former, it pertains to binary arithmetic, where in the latter, it retains it's original Greek pertaining to *speech* and symbols, logos). Further, one can notice that in the former, the progression has been towards more sophisticated Data Structures (hence the evolution towards Object-Orientation), where in the latter (I'm guessing, since it's not my area of expertise) the progression has been towards function sophistication (where recursion seems to be paramount). Okay, you've lost me again. What do logic gates have to do with data structures and OOP? What does symbolic logic have to do with functional programming? -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
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 ReddyTel: +44 121 414 2740 Professor of Computer Science Fax: +44 121 414 4281 School of Computer Science University of BirminghamEmail: u.s.re...@cs.bham.ac.uk Edgbaston Birmingham B15 2TT Web: http://www.cs.bham.ac.uk/~udr -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Mark Janssen writes: From: en.wikipedia.org: Programming_paradigm: A programming paradigm is a fundamental style of computer programming. There are four main paradigms: object-oriented, imperative, functional and declarative. Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming. While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? And, 2) If so, shouldn't a theory of types announce what model of computation they are working from? These distinctions are not fully valid. - Functional programming, logic programming and imperative programming are three different *computational mechanisms*. - Object-orientation and abstract data types are two different ways of building higher-level *abstractions*. The authors of this paragraph did not understand that computational mechanisms and higher-level abstractions are separate, orthogonal dimensions in programming language design. All six combinations, obtained by picking a computational mechanism from the first bullet and an abstraction mechanism from the second bullet, are possible. It is a mistake to put object-orientation in the first bullet. Their idea of paradigm is vague and ill-defined. Cheers, Uday Reddy -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
If you have trouble getting hold of The Essence of Algol, ... There seems to be a downloadable copy at: www.cs.cmu.edu/~crary/819-f09/Reynolds81.ps It's in PostScript, which is easily convertible to PDF if you wish. Nikhil On Wed, Apr 17, 2013 at 5:30 AM, Uday S Reddy u.s.re...@cs.bham.ac.ukwrote: [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list] Mark Janssen writes: From: en.wikipedia.org: Programming_paradigm: A programming paradigm is a fundamental style of computer programming. There are four main paradigms: object-oriented, imperative, functional and declarative. Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming. While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? And, 2) If so, shouldn't a theory of types announce what model of computation they are working from? These distinctions are not fully valid. - Functional programming, logic programming and imperative programming are three different *computational mechanisms*. - Object-orientation and abstract data types are two different ways of building higher-level *abstractions*. The authors of this paragraph did not understand that computational mechanisms and higher-level abstractions are separate, orthogonal dimensions in programming language design. All six combinations, obtained by picking a computational mechanism from the first bullet and an abstraction mechanism from the second bullet, are possible. It is a mistake to put object-orientation in the first bullet. Their idea of paradigm is vague and ill-defined. Cheers, Uday Reddy -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On 17.04.2013 11:30, Uday S Reddy wrote: Mark Janssen writes: From: en.wikipedia.org: Programming_paradigm: A programming paradigm is a fundamental style of computer programming. There are four main paradigms: object-oriented, imperative, functional and declarative. Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming. I removed the second sentence relating paradigms to computation models and put it on the talk page instead. It does not make sense to connect imperative programming to Turing machines like functional programming to lambda calculus. A better match would be random access machines, but the whole idea of a connection between a programming paradigm and a computation model is misleading. While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? And, 2) If so, shouldn't a theory of types announce what model of computation they are working from? These distinctions are not fully valid. - Functional programming, logic programming and imperative programming are three different *computational mechanisms*. - Object-orientation and abstract data types are two different ways of building higher-level *abstractions*. The authors of this paragraph did not understand that computational mechanisms and higher-level abstractions are separate, orthogonal dimensions in programming language design. All six combinations, obtained by picking a computational mechanism from the first bullet and an abstraction mechanism from the second bullet, are possible. It is a mistake to put object-orientation in the first bullet. Their idea of paradigm is vague and ill-defined. Cheers, Uday Reddy -- Andreas AbelDu bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.a...@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/ -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
I'm not quite sure I understand your question, but I'll give it a shot. :-) Thank you, and my apologies for my late reply. The C/C++ model, in which the types are anchored to the machine hardware, in the exception, not the rule. In the academic literature, type theory is almost entirely focused on studying abstract models of computation that are purely mathematical, and bear no resemblance to the underlying hardware. The lambda calculus is the most general, and most commonly used formalism, but there are many others; e.g. Featherweight Java provides a formal model of objects and classes as they are used in Java. Understood, but I feel this is where theory has gone too far away from reality. Wikipedia (admittedly not an authoritative resource), lists a clear distinction between languages rooted to the Turing machine, and those rooted in lambda calculus: From: en.wikipedia.org: Programming_paradigm: A programming paradigm is a fundamental style of computer programming. There are four main paradigms: object-oriented, imperative, functional and declarative. Their foundations are distinct models of computation: Turing machine for object-oriented and imperative programming, lambda calculus for functional programming, and first order logic for logic programming. While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? And, 2) If so, shouldn't a theory of types announce what model of computation they are working from? You say the C/C++ model is the exception, but in the programmer community (excepting web-based languages) it is the opposite. The machine model dominates. In fact, I'm not even sure how Java operates, but through some sorcery I don't want to take part in. Types and Programming Languages, by Benjamin Pierce, is an excellent introductory textbook which describes how various language features, including objects, can be formalized. If you are interested in OOP, Abadi and Cardelli's Theory of Objects is the obvious place to start, although I'd recommend reading Pierce's book first if you want to understand it. :-) Abadi and Cardelli discuss both class-based languages, and pure object languages. If you are interested in the type/object distinction in particular, then I'll shamelessly plug my own thesis: Pure Subtype Systems (available online), which describes a formal model in which types are objects, and objects are types. If you are familiar with the Self language, then you can think of it as a type system for Self. Thank you very much. I will look for them. Once you have a type system in place, it's usually fairly straightforward to compile a language down to actual hardware. An interpreter, like that used in Python, is generally needed only for untyped or dynamic languages. There are various practical considerations -- memory layout, boxed or unboxed data types, garbage collection, etc. -- but the basic techniques are described in any compiler textbook. Research in the areas of typed assembly languages and proof carrying code are concerned with ensuring that the translation from high-level language to assembly language is sound, and well-typed at all stages. Very interesting. I appreciate the those leads -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
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
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Tue, Apr 16, 2013 at 5:16 PM, Mark Janssen dreamingforw...@gmail.com wrote: Understood, but I feel this is where theory has gone too far away from reality. How so? Turing machines and lambda calculus were both invented in the 30s, before any real mechanical computers existed. If anything, it is programming that has strayed too far from theory. ;-) While I understand the interest in purely theoretical models, I wonder two things: 1) Are these distinct models of computation valid? If they provide an algorithmic/mechanical means of solving problems, then they are valid models of computation. An abacus is a valid model of computation, although I wouldn't want to compute a million digits of pi on it. I may be missing what you really mean by valid here. 2) If so, shouldn't a theory of types announce what model of computation they are working from? You say the C/C++ model is the exception, but in the programmer community (excepting web-based languages) it is the opposite. The machine model dominates. In C/C++ the types are based on the hardware. You have 16-bit ints and 32-bit ints and 64-bit floats and what not because those are the types that fit neatly in the storage units of the hardware. In higher-level languages like Python, the types are abstract, not based on the hardware. Python doesn't have 32-bit ints, except as an implementation detail that the programmer need not be aware of. Python ints have arbitrary precision. In fact, I'm not even sure how Java operates, but through some sorcery I don't want to take part in. It compiles to an intermediate language that is executed by a virtual machine, much like Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Tue, Apr 16, 2013 at 5:40 PM, Mark Janssen dreamingforw...@gmail.com wrote: 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). Modern computers are based on the Von Neumann architecture, not Turing machines. 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? Theory of computation is mostly about determining what kinds of problems fundamentally can or cannot be solved by computation. The models used are designed to be reasoned about, not to be used for solving real-world programming tasks. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Mark Janssen writes: After the 2001 type/class unification , it went towards Alan Kay's ideal of everything is an object As a contrast, this is very distinct from C++, where everything is concretely rooted in the language's type model which in *itself* is rooted (from it's long history) in the CPU architecture. ... My question is: Is there something in the Computer Science literature that has noticed this distinction/development in programming language design and history? 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. 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. 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. Scala might be the best model in this respect, though I do not know its type system fully. Here are a couple of references in theoretical work that might be helpful in understanding these connections: - John Reynolds, The Essence of Algol, in de Bakker and van Vliet (eds) Algorithmic Languages, 1981. Also published in O'Hearn and Tennent (eds) Algol-like Languages, Vol. A, 1997. - Uday Reddy, Objects and Classes in Algol-like Languages, Information and Computation, 172:63-97, 2002. (previously in FOOL workshop 1998.) http://www.cs.bham.ac.uk/~udr/papers/classes.pdf However, there are properties that are special to storage types, which are not shared by all class types. Sometimes, they simplify some theoretical aspects. It is not uncommon for authors to make a distinction between storage types and general types. An example is one of our own papers: - Swarup, Reddy and Ireland: Assignments for applicative languages, FPCA 1991. http://www.cs.bham.ac.uk/~udr/papers/assign.pdf Cheers, Uday Reddy -- http://mail.python.org/mailman/listinfo/python-list
RE: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Date: Sun, 14 Apr 2013 22:55:59 -0700 From: deles...@gmail.com To: dreamingforw...@gmail.com CC: types-l...@lists.seas.upenn.edu; python-list@python.org Subject: Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ] I'm not quite sure I understand your question, but I'll give it a shot. :-) I'm in this same camp too :) The C/C++ model, in which the types are anchored to the machine hardware, in the exception, not the rule. In the academic literature, type theory is almost entirely focused on studying abstract models of computation that are purely mathematical, and bear no resemblance to the underlying hardware. The lambda calculus is the most general, and most commonly used formalism, but there are many others; e.g. Featherweight Java provides a formal model of objects and classes as they are used in Java. Types and Programming Languages, by Benjamin Pierce, is an excellent introductory textbook which describes how various language features, including objects, can be formalized. If you are interested in OOP, Abadi and Cardelli's Theory of Objects is the obvious place to start, although I'd recommend reading Pierce's book first if you want to understand it. :-) Abadi and Cardelli discuss both class-based languages, and pure object languages. If you are interested in the type/object distinction in particular, then I'll shamelessly plug my own thesis: Pure Subtype Systems (available online), which describes a formal model in which types are objects, and objects are types. If you are familiar with the Self language, then you can think of it as a type system for Self. Offering a different view, I'd like to (also, shamelessly) plug my own thesis: NOOP: A Mathematical Model of OOP (available online) in which I denotationally model nominally-typed (ie, statically-typed class-based) OO languages such as Java, C#, C++ and Scala (but not Python). In agreement with the most common tradition in PL research, types in NOOP are modeled abstractly as (certain) sets (of objects). NOOP largely mimics, for nominally-typed OO languages, what Cardelli, Cook, and others earlier did for structurally-typed OO languages. Regards, -Moez Once you have a type system in place, it's usually fairly straightforward to compile a language down to actual hardware. An interpreter, like that used in Python, is generally needed only for untyped or dynamic languages. There are various practical considerations -- memory layout, boxed or unboxed data types, garbage collection, etc. -- but the basic techniques are described in any compiler textbook. Research in the areas of typed assembly languages and proof carrying code are concerned with ensuring that the translation from high-level language to assembly language is sound, and well-typed at all stages. -DeLesley On Sun, Apr 14, 2013 at 8:48 PM, Mark Janssen dreamingforw...@gmail.comwrote: [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list] Hello, I'm new to the list and hoping this might be the right place to introduce something that has provoked a bit of an argument in my programming community. I'm from the Python programming community. Python is an interpreted language. Since 2001, Python's has migrated towards a pure Object model (ref: http://www.python.org/download/releases/2.2/descrintro/). Prior to then, it had both types and classes and these types were anchored to the underlying C code and the machine/hardware architecture itself. After the 2001 type/class unification , it went towards Alan Kay's ideal of everything is an object. From then, every user-defined class inherited from the abstract Object, rooted in nothing but a pure abstract ideal. The parser, lexer, and such spin these abstrations into something that can be run on the actual hardware. As a contrast, this is very distinct from C++, where everything is concretely rooted in the language's type model which in *itself* is rooted (from it's long history) in the CPU architecture. The STL, for example, has many Container types, but each of them requires using a single concrete type for homogenous containers or uses machine pointers to hold arbitrary items in heterogeneous containers (caveat: I haven't programmed in C++ for a long time, so it's possible this might not be correct anymore). My question is: Is there something in the Computer Science literature that has noticed this distinction/development in programming language design and history? It's very significant to me, because as languages went higher and higher to this pure OOP model, the programmer+data ecosystem tended towards very personal object hierarchies because now the hardware no longer formed a common basis of interaction (note also, OOPs
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
On Apr 14, 2013, at 11:48 PM, Mark Janssen wrote: After the 2001 type/class unification , it went towards Alan Kay's ideal Are you sure? Remember Kay's two motivations [*], which he so elegantly describes with [the] large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether. At least for me, this quote sends a signal to language designers that is still looking for a receiver -- Matthias [*] http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html -- http://mail.python.org/mailman/listinfo/python-list
Re: [TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
I'm not quite sure I understand your question, but I'll give it a shot. :-) The C/C++ model, in which the types are anchored to the machine hardware, in the exception, not the rule. In the academic literature, type theory is almost entirely focused on studying abstract models of computation that are purely mathematical, and bear no resemblance to the underlying hardware. The lambda calculus is the most general, and most commonly used formalism, but there are many others; e.g. Featherweight Java provides a formal model of objects and classes as they are used in Java. Types and Programming Languages, by Benjamin Pierce, is an excellent introductory textbook which describes how various language features, including objects, can be formalized. If you are interested in OOP, Abadi and Cardelli's Theory of Objects is the obvious place to start, although I'd recommend reading Pierce's book first if you want to understand it. :-) Abadi and Cardelli discuss both class-based languages, and pure object languages. If you are interested in the type/object distinction in particular, then I'll shamelessly plug my own thesis: Pure Subtype Systems (available online), which describes a formal model in which types are objects, and objects are types. If you are familiar with the Self language, then you can think of it as a type system for Self. Once you have a type system in place, it's usually fairly straightforward to compile a language down to actual hardware. An interpreter, like that used in Python, is generally needed only for untyped or dynamic languages. There are various practical considerations -- memory layout, boxed or unboxed data types, garbage collection, etc. -- but the basic techniques are described in any compiler textbook. Research in the areas of typed assembly languages and proof carrying code are concerned with ensuring that the translation from high-level language to assembly language is sound, and well-typed at all stages. -DeLesley On Sun, Apr 14, 2013 at 8:48 PM, Mark Janssen dreamingforw...@gmail.comwrote: [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list] Hello, I'm new to the list and hoping this might be the right place to introduce something that has provoked a bit of an argument in my programming community. I'm from the Python programming community. Python is an interpreted language. Since 2001, Python's has migrated towards a pure Object model (ref: http://www.python.org/download/releases/2.2/descrintro/). Prior to then, it had both types and classes and these types were anchored to the underlying C code and the machine/hardware architecture itself. After the 2001 type/class unification , it went towards Alan Kay's ideal of everything is an object. From then, every user-defined class inherited from the abstract Object, rooted in nothing but a pure abstract ideal. The parser, lexer, and such spin these abstrations into something that can be run on the actual hardware. As a contrast, this is very distinct from C++, where everything is concretely rooted in the language's type model which in *itself* is rooted (from it's long history) in the CPU architecture. The STL, for example, has many Container types, but each of them requires using a single concrete type for homogenous containers or uses machine pointers to hold arbitrary items in heterogeneous containers (caveat: I haven't programmed in C++ for a long time, so it's possible this might not be correct anymore). My question is: Is there something in the Computer Science literature that has noticed this distinction/development in programming language design and history? It's very significant to me, because as languages went higher and higher to this pure OOP model, the programmer+data ecosystem tended towards very personal object hierarchies because now the hardware no longer formed a common basis of interaction (note also, OOPs promise of re-usable code never materialized). It's not unlike LISP, where the power of its general language architecture tended towards hyperpersonal mini macro languages -- making it hardly used, in practice, though it was and is so powerful, in theory. That all being said, the thrust of this whole effort is to possibly advance Computer Science and language design, because in-between the purely concrete object architecture of the imperative programming languages and the purely abstract object architecture of object-oriented programming languages is a possible middle ground that could unite them all. Thank you for your time. Mark Janssen Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
