Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Nerval's Lobster writes "Previously, developer Jeff Cogswell focused on the respective performances of C# and Java. Now he's looking at yet another aspect of the languages: the runtime libraries—what exactly the libraries are, how they are called, and what features the languages provide for calling into them. Examining the official Java API (now owned by Oracle) and the official .NET API owned by Microsoft, he finds both pretty complete and pretty much a 'tie' with regard to ease-of-use and functionality, especially since Java version 7 release 6 allows for automatic resource management. Read on and see if you agree."

However, I mostly code in C#.NET and I dabble in Java in my spare time to model financial markets. What I have found is that C# has some powerful features that other languages do not have. This allows the.NET framework to be a little more robust than Java. Also my opinion is that C# and.NET creates a more syntactically elegant and coder friendly experience whereas Java is good, but not as good as.NET.
In closing, C#.NET > Java.
Please address.NET hate-responses to/dev/null

Microsoft has had the benefit of being the single controller of the.NET framework whilst Java has been victim of design by committee a lot of the time. This is why the.NET framework has managed to stay tidier and more focussed, but as I said in my other post what does it matter, because who the fuck sticks to just the core framework anyway when there are things like Spring out there?

Microsoft also had the benefit of Java going first and making all the mistakes, and then Microsoft got lucky when Java lost its first-mover advantage chasing down several blind alleyways -- "Applets", Sun's mismanagement, a bureaucratic open source strategy.

Applets are still freaking good.Look at for example: http://jchart2d.sourceforge.net/applet.shtml [sourceforge.net] I can get a full demo of the application in my web browser, how cool is that. IMHO the browser developers sunk Java Applets, because of their concentration to Flash and JavaScript. Java Applets are still way better then what you can do with JavaScript. For example, 3D with OpenGL, and it don't take 50% of my CPU like with JavaScript.

Open source is one of the strongest points of Java. There are now 500,000 open s

Microsoft has also had the benefit of Anders Hejlsberg being the lead architect, one of the best minds in the industry. There are maybe a handful of people in the industry today that can stand at the same level as him, and none currently alive that can stand taller. Hiring him away was a major boon to Microsoft and a crushing blow to Borland.

Microsoft has also had the benefit of Anders Hejlsberg being the lead architect, one of the best minds in the industry. There are maybe a handful of people in the industry today that can stand at the same level as him, and none currently alive that can stand taller. Hiring him away was a major boon to Microsoft and a crushing blow to Borland.

As much as I love to code in C#, I think that Martin Odersky is at least as smart and knowledgeable as Anders Hejlsberg. I've seen them debate each other and IMHO Martin came out looking somewhat better. And Scala is no small feat.

While Mono allows C#, it does not turn.NET into a cross platform executable environment. Practical programs using C# and.NET are tightly tied to Windows capabilities. Since C# isn't a standardized language, and Microsoft doesn't even stick to their own standards with their own products anyway, there will be incompatibilities between Windows.NET and Mono. Mono also does not re-implement all of the.NET framework and is playing catch up whenever there's a new inevitable.NET release. So if you want a cross platform executable system you are much better off with Java.

Basically the whole reason for existence of.NET was to tie the developer to Windows. It was created as a direct response to Java being a cross platform system.

The reason for.Net is not to tie developers to Windows. Microsoft just doesn't care about developers on other platforms. It's not malice, just laziness.

That said, it's important to know where.Net came from. Others have already pounced on the C# standardization comment, so I'm going to skip that part, but here's the rest as best as I can figure it out.

In the early 90's, Java became a thing. And it was good. Slow, but good. It steadily improved, and eventually, the hype wave washed it ashore on Windows-land

I am both a professional java and C# developer. Each one has their advantages:

On the C# camp:* delegates and events* functional constructs* automatic variable types* LINQ* Value types (efficiently allocate thousands of value objects in an array, you need some really nasty workarounds in java)* Generics that keep their types at runtime

On the java camp:* Spring (There is Spring.Net, but lets be honest: it does not compare)* Collections library (much more complete and better thought out than C#'s)* Maven* J2EE* A million other libraries freely available, that do _anything_ you want.* Portable to more platforms (Mono sometimes leaves something to be desired)

So in my humble opinion, C# is much more complete as a language, but java has much better libraries and community. So which one would I pick? well, it depends on the project, the platform, and the amount of code I can reuse from open source libraries.

I don't use C#, however last I looked all of its features were borrowed from other preexisting languages, same as Java. Is there something new and Microsoft for once in its life has done something novel?

I don't use C#, however last I looked all of its features were borrowed from other preexisting languages, same as Java. Is there something new and Microsoft for once in its life has done something novel?

LINQ is a pretty big deal. I don't know of any language that has something similar. LINQ itself is comprised of a number of language constructs such as expression trees, extension methods, type inference, anonymous types.

Async/await is huge! Right there, MS looks to leapfrog other platforms by allowing developers to create robust, asynchronous programs that doesn't need to spin up threads (or use threadpools) to achieve perfectly composable asynchronous methods.

Dynamic support (statically typed to be of dynamic type) allows the best from dynamic languages to be used from within C#, even interop'ing with dynamic languages and e.g. use an object created in Ruby as a first-class object in C# (or vice versa).

To be fair async still uses threadpools and you have to be careful how you use it so you don't starve it but yeah Linq, async and dynamic are all big deals. I'd also add how maintained it is. Thinking of the recent java volunerablity they new about it for something like 8 months I think before patching it. As bad as MSs rep is I don't think they would do that. Their ecosystem revolves on tools and platforms to keep the windows and Office (and SQL and sharepoint) the platform of choice for IT/devs. What does

Especially since what it actually does, doesn't seem to match up with what they tell you it does. At least in the simple cases they use for examples.

Citation needed. Care to elaborate?

Grand Central Dispatch has had similar functionality. The key differences being that Await has more concise syntax for the simple cases, but it gets progressively uglier the more complicated your cases become (such as awaiting a group of tasks that can all be done in parallel to each other

You mean likeawait Task.WhenAll(task1, task2, task3); ?You find that too complicated? I am curious how you would make that code simpler in Java, Objective-C or C?

GCD's syntax starts off somewhat ugly

Indeed

..., but doesn't really change as you do more complicated things, partly because the syntax already assumes you probably want to use blocks/lambdas by default so you can spin off 2-3 lines of code that don't really need a full function.

Apart from being verbose and ugly, GCD still does not solve the problem with composability of asynchronous operations. GCD is the equivalent of TPL (Task Parallel Library) in.NET or Futures in Java.

If you look at the lambda examples from Java 8 it looks like the collections API now mimic LINQ.

But still no expression trees and no ad-hoc anonymous types so nothing resembling LINQ to Entities, LINQ to Twitter etc.

Dynamic support in Java is called Invoke Dynamic and available in Java 7.

The dynamic support in Java is in the VM only. You cannot use foreign language objects as first class objects from within Java. Essentially, Javas dynamic support was created to make dynamic languages on the Java VM platform not suck. It is not a Java language feature.

C#s dynamic feature is support for dynamic languages the same way, but also lets you create objects in a foreign language a

Async is (or was) a pretty standard feature in some languages and run time systems and operating systems. Usually it's just a library or operating system you can use, but ya, that's not integrated into the language itself. But consider Ada with asynchronous transfer of control. Erlang has asynchronous stuff, but maybe that looks too much like message passing. Certainly Smalltalk allowed you to have blocks executed asynchronously. Though it all depends upon what your definitions are, it's too easy to say that it's just boring old message passing and it's not really in the language unless there's some special syntax for it.

Async in the context of C# usually refers to async/await [microsoft.com]. If you're familiar with PL concepts, the concise way to describe it is that it takes a sequential algorithm, and rewrites it in continuation-passing style for you, with continuation boundaries explicitly determined by where you put 'await" in your code. E.g. consider this:

You would have more luck with that if you'd actually had some substance in your post. You basically said, "I like.NET better than Java," but didn't explain why.

Specifically I'd like to hear why you think the.NET framework is more robust than Java. Of all the reasons I could think of for supporting.NET over Java, that is not one of them. What makes you say it's robust?

However, I mostly code in C#.NET and I dabble in Java in my spare time to model financial markets. What I have found is that C# has some powerful features that other languages do not have. This allows the.NET framework to be a little more robust than Java. Also my opinion is that C# and.NET creates a more syntactically elegant and coder friendly experience whereas Java is good, but not as good as.NET.
In closing, C#.NET > Java.
Please address.NET hate-responses to/dev/null

I'm not saying its the case here, but often the best framework is the one you know best. Of course that is true for you personally, but its sometimes hard to distinguish "I'm not sure how to do it with that API" to "that API is not as clear as the one I know well".

Java is actually not "entirely OOP based" although it's close enough for most purposes. Example:

17.ToString()works in C#. It (or the eqivalent 17.toString()) does not work in Java.

In.NET, everything is an object. "int" is another name for Int32, which is a struct (stack-allocated, value-passed object) that inherits from Object and implements a number of interfaces (IComparable, etc.).

No, Java allows you to declare arrays of arrays - also called "jagged" arrays because not every "sub-array" need to have the same length (you can assign different arrays after initialization). Arrys of arrays are not multidimensional arrays, however.

C# allow you to declare both "jagged" arrays of arrays as well as true multidimensional arrays.

In some (limited) situations the true multidimensional arrays will slightly outperform jagged arrays. This happens if you mostly access random cells of the array. In t

Or Iff in VB. That is the beauty of.Net built in support for a variety of languages. I've had at times used C# FOSS controls in VB projects and vs versa. You're knowledge of the platform transfers ridiculously quickly. We still don't get cross language projects but it is just a matter of picking the pieces to put in which libraries well and a old VB hack can work alongside someone using C# or whatever.

Distint signed and unsigned variants of all integer types (handy for interop with native code, and occasionally for other things), "using" blocks (forces an object to be cleaned up when it goes out of scope, instead of whenever the garbage collector gets around to noticing that it's out of scope), destructors (no, Java finalize() does *not* count), lambdas (and delegates in general; the closest thing Java has to a simple function pointer is ridiculously verbose), LINQ or anything like it, better generics th

C# was the direct result of MS being blocked from using Java, and was their J# product re-branded into.net. The core is nearly identical with the exception that C# has access to things like DirectX, and a few other nice to have APIs from MS

MS's extensions were to make it easier to access system code without having to go through the typical hurdles you do in Java (JNI is a little bitch). That said it was a violation of the Java specification. When MS created C#, as a language there were specific ties to support "unsafe" execution (direct access to pointers, and lower-level system structures), as well as C-style library interfaces via easy [DllImport] declarations and via direct PInvoke statements. IMHO this is the single biggest advantage t

C# does not appear to have 40 Critical bug fixes every quarter like Java does either.

Sure they do [lmgtfy.com]. The flaws aren't in the language (with Java or Silverlight), after all, if you're running a program on your local machine in either of those languages, they're designed to give you access to the filesystem, etc. the flaw in the idea of trying to run foreign code on a local sandbox. Good luck.

95% of those java bugs are for the browser plugin. Last time I checked, activeX didnt have a great track record either. They both find about the same amount of server issues..Net just sells their extra vulnerabilities to the NSA rather than fixing them.

No they are not. They are all over the runtime and library: Libraries, Hotspot, JavaFX, AWT (many), 2D, serialization, reflection, JAXP, RMI, beans, JAX-WS, etc etc. They are amplified by the fact that many of them are indeed in a library/feature that can be accessed through applets from remote. But the vast majority of the vulnerabilities exists isolated from the applet and could be exploited through other channels.

ActiveX has nothing to do with.NET.

And even so, there has been precious few vulnerabilities in ActiveX. The problem with ActiveX was that the model allowed foreign code to execute non-sandboxed on your machine, so that a bug in a control could have (and had) dire consequences. In that regard, ActiveX resembles SUID on *nix: You check at the gate and if the subject appears to have legitimate papers you let him in and assume that he'll be well-behaved. Just like with SUID where a bug in a SUID root tool may lead to system compromise, a bug in an ActiveX control could let the attacker run his own code with your credentials.

As they are the harbingers of the new age, post dotcom world, where overspecced hardware fixes everything, where there are legions of entitled douchebag "developers" who took a certification course, and of apps which can't run in less than 8GB of memory (our resident BOFH hung up on our developers when they asked for a 64GB VM because they kept getting OOM errors in Java).

In short, both languages rode the crest of the cultural revolution where it is now OK to suck, to offshore code development with no expectation of quality coming back, of "agile" methods where your next version is always going to be the stable one. I'm not exactly saying that these languages CAUSED any of this, but there is at least a temporal correlation.

Let me say that it is easy to create GREAT systems in Java (and I assume in C#/.NET). However, in enterprise world, that seldom happens. That is not because of languages, but because of several management related issues:

1. Technical excelence is rarely seen as a goal, implementing features is.
2. Technical fixes do not drive development, satisfying business requirements does.
3. Things are rarely if ever refactored, consolidated or tidied up, as business doe

yeah, RAM is expensive - especially when your server will only stack a fixed number of sticks in there, and its being shared with several other teams. (and before you say "buy another server", you have to consider the up-front cost of it, plus the maintenance contract with the supplier plus the electricity to power it and the aircon - and electricity certainly isn't cheap nowadays, especially when you go down that road, because next thing you know, each team will want their own, and then some will want 2 or

Properties as they are now in C# are a great idea - you don't need a private member variable backing them. They're now just member variables with the option to have different access control for reading an writing (e.g., public get, private set) and the option to hook in some code on get or set on those rare occasions when you need to. It just needs to evolve a bit further now to eliminate the distinction between members and properties and we're set.

The distinction is rather important. A property is a semantic construct. It has a meaning. A member is an implementation detail.

Its the same with Events and Delegates. While they do have some technical differences, the main difference is a semantic one. An event is a semantic way to interface with an object. A delegate is an lower level construct often, but not always, used in the implementation of an event.

...LINQ (as in LINQ to objects, LINQ to Entities, LINQ to XML - all part of the core framework)...

This is my biggest gripe with TFA: He says "the data access APIs are complete, and you can effectively accomplish the same thing". Sure, you could, with only a slightly smaller amount of code than accomplishing the code in C. The ability to both filter data and synthesize new records through combination easily, even as a feature of the standard library, is powerful. That it is a syntactic feature is amazing on the order of Perl making regular expression literals a thing. Java has absolutely no construct th

Async/await are language extensions that allow you to write asynchronous code as if it were synchronous. Note how it is NOT about parallel/threads (although that is also a use case) but a much more fundamental concept of asynchronicity. As such you can compose asynchronous calls with branches, loops, try-catch blocks etc. Without such language support you will have to rely on futures/promises that are implemented in separate methods. Thus, you cannot easily loop over such futures/promises a

But your comment over the wieldiness of one over the other baffles me. Fundamentally, Java's futures should operate in the exact same way as C#'s version with the same caveats. Do you know any real world example to help clear up this dissonance?

Once again, its part of the standard library without needing to change the language's syntax

"Generator methods"I'm assuming you're talking about re-implementing common framework service implementations, and if so Java has a ton of non-standard techniques to do this that most developers work with. It'd be nice if they were more consistent of the implementation though.

No, I'm talking about the ability to create methods that use the yield return and yield break syntax to implement infinite sequences or just allow me to yield items of a sequence and allow the consumer to process each item as it is produced rather than creating the entire sequence before returning.

Well, looking it over, it does save on either performance or writing extra boiler plate to create an interator that stores loop processing state itself, but it seems like something that I'd use very sparingly, or more likely end up implementing it in different ways anyways. Leaving the code as such seems finnicky to me considering that either the inner or outer blocks could mutate the control flow (Like iterating over a list while adding/removing entries from it as a side-effect).

You can and its rather frequent in C# to have them. Not too different from using an iterator within an iterator. Common, basic stuff. The yield operator is just syntax sugar to easily create iterators. They're used roughly for the same thing, but are closer to their semantic idea.

Since C# has quite a few functional constructs, having an easy way to create an iterator/generator is critical to keep the code clean, as they're used all over the place. In LINQ, they're basically in every methods.

I use both, and I find that.NET really shines when you're in unfamiliar territory and working with a part of the framework that you don't touch every day. Features are more easily discovered and idioms tend to be more consistently applied in.NET, whereas it feels like Java suffers from implementers applying the pattern du jour, forcing you to wade through more docs.

I attribute much of.NET's success in this regard to the absolutely awesome book "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable.NET Libraries," which includes a lot of direct insights from the designers of the framework. Microsoft has been really good about sticking to those guidelines, and it shows.

I agree with your comment but it really sucks when you have to wade through.NET docs. It is easy to track down the API documentation for Java and get examples. In.net you have to spend a half an hour on google to get a simple sample code snippet. Ask a question on stackoverthrow and get flamed about your question. "Is this Winforms, WPF, ASP---what are you using!" Winforms. "Winforms sucks why the hell are you using that?" "What language?" VB.NET. "Why can't you use C#?"

it has specifically licensing it to the public and has the capacity to shutdown Mono at any time.

*sigh* unfortunately this comment is going to attract a lot of MS chills repeating ad nauseam phrases like "community promise" and "estoppel".

You are obviously aware of it, so why do you continue to spread this FUD? I find it especially ironic in a discussion about comparison between Java and C#, where only one of the vendors have actually tried to sue. And it is not Microsoft.

The history with the community promise is that first Microsoft submitted C# and the core libraries to ECMA and ISO for standardization. In doing so Microsoft committed to offer license for any patents essential to implementation under RAND terms (Reasonable And Non Discrimi

The business doesn't really care, but who else has puked in their own mouth watching a Windows admin work? I'm so sick of even talking to these dumb fucks that I loath the IT department because of them.

Um, as someone who is somewhat (but not only somewhat) familiar with generics in both systems, I don't see anything in TFA's explanation which is misleading or incorrect, nor contradicted by your link. Care to elaborate on what you mean?

I can help. The author claims this:

Java, however, uses a method called type erasure. Essentially, the type checking only happens at compile time. The actual container types internally could still hold any type, but the compiler explicitly stops you from attempting to put other types into the containers.

That is wrong. In Java, type checking happens at *runtime*. During the type erasure the compiler will add downcasts into the code which will be evaluated at runtime. When a collection has been declared with i

You're right, the article does a pretty accurate reflection of the realities of both systems. I'd love to have runtime generics to work with under very rare conditions, but just as the article mentioned, there are workarounds that lead to slightly less elegant code to do so. Mind you, this is generally only a problem for generalized frameworks more so than day coding tasks, but its still a nice to have.