Slashdot Mirror
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."
Whidbey is the code name for the next Visual Studio, not just C#.
There's an island just outside of Seattle that is called "Whidbey Island".
Maybe you want to take a look a mono.
Note to self: get smarter troll to guard door.
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.
Integrate Keynote and LaTeX
Perl 6 will have continuations...
h tm l
http://www.sidhe.org/~dan/blog/archives/000156.
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.
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.)
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
Sivaram Velauthapillai
Seeking the meaning of life... @slashdot of all places
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.
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.
"I think this line is mostly filler"
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* ;)
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. ;-)
Who is John Galt?
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.
n fo/road map.aspx
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/producti
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.
Natural != (nontoxic || beneficial)
I just want to know which ones do so I can be sure not to transfer there.
Stanford, for one. It's an optional course that doesn't count towards the major, but they do teach C#. I can see why you'd want to avoid one of the top two schools for Computer Science in the world, because they teach an optional class on a language that might get you a job. Wait, no I can't.
Anyway, YMMV, and I didn't get in to Stanford after all, so maybe I'm not the best source, but http://cs193n.stanford.edu/ sure looks like a C# class to me.
In response to the MS using this for its own products. I recently talked to a MS employee and apparently C# is being used to write all their products and actually the majority of the MS OS is being converted to C#.
[snicker] [snort] I'm sorry, but you were misinformed. As a kernel dev (I'm part of the Core Technology team in building 27 at Microsoft's Redmond campus), I can tell you with all finality that we're not moving the OS over to C#. Our work is strictly in C, occasional C++, and assembly.
That said, most of the higher level APIs for things like drawing, networking and so on will now have a managed wrapper, which means you can write C# that calls them.
Also, many of our network servers like IIS, SQL Server, BizTalk and so on will support a managed assembly (that's just a managed DLL) that allows managed code to configure those servers. This, to me, is the biggest deal.
Also, some non-OS products will be using some C#, though the Office team has stated emphatically that they won't be rewriting Office in C# anytime soon. There are pieces of the Office team that use C#, but that's a little bit different.
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.
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.
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.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I'm in web development ( full microsoft environment ) using C#, SqlServer2000, WinXP
Pros:
Cons:
VB.NET can compile console programs. VB5/6 could not, however it was possible to hack it to since VB5/6 were compiled using a syntax modified version of VC and the same linker as VC, so all you would have to do is override the /SUBSYSTEM switch to link.exe and you'd have a console application. I've done it several times.
.NET anyways except in interop scenarios. .NET so it's not a big deal.
.NET and COM classes. While I know and agree that this is a bad practice anyway, it can simplify COM programming significantly. .NET completely supports this but the C# team avoided it because if an application referenced a class that had a method with an optional parameter the default value would be compiled into the calling class. The default could be changed on a latter version but the client would still use the old default.
.NET framework is open to both languages equally. In Whidbey some of those differences will disappear and some new differences will surface. VB.NET will gain unsigned types, generics and also Edit & Continue (which is a mighty useful feature.)
In the case of VB.NET and C#, there are very few things that C# can do that VB.NET cannot. Some examples are:
1. Use of pointers/unmanaged code, which is useful in circumstances such as pixel-by-pixel image manipulation.
2. Unsigned types, which aren't really used much within
3. Using disposal semantics, which is syntactical candy and VB.NET can perform the same duties, it just requires more typing.
4. Lack of dependance on yet another library, Microsoft.VisualBasic.dll, although that lib is quite small and distributed with
On the other hand VB.NET can do the following that C# cannot:
1. Late bind to a class, by disabling strict typing VB.NET can create and use a class without knowing anything about that class, both
2. With semantics, which is syntactical candy but very convenient for people who are used to Pascal and Visual Basic.
3. Parametered properties. C# supports indexers, but only one of them. In VB.NET any property can require a parameter or any number of parameters.
4. Option parameters.
Really that's not a whole lot. The vast
Not to be confused with a VB.NET thumper. I switch back and forth between the two like a confused Canadian.
C# does not support checked exceptions (so now "throws" declaration). Anders Hejlsberg, one of the C# language designers, discussed why this is in a recent interview:
http://www.artima.com/intv/handcuffsP.html
Basically, the C# designers have serious concerns about checked exceptions: they don't scale and can cause versioning problems. Read the interview, it is interesting.
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).
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?
C# 2.0 Specification 1 C# 2.0 S 1 Anders Hejlsberg, Peter Golde, Shon Katzenberger .0 6 Generics, Anonymous Methods, Iterators, Partial Types e ene Normal.dot n Anders Hejlsberg us 130 Microsoft Word 10.0
no more comments!
-- kryps
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.
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.
Amazing magic tricks
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
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.