3 ms·

This article has a great title. Would have been nice if there was a bit more content to it; maybe we wouldn't have ended up with a bunch of hostile comments wi

by merlish 14y ago

This article has a great title. Would have been nice if there was a bit more content to it; maybe we wouldn't have ended up with a bunch of hostile comments with spelling mistakes. So let's give it a go. An opinionated past, present, and future for C#: The past: .NET emerged seemingly in 2002/2003 with a feature set similar to Java. This was pre-generics, and all code written in C# in this era is alien and involves a bit of casting. Microsoft released Visual Studio 2002, containing support for (at least) Visual C#, VB.net, Visual C++ .NET (of course. let's blend two completely different object systems. my actual favourite: Objective-C++ .NET), real C++, and Visual J#, the successor to Visual J++ (which Sun had sued the crap out of them for). Of course you're not jealous of the JVM, Microdollar! We believe you. C# did have structs at this point, distinct from classes, which are a pretty cool feature. They're more lightweight than classes, and I believe are passed by value rather than by reference like with classes. Also, unsigned integer types. As a man who had to make a small machine 'emulator' in Java as part of a not incredibly well thought-out practical, I appreciate not having to bend my mind around poking the sign bit to try and get the real number I'm actually after. And automatic unboxing and boxing of types was cool too. Int basically the same as int. So they did have a few original thoughts. Event handling also deserves a mention, so there we go. I personally was coding in VB6 at this time, and viewed VB.net with a mixture of bewilderment and contempt. So many keywords! Although the My.* namespace looked really cool. Actually being able to find out and change things about the current system, without being e.g. only allowed to change registry settings in a VisualBasic area of the registry. That was about the time that I was messing around with threads thanks to the AddressOf operator, so really, a move was probably on the cards. (You had to bind the Windows threading API yourself, and when you tried to pause in the IDE it would only pause one thread, get confused, and crash.) I eventually moved to VB.net (in the 2.0 era) and turned to treating C# with a mixture of bewilderment and disgust. (Clearly, I'm a quick learner.)

merlish 14y ago
The 2.0 era Java and .NET got generics around about the same time, a few years later. Java (sanely, to be honest) implemented generics via type erasure - so the compiler does the type checking, and then emits code that has no type information for generic containers - whereas the .NET team elected to break backwards compatibility* and make the runtime understand generics. I think Mono appeared around this time. This is the time when .NET started to get going, to be honest. Never settle for writing < 2.0 targetted code! Not that you can, unless you're running Visual Studio pre-2005. XNA ran 2.0, although Microsoft's bored of trying to get people who aren't amateurs to use that now. Running my own code on the Xbox 360 was pretty cool though. But they seriously needed to put a better garbage collector on that thing. It was, er, rubbish. * An annoying but possibly necessary decision. To this day, .NET 1.0/1.1 and 2.0+ apps require two separate runtimes to be installed, on Windows. Although Mono just deals with it, I think. Still, coming across the odd remaining 1.1 program can be a nasty surprise.
- merlish 14y ago
  The present (kinda): 3.0/3.5 Man, why would anyone want any of this LINQ or closure stuff? I don't get it. We already have event handlers, and for blocks can do anything LINQ can do (that I'd use it for)! It was about this time that I got into Haskell, somewhat out of necessity as that's what our uni course starts teaching. I've only grown more fond of Haskell since those days, mostly after learning a little OCaml/F# and seeing how comparatively nasty ML syntax is. Yeuch. VB.net kinda lagged implementation-wise for these features vs. C# - I guess I wasn't the only person who moved from the former to the latter - but in C# they were fairly glorious. No more would we be teased about the relative verbosity of our language! Fine, we still might go a bit long horizontally, but now we too can fit an amount of functionality on one line sufficient to guarantee the confusion of the reader and thus job security. Not that I have a job. Does job security keep you out of a job if you don't have one? Hm. LINQ uses method extensions (a hilarious but occasionally useful bit of the language) to add new functions to all the collections types whenever LINQ is imported. Mapping and 'aggregating' (folding) and what have you arrived in C# 3.0, with surprisingly nippy implementations, and a whole lot more came with 3.5/4.0 (I forget). Cool stuff. Cooler with closures. With events we didn't have to worry about writing inner Listener classes willy-nilly (insert comedy projectile vomiting here), but you still had to define the type of the function you were writing explicitly. Not so with closures. They're cool. I sometimes use them like private inner functions, but I'm pretty sure that's my fault. Something else most definitely worth mentioning that came around here that is undoubtedly a good and cool thing was type inference, or the super magic 'var' keyword. (Like the C++ auto keyword, THAT CAME AFTERWARDS (possibly). We're inventing! Yay!) Out with the List<string> stringList = new List<string>()! In with the var sl = new List<string>()! Glorious. While I'm going long here, I need to also mention automatic property implementations. So we don't have getWhatever and setWhatever functions in C# - (though we do agree with our Java brethren that generally exposed fields Are A Bad Thing) - we have: public whatever { get { return _whatever; } private set { _whatever = value; } }. But in 3.0, you can do e.g. public whatever { get; private set; } and the boilerplate is written for you. If you ever want to swap them out with some code that actually does something at a point after that, you can then go ahead and do that. Awesome stuff. Java coders love this when they learn about it. I think Mono also came of age here and stopped sucking. A new generational garbage collector (sgen), far greater API support, and the demands of game developers embedding the runtime left, right and center undoubtedly helped. (Mono runs on Windows and consoles, too, you know!) Their System.Drawing implementation is still a bit crappy, though. I've had to do some weird things to alpha channels and what have you.
thebluesky 14y ago
> which Sun had sewed the crap out of them for Speaking of spelling mistakes...
- merlish 14y ago
  Oops. I wonder if that makes me guilty of libel or slander.

by merlish 14y ago

merlish 14y ago

The 2.0 era Java and .NET got generics around about the same time, a few years later. Java (sanely, to be honest) implemented generics via type erasure - so the compiler does the type checking, and then emits code that has no type information for generic containers - whereas the .NET team elected to break backwards compatibility* and make the runtime understand generics. I think Mono appeared around this time. This is the time when .NET started to get going, to be honest. Never settle for writing < 2.0 targetted code! Not that you can, unless you're running Visual Studio pre-2005. XNA ran 2.0, although Microsoft's bored of trying to get people who aren't amateurs to use that now. Running my own code on the Xbox 360 was pretty cool though. But they seriously needed to put a better garbage collector on that thing. It was, er, rubbish. * An annoying but possibly necessary decision. To this day, .NET 1.0/1.1 and 2.0+ apps require two separate runtimes to be installed, on Windows. Although Mono just deals with it, I think. Still, coming across the odd remaining 1.1 program can be a nasty surprise.

merlish 14y ago
The present (kinda): 3.0/3.5 Man, why would anyone want any of this LINQ or closure stuff? I don't get it. We already have event handlers, and for blocks can do anything LINQ can do (that I'd use it for)! It was about this time that I got into Haskell, somewhat out of necessity as that's what our uni course starts teaching. I've only grown more fond of Haskell since those days, mostly after learning a little OCaml/F# and seeing how comparatively nasty ML syntax is. Yeuch. VB.net kinda lagged implementation-wise for these features vs. C# - I guess I wasn't the only person who moved from the former to the latter - but in C# they were fairly glorious. No more would we be teased about the relative verbosity of our language! Fine, we still might go a bit long horizontally, but now we too can fit an amount of functionality on one line sufficient to guarantee the confusion of the reader and thus job security. Not that I have a job. Does job security keep you out of a job if you don't have one? Hm. LINQ uses method extensions (a hilarious but occasionally useful bit of the language) to add new functions to all the collections types whenever LINQ is imported. Mapping and 'aggregating' (folding) and what have you arrived in C# 3.0, with surprisingly nippy implementations, and a whole lot more came with 3.5/4.0 (I forget). Cool stuff. Cooler with closures. With events we didn't have to worry about writing inner Listener classes willy-nilly (insert comedy projectile vomiting here), but you still had to define the type of the function you were writing explicitly. Not so with closures. They're cool. I sometimes use them like private inner functions, but I'm pretty sure that's my fault. Something else most definitely worth mentioning that came around here that is undoubtedly a good and cool thing was type inference, or the super magic 'var' keyword. (Like the C++ auto keyword, THAT CAME AFTERWARDS (possibly). We're inventing! Yay!) Out with the List<string> stringList = new List<string>()! In with the var sl = new List<string>()! Glorious. While I'm going long here, I need to also mention automatic property implementations. So we don't have getWhatever and setWhatever functions in C# - (though we do agree with our Java brethren that generally exposed fields Are A Bad Thing) - we have: public whatever { get { return _whatever; } private set { _whatever = value; } }. But in 3.0, you can do e.g. public whatever { get; private set; } and the boilerplate is written for you. If you ever want to swap them out with some code that actually does something at a point after that, you can then go ahead and do that. Awesome stuff. Java coders love this when they learn about it. I think Mono also came of age here and stopped sucking. A new generational garbage collector (sgen), far greater API support, and the demands of game developers embedding the runtime left, right and center undoubtedly helped. (Mono runs on Windows and consoles, too, you know!) Their System.Drawing implementation is still a bit crappy, though. I've had to do some weird things to alpha channels and what have you.

thebluesky 14y ago

> which Sun had sewed the crap out of them for Speaking of spelling mistakes...

merlish 14y ago
Oops. I wonder if that makes me guilty of libel or slander.