C# 2.0 Spec Released

An anonymous reader writes "Microsoft released the design specifications document for C# 2.0 (codenamed 'Whidbey') to be released early next year. New features of the language include generics similar to those found in Eiffel and Ada, anonymous methods similar to lambda functions in Lisp, iterators, and partial types."

Comments

Code name

[flynt]

Whidbey is the code name for the next Visual Studio, not just C#.

Re:Code name

[gfody]

if(x = 1)...

still not even a compiler warning.. *sigh*

Re:Whidbey?

[ergo98]

There's an island just outside of Seattle that is called "Whidbey Island".

Re:gc#?

[termos]

Maybe you want to take a look a mono.

Ruby Continuations

[Llywelyn]

I'm still not sure why one would use continuations for well-designed code (kind of like labels in C++). I think the Ruby FAQ has the best statement on continuations.

-----
Ruby's continuations allow you to create an object representing a place in a Ruby program, and then return to that place at any time (even if it has apparently gone out of scope). Continuations can be used to implement complex control structures, but are typically more useful as ways of confusing people.

Re:Ruby Continuations

[Piquan]

Okay, no offense, but that's the worst description of continuations I've ever heard. It seems to be giving people ideas that it's like goto, which is a common reaction people have when they first hear about continuations. But it's not accurate. Goto manipulates the instruction pointer alone; continuations manipulate the entire stack in much more interesting ways.

There's some good stuff on continuations out there. They have little use in imperative programming styles like C++ encourages. In functional styles, they're used to implement exceptions, non-determinism, coroutines, generators, and a host of other control features that can open up whole new worlds of programming.

The crack about "ways of confusing people" doesn't mean that continuations tend make your code unreadable, like goto. It means that continuations are a confusing concept, but if you understand continuations, you can make much clearer code.

Perl 6 will have continuations

[Anonymous Coward]

Perl 6 will have continuations...

http://www.sidhe.org/~dan/blog/archives/000156.h tm l

Re:Does C# have continuations?

[Tom7]

You should get out more. There's a world of programming paradigms most people have never heard of, because they're still stuck using C-alike block structured OO languages.

Continutions are, roughly speaking, a generalization of setjmp and longjmp in C. However, to have true "first-class" continuations they need to be objects that you can pass around, store in data structures, etc. In C this isn't true, because if you return from the stack frame that did the setjmp, the continuation is invalidated. Lisp has "call/cc", some implementations of ML have "calcc" (typed), and many scripting languages have it, because it's pretty easy to implement in an interpreted language.

Continuations can be used to implement exceptions, user-level thread packages, "early exits" from recursive code, and other cool stuff.

Re:Does C# have continuations?

[Gorobei]

It's Scheme that has call/cc. Common Lisp didn't provide it (though it's not hard to write something similar if you really want it.)

Re:moving towards bloatware or are these important

[Sivaram_Velauthapill]

Removing something is very difficult. In fact, it is not recommended (unless it is a serious flaw or bug). There may be millions of developers using a particular feature or programming technique that is "bad". If you go and remove it, it could adversely affect all these programmers and their existing code. This is one reason why companies don't really remove features. Backward compatibility in software is absolutely crucial (especially when you force developers to upgrade to new versions all the time).

The best thing to do is to "phase" out the undesired feature by not recommending it, not featuring it prominently in books, shifting features into optional components that must be installed, etc.

I know this isn't exactly the ideal way to do things but I see no other way. I mean, if I was responsible for Visual Studio (or C# specifications), I would not remove features. Who knows who is using a particlar feature?

Sivaram Velauthapillai

Re:Why should I care?

[funked]

I've been using C# for about a year or so now. I started with Java, and made a clean switch to C# for a few projects that required it. I don't think that it will ever replace any of the three P languages, but is more targeted at taking Java down.

I'm not a full-time developer, I usually develop some basic web applications to enhance some of the new solutions I implement for Systems Administration. My experience with it is limited, but I'll give you my pro's and con's:

Pro's

Easier access to IO - just try it in Java and see. It's much faster in C#

Improved XML support - also a lot simpler in c#

Not as many third party specifications to learn. I remember having to learn Struts, Ant, Tomcat, and then Sophia after learning JSP - what a pain in the ass.

MSDN - The help system inside VS.NET is better than most languages' will ever be.

Con's

Not the best IDE in my opinon - IntelliJ smokes Visual Studio.NET in almost every respect(except for the help).

Can't use it on Linux or BSD - my applications are bound to fail more frequently than an equivalent Java/PHP/Perl app running on a secure box.

Most of the support I used to recieve about Java, Python, and other open source languages don't discuss c#. There just aren't the same amount of mailing lists, IRC channels, forums, to throw around C# ideas. The ones that do discuss it tend to cater to the Lowest Common Denominator.

I have to resort to Visual Studio 6 in order to create desktop applications that run on everyone's machine. The .NET framework has been a hard sell for the enterprise I work in.

Re:Who gives a shit about C#

[aled]

What exactly do you mean by undocumented? The language and virtual machine are fully documented, you can download the sources to jdk and libraries, and is much more open than C$, though less than others open source projects.

Re:Why C# doesn't Totally Suck

[krumms]

come on, where are the real differences

I thought the same thing. It's actually lots of little things that make C# nicer all 'round (in comparison to Java): Most pleasant for me is the fact that I can use enumerations without (a) declaring a new class/interface (b) placing a ridiculously long "public static final int" before EACH member of the enumeration and (c) being able to use the newly declared enumeration's new type name for parameters instead of just "int" - remember semantics?

Integrating legacy shit is also a snap with C#. Sure, managed C++ is better, but have you tried doing the same thing in Java? Yuck.

Lots of little things like this, IMHO, make C# better than Java.

I hate the fact that Microsoft charges an arm and a leg for Windows/MSVS/everything. But I like C#.

If only it was cross platform from the word go. Mono's nice, but the MSVS IDE is what keeps Microsoft/Windows up and above Linux as far as ease of development goes.

Python's better than everything else anyway. *hides* ;)

Re:Does adding every ingredient make it better?

[delirium28]

>That's crazy. Universities don't teach programming languages except as tools to teach more important concepts.

Not true. Check out University of Waterloo as an example of Microsofts approach to exposing C# to a new generation of developers. Well, engineer's, but close enough. ;-)

more info

[rabtech]

First off, Whidbey is the next version of Visual Studio, which is designed to use the dotnet framework v2. The SDK will be released publicly around the same time, so those who prefer Notepad need not pay one cent to write dotnet apps.

Secondly, generics, partial types, and such are being added to the CLR, as well as Microsoft's "first-class" languages, meaning that yes VB.NET will include them. VB.NET also gets operator overloading, native support for unsigned types, and in-line XML commenting.

You can read it all at the roadmap here:
http://msdn.microsoft.com/vstudio/productin fo/road map.aspx

It tells about some of the changes to the IDE, the CLR, and the languages. One interesting new "feature" is a sort of grammatical analyzer for writing code that will suggest improvements or corrections, similar to the way word underlines misspellings or grammar errors.

Whether it will be a great tool or a bloody nuisance remains to be seen.

Re:Why should I care?

[Baavgai]

C# is basically Java for Windows, take two. It does seem to have learned from the evolution of Java and cleaned some of the messier bits.

Exception handling is a little looser, without the need to declare thrown exceptions or catch those declarations. There is a still an exception based error handling system, it's just more implicit than explicit.

I really like the properties, an idea they took from Visual Basic. At some point in Java history (birth of EBJs?) it was concluded that public class variables were a bad idea. Java standardized on a getter / setter model that is more a convention rather than a language rule. C# uses a property, which has either a get, set, or both. If fills the same OOP niche, only more cleanly.

There is also some neat static ( class level ) functionality. Interestingly, while exceptions aren't explicit, inheritance is. A method must be declared virtual to be overridden, a more C++ thing to do.

Basically, there are many little changes from Java that make C# not Java. But, the changes do make sense and make C# an enjoyable language to program in.

It's already there in Java 1.5

[blamanj]

Enums have been added, generics have been added, automatic iteration in for loops have been added, et cetera. True, it hasn't been released yet (the first Java 1.5 betas are due next quarter), neither is Whidbey, and the JSRs have been out for some time, and the prototype compiler with generic support has been available for months.

Not quite the same thing.

[devphil]

The quote that the parent AC plagarized is from Antoine de Saint-Exupery, the French aircraft designer living in the first half of the 20th century. (And author of The Little Prince, if that hasn't been banned in America yet.) He was speaking in the context of original design, not individual features.

While the plane is still on paper, that's the time to remove all the unneccessary cruft. That's de Saint-Exupery's point. Not after the plane has been built; then the dependancy problems you mention arise. That's not the proper time. Certainly not in midflight.

Re:Why should I care?

[Bobbysmith007]

Background:
I'm in web development ( full microsoft environment ) using C#, SqlServer2000, WinXP

Pros:

1. Great documentation (ala MSDN) for extensive, helpful base classes
2. Very flexible and readable
3. XML comments integrate with the Visual Studio .Net IDE to create developer time tooltip documentation
4. Its very easy to create and manage many layers of abstraction such that any layer can be changed without needing to alter much code elseware.
5. Very easy IO using the System.IO name space base classes. Great objects that are arranged fairly standardly that just take the frustration out of alot of the repetitive work.
6. While I generally dont know the implementation of a base class object (see con 1), They do seem to be very well implemented in most cases
7. While not useful to everyone, It has very good SqlServer classes in the System.Data.SqlClient namespace. The syntax used is standard, well documented, easy to pickup, fairly powerful, and very flexible. I deal with a decent sized database and there tools for every purpose, it seems.
8. Because of the excellent auto-complete and tooltip comments, its a pretty quick language to pick up with just Visual Studio Help(MSDN) and the IDE.
9. The property is a great addition to the standard syntax of the language. It allows the getter, setter functions to be treated a public variable. I think this helps realize a truly object based system a little better.

Cons:

1. As far as Ive found there is little documentation on the inner workings of the base classes
2. Its from Microsoft who I generally consider money grubbing, domineering whores
3. All .Net apps need the .Net Runtime in order to be run. This creates compatability issues even amongst older versions of windows (as the vast user base doesn't see the need to patch (ie older members of family))
4. Its native source control (Visual Source Safe) is a pain in the ass to use, and I found it somewhat unreliable.
5. Im not a terribly big fan of VSNet's HTML designer. To be objective about it though I must admit that after changing its default view to HTML instead of design, Ive never flipped back so I have very little experience with it.

Re:Summary of changes: not much new

[TummyX]

You forgot iterators which let you define more declarative how an enumerator/iterator works.

IEnumerable<T> Test()
{
get
{
for (int i = 0; i < 10; i++)
{
yield i;
}
}
}

foreach (int i in Test())
{
Console.WriteLine(i);
}

1 is only in the spec stage here, whereas for Java there is already a technology preview, i.e. a more or less working implementation

There has been a working implementation of generics for over a year now (for rotor).

Re:Who gives a shit about the ECMA?

[azaris]

Who the hell is the ECMA?

"Ecma International is an industry association founded in 1961, dedicated to the standardization of information and communication systems."

Here is a list of their standards. It includes specs related to C, Ada, IDL, ECMAScript (JavaScript), C# and WSDL. Interestingly enough, Sun and Oracle are absent from their membership list.

Why not an IETF standard?

Hint: the "I" stands for Internet. What does C# have to do with the Internet?

Re:booooring

[kryps]

Java generics are broken because they don't guarantee type safety across compilation units. That requires VM changes, changes that Microsoft was willing to make but Sun wasn't.

You don't know what you are talking about. The JSR 14 generics proposal offers compile-time type-safety while retaining compatibility with old (i.e. not generified) libraries. That means as long as you do not use "raw" types (e.g. Vector instead of Vector<String>) type safety is guaranteed and the compiler will emit a warning (and probably even an error in future versions) if it encounters usage of a raw type.

-- kryps

Generic generics?

[dalleboy]

After reading this I'll understand that C# generics really suck, big time, compared to C++ templates.

The constraints are really a pain in the butt, as you must specify what interfaces that the 'generic' type must implement, and not what specific methods of the interfaces that the generic type must implement. What you say, you may think: But if I wanted any type that has a method named 'void Print()' to be executed by my generic class, all of those types must implement a named interface (IPrintable). That is perhaps OK if I have full control over the source code, but whatif I'm using a library written by someone else?

If you don't specify a constraint the 'generic' type will effectivly be of type Object, and we all know how much we can do with the type Object. Hmm, let me think, oh yeah: ToString. No need for generics there.

The examples in the spec are also mostly container class examples, wonder why? Perhaps that the generics of C# can't do anything but (or mostly) container (or container like) classes.

Re:C# generics on built-in types do not use boxing

[rnd()]

In case anyone reading the parent didn't get it, that means that the C# implementation of generics will have a strong efficiency advantage over Java's b/c boxing/unboxing is a costly operation.

Re:c# and Stdin/Stdout anyone?

[GroovBird]

You are misinformed.

The Console class has indeed two properties: In and Out that are respectively TextReader and TextWriter objects, but there are also the OpenStandardInput and OpenStandardOutput methods that will return you a nice Stream that you can then write directly to (using byte arrays, for example).

And this is all easily done using command line compilers included with the SDK, or in Mono.

See, that wasn't too hard?

Dave

Re:booooring

[bwt]

on some theoretical JIT, might actually run faster than a snail.

You do know that java is faster than C# for non-GUI apps, right? source. I suspect that if you dump swing and go with the eclipse SWT, you probably equalize the GUI speed issue too, which would mean that on windows platforms Java is faster than C#.

The "java is slow" reputation was earned with java 1.1 and was fixed long ago when the JIT VM's came out (they are part of all modern JVM's). Memory use issues might give you a real issue to knock java on, but you really shouldn't repeat untrue lore.