Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43601 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-14 20:48 -0700
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-15 10:11 +0000
      Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-04-15 19:43 +0200
        Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-16 02:15 +0000
      Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Dave Angel <davea@davea.name> - 2013-04-15 17:13 -0400
        Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Rotwang <sg552@hotmail.co.uk> - 2013-04-15 23:12 +0100
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Angelico <rosuav@gmail.com> - 2013-04-16 08:32 +1000
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Rotwang <sg552@hotmail.co.uk> - 2013-04-15 23:54 +0100
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-16 15:38 -0700
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-17 06:40 +0000
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Angelico <rosuav@gmail.com> - 2013-04-17 16:56 +1000
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Rebert <clp2@rebertia.com> - 2013-04-17 00:16 -0700
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-17 18:40 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-16 17:14 -0600
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Michael Torrie <torriem@gmail.com> - 2013-04-18 10:37 -0600
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Neil Cerutti <neilc@norwich.edu> - 2013-04-18 17:57 +0000
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 01:00 +0000
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Roy Smith <roy@panix.com> - 2013-04-18 21:08 -0400
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-18 18:24 -0700
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ned Batchelder <ned@nedbatchelder.com> - 2013-04-18 22:10 -0400
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-18 19:30 -0700
                  Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 03:38 +0000
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ned Batchelder <ned@nedbatchelder.com> - 2013-04-18 22:39 -0400
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-05-01 13:32 -0700
                  Re: The type/object distinction and possible synthesis of OOP and imperative programming languages alex23 <wuwei23@gmail.com> - 2013-05-01 18:13 -0700
      Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-15 20:52 -0400
        Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-16 02:32 +0000
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-15 23:17 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-15 22:46 -0600
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages rusi <rustompmody@gmail.com> - 2013-04-15 21:56 -0700
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-16 05:59 +0000
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Serhiy Storchaka <storchaka@gmail.com> - 2013-04-16 11:25 +0300
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-04-16 11:07 +0200
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-16 12:49 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ethan Furman <ethan@stoneleaf.us> - 2013-04-16 10:29 -0700
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-16 14:29 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-16 12:22 -0600
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-04-17 14:04 +0200
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-15 23:54 -0700
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-15 23:54 -0700
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages rusi <rustompmody@gmail.com> - 2013-04-21 08:44 -0700

Page 1 of 3  [1] 2 3  Next page →

#43601 — The type/object distinction and possible synthesis of OOP and imperative programming languages

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

[toc] | [next] | [standalone]

#43612

On Sun, 14 Apr 2013 20:48:05 -0700, Mark Janssen wrote:

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


Incorrect.

Python's data model has always been 100% object oriented. Prior to the 
"class/type" unification, it simply had *two distinct* implementations of 
objects: types, which were written in C, and classes, which were written 
in Python.

After unification, the two kinds of object were no longer entirely 
distinct -- you could then subclass types in Python code, using the same 
"class" keyword as you would use for a pure-Python class.

And starting with Python 3, the last vestiges of the distinction have 
disappeared. Now, "class" and "type" are mere synonyms. Both built-in 
types and custom classes use the same mechanism.


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

Incorrect. In Python 2.7:


py> class AClass:
...     pass
... 
py> issubclass(AClass, object)
False



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43631

Op 15-04-13 12:11, Steven D'Aprano schreef:

>
> Python's data model has always been 100% object oriented. Prior to the
> "class/type" unification, it simply had *two distinct* implementations of
> objects: types, which were written in C, and classes, which were written
> in Python.
>
> After unification, the two kinds of object were no longer entirely
> distinct -- you could then subclass types in Python code, using the same
> "class" keyword as you would use for a pure-Python class.
>
> And starting with Python 3, the last vestiges of the distinction have
> disappeared. Now, "class" and "type" are mere synonyms. Both built-in
> types and custom classes use the same mechanism.

I had gotten my hopes up after reading this but then I tried:


$ python3
Python 3.2.3 (default, Feb 20 2013, 17:02:41)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> class vslice (slice):
...   pass
...
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: type 'slice' is not an acceptable base type


It seems types and classes are still not mere synonyms.

[toc] | [prev] | [next] | [standalone]

#43654

On Mon, 15 Apr 2013 19:43:32 +0200, Antoon Pardon wrote:

> Op 15-04-13 12:11, Steven D'Aprano schreef:
> 
> 
>> Python's data model has always been 100% object oriented. Prior to the
>> "class/type" unification, it simply had *two distinct* implementations
>> of objects: types, which were written in C, and classes, which were
>> written in Python.
>>
>> After unification, the two kinds of object were no longer entirely
>> distinct -- you could then subclass types in Python code, using the
>> same "class" keyword as you would use for a pure-Python class.
>>
>> And starting with Python 3, the last vestiges of the distinction have
>> disappeared. Now, "class" and "type" are mere synonyms. Both built-in
>> types and custom classes use the same mechanism.
> 
> I had gotten my hopes up after reading this but then I tried:
> 
> 
> $ python3
> Python 3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> class vslice (slice):
> ...   pass
> ...
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: type 'slice' is not an acceptable base type
> 
> 
> It seems types and classes are still not mere synonyms.


You are misinterpreting what you are reading. The mere fact that 
something cannot be subclassed doesn't mean anything. That's just a 
restriction put on the class by the implementation. It's not even clear 
that it is a guaranteed language restriction or a mere accident of 
implementation. With a bit of metaclass trickery, I could equally create 
a pure-Python class that cannot be easily subclassed.

The proof that types and classes are the same in Python 3 is simple:

py> class C:
...     pass
...
py> type(C) is type(int) is type(type) is type
True

The type of the pure-Python class is type itself.

However, even this can be bypassed, using a metaclass!

py> class D(metaclass=Meta):
...     pass
...
py> type(D) is type
False
py> issubclass(type(D), type)
True


So when using a metaclass, the type of the class is not necessarily type 
itself, but it will be a subclass of type.

This does not hold in Python 2.x, not for old-style "classic" classes. 
Classic classes are in a world of their own, distinct from types:

# Python 2
py> class C:
...     pass
...
py> type(C)
<type 'classobj'>
py> issubclass(type(C), type)
False



In Python 3, we can expect these two conditions to always hold:

* all instances are instances of object;

* all classes are instances of type.


Notice that this implies that type and object are circularly defined: 
object, being a class, is an instance of type, but type, being an object, 
is an instance of object:

py> isinstance(type, object)
True
py> isinstance(object, type)
True



These two conditions even apply to unsubclassable objects like slice:

py> isinstance(slice(1, 5, 2), object)
True
py> isinstance(slice, type)
True



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43643

On 04/15/2013 01:43 PM, Antoon Pardon wrote:
> Op 15-04-13 12:11, Steven D'Aprano schreef:
>
>>
>> Python's data model has always been 100% object oriented. Prior to the
>> "class/type" unification, it simply had *two distinct* implementations of
>> objects: types, which were written in C, and classes, which were written
>> in Python.
>>
>> After unification, the two kinds of object were no longer entirely
>> distinct -- you could then subclass types in Python code, using the same
>> "class" keyword as you would use for a pure-Python class.
>>
>> And starting with Python 3, the last vestiges of the distinction have
>> disappeared. Now, "class" and "type" are mere synonyms. Both built-in
>> types and custom classes use the same mechanism.
>
> I had gotten my hopes up after reading this but then I tried:
>
>
> $ python3
> Python 3.2.3 (default, Feb 20 2013, 17:02:41)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> class vslice (slice):
> ...   pass
> ...
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: type 'slice' is not an acceptable base type
>
>
> It seems types and classes are still not mere synonyms.

No, it seems you're trying to use an internal detail as though it were a 
supported feature.

 From page:
     http://docs.python.org/3.3/reference/datamodel.html#types

"""Internal types
A few types used internally by the interpreter are exposed to the user. 
Their definitions may change with future versions of the interpreter, 
but they are mentioned here for completeness.
"""


-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#43645

On 15/04/2013 22:13, Dave Angel wrote:
> On 04/15/2013 01:43 PM, Antoon Pardon wrote:
>> [...]
>>
>> I had gotten my hopes up after reading this but then I tried:
>>
>>
>> $ python3
>> Python 3.2.3 (default, Feb 20 2013, 17:02:41)
>> [GCC 4.7.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>  >>> class vslice (slice):
>> ...   pass
>> ...
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in <module>
>> TypeError: type 'slice' is not an acceptable base type
>>
>>
>> It seems types and classes are still not mere synonyms.
>
> No, it seems you're trying to use an internal detail as though it were a
> supported feature.
>
>  From page:
>      http://docs.python.org/3.3/reference/datamodel.html#types
>
> """Internal types
> A few types used internally by the interpreter are exposed to the user.
> Their definitions may change with future versions of the interpreter,
> but they are mentioned here for completeness.
> """

To be fair, one can't do this either:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 
bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
 >>> class C(type(lambda: None)):
	pass

Traceback (most recent call last):
   File "<pyshell#2>", line 1, in <module>
     class C(type(lambda: None)):
TypeError: type 'function' is not an acceptable base type


and I don't think that FunctionType would be considered an "internal 
detail", would it? Not that I'd cite the fact that not all types can be 
inherited from as evidence that types and classes are not synonyms, mind.

[toc] | [prev] | [next] | [standalone]

#43647

On Tue, Apr 16, 2013 at 8:12 AM, Rotwang <sg552@hotmail.co.uk> wrote:
> Traceback (most recent call last):
>   File "<pyshell#2>", line 1, in <module>
>     class C(type(lambda: None)):
> TypeError: type 'function' is not an acceptable base type
>
>
> and I don't think that FunctionType would be considered an "internal
> detail", would it? Not that I'd cite the fact that not all types can be
> inherited from as evidence that types and classes are not synonyms, mind.

Actually, I'm not sure how you'd go about inheriting from a function.
Why not just create a bare class, then assign its __call__ to be the
function you're inheriting from?

ChrisA

[toc] | [prev] | [next] | [standalone]

#43648

On 15/04/2013 23:32, Chris Angelico wrote:
> On Tue, Apr 16, 2013 at 8:12 AM, Rotwang <sg552@hotmail.co.uk> wrote:
>> Traceback (most recent call last):
>>    File "<pyshell#2>", line 1, in <module>
>>      class C(type(lambda: None)):
>> TypeError: type 'function' is not an acceptable base type
>>
>>
>> and I don't think that FunctionType would be considered an "internal
>> detail", would it? Not that I'd cite the fact that not all types can be
>> inherited from as evidence that types and classes are not synonyms, mind.
>
> Actually, I'm not sure how you'd go about inheriting from a function.
> Why not just create a bare class, then assign its __call__ to be the
> function you're inheriting from?

No idea. I wasn't suggesting that trying to inherit from FunctionType 
was a sensible thing to do; I was merely pointing out that slice's 
status as an internal feature was not IMO relevant to the point that 
Antoon was making.

[toc] | [prev] | [next] | [standalone]

#43710

On Mon, Apr 15, 2013 at 3:32 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Apr 16, 2013 at 8:12 AM, Rotwang <sg552@hotmail.co.uk> wrote:
>> Traceback (most recent call last):
>>   File "<pyshell#2>", line 1, in <module>
>>     class C(type(lambda: None)):
>> TypeError: type 'function' is not an acceptable base type
>>
>>
>> and I don't think that FunctionType would be considered an "internal
>> detail", would it? Not that I'd cite the fact that not all types can be
>> inherited from as evidence that types and classes are not synonyms, mind.
>
> Actually, I'm not sure how you'd go about inheriting from a function.
> Why not just create a bare class, then assign its __call__ to be the
> function you're inheriting from?

I think his point remains valid, from a theoretical pov.  Python
prides itself on the idea of "first-class functions" and such, but
unlike the world of lambda calculus, this selling point is a bit
invalid.  Because for Python (and any C-based language), it is roots
squarely in the Turing machine and its real-word implementation.

  (Note this contrasts starkly with Java(script), which doesn't seem
to be based on anything -- can anyone clarify where Java actually
comes from?)
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#43732

On Tue, 16 Apr 2013 15:38:29 -0700, Mark Janssen wrote:

> On Mon, Apr 15, 2013 at 3:32 PM, Chris Angelico <rosuav@gmail.com>
> wrote:
>> On Tue, Apr 16, 2013 at 8:12 AM, Rotwang <sg552@hotmail.co.uk> wrote:
>>> Traceback (most recent call last):
>>>   File "<pyshell#2>", line 1, in <module>
>>>     class C(type(lambda: None)):
>>> TypeError: type 'function' is not an acceptable base type
>>>
>>>
>>> and I don't think that FunctionType would be considered an "internal
>>> detail", would it? Not that I'd cite the fact that not all types can
>>> be inherited from as evidence that types and classes are not synonyms,
>>> mind.
>>
>> Actually, I'm not sure how you'd go about inheriting from a function.
>> Why not just create a bare class, then assign its __call__ to be the
>> function you're inheriting from?
> 
> I think his point remains valid, from a theoretical pov.  Python prides
> itself on the idea of "first-class functions" and such, but unlike the
> world of lambda calculus, this selling point is a bit invalid.


Python functions are first-class functions, which is short-hand for 
saying "functions which are also capable of being treated as values, 
which means they can be created at run-time, returned from functions, 
passed around as arguments, and assigned to variables".

Python's function type is not a first-class object-type, because it 
cannot be subclassed in at least three of the main implementations. But 
this has nothing to do with whether or not functions are first-class 
functions, which is an unrelated meaning. One can conceive of a language 
where FunctionType is a first-class type capable of being subclasses, but 
functions are *not* first-class values capable of being passed around as 
arguments.



> Because for Python (and any C-based language), 

Python-the-language is not C-based, or at least, very little of Python is 
C-based. It's main influences are, according to GvR, Lisp and ABC, with 
Pascal, Haskell and of course C also having some influence. Syntax-wise, 
it is much more of an Algol-inspired language than a C-inspired language.



> it is roots squarely in the
> Turing machine and its real-word implementation.

Python is certainly not inspired by Turing machines. Since a Turing 
machine is a simple device with an infinitely long paper tape which can 
have marks added and deleted from it, very few real programming languages 
are based on Turing machines.

It is, however, Turing-complete. Just like every programming language 
worthy of the name, whether it has syntax like Python, C, Lisp, Forth, 
INTERCAL, Oook, Applescript, Inform-7, Java, PHP, or x86 assembler.


>   (Note this contrasts starkly with Java(script), which doesn't seem
> to be based on anything -- can anyone clarify where Java actually comes
> from?)

C.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43734

On Wed, Apr 17, 2013 at 4:40 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 16 Apr 2013 15:38:29 -0700, Mark Janssen wrote:
>>   (Note this contrasts starkly with Java(script), which doesn't seem
>> to be based on anything -- can anyone clarify where Java actually comes
>> from?)
>
> C.

offee.

ChrisA

[toc] | [prev] | [next] | [standalone]

#43738

On Tue, Apr 16, 2013 at 11:40 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 16 Apr 2013 15:38:29 -0700, Mark Janssen wrote:
<snip>
> >   (Note this contrasts starkly with Java(script), which doesn't seem
> > to be based on anything -- can anyone clarify where Java actually comes
> > from?)
>
> C.

"Influenced by: Ada 83, C++, C#, Eiffel, Generic Java, Mesa, Modula-3,
Oberon, Objective-C, UCSD Pascal, Smalltalk"
"Categories: C programming language family | [...]"
– http://en.wikipedia.org/wiki/Java_(programming_language)

Sincerely,
Chris
--
Read Wikipedia's infoboxes! People work hard on them!

[toc] | [prev] | [next] | [standalone]

#43784

On Wed, 17 Apr 2013 00:16:21 -0700, Chris Rebert <clp2@rebertia.com>
declaimed the following in gmane.comp.python.general:


> 
> "Influenced by: Ada 83, C++, C#, Eiffel, Generic Java, Mesa, Modula-3,
> Oberon, Objective-C, UCSD Pascal, Smalltalk"
> "Categories: C programming language family | [...]"
> – http://en.wikipedia.org/wiki/Java_(programming_language)
>
	And kept the worst features of each... <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#43712

On Tue, Apr 16, 2013 at 4:38 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
> I think his point remains valid, from a theoretical pov.  Python
> prides itself on the idea of "first-class functions" and such, but
> unlike the world of lambda calculus, this selling point is a bit
> invalid.  Because for Python (and any C-based language), it is roots
> squarely in the Turing machine and its real-word implementation.

I'm having a hard time following what you're trying to say here.
Lambda calculus and Turing machines are theoretical models of
computation, not languages.  You can model Lisp programs with Turing
machine, and you can model C programs with lambda expressions.
Practically speaking you would probably have an easier time doing it
the other way around, due to the procedural nature of the Turing
machine versus the functional nature of the lambda calculus.

By the usual definition of "first-class function" [1], Python
functions are first-class; this has nothing to do with functional vs.
procedural programming (although it is more commonly found in the
former) or to do with Turing machines (which don't even include
functions as a concept).

>   (Note this contrasts starkly with Java(script), which doesn't seem
> to be based on anything -- can anyone clarify where Java actually
> comes from?)

I don't understand why you would consider Python to be "C-based" or
"Turing machine-based" but not Java or Javascript.

[1] http://en.wikipedia.org/wiki/First-class_citizen

[toc] | [prev] | [next] | [standalone]

#43839

On 04/16/2013 04:38 PM, Mark Janssen wrote:
>   (Note this contrasts starkly with Java(script), which doesn't seem
> to be based on anything -- can anyone clarify where Java actually
> comes from?)

Java is not equal in any way with JavaScript.  The only thing they share
are semicolons and braces.  Naming EMCAScript JavaScript was a very
unfortunate thing indeed.

For the record, JavaScript is what they call a "prototype-based
language."  http://en.wikipedia.org/wiki/Prototype-based_programming.
You can emulate an OOP system with a prototype-based language.

I highly recommend you read a book on formal programming language theory
and concepts.

[toc] | [prev] | [next] | [standalone]

#43845

On 2013-04-18, Michael Torrie <torriem@gmail.com> wrote:
> On 04/16/2013 04:38 PM, Mark Janssen wrote:
>>   (Note this contrasts starkly with Java(script), which doesn't seem
>> to be based on anything -- can anyone clarify where Java
>> actually comes from?)
>
> Java is not equal in any way with JavaScript.  The only thing
> they share are semicolons and braces.  Naming EMCAScript
> JavaScript was a very unfortunate thing indeed.
>
> For the record, JavaScript is what they call a "prototype-based
> language."  http://en.wikipedia.org/wiki/Prototype-based_programming.
> You can emulate an OOP system with a prototype-based language.
>
> I highly recommend you read a book on formal programming
> language theory and concepts.

Let me recommend Concepts, Techniques and Models of Computer
Programming, Van Roy and Haridi.

http://www.info.ucl.ac.be/~pvr/book.html

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#43875

On Thu, 18 Apr 2013 10:37:17 -0600, Michael Torrie wrote:

> For the record, JavaScript is what they call a "prototype-based
> language."  http://en.wikipedia.org/wiki/Prototype-based_programming.
> You can emulate an OOP system with a prototype-based language.

Prototype languages *are* OOP. Note that it is called OBJECT oriented 
programming, not class oriented, and prototype-based languages are based 
on objects just as much as class-based languages. They are merely two 
distinct models for OOP.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43876

In article <51709740$0$29977$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Thu, 18 Apr 2013 10:37:17 -0600, Michael Torrie wrote:
> 
> > For the record, JavaScript is what they call a "prototype-based
> > language."  http://en.wikipedia.org/wiki/Prototype-based_programming.
> > You can emulate an OOP system with a prototype-based language.
> 
> Prototype languages *are* OOP. Note that it is called OBJECT oriented 
> programming, not class oriented, and prototype-based languages are based 
> on objects just as much as class-based languages. They are merely two 
> distinct models for OOP.

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.

[toc] | [prev] | [next] | [standalone]

#43877

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

Here's a simple rule to resolve the ambiguity.   Whoever publishes
first, gets to claim origin of a word and its usage, kind of like a
BDFL.  The rest can adapt around that, make up their own word, or be
corrected as the community requires.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#43878

On 4/18/2013 9:24 PM, Mark Janssen wrote:
>> 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.
> Here's a simple rule to resolve the ambiguity.   Whoever publishes
> first, gets to claim origin of a word and its usage, kind of like a
> BDFL.  The rest can adapt around that, make up their own word, or be
> corrected as the community requires.
>

You won't solve the problem of confusing, ambiguous, or conflicting 
terminology by making up a rule.  "Object-oriented" means subtly 
different things to different people.  It turns out that computing is a 
complex field with subtle concepts that don't always fit neatly into a 
categorization.  Python, Java, Javascript, Ruby, Smalltalk, Self, PHP, 
C#, Objective-C, and C++ are all "object-oriented", but they also all 
have differences between them.  That's OK.  We aren't going to make up a 
dozen words as alternatives to "object-oriented", one for each language.

You seem to want to squeeze all of computer science and programming into 
a tidy hierarchy.  It won't work, it's not tidy. I strongly suggest you 
read more about computer science before forming more opinions.  You have 
a lot to learn ahead of you.

--Ned.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web