Actually, one more thing (huge if you are working on a modular project). When dynamically loading a library in C# vs. Java - it seems that the Java API is a bit nicer (one of few cases), however the path lookup seems to be much more painful to deal with. At this point, I'd give them parity. I'll need someone to confirm .NET is better in this next regard:
In Java - If you want to unload a java module you've dynamically loaded runtime, you need to get rid of all references to the loaded module and hope the GC has decided to delete it. If you do not, or the GC has not, then when you request the module be loaded again, it will pull the old loaded module (not good if you've updated it since the first load). .NET doesn't have this issue, does it? Java appears to have 3rd party modules to help with this, but from what I've read, they aren't a sure thing. Thanks, -Jim Stapleton -----Original Message----- From: Stapleton, Steven J. Sent: Wednesday, April 06, 2011 7:52 AM To: 'Alex'; [email protected] Subject: RE: [Mono-list] Need Business Case for Mono Regarding #1, if the 'trick question' is meant to suggest Java lacks closures, you are incorrect. Mind you, the syntax for Java closures is asinine and excessively verbose/clunky at best, C# is MUCH more elegant. On the verbose/clunky side of things, there's a large number of things you might want to do with Java in relation to File IO or Date/Time, many of which are reasonable to do at the same time. Unfortunately, each uses slightly different parts of the API, in my experience, this has lead to the necessity of having a lot of extra code to do something you've already done. The .NET framework seems much more cohesive, allowing for less code baggage. Sorry, I have to program Java for my job, so any chance I get to say why C# is better, I usually take. I'd also like to add that C# has properties, which can make programming nice (although, used improperly, can slow it down, because you may forget they have overhead closer to a function call than member variable access). This is minor, and probably not worth mentioning in a business case. Also, I'll add a #6) p/Invoke is a lot simpler than the Java method for native code access, as far as I can tell, while still granting the programmer a lot of flexibility. Note: This doesn't reduce cross platform compatibility as much as you might think - many C/C++ libraries are available across many platforms, allowing you to use the same call, so long if they are compile with a calling convention that .NET can use. You'll need to specify your library without '.dll' or '.so', and then your assemblies configuration .xml file will need to have a special case for Macs, and if you compiled in VS 2010, you'll need to add a translation, because it automatically adds the '.dll' it seems. Google "Mono PInvoke" and you should find all of this stuff in good detail. -Jim Stapleton -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alex Sent: Wednesday, April 06, 2011 3:20 AM To: [email protected] Subject: Re: [Mono-list] Need Business Case for Mono Hi, 1) C# is a more evolving language (than Java), actively maintained and pushed by Microsoft, Novell, and other companies. It continues to get new features that people actually /need/. (As an example, how long did it take for Java to get closures? (trick question)). C++(0x) is actually also pretty evolving, so in this area, I'd say Java is the loser :). 2) It has a much richer standard library than any of the two alternatives. 3) Compared to C++, both Java and C# would be superior due to the simple fact that they're managed languages; such languages come with lots of benefits that native code will not give you (GC, proper exceptions on null refs, array bounds checks, no use of uninitialized variables, etc...). This highly boosts productivity and maintainability, and helps reduce bugs caused by programming errors. See also http://en.wikipedia.org/wiki/Managed_code. 4) In many language features, C# and the CLI are more architecturally complete than both C++ and Java. This of course brings benefits in that little to no design mistakes have been made in the language (in reality, of course C# has a few mistakes too; but they're hardly comparable to Java generics or C++ multiple inheritance...). 5) C# is _truly_ portable. While C++ code may compile on any platform, you can't run the compiled code on other platforms than the one you compiled it on. You can compile C# and run it anywhere. (Many more arguments exist, but these should by far be enough...) Of course, there's a great deal of bias in all of these :), but I'm sure the arguments will serve you well anyhow... Regards, Alex 2011/4/6 Computerizer <[email protected]>: > Hey all, > > I'm working on researching a potential server-type project that needs to be > multi-platform (Windows, Linux, Solaris). It'll have UI (probably be web > based) and do a lot of network-protocol stuff (like FTP, for example). The > research team is trying to decide between using native C++, Java, and C# for > implementing this. > > Can you give me some great business case arguments for using C# and Mono > instead of Java? I really want to use C# for this one. > > Thanks! > > > -- > View this message in context: > http://mono.1490590.n4.nabble.com/Need-Business-Case-for-Mono-tp3429397p3429397.html > Sent from the Mono - General mailing list archive at Nabble.com. > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 1179559405) is spam: Spam: https://antispam.osu.edu/b.php?i=1179559405&m=3f49376f6970&c=s Not spam: https://antispam.osu.edu/b.php?i=1179559405&m=3f49376f6970&c=n Forget vote: https://antispam.osu.edu/b.php?i=1179559405&m=3f49376f6970&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
