On Sep 28, 4:41 pm, "Tim Rowe" <[EMAIL PROTECTED]> wrote:
> 2008/9/28 Aaron Castironpi Brady <[EMAIL PROTECTED]>:
>
> > 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.
--
http://mail.python.org/mailman/listinfo/python-list
