Re: Not fully OO ?

[Aaron \Castironpi\ Brady]

Re: Not fully OO ?

On Sep 26, 8:10 pm, "Tim Rowe" <digi...@gmail. comwrote:

2008/9/27 Aaron Castironpi Brady <castiro...@gma il.com>:
>

But I, and I imagine I'm not the only one, would love to know the
example that C# developed faster than Python.  I suppose the fact that
the line of wx specification that has two identifiers where C# has one
is more of a drain on programmer resources than may commonly be
recognized--- not the same as the cost of one extra word in a paper or
in an editorial.  Similarly, maybe the program that has one extra
identifier in a line takes a lot more time to develop.

>
But I didn't use wx -- that's rather the point.  Long before the days
of Python, I kept wanting to use Modula2 but kept getting driven back
to C because in Modula2 I kept having to write stuff that was already
in C libraries. Modula2 was a far better language, but C usually was
far more productive because of what went around it.  C#'s tight
integration with .net and VS mean that it's not a question of one
identifier instead of two, it's *zero* identifiers instead of two
because the tool does it all for me.  Does that mean that C# is a
better language than Python? No, of course not. Does it mean that what
I was doing was not possible in Python? No, of course not. Does it
mean that C# was more productive than Python for me doing that
particular job? Yes it does. (FWIW, I also found the .net XML handling
easier to cope with on that same job).
>
One day Iron Python plus the VS integration might wean me off C# but
last time I looked it wasn't close. Maybe I should take another look
and see how it's coming on.
>
--
Tim Rowe

No way. It's *zero* instead of one, if so, because the only thing C#
has is a bunch of handcuffs and implicit 'self'. You have a line
like:

n= aTree.ExpandedC ount

What in 'wx', which I -am- using, <avoids insubordinate tone>, takes
more identifiers:

n= self.aTree.Expa ndedCount

or if you're 'inlining', for lack of better words, everything, outside
a class,

n= aForm.aTree.Exp andedCount.

For a grand total of 1 'aForm' identifier that C# infers implicitly.

[Tim Rowe]

Re: Not fully OO ?

2008/9/27 Aaron Castironpi Brady <castironpi@gma il.com>:

No way. It's *zero* instead of one, if so, because the only thing C#
has is a bunch of handcuffs and implicit 'self'. You have a line
like:

You don't follow what I said, and from your tone I get the feeling you
don't *want* to follow what I'm saying, not because I'm criticising
Python (I'm not), but because I'm guilty of the heresy of suggesting
that it's not actually simultaneoulsy optimised for every possible
use.

My point is that there are zero parameters as far as I am concerned
because I don't actually touch most of the GUI code. There could
actually be hundreds of parameters, for all I care. They're not my
concern. Most of the time I like that -- the tools are doing my work
for me.

--
Tim Rowe

[Aaron \Castironpi\ Brady]

Re: Not fully OO ?

On Sep 27, 6:55 pm, "Tim Rowe" <digi...@gmail. comwrote:

2008/9/27 Aaron Castironpi Brady <castiro...@gma il.com>:
>

No way.  It's *zero* instead of one, if so, because the only thing C#
has is a bunch of handcuffs and implicit 'self'.  You have a line
like:

>
You don't follow what I said, and from your tone I get the feeling you
don't *want* to follow what I'm saying, not because I'm criticising
Python (I'm not), but because I'm guilty of the heresy of suggesting
that it's not actually simultaneoulsy optimised for every possible
use.
>
My point is that there are zero parameters as far as I am concerned
because I don't actually touch most of the GUI code.  There could
actually be hundreds of parameters, for all I care. They're not my
concern. Most of the time I like that -- the tools are doing my work
for me.
>
--
Tim Rowe

flamewar.avert( ), please. Yes, I agree, I did not follow every
word. It's a fundamental disagreement about successful ways to
communicate, and, for the philosophers, successful communication,
whether I should have nitpicked first thing, or tried to go along with
the gist. I tried the latter. In your case, I guessed wrong. Sorry.

Before I tried wxFormBuilder, I imagined that C# would be vastly
faster to develop than Python, for anything requiring any non-trivial
graphical interface. I've done extensive VB, so I can attest to that
personally. It is not. The difference in dev times is about the time
it takes to write:

def onClick( event ):
...
controlA.bind( wx.MOUSEDOWN, onClick )

perhaps several times, which, <glances at watch>, is not long. You do
get the IDE, true, and that code is auto-crafted for you. But 'wx'
does give you data in an XML file, instead of a script. And talk
about a difference in identifiers:

<form>
<button>
<pos>20,30</pos>
<color>gray</color>
</button>
</form>

vs.

form.button.pos = 20, 30
form.button.col or= gray

You can come up with examples that favor either. But the opposite of
statistical is anecdotal. Sorry again.

The last time I 'checked in' at your post, your claim was "an hour or
so" vs. "ages". Hence my responses. You could probably sneak by by
claiming a factor of *two*, but if you were exaggerating, please say
so at any time.

Penultimately, forgive my sarcasm--- I'm a bit feisty right now. I
was distinguishing between arguments in particular, and identifiers in
general.

And lastly, "simultaneo ulsy optimised for every possible use" is a
bold claim that I didn't make, at least, to come forward, in so many
words. I do believe, and it shows, as of today, and you can quote me
on this, that it's "pretty generally applicable", though I reserve the
right to change my mind on the matter with or without notice.
Especially if I learn something. I do not believe that C# is pretty
generally applicable. I maintain that I will adjust that estimate if
I ever get any facts about C#, since I don't have very many. (In
fact, outside of my VB, COM, and MFC experience, you could say I have
no clue. Very tongue in cheek.)

In fact, do a Google for 'castironpi "every possible"'. You get a
"can't ... every possible", and your post, and something else. That's
it.

Python has a lot of things C# doesn't. Can we agree on that?

[Lawrence D'Oliveiro]

Re: Not fully OO ?

In message <mailman.1515.1 222382168.3487. python-list@python.org >, James
Mills wrote:

On Fri, Sep 26, 2008 at 8:20 AM, Lawrence D'Oliveiro
<ldo@geek-central.gen.new _zealandwrote:
>

>Object orientation IS procedural.

>
Correction: OOP is Imperative.

No, "procedural ".

The functional unit is called an "expression ", the encapsulation of which is
called a "function". Hence "functional ".

Similarly, the procedural unit is commonly called a "statement" , the
encapsulation of which is a "procedure" , not an "imperator" .
Hence "procedural ".

[Lawrence D'Oliveiro]

Re: Not fully OO ?

In message
<f9b466b0-9945-42c1-ad9c-2f65c8d4b907@y3 8g2000hsy.googl egroups.com>,
Aaron "Castironpi " Brady wrote:

I understand that formal proof systems, as well as automated
theorem provers, have been difficult to develop.

The basic problem is: having proved that a program satisfies certain
formally-specified criteria, how do you prove that those formal criteria
specifications actually correspond to the original problem you were trying
to solve? The proof just pushes the correctness problem back another level.

[Bruno Desthuilliers]

Re: Not fully OO ?

Lawrence D'Oliveiro a écrit :

In message <mailman.1515.1 222382168.3487. python-list@python.org >, James
Mills wrote:
>

>On Fri, Sep 26, 2008 at 8:20 AM, Lawrence D'Oliveiro
><ldo@geek-central.gen.new _zealandwrote:
>>

>>Object orientation IS procedural.

>Correction: OOP is Imperative.

>
No, "procedural ".

Nope, "imperative " !-)

The functional unit is called an "expression ", the encapsulation of which is
called a "function". Hence "functional ".
>
Similarly, the procedural unit is commonly called a "statement" , the
encapsulation of which is a "procedure" , not an "imperator" .
Hence "procedural ".

"imperative " means that the computation is done through statements that
modify the program's state.

"procedural " means that these statements are organized in "procedures ",
that group a serie of statements.

OO is based on objects (that carry and manage internal state) and
messages. A message can happen to trigger a serie of statements that
modifies a program state, so you could say (and this wouldn't be totally
false) that an OO method can be seen as a procedure (or at least some
methods...), but the whole program's organization is still not the same
as one seen in procedural programming. IOW, it's more a matter of how
you design / organize your (otherwise imperative) program than anything
else.