C# appreciation thread

How many of you guys prefer coding in C#? I feel that C# is the best language for quickly coding programs for windows, and with managed directx there's tons of awesome stuff you can do. I just started my computer-education this autumn, and we're being forced to make stuff in java. Java and C# are pretty much identical, only C# has more functionality (WHY doesn't java have properties? X| ), has the infitely superior development environment ('cause remembering the syntax of your programming language is SO last paradigm), and, in my experience, runs a good deal faster than java.

in before flamewar

arguing a language is better by comparing it to java.... kids these days.

C# is .NET. F-F-F-F-FATALITY!

>>1

On a basic level, C# and Java are similar, but the deeper you learn the language the more differences you'll find.  I, personally, prefer C# due to some of the language features (and especially some of the *upcoming* language features--- C# is slowly evolving into a much more modern language than its immediate peers. Type inferencing, lambda expressions, and extension methods, oh my!), but Java's been around longer and allows more easily consistent development no matter what sort of computer you, as a student, happen to be using at home.

I, personally, am of the school of thought where a student's first language should be some sort of assembler, and higher level languages are built up from there.  If you've written "Hello World" in Sparc assembly, you'll be thanking your lucky stars you get to work in C or Java.  Heh.

I haven't used it yet, but it's not Lisp so it's already off to a bad start.

>>5
I think likewise.

How does it compare to python, which I already have installed?

Just tell me one thing: does it use statements or is everything an expression? If it's the latter I might consider trying it out. Statements are so 1960s punch card readers.

Nevermind I googled for "c# statements" and apparently it's no different from all the other dumb powerless languages.

>>10 need a bigger eWang.

>>10 is being an elitist language dork who doesn't recognize the value of massive quantities of industrial-strength libraries and the expense of training entire devteams in intelligent uses of different paradigms. 

If we ignore him, he'll probably go away.

>>12
Java has massive quantities of industrial-strength libraries, that doesn't mean it's any good.

>>1
Who's stupid enough to want intermediate code/virtual machine ("managed code") when it's not really cross-platform? That's a retarded idea aimed to trick Java fans in. If you're writing Windows applications, compile them for real, because you can, and it's better.

>>3
Yeah, that's not saying much, is it? :)

>>13

I didn't say it's good.  I said it's valuable.  There's a difference.

Java has its place, though, as almost every language does.  I still think it's great fun for small-to-medium sized webapps.

>>14

You have a simplified view of the virtual machine paradigm.  While I agree that the lack of initial cross-platform support is a significant potential feature that's being given the boot, you're disregarding other advantages of the virtual machine approach.

* Multi-language interoperability if the languages are built on the same VM.  This way even the language snobs (>>10) can write code that interfaces with production code.

* Platform for API experimentation with (initially, anyway) no backcompat concerns.

* Additional "sandbox" infrastructure.  Another layer of isolation can only be a good thing.

* Ability to define a low level assembly language without creating a corresponding hardware architecture.

* And, with C# in particular, a sneaky means to introduce modern language features (whose absence language snobs like >>10 always bemoan) to the unwashed masses while maintaining a comfortable, familiar development environment.

And I've only scratched the surface.  Cross platform operability is *not* the only advantage to using a virtual machine paradigm.

>>15
Java for small to medium sized webapps? Sure if you enjoy S&M!

>>16

You have a different opinion than >>15 about something that's completely subjective.  Congratulations.  Have a cookie.

>>17
You just said a bunch of crap that's neither interesting nor relevant. Have two cookies and a +4 insightful.

>>18
Harb.

15 cookies.

>>15
I still think it's great fun for small-to-medium sized webapps.
Your idea of fun is very different from mine, then :P

As for VMs:

Multi-language interoperability if the languages are built on the same VM.
This was possible with real code decades ago. Ever heard of object linking?

Platform for API experimentation with (initially, anyway) no backcompat concerns.
I don't really see this as an advantage; you can always build new APIs for existing platforms. For example, MFC was built on Win32.

Additional "sandbox" infrastructure.  Another layer of isolation can only be a good thing.
I agree, this is good, but not it gets in the way if you want high performance applications. Interpreted code and virtual machines is great for web applications, scripts, and other stuff, but not for 85% of the software you have in your hard disk right now.

Ability to define a low level assembly language without creating a corresponding hardware architecture.
This is fun, but useless. I think many of us (including myself) created his/her toy virtual machine one day, but you shouldn't be writing applications for others on your plaything.

And, with C# in particular, a sneaky means to introduce modern language features (whose absence language snobs like >>10 always bemoan) to the unwashed masses while maintaining a comfortable, familiar development environment.
This doesn't have anything to do with virtual machines. You could just as easily write a real compiler for C# or any langauge supporting these features.

This doesn't have anything to do with virtual machines. You could just as easily write a real compiler for C# or any langauge supporting these features.

Cases in point: GCJ compiles Java bytecode to object code, Common Lisp has plenty of compilers, and ~30 years of performance hacks have made Lisp binaries surprisingly efficient.

>>21 Correct me if I'm wrong; but isn't GCJ rather a bit on the redundant and stupid side?

>>22
Not if it's making things work faster and be equally as portable. In fact, if things can be made to work faster and be equally as portable, it's not doing them what's stupid.

Not if it's making things work faster and be equally as portable.

Except that GJC loses out to modern JITs pretty badly, or at least it did a year ago. Maybe they've improved it since then. On the other hand, it's probably faster than interpreted mode, since there are no JITs for some architectures.

The main benefit to GJC isn't speed. It's memory.

>>24
And since Java's main problem isn't speed, it's memory...

BUT we're getting a little sidetracked here, I was just raising a case in support of >>20's assertion that advanced language features aren't dependent upon VMs.

advanced language features aren't dependent upon VMs.

Indeed. Actually, I find the "virtual machine paradigm" mentioned by >>15 a bit hilarious. Technically, most modern OS's fall under virtual machines too. So what?

I guess some people have trouble seperating language from implementation.

Of course all of the things mentioned in >>15 are possible without VMs.  After all, the VM was built without a VM.  It's an approach to solving a problem in a different way that works well for certain applications and not so well for other applications.  Like *every* designed solution.

Stating that VMs are universally stupid is just as moronic as stating that VMs are universally good.  They're a single solution used to address certain problems that could be addressed in any number of other ways as well.

VMs don't work for your particular problem space?  Great!  Don't use them.  Don't be the asshat who thinks that his own problem space is the only problem space in the world that matters, though.  The fact remains that there are lots of applications where VMs *do* prove to be a useful solution technique.

>>27
Uh, dude, how does that refute anything that was said?

Nobody said that you should stop using a VM, they just pointed out that using a VM doesn't automatically give you super magical powerzzz. The only thing a VM does that interpreters and compilers can't do is run binary objects portably.

Everything can be done just fine with normal compilers/interpreters/whatever the fuck you use. It's got nothing to do with a VM. That's one retarded element of C#'s design: it's not really portable, but it expects you do run a VM anyway.

Of course, an OS is a VM too. All those system libraries? All that virtual memory and process switching? File systems? Drivers? The thing that makes your sound card go boing? What the hell do you think that is? Jizz on your CPU?

Bah, I was just thinking today how OSes are all VMs to some degree, then two people (possibly the same person posting twice) get there before I can post about it and look smart.

C# is a very good language but if you believe computer sciences is about using DirectX, you've already lost...

In about a month I'm starting a new job in a VB6 shop. C# would be nice...

(course Lisp, Ruby or half a dozen other languages would be even nicer)

For very little time, you can get that done in PHP.
For a bit more time, you can get that done in PHP the right way.
If you don't mind the terrible syntax, you can get that done in Perl the right way too.

But VB man. The disadvantages of a scripting language without the advantages of a scripting language it is.

But VB man. The disadvantages of a scripting language without the advantages of a scripting language it is.

If you don't mind the terrible syntax, you can get that done in Perl the right way too.

I don't know what it is about Perl. I had this love/hate relationship going: it's an ugly language with more quaint nuances than English, but it could get a shitload done. CPAN for the win.

Lately I'm liking Perl more though. The more I use it, the more awesome it seems. Is this abused child syndrome?

>>34
Perl's main advantage and main disadvantage is its ability to represent complicated data structures and operations with extremely brief syntax. I've yet to see a real difference between Perl and Python other than the syntax, which causes me to stick with Perl, mostly because I hate typing a lot.

Python under the hood has all of perl's data structures. The main difference is namespaces.

>>35
Yes, but those short, cryptic pieces of code are to programmers doing maintenance what AOLspeak is to forum posters.

>>36 Ok, I'm going to confess my ignorance here (i'm a hobbyist) and ask what do you mean by 'namespace'? Do you mean the way that variables are handled or am I way way off?

>>37

AOLspeak is *waaaay* more legible.

# copy stdin to stdout, except for lines starting with #
    while left_angle_right_angle:
        if dollar_underscore[0] =eq= "#":
            continue_next;
        }
        print dollar_underscore;
    }
this is legible