Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Microsoft Programming IT Technology

C# 2.0 Spec Released 634

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."
This discussion has been archived. No new comments can be posted.

C# 2.0 Spec Released

Comments Filter:
  • gc#? (Score:2, Insightful)

    by 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#? (Score:2, Insightful)

      by 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#? (Score:5, Informative)

      by termos ( 634980 ) on Saturday October 25, 2003 @08:49PM (#7311343) Homepage
      Maybe you want to take a look a mono [go-mono.com].
    • Re:gc#? (Score:4, Insightful)

      by edalytical ( 671270 ) on Saturday October 25, 2003 @09:25PM (#7311558)
      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.
      • What a shitty school. What the hell is the point of learning Pascal->C? Pascal and C are basically equivalent, except hat Pascal is much more Obsolete. And what's the point of learning C before C++? You can do anything in C++ that you could do in C, and you often have to do crappy things in C that would be much cleaner in C++.

        At our school C# is an elective.
        • Re:ugh (Score:4, Insightful)

          by Slime-dogg ( 120473 ) on Sunday October 26, 2003 @12:43AM (#7312320) Journal

          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. [att.com]

  • Code name (Score:5, Informative)

    by flynt ( 248848 ) on Saturday October 25, 2003 @08:41PM (#7311301)
    Whidbey is the code name for the next Visual Studio, not just C#.
    • Re:Code name (Score:3, Informative)

      by gfody ( 514448 )
      if(x = 1)...

      still not even a compiler warning.. *sigh*
  • by 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?
    • You can already develop in C# for Office with Visual Studio Tools for Office.

      Bill
    • 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
      • by devphil ( 51341 ) on Saturday October 25, 2003 @11:38PM (#7312041) Homepage


        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.

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

        Yup. Java does this. It is called "deprecated". For instance parts of the Date class have methods which are deprecated. The method's functionality has been moved to the Calendar class.

        It still works, but the compiler gives you a warning.
  • Seems like a pretty limited spec.

    All it says is:
    Plugger: No approperiate application for type application/msword found!

    whatever...

  • Code Name (Score:3, Insightful)

    by boatboy ( 549643 ) on Saturday October 25, 2003 @08:53PM (#7311366) Homepage
    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
  • by Pflipp ( 130638 ) on Saturday October 25, 2003 @09:09PM (#7311457)
    OK so I'm in the position of having to write an emergency support application for a M$-based system in a M$-based environment. Stuck in there. Completely. Been requested to make a maintainable, manageable solution. And yes, this is to say "make it for M$, with M$ tools as much as you can".

    I guess even within these circumstances, I'd have refused to open Visual Studio for this project, if it didn't say ".NET" as well. I mean, think of it: previous versions of VS only supported C++ or VB, with APIs to cry for (admittedly, I don't know about MFC, only about Win32).

    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). I'd rather have a language at a scripting level -- and NO, that's NOT VB. I hope I don't have to explain why I hate VB if only on very first sight.

    So with .NET, M$ introduced a quite nice API and Java language (come on, where are the real differences) into Visual Studio, which at least saved my day; I had found an acceptable programming environment for within Windows..!

    There's really no need for anybody to pick on C#, long as it's realized that it's just finally a nice programming environment for Windows, and nothing (well, not much) more. (BTW, it's not much different from NeXT (now Apple)'s use/ takeover of Objective C.)
    • by krumms ( 613921 ) on Saturday October 25, 2003 @09:58PM (#7311751) Journal

      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* ;)

      • by blamanj ( 253811 ) on Saturday October 25, 2003 @10:33PM (#7311925)
        Enums have been added, generics have been added, automatic iteration in for loops have been added, et cetera [sun.com]. 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 [sun.com] has been available for months.
        • 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.

          1. I wasn't talking about Whidbey, I was talking about the current release of C#.
          2. JSRs are talk. C# is a reality.
          3. C# has already been implemented - further, its implementation is already production quality (irrespective of what Microsoft's definition of "production quality" is - if you d
      • 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.

        For some people, perhaps. I find the MS development tools so nauseatingly bad that they are one of the main reasons that I don't do anything with Windows.

        Fortunately, on Linux you get a choice: excellent command line tools and IDEs. On Windows, unfortunately, you don't: Windows command line tools simply are completely useless.
    • 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 error

      • curious, of what serious error do you speak?
  • innovation (Score:3, Insightful)

    by pizza_milkshake ( 580452 ) on Saturday October 25, 2003 @09:23PM (#7311538)
    wow, that will they think of next?
  • more info (Score:4, Informative)

    by rabtech ( 223758 ) on Saturday October 25, 2003 @10:10PM (#7311808) Homepage
    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.
    • "Whether it will be a great tool or a bloody nuisance remains to be seen."

      If you cannot turn it off choice two is the obvious answer!

  • by ashultz ( 141393 ) on Saturday October 25, 2003 @10:12PM (#7311816)

    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
  • Java announced Generics months ago. In all, it seems like the java stuff is more exciting, although the lambda-like stuff in C# seems interesting.

    It's good to see commercial competition adding new features to commercial languages, although I hope they don't get so feature bloated they become like Perl.
    • Re:booooring (Score:4, Interesting)

      by penguin7of9 ( 697383 ) on Sunday October 26, 2003 @12:40AM (#7312310)
      Java announced Generics months ago. In all, it seems like the java stuff is more exciting, although the lambda-like stuff in C# seems interesting.

      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.

      Java is more and more turning into an accumulation of evil kludges. Instead of type-safe generics, we got a hack. Instead of lexical closures, we got nested classes. Instead of structs, we got some half-hearted promise of optimization under some nebulous set of circumstances that can't work in general. Instead of multidimensional arrays, we got some classes with a horrendous syntax that, on some theoretical JIT, might actually run faster than a snail.

      I don't know whether C# will grow up into a well-designed general purpose programming language, but it is crystal clear that Java has missed the boat.
      • Re:booooring (Score:4, Informative)

        by kryps ( 321347 ) on Sunday October 26, 2003 @10:37AM (#7313624)
        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
      • Re:booooring (Score:3, Informative)

        by bwt ( 68845 )
        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 [dada.perl.it]. 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
  • by truth_revealed ( 593493 ) on Sunday October 26, 2003 @12:17AM (#7312207)
    From the C# 2.0 spec:

    "When an instance of Stack<int> is created, the native storage of the items array is an int[] rather than object[], providing substantial storage efficiency compared to the non-generic Stack. Likewise, the Push and Pop methods of a Stack<int> operate on int values, making it a compile-time error to push values of other types onto the stack, and eliminating the need to explicitly cast values back to their original type when they're retrieved."

    Java uses Object boxing for built-in types in their generics implementation.
  • by Zo0ok ( 209803 ) on Sunday October 26, 2003 @04:19AM (#7312803) Homepage
    Ok, this is actually a .NET issue, not really a c# issue.

    StandardInput and StandardOutput, in .NET, are text based streams, made up of 16-bit chars. When writing a (16-bit) char to StandardOutput it is converted to something else (UTF-8, maybe).

    Piping binary data from one app to another is a very non-trivial task.

    These are the small "features" that make c# unsuitable for anyone "thinking UNIX". Of course piping through stdout/stdin is not needed: you can use remoting, sockets or whatever - but those make easy things hard.

    Anyone who has written a c# program that uses stdin/stdout for binary data?

    BTW, you definately does not need Visual Studio to program .NET, vim + .NET framework and the online MSDN reference is completely sufficient.

Whoever dies with the most toys wins.

Working...