subject:"RE\: Multi\-Threading in Python"

On Mon, Oct 21, 2013 at 1:07 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 One of the reasons multiple languages exist is because people find that
 useful programming idioms and styles are *hard to use* or ugly in some
 languages, so they create new languages with different syntax to make
 those useful patterns easier to use. But syntax is not everything.
 Whether you write:

 object.method(arg)// Python, VB, Ruby, Java
 object#method arg // OCaml
 object:method arg // Lua
 method object arg // Haskell, Mercury
 object method arg // Io
 object-method(arg)   // C++, PHP
 method(object, arg)   // Ada, Dylan
 send method(arg) to object  // XTalk family of languages


 etc. does not really change the fact that you are calling a method on an
 object, despite the change in syntax. Even Forth has frameworks that let
 you write object-[oriented|based] code using a stack and reverse Polish
 notation syntax.

There seems to be a school of thought that if it doesn't have special
syntax, the language doesn't support it. This is true to an extent
(eg C doesn't support sockets, the code is all in the standard
library), and it does distinguish C from C++ in object orientation
(C's version is simply dedicating the first function argument to
'self', where C++ and Python and so on have an alternative syntax that
puts the self/this argument before the function name), but I don't
know that it's the whole story. Python 2.x has special (and somewhat
magical) syntax for file I/O; Python 3.x, as far as I know, has none -
open and print are just builtins, with no magic around them. Which is
better? I would say that standard functions are inherently more
flexible (you can shadow print and call the original, for instance),
but that would mean that the better way is to NOT support I/O.

If an analogy helps, let's look at the trading card game Magic: The
Gathering. The general design principle is that unusual effects get
written out on the card, rather than having actual rules to support
them; rulebook text is used only when printing abilities on the card
is unable to do everything. (There are also keyword abilities, which
are like Python's builtins - fear simply means can't be blocked
except by artifact and/or black creatures, and it could just as well
be written out on the card.) Does this mean that Magic supports
lifelink (which has entries in the Comprehensive Rulebook) but doesn't
support defenders (which simply can't attack)? I think not; the game
is most definitely designed for both.

Granted, C probably wasn't designed with object orientation in mind;
but it doesn't take very much effort to make it work (just pointer
casts and some argument order conventions). Sure, a bit of real
support helps (preventing accidental cross-casts), but it's pretty
easy to manage without. Adding to the list of object oriented C
systems is NIH:

http://ifdeflinux.blogspot.com/2012/05/quick-libnih-tutorial.html

It's small enough and light enough to be used by really early systems
like Upstart (a Linux bootloader) and it's a garbage-collected
object-oriented C library.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Mon, Oct 21, 2013 at 5:44 PM, Peter Cacioppi
peter.cacio...@gmail.com wrote:
 I've written a fair bit of code in pure C, C++, C#, Java and now getting 
 there in Python.

 The difference between C# and Java is fairly minor.

 The others have large and significant differences between them. Garbage 
 collectors or not is huge. Exceptions or not is huge.  Dynamic or static 
 typing is huge. Language support for polymorphism or not is huge.

 This is just one language feature. I could go on and on. The idea that the 
 differences between these languages is just syntactic sugar and aesthetics is 
 so profoundly misguided that I can only assume that this misconception was 
 proposed as a bizarre form of trolling.

I don't think anyone's denying that there are differences. If there
weren't, we'd all be using the same language! But most of what you
said isn't object orientation. Garbage collection is huge, but it's
nothing to do with OOP. Exceptions are completely separate again. (And
exception *usage* is separate from exceptions. C++ and PHP both
support exceptions, but most operations don't raise them. Python, on
the other hand, uses exceptions for everything.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Mark Lawrence


On 21/10/2013 07:44, Peter Cacioppi wrote:

I've written a fair bit of code in pure C, C++, C#, Java and now getting there 
in Python.

The difference between C# and Java is fairly minor.

The others have large and significant differences between them. Garbage 
collectors or not is huge. Exceptions or not is huge.  Dynamic or static typing 
is huge. Language support for polymorphism or not is huge.

C code invokes a very meaningful overhead of memory management. The task of 
insuring that memory doesn't leak here is far larger than in garbage collected 
languages, and much more difficult than C++ (which can guarantee stack based 
destruction).

This is just one language feature. I could go on and on. The idea that the 
differences between these languages is just syntactic sugar and aesthetics is 
so profoundly misguided that I can only assume that this misconception was 
proposed as a bizarre form of trolling.




As my crystal ball is once again being mended, would you please be kind 
enough to tell all of us who and exactly what you're replying to.


--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Mon, Oct 21, 2013 at 6:27 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 21/10/2013 07:44, Peter Cacioppi wrote:
 [ a whole lot of stuff ]

 As my crystal ball is once again being mended, would you please be kind
 enough to tell all of us who and exactly what you're replying to.

Mine is in service at the moment. It says that Peter was actually trying to say:

I use Google Groups and it sucks, so I delete all the context because
then nobody can see how much it sucks at showing context.

Peter, please can you use a different posting method? GG doesn't wrap
text properly, so it often results in really long lines with only a
single angle-bracket marking it as a quote, which makes the _next_
level of citation ugly.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Mark Lawrence


On 21/10/2013 08:31, Chris Angelico wrote:


I use Google Groups and it sucks, so I delete all the context because
then nobody can see how much it sucks at showing context.


Because it's written in (say) C++ in an object orientated style, so by 
rewriting it using assembler in a procedural style it will be fixed?




ChrisA



--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Mon, Oct 21, 2013 at 6:39 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 21/10/2013 08:31, Chris Angelico wrote:

 I use Google Groups and it sucks, so I delete all the context because
 then nobody can see how much it sucks at showing context.


 Because it's written in (say) C++ in an object orientated style, so by
 rewriting it using assembler in a procedural style it will be fixed?

Certainly not. The solution is to use FORTRAN and functional style.
That should be obvious!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Mark Lawrence


On 21/10/2013 08:43, Chris Angelico wrote:

On Mon, Oct 21, 2013 at 6:39 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:

On 21/10/2013 08:31, Chris Angelico wrote:


I use Google Groups and it sucks, so I delete all the context because
then nobody can see how much it sucks at showing context.



Because it's written in (say) C++ in an object orientated style, so by
rewriting it using assembler in a procedural style it will be fixed?


Certainly not. The solution is to use FORTRAN and functional style.
That should be obvious!

ChrisA



Thank you for the correction, my mistake I'm afraid :(

--
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Steven D'Aprano

On Sun, 20 Oct 2013 23:44:27 -0700, Peter Cacioppi wrote:

 This is just one language feature. I could go on and on. The idea that
 the differences between these languages is just syntactic sugar and
 aesthetics is so profoundly misguided that I can only assume that this
 misconception was proposed as a bizarre form of trolling.

I don't know who you are responding to, or what they said to give you the 
impression that they believe that all differences between languages is 
*merely* syntactic sugar, but I certainly don't believe that.

In fact, given that you haven't quoted anyone, I'm tempted to call it a 
straw-man, except you don't appear to be arguing against anyone, so there 
is nobody it could be a straw-man of :-)



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Metallicow

Python is the Best!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Peter Cacioppi

Specifically the following seems so misguided as to be deliberate trolling.

One of the reasons multiple languages exist is because people find that 
useful programming idioms and styles are *hard to use* or ugly in some 
languages, so they create new languages with different syntax to make 
those useful patterns easier to use.

This is just profoundly wrong. If anything, different languages strive to 
maintain common syntax. You can see foo.bar() as legal syntax meaning 
essentially the same thing in C++, C#, Java and Python (and likely quite a few 
other languages). There is NOT a deliberate effort to create new syntax just 
for aesthetics, there is the exact opposite. There is a deliberate effort to 
maintain consistency with the syntax of pre-existing languages.

Languages sprout up for a variety of reasons. C++ has very significant 
functionality that doesn't exist in C. Java/C# can say the same thing to C++, 
and Python to all of the others. 

Please lets not pretend that it's all just ballpark equivalent facades 
plastered on top of a Turing machine. New languages pop up to automate boring 
and repetitive tasks that chew up your time in older languages. That's the 
trend - abstractions automating repetitious and error-prone tasks. 

Not hey, this syntax isn't too my taste, I'm going to toodle it up.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Metallicow

Are you suggesting Advertising is the Best language there is?
# After many years, I agree not, but what to may...
def If I do Something do, you not react():
 IsMySyntaxNotCorrect()
 CanINotCorrectMyGrammaticalMistakesAndSeekAcceptance():
 # The most arguable language is arguably the most important to discuss.
 # Everyone is of the same basic mindset here.
 # 16 years of reading everyone elses words hasn't changed my view.
 # I make it real, and sometime I don't like it either.
 # Actions speak loader than comments.
 language = python

 benefits = failures
 failures = newTerminology
 newTerminology = newIdeas
 newIdeas = benefits

 Sometimes when the whole world doesn't complain about your 
newTerminology, they are trying to say let it live, but more often they say 
leave it alone. And Vise Versa.

 But more often they complain about the readability.
 Or the Indenation.
 Or the style of a personal poem.
 Or how the next person should learn it best.
 
I read a indented book first, then I read a un indented book. Sir.
  go figure
 nowpost()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread rusi

On Monday, October 21, 2013 2:13:52 PM UTC+5:30, Peter Cacioppi wrote:
 Specifically the following seems so misguided as to be deliberate trolling.

The same could be said for this below… but…

 
 One of the reasons multiple languages exist is because people find that 
 useful programming idioms and styles are *hard to use* or ugly in some 
 languages, so they create new languages with different syntax to make 
 those useful patterns easier to use.
 
 
 This is just profoundly wrong. If anything, different languages strive to 
 maintain common syntax. You can see foo.bar() as legal syntax meaning 
 essentially the same thing in C++, C#, Java and Python (and likely quite a 
 few other languages). There is NOT a deliberate effort to create new syntax 
 just for aesthetics, there is the exact opposite. There is a deliberate 
 effort to maintain consistency with the syntax of pre-existing languages.
 
 
 
 Languages sprout up for a variety of reasons. C++ has very significant 
 functionality that doesn't exist in C. Java/C# can say the same thing to C++, 
 and Python to all of the others. 
 
 
 Please lets not pretend that it's all just ballpark equivalent facades 
 plastered on top of a Turing machine. New languages pop up to automate boring 
 and repetitive tasks that chew up your time in older languages. That's the
 trend - abstractions automating repetitious and error-prone tasks. 
 
 
 
 Not hey, this syntax isn't too my taste, I'm going to toodle it up.


… but I am not going to do so.
Instead I reiterate:

The whole point of studying programming language semantics is just so that we 
can distinguish between the 'just toodle it up' differences and the bigger ones.
And so projects that take the Alice' Humpty Dumpty attitude:

When I use a word, Humpty Dumpty said in rather a scornful tone, it means 
just what I choose it to mean -- neither more nor less. 

should be treated with suspicion in correspondence with the scorn.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Roy Smith

On Mon, Oct 21, 2013 at 1:07 PM, Steven D'Aprano 
steve+comp.lang.pyt...@pearwood.info wrote:
 One of the reasons multiple languages exist is because people find that
 useful programming idioms and styles are *hard to use* or ugly in some
 languages, so they create new languages with different syntax to make
 those useful patterns easier to use. But syntax is not everything.
 Whether you write:

 object.method(arg)// Python, VB, Ruby, Java
 object#method arg // OCaml
 object:method arg // Lua
 method object arg // Haskell, Mercury
 object method arg // Io
 object-method(arg)   // C++, PHP
 method(object, arg)   // Ada, Dylan
 send method(arg) to object  // XTalk family of languages

You missed the ever-so-special Objective C syntax:

[object method arg1 withSomething arg2 withSomethingElse arg3]

I'm sure I got that slightly wrong.  I don't do Objective C, and my eyes 
glaze over every time I have to read it.

And, of course, there's Postscript (stolen from Forth) stack syntax:

arg3
arg2
arg1
function

although it's more than just syntax; it's a totally different program 
architecture.  A lot of people don't realize that PostScript is not just 
a printer file format, it's a real language with functions, variables, 
loops, and all that good stuff.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Steven D'Aprano

On Mon, 21 Oct 2013 01:43:52 -0700, Peter Cacioppi wrote:

 Specifically the following seems so misguided as to be deliberate
 trolling.
 
 One of the reasons multiple languages exist is because people find that
 useful programming idioms and styles are *hard to use* or ugly in some
 languages, so they create new languages with different syntax to make
 those useful patterns easier to use.

As the author of that quote -- and I wonder why you're dropping 
attributions -- I can assure you I am not trolling.

Why do you think that my comment is misguided? If you don't believe that 
people write new languages because they are dissatisfied with the 
existing ones, why do you think they write new languages?

I think that my comment should be uncontroversial. At least some 
languages were invented because the author was dissatisfied with some 
existing language and wanted a better language. Bjarne Stroustrup wrote 
C++ to be a better C supporting data abstraction, OOP and generic 
programming, which were too hard to do right in C.

http://www.stroustrup.com/bs_faq.html

Niklaus Wirth wrote Pascal because he wanted a *simpler* language than 
Algol -- he famously walked out of one of the Algol design conferences 
because he disagreed with the direction they were taking -- and then he 
followed Pascal with Modula 2 and Oberon to be better Pascals, e.g. 
adding support for parallisation, which was hard to do in Pascal.

Bertrand Meyer invented Eiffel because he liked the style of Ada and the 
OOP of Stimula, and wanted to make Design By Contract easier to use.



 This is just profoundly wrong. If anything, different languages strive
 to maintain common syntax.

With respect, I think that demonstrates a lack of experience with 
programming languages. What common syntax do you perceive between 
languages such as these?

- Hypertalk
- Forth
- Pascal
- Lisp
- Haskell
- bash
- Inform 7
- Prolog

All of these are real languages; none of them are joke languages. If you 
aren't at least aware of their existence, and the general feel of their 
syntax, then you aren't qualified to comment on programming language 
syntax. The world is much bigger than just the C family of languages.

Of course, languages tend to resemble the languages that most influenced 
them, and there are distinct family resemblances, e.g. XTalk languages, 
Algol-based languages, etc. Some pairs of languages are closer than 
others, e.g. both Hypertalk and Haskell would accept x + 1 as a valid 
expression to evaluate one more than x, whereas in Forth it means 
something completely different.


 You can see foo.bar() as legal syntax meaning
 essentially the same thing in C++, C#, Java and Python (and likely quite
 a few other languages). There is NOT a deliberate effort to create new
 syntax just for aesthetics, there is the exact opposite. There is a
 deliberate effort to maintain consistency with the syntax of
 pre-existing languages.

Perhaps you ought to re-read my earlier comment. I did not say that 
people create new syntax just for aesthetics. I said that one reason 
for making a new language (there may be more than one!) is if a useful 
idiom or design pattern is *hard to use* in a language. Parallel 
processing is hard in Pascal, so Wirth created Oberon; OOP is hard in C, 
so Stroustrup created C++.

Often languages aren't just another language, plus foo for some foo. 
Java isn't just C-with-garbage-collection-and-objects, but James Gosling 
invented Java because he wasn't happy with the level of support for 
garbage collection and OOP in existing languages. They're not just gluing 
one more feature on top of an existing language. Here is Rob Pike's 
explanation for why Go was invented:

http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-
more.html

Short version: they wanted a language where concurrency was easy, and 
were dissatisfied with C and C++. Pike tried to do concurrency in C++ and 
failed:

[quote]
I actually tried and failed to find a way to bring the ideas 
to C++. It was too difficult to couple the concurrent operations 
with C++'s control structures, and in turn that made it too hard
to see the real advantages. Plus C++ just made it all seem too
cumbersome, although I admit I was never truly facile in the
language. So I abandoned the idea.


Actually, depending on how you define aesthetics, that is *exactly* why 
people define new syntax. You can write loops with GOTO:

10 do this
20 do that
30 if condition GOTO 10

but it's ugly, by which I mean it is hard to use, error prone, and not 
easily maintained. And so modern languages eschew GOTO for while loops. 
Likewise if you have while, you don't strictly need for loops as well:

i = start
while i  end:
process(i)
i += step

nevertheless compared to a for-loop, such a construct is ugly (harder 
to use, more error prone, less easily maintained, harder to read, harder 
to analyse), and so modern imperative languages tend to provide

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread Peter Cacioppi

but it's ugly, by which I mean it is hard to use, error prone, and not
easily maintained.

OK, I see the problem. What you call ugly is really just objectively bad.

Ugliness and beauty are subjective qualities that can't really be debated on a 
deep level. Like I mentioned in other post, I find the lazy-evaluation idiom 
that avoids __init__ initialization of the stored value to be pretty, so I code 
it that way (in C#, in Java, in Python, even though the syntax is slightly 
different in each one).

But I wouldn't say that using the __init__ (or the constructor) to initialize 
the lazy variable is hard to use, error prone, not easily maintained. I would 
say it's ugly (or less pretty), and that it does seem to have some minor 
functional drawbacks. But I wouldn't make a big deal out of it if a colleague 
wanted to code it that way. 

Looking at Fortran, C, C++, C#, Java and Python (the languages I have done 
large bodies of work in, and, not coincidentally, some of the most popular 
languages ever, since I like to get paid and that requires going with the flow 
a little) it's easy to see that a lot of cosmetic things are maintained (i.e. 
foo.bar(), k += 1, etc) but some important, conceptual things are improved in 
profound ways. So a colleague that was advocating coding a project in C when 
Python would work ... yeah, that's a deal breaker, we're going to lock horns 
over that. 

I wasn't going to ramble on like this but I think you, Stephen, were the one 
encouraging me to step into the flames.



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-21 Thread rusi

On Tuesday, October 22, 2013 8:25:58 AM UTC+5:30, Peter Cacioppi wrote:

Guess-who said:

 but it's ugly, by which I mean it is hard to use, error prone, and not
 easily maintained.
 
 OK, I see the problem. What you call ugly is really just objectively bad.

You continue to not attribute quotes.

What user agent/group are you using?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-20 Thread Steven D'Aprano

On Fri, 18 Oct 2013 22:26:02 -0700, rusi wrote:

 On Saturday, October 19, 2013 2:02:24 AM UTC+5:30, Peter Cacioppi wrote:
 
 I still say that object-based is a distinct and meaningful subset of
 object-oriented programming.
 
 Yes that is what is asserted by
 http://www-public.int-evry.fr/~gibson/Teaching/CSC7322/ReadingMaterial/
Wegner87.pdf
 -- a classic though old reference

The truth of a definition is not really something that is amenable to 
proof, only to agreement. In my experience, there is no widespread 
agreement on what the terms object oriented or object based 
programming mean. I expect that most people would consider them synonyms, 
or might consider the first to have some vigorous meaning while the 
second is just an informal term for a language that in some sense is 
based on objects in some way.

Even if we agreed that there was a distinction between the two -- and I 
don't think we do -- there is certainly no agreement as to what that 
distinction actually is. There are far too many mediocre programmers with 
limited experience outside of their narrow field who assume that whatever 
sliver of C++/Java/Python/whatever that they learned is the One True 
Definition of object-oriented programming. And too many academics looking 
for hard boundaries between concepts which, fundamentally, exist in a 
continuum.

It's all just part of the human tendency to pigeon-hole. According to 
some, Java, which has many low-level machine primitive types, is an 
object-oriented language, while Python, which has no machine primitives 
and where every value is an object, is not. Explain that one, if you can.



[...]
 It's an important distinction, because a project that is constrained to
 C should (IMHO) target an object-based design pattern but not an
 object-oriented one. That said, I'm open to disputation-by-example on
 this point, provided the example is reasonably small and pretty. (If
 the only polymorphic C code is ugly and non-small, it sort of proves my
 point).

Define ugly :-)

One of the reasons multiple languages exist is because people find that 
useful programming idioms and styles are *hard to use* or ugly in some 
languages, so they create new languages with different syntax to make 
those useful patterns easier to use. But syntax is not everything. 
Whether you write:

object.method(arg)// Python, VB, Ruby, Java
object#method arg // OCaml
object:method arg // Lua
method object arg // Haskell, Mercury
object method arg // Io
object-method(arg)   // C++, PHP
method(object, arg)   // Ada, Dylan
send method(arg) to object  // XTalk family of languages


etc. does not really change the fact that you are calling a method on an 
object, despite the change in syntax. Even Forth has frameworks that let 
you write object-[oriented|based] code using a stack and reverse Polish 
notation syntax.


[...]
 Just as the study of algorithms arose out of a desire to study program
 efficiency but with the nitty-gritty details of machines abstracted
 away, in the same way programming language semantics arose in order to
 study broad classes of languages with details hidden away.

I don't think that programming language semantics arose so much in order 
to *study* languages, more to *program*. Programming languages pre-date 
the study of programming languages :-)


 Unfortunately, even after 50 years of trying, semantics has been a
 dismal failure in defining the what and where and whither of OOP. In a
 sane world this would have signified that perhaps OOP as a concept(s)
 needs to be questioned. Considering that the opposite has happened --
 programming language semantics as an area has become distinctly
 'old-fashioned' and not-so-respectable-- I can only conclude that the
 world is not sane.

All the words are in English, yet somehow I can't quite make sense of 
this paragraph. You seem to be using semantics in a way that doesn't 
quite make sense to me. To me, programming language semantics is the 
*meaning* of code: var = func(arg) is the syntax, call func with arg 
and assign the result to var is the semantics. What do you mean by it?


 Well the tide is slowly turning -- here's a growing bunch of people
 questioning the validity of OOP:
 http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism

*Criticism* is not the same as questioning the validity. Certainly I can 
criticise OOP:

- if you care about machine efficiency, shoving small ints into a bulky 
object wrapper is bad for machine efficiency;

- ravioli code is to OOP as spaghetti code was to BASIC;

- large, deep object hierarchies are complex and hard to understand and 
learn;

etc. But then I can also criticise functional programming, declarative 
programming, imperative programming, logic programming, etc. There is no 
One True Programming Paradigm suitable for every task, just as there is 
no One True Programming Language.

 
 Of these I find two noteworthy:
 1. Stepanov who is next to Stroustrup in C++

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-20 Thread Roy Smith

In article 52648c54$0$29981$c3e8da3$54964...@news.astraweb.com,
 Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:

 According to 
 some, Java, which has many low-level machine primitive types, is an 
 object-oriented language, while Python, which has no machine primitives 
 and where every value is an object, is not. Explain that one, if you can.

That's easy to explain.  Python doesn't have private data, therefore it 
isn't OO.  Well, according to the Java-esque gospel, at any rate.

Whenever somebody tells you what OO means, ask him what part of the 
elephant he's touching.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-20 Thread rusi

On Monday, October 21, 2013 7:51:12 AM UTC+5:30, Roy Smith wrote:
 In article 
  Steven D'Aprano  wrote:
 
  According to 
  some, Java, which has many low-level machine primitive types, is an 
  object-oriented language, while Python, which has no machine primitives 
  and where every value is an object, is not. Explain that one, if you can.
  
 That's easy to explain.  Python doesn't have private data, therefore it 
 isn't OO.  Well, according to the Java-esque gospel, at any rate.

 Whenever somebody tells you what OO means, ask him what part of the 
 elephant he's touching.

Nice one ! Complementarily one can ask what does a typical Picasso cubist 
painting eg http://www.artchive.com/artchive/p/picasso/cadaques.jpg
represent? The avant gardists will wax eloquent.
And some (of us philistines) will of course say: Nothing.
Just as there may an elephant which we are too blind to see, its good to keep 
in mind the possibility that there may be big words without anything actually 
there.

Colloquially known as the emperor's new clothes

On Monday, October 21, 2013 7:37:17 AM UTC+5:30, Steven D'Aprano wrote:
  Unfortunately, even after 50 years of trying, semantics has been a
  dismal failure in defining the what and where and whither of OOP. In a
  sane world this would have signified that perhaps OOP as a concept(s)
  needs to be questioned. Considering that the opposite has happened --
  programming language semantics as an area has become distinctly
  'old-fashioned' and not-so-respectable-- I can only conclude that the
  world is not sane.
  
 All the words are in English, yet somehow I can't quite make sense of
 this paragraph. You seem to be using semantics in a way that doesn't
 quite make sense to me. To me, programming language semantics is the
 *meaning* of code: var = func(arg) is the syntax, call func with arg
 and assign the result to var is the semantics. What do you mean by it?

Yes its always good to be skeptical about the emperor's new clothes…

I thought I'd point to wikipedia 
http://en.wikipedia.org/wiki/Semantics_%28computer_science%29 but its doing a 
less than stellar job of it so heres my thoughts:


Programming language semantics categorises roughly into:
1. Operational
2. Denotational
3. Axiomatic
4. Algebraic

Some historical context:

1. proof theory vs model theory

In logic, the proof theorists want to study how to prove or reason about 
something
The model theorists, more platonically inclined, want to say what something is
Corresponds to the philosophical divide between epistemology and 
ontology/metaphysics.
The latter can be more 'grand' but is therefore subject to the most penetrating 
criticism.
Historically the big contributions of Aristotle and Plato were under the title 
of metaphysics and the big contributions of Kant and Hume were to show that for 
the most part metaphysics is bullshit.
In short these kinds of arguments are a bit older than you and me!!

In programming language research, the model-theorists end towards denotational 
semantics;
the proof theorists tend towards axiomatic and algebraic semantics;
The implementers come from the operational camp

2. programs ∈ languages

 To me, programming language semantics is the *meaning* of code.

Yes this is an eminently sensible pov (and has precedents like Hoare, Dijkstra, 
Floyd etc -- the 'axiomatic' guys). However you cannot really talk of the 
meaning of programs without talking of the meaning of programming languages. 
Clearly this -- the meaning of the language -- is a grander project and just as 
in philosophy, is as liable to called out as bullshit.  As an example the 
repeating argument about what IS a variable indicates the crying need to 
discuss this more metaphysically -- ie denotational semantically -- because if 
we dont, the result is just a mess

- in C a variable *means* this
- in python it means that
- in math it means something
- etc

 But then I can also criticise functional programming, declarative programming,
 imperative programming, logic programming, etc. There is no One True 
 Programming 
 Paradigm suitable for every task, just as there is no One True Programming 
 Language.

Analogy:

When we deal with an existing code-base, we often find 
flaws/issues/gaffes/whatever in the design or architecture.  On the other hand 
sometimes we find there is no design or architecture whatever
I believe there is a big difference between the two.  In PLs think php.

I think what Stepanov is saying (and most of the others at 
http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism ) is this 
distinction.

My own view in summary: Between programming and mathematics, mathematics is the 
prior.  This is obviously true as history including the name 'computer' and all 
its modifications. To the extent that ontogeny recapitulates phylogeny this 
is true in fact as well.

The OOP aficionados are straining to break their umbilical cord with X. That X 
may -- depending on context/background -- be

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-19 Thread Steven D'Aprano

On Wed, 16 Oct 2013 23:49:02 -0700, Peter Cacioppi wrote:

I don't know if I want to step into the flames here,

Go on, be bold! You learn a lot by making bold claims and having them
shot down. Or at least, I did. Now I know everything, so I can afford to
be humble.

*wink*

but my
understanding has always been that in the absence of polymorphism the
best you can do is object based programming instead of object
oriented programming.

Well, that surely depends on the semantics of what you mean by object
based versus object oriented, and I don't think there is any one hard,
universally agreed upon definition of those.

Object based programming is a powerful step forward. The insight that by
associating data structures and methods together you can significantly
improve readability and robustness.

This implies that object-based simply means that you have *syntax* for
associating methods with data, i.e. objects. I don't think I would agree
with that definition. For instance, I often describe Python as object-
based in the sense that *all* values in Python are objects, even things
which would be low-level primitives in some other languages, although you
can still write procedural, imperative or functional-style code.

Object oriented programming takes things further, most significantly by
introducing the idea that the object reference you are referencing might
be a run time dependent sub-class.

And I *strongly* disagree with this. I wonder whether you have read this?

http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts

Quote:

Benjamin C. Pierce and some other researchers view any attempt
to distill OOP to a minimal set of features as futile. He
nonetheless identifies fundamental features that support the
OOP programming style in most object-oriented languages:
[list of five feature]

Similarly, in his 2003 book, Concepts in programming languages,
John C. Mitchell identifies four main features: [...] Michael
Lee Scott in Programming Language Pragmatics considers only
[three features]

It is notable that polymorphism is *not* one of the three features listed
by Scott (although it is included by the other two). So I don't agree
that subtype polymorphism is necessary for OOP.

I can easily conceive of object-oriented languages with inheritance but
no subtype polymorphism. For instance, prototype-based OOP languages have
inheritance, but since they don't really have types in the class-based
OOP sense, they don't have subtypes, hence no subtype polymorphism.

Even Python, which isn't strongly typed,

That's not the case, although that's been discussed in other posts.

manages polymorphism by allowing the self argument to a sub-class
of the method class.

I must admit I don't really understand what this sentence is supposed to
mean.

There are many wonderful examples of object based programming in C. I
believe VB (not VB.net, the older VBA language) is object based but not
object oriented.

True object oriented programming

http://en.wikipedia.org/wiki/True_Scotsman_fallacy

seems to require proper support from
the language itself, because the run-time resolution of the this/self
reference needs specific constructs in the language.

Again, I don't understand what you are trying to say here. Provided that
the this/self reference has a type, what more does the language need to
provide? The reference itself is enough to identify the instance (since
it is the instance!) and the instance's type is enough to identify the
type (since it is the type!).

Bear in mind that my usual disclaimer when wading into the flames like
this is to quote Randy Newman ... I may be wrong but I don't think
so!!

:-)

--
Steven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-19 Thread Chris Angelico

On Sat, Oct 19, 2013 at 8:57 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Wed, 16 Oct 2013 23:49:02 -0700, Peter Cacioppi wrote:

 I don't know if I want to step into the flames here,

 Go on, be bold! You learn a lot by making bold claims and having them
 shot down.

Yes, it's a very effective technique. I just learned another meaning
of the word trepan via Savoynet that way. (It's a synonym for its
anagram entrap, as well as being a surgical operation on the skull.
So now you know, too!)

 Even Python, which isn't strongly typed,
 manages polymorphism by allowing the self argument to a sub-class
 of the method class.

 I must admit I don't really understand what this sentence is supposed to
 mean.

As I understand it, there's a little word missing: ... allowing the
self argument to BE a subclass That is, in this example:

class A:
def foo(self):
return spam
class B(A):
pass

x=B()
print(x.foo())

the method named foo and defined in class A might not get, as its
'self' argument, an instance of class A, but might instead get a
subclass thereof. Thus, polymorphism. Similarly, this C example cheats
a bit, but does work:

struct A
{
/* ... declare members here */
}
struct B
{
struct A base;
/* ... more members */
}

int foo(struct A *self)
{
/* ... */
}

int main()
{
struct B obj;
foo((struct A *)obj);
}

It depends on the compiler not tinkering with the layout of the
structure at all, which I don't believe is guaranteed but is fairly
safe to assume. (The equivalent C++ code could use real inheritance,
and then it is guaranteed, plus the pointer can be cast implicitly.
But we already know C++ does object oriented code more cleanly.) As
far as foo() is concerned, it's been given a 'struct A', albeit one
with a few extra members after it.

 True object oriented programming
 seems to require proper support from
 the language itself, because the run-time resolution of the this/self
 reference needs specific constructs in the language.

 Again, I don't understand what you are trying to say here. Provided that
 the this/self reference has a type, what more does the language need to
 provide? The reference itself is enough to identify the instance (since
 it is the instance!) and the instance's type is enough to identify the
 type (since it is the type!).

See above C example - except that true support would include implicit
upcasting, and would thus disallow cross-casting (which the C example
above would have problems with - you could cast any pointer to any
type with the exact same syntax and no compiler warning or error).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-18 Thread Peter Cacioppi

 I think the author goes a little too far to claim that strong
 weak are meaningless terms when it comes to type systems

I can live with that, actually.

The important language classifications are more along the lines of static vs. 
dynamic typing, procedural vs. functional, no objects vs. object based vs. true 
OO.

That probably starts another flame war, but this thread is already running 
around with its hair on fire.

I still say that object-based is a distinct and meaningful subset of 
object-oriented programming. The former can be implemented elegantly in a wide 
range of languages without much in the way of specific language support, the 
latter needs to designed into the language to allow a modicum of polymorhpic 
readability.

It's an important distinction, because a project that is constrained to C 
should (IMHO) target an object-based design pattern but not an object-oriented 
one. That said, I'm open to disputation-by-example on this point, provided the 
example is reasonably small and pretty. (If the only polymorphic C code is ugly 
and non-small, it sort of proves my point).


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-18 Thread Mark Lawrence


On 18/10/2013 21:32, Peter Cacioppi wrote:

I think the author goes a little too far to claim that strong
weak are meaningless terms when it comes to type systems


I can live with that, actually.

The important language classifications are more along the lines of static vs. 
dynamic typing, procedural vs. functional, no objects vs. object based vs. true 
OO.

That probably starts another flame war, but this thread is already running 
around with its hair on fire.

I still say that object-based is a distinct and meaningful subset of 
object-oriented programming. The former can be implemented elegantly in a wide 
range of languages without much in the way of specific language support, the 
latter needs to designed into the language to allow a modicum of polymorhpic 
readability.

It's an important distinction, because a project that is constrained to C 
should (IMHO) target an object-based design pattern but not an object-oriented 
one. That said, I'm open to disputation-by-example on this point, provided the 
example is reasonably small and pretty. (If the only polymorphic C code is ugly 
and non-small, it sort of proves my point).




As far as I'm concerned all of the above belongs on 
comp.theoretical.claptrap, give me practicality beats purity any day of 
the week :)


--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-18 Thread Peter Cacioppi

 give me practicality beats purity any day of the week :) 

Without some notion of theory you will end up with php instead of python (see 
how I looped the thread back around on track ... you're welcome).

If you think php is no worse than python for building reliable, readable code 
bases than god love you. Readability is huge for allowing efficient team 
development of larger projects, and readability flows from these sort of 
discussions.




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-18 Thread rusi

On Saturday, October 19, 2013 2:02:24 AM UTC+5:30, Peter Cacioppi wrote:
 
 I still say that object-based is a distinct and meaningful subset of
 object-oriented programming.

Yes that is what is asserted by
http://www-public.int-evry.fr/~gibson/Teaching/CSC7322/ReadingMaterial/Wegner87.pdf
 
-- a classic though old reference

 The former can be implemented elegantly in a wide range of languages without 
 much in the way of specific language support, the latter needs to designed 
 into the language to allow a modicum of polymorhpic readability.

3 examples were given (1) python's C implementation (2) OS/2 (3) Linux kernel
About 2 I dont know anything though I believe gdk and gobject are more 
contemporary examples.

About 1 I have reservations -- see below

IMO the linux kernel is the closest approx to what you are asking:
The details are here http://lwn.net/Articles/444910/
The top level summary is in the opening paras of
http://lwn.net/Articles/446317/
 
 It's an important distinction, because a project that is constrained to C 
 should (IMHO) target an object-based design pattern but not an 
 object-oriented one. That said, I'm open to disputation-by-example on this 
 point, provided the example is reasonably small and pretty. (If the only 
 polymorphic C code is ugly and non-small, it sort of proves my point).

Yes this is an important point though hard to argue in a definitive way -- I 
call such arguments philosophical rather than scientific; ie it is important 
but it cant really be settled once and for all.

To see this one can start with two extremes:
Extreme 1: Computability (aka Turing) theory. From this pov every 
language/system/computer is equivalent to every other and people designing 
'newer' and 'better' ones are wasting their's and other's time just like 
fashion designers who keep alternating pant-hems from Elvis Presley to narrow.

Extreme 2: Semicolon as separator differs from semicolon as terminator;
P4 processor is different from P2 etc etc -- essentially treating any 
difference as a substantive difference.

Clearly both extremes are unsatisfactory: the first lands us into the 
Turing-tarpit. The second makes a discussion of close-but-different impossible.

Just as the study of algorithms arose out of a desire to study program 
efficiency but with the nitty-gritty details of machines abstracted away, in 
the same way programming language semantics arose in order to study broad 
classes of languages with details hidden away.

Unfortunately, even after 50 years of trying, semantics has been a dismal 
failure in defining the what and where and whither of OOP.
In a sane world this would have signified that perhaps OOP as a concept(s) 
needs to be questioned.
Considering that the opposite has happened -- programming language semantics as 
an area has become distinctly 'old-fashioned' and not-so-respectable-- I can 
only conclude that the world is not sane.

Well the tide is slowly turning -- here's a growing bunch of people questioning 
the validity of OOP:
http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism

Of these I find two noteworthy:
1. Stepanov who is next to Stroustrup in C++ circles, calls OOP a hoax.
2. Carnegie Mellon university has eliminated OOP as unsuitable for a modern CS 
curriculum

And which is why I sympathize with Mark Janssen's passion to clean up the OOP 
act.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-18 Thread Chris Angelico

On Sat, Oct 19, 2013 at 4:26 PM, rusi rustompm...@gmail.com wrote:
 3 examples were given (1) python's C implementation (2) OS/2 (3) Linux kernel
 About 2 I dont know anything though I believe gdk and gobject are more 
 contemporary examples.

Good point, I believe you're right there. I haven't worked with
GTK/GDK in C, but when poking around the docs to work out how to use
them in Python or Pike, I've seen something of how it's done. And yes,
they're polymorphic and properly object oriented.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

I don't know if I want to step into the flames here, but my understanding has 
always been that in the absence of polymorphism the best you can do is object 
based programming instead of object oriented programming.

Object based programming is a powerful step forward. The insight that by 
associating data structures and methods together you can significantly improve 
readability and robustness. 

Object oriented programming takes things further, most significantly by 
introducing the idea that the object reference you are referencing might be a 
run time dependent sub-class. Even Python, which isn't strongly typed, manages 
polymorphism by allowing the self argument to a sub-class of the method class.

There are many wonderful examples of object based programming in C. I believe 
VB (not VB.net, the older VBA language) is object based but not object 
oriented. 

True object oriented programming seems to require proper support from the 
language itself, because the run-time resolution of the this/self reference 
needs specific constructs in the language. 

Bear in mind that my usual disclaimer when wading into the flames like this is 
to quote Randy Newman ... I may be wrong  but I don't think so!!


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)


On 17/10/2013 01:53, Mark Janssen wrote:

And your earlier idea that punched cards didn't have tokens is wildly
ignorant of the state of software and languages 50 years ago.


Please tell me how you parsed tokens with binary switches 50 years
ago.  Your input is rubbish.



You must be one of the happiest people on this planet.  At least with 
respect to the history of computer science, ignorance is bliss.


--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, Oct 17, 2013 at 5:49 PM, Peter Cacioppi
peter.cacio...@gmail.com wrote:
 I don't know if I want to step into the flames here, but my understanding has 
 always been that in the absence of polymorphism the best you can do is 
 object based programming instead of object oriented programming.

 Object oriented programming takes things further, most significantly by 
 introducing the idea that the object reference you are referencing might be a 
 run time dependent sub-class. Even Python, which isn't strongly typed, 
 manages polymorphism by allowing the self argument to a sub-class of the 
 method class.

What you've said here is that without polymorphism, you can't have
polymorphism. :)

The OS/2 PM with SOM (System Object Model) classes does give
polymorphic functionality; here's a bit of an example:

(Reference: http://www.markcrocker.com/rexxtipsntricks/rxtt28.2.0299.html
- class hierarchy, standard classes only)

Part way down you'll see WPFolder. It's a subclass of WPFileSystem
(aka stuff backed by the disk as opposed to abstract objects), which
is a subclass of WPObject (aka stuff you can see and click on),
which is a subclass of SOMObject (aka stuff). The WPFolder class
defines a whole pile of functionality, and its code is all stored in
some library somewhere, as a binary on the disk. Well and good.

Now look at the WPRootFolder class. It's a subclass of WPFolder and
adds a few extra bits and bobs designed for the root of any particular
drive (OS/2 uses an MS-DOS style of drive letters for volumes, rather
than a Unix-style mount points) - menu items for formatting the drive,
getting extra info perhaps, whatever. But most of its functionality
comes from WPFolder.

When a WPFolder method is called on a WPRootFolder, the code has to
handle the fact that it's working with a subclass of that object. As
long as the proper SOM boilerplate is maintained correctly, the
WPFolder code won't even be aware that it's operating on a
WPRootFolder. That's polymorphism, and it's all done in a completely
cross-language way :)

(There are additional complications, as it's possible for a subclass
to WPReplaceClass (I'm probably misremembering the function name)
itself into the position of the parent class, which messes up the
hierarchy a bit - it still all works, but it's less clean to describe.
Most things work the way I'm describing.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)


 What you've said here is that without polymorphism, you can't have
 polymorphism. :) 

Respectfully, no. I refer to the distinction between object based and object 
oriented programming. Wikipedia's entry is consistent with my understanding 
(not to argue by wiki-authority, but the terminology here isn't my personal 
invention).

Your example of polymorphism in a non OO language makes my tired head hurt. 
Do you have a clean little example of polymorphism being mocked in a reasonable 
way with pure C? There are many nice object-based C projects floating around, 
but real polymorphism? I think you can't do it without some bizarre 
work-arounds, but I'd be happy to be shown otherwise.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Christian Gollwitzer


Am 17.10.13 09:23, schrieb Peter Cacioppi:

Do you have a clean little example of polymorphism being
mocked in a reasonable way with pure C? There are many nice
object-based C projects floating around, but real polymorphism? I
think you can't do it without some bizarre work-arounds, but I'd be
happy to be shown otherwise.


http://stackoverflow.com/questions/524033/how-can-i-simulate-oo-style-polymorphism-in-c/524076#524076

(Haven't tried to compile it, but I think there is an error in answer 
#5, the this pointer must be cast to VTable* before calling).


C is reasonably close to OO thanks to its structs. Most language 
constructs of C++ can be directly converted into C with just some more 
typing effort. You will have problems with exceptions (setjump?), 
templates (macros?) and RTTI.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, Oct 17, 2013 at 6:23 PM, Peter Cacioppi
peter.cacio...@gmail.com wrote:
 Respectfully, no. I refer to the distinction between object based and object 
 oriented programming. Wikipedia's entry is consistent with my understanding 
 (not to argue by wiki-authority, but the terminology here isn't my personal 
 invention).

Yep, but your definition of object oriented programming is
fundamentally based on support for polymorphism, and your opening
statement said that it's impossible without polymorphism :)

Anyway, what I sought to prove was that polymorphic object oriented
code can be written in C or any other language.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Jussi Piitulainen

rusi writes:

 However - to speak a little for Mark's perspective (from a hopefully
 more educated background): There's a fine line between laboriously
 simulating a feature and properly supporting it:

 - C has arbitrary precision arithmetic -- use gmp library
 - C is a functional language -- use function pointers and/or
   hand-generated macros with macro operators # and ##

A tangent, but I cannot resist: that latter point is literally the
first thing I ever heard about C.

I knew some Basic, 6502 (dis)assembler, I think Pascal, and probably
Forth, at the time, and I had some idea about what functional
programming means. I may have been already interested in Scheme, but I
don't think I had access to an implementation yet.

Then I overheard an acquaintance telling another: C is a functional
programming language (C on funktionaalinen ohjelmointikieli).
Interesting! But when I later learnt some C it turned out to be almost
the opposite of functional programming.

I guess it was the terminology: Pascal had procedures and
functions while C only had functions.

(Mis)information was not as abundant back then as it is now.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thursday, October 17, 2013 12:19:02 PM UTC+5:30, Peter Cacioppi wrote:
 Object oriented programming takes things further, most significantly by 
 introducing the idea that the object reference you are referencing might be a 
 run time dependent sub-class. Even Python, which isn't strongly typed, 
 manages polymorphism by allowing the self argument to a sub-class of the 
 method class.

Yes and the reference I earlier gave was just for that:
http://lwn.net/Articles/444910/

Ironically he describes the whole 'polymorphism-in-C' infrastructure there but 
does not call it that.
The first line however in the sequel article http://lwn.net/Articles/446317/
does just that. Heres the quote:


In the first part of this analysis we looked at how the polymorphic side of 
object-oriented programming was implemented in the Linux kernel using regular C 
constructs. In particular we examined method dispatch, looked at the different 
forms that vtables could take, and the circumstances where separate vtables 
were eschewed in preference for storing function pointers directly in objects. 
In this conclusion we will explore a second important aspect of object-oriented 
programming - inheritance, and in particular data inheritance.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thursday, October 17, 2013 6:09:59 PM UTC+5:30, rusi wrote:
 On Thursday, October 17, 2013 12:19:02 PM UTC+5:30, Peter Cacioppi wrote:
 
  Object oriented programming takes things further, most significantly by 
 introducing the idea that the object reference you are referencing might be a 
 run time dependent sub-class. Even Python, which isn't strongly typed, 
 manages polymorphism by allowing the self argument to a sub-class of the 
 method class.
 
 
 Yes and the reference I earlier gave was just for that:
 http://lwn.net/Articles/444910/
 
 Ironically he describes the whole 'polymorphism-in-C' infrastructure there 
 but does not call it that.
 
 The first line however in the sequel article http://lwn.net/Articles/446317/
 does just that. Heres the quote:

I would be a bit remiss if I left it at that -- yeah Mark is clueless about his 
history and philosophy.  However the general usage of the word polymorphism in 
the OOP community is not much better.

Cardelli and Wegner:
http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
give a conspectus of the field.  Especially section 1.3 shows that the word can 
mean one of 4 very different and unrelated ideas.

OOP aficionados think one of them to be the only one. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Grant Edwards

On 2013-10-17, Mark Janssen dreamingforw...@gmail.com wrote:
 And your earlier idea that punched cards didn't have tokens is wildly
 ignorant of the state of software and languages 50 years ago.

 Please tell me how you parsed tokens with binary switches 50 years
 ago.  Your input is rubbish.

Are you under the misapprehension that punched cards and binary
switches are the same thing?  

Punched cards were just another meidium for source code or textual
data.  Each card was a line of text (either a line of source code or a
line of data).

-- 
Grant Edwards   grant.b.edwardsYow! I know how to do
  at   SPECIAL EFFECTS!!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

Prior to that [the '70s] you have punch cards where there's no meaningful
 definition of parsing because there are no tokens.

 I have no idea what you mean by this. [...]
 You seem drawn to sweeping statements about the current state and history of
 computer science, but then make claims like this about punched cards that
 just make no sense.

It's like this.  No matter how you cut it, you're going to get back to
the computers where you load instructions with switches.  At that
point, I'll be very much looking in anticipation to your binary-digit
lexer.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)


On 17/10/2013 15:49, Mark Janssen wrote:

Prior to that [the '70s] you have punch cards where there's no meaningful
definition of parsing because there are no tokens.

I have no idea what you mean by this. [...]
You seem drawn to sweeping statements about the current state and history of
computer science, but then make claims like this about punched cards that
just make no sense.


It's like this.  No matter how you cut it, you're going to get back to
the computers where you load instructions with switches.  At that
point, I'll be very much looking in anticipation to your binary-digit
lexer.



Please dial 911, 999 or whatever and ask for an ambulance, it looks as 
if the last batch that you bought to smoke was heavily contaminated.


--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Fri, Oct 18, 2013 at 1:49 AM, Mark Janssen dreamingforw...@gmail.com wrote:
 It's like this.  No matter how you cut it, you're going to get back to
 the computers where you load instructions with switches.  At that
 point, I'll be very much looking in anticipation to your binary-digit
 lexer.

Even when computers were primarily programmed in high level languages,
boot code could still be toggled in with manual switches. There's a
story around someplace of a guy who did that _over the phone_ and, if
I recall correctly, without a reference manual - which would mean he
had the entire boot code for that computer memorized. So, yeah,
loading instructions with switches isn't incompatible with lexing,
though I don't know if that term existed at the time.

Ultimately, computers work with data, which can be represented (and
inputted) with binary states like switches, and can itself represent
text. To parse text, a computer performs analysis on binary data.
Someone could today build a computer that takes input on punched cards
or switches or a Navajo saying A'la'ih and Do'neh'lini [1], and then
parse the corresponding text as (say) C code. The two are completely
orthogonal.

ChrisA

[1] if http://xkcd.com/257/ is correct
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Piet van Oostrum

Peter Cacioppi peter.cacio...@gmail.com writes:

 What you've said here is that without polymorphism, you can't have
 polymorphism. :) 

 Respectfully, no. I refer to the distinction between object based and object 
 oriented programming. Wikipedia's entry is consistent with my understanding 
 (not to argue by wiki-authority, but the terminology here isn't my personal 
 invention).

 Your example of polymorphism in a non OO language makes my tired head hurt. 
 Do you have a clean little example of polymorphism being mocked in a 
 reasonable way with pure C? There are many nice object-based C projects 
 floating around, but real polymorphism? I think you can't do it without some 
 bizarre work-arounds, but I'd be happy to be shown otherwise.

The first C++ compilers were just preprocessors that translated into pure C 
code, which was then compiled with a C compiler. The resulting intermediate C 
code would be an object-oriented program in C. IIRC, the C code was reasonably 
clear, not really convoluted, so you would have been able to write it yourself.
-- 
Piet van Oostrum p...@vanoostrum.org
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Wednesday, October 16, 2013 1:56:27 AM UTC+5:30, zipher wrote:
 Yes, well clearly we are not having the same thoughts, yet the
 purpose of the academic establishment is to pin down such terminology
 and not have these sloppy understandings everywhere.  You dig?

Heh Mark I am really sorry.  I think this is the third or fourth time that I 
say something to which you reply with such egregious rubbish -- parsing has 
something to do with card-punches?!?! Yeah like python has something to do with 
the purple shirt I am wearing -- that a dozen others jump at you with a 
resounding 'Cut the crap!'

Well speaking for myself, I know I speak more wisely sometimes and more 
stupidly at others and I would wish my penalizers to calibrate the punishment 
to the crime.

Likewise here. I certainly 'dig' your passion to clean up the 'sloppy 
understandings everywhere' and would only wish for you the sanity of more 
knowledge of the subject before you begin to hold forth.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread MRAB


On 17/10/2013 18:32, rusi wrote:

On Wednesday, October 16, 2013 1:56:27 AM UTC+5:30, zipher wrote:

Yes, well clearly we are not having the same thoughts, yet the
purpose of the academic establishment is to pin down such
terminology and not have these sloppy understandings everywhere.
You dig?


Heh Mark I am really sorry.  I think this is the third or fourth time
that I say something to which you reply with such egregious rubbish
-- parsing has something to do with card-punches?!?! Yeah like python
has something to do with the purple shirt I am wearing -- that a
dozen others jump at you with a resounding 'Cut the crap!'

Well speaking for myself, I know I speak more wisely sometimes and
more stupidly at others and I would wish my penalizers to calibrate
the punishment to the crime.

Likewise here. I certainly 'dig' your passion to clean up the 'sloppy
understandings everywhere' and would only wish for you the sanity of
more knowledge of the subject before you begin to hold forth.


I learned a new word yesterday: ultracrepidarian. :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)


On 17/10/2013 18:32, rusi wrote:

On Wednesday, October 16, 2013 1:56:27 AM UTC+5:30, zipher wrote:

Yes, well clearly we are not having the same thoughts, yet the
purpose of the academic establishment is to pin down such terminology
and not have these sloppy understandings everywhere.  You dig?


Heh Mark I am really sorry.  I think this is the third or fourth time that I 
say something to which you reply with such egregious rubbish -- parsing has 
something to do with card-punches?!?! Yeah like python has something to do with 
the purple shirt I am wearing -- that a dozen others jump at you with a 
resounding 'Cut the crap!'



Cut the crap, cut the bollocks more like.  I am of course using the term 
in the context described here 
http://en.wikipedia.org/wiki/Sex_Pistols#Never_Mind_the_Bollocks


--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

 The first C++ compilers were just preprocessors that translated into 
 pure C code ...

I agree with this.

 the C code was reasonably clear, not really convoluted, so you would have 
 been able to write it yourself. 

I disagree with this. My sense of C is that IF you are relying on preprocessors 
to do sophisticated things, THEN you are not writing clear C code. The 
implementations I've seen of polymorphism-of-structs in C are quite ugly to my 
eyes, and make me grateful C++ was invented.

OTOH, I've seen object-based C development projects (I.e. where you could tell 
what function was being called at compile time) that are quite readable. It 
requires coding discipline (as does readability in any language).

We might just be arguing over the definition of readable here. I have been 
told that my standards of readable are unreasonable, so perhaps I'm in the 
wrong here. That said, I'm just glad true OO languages exist, especially Python.

All hail Guido.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, Oct 17, 2013 at 10:32 AM, rusi rustompm...@gmail.com wrote:
 On Wednesday, October 16, 2013 1:56:27 AM UTC+5:30, zipher wrote:
 Yes, well clearly we are not having the same thoughts, yet the
 purpose of the academic establishment is to pin down such terminology
 and not have these sloppy understandings everywhere.  You dig?

 Heh Mark I am really sorry.  I think this is the third or fourth time that I 
 say something to which you reply with such egregious rubbish -- parsing has 
 something to do with card-punches?!?! Yeah like python has something to do 
 with the purple shirt I am wearing -- that a dozen others jump at you with a 
 resounding 'Cut the crap!'

You feedback is respected.  However, you haven't included in your
analysis that you have a closed group here of Python aficionados.  I
invite you to take a look at
http://c2.com/cgi/wiki?TypeSystemCategoriesInImperativeLanguagesTwo
before you continue to issue insults.

 Likewise here. I certainly 'dig' your passion to clean up the 'sloppy 
 understandings everywhere' and would only wish for you the sanity of more 
 knowledge of the subject before you begin to hold forth.

Talk to me after you've finished your assignment.
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Terry Reedy


On 10/17/2013 2:49 AM, Peter Cacioppi wrote:


 Even Python, which isn't strongly typed,


Python objects have a definite type/class.  It is fixed for instances of 
builtins. If that is not 'strong', the word has no meaning.



manages polymorphism by allowing the self argument to a sub-class of the method 
class.


???

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)


On 17/10/2013 07:49, Peter Cacioppi wrote:

I don't know if I want to step into the flames here,
Even Python, which isn't strongly typed



Yeah right.

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

My bad, Python is dynamically typed, but also strongly typed.

But I still say it has language features that specifically support 
polymorphism, which is why true OO can be developed in Python in a readable way.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Ned Batchelder


On 10/17/13 3:49 PM, Mark Janssen wrote:

On Thu, Oct 17, 2013 at 10:32 AM, rusi rustompm...@gmail.com wrote:

On Wednesday, October 16, 2013 1:56:27 AM UTC+5:30, zipher wrote:

Yes, well clearly we are not having the same thoughts, yet the
purpose of the academic establishment is to pin down such terminology
and not have these sloppy understandings everywhere.  You dig?

Heh Mark I am really sorry.  I think this is the third or fourth time that I 
say something to which you reply with such egregious rubbish -- parsing has 
something to do with card-punches?!?! Yeah like python has something to do with 
the purple shirt I am wearing -- that a dozen others jump at you with a 
resounding 'Cut the crap!'

You feedback is respected.  However, you haven't included in your
analysis that you have a closed group here of Python aficionados.  I
invite you to take a look at
http://c2.com/cgi/wiki?TypeSystemCategoriesInImperativeLanguagesTwo
before you continue to issue insults.


I'm interested to learn more about your ideas, but that wiki page is not 
going to help much.  It's a chaotic back-and-forth, with no attribution, 
so it's impossible to know who is saying what.  Except that it devolves 
into the same frustrated confusion, and then insults that this thread 
has, so I can tell: those trying to understand are frustrated, and Mark 
starts insulting people. Hitler!: what does that mean??


Mark, if you want people to understand you, you have to get your facts 
straight, you have to explain yourself clearly, and when people don't 
understand, you have to not resort to insults.  Perhaps you are a 
misunderstood genius, I can't tell for sure.  So far it just looks like 
you are making sweeping over-generalizations based on insufficient 
understanding of the current and past complexities of the field.


Read and listen more.  Write and say less.

--Ned.

Likewise here. I certainly 'dig' your passion to clean up the 'sloppy 
understandings everywhere' and would only wish for you the sanity of more 
knowledge of the subject before you begin to hold forth.

Talk to me after you've finished your assignment.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Ethan Furman


On 10/17/2013 01:57 PM, Ned Batchelder wrote:


Read and listen more.  Write and say less.


Mark Janssen has no interest in learning.  From a thread long-ago:

Mark Janssen wrote:

Ethan Furman wrote:

Mark Janssen wrote:


Really?

-- int=five
-- [int(i) for i in [1,2,3]]

TypeError:  str is not callable

Now how are you going to get the original int type back?


Mark Janssen, you would increase your credibility if you actually *learned*
Python.


Thank you, I actually knew it and was feigning ignorance for a good
reason -- where is this magical assignment stack which remembers
what int was originally bound to after I rebound it myself?


As you can see, if caught out he claims he was feigning ignorance, but then 
immediately shows the ignorance is real.

I take some solace in him not being a profane troll, as some in the past have 
been.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-17 Thread Roy Smith

In article cb5c412c-7d41-4778-acc6-c82200848...@googlegroups.com,
 Peter Cacioppi peter.cacio...@gmail.com wrote:

 OTOH, I've seen object-based C development projects (I.e. where you could 
 tell what function was being called at compile time) that are quite readable. 

If you can tell what function will be called by looking at the code, 
it's not object oriented enough :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Fri, Oct 18, 2013 at 11:01 AM, Roy Smith r...@panix.com wrote:
 In article cb5c412c-7d41-4778-acc6-c82200848...@googlegroups.com,
  Peter Cacioppi peter.cacio...@gmail.com wrote:

 OTOH, I've seen object-based C development projects (I.e. where you could
 tell what function was being called at compile time) that are quite readable.

 If you can tell what function will be called by looking at the code,
 it's not object oriented enough :-)

Is that why there's the International Object-oriented C Code Contest
at www.ioccc.org ?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, 17 Oct 2013 07:49:52 -0700, Mark Janssen wrote:

 It's like this.  No matter how you cut it, you're going to get back to
 the computers where you load instructions with switches.  At that point,
 I'll be very much looking in anticipation to your binary-digit lexer.

Why stop there? If you go back far enough, you've got Babbage with his 
Analytical Engine and his laboriously hand-cast analog gears.

Nobody disputes than once there were no parsers or lexers, and then some 
time later there were. But so bloody what? That is ancient history, 
irrelevant to the practice of computer programming for the last sixty 
years. There is likely hardly anyone still alive who was programming 
using switches, there weren't that many of them in the first place and 
they would be in their 80s or 90s now.

It's not the fact that parsers once didn't exist that people object to, 
but your total misunderstanding of when that was and its significance to 
computer science today.

Relevant:

http://www.xkcd.com/451/



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, Oct 17, 2013 at 3:10 PM, Ethan Furman et...@stoneleaf.us wrote:
 On 10/17/2013 01:57 PM, Ned Batchelder wrote:


 Read and listen more.  Write and say less.


 Mark Janssen has no interest in learning.  From a thread long-ago:

 Mark Janssen wrote:

 Ethan Furman wrote:

 Mark Janssen wrote:


 Really?

 -- int=five
 -- [int(i) for i in [1,2,3]]

 TypeError:  str is not callable

 Now how are you going to get the original int type back?


Thank you for bringing this back up.  Was it you who suggested that
built-in are re-assignable?  Because this is a bad idea for the
reasons I just showed.  My error in that example was going into arcane
points that I should have cross-checked in the Python language
definition (that built-ins were or were *not* assignable), then I
wouldn't have had to have made my (otherwise valid) point, that there
is no magical stack which will remember your language re-assignment
so that you can get it back, but then the example should have never
been pushed into existence in the first place.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, 17 Oct 2013 19:24:58 +1100, Chris Angelico wrote:

 Anyway, what I sought to prove was that polymorphic object oriented code
 can be written in C or any other language.

The proof of this is that any Turing-complete language can simulate any 
other language. Obviously the *difficulty* can vary, but any sufficiently 
expressive language can be used to write an interpreter for some other 
language which gives you the results you want.

I'm not just talking hypothetically here. Python is polymorphic, and 
there are at least two Python implementations written in C (CPython and 
Stackless). So if you took all the C code which implements object-
oriented behaviour within CPython, added it to your C project, and then 
used it directly as a framework, you would have polymorphic code written 
using nothing but C.

Of course, this wouldn't be idiomatic C code, and you won't have syntax 
for what you want, but that's why other languages get invented in the 
first place.


-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

 It's like this.  No matter how you cut it, you're going to get back to
 the computers where you load instructions with switches.  At that point,
 I'll be very much looking in anticipation to your binary-digit lexer.

 Why stop there? If you go back far enough, you've got Babbage with his
 Analytical Engine and his laboriously hand-cast analog gears.

And there you bring up the heart of it:  the confusion in computer
science.  thank you.  Babbage's differential engine is not doing
*computation* , it is doing *physics*.  We must draw a line somewhere,
because the digital realm in the machine is so entirely separate from
the physics (and even the physical hardware), that I could make a
whole other universe that does not conform to it.  It is a whole other
ModelOfComputation.

Q.E.D.  (Who else is going to have to eat a floppy disk here?)

 Relevant:

 http://www.xkcd.com/451/

*winks*.  BTW, all this regarding models of computation and such is
relevant to the discussion only because of one thing:  I like python.
I will leave that vague response for a later exercise after I get an
invite from a University (MIT?) to head their Computer Engineering
department.

Cheers,

Mark
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, 17 Oct 2013 18:59:07 -0700, Mark Janssen wrote:

 -- int=five
 -- [int(i) for i in [1,2,3]]

 TypeError:  str is not callable

 Now how are you going to get the original int type back?


Trivially easy:

py int
type 'int'
py int = five  # Oops!
py int(42.5)
Traceback (most recent call last):
  File stdin, line 1, in ?
TypeError: 'str' object is not callable
py del int
py int(42.5)  # Phew!
42



 Thank you for bringing this back up.  Was it you who suggested that
 built-in are re-assignable?  


It's not just a suggestion, it is a fact. The built-ins are just a 
namespace, like any other module, class, or other namespace.

(Of course, if you break something in the built-ins, the consequences are 
likely to be significantly more wide-ranging, but that's another issue.)

However, in the code shown above, you don't actually reassign a built-in. 
You merely shadow it within the current module. Do you understand the 
difference? In the above, the *builtin* int still exists, but your code 
can no longer get direct access to it because a *global* int gets in the 
way. Using Python 2.7:

py import __builtin__ as builtins
py builtins.int
type 'int'
py int = five
py int
'five'
py builtins.int
type 'int'

so deleting the global int simply reveals the otherwise hidden 
builtin.int instead.

However, if you rebind the builtin, Python doesn't remember what the old 
value was (although in principle it could):

py del int  # get rid of the global
py int is builtins.int
True
py builtins.int = six  # oh oh, this could be bad
py int
'six'
py del int
Traceback (most recent call last):
  File stdin, line 1, in ?
NameError: name 'int' is not defined



In this case, deleting the builtin doesn't magically recover it, it just 
deletes it:

py del builtins.int
py int
Traceback (most recent call last):
  File stdin, line 1, in ?
NameError: name 'int' is not defined


At this point, in general, you've buggered up the current Python 
environment and would normally need to restart the interpreter. But in 
this specific case, all is not quite so lost: we can recover from this if 
only we can find another reference to the int built-in type, and restore 
it to the builtins:


py builtins.int = type(42)
py int(23)
23


I see no reason why Python couldn't create a read-only backup builtins 
namespace, but on the other hand, why bother?


 Because this is a bad idea for the reasons I just showed.

Breaking things is always a bad idea. But re-binding is not necessarily 
a bad thing. Let's say I want to find out how often the built-in len 
function is called by some module:


py count = 0
py def mylen(x):
... global count
... count += 1
... return _len(x)
...
py _len = len  # save the real len
py builtins.len = mylen  # monkey-patch the builtins
py import mymodule
py count
3

Now obviously this is a trivial example. But there are more interesting, 
and useful, reasons for monkey-patching builtins, usually for testing and 
debugging purposes. Such a technique should be used with caution, but it 
can be used.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Wed, 16 Oct 2013 23:49:02 -0700, Peter Cacioppi wrote:

 Even Python, which isn't strongly typed

I see that in a later message you have stepped away from that 
misconception, but I think it is well worth reading this essay:

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

previously known as What To Know Before Debating Type Systems.


I think the author goes a little too far to claim that strong and 
weak are meaningless terms when it comes to type systems. I think it is 
quite reasonable to accept that there is no hard and fast line dividing 
strongly and weakly typed languages, without concluding that the 
terms are meaningless. I think it is reasonable to say that Haskell has a 
very strong type system, since it will (almost?) never allow any 
operation on an unexpected type, or automatically convert one type to 
another. Pascal is a little weaker, since it will automatically convert 
numeric types but nothing else. Perl and PHP are a lot weaker, since they 
will convert strings to numbers and vice versa. If you want to draw the 
line between strong and weak so that Pascal is on one side and Perl 
on the other, that seems reasonable to me.

One thing he missed is that there are untyped languages where everything 
is the same type. If everything is the same type, that's equivalent to 
there being no types at all. Examples include TCL and Hypertalk, where 
everything are strings, and Forth, where everything are two-byte words.

But I digress. Apart from those couple of little criticisms, I think it 
is a very useful article to read.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thursday, October 17, 2013 11:14:29 PM UTC+5:30, MRAB wrote:
 On 17/10/2013 18:32, rusi wrote:
  On Wednesday, October 16, 2013 1:56:27 AM UTC+5:30, zipher wrote:
  Yes, well clearly we are not having the same thoughts, yet the
  purpose of the academic establishment is to pin down such
  terminology and not have these sloppy understandings everywhere.
  You dig?
 
  Heh Mark I am really sorry.  I think this is the third or fourth time
  that I say something to which you reply with such egregious rubbish
  -- parsing has something to do with card-punches?!?! Yeah like python
  has something to do with the purple shirt I am wearing -- that a
  dozen others jump at you with a resounding 'Cut the crap!'
 
  Well speaking for myself, I know I speak more wisely sometimes and
  more stupidly at others and I would wish my penalizers to calibrate
  the punishment to the crime.
 
  Likewise here. I certainly 'dig' your passion to clean up the 'sloppy
  understandings everywhere' and would only wish for you the sanity of
  more knowledge of the subject before you begin to hold forth.
 
 I learned a new word yesterday: ultracrepidarian. :-)

Hehe!
And if you had uttered 'ultracrepidarian' before yesterday you would have been
ultracrepidarian. After that not.
[With frank and free respect to the power of google and cut-n-paste]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Friday, October 18, 2013 7:38:30 AM UTC+5:30, zipher wrote:
  It's like this.  No matter how you cut it, you're going to get back to
  the computers where you load instructions with switches.  At that point,
  I'll be very much looking in anticipation to your binary-digit lexer.
 
  Why stop there? If you go back far enough, you've got Babbage with his
  Analytical Engine and his laboriously hand-cast analog gears.
 
 And there you bring up the heart of it:  the confusion in computer
 science.  thank you.  Babbage's differential engine is not doing
 *computation* , it is doing *physics*.  

And today's computers dont 'do' electronics??

Heres Dijkstra
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD09xx/EWD924.html
and search forward to 'magic'

 We must draw a line somewhere,
 because the digital realm in the machine is so entirely separate from
 the physics (and even the physical hardware), that I could make a
 whole other universe that does not conform to it.  It is a whole other
 ModelOfComputation.
 
 Q.E.D.  (Who else is going to have to eat a floppy disk here?)


  Relevant:
 
  http://www.xkcd.com/451/

 *winks*.  BTW, all this regarding models of computation and such is
 relevant to the discussion only because of one thing:  I like python.
 I will leave that vague response for a later exercise after I get an
 invite from a University (MIT?) to head their Computer Engineering
 department.

Jokes have a propensity to reveal the subconscious of the jokers
[Btw that joke is usually called a pun]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Thu, 17 Oct 2013 19:08:30 -0700, Mark Janssen wrote:

 It's like this.  No matter how you cut it, you're going to get back to
 the computers where you load instructions with switches.  At that
 point, I'll be very much looking in anticipation to your binary-digit
 lexer.

 Why stop there? If you go back far enough, you've got Babbage with his
 Analytical Engine and his laboriously hand-cast analog gears.
 
 And there you bring up the heart of it:  the confusion in computer
 science.  thank you.  Babbage's differential engine is not doing
 *computation* , it is doing *physics*.

That's certainly a good example of confusion, but it's not computer 
science's, it's yours.

[Aside: I specifically didn't mention the difference engine because it 
wasn't a full-blown computer, merely a calculating device like an abacus, 
only more complicated. Babbage's Analytical Engine, on the other hand, 
would have been a real, Turing Complete, fully general purpose 
programmable computer, had he ever finished it.]

The point is, *everything* we do is merely physics, since to do 
something means to have matter and energy interacting, and that is 
physics. Yes, Babbage's Analytical Engine was merely doing physics in 
the same way that an iPhone or IBM mainframe is doing physics -- or 
your brain, for that matter. All four examples are reductionism gone mad. 
The fact that the Analytical Engine used mechanical gears, while iPhones 
and mainframes use electrons drifting across doped silicon, and the brain 
uses tiny electric currents in a gelatinous chunk of meat of Byzantine 
complexity made from tens of thousands of chemicals, is the *least* 
interesting part of the exercise, from the perspective of computer 
science.

(Other perspectives are of value. For instance, how does a simple 
molecule like CH₃CH₂OH affect the computations in the brain in such a way 
that leads to punch-ups out the front of King Street nightclubs at 3 on a 
Saturday morning? Inquiring minds want to know!)

One of the insights of computer science, and obviously one that you have 
misunderstood, is that the *medium doesn't matter*. Computation is an 
interesting and important phenomenon in its own right, and it doesn't 
matter[1] whether you implement it using electric current flowing through 
wires and values, in silicon chips, using mechanical gears, water flowing 
through pipes, in the differential growth of DNA-based bacteria -- yes, 
seriously, look up DNA computers -- or in messy slabs of complicated 
meat. Or even using a mathematical abstraction like Conway's Game of Life.


 We must draw a line somewhere,
 because the digital realm in the machine is so entirely separate from
 the physics (and even the physical hardware), that I could make a whole
 other universe that does not conform to it.  It is a whole other
 ModelOfComputation.

But it is precisely because computation is independent of the physical 
media that it is performed on that we *should not* reject Babbage's 
Analytic Engine. It simply doesn't matter that it uses mechanical gears 
instead of doped silicon. That just means it's slower and noisier, not 
that is is any less performing computation.



[1] Except for such boring matters as efficiency and speed.

-- 
Steven
 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Fri, Oct 18, 2013 at 2:14 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 One thing he missed is that there are untyped languages where everything
 is the same type. If everything is the same type, that's equivalent to
 there being no types at all. Examples include TCL and Hypertalk, where
 everything are strings, and Forth, where everything are two-byte words.

 But I digress. Apart from those couple of little criticisms, I think it
 is a very useful article to read.

Continuing the digression slightly: If everything's a string, how do
you handle aggregate types like arrays? Are they outside the type
system altogether (like in C, where an array-of-int isn't something
you can pass around, though pointer-to-int is)? The only language I've
worked with that has everything is strings is REXX, and it does some
fancy footwork with variable names to do mappings, with a general
convention around the use of stem.0 to create ersatz arrays (probably
how JavaScript got the idea).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Fri, 18 Oct 2013 15:12:36 +1100, Chris Angelico wrote:

 On Fri, Oct 18, 2013 at 2:14 PM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 One thing he missed is that there are untyped languages where
 everything is the same type. If everything is the same type, that's
 equivalent to there being no types at all. Examples include TCL and
 Hypertalk, where everything are strings, and Forth, where everything
 are two-byte words.

 But I digress. Apart from those couple of little criticisms, I think it
 is a very useful article to read.
 
 Continuing the digression slightly: If everything's a string, how do you
 handle aggregate types like arrays? Are they outside the type system
 altogether (like in C, where an array-of-int isn't something you can
 pass around, though pointer-to-int is)? 

I don't know about TCL, but in Hypertalk, when I said everything is a 
string, I meant it. If you want a list of strings, you create one big 
string using some delimiter (usually spaces, commas or newlines). So I 
might say something like:

# it's been a few years, I may have some of the syntax wrong
put field list of stuff into text
for i = 1 to the number of lines of text:
get line i of text
if word 3 of item 6 of it is stop then do_stop()
else do_start(word 1 of item 2 of it)

Hypertalk uses (almost) natural language chunking: lines are chunks of 
text separated by newlines, items are separated by commas, and words are 
separated by spaces. So you can easily implement up to three dimensional 
arrays:

a b,c d,e f
g h,i j,k l
m n,o p,q r

is a list of three lines, each line having three items, each item having 
two words. (Oh, and there's one more layer of chunking: the character or 
char. Guess what that does?)


Actually, perhaps it's not quite true that everything is a string. 
Hypertalk also has fields, which are text fields in the GUI environment. 
Fields have properties such as the textsize and the font, as well as 
contents, which are strings. There are also buttons, which don't have 
contents, although some of them can have state like On or Off. There are 
cards, which contain fields and buttons, and backgrounds, which contain 
cards, and stacks, which contain backgrounds. So it actually was rather 
object-oriented in a way, but the objects were completely tied to the GUI 
environment. You couldn't directly create an abstract field object, 
instead you treated it like a macro playback and did things like this:

choose menu item New Field from Tools menu
set the name of field New Field to foo
set the rect of field foo to 25,25,100,200

or if you were really keen, or perhaps foolish:

select field tool
drag from 25,25 to 100,200
set the name of field (the number of fields) to foo


Despite its flaws, it was great fun to program in, and the best 
integrated GUI programming environment I've every seen by far.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Fri, Oct 18, 2013 at 3:45 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 I don't know about TCL, but in Hypertalk, when I said everything is a
 string, I meant it. If you want a list of strings, you create one big
 string using some delimiter (usually spaces, commas or newlines).

Fair enough. As a system, that works reasonably cleanly... if a little
inefficiently, since you need to delimit everything. But hey, your
arrays are first-class objects by definition, and that's a good thing!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

On Tue, Oct 15, 2013 at 2:46 PM, Grant Edwards invalid@invalid.invalid wrote:
 On 2013-10-15, Mark Janssen dreamingforw...@gmail.com wrote:

 Yeah, well 40 years ago they didn't have parsers.

 That seems an odd thing to say. People were assembling and compiling
 computer programs long before 1973.

I'm using the word parser in the sense of a stand-alone application
that became useful with the growing open source culture that was
developing in the 70's.  Prior to that you have punch cards where
there's no meaningful definition of parsing because there are no
tokens.  Would you say you were parsing on an old digital machine
where you input programs with binary switches?

But after the advent of the dumb terminal, parsers started evolving,
and that was the early 70's.  I might be a year or two off, but I only
gave one significant digit there.   ;^)

Cheers,
-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

 Types on the other hand correspond to our classifications and so are
 things in our minds.

 That is not how a C programmer views it.  They have explicit
 typedefs that make it a thing for the computer.

 Speaking as a C programmer, no.  We have explicit typedefs to create new
 labels for existing types, to make the type-abstraction easier to relate to
 the object-abstraction.

Who uses object abstraction in C?  No one.  That's why C++ was invented.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread rusi

On Wednesday, October 16, 2013 11:27:03 PM UTC+5:30, zipher wrote:
  Types on the other hand correspond to our classifications and so are
  things in our minds.
 
  That is not how a C programmer views it.  They have explicit
  typedefs that make it a thing for the computer.
 
  Speaking as a C programmer, no.  We have explicit typedefs to create new
  labels for existing types, to make the type-abstraction easier to relate to
  the object-abstraction.
 
 Who uses object abstraction in C?  No one.  That's why C++ was invented.

I wonder if you've heard of something called linux?
http://lwn.net/Articles/444910/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread Grant Edwards

On 2013-10-16, Mark Janssen dreamingforw...@gmail.com wrote:
 On Tue, Oct 15, 2013 at 2:46 PM, Grant Edwards invalid@invalid.invalid 
 wrote:
 On 2013-10-15, Mark Janssen dreamingforw...@gmail.com wrote:

 Yeah, well 40 years ago they didn't have parsers.

 That seems an odd thing to say. People were assembling and compiling
 computer programs long before 1973.

 I'm using the word parser in the sense of a stand-alone application
 that became useful with the growing open source culture that was
 developing in the 70's.  Prior to that you have punch cards where
 there's no meaningful definition of parsing because there are no
 tokens.

What do you mean there are no tokens?.   Pascal/Fortran/COBOL on
a deck of punched cards is parsed/compiled the same as it is in a file
on a hard drive.

 Would you say you were parsing on an old digital machine
 where you input programs with binary switches?

No, that's not what I'm talking about.  I'm talking about compiling
Fortran or PL/1 or whatnot.

 But after the advent of the dumb terminal, parsers started evolving,
 and that was the early 70's.  I might be a year or two off, but I only
 gave one significant digit there.   ;^)

I don't understand what dumb terminals have to do with it.

-- 
Grant Edwards   grant.b.edwardsYow! I'm GLAD I
  at   remembered to XEROX all
  gmail.commy UNDERSHIRTS!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread Grant Edwards

On 2013-10-16, Mark Janssen dreamingforw...@gmail.com wrote:
 Types on the other hand correspond to our classifications and so are
 things in our minds.

 That is not how a C programmer views it.  They have explicit
 typedefs that make it a thing for the computer.

 Speaking as a C programmer, no.  We have explicit typedefs to create new
 labels for existing types, to make the type-abstraction easier to relate to
 the object-abstraction.

 Who uses object abstraction in C?  No one.

It's not that uncommon.  I've seen it done many times.

 That's why C++ was invented.

C++ was invented because people _were_ doing object abstraction in C
and wanted an easier way to do it.

-- 
Grant Edwards   grant.b.edwardsYow! I'm continually AMAZED
  at   at th'breathtaking effects
  gmail.comof WIND EROSION!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread Skip Montanaro

 Who uses object abstraction in C?  No one.  That's why C++ was invented.

 I wonder if you've heard of something called linux?
 http://lwn.net/Articles/444910/

If not, Linux, how about Python?

http://hg.python.org/cpython/file/e2a411a429d6/Objects

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread Chris Angelico

On Thu, Oct 17, 2013 at 5:49 AM, Skip Montanaro s...@pobox.com wrote:
 Who uses object abstraction in C?  No one.  That's why C++ was invented.

 I wonder if you've heard of something called linux?
 http://lwn.net/Articles/444910/

 If not, Linux, how about Python?

 http://hg.python.org/cpython/file/e2a411a429d6/Objects

Or huge slabs of the OS/2 Presentation Manager, which is entirely
object oriented and mostly C. It's done with SOM, so it's possible to
subclass someone else's object using a completely different language.
Makes for a lot of boilerplate in the source code, but it works. You
can even - often without the different subclasses being aware of each
other - have two or more unrelated modules each subclass-and-replace a
standard class like WPFolder (which represents a folder, usually
backed by a directory on disk) to modify its behaviour.

Yep, definitely possible to write OO code in C.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

 Who uses object abstraction in C?  No one.  That's why C++ was invented.

 If not, Linux, how about Python?

 http://hg.python.org/cpython/file/e2a411a429d6/Objects

 Or huge slabs of the OS/2 Presentation Manager, which is entirely
 object oriented and mostly C. It's done with SOM, so it's possible to
 subclass someone else's object using a completely different language.

Now this is the first real objection to my statement: OS/2 and the
Presentation Manager, or windowing system.

But, here it is significant that the user /consumer (i.e. *at the
workstation* mind you) is *making* the object because thier visual
system turns it into one.  Otherwise, at the C-level, I'm guessing
it's normal C code without objects, only struct-ured data.  That is,
you don't get all the OOP benefits like inheritance, polymorphism and
encapsulation.  C can do 2 of those, albeit kludgingly, but not all
three.  And without all three, it's not at all well-established that
you're doing real OOP.

-- 
MarkJ
Tacoma, Washington
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread Chris Angelico

On Thu, Oct 17, 2013 at 11:13 AM, Mark Janssen
dreamingforw...@gmail.com wrote:
 But, here it is significant that the user /consumer (i.e. *at the
 workstation* mind you) is *making* the object because thier visual
 system turns it into one.  Otherwise, at the C-level, I'm guessing
 it's normal C code without objects, only struct-ured data.  That is,
 you don't get all the OOP benefits like inheritance, polymorphism and
 encapsulation.  C can do 2 of those, albeit kludgingly, but not all
 three.  And without all three, it's not at all well-established that
 you're doing real OOP.

Wrong. At the C level, it's all still objects, with inheritance,
polymorphism, and encapsulation. Piles and piles of boilerplate to
make things work, and you have to compile your .IDL file into C and
then fill in your code, and make sure you don't disrupt things, but it
works beautifully. It's object oriented machine code.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread alex23


On 17/10/2013 3:57 AM, Mark Janssen wrote:

Who uses object abstraction in C?  No one.  That's why C++ was invented.


Aristotle maintained that women have fewer teeth than men; although he 
was twice married, it never occurred to him to verify this statement by 
examining his wives' mouths. -- Bertrand Russell


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)

2013-10-16 Thread Ned Batchelder


On 10/16/13 8:13 PM, Mark Janssen wrote:

Who uses object abstraction in C?  No one.  That's why C++ was invented.

If not, Linux, how about Python?

http://hg.python.org/cpython/file/e2a411a429d6/Objects

Or huge slabs of the OS/2 Presentation Manager, which is entirely
object oriented and mostly C. It's done with SOM, so it's possible to
subclass someone else's object using a completely different language.

Now this is the first real objection to my statement: OS/2 and the
Presentation Manager, or windowing system.

But, here it is significant that the user /consumer (i.e. *at the
workstation* mind you) is *making* the object because thier visual
system turns it into one.  Otherwise, at the C-level, I'm guessing
it's normal C code without objects, only struct-ured data.  That is,
you don't get all the OOP benefits like inheritance, polymorphism and
encapsulation.  C can do 2 of those, albeit kludgingly, but not all
three.  And without all three, it's not at all well-established that
you're doing real OOP.



Mark, it's clear you're passionate about computer science, but with all 
due respect, you need to learn more about it.  Real OOP is a misnomer: 
every language brings its own style of OOP, none more legitimate than 
any other.  And your earlier idea that punched cards didn't have tokens 
is wildly ignorant of the state of software and languages 50 years ago.


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python was designed (was Re: Multi-threading in Python vs Java)