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

gc#?

[Anonymous Coward]

Ok, I know I'm a bad coder for liking C sharp, but gcc should really support it - like it or not, college computer science people *are* learning it, and Free software should support it. In fact, supporting visual basic compilation wouldn't be a bad idea either...

Re:gc#?

[Anonymous Coward]

put your money where your mouth is; so to speak :)

gcc is Free software; so download the source and add c# or visual basic support. Once you get the ball rolling others will join in and help.

Re:gc#?

[edalytical]

college computer science people *are* learning it

What colleges are teaching C#? At my school we had one Pascal course then went into C followed by C++. I believe we could have taken Assembly right after Pascal, but I'll take that after I finish C++. I've heard of other schools starting with java or even python. I'm not arguing that schools don't teach C#, I just want to know which ones do so I can be sure not to transfer there.

moving towards bloatware or are these important?

[Anonymous Coward]

You've truely engineered something great not when you can't add anything more to it, but only when you can no longer remove anything from it.

Its great that they are adding new features. But are they removing anything that was decided to be a bad idea? Now is the time to do it, in the early versions shortly after its birth, before there is too much legacy code...

Will MS begin to use this for its own products like Office in the near future?

Code Name

[boatboy]

Actually, Whidbey is the code name for the next release of Visual Studio and .NET Framework. C# is just a part of it. http://msdn.microsoft.com/vstudio/productinfo/road map.aspx#whidbey

Re:Who gives a shit about C#

[Anonymous Coward]

C# is ECMA standardized. Java is wholly owned by Sun. Sun has repeatedly balked at standardizing Java due to the inherent loss of control.

Perhaps there are potential submarine patents, but Java is absolutely vendor-tied while C# is at least relatively open.

Re:Does adding every ingredient make it better?

[Tom7]

No, but consider the competition. C++ is insanely complicated and broken, and is popular. Perl is insanely broken and complicated, and it is popular.

Anyway, anonymous higher order functions and generics are two really glaring deficiencies in Java, C#, and many other modern OO languages, so adding them is a step in the right direction. It's not as if these are minor, useless features.

> Is this their plan to "lock in" universities to teaching microsoft programing to all levels, because it will take
> 4 years of classes just to cover it all?

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

Re:Does adding every ingredient make it better?

[Qzukk]

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

Thats a great idea. Sounds great on paper, sounds great in theory. Sounds great while you're playing around with a bubble sort.

After that, its a load of crap.

Tell you what: You learn your bubble sort however you want. Your assignment is to write a program that uses a row colored spheres with numbers texture mapped to the surface of the sphere to demonstrate how the bubble sort actually operates.

I learned to do this at my university, and was lucky enough to get a professor that hadn't bought into the Windows Thing, and tought graphics programming with OpenGL (available everywhere) instead of DirectX (available in windows, and if you're lucky, wine).

In fact, when you get out of your pretty little university, you can try and get a job on "I know my programming theory". If you don't know the language and APIs that Company X is using, you're sunk. These days they don't settle for learning on the job. I had a wonderful job interview for developing an interesting application, I wowed them all with my knowledge, except for one little thing: I didn't know Perl/GTK which was what they were writing their application in. A few weeks later I got a check in the mail for my flight, car rental, and hotel and a thank you letter for taking the time to interview them in person.

innovation

[pizza_milkshake]

wow, that will they think of next?

Re:Does adding every ingredient make it better?

[yoshi_mon]

C is a low level language and makes no bones about it being such.

Is such a high level language such as one that is designed to run upon other protocals the same?

No.

Re:Does adding every ingredient make it better?

[deranged unix nut]

Personally, a "broken" language is a language that requires so much work to do things right that programmers that use them frequently do things wrong. For example, my all time favorite security flaw: the buffer overflow.

A good language should support the development of code that doesn't contain common flaws. In my opinion, C and C++ are directly responsible for security flaws that cost trillions.

Re:Does adding every ingredient make it better?

[Randolpho]

Universities are right to teach important concepts (and not just algorithms like bubble-sort -- that's friggin freshmen stuff anyway) like software engineering, project managment, relational algebra (i.e. database stuff), networking, AI, parsing, logic, circuit design, and (I'm lumping here) under-the-hood operating system concepts.

If you've got a Computer Science degree, and you payed attention, you can pick up the syntax for a new language within an hour. With a good API reference, you can be banging out code like an old pro with a weekend of study. It's not that hard.

What matters far more than how well you know a language is how well you know how to program. Any monkey with a keyboard can whip out a Visual Basic app.

But to write truly masterful code... that transcends skill with a language and approaches art.

That said, I'm going to contradict myself: it's important to know the basic capabilities of the language you're working with. Java would be a shitty language to write, say, a program that computes the sum of the two numbers input to it on the command line, because it takes so long for the VM to load -- far more than the actual execution time of the program.

Fortunately, things like that can be quickly learned.

the kitchen sink too?

[ashultz]

The next version will of course have features from Esperanto, Mandarin, and Martian.

I'm all for extending a language, but they haven't had C# around enough to be larding new stuff on. The language already had several ways to do most things, now they're adding more?

If we wanted ten ways to do anything, we'd use perl. If we're not using perl, that usually means we like to be a little more constrained.

-andy

Ask a stupid programmer....

[emarkp]

I actually happen to dislike C++, but on top of that, it doesn't suit my project, because the low-levelness makes it harder to program without errors (e.g. null pointers, memory leaking)

It's not surprising that a poor programmer likes C#--it's designed for people who can't design and code well. It's a continuing trend of giving more band-aid's to a language to compensate for lazy and/or incompetent programmers.

Here's a clue: null pointers and memory leaks are not "low level" problems--they're logic errors. Dereferencing a null pointer can happen in Java, and accessing a disposed object can happen in C#. Memory leaks and null pointers usually mean you aren't managing an object's lifetime correctly, and are typically symptoms of design errors (or minor bugs--off by one, etc.--which can happen in any language).

C# is like most MS tools--great for 80% of the work, but the last 20% is difficult or nearly impossible because MS didn't think of the problem you were trying to solve, and the language isn't flexible enough to adapt.

Finally, it is impossible to report errors in the implementation. When I found a serious error in the .Net runtime, I tried several ways to report it, getting no answer, or in the case of the microsoft.* newsgroups, assertions that I couldn't find bugs since the high-and-mighty MS and testers hadn't find it.

Sigh. Compare that to the people who hang out in comp.lang.c++.* -- I ran screaming away from C# as quickly as possible.

Re:Ask a stupid programmer....

[emarkp]

Goto the source, MS. Plonk your 200 bucks down and report it. If it is a REAL problem you will get your 200 bucks back if its YOU they keep it. ...

They do not respond well to 'its broke fix it'.

Gee, and I thought my MSDN Enterprise subscription would be sufficient. Why should I plonk down $200 to report a bug? I didn't want an immediate fix, we already had a workaround. I just wanted to report a bug. I had sample data and exact steps to reproduce it.

Instead I simply stopped using C# and went on to better things. I'd rather have a language and implementation that works, and has a useful community than one that MS is pushing as 'the next big thing'.

Re:Ask a stupid programmer....

[emarkp]

It's amazing what gets marked as "Insightful" around here.

Ah, when asked to defend the indefensible (C's insane design) instead declare yourself an expert and attack the person raising the issue as " lazy and/or incompetent".

Um, no. I was responding to the so-called "low-level problems" of C++ (not C). Null pointers are useful in a function to represent an object, or the fact that an object is not available. Dereferencing a null pointer is a logic error, because it means the object isn't available. Dereferencing it means your logic doesn't know the difference between a valid object and a non-existant object. Failing to understand the difference is a mark of incompetence or laziness. Hence my comment. Most memory leaks can be eliminated with auto_ptr (now in the standard for 6+ years) or boost's smart pointers. Simply slapping garbage collection onto a language doesn't solve this. In the case of C#, you lose deterministic destruction, which means that you can't properly clean up objects that are owned by the object being destroyed. C# forces you to kludge around this by checking to see if the object is being disposed of manually, or by the system, e.g.:

protected virtual void Dispose(bool disposing) {
if (!_disposed) {
if (disposing) DisposeManaged();
DisposeUnmanaged();
}
_disposed = true;
}

Of course, this fails in a multithreaded program. So you have to lock the internal variable if you want thread safety.

The problems cited are language problems. Yes, you can do workarounds and never create a bug but a competent language should make it easier to write bug-free code not add land mines to swagger over.

Sorry, they are not language problems. Real language problems in C and C++ are e.g. integer promotion rules and syntax ambiguities which sometimes parse a function call (typically a constructor) as a function declaration. If you still think these are language problems, be honest and point out that C# has them too. For instance:

SomeObject oops;
using (SomeObject so = new SomeObject())
{
oops = so;
}

oops.DoSomething(); //BOOM!!!

And the garbage collection doesn't help with database connections, graphics widgets, etc. You must manually dispose them if you want them to work reasonably. How, precisely is this any better than manual destruction?

Re:Who gives a shit about the ECMA?

[Arker]

Have things changed so much that we can trust Microsoft and its "standards body" largely consisting of companies dependent on Microsoft to keep all extensions to this "standard" in the open and available to all players?

Of course not.

But those who don't remember history are doomed to repeat it.

Re:ugh

[Slime-dogg]

Wrong.

Pascal is not meant for serious programming like C is, but Pascal has sorta grown into this business application language, and is far from obsolete.

You also cannot do anything in C++ that you can in C. You can do this in C, but not C++:

void f(); /* argument types not mentioned */

void g()
{
f(2); /* poor style C. Not C++ */
}

Or...

void* malloc(size_t);

void f(int n)
{
int* p = malloc(n*sizeof(char)); /* not C++. In C++, allocate using `new' */
char c;
void* pv = &c;
int* pi = pv; /* implicit conversion of void* to int*. Not in C++ */
}

These examples were shamelessly ripped from Bjarne's FAQ, which is available Here.

Re:Why should I care?

[AuMatar]

I'd like to comment on some of your pros here.

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

I'm the last man in the world to support Java, but C# is optimized to windows, and probably matches the OS's file system better. I'm not sure if C# would do as well in an non-MS environment

# Improved XML support - also a lot simpler in c#

This is a pet peeve of mine. LANGUAGES SHOULD NOT BE DEBATED BY THEIR STANDARD LIBRARIES. Don't like a library? Download another. Buy one. I'm sure theres 50 gadzillion XML libraries floating around. Chances are you'll like one better than the default. If you want to debate languages, debate the features of the language- what does one language enable you to do natively that another doesn't, or what does one make easier?

This is why languages should NOT have huge libraries. The designers of a language do not get everything right, especially the first time through. Invariably, third party designers who can focus in on one area can make a better API. In languages where they have huge standard libraries, like Java and C#, people tend not to bother because there's one already there. Unfortunately, that makes people end up using terrible APIs (the original Java gui, anyone?), and leads to a lot of bad comparisons between languages that have nothing to do with the languages.

# 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.

They'll come, C# hasn't been around as long. ALthough what the hell those things are I don't know (and beign a C programmer, never will need to. Nah!)

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

I've found a lot of inaccuracies in MSDN, although I admit the idea is nice. But comparing webpages about the two languages in a language comparison? Just plain inane. A nice help page or not has nothign to do with a language!

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

Again- the IDE is not a language feature. Its not really a good way to compare two languages.

Re:Who gives a shit about C#

[sadiklis]

C# is ECMA standardized. Java is wholly owned by Sun.

The biggest chunk of any language is it's vocabulary. In this case it's API.

There are OSS J2EE projects (Jboss, Jonas, Jakarta's new project).

And then there is this purely proprietary thing called MBF - Microsoft Business Framework.

BTW to emphasise that the beef is in API, not language, let me remind you that .NET Framework can be programmed in many languages (C#, VB.NET, Managed C++, etc.).

What other nearly-irrelevant subset of the beef is standartized by ECMA? Ones-and-zeores maybe? You know: "our systems are open, 'cause they are based on "ones-and-zeroes" standard" ;-)

Anyway, ECMA seems to be almost a joke in terms of freedom of their standards: http://techupdate.zdnet.com/techupdate/stories/mai n/0,14179,2832719,00.html:

But getting the stamp of approval from TC39 and the General Assembly doesn't mean that Microsoft is in any way ceding its ownership of C# and CLI. As part of the ECMA process, Microsoft, like any other company or organization seeking standardization of its technology, must make a declaration related to licensing the technology that complies with ECMA's Code of Conduct in Patent Matters. "The role of a standards body in this context is to warrant that licensing is possible on RAND (reasonable and non-discriminatory) conditions," explained van den Beld. So while Microsoft wouldn't be able to do whatever it wishes to C# itself, apparently the company would have plenty of latitude in terms of licensing.

And it appears that ISO (C#/CLI are ISO standards too) is no better: http://www.imaging-resource.com/NEWS/1027527673.ht ml (JPEG no more?):

'Register' article suggests the standards body may formally withdraw the JPEG standard altogether if Forgent continues with its patent claims...

ISO rules require that its standards be implementable free, or under "reasonable and non-discriminatory" (RAND) terms.

So what is a safer bet, OSS Java or .NET? Of course .NET, because it's closed and thus patent-torpedoes-invincible - can license patented technology, unlike all those open J2EE projects...

I'm sure it's better to suffer proprietary lock-in than potentially-deadly patent threat. Right?

Yet, even MS can be torpedoed successfully once in a while (e.g. that plugins patent hitting IE).

Software world seems to be a mess with no clear future perspective.

[Sorry for a somewhat-messy/offtopickish post.]

Re:Who gives a shit about C#

[gafter]

> C# is ECMA standardized. Java is wholly owned by Sun. Sun has repeatedly balked at standardizing Java due to the inherent loss of control.

I suggest you write the following lists side-by-side:

On the left, list the companies with members on the standards committe participating in defining the specification of upcoming versions of the Java language (JSRs 14, 175, 176 and 201). Count how many times each company appears on these lists, too.

On the right, list the companies with members on the standards committe participating in defining the specification of upcoming versions of the C# language.