Importance of C# (was Re: IronPython-0.6 is now available!)

John johng2001 at
Fri Jul 30 23:33:30 CEST 2004

Oh Boy! You do disagree with almost everything I said. My post was
asking for it. Wasn't it? :-). I don't want to start a language war,
especially with languages not even the topic of the group. Not that
that I dislike language wars. They are educational so long as I am not
in them :-).

VS2005 free version just came out and I am in puppy love. Hence the
passionate post.

I don't have any bone to pick on Swing, EJB or MVC per se. They just
don't solve MY problems (and I tend to think most people's problems)
as easily as I would expect them to.

> > 1.) No classpath issues.
> It *does* have classpath issues - sometimes even greater than Java's -
> but most of the time this is hidden from the developer.

OK! I am unaware of any. Can you point me to some.

> > 4.) IO doesn't require me look up the manuals each time to figure out
> > which 3 or so classes I need this time.
> Why not? Because the APIs closer match another language you've used?
> If so, coincidence.

Not at all! I am not saying C# is special. Just that Java IO is
annoying for day to day tasks. 3 classes to open a file? That is
taking the flexibility factor a bit too far. Would it kill them to
include a few classes for day to day tasks?

> > 5.) Excellent performance (Not just on paper).
> Performance should be about the same, since both languages are
> compiled to native code on startup.

I have no bench marks at hand to back things up. C# apps ALWAYS felt
faster than Java apps in my experience.

> > 6.) Easy deployment.
> Oh, Microsoft's fabled "xcopy deployment"? How is copying a jar file
> harder than compying an EXE plus required DLLs?

Yes! Why do I have to list every jar file I use for the application in
the classpath? Why can't I just drop them in the same folder with the
app and expect the JVM to find them. Isn't that intuitive? Practically
every VM language I know does that. Current folder had to be listed in
explicitly in the current path. Is that intuitive? Every other
language behaves the other way.

> > 7.) Absolutely the best web development framework (OK! I may be
> > getting a bit religious here but I love the component and event driven
> > model. JFaces as I looked at it was not very mature).
> JavaFaces seems to match the functionality of ASP.Net's CodeBehind
> logic, except you're not restricted to an event model; you configure
> events yourself in XML files. IDE support for it is coming.

I would not use ASP.NET without IDE support. ASP.NET and JFaces are
built for IDE technologies. So I consider JFaces immature at present.

  I tried JFaces in Sun's IDE. In general I find servlet container
based approach painful because of the class loaders. I know that many
people use them happily. I am not one of them.

> > 9.) An IDE that actually feels simple.
> Which Java IDEs have you tried? And which C# ones?

WSAD, Netbeans and Eclipse.
Visual Studio.

You are a Java developer and probably have used these IDE's over an
extended period of time to no longer see the complexities within.

To test intuitiveness, take a newbie, give him J# in VS and Java in

To quote an example, we teach Java here. I was discouraged to
introduce Eclipse (which is much simpler than the other Java IDEs and
I loved it immediately after coming across it for the first time) to
the students because it overwhelmed them. On the other hand, I would
not even want to introduce C# without Visual Studio.

> > 10.) DESIGNED for multiple languages (I admit I rediculed this till
> > recently saying that all languages needed needed to be like C# to be
> > supported and it was no better than Java in this. But with IronPython
> > and F#, it looks a bit promising. But I need them to be integrated
> > into Visual Studio for me to love them.)
> The only language designed for .Net is and will always be C#. The
> other languages are *wrestled* into the CLS strait-jacket, and for
> some - like C++ - it does not fit well.

They seemed to compile Quake 2 fine.

More information about the Python-list mailing list