mikegoes101
Weaksauce
- Joined
- Jan 20, 2010
- Messages
- 71
I have learned Java in School and .Net at work. Hands down I perfer .Net but what are your thoughts?
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
C# has better documentation. VB.NET is still the same horror VB6 was and to be avoided at all cost. Java as a language is lacking. I program mostly C++ professionally and the incredibly high-level approach taken in Java combined with its lacking implementation of OO makes for a rather painful experience. C# is much more to my liking in that regard.
.Net as a runtime doesn't really offer many benefits over running native, because you lose the ability to go cross-platform (the OSS Linux implementation isn't 100% compatible) and managed code can lead you into even worse minefields than regular unmanaged code, mostly because you can't see WTF it's doing behind the scenes. The Java VM has the same managed vs unmanaged issues, but as a VM it wins because it's cross-platform (any noticeable platform), very efficient and can run more than just Java (which the .NET runtime can do too, of course).
In the end most applications are still programmed in C/C++
.NET
Is Java even being widely used anymore?
C# has better documentation. VB.NET is still the same horror VB6 was and to be avoided at all cost. Java as a language is lacking. I program mostly C++ professionally and the incredibly high-level approach taken in Java combined with its lacking implementation of OO makes for a rather painful experience. C# is much more to my liking in that regard.
Out of curiousity, what is Java lacking in OO implementation? Only know Java atm but I know it fairly well at this point. From the little I looked at c#, it looked similiar with the exception of being able to create seperate scopes pretty much anywhere and the whole struct thing. Oh, is it that java can only pass parameters by value? Dont know how that would fall into OO though.
If you mean anonymous methods, Java can do that too. In my experience, however, C# has the better programming conventions, and is just nicer to use than Java. I could do with either, but I hope in the long run, the most elegant language wins out (which currently is C#).
Oh, is it that java can only pass parameters by value
C# has better documentation. VB.NET is still the same horror VB6 was and to be avoided at all cost.
Ignore any comments along the lines of "avoid VB.Net like the plague"; VB.Net is not VB6, both VB.Net and C#.Net go through the same CLR into MSIL, and (generally speaking) are only syntactical differences between C#.Net and VB.Net. There's a book I've mentioned before that highlights the more niche difference, but that is starting to show a little age as the C# and VB teams at MS tighten up things more and more.
Parameters in Java are all pass-by-reference. Primitives are immutable as are Strings.
If you're a C++ programmer though, C# will be more akin to what you've done before, I think. VB .NET has always looked a little funky to me.
Restraint.Out of curiousity, what is Java lacking in OO implementation?
I'll conceed to the point that most apps still rely on C/C++ just look at vista. But compare Vista to Win7 and you see the power that .Net can bring
Win7 and Vista are both written primarily in C++, and comparing them doesn't teach us anything about Java or C#.
It's one of the major themes in my current data structures class that java only has pass by value
You are correct and devman is incorrect -- Java is completely pass-by-value. However, it passes references by value (for non-primitives), so as long as you don't change the Object that the parameter points at, you're changing the original Object.
However, if you set the parameter to a new Object, then it is now pointing at a completely different Object than the original, and from that point on, nothing you do to the parameter will affect the original.
Thank you for the correction, Java is indeed pass references by value, I was mistaken.
Restraint.
Win7 and Vista are both written primarily in C++, and comparing them doesn't teach us anything about Java or C#.
By "restraint", I mean the lack of restraint in the oopaholic design of the Java libraries.
By "restraint", I mean the lack of restraint in the oopaholic design of the Java libraries.
Control Panel in Win7 is a native application. It's possible to write a control panel applet that is managed, but I don't think any of the system-provided ones are. The Windows' team problems with managed code have been pretty well documented.
Which also doesn't tell us anything, either. For example, my team re-wrote one of the tools that ships in SQL Server in C# from C++. It's one of my most regrettable technical decisions; performance is terrible. Decisions about platform are made at companies like Microsoft for political and schedule reasons far more often than they are for technical reasons. That is, you can't assume that the application of a certain technology is an endorsement of its merit.I was thinking more of the some of the configuration tools controls, such as the hyper-v wizard, ipsec policy manager, etc (which I just checked - they're managed). I don't think any of the core OS is managed code (especially not in my area - graphics drivers), but a number of the tools are moving that direction.
citation needed
http://blogs.techrepublic.com.com/programming-and-development/?p=553 is one decent explanation of the issue. Another is the poor performance of the Java runtime. There are simply too many layers of OO crap to get work done; immutable strings are a symptom of this design problem. The same thing is true of the .NET framework; pretty close, but not quite as bad.
Which also doesn't tell us anything, either. For example, my team re-wrote one of the tools that ships in SQL Server in C# from C++. It's one of my most regrettable technical decisions; performance is terrible. Decisions about platform are made at companies like Microsoft for political and schedule reasons far more often than they are for technical reasons. That is, you can't assume that the application of a certain technology is an endorsement of its merit.
For Mobile Applications on multiple platforms Java definitely has its importance however many new techs backed by android etc will make Suns Java less of a mainstay.
I couldn't disagree more. Microsoft has pushed on about developer productivity in C#, and I just don't agree that it's real. For trivial apps, sure; you can slap something together pretty quick. For quality, commercial software, though, you've got to spend the time you've saved in the development cycle cleaning up other problems. A more complicated installer, for example; localization problems, perf issues, and so on.though there's definitely something to be said for the ability of C# and similar to help you make those tight schedules.
There are situations when that's true. It's surprising those situations would come about in a company with 90,000 people and two to five years between product releases.That is, sometimes (often, even), the ability for a certain technology to meet your needs in the timeliest manner may outweigh the need to meet your needs in the most computing-speed-efficient, a trade-off you're well aware of.
I don't think the issues you notice are related only to low-level interop, but it's certainly one of the big areas of concern. The cost of leaving the confines of .NET are very high, but frequently necessary.Of course, I say that while writing this c++ framework for testing certain plug and play capabilities and correct performance of graphics drivers, one of those areas where using C# would actually slow me down a ton both in work and code efficiency - I'd spend more time working with p/invoke than I would actually implementing logic >.<
I couldn't disagree more. Microsoft has pushed on about developer productivity in C#, and I just don't agree that it's real. For trivial apps, sure; you can slap something together pretty quick. For quality, commercial software, though, you've got to spend the time you've saved in the development cycle cleaning up other problems. A more complicated installer, for example; localization problems, perf issues, and so on.
Hurry up and wait.There are situations when that's true. It's surprising those situations would come about in a company with 90,000 people and two to five years between product releases.