Talk:C Sharp (programming language)/Archive 1

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Archive 1
| Archive 2 →

Contents

External Links and spam

The links added to this article (and indeed all development topics) must be encyclopedic in the sense that they provide valuable context to the article at hand. C# is no exception. Otherwise the External links section would end up being a repository for everyone's pet C# development website. So if you're wondering why your link was removed, that's why. This is no different from any other WP topic that deals with popular things that have relatively large web coverage like Pokemon or iPod accessories. -- klaus

I object to the use of the term "spam" for a site one does not think belongs on the external links list of a certain page. It is derogatory and inflammatory. I would like to understand the sysyem. What is the justification for having the C# compilers and Mono project links here?
---71.252.197.197
I'd object to the term "spam" as well, belive me. I understand there is no commercial gain here whatsoever. I don't think anyone is accusing you of that (well, I'm not). But that's what it's called for some reason, "link spam". I guess it's an unfortunate label. BTW, for the guide on external linking see Wikipedia:External links. In the case of your site for example, I simply don't see any uniqueness factor that would justify including the link. The C# and Mono compilers are here because they are "encyclopedic" in that they refer directly to the topic at hand. -- klaus
You might want to read Wikipedia's guidelines on external links in order to understand what should and should not be linked. Also this section on how not to be a spammer. If your only reason for participating in Wikipedia is to add external links, then you probably shouldn't bother, as Wikipedia is not a link farm. But if you'd like to contribute content, that would be welcome. --Craig Stuntz 16:08, 28 July 2006 (UTC)

Politics, patents, open-ness

Hi, regarding the following statements:

  • "However, that standard library provided with C#, including the extensive GUI library, is not an open or completely documented [library], ..."
    • C# and the .NET libaries upon which it is based are open. You're referring to the implementation as provided by one arbitrary company. You cannot judge that and say it's the same as C# itself. You might as well be saying that C# includes Gtk# if you say that it includes WinForms.
    • Whether third parties (i.e., not the standards bodies themselves) release closed-source libraries implemented in .NET is immaterial to the language's inherent openness. Although it may be worthwhile to mention in a neutral way, I believe this section violates NPOV in its judgment of C# (which is standardized by the ECMA and ISO), based on the actions of one company. For instance, if some rival company decided to come up with a Gtk# or WinForms competitor that was closed source and internally undocumented, it would still not be an argument against C#/.NET as an open development platform. C# is open; it is a matter of course that not all things written with it will be also.
  • "so an independant implementation which can run all programs written for Microsoft's C# would be difficult"
    • This is true; however, that is not a correct standard by which we should judge C#. Microsoft developed C#, this is true, but submitted the language and its core libraries for standardization by the independent bodies ECMA and ISO. As I mention above, it is not NPOV to judge the language and its standardized libaries on the basis that one company has released undocumented, closed-source libraries.
    • For example, Microsoft has also released a plethora of libraries written in C++, such as MFC. It is likewise not an argument against C++ (nor is it even worth mentioning) that some company (Microsoft) has written a closed library (MFC) available in C++.
  • "and of questionable legal basis (see discussion about Mono)."
    • This is not true. The legal basis is firmly established. The ISO standards body requires that all standards ratified are free of restricting patents; that is, any standard approved by the ISO may be implemented without fear of patent protections. This is true of the C# language and .NET platform. The Mono website itself (an independent, open-source .NET and C# implementation) states:
      • "The core of the .NET Framework, and what has been patented by Microsoft falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA, (he is one of the inventors listed in the patent) ... Basically a grant is given to anyone who want to implement those components for free and for any purpose."
    • Even if this were not true, the terms of ISO require free implementation, as I mentioned earlier.
    • It may be the case that WinForms is covered by some patents. However, as discussed above this is not relevant to the discussion of C# itself. If any company released any library covered by patents targeted at .NET, is this worth mentioning in a discussion on C#? I say no, it is not.
    • It is very important to be clear that C# and .NET are standards defined by ISO and ECMA, and no one else. What other companies do, in terms of the proprietary libraries they release or the patents they own on their own libaries, cannot be used fairly as a criticism of C#.
    • If you look at most of the recent standards published by the ECMA and ISO, you will see that the majority of them have been developed by single companies or coalitions of companies. For example, the famous language JavaScript (more correctly named ECMAScript) was developed by Netscape Communications. It became standardized and now is under development by many companies. There is even a JavaScript implementation for .NET. Once a technology becomes standardized, it is irrelevant who originated it. Does it matter that the unit of energy, the Joule was named after and developed by James Prescott Joule? No. It's a standard now, and when you're talking about Joules, you're referring to the SI unit. Microsoft in this situation does not pretend that WinForms and similar libraries are part of the .NET framework standards. They are independent libraries published independently, and one cannot judge the C#, as standardized (which is what this article is about!) based upon them.
    • Please respond, as I believe article violates NPOV.
    • Xiphoris 22:42, 12 June 2006 (UTC)
I didn't write this so I won't defend it, but I'll point out that this seems to me to be yet another manifestation of the very common confusion between C# in particular and .NET in general. There are large parts of MS's .NET framework implementation which are not based on any standard, whereas C# is completely standardized as are the parts of the framework on which it relies. The article could probably do a better job of clarifying this general difference between C# and .NET, especially now that ".NET 3.0" will be shipping with C# 2.0 during C# 3.0's development, or so it appears. --Craig Stuntz 02:39, 13 June 2006 (UTC)
I would go further and say that C# per se has nothing to do with the .NET framework or the BCL. Quoting from the ECMA spec, "Although Microsoft’s implementation of C# relies on CLI for library and runtime support, other implementations of C# need not, provided they support an alternate way of getting at the minimum CLI features required by this C# standard."
Furthermore, C#'s actual requirements of a library are quite modest,and are detailed in the spec's "Annex D. Standard Library". This covers certain required exception classes, array members, interfaces for enumeration, and base data types such as int.
With that in mind, it's clear that much of this article's content is off-topic. I/O classes, garbage collection, and reflection, to name a few, are not a part of C#. Neither is MIDL, for that matter. We need to make this much clearer, probably by creating a different topic, named something like "C# Programming in the .NET framework". Leotohill 04:37, 13 June 2006 (UTC)
I think we have to discuss the standard library that Microsoft provide. That is what most people will think of when they think about C#, and what most books discuss. Mrjeff 21:25, 14 June 2006 (UTC)
On the contrary, I think we need to emphasize the difference. People are already badly confused about this, and it's only going to get worse when MS releases ".NET 3.0" containing and built with the C# 2.0 compiler, with C# 3.0 to follow later on. Furthermore, a discussion of the framework is no more or less relevant for any other .NET-compatible language. For example, one of the key features of .NET generic classes which separate them from C++ templates is that they are language-independent. Understanding the difference between C# and the .NET framework is in my opinion a critical point of understanding. We can and should discuss the libraries in other articles, however, and we can link to them here. --Craig Stuntz 16:47, 15 June 2006 (UTC)
Craig has hit the nail on the head. It makes no sense to discuss garbage collection, reflection, I/O, and such as if they were attributes of C#, when in fact the exact same things could be said of any .NET programming language that uses the .NET framework. Proper links between the topics is the way to go. Leotohill 17:51, 15 June 2006 (UTC)
I agree. BTW, This is fun, you guys. I'm enjoying collaborating with all of you to improve this article. There are some links between the CLI/CLR and the C# language; I will do some research and see if I can establish what the relationships are between them :) Xiphoris 08:51, 20 June 2006 (UTC)

I am troubled, under this same heading, by a remark made in the opening paragraph describing C#:

  • "C# has a procedural, object-oriented syntax based on C++..."
When one reviews the Java programming language topic, one doesn't see the reference to Java being a "procedural" language at all - and rightly so, in my view. Knowing both, as I do, but perhaps lacking the academic background to judge this empirically as another academic reading this might, I have to ask why C#, as distinguished from Java, would be defined or characterized as 'procedural' whereas Java is not? If there's no sound rationale for describing C# as such, I reccomend deletion of the terms 'procedural' and 'procedure-based' in referring to C# throughout the article. ross613 19:24, 25 January 2007 (UTC)

Regarding references to VB.NET

Gaijin42 added the following to the section on managed memory:

"C# and VB.net provide explicit control of unmanaged resources, such as database connections, ... (IDisposable stuff)"

I don't feel that mentioning VB.NET here serves a purpose. C# provides such things only because it's a .NET language, and all .NET languages support the same IDisposable interface. There's no more reason to mention VB.NET than there is, say, IronPython or JavaScript.NET (yes, there is JavaScript.NET). I think the most correct thing might be to say that .NET provides that feature, but since this is an article on C# it's reasonable to say that C# provides that feature; it's OK to leave it unstated that it's actually provided through .NET, which C# sits on top of. In any case, there's no specific reason to mention VB.NET here, as this is an article on C#. I recommend we remove this reference. It might be more relevant to include it in the article comparing C# and VB, or perhaps in a section of this article comparing it to other languages, but not here.

Gaijin42, I support the notion of an article comparing VB to C#; however, do you think we could expand it to include all major .NET languages (not toy ones)? Also, was there a reason to mention VB.NET here that I didn't notice?

Xiphoris 03:32, 9 June 2006 (UTC)

Received no response. Removing unnecessary references to VB.
Xiphoris 22:51, 12 June 2006 (UTC)
Hmmm, I'm still not happy with the page. The article mentions C++ a number of times as a basis of comparison for language features. Does anyone have an idea how to clearly describe such features without unnecessarily referring to other languages, such as C++?
Xiphoris 22:54, 12 June 2006 (UTC)

This article needs to be cleaned up

When I have time over the next couple of days, I'm going to try to clean this article up. The article contains both poorly worded sentences and phrases as well as plainly counterfactual statements. Here's an example:

In languages that do not provide garbage collection, the programmer must explicitly free all allocated memory. Failure to do so is a common program bug, resulting in a memory leak, where the program continues to allocate more and more memory to itself.

That's not what a memory leak is.

I am not the best writer in the world, so any help improving the phrasing of my additions is appreciated. However, I would request that people make suggestions about rephrasing here and allow me to rephrase my own sentences instead of making the changes yourself. Thanks! —Xiphoris 05:23, 5 June 2006 (UTC)

Xiphoris, please provide here an alternate definition of a memory leak that you find acceptable.
The part that I had issue with was this, mostly because of the low quality and lack of clarity:
"Failure to do so is a common program bug, resulting in a memory leak, where the program continues to allocate more and more memory to itself."
The language "continues to allocate more and more memory to itself" isn't technical language. Plus, it has nothing to do with a memory leak. Whether the program continues to allocate memory is immaterial -- all it needs to do is allocate one object and lose track of it for a leak to occur.
Also, specifically, a memory leak is not when a program does not free memory, it's when it cannot. The issue of whether some allocated object is a memory leak is an issue, to use technical language, of reachability. Specifically speaking, all reachable objects are not leaked; all leaked objects are unreachable. A program only leaks memory if it loses track of something it has allocated. For example,
int* i = new int();
i = 0; // lost the integer allocated with new
If the program still has access to the object and has the ability to deallocate it, it is not a memory leak. Indeed, if the program still has access to the object, it can still potentially use that object. The only way to say for sure that some object has been leaked is when you know that the program no longer has the ability to deallocate it.
You have a very orthodox definition of memory leak. Nothing wrong with that - I'm just accustomed to a more liberal one. My definition encompasses programs that could release the memory, but do not. For example, consider a program that keeps some session state based on a an http seesion id. It has a data structure (e.g., Hashtable) that is indexed by sessionId. This poorly written program does not remove the entry from the table when a session ends. No functional harm is done, but the memory associated with that session state is retained. So, if 1,000 users login and logout, the program has retained the session state of all 1,000, even though none are logged in any more. I'd call that a memory leak. Note that my definition allows for the existence of memory leaks in GC environments, while yours does not. GC eliminates one cause of leaks, but not all. I think my description is consistent with Memory leak.
I agree that my one-sentence description in the article is neither technical nor complete. It is non-technical on purpose: as far as possible within context, I try to make an article understandable by the non-specialist reader. (In this case, though, I'm tilting at windmills, because I've inserted my non-technical description inside a big pile of jargon written by others.) But even if not complete, I think the statement works well. In particular, in this article I would not bother to cover the case of the memory leak that is unnoticed. But when choosing between a simple example of a leak that does not cover all cases, and the complete description that does, I'd favor the former, and refer to Memory leak for the full definition.
My definition encompasses programs that could release the memory, but do not.
That's what GC is, isn't it? Apart from the notion of automatically tracking memory, GC systems don't instantly free it (like refcounting systtems would). They can release the memory but do not. I don't think that's a good definition of memory leaks, therefore.
Note that my definition allows for the existence of memory leaks in GC environments, while yours does not. GC eliminates one cause of leaks, but not all.
But the causes of memory leaks in GC environments almost never have to do with allocation of memory. Instead, they're "conceptual" leaks (that really have nothing to do with memory allocation) like failing to close a file or socket. (The resources are not actually 'leaked' per se; they're just closed a long time after the object is last used). Whether you consider such things memory leaks is a matter of definition; maybe I'll be picky and call them 'resource leaks' :)
But even if not complete, I think the statement works well. In particular, in this article I would not bother to cover the case of the memory leak that is unnoticed. But when choosing between a simple example of a leak that does not cover all cases, and the complete description that does, I'd favor the former, and refer to Memory leak for the full definition.
The problem I had with the existing definition was the part about "continuing to allocate memory into itself". I think the definition would be fine if we simply mentioned that programs allocate memory but don't free it, and how/why GC prevents this.
Xiphoris 02:05, 13 June 2006 (UTC)
That's what GC is, isn't it?
No - the difference is that GC eventually releases memory when it is appropriate to do so , and a memory leak is when a program doesn't release memory when it would be appropriate to do so. So I'd say that a memory leak is when a program should release memory, but doesn't. Sometimes it doesn't because it can't (as in your example) and sometimes it doesn't because it's stupid (as in mine).
That said, the current wording with the "more and more" removed is fine. Nice to hash it out with you.
Leotohill 04:48, 13 June 2006 (UTC)


Although your definition of memory leak is arguably more correct, it is less useful. After all, if a program has a memory leak, but nobody notices, who cares? The only memory leaks of consequence are those that cause excessive memory use.


Xiphoris 20:57, 9 June 2006 (UTC)
Also, I don't agree with your change of "object" to "component". I've never heard of a "component-oriented language". What are the characteristics of such a language? Why is that a better description of C# than "object-oriented"? Leotohill 12:15, 5 June 2006 (UTC)
Sorry, now I see that you have introduced a talk section on component OP. I'll place some comments there.


Continuing the list on needed clean-ups, the following statement is unaccurate:

C# supports a strict boolean type, bool. Statements that take conditions, such as while and if, require an expression of a boolean type. While C and C++ also have a boolean type (...)

C does not have a native boolean type (although a type "bool" or "boolean" is defined by many libraries), and conditions for if/for/while statements must be of "arithmetic or pointer type", according to K&R second edition. I had edited this myself, rephrasing the statement, but edited back since I felt someone might do it better. 201.67.28.37 05:35, 10 October 2007 (UTC)

C has a native boolean type (_Bool) since C99. -- int19h 06:26, 10 October 2007 (UTC)

Component-oriented programming

It is more specific to say that C# is a component-oriented language because the principle division of elements of the system is the component, which is a portable, self-contained set of functionality. .NET implements this notion as an assembly. Depending on your perspective, component-oriented programming may be either a subset or superset of object-oriented programming. However, a number of C#'s features are specifically component-oriented (such as delegates) and I believe it is more accurate to describe the language this way. In case users are interested, I have specific industry experience related to this language. I have been a programmer of many languages for many years, and have extensive experience in many of them. Nevertheless, I have corporate affiliation of a sort that some users might use to argue that I am biased. I do see myself as biased on many issues, but programming languages is not one of them. I believe I can factually evaluate the pros and cons of this language, and others, despite my industry affiliation. I invite those who are interested to read more about me on my user page. —Xiphoris 04:59, 5 June 2006 (UTC)

I disagree with the change. I see component-orientation as a aspect of a design of the artifacts produced by programming. It might be easier to produce components with one language, over another, but a language itself is not component-oriented. A language does not contain functionality, while a component does. If the assembly indicates that C# is component-oriented, then so is any .NET language, because all produce assemblies. Are you saying that VB.NET, COBOL, Python, and all the other languages that are implemented in .NET are component-oriented? Leotohill 12:37, 5 June 2006 (UTC)
A language does not necessarily have to be component-oriented or not; component oriented-programming can easily be enabled by a library as much as a language. For instance, non-CLI C++ can do component-oriented programming through use of COM. C++ has no component-oriented development features because it is unaware of ABIs -- compiled code of various compilers is often not able to interact with compiled code of other compilers; as a result libraries must often settle for the 'common denominator' of a C-like calling convetion. For example, if I write and compile a class in Borland C++, put it in a DLL file, I will not be able to instantiate and call that class using Visual C++. The reason I cannot do this is because the C++ language has no component-oriented features. But it is also possible for a language to specifically be aware of and empower component-oriented development.
I will agree that component-oriented programming refers to the way that compiled units interact with each other, not the way that code within the language interacts. However, it is possible for language features to facilitate the way that compiled units interact. For instance, C# has access keywords like public, private, and internal which go far beyond the semantic in C++; in C++, the notion of private completely disappears when code is compiled, and I can (using a pointer) modify a private variable from outside in a class; in C# though, the semantics of private aspects of components are enforced using the security model and simply cannot be accessed without a security bypass. In this case, the component-oriented access keywords of the language exist to facilitate the interactions of the compiled units.
C#'s compilation target is .NET, and many of the features it offers are congruent with .NET features. As a result, one can say that that language features that C# offers serve to provide component services to compilation units. The C# language feature private corresponds to much more than just what happens in the language, and that private designation can be seen by VisualBasic, IronPython, or any other .NET language. It is a component-oriented programming feature for that reason, in my opinion.
If those other .NET languages offer component services, such as the distinction between various access modifiers, then one could say that they are component-oriented. One critical piece of component-oriented programming is that components are self-describing; i.e., I don't need some "header file" or whatnot to use them -- all the relevant information is in the component itself.
Another critical feature of component-oriented development is the focus on interface implementation instead of class inheritance. Object-oriented programming literature generally discusses how GermanShepherd derives from Dog derives from Animal, and all of them have variously more complex definitions of EatFood(). OOP generally does not present the term interface, which is a completely implementation-free contract. In component-oriented development, the essential form of contract is the interface, inheritance from which has very different semantics than class inheritance. COP and C# generally discourage class inheritance in favor of interface inheritance in all but a very few circumstances. Indeed, the .NET class library only does it rarely, but uses interface inheritance frequently.
Since you are new to the term, I thought I might provide some resources for you to read about component-oriented programming so that we may discuss this issue effectively.
  1. http://en.wikipedia.org/wiki/Software_componentry - Section titled "Differences from object-oriented programming"
  2. http://www.amazon.com/gp/product/0596102070/sr=8-1/qid=1149576405/ref=pd_bbs_1/102-5591093-9912923?%5Fencoding=UTF8 -- the book "Programming .NET Components" is one of the best books I've read on .NET, and it covers the essential points of what it means to make a component and how to do it well. If you're a .NET programmer I would highly recommend this book. It's possibly the best programming book I've ever read. (Every other book I've read spends tons of time telling me things I already know, like what a for loop means. This book dives right in act exactly the level of sophistication I want on the subjects that are in the book.)
  3. [Aspect-oriented programming is a very different but related concept, in that it may either be implemented in a language itself or with support libraries. There are libaries such as called Aspect# which allow aspect-oriented programming to be used in C# even though C# has no specific aspect-oriented features; but there are also programming languages that specifically include aspect-oriented features to make this process easier.
I see your points an am not 100% behind the edit I previously made. However, I do still believe it's right and see the point of this discussion about figuring out which way to introduce the language as being more beneficial. Perhaps I'll ask some people at work how they would prefer the language be described and report back. Anyway, let me know what you think!
Xiphoris 06:55, 6 June 2006 (UTC)


good points, but still not enough to convince me that the designation is appropriate. If anything, your arguments apply to the .NET platform more than to C# in particular. And then there's a language like Powerbuilder, which has private class members, and events, and self-describing modules. Have others publicly described C# as a COL? Is the designation in any way becoming popular? We don't want to be creating controversial new designations on WP. If it were very clearly a better designation I might go for it, but it's not so clear to me. Leotohill 01:03, 7 June 2006 (UTC)
OK, I've reverted component-oriented to object-oriented. I'll revisit this topic sometime in the future once there is better, or at least more public, evidence supporting the ocmponent-oriented designation. Thanks for the interesting discussion.
Xiphoris 03:21, 9 June 2006 (UTC)

Compiled (JITted) Code Cache and ngen.exe

From the article:

"The resulting binary code is stored temporarily (in a memory cache), so if the program uses that portion of code again, the cached version is used. However this is only in effect during the runtime of the program. If a .NET application is run again, this compilation process is done again."

I happen to know that certain libraries and executables are compiled to native code and stored in some sort of cache on the hard drive under some conditions. ngen.exe is part of the procedure that makes this possible. Someone (or myself) should do the research to make the necessary corrections to the article.

Samrolken 09:53, 18 Jan 2004 (UTC)

Actually, this is technically incorrect. I am pretty sure that the object code is usually written to disk, but I might be wrong. Certain run-time optimizations may prevent this, I am not sure.

In .Net object code is normaly never writen to disk, JIT compile it when needed and that's all (So the MSIL->x86 compilation appends for every launch) but that's true that you could ngen your assemblies and then the object code will be used)
The standard practice is what do microsoft : using ngen to generate native assemblies during the setup of the program
Virtualblackfox 28 June 2005 21:57 (UTC)

Complete Hash

Certain cynics have suggested that C# should be pronounced complete hash.

See-Pound is also sometimes used (by me, at least!). -mhr 07:09, 18 Nov 2003 (UTC)
Cynics of nearly everything have alternate pronunciations/spellings for products they wish to jeer. Point? Samrolken 09:53, 18 Jan 2004 (UTC)
To add a reference to the whole "C-Hash" thing, I give the infamous TheRegiter's take on it all: [1] they also have some opinions of readers on the issue: [2] and yes, it's all very cynical. But hey I've pronounced it 'C Hash' since before I knew how it was supposed to be pronounced, and I still do out of my cynicism. - SHayter 23:43, 20 August 2006 (UTC)

Is C# Just a Java Clone?

Many sources say that C# is more or less a copy of Java with some minor changes / enhancements. Could somebody elaborate on this please? 213.3.87.59 02:26 30 Dec 2002 (UTC)
C# has many of the same features as Java, but also has some noticeable differences. It is obvious that the C# designers used a lot of concepts from Java, but they took some from C++ as well.
The big differences are in the actual class heirarchies and actual executable representation. Java has a big set of base classes, as does C#. But Java's and C#'s class libraries bear little resemblance to one another.
A Java executable contains byte-code which must be executed via a Java Virtual Machine (JVM). Similarly, C# executables contain MSIL which must be JITted via the .NET framework (or the CLR). The JVM converts byte code into binary code as it is executed. The binary output of C# code is cached and used again if the program uses that part of the code again. So C# may be faster in execution since it caches the binary code and most JVM's do not.
Critics state that C# is MS's attempt to kill Java. Who knows if this is true, but the reality is that C# fixed and added a lot of features that Java excluded. Java still has its place as does C# now.
Feel free to include any of this information in the article as you see fit.
—Frecklefoot 20:43 9 Jul 2003 (UTC)
I think beginners are helped if there is a clear distinction made between programming languages, used to express a programming idea, and the mechanisms supplied to interpret that language. Is it really true that C# programs will only ever be interpreted by the .NET framework? AJim 18:57, 15 Apr 2004 (UTC)
Well, that Microsoft's plan. They plan to install the .NET Framework on all future versions of their operating systems (the MSIL is "portable" in this manner), but I don't think they'll stop anyone who wants to write their own version of the CLR for a different OS. Being Microsoft, they'll just change it so often that it will be impossible to keep it as up to date as the Windows CLR. Why do you ask? —Frecklefoot 19:09, Apr 15, 2004 (UTC)
Java And C-Sharp Compared has a pretty good comparison of the two languages. - Bevo 20:45, 15 Apr 2004 (UTC)
There is a lot of politics here, no question. Microsoft is Microsoft. Windows needed a new development platform. A Java-like language with a supporting runtime was a natural choice - it was popular, easier to program (in some ways) than C/C++, and could cleanly support multiple languages, even multilanguage projects.
If Java was open source, Microsoft wouldn't be able to touch it. Java is corporate sponsored by Sun, which has been a clear enemy of Microsoft (in the 90's the CEO was very vocal about MS). So Microsoft could not invest in Java without giving huge credibility and control to Sun. Even then, Java and a JVM alone would not unify the platform the same way .NET does. The natural choice was to make a similar language, C#, and a new runtime (CLR).
Dude, sign your posts. :-) Use ~~~ or ~~~~ (the latter timestamps your signature, like mine). — Frecklefoot | Talk 15:41, Jul 6, 2004 (UTC)
C# is hardly a Java clone. One could claim that Java is a C++ clone, ad infitum if you wanted to start equivocating wildly. C# has had from the beginning strong Java influences, yes, but not a clone. C# retains the concept of pointers, enumerations (just added in J2SE5... wtf, they skipped 3.5 numbers!), event handling (it is a "first class citizen" in the language, so to speak), operator overloading (Java needs this to be a better OO language, IMO), the foreach loop, and others. Moreover, IMO, C# has the right amount of verboseness, having programmed in both Java and C# extensively, I say it is smarter to write "bool" rather than "boolean".
I don't think Java, or any other language for that matter, needs operator overloading to be a better OO language. After all, it's just syntactic sugar for method calls. In fact, I think Java needs to get rid of the way you can call static methods via instance references to be a better OO language. — JIP | Talk 07:40, 21 Apr 2005 (UTC)
Syntactic sugar? Come on! It makes statements a lot more readable... someClass + someInt is more readable (and more concise) than someClass.toInt() + someInt. DoomBringer 01:21, 1 Jun 2005 (UTC)
Syntactic sugar does mean enchanced readability. Avoid the features like pointers and enumerations (which are not C++ - deriviations) and you get a pure Java OOP source code compiled into Java bytecode. C++ source code looks completely different and is unservicable/unrecognisable/unmanagable by intelligent IDEs. --Javalenok 15:43, 13 June 2006 (UTC)
Just wanted to agree with the last reply - C# is FAR from a Java clone. It is somewhat similar syntactically but the fact that it's part of the CLR makes it a different animal entirely, not to mention some other miscellaneous (but major) differences such as switching on strings being allowed (and optimized to a hashtable behind the scenes when advantageous), the absence of checked exceptions (a very deliberate omission by the C# team), and allowing pointers a la C++ (as the previous posted mentioned) in "unsafe" mode. In fact, I think these differences are very important and relevant and should be included in the article. Overall C# is a very simple, uncluttered, and I would say beautiful language. One can't truly appreciate it (and will probably instead attack it for being a brainchild of the evil Microsoft) until one has used it. --WayneMokane 07:57, 19 Dec 2004 (UTC)
Adopting "programming with potinters" concept into Java does not kill its spirit, neither make it c++ deriviateve (there is a bunch of languages besides C supporting the pointers). Both language synthax, Javadoc, all the libs starting from the root Object class, GC, exceptions, bytecode VM - everything is stolen. The most considerable difference, the Microsoft's inventation, is getting money from developers for pinning your application users at their commertial platform. Actually, this behaviour is not an attempt to kill the Sun-Java, it is not a revenge - Microsoft just did not have such a tool for effective application development. Microsoft was forced to make a clone to prevent the drift of developers and users from the Windows on the Java platform. Not only C# is clone of Java - the whole .Net is a clone of Java platform.--Javalenok 15:29, 20 January 2006 (UTC)
Hmmm... following this logic Java and C# are both clones of Smalltalk. I Think we can agree that they are not that, at least. Hogan 23:37, 28 April 2006 (UTC)
It's more or less Microsoft's response to losing that lawsuit from Sun. They took MS-Java and removed the OS-compatibility, then kept the same syntax and structures that Java uses. Perhaps a section refering to the similarities should be made?
Even if it is based on a different framework, the syntax of C# is very similar to Java, so actually programming in C# isn't much different than Java/J#. Having had some experience in Java and J#, learning C# was very easy. --71.227.190.111 15:30, 14 July 2006 (UTC)

When it comes to C# and .NET specifically, if you take a step back they bear a striking resemblance to Java:

  • Bytecode (yes, MSIL is bytecode).
  • JIT.
  • Monolithic support class library
  • Cross-platform in theory as designed by Microsoft, and in practice as implementod by Mono and DotGNU.

But it does support things that Java doesn't:

  • Delegates, aka function pointers.
  • Real properties (although this could be implemented in the Java language as syntactic sugar for getters and setters).
  • Tighter control of element overriding.
  • Stack objects aka structs.

This is by no means an exhaustive list. While I do think that .NET copied a lot of the design of Java, it's equally obvious that they put a lot of thought into the things that they changed/added and didn't just "copy Java." --Chris (talk) 16:08, 14 July 2006 (UTC)

They tried to "just 'copy Java'" (J++) and Sun beat them in court. Hence, C#: the I-can't-believe-it's-not-Java. --70.104.16.183 17:47, 18 October 2006 (UTC)

Delphi's Influence

C#'s chief architect is Anders Hejlsberg, the brains behind Turbo Pascal and arguably the main brain behind Delphi. The similarities between C# and Delphi are striking to anyone familiar with both languages. This point deserves a bit of expansion, I think: you can't grok C# if you only think about Java and C++, because a lot of the stuff that's alien to both is part of Delphi.

Quite true. C# addresses a number of problems and annoyances that are found in C++, much more so than Java did. I can certainly see the Delphi influence in C#, although It's probably more obvious in the IDE than in the language itself. C# also takes programming languages a step beyond existing languages with the concept of attributes. --69.5.156.155 5 July 2005 13:35 (UTC)
I'd have to agrue that point -- most people would say that attributes take the language back a step to C or ASM. Attributes while having a nice OO sounding name slap the face of OO programming. Attributes (while nice feature) are really just (user programmable) pragmas or macros. Hogan 23:41, 28 April 2006 (UTC)
This is not true. Only some uses of attributes result in them being similar to macros and pragmas. One use you're thinking is probably something like [Deprecated]. However, there are a number of other things that one can do with attributes. For example, they're available at runtime via reflection -- that's nothing like macros or pragma. They're used in very interesting and powerful ways within the .NET framework, ways which have a non-obvious OO equivalent. Take a look at XmlSerializer for example.
Xiphoris 01:56, 13 June 2006 (UTC)

Paragraph Too Technical

The following paragraph needs elaboration (better language, more context, eg. comparsion with Java JIT compilers which have been around for some years now; language too technical. From a user point of view it is important too know if the programs are as slow as Java programs or not.)

The verb to jit is not generally known.  ;-)

When the program is executed, the .NET framework JITs the intermediate code into machine language as it is run. The JITting is very fast and is not noticeable on most modern PCs. As different parts of the program are used, they are JITted. Once JITted, that portion of the program does not need to be JITted again for that run (the program will use the JITted version). Each time a .NET application is run, it needs to be JITted in this fashion. Because the .NET applications require this JITting, only computers with the .NET framework can run .NET applications.

--Hirzel 13:07 9 Jul 2003 (UTC)

How's this?
When the program is executed, the .NET framework JITs the intermediate code into binary code as it is run. The JITting is very fast and is not noticeable on most modern PCs. As different parts of the program are used, they are JITted and the resulting binary code is cached. If the program uses that portion of code again, the cached binary version is used. Each time a .NET application is run, it needs to be JITted in this fashion. Because the .NET applications require this JITting, only computers with the .NET framework can run .NET applications.
I'm technical, so it's hard for me to see what is "too technical" about this paragraph (I wrote it originally). I included links for JIT which I realize is unfamiliar to many people. I'd appreciate someone unfamiliar with the field to take a swipe at it, but the whole JITting thing is pretty technical. I don't know if it can be made any easier to understand. But just because it's hard to grasp doesn't mean it shouldn't be included. I read TONS of stuff in Wikipedia that I don't understand. :-) —Frecklefoot 20:28 9 Jul 2003 (UTC)
I gave it a try. I avoided using the abreviation jit as a verb. I added two subtitles. It would be nice to have something about the syntax as well. --Hirzel 22:25 9 Jul 2003 (UTC)
The syntax is similar to both Java and C++. For example, in C++ you might use class.foo() or class->foo() depending on the situation. In Java and C#, you always use the dot notation (i.e. class.foo()).
C# also has a really nice feature called Properties. With a Property, you can get/set values in classes in a more familiar manner while still hiding information. Let me put this into plain English. In C++ or Java, to get or set a private member, you'd have to do this:
int foo = myClass.GetFoo();
myClass.SetFoo( foo );
However, with properties in C#, you can do this:
int foo = myClass.Foo;
myClass.Foo = foo;
It looks like you are setting and getting a public member, but in reality you are accessing the private instance of foo (notice capilization). The manner in which properties are declared in C# looks like this:
public class Bar
{
  private int foo;
  ...
  public int Foo
  {
     get
     {
        return foo;
     }
     set
     {
        foo = value;
     }
  }
  ...
}
Note the special keywords "get", "set" and "value". The example above just returns and sets the private member, but anything can be put into the get/set routines--they behave just like regular functions.
C# also won't allow you to directly access memory like you can in C++ (it is similar to Java in this manner). But you can access memory directly if you enclose the code in a block declared as "unsafe". If you do this, you, the programmer, are responsible for releasing any memory you allocate as the GC won't.
There are other differences, but these are the two big ones that come to mind. —Frecklefoot 14:25 10 Jul 2003 (UTC)

In our University we had a project- comparing of execution time of same applications(about 50 apps. of different types, sizes, etc.) writen in C# and J . not once J was faster and C# was faster 2-12 times!!!

C# to C#

I noticed Dysprosia changed all the instances of C# to C#. While I realize this would be correct for music notation, I have never seen C# written this way (even by Microsoft). If no one objects, I'll change it back to C#. Any objections?

Also, I changed the notation in the example from the K&R/Java style to the C++/C# style which is preferable for C# code. —Frecklefoot 14:19, 4 Aug 2003 (UTC)

No, wait, this is how MS themselves format it on the box...Dysprosia 03:56, 17 Nov 2003 (UTC)

Lookylooky [3] :) I suspect MS couldn't be bothered to always render C# as C#... Dysprosia 04:06, 17 Nov 2003 (UTC)

Microsoft marketing uses a logo that resembles ".net" but you'll find Microsft explictly states it's more corretly ".NET", so I expect C# versus C# is the same, but I haven't looked for the style/trademark guide that says so. — Mark Hurd 19:07, 17 Nov 2003 (UTC)

Perhaps it'll be best to sup the sharp once, and leave the rest. I don't know :) Dysprosia 10:11, 17 Nov 2003 (UTC)

I'm a total newb but I undid Nohats use of the proper sharp symbol mainly because it was showing up as a square in Internet Explorer and Opera. So I think the symbol used wasn't UTF-8 or something. Using a superscript version of the regular # seems to work best because it shouldn mess up searches too much. Pardon me if I goofed up, a newb still getting his bearings. Foofy 13:31, 1 August 2005 (UTC)

You were absolutely right about this, Foofy. The large majority of readers (more than 95%) will just see screwed up characters, not the intended character, regardless of which is more correct. Let's stick to # and think about our readers. Deco 18:52, 1 August 2005 (UTC)

C# is referred to as C# by ECMA, Microsoft and the vast majority of all the other sources. C# is shown on the logo (and that logo on the box) of C# but that is an artwork rather than an actual text reference. C# is C#. 213.46.246.133 20:06, 14 July 2006 (UTC)