Not fully OO ?

[Aaron "Castironpi" Brady]

On Sep 28, 4:41 pm, "Tim Rowe" <digi... at gmail.com> wrote:
> 2008/9/28 Aaron Castironpi Brady <castiro... at gmail.com>:
>
> > 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?
>
> --
> Tim Rowe

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.