Not fully OO ?

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

I think Patrick is responding to a comment from Tino Wildenhain:

That didn't showed here (reading this from c.l.py via free.fr). Sorry.

Well then it still depends on the perception of "job done". For example
PHP programmers would bet their soul that their language of choice is
exactly the right one to "get the job done."
[end quote]

Patrick, you will cause much less confusion if you quote relevant parts
of the text you are replying too.

Indeed. At least it would have made clear (to me) there was something
missing in the thread...

 

[Bruno Desthuilliers]

Tim Rowe a écrit :

Well, I did say "Often". Before now I've struggled for ages to write a
Python program to do a job, then when I've tried C# all the problems
have fallen away and the job was done in an hour or so.

Not to start a troll, but from what I've seen of C# so far I do find
this a bit surprising and really suspect more of a library issue than a
language one. Care to tell more about the problem and solution ?

(NB : I wouldn't even asked if you had mentionned say Erlang or Prolog
or OCaml - well, some mostly different language - instead of C#)

 

[Aaron \Castironpi\ Brady]

Well, I did say "Often". Before now I've struggled for ages to write a
Python program to do a job, then when I've tried C# all the problems

What problems?

have fallen away and the job

What job?

was done in an hour or so. But other
times it has been the other way around; I've done stuff in Python that
I wouldn't know where to begin with in other languages. One of my
constant refrains is that *no* tool is ideal for *all* jobs!

If you have wxFormBuilder and the win32 library, it's pretty fast.

Python's philosophy is to make common things easy and everything
possible.

 

[Tim Rowe]

Not to start a troll, but from what I've seen of C# so far I do find this a
bit surprising and really suspect more of a library issue than a language
one. Care to tell more about the problem and solution ?

(NB : I wouldn't even asked if you had mentionned say Erlang or Prolog or
OCaml - well, some mostly different language - instead of C#)

IIRC it was library issues -- for one thing I still find it a lot
harder to manage an MS Windows GUI under Python than I do under .NET
(I've never succeeded in getting Iron Python to run properly). In one
sense you could argue that that's not a language issue, and you'd be
right: there's nothing in the syntax or semantics of either language
that makes it so. But in another sense I'd say it is a language issue
(and of course I think I'm right!) because Python aims to be platform
independent, and whilst that means gains in portability it means that
in return it loses the ease-of-programming of a tightly integrated
platform.

 

[Tim Rowe]

If you have wxFormBuilder and the win32 library, it's pretty fast.

Speed has never been an issue for me with Python. For my masters
degree I did a project that involved a lot of number crunching, and in
my proposal I wrote that I'd use Python for most of the code and C for
any parts that were unacceptably slow. In practice, not only did I
never need to replace any parts with C, I never even needed to use
numpy; it was quite fast enough as it was.

Python's philosophy is to make common things easy and everything
possible.

But what's common for one person may be uncommon for another. And
sometimes "possible" isn't enough, or we'd all be using INTERCAL!

Another, quite different example to the one I was referring to earlier
is the fact that I often work with safety critical systems. I don't
think formal proof of program behaviour would be at all
straightforward in Python (or C# for that matter, and although Spec#
gets closer, it really needs a language like Spark Ada).

 

[Aaron \Castironpi\ Brady]

Speed has never been an issue for me with Python. For my masters
degree I did a project that involved a lot of number crunching, and in
my proposal I wrote that I'd use Python for most of the code and C for
any parts that were unacceptably slow. In practice, not only did I
never need to replace any parts with C, I never even needed to use
numpy; it was quite fast enough as it was.


But what's common for one person may be uncommon for another. And
sometimes "possible" isn't enough, or we'd all be using INTERCAL!

Another, quite different example to the one I was referring to earlier
is the fact that I often work with safety critical systems. I don't
think formal proof of program behaviour would be at all
straightforward in Python (or C# for that matter, and although Spec#
gets closer, it really needs a language like Spark Ada).

No. I understand that formal proof systems, as well as automated
theorem provers, have been difficult to develop. When I took ML, the
homeworks were to prove the correctness of an interpretation of a
program, and the unique existence of a meaning by induction.

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. Perhaps it's
the "7 +/- 1" trend in attention span that makes the difference large
in that case. 8 identifiers would in that theory be a big deal, so
the example in C# could make the case for it.

 

[Tim Rowe]

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.

 

[Aaron \Castironpi\ Brady]

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.

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

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

n= self.aTree.ExpandedCount

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

n= aForm.aTree.ExpandedCount.

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

 

[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:

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.

 

[Aaron \Castironpi\ Brady]

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.

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.color= 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, "simultaneoulsy 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]

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]

In message

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]

Tim Rowe a écrit :

IIRC it was library issues -- for one thing I still find it a lot
harder to manage an MS Windows GUI under Python than I do under .NET
(I've never succeeded in getting Iron Python to run properly). In one
sense you could argue that that's not a language issue, and you'd be
right: there's nothing in the syntax or semantics of either language
that makes it so. But in another sense I'd say it is a language issue
(and of course I think I'm right!)

And - after reading the following argument - I think you're wrong !-)

because Python aims to be platform
independent, and whilst that means gains in portability it means that
in return it loses the ease-of-programming of a tightly integrated
platform.

Still a library issue. Python doesn't defines "platform-independant" the
way Java does, and there are quite a couple Python packages (third-part
or even in the standard lib) that are clearly platform-specific -
including MS Windows COM stuff, which was a major PITA using VB6.

 

[Tim Rowe]

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.

I'm confused about where VB comes in -- I find VB just *slightly*
harder than INTERCAL. C# I find fairly easy.

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

Yes, it's anecdotal, but development time isn't just about how fast
the program is to type (otherwise, why aren't we all using APL?)

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.

Ok. I was exaggerating when I said that VB was harder than INTERCAL.
It's marginally easier.

As for the program I was working on, I worked for over a day on it in
Python, and did it in about an hour in C#, although in fairness I
didn't forget all the thinking I'd done on the previous day. I have a
lot more Python experience than C# experience, but don't claim to be a
guru in either. And no, I don't work two hour days (unfortunately). I
have indicated that the GUI wasn't the only issue; in C# it was just
easy in that case to find all the library bits I needed to in order to
accomplish the task. It isn't always so.

on this, that it's "pretty generally applicable"

I'm with you on that.

I do not believe that C# is pretty generally applicable.

I agree on that, but *only* because it's a proprietary language with
imperfect support once you move away from the .net platform. It's a
generally applicable language to .net, but .net is not a general
platform.

fact, outside of my VB, COM, and MFC experience, you could say I have
no clue. Very tongue in cheek.)

If you see C# as being in any way related to VB, it's no wonder you're
down on it!

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

And C# has things that Python doesn't (such as static typing). Can we
agree on that, too?

 

[Aaron \Castironpi\ Brady]

I'm confused about where VB comes in -- I find VB just *slightly*
harder than INTERCAL. C# I find fairly easy.


Yes, it's anecdotal, but development time isn't just about how fast
the program is to type (otherwise, why aren't we all using APL?)


Ok. I was exaggerating when I said that VB was harder than INTERCAL.
It's marginally easier.

As for the program I was working on, I worked for over a day on it in
Python, and did it in about an hour in C#, although in fairness I
didn't forget all the thinking I'd done on the previous day. I have a
lot more Python experience than C# experience, but don't claim to be a
guru in either. And no, I don't work two hour days (unfortunately). I
have indicated that the GUI wasn't the only issue; in C# it was just
easy in that case to find all the library bits I needed to in order to
accomplish the task. It isn't always so.


I'm with you on that.


I agree on that, but *only* because it's a proprietary language with
imperfect support once you move away from the .net platform. It's a
generally applicable language to .net, but .net is not a general
platform.


If you see C# as being in any way related to VB, it's no wonder you're
down on it!


And C# has things that Python doesn't (such as static typing). Can we
agree on that, too?

Maybe too much of my personal life is affecting my judgment of C#.
You mention tools (that are doing the work for you) and I think
incompatibility. Maybe that part is just because I feel like tools
are like 'excuses'. And maybe that part is just because... awkward.

I'm going to have to bow out of the dispute, sorry, because I am not a
person that knows both of them. (How you decide who knows a language
isn't exactly clear, by the way. It's been stated, for example, that
I don't know Python, as well as that I don't know English.)

You said C# = 1 hour, Python = ages. I said I could see that if it
came to developing a GUI with a draw-on tool in one and not in the
other. (Write that C# GUI spec by hand or position your controls from
scratch.)

You could make a case that you can get bad habits from developing in a
tightly-coupled ("tightly-integrated") framework, as you suggested C#
was. I would agree to it.

I do not find that the Python library is particularly lacking, and the
VB6 library was.

If you're referring to documentation, though, I really like the win32
API docs. They're precise and thorough. The Python docs leave some
stuff unsaid; there's a lot of stuff you can do in Python that people
have to tell you or you have to discover on your own. Which one are
the C# docs like?

Not to reopen the wound, or rather to reopen it patiently: I classify
'static-typing' as handcuffs. C# has handcuffs and lots of kinds of
them. "But static-typing lets you do <fill in the blank>." ? Other
than that, I don't know of any examples, from which I won't infer that
there aren't any. (That was -won't- infer.) "Call," I guess; I'll
bite. What?

If you're referring to library depth, there's a lot of stuff that
probably classifies as wheel reinvention that shouldn't necessarily go
in the library. There was a good example today. 'Return a string of
5 random digits.' You could put that in the library, and call it
'RandomDigitString( int length )'. Doing it by hand only takes one
line though: '"%05i"%random.randint(0,99999)'. Does it belong in the
library? Otherwise you're technically reinventing the wheel, right?

If you want to talk about your application, the day-to-hour ratio
example, please do.

 

[Bruno Desthuilliers]

Lawrence D'Oliveiro a écrit :

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.