| ActiveMac | Anonymous | Create a User | Reviews | News | Forums | Advertise |
|
|
|
User Controls |
|
New User |
|
Login |
|
Edit/View My Profile |
|
|
|
|
|
|
|
ActiveMac |
|
Articles |
|
Forums |
|
Links |
|
News |
|
News Search |
|
Reviews |
|
|
|
|
|
|
|
News Centers |
|
Windows/Microsoft |
|
DVD |
|
ActiveHardware |
|
Xbox |
|
MaINTosh |
|
News Search |
|
|
|
|
|
|
|
ANet Chats |
|
The Lobby |
|
Special Events Room |
|
Developer's Lounge |
|
XBox Chat |
|
|
|
|
|
|
|
FAQ's |
|
Windows 98/98 SE |
|
Windows 2000 |
|
Windows Me |
|
Windows "Whistler" XP |
|
Windows CE |
|
Internet Explorer 6 |
|
Internet Explorer 5 |
|
Xbox |
|
DirectX |
|
DVD's |
|
|
|
|
|
|
|
TopTechTips |
|
Registry Tips |
|
Windows 95/98 |
|
Windows 2000 |
|
Internet Explorer 4 |
|
Internet Explorer 5 |
|
Windows NT Tips |
|
Program Tips |
|
Easter Eggs |
|
Hardware |
|
DVD |
|
|
|
|
|
|
|
Latest Reviews |
|
Applications |
|
Microsoft Windows XP Professional |
|
Norton SystemWorks 2002 |
|
|
|
Hardware |
|
Intel Personal Audio Player 3000 |
|
Microsoft Wireless IntelliMouse Explorer |
|
|
|
|
|
|
|
Site News/Info |
|
About This Site |
|
Affiliates |
|
ANet Forums |
|
Contact Us |
|
Default Home Page |
|
Link To Us |
|
Links |
|
Member Pages |
|
Site Search |
|
Awards |
|
|
|
|
|
|
|
Credits |
 |
Desktop Battle Swirls Around Java | |
|
||
| Time: 09:51 EST/14:51 GMT | News Source: CRN | Posted By: Robert Stein | ||
|
Behind such programs and more is the very technology at the center of an intense battle between Microsoft and Sun Microsystems over control of desktop computers. Though Sun has mostly lost that fight, the beleaguered Silicon Valley icon is trying to give new life to its Java programming language with an aggressive push into mobile devices. Once again, it finds a foe in Microsoft. But this time Sun has the lead. | ||
|
Write Comment
Return to News |
Displaying 1 through 25 of 167 Last | Next |
The time now is
6:32:18 AM
ET.
Any comment problems? E-mail us |
| #1 By 7390 (198.246.16.251) at 7/14/2003 10:29:38 AM |
| umm..what battle? I thought that this was decided years ago and that Java was banished to the server? |
| #2 By 14326 (216.75.223.70) at 7/14/2003 11:37:28 AM |
|
RedHook
It appears that Java has also been 'banished' to 94 million phones. |
| #3 By 1124 (165.170.128.66) at 7/14/2003 12:02:37 PM |
|
CooCooCaChoo,
What do you mean by "mature" when talking about managed code?(Better OS support, better language, better frameworks, or just more usage by programmers and users) The incentives over native code(BTW managed code compiles to native code) is productivity. |
| #4 By 2332 (216.41.45.78) at 7/14/2003 1:12:46 PM |
|
Managed code is the future. It's as simple as that. In the near future 100% of all code running on a machine (with some small exceptions) will be managed. Certainly all full fledged application (yes, including games) will be managed.
The question is, is it the present? I think so, but it's certainly arguable. |
| #5 By 2332 (216.41.45.78) at 7/14/2003 7:01:17 PM |
|
#7 - "the incentives to write in a compiled language is a better thing produced in the end"
Why do you say that? Why is a program written in C better than a program written in C#? "And I disagree that managed code makes anything more productive. That's the IDE, not the nature of the managed code." Well, the IDE certainly is a big factor, but would you not agree that not having to worry about stupid things like memory management makes you more productive? If you and I both write a complicated application, you in C++, me in C#, I can almost certainly create the same application in far fewer lines of code - a big part of that are the services that managed runtimes provide, like memory management. "people have the audacity to claim you don't have to worry about things like memory management" For the most part, you don't. Obviously, you still need to worry about unmanaged resources, but you rarely need to worry about memory. Microsoft's generational garbage collector is almost certainly better than anything you or I could ever write on our own. One thing managed programmers accept (usually) is that the runtime knows better for certain things, and memory management is one of them. "you get WORSE problems from people that refuse to think about the fundamentals of what they are doing." Ah yes, the old "but if it's easy, the dumb people will be able to do it!" Come on. Let's not be that insecure about our jobs. I agree fundamentals are important, but the same argument could be made (and was!) by assembly programmers regarding C programmers. As far as I'm concerned, the more plumbing that's abstracted away from me, the better. "But the IMPORTANT things will still be compiled code where the Software Engineer does the managing, instead of being managed by the code." Would you consider ASP.NET important? It performs FAR better than ASP, and many other older web applications platforms. Guess what, it's written 100% in C#. As I'm sure you know (but for some reason don't want to accept), managed code can run just as fast, if not faster, than unmanaged code. It all depends on the circumstances. "When you make a Java program, you are not in fact making a java program... you are configuring the VM. You are doing nothing but configuring the real program, the VM, to do something for you. So you are STUCK with a one-program-that-does-everything under the sun." Talk about an over simplification. You're not simply configuring a VM, any more than assembly "configures" a processor. Especially in the case of .NET and the CLR, where all code is JIT'd into machine code before it's run. "Bright ideas:!:!:!: Let the hardware engineers design the machines and if you want to do software engineering, learn how to do it right! Don't cry about pointers, just learn, or do something else with your time." Ahh, another elitist unmanaged coder. Guess what: your days are numbered. I programmed C++ for several years, and yet I still like the managed world better. Imagine that. It's actually possibly for somebody to be smart, and prefer to take advantage of a managed runtime. "Managed code is not the future, the future is an OS that can manage processes effectively." You keep thinking that. I'll throw you a quarter while you're in the unemployment line. |
| #6 By 12071 (203.185.215.149) at 7/14/2003 8:19:06 PM |
|
#8 Whilst you're specifically asking cba, I'll throw my 2cents in =)
"Why do you say that? Why is a program written in C better than a program written in C#?" If you define better as faster for instance than C is much better than C++ and even better than C#. A C program can also do things that you cannot, e.g. 'inline assembler'. Sure you may not want it or need it, we're not arguing that, I'd just rather have a complex codec written in C with assembler than wait 4 times as long for your managed C# code to finish encoding my video. "I can almost certainly create the same application in far fewer lines of code" Lines of code don't actually mean anything... you do realise that don't you? Hell I can write all my programs in a single line of code if I want - sure it'll be a LONG line, but it will just be a single line! I agree here with cba that the IDE does far more for productivity than managed code. |
| #7 By 2459 (69.22.78.116) at 7/14/2003 10:27:19 PM |
|
"Managed code is not the future, the future is an OS that can manage processes effectively."
Actually, both of these are the furture, as far as MS is concerned anyway. For Longhorn and its successors (and even for MS' mobile and embedded OSes in time), the majority of support is towards managed APIs. The apps included with Longhorn, the next Office suite (after Office 2003), browser, etc., are going to be managed. The kernel, drivers, and other low-level code will remain C++ in Longhorn, but eventually move to managed code as well. "I'd just rather have a complex codec written in C with assembler than wait 4 times as long for your managed C# code to finish encoding my video." As RMD said, in many cases managed code can be just as fast, if not faster, than unmanaged code. What makes you think that your encoder will run 4 times faster just by writing in C and assembly? It'd probably take more time for you to code and tune your assembly, and you could still get beaten by someone that did their encoder done in C++. This situation is similar to the argument of .NET code versus unmanaged code. Just as a good C++ compiler/coder may be able to optimize code better and in less time than someone hand-tuning assembly, .NET can potentially optimize code better than someone using unmanaged runtimes, particularly because the code is always compiled to native code before runtime, and it can take advantage of the exact system the end-user is running, rather than the one the coder is running. The .NET code is also likely to be less buggy and more secure due to the runtime's safeguards. |
| #8 By 135 (208.50.204.91) at 7/14/2003 11:37:19 PM |
|
kabuki -
"I can almost certainly create the same application in far fewer lines of code" Lines of code don't actually mean anything... you do realise that don't you? He's not arguing LOC as a means of productivity. He's arguing that fewer lines means things are easier to do, that there is less chance for error in functionality... that the programmer is more efficient. Hell I can write all my programs in a single line of code if I want - sure it'll be a LONG line, but it will just be a single line! And unreadable, which misses the point RMD made. I agree here with cba that the IDE does far more for productivity than managed code. Says someone who has obviously not worked with .NET. I'm an old C developer, and there's no way I'd go back to that crap way of development. C# frees me from worry about the tedious. Hmm, sort of like the way Windows enhances my productivity compared to Unix. Ahh, now I see why you still want to use C, you still believe doing everything the hard way is better. :( |
| #9 By 12071 (203.185.215.149) at 7/15/2003 12:41:08 AM |
|
#10 And the key words are "can be". I know all about the advantages of JIT compilers and hence why managed code *can be* as fast and in fact faster than unmanaged code. But that's still a "can be" issue.
#11 Maybe RMD wasn't arguing that LOC are a measure of productivity - then again he was talking about productivity and he did make a reference to the fact that it would be shorter (i.e. he would be more productive) if he wrote it in C#. If the programmer is more efficient as you say, wouldn't this mean that he could therefore be more productive? "And unreadable, which misses the point RMD made" RMD never made a point in regards to readability of code. He was talking about productivity. "Says someone who has obviously not worked with .NET." See if you read some of my previous comments you would know full well that I do a reasonable portion of development in C# using VS2003 - and VS2003 does far more for my productivity than C# does. "I'm an old C developer" Since you made guesses about me, I'll make a few about you. I doubt you're old, let alone an old C programmer, and honestly it doesn't make a difference either way - you could really be just a VB programmer - it would not suprise me in the least! "Ahh, now I see why you still want to use C, you still believe doing everything the hard way is better. :(" No, I just see the benefits of C and can determine what it is and what it is not useful for. Whilst most of my development is currently with Java and C#, I wouldn't use either to write a video codec for instance. You may and good luck to you and all your clients! |
| #10 By 2332 (65.221.182.2) at 7/15/2003 10:13:57 AM |
|
#9 - "I'd just rather have a complex that you cannot, e.g. 'inline assembler'."
Not only can I have inline assembly in a C# program, I can have inline assembler in a VB6 program. It's called a byte array. Load it up with assembly, and point a system callback function at it. Done. Just be sure to mark your method as unsafe in C#. It's interesting you picked one of the two things I could think of that most people don't think you can do in .NET. One of those two things, multiple inheritance, you really can't do in .NET. "I'd just rather have a complex codec written in C with assembler than wait 4 times as long for your managed C# code to finish encoding my video." Why do you think it would take 4 times longer to encode video in C# than in C? Again, if you really want asm, you can use asm. It's not an issue. But if you're using asm, you're not using C, now are you? That would seem to suggest not a unmanaged vs. managed issue, but a low level versus high level issue. That's a valid point, but, again, a different point. "Hell I can write all my programs in a single line of code if I want - sure it'll be a LONG line, but it will just be a single line!" Yawn. You know what I meant. If you feel you need to be silly to dodge the point, then fine. In general, you can equate normal lines of code with productivity because the fewer lines you have to write to get the same job done, the more productive you are. "I wouldn't use either to write a video codec for instance" I would. Not only that, but I'm willing to be that while it may not have the raw speed of an codec written in asm, I'll be able to finish it long before you will. If it still gets the job done on the target machines, then guess who will get the job and guess who won't? It's not always a question of raw speed. It's a question of how fast is fast enough? In those circumstances where C# isn't as fast as C, you need to consider whether or not it's still fast enough for the job at hand. More often than not, it will be. This post was edited by RMD on Tuesday, July 15, 2003 at 10:14. |
| #11 By 2332 (216.41.45.78) at 7/15/2003 4:08:59 PM |
|
To illustrate my point:
http://www.vertigosoftware.com/Quake2.htm A quote: "In July 2003, Vertigo Software, Inc. is releasing Quake II .NET, a port of the C-language based engine to Visual C++ with a .NET managed heads-up display. We did this to illustrate a point: one can easily port a large amount of C code to C++, and then run the whole application as a managed .NET application using the Microsoft Common Language Runtime (CLR) without noticeable performance delays. Once running as a .NET managed application, adding new features is easy and fun." |
| #12 By 16451 (63.227.226.13) at 7/15/2003 4:32:13 PM |
|
What impresses me is how they stand behind their work.
We welcome your comments (quake2@vertigosoftware.com), but regret there is zero support, i.e., we can’t help you with setup issues, video card drivers, or how to defeat the bad guys on level 4. |
| #13 By 2459 (69.22.78.116) at 7/15/2003 8:18:40 PM |
|
Interesting, thanks RMD:
Run the native version of Quake II .NET. The main points are: • This is the native version of the port. • The Quake C code was ported to C++ using Microsoft® Visual C++® .NET 2003. • It took around 4 days to port. Run the managed version Run the managed version of Quake II .NET. The main points are: • This is the managed version of the port; this version runs in the .NET Framework. • Now have the flexibility to mix native and managed code: use garbage collection, .NET Framework classes, etc. • It took around 2 days to port the native version to the managed version. How is the performance of the managed version? Initially, the managed version was faster than the native version when the default processor optimization setting /G5 (Pentium) was used. Changing the optimization setting to /G7 (Pentium 4 and Above) created a native version that runs around 15% faster then the managed version. "What impresses me is how they stand behind their work." RH7.3, this isn't a commercial product. It's more of a proof of concept and guide for developers. I wouldn't be surprised if the project was commissioned by Microsoft since Vertigo has done sample projects like this for them before. |
| #14 By 16451 (65.19.16.18) at 7/15/2003 9:36:44 PM |
| I know what it is, and what it is not; thank you very much. From Vertigo's whitepaper: Running Quake II.NET in the timedemo test indicates the managed version performs about 85% as fast as the native version. |
| #15 By 2459 (69.22.78.116) at 7/16/2003 10:32:56 PM |
|
"Running Quake II.NET in the timedemo test indicates the managed version performs about 85% as fast as the native version."
That's a different way of saying the same thing I quoted above: ----------------- How is the performance of the managed version? Initially, the managed version was faster than the native version when the default processor optimization setting /G5 (Pentium) was used. Changing the optimization setting to /G7 (Pentium 4 and Above) created a native version that runs around 15% faster then the managed version. ---------------- What's your point? |
| #16 By 2459 (69.22.78.116) at 7/16/2003 10:35:33 PM |
|
BTW, "native" (Vertigo's use) really isn't the best term to use here since both the managed and unmanaged versions are compiled to native code. This post was edited by n4cer on Thursday, July 17, 2003 at 01:13. |
|
Write Comment
Return to News |
Displaying 1 through 25 of 167 Last | Next |
The time now is
6:32:18 AM
ET.
Any comment problems? E-mail us |
