Talk:Comparison of C Sharp and Java
 | Java Start‑class Low‑importance | |||||||||
| ||||||||||
 |
Links from this article with broken #section links : You can remove this template after fixing the problems | FAQ | Report a problem |
| Links from this article which need disambiguation (check | fix): [[CLR]], [[generics]]
For help fixing these links, see Wikipedia:WikiProject Disambiguation/Fixing a page. Added by WildBot | Tags to be removed | FAQ | Report a problem |  |
|
This page has archives. Sections older than 90 days may be auto-archived by Lowercase sigmabot III if there are more than 4. |
Simplicity vs. feature richness
Wikipedia is great for beeing _SIMPLE_ not for beeing "feature rich". This article evaluates C# as better, because it has more features, than Java. The "missing" features of Java are marked red. Diplomatically speaking, this approach is not very clever. 193.165.212.242 (talk) 11:54, 14 November 2011 (UTC) (cs:User:Pteryx)
The tone of the article makes it seem heavily biased towards C# because it has features that Java doesn't - ignoring whether Java would actually benefit from these features or not, and the fact that the vast majority of them were deliberately left out because of design principles of the language. Then lo and behold when a feature comes along that's in Java and NOT in C# (checked exceptions for instance) the article launches straight into talking about all the disadvantages of checked exceptions! And when the opposite happens, such as with LINQ, the article discusses all the positives about it.
This article has the potential to be good, however at the moment it's nothing more than a load of biased waffle. I use both C# and Java extensively and have no bias towards one or the other, but this page definitely does. 86.26.141.146 (talk) 17:31, 1 January 2012 (UTC)
- Once again (see below): this article compares two languages by listing their features and mentioning alternatives on he other side. Becaue C# has more features than Java, C# comes out as ... well, having more features. There is no bias in that whatsoever. Commenters like you keep coming here on how the article is 'biased towards' C#. I don't see any such bias. Please point it out. There definitely needs to be an opinion piece to explain to people using software that more features doesn't always equate better, but this article is not the place for that, I think. Rp (talk) 18:05, 3 January 2012 (UTC)
- Article.biased() == false; C# is simply a newer language than Java and thus has more features because the C# programmers thought of stuff that the Java guys didn't. But that doesn't make it better. How it's used is important as well. Cheers, The Doctahedron, 00:42, 24 January 2012 (UTC)
Value types
C# value types are not syntactic sugar. To meet that definition you would have to demonstrate what kind of code is really generated which you could have written yourself. You cannot do that with value types as they exhibit copy semantics - i.e. they are stack allocated and new copies are created when assigned or passed as parameters. Apart from that, being "syntactic sugar" is not an impeachment. Every single programming language is rife with "syntactic sugar". For loops are syntactic sugar: You can demonstrate how the resulting code can be generated as a result of statements and a while loop (or vice versa). Syntax matters. Useerup (talk) 22:26, 25 October 2010 (UTC)
- Response: Value types are not a language feature,end of story, your wrong , give it up. Nobody outside Redmond and MS Fanboys cares about value types. They are not defined in any computer science literature, they are an invented type by MS. Not once in programming in C/C++/python/ruby/java/ADA/perl have I ever heard someone say 'geez wiz I wish I had value types'. You really need to stop arguing with everyone on this page. You keep reverting peoples changes, pretty much disagreeing with everyone where they are saying there is bias. How are we suppose to get rid of bias if you are allowing any real changes? —Preceding unsigned comment added by Bongey (talk • contribs) 14:46, 26 October 2010 (UTC)
- C#/MS aren't the first once that use the naming 'value' and 'reference' types for their objects, let me just name ECMAScript (or more commonly known as javascript), which was there long before, and used that including the name. Before you make assumptions, here's a technical (though easy to understand) explanation of what a value type actually is: http://stackoverflow.com/questions/1113819/c-arrays-heap-and-stack-and-value-types/1114152#1114152. Try to link that to C++ and you'll see that a reference type is actually nothing but a pointer to an object (which is stored on the heap) that is stored on the stack, and with value types, the actual object is stored on the stack. So under different names, this feature is present in a lot of programming languages. Aidiakapi (talk) 10:02, 15 September 2011 (UTC)
- "Value types" is a kind of language feature.
In Java, they are called primitives.
In C++, the difference can be summed as "Do I own the object directly, or through a (smart of not) pointer?". The difference is very important, as in C++, the last thing you want is to allocate everything through a new, if only because of performance reasons. But I should not have to explain you this, as you claim extensive experience in C++.
Anyway, this is exactly the reason why in Java primitives are not objects (I was told they tried having all primitives being true objects at first, but turned back because of performance).
In C#, they made Value Types derived from Object, but still made them "primitives" as understood by Java.
So Value Types are, as primitives, a language feature.
Fact is, Value Types as understood by C# are a first-class citizen of C#, when their equivalent (primitives) are not in Java:
C# handles boxing/unboxing when needed, and does not impose boxing/unboxing when it is not needed, for example.
Java is unable to handle primitives correctly without always boxing them first (for example, in generics).
Thus, the difference in handling Value types/primitives by the two languages is very important, and should be explicit in the current article.
Paercebal (talk) 13:05, 23 April 2011 (UTC)
- "Value types" is a kind of language feature.
- I fail to see what's specific in Value Types, except Microsoft's marketing maybe. In .NET value types are also boxed / unboxed, because .NET really wraps the primitive values in Objects, and this operation cost a lot, like in Java. Also transparent boxing / unboxing of primitives is also managed in Java, for example this is perfectly valid Java code:
List<Integer> list = new ArrayList(); list.add(2); int value = list.get(0);
More than that, if you try to code the same examples provided by Microsoft to explain how Value Types are working, these examples also work in Java, with an almost identical syntax.Hervegirod (talk) 21:41, 24 June 2011 (UTC)
You are mistaken, value types are not boxed/unboxed in .NET like they are in Java. This would be the code in C#:
var list = new List<int>(); list.Add(2); int value = list[0];
And it would not involve the relatively expensive boxing and unboxing conversions. This goes for any primitive and value type (primitive types are just a subset of value types). int is a value type, and in C# you can define new value types. Only when value types are treated like objects (reference types) are they boxed. You may declare arrays of custom value types and the array will contain the actual values not a boxed references to values. Useerup (talk) 23:23, 26 June 2011 (UTC)
- Microsoft documentation says: "Boxing operations occur when you pass a value type to a method that takes a System.Object as an input parameter."[1]. Which is the case for List.[2]. There is a lot of syntactic sugar in C#. Hervegirod (talk) 12:39, 15 January 2012 (UTC)
- This thread is more than six months old, so I wouldn't expect much response. However, the documentation you linked says "..takes a System.Object as..". Generic list does not take System.Object as input parameter, indeed, the lack of boxing is one the main reasons for generics to exist and why generic collections are faster than their nongeneric counterparts. List<T> differs from ArrayList (which inherits from IList interface) by strong typing of the collection objects. --Sander Säde 12:59, 15 January 2012 (UTC)
- As Sander Säde says, you are linking to the non-generic version (comparable to a "raw" type in java). C# has generic versions of collections and in there you will find a List<T> as was demonstrated to you in the example above. Repeat: Value types are first-class citizens and unlike in Java no boxing is performed when stored in a generic collection of the same type. It has to do with the fact that C# has reified generics and does not erase the type of generics parameters.--Useerup (talk) 16:52, 16 January 2012 (UTC)
- Trying to implement a Complex type in C# is a good exemple of what C# can do with value types and operator overloading (kind of new primitive types). It is impossible in Java. — Preceding unsigned comment added by 193.8.222.12 (talk) 10:53, 17 January 2012 (UTC)
- Microsoft documentation says: "Boxing operations occur when you pass a value type to a method that takes a System.Object as an input parameter."[1]. Which is the case for List.[2]. There is a lot of syntactic sugar in C#. Hervegirod (talk) 12:39, 15 January 2012 (UTC)
I think you're missing the point...
Some contributors have hinted at what I'm going to say. Perhaps it should be stated directly.
It's "obvious" that a language with "more" and "better" features is the "superior" language, right? Well, maybe. This article ignores the point that the differences among languages aren't as important as the differences among the programs you write with these languages. For example...
How do Java's seeming "deficiencies" affect one's ability to implement a particular programming approach?
How often do programmers have to "work around" particular features in either language?
How do the languages' features and syntax affect one's ability to write clear, easily maintainted code?
In other words... how do the differences between Java and C# affect their utility as programming tools, including algorithmic "expressiveness"?
I'm sure programmers more-experienced than I will have caught things I've missed. But the article is too low-level; it overlooks the broader issues. WilliamSommerwerck (talk) 20:57, 23 August 2011 (UTC)
- (not sure what/who the above comment is aimed at but here goes) No, it is not obvious that a language with more features is "superior" (as you out it). The objective of this article is not to pass judgement on which is superior. You are setting up a straw-man argument. A wikipedia article is about verifiable facts. This article should only under exceptional circumstances label anything as a "deficiency" - and should only do so if there are ample authoritative sources for such a claim. Whether a language supports a specific (or equivalent) feature, or even how it supports a given programming discipline (functional programming, dynamic programs, object oriented programs, numeric or financial applications etc) can be demonstrated by careful examples. However, turning the article into a survey or synthesis of how the languages are actually used would violate WP:NOR. That said, I'm all for creating a more discipline oriented article (as opposed to a feature-oriented article). It is, however, very difficult to do so without introducing original research. Useerup (talk) 17:40, 24 August 2011 (UTC)
- I'm concerned that this article contains really a lot of original research, which is maybe inevitable considering the amount of content in it. But I think it has much too many content for its subject. Sticking to valid sources would reduce its content, but improve its quality (and be in line with Wikipedia rules BTW). For now even for programmers its very difficult to read. BTW there is a tendency in this article to explain concepts, but I would prefer to have the explanation in the specific articles about these concepts (example Delegates) rather than in this already overly long comparison article. Hervegirod (talk) 21:41, 28 August 2011 (UTC)
- (not sure what/who the above comment is aimed at but here goes) No, it is not obvious that a language with more features is "superior" (as you out it). The objective of this article is not to pass judgement on which is superior. You are setting up a straw-man argument. A wikipedia article is about verifiable facts. This article should only under exceptional circumstances label anything as a "deficiency" - and should only do so if there are ample authoritative sources for such a claim. Whether a language supports a specific (or equivalent) feature, or even how it supports a given programming discipline (functional programming, dynamic programs, object oriented programs, numeric or financial applications etc) can be demonstrated by careful examples. However, turning the article into a survey or synthesis of how the languages are actually used would violate WP:NOR. That said, I'm all for creating a more discipline oriented article (as opposed to a feature-oriented article). It is, however, very difficult to do so without introducing original research. Useerup (talk) 17:40, 24 August 2011 (UTC)
- I agree with WilliamSommerwerck. A "feature rich" language tends to be more efficient in some aspects, but it is harder to understand and to maintain. Languages are used to write applications. In more features more treacherous details may hide. For example, comparing signed and unsigned integers may create a serious problem in C/C++. Not having unsigned integers means significant simplification of "rules of the game". In my opinion this is no defficiency, this is GOOD. The article marks not having unsigned integers as Java defficiency, this is ignorance. However, from the point of view C programmer the differences between C# and Java are too small to say which language is "better". Maybe Python ;) --193.165.212.242 (talk) 11:43, 14 November 2011 (UTC) (cs:User:Pteryx)
Suggest correction to "High-Precision Floating Point" row on the feature table
Decimal is a fixed-point type. It's the exact opposite of floating point. The only thing they have in common is that they both can have a decimal point in their string representations. — Preceding unsigned comment added by 66.193.1.106 (talk) 14:15, 7 September 2011 (UTC)
- Decimal is a floating-point type. It's modeled as -1sign * coefficient * 10-exponent. The exponent term determines where the decimal point will be, hence "floating-point." A fixed-point value is basically an integer with an assumed radix point at a predefined position. SqlDecimal is closer to a fixed-point type, but the scale is still adjustable and it doesn't have the performance benefit that you might expect from a true fixed-point type. Maghnus (talk) 12:51, 15 September 2011 (UTC)
Incorrect/Outdate Comparison Chart
It seems that the comparison chart has some mistakes or it's outdated, it needs a java expert to revise it. I think java has some features but in the article it's said it doesn't such as : Implicit conversions,Explicit conversions, Events, Rectangular (multidimensional) arrays, Unified arrays and collections, ...
Also it seems that features of C# is listed, then it compared to java, which is a completely wrong approach since in many cases java has a better and more smart workaround for a problem without needing to have a feature for it. For example java never needs Explicit interface implementation, since it has co-variant return types. — Preceding unsigned comment added by 83.166.30.230 (talk) 17:19, 14 December 2011 (UTC)
- The purpose of explicit interface implementation in C# is to hide functionality unless an instance is explicitly casted to the interface type, or to stack method or operator implementation that would otherwise clash (such as IList vs. IList<T> member implementation). So co-variant return types in Java is not equivalent. Dahvyd (talk) 06:28, 15 January 2012 (UTC)
- The table is correct:
- Implicit/explicit conversions: Perhaps they should be termed custom implicit and explicit conversions. Java does not allow you to create a new type (class) and define conversions to be used automatically when resolving parameter types (implicit conversions) or custom "casting" logic (explicit conversions). In C# implicit conversions have been used to allow automatic "promotion" from e.g. int to the decimal.
- Events in Java exist in the BCL, but it is not a language feature as it is in C# (this WP article is about the programming languages). C# events generate "adders" and "removers" automatically much like automatic properties.
- Rectangular arrays: No, Java does definitively not have those. Both Java and C# have "arrays of arrays" (also called "jagged" arrays), but only C# has rectangular arrays. Their usefulness can be discussed; they have certain advantages (sometimes better performances under random access) and drawbacks (overhead under sequential access) compared to arrays of arrays.
- Unified arrays/collections: C# allows a "list" view on arrays and the "foreach" loop uses the unified IEnumerable interface which both arrays and collections implement. In Java, arrays and collections have not been unified; rather the "for" loop has been extended to accept both collections and arrays with the "for each" syntax. But they are actually different statements and you cannot pass an array where a list is expected. You can in C#
- Maybe the table needs to be supported by more examples? --Useerup (talk) 16:46, 16 January 2012 (UTC)