Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why should I upgrade to c# 4.0?
Our projects are currently all C# 3. If we dont have a specific requirement for features that C# 4 provides, would there be any other reasons for us to upgrade? Thanks.
Edit
There seems to be more of an advantage with using the new CLR and not just the new language features.
I personally don't feel that there are great language enhancements between C#3 and C#4 if you're targeting the same framework (2.0-3.5).
However, if you move to .NET 4 CLR as well, I think there are all sorts of benefits in the runtime you can take advantage of. My favorite feature is the parallel task library.
It depends on what you want to do. I don't there are killer language features that 2.0 (Generics) and 3.0 (LINQ and Lambdas) had. C# 4 is more scenario based (see list below for some). If you want to:
take advantage of the new features in WCF (default endpoints, improved WCF REST support, etc.);
work with Entity Framework 4 and it's new features along with WCF Data Services to expose your EF model as a data service;
take advantage of some of the multi-threaded enhancements (e.g. Tasks instead of using Threads);
CodedUI tests (more of an IDE thing, not a language thing);
etc.
...then maybe I would. (Most of my projects utilize WCF in some way, so I'm in the process of upgrading.)
I wouldn't upgrade just to upgrade. Upgrade if you have a business/technical reason to do so. You have to weigh the costs (less time coding while you upgrade your environment) with the benefits (latest language, and as one commenter said, happier developers).
Plus, the IDE is nice (although I've found it a little unstable at times). And as w69rdy's comment said, it's backwards compatible. You may want to give the IDE a try and still stay on .NET 3.5 just to try some of its features (like the extension manager and schema comparer).
If your software is fairly static and business critical then an upgrade may present a risk to the production uptime of the business. However, if you plan to continue development of the business' software well into the future then at least planning to upgrade is a step in the right direction. There's no reason to limit one's development to older versions if the company wants its code to keep moving forward. Future problems may have easier and more expressive solutions using newer language capabilities.
There's also certainly something to be said about keeping one's development staff current on technologies. If the business wants its technologies to remain static, it's going to have an increasingly difficult time finding talent over the years.
If upgrading to C# 4 is not a vey large pain for your system, then it's worth it just to have you projects on the new runtime, if .NET 4 were running on .NET 2 like .NET 3.5 is I would say don't bother, but the benefits of being on the newer runtime are futuresafety in this case since there will be future .NET releases based on the .NET 4 runtime, and the upgrade may be more difficult come that time.
I am making the assumption that you're asking if it's worth it when you don't need it because it wouldn't be extremely difficult for you to upgrade, if it would present particular risk and difficulty in your project then it would not be advisable without a sufficient business need for the functionality in .NET 4
If you are using ASP.NET WebForms it might be worth. Take a look at this blog entry.
Web.config files are much cleaner now and css support was enhanced a lot. WebForms Routing is also a core feature under 4.0. Best of all, you finally get full control over your control id's!
In my opinion, WebForms still isn't as nice as ASP.NET MVC, but it got much required love in 4.0.
Reading the Bruce Eckel book "Thinking in C#", to relearn C#, since I haven'y used it for many years but am likely to be needing it again soon.
I was surprised by this statement:
"In C++, the keyword that implements
parameterized types is “template.”
.NET currently has no parameterized
types since it is possible for it to
get by—however awkwardly—using the
singly rooted hierarchy. However,
there is no doubt that parameterized
types will be implemented in a future
version of the .NET Framework."
I think I remember reading somewhere that C# has generics - which are similar to C++ templates?
Am I wrong, or is the Eckel book simply too outdated (if so, is it worth still reading or is there a more up to date book online?)
[Edit]
Eeek, I'm glad I checked in here first. Looks like I'll have to throw that book away (written in 2002 I believe). Can anyone recommend any downloadable book that has the same depth of Eckels 'Thinking in ...' series?
There are a lot of C# books out there, but most of them are far too basic, or do not cover enough material. I was happy to find Eckel's book, since he covers C# in usual thorough style (from an introduction to OOP [which I don't need], through WinForm and Threading) - Unfortunately, it looks like its too old (Damn you MS for changing C# specs more times than I've had hot dinners!)
Can anyone recommend a good downloadable C# book that has a similar width/depth coverage?
[Edit 2]
Just seen this book:
http://www.free-ebooks-download.org/free-ebook/dotnet/CSharp/beginning-visual-csharp-2010.php
I'd like the opinion of this book from any professional C# developers out there ...
It's probably describing C# 1.0, which didn't have generics.
I would recommend finding a newer book that covers LINQ (introduced in C# 3) and dynamic (C# 4).
I would definitely get the most recent book that's relevant to the version of the .NET framework you're programming for. I started with an old book which didn't even cover automatic properties. Now one year later, I'm changing all of the previous code because it's so bloated and verbose.
Anyhow, C# does have generics, which as far as I can tell are the equivalent of C++ templates.
Generics are in C# since .NET 2.0, which came with Visual Studio 2005. The book is older than 5 years, you definetly need to get rid of it! :)
As others have noted, your book is out of date, or rather describes an out-of-date version of the framework.
It's interesting to note that the first language specification for C# published to ECMA for standardization included generics as a part of the language. C# 1.0 and 1.1, in not including generics, were not full implementations of the C# language. 1.0 and 1.1 should have been numbered 0.1 and 0.2 or some such, but Microsoft doesn't number things like that, as risk adverse people avoid doing real work with beta products.
I mean library and syntax of C#.
For the class library, ask the Mono Class Library status page
C# 3.0 is supported fully.
C# 4.0 version works but considered 'preview' until MS compiler is finalized. There're even some language extensions, although I doubt if they will be ever backported to MS compiler.
You can view Mono's status updates (Like a Timeline, really), from their wiki.
Mono Status Report
There's a pretty in-depth analysis here from January of this year.
The Wikipedia article's "Current status and roadmap" looks helpful too.
There's no equivalent of VT fixup or anything related to unmanaged exports for that matter.
That's not surprising, though. Considering that you would have a hard time using something looking like a Windows DLL as .so or .dylib. ;-)
I am not sure, but mixed-mode hasn't been supported a few years ago when I wanted to use it.
Maybe they added it, but I don't think so. Might be the big fat mother of all worm cans to open for an X platform CLI implementation.
There are three aspects you need to consider.
Language
Framework
Runtime
Language:
Mono fully implements C# 2.0, and has almost complete support for 3.0. This means it supports all of the syntactical language features like generics, properties, anonymous methods/types, etc.
Mono supports Visual basic 8, but not 9.
Framework:
Mono fully implements ASP.NET and ADO.NET. Windows.Forms is mostly done.
WCF and WF are in progress.
WPF is not done, and is many years away from being done (if ever). I believe this is now a side project.
Linq-to-SQL is not yet finished.
Runtime:
The CLR has been almost fully implemented, including support for the DLR.
Your best two sources of information are probably the Mono home page (specifically the FAQ and the Status report), and the Wikipedia page on Mono.
Please have a look at the Mono Project Site or at the Wikipedia-Article.
But the last thing I heard is thet C# 3.0 is complete (except some LINQ-Features).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
C# has a good momentum at the moment. What are the features that you would need to have in order to switch (or return) to Java?
It would also be quite useful if people posted workarounds for these for the current Java versions, e.g. Nullables being wrapped around custom classes, to make this a much more interesting wiki.
As a .NET/C# developer here are the missing features that annoy me. This list in no particular order - just as thoughts come to mind:
The Java library is too small. For common things I have to choose between 5 competing open source products because the base library is lacking in so many ways.
This is an Object Oriented programming language right? Why in the heck do primitive types not inherit from "object"?
Pointers
Lambdas
Closures
Partial Classes and to a lesser extent partial Methods
Real support for Generics
Using statements and Dispose - this was a real WTF for me. You really have to explicitly close connections in try/catch blocks. Poor Java guys!
Yield return would be nice
Unsigned integers - again WTF? I have to use number types larger than I need for what purpose again?
In Java you can return from final blocks of try/catch. A co-worker confused the hell out of me for hours by introducing a bug this way. This behavior should be prohibited as in C#.
I rarely have to use Java and when I do, I have all sorts of WTF moments.
Edit: I Removed for-each comment based on the fact it is no longer a missing Java feature since 1.5.
In my experience, Java vs. .Net is more of a business decision than a technical one. Shops with MS experience trend towards .Net and shops with Java experience trend towards Java & OSS. I've seen little evidence of people switching based upon language features. On the other hand, I've seen shops heavily tilt towards one platform b/c of one or two key employees they wanted to hire being knowledgeable in that area.
in no particular order:
function pointers (delegates); the whole passing interfaces around thing is stupid
real generics; what's the point of having type safe generics if the compiler can't even hold the meta data through a unit's compilation?
ui speed; all the self-drawing ui libraries are very slow compared to native controls wrapped in "managed" libraries, not to mention that microsoft's self-drawn ui is hardware accelerated through direct3d
an yield return construct; c# is so user friendly in this it's crazy
operator overloading
linq; just cuz its so addicting
properties; more synctatic sugar you get addicted to
better interop with native code; c#'s p/invoke and native com support makes interop so easy compared to jni -.-
first class value types; this goes hand in hand with real generics, having generic lists that never box/unbox in c# is part of why c# is faster than java.
and i'd say this is the most important one:
a responsive, informative debugger; nothing can even come close to visual studio right now
Just going off the cuff, I think the biggest thing Java 7 needs that everyone is lamenting the lack of is closures.
I'm a C# programmer and about one year ago I had to participate in the development of an application in Java. What I missed the most was:
Visual Studio (Eclipse is nice, but
VS is VS, especially Team Edition)
Comparing strings with ==
Properties
Basic types as first-class objects
(e.g. not "int" type vs "Integer"
class)
Anonymous methods (a workaround can
be made by using anonymous classes
but it is not the same)
LINQ
And there was one single Java feature that I missed when I went back to C#: explicit exception declaration in method signatures.
DISCLAIMER: I am speaking about a somewhat old project, I don't know if some of these features are present in current versions of Java.
Less heinous XML parsing and manipulation tools. Doing anything with XML in Java sucks.
I'll also give one answer the other way around. C# needs an enumeration implementation like Java has. Java's enumerations rock!
Let me add anonymous overrides to this list also. Sorry to go off topic, but C# needs the ability to anonymously override methods. I have been switching back and forth between Java and C#, and I have to say for unit testing legacy code, there is nothing better than anonymous class overriding.
I would need function pointers of some sort. The ability to use delegates in C# is so useful. There are so many times in Java where I want to create a map of delegates or function pointers as the solution, but I can't. I know you can simulate a similar thing in Java, but having the abstraction as part of the language is a huge plus!
Momentum. I have done a lot of development on both platforms. I'm enjoying the .NET side more because of the way the C# language is evolving. Java's evolution seems to be more a reaction to C# than an actual vision. So I think the best thing for Java to do is ignore .NET and create something new of its own.
Another one I would like is some equivalent to LINQ. I noticed how much I actually depend on the ability to use LINQ when I tried to do a top coder competition and realized they only support .NET 2.0. Once you get used to using LINQ to solve problem and make it part of your regular programming vocabulary it is very difficult to not see problems in that light. It is akin to using generics and then not being able to use generic.
I think, choice between Java and C# is not a question of language features, but a question of platform and ecosystem choice.
So, I doubt that any new syntactic sugar in Java or C# can lead to a significant amount of switchers between the platforms.
After all, JVM world has Scala and many language-sensitive developers are using it in some way.
I think, you should consider swithcing this holywar from "Java vs C#" to "JVM vs CLR", because JVM is (in the last years — mostly) not only Java, but also Scala, Groovy, Clojure, JRuby, Jython, and dozen of JVM-languages.
Properties!
Anonymous objects are nice too
Continuations, like Scala (on top of the rest) would be good too, for agents development.
Support to run over CLR (and vice versa perhaps for JVM) without IKVM and other such layers.
Let's be clear that we need to distinguish between Java and the JVM. I actually switched from C# to Java, but I admit it was not because of Java's amazing language features! In my very humble opinion, C# is the better language, and CLR is the perhaps a more elegant VM. However, even with Mono, you're not writing applications that run everywhere!
I think the greatest argument for Java is the amazing community it has. This is where the cutting edge technology is being developed, not at Sun (now Oracle). The Java community has consistently been the leader in developing Enterprise technologies. For instance, how long did it take Microsoft to provide a DI Framework? Where's AOP in .NET? When I start a .NET project, my foundation is Spring.NET, a Java port. When I need ORM, it's NHibernate. Need a testing framework? NUnit. I realize there are other OSS projects for the .NET platform, but their numbers and support from Microsoft are laughable compared to the Java community.
on the other side, has .net got enterprise open projects like Terracotta (semi commerical), Infinispan, Compass ? no. ncache (commerical), lucene.net are far behind them. Especially Terracotta is unique, it can improve some of your app x100, it's simply perfect and free (partitioning is commerical). If we implement a high load app in both .net with anything and java with terracotta + hibernate + terracotta-hibernate-integration, java app will probably far more performant than .net one. Ther're some ports to .net like nhibernate, log4net, lucene.net, but all of them are trying to catch java versions. And entity framework is a disaster, they have to start with nhibernate as the base or get some lessons from them.
.net is only working on windows (mono is far from enterprise, there isn't any enterprises using it), how much money does myspace.com spent for their 4000 windows web server licences ? 1 million ?
You can't install a simple plugin to VS (and can't do some other things) if don't buy professional edition,
Some windows instance types in amazon web services are nearly x2 price of the linux ones.
if you look at ohloh.net open source java project counts (with language comparison tools), you'll see that java has x5 more volume than c#.
also Java has %20 share on worldwide while c# has %4.x (source:tiobe.com)
Look at the top web sites; only microsoft and myspace are using .net. google, amazon, ebay, linkedin, alibaba, twitter (switched to scala from rails)... many of them are using java and many others are using php, ruby (facebook, yahoo,..)
As a language Java is far behind c#, but Scala (runs on jvm) is as good as c# and it's performance is nearly same as java and also it can use all jdk and other java code as his library.
I'm not saying java is better, but I'm saying java is as valuable as .net, too.
A native 'decimal' type for Java replacing the BigDecimal class would be nice. But Java thread-safe collections are nice.
Perhaps the question is not so much what Java 7 needs to persuade developers to use it, but more a case of what makes developers want to move from Enterprise/server-side java language to a different C# desktop Windows-only oriented world?
For most developers, the language isn't difficult to pick up be it Java or C#. I develop in Java, but Linq didn't take long to understand and use.
I think the choice of Java or C# depends on what motivates you personally -perhaps money? in which case either language will do whether they have certain features or not.
Ste
They should start by fixing the Calendar/Date related classes, even that seems too much to ask.
A simple way to map values in your model to the UI (like bind in Java/FX)
I think it depends on bussiness decisions, not the languages themselves.
But I really really really love C# lambdas and curry :D :D
http://mikeomatic.net/?p=82
a map({codeblock}) which runs over anything iterable would be nice. And filter too. And being able to return multiple values easily from a method.
(a,b,c) = getThreeValues();
(would assign the individual variables a, b and c).
Actually I just think they should have Haskell as a supported scripting language on the JVM :D
linq, lambda, anonymous types
I don't see any point in "luring" anyone anywhere. They solve different problems and you should use whichever one suits you.
Java has less "Language" and less structures to trip up new people, it's platform independent and it doesn't change too fast allowing old code to stick around for a LONG time (Good for some large companies).
C# has tight desktop integration and a slew of nice features that make it more fun to program. It has .net integration. It has pointers, closures, etc which make it harder for n00bs (a valid language target, hence Basic) but more fun for experienced programmers--I haven't convinced myself that these features make you more productive, but in some situations they can make your code a lot nicer! Also if you need pointers, you need pointers.
I don't see a whole lot of overlap in target audiences. Why change a language to attract programmers when it's healthier for the entire industry to have two healthy languages each targeted at solving different problems attracting different developers?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Back in 2000 (when .NET was unleashed upon us IIRC) it was an innovative cutting edge language (last time I used it was 2003).
From what I read though, Sun has only evolved the language exceedingly slowly. I've even read that where the language has evolved, such as the addition of Generics, developers have complained about poor implementation.
Are these accurate perceptions, and if so, any thoughts on why, particularly with the seemingly obvious competition from C#?
From an enterprise point of view, evolving a language is not a good thing, it's actually pretty bad.
That's why you hear older languages like cobol, fortran and even C written with year numbers after them--many enterprises stick with that year.
On top of that, larger teams means more of a chance that someone in your team will do stuff others don't understand, so there is an important but under-rated value in keeping a language simple and clean. This means not adding too many alternative ways to do things.
I worked with Ruby and had a ball with the language, but looking at it from an enterprise point of view, it was an absolutely terrifying language. I couldn't count the ways a bad programmer could mess up a large team, forcing them to spend days untangling a mess created in minutes.
There are companies who refuse to go to java 5.0 because of the complexity of generics. (We're still working on 1.3x but that's for another reason).
And honestly, most "Improvements" buy you very little. Some syntax change, the ability to remove a few levels of braces.
I can't think of a single case where Java has forced me to repeat business logic (Which is what I worry about when I'm trying to make my code "DRY")--it's a clean enough language to be completely DRY if you're a good programmer.
For instance, anything you can do with a closure you can do with a subclass without repeating business logic--what you end up with looks worse because of layers of braces/extra class definitions, but is often more reusable (You can extend the class you use to implement your callback, but you can't extend a closure method, you have to rewrite it.)
I didn't feel this way about code for the first few decades of my career (I LOVE language tricks, the funkier the better), but now I've been at this a long time--It could be my old age sneaking in, or it could be experience, but now I see huge benefits to simple, explicit, stable code (offered by a language that won't let you play tricks) and can't really find a single advantage to many alternative methods, even if they save a line or two of typing.
If you are looking for a java upgrade, however, look at Scala. It's pretty freaking amazing, still runs on the JVM, interacts with Java, etc.
Most languages have one strong hand involved in their origin and evolution. Think: Larry Wall/Perl, Guido/Python, Matz/Ruby, Odersky/Scala, Hickey/Clojure, etc. These guys are all brilliant language dudes. I'd give my left arm to be half as smart as any of them.
Java has actually had the distinction of having not just one but a series of amazing language guys at the helm - starting with Gosling, but I also think of Guy Steele, Bill Joy, Gilad Bracha, Neal Gafter, etc - all amazing guys. That actually has been a good thing (I think). It's made the language better but prevented stagnation.
But for the last couple years, there's been a real vacuum of language leadership. At the moment, no one's minding the store. No one's making the hard decisions about what fits with the Java mold and makes sense to add (or more importantly to not add). I don't know what that means. I'm hopeful that the enormous popularity and reach of Java and the strong base of the JVM mean that this vacuum is too attractive not to be filled and given direction at some point. But I'm only cautiously hopeful because I don't know who that will be.
John Rose is that dude on the JVM side. Though if I can only get innovation in one or the other, I'd take JVM right now anyways. :)
Java has certainly been evolving very slowly - especially if you compare it with C# and VB. I personally feel that they made the wrong decision with generics in terms of keeping backward compatibility at the cost of execution-time safety and efficiency. The .NET approach works a lot better in almost every way, IMO.
Java 7 has a long list of potential features - both language and platform - but it's been an awfully long time in the making, and there's still significant question marks over many of the features.
I wouldn't like to place any "blame" on why this has happened, however.
The evolution of the Java language has been slow, but deliberately so.
Generics provides a good example. Compatibility with prior versions of Java was a requirement. Given the goals of the project, the generics implementation performs a very useful function exactly as designed. However, it doesn't meet the expectations of many developers that expected the behavior of reified generics.
Innovation in the JVM, on the other hand, has been extremely rapid, often leading the way for other VMs, and promoting competition in the performance arena.
In my opinion, the Java language should be as stable as possible. I like the idea of closures, but I don't believe Java is the language for them. (If something must go in, I'd prefer the conservative FCM.) I work with a team of developers that need training, to build and maintain a complex production application. The Java language gives us a nice blend of power and structure as it is.
Other languages, like Scala and Groovy, and ports to the JVM like Ruby and Python, will continue to give life to the Java platform, even after the Java language itself has gone the way of COBOL.
Java has different problems then .Net at the moment, resulting in different choices.
.Net, being relatively new and with a chance to avoid some of Java's mistakes has the chance to do thing differently. This gives it two main advantages:
MS was able to more clearly distinguish between run time platforms. C# 3.0 will clearly not run on the 1.1 framework, and C# 1.1 won't run on the 3.0 framework. Of course, there is some fuzziness there, but in general you have a better idea where you stand. On the other hand, the client JVM auto-updates by default on windows. So it can be much trickier keeping an old system working.
The .Net framework, being younger, has accumulated much less cruft and internal complexity. Those things will kill the speed with which you can add new features. We're now starting to see some of this in .Net also. For example: there are a number of BCL functions that require you to pass in or return an array that should instead use an IEnumerable. The history of those functions make it nearly impossible to ever change them.
Those two things conspire together to make it possible (at the moment) for the the .Net languages to advance more quickly. However, like I've already said we're starting to see these effects catch up with .Net as well.
I think that Sun are now being conservative and ensuring they make the right decisions after making a few poor ones.
In addition there was a lot of politicking and messing around before Java 1.5 came out. Many companies were using third party hacks like Generic Java, because these core language features weren't available but strongly desired.
I think they have sped up again since 1.5, with 1.7 on the horizon, and it looks like each of these has delivered very useful new features. The open sourcing of the language is good as well.
And whatever some people say, retaining backwards compatibility has been a very important feature in the Java language.
I would say that .NET has kicked Sun's arses into gear, and that it is good that they both exist.
For a long time, Java has (for better or for worse) preferred to introduce new functionality through frameworks, rather than in the language itself.
You could argue that, for example, someone writing a Spring/Hibernate/Struts application is actually writing in a specialized dialect of Java, since their code will be largely inoperable without all the reflection/injection/instrumentation magic performed by the frameworks.
Personally, I'd prefer for the language to evolve a little bit more, and for the framework authors to quit monkeying with the language semantics via bytecode manipulation.
As a side note, I also strongly disagree with Sun's decision to use type erasure in their implementation of Generics. Supposedly, they wanted to ensure backward compatibility, but to me that seems totally spurious, since Annotations (added at exactly the same time, in Java 5) created their own set of incompatibilities. At any rate, code compiled for Java 5 can't ever be executed on an earlier JVM, so the backward-compatibility claim seems very dubious to me.