Linked by Eugenia Loli on Mon 19th Sep 2005 17:02 UTC, submitted by Eli M. Dow
Mono Project Build applications for Linux while maintaining cross-platform capabilities using .NET languages.
Permalink for comment 33901
To read all comments associated with this story, please click here.
Managed Code is what we need
by Anonymous on Tue 20th Sep 2005 11:19 UTC
Member since:

Look at all those problems which raise with pointers, malloc and other (mainly C/C++-specific) problems which raise with unmanaged code: buffer over/underflows, weak casting and other bad things which lead to security leaks. Managing the memory manually is a very heavy duty task and no single application (maybe except hello-world-alikes) never somewhere suffered from writing to wrong parts of the memory.

Even best programmers run into problems with memory and code management. Of course, Mono/Java cannot make the code 100% secure against abuses, but it reduces the amount of code you have to maintain to somewhere under 50% of the original C code by taking away memory and code management. I ran into situations where the GC could not get rid of a variable because it thought that it was still referenced - no code is perfect. Manually nilling it helps - but such a situation is very rare compared to random segmentation faults you run into with C or C++ just because the data was of wrong type.

Yes, you cannot replace essential things with managed code. Writing a kernel in c# or java is hardly possible, but if the runtime environment (here I mean mono or java) allows accessing the kernel, then you can do anything you wanted to do low-lvl. Yes, for every task only best suitable tool should be used - and in a lot of cases C isn't the suitable language anymore. Sorry, but you can write to block devices even with brainfuck/fuckfuck, but I doubt you'll do that.

It is the point we should achieve: move the majority of code to managed runtimes and in my eyes to you make more sense to let the kernel, the RE, xorg stay as they are and move everything else [you can] to Mono or Java. That will raise code quality rapidly.

But that means that 96% of the code will have to be rewritten. But hey, a lot of code had to be rewritten from COBOL and Fortral once upon a time, too.

This is the race and Microsoft does everything wrong it can: win32-winforms-avalon - 3 API changes in only several years. That's why .NET hasn't been adopted until now [except by ATI and HP]. The one who manages to move the majority of the code base from unmanaged to managed will rule upcoming 20 years of IT.

And yes, while Java is a very consistent development environment, it is not usable for such a task. GCJ exists with a lot of ambition and GCC is in unmanaged (GCJ has a GC) world is what .NET is in managed. It is a good move from mono's side to support java. And I hope that they will do that good.

Sorry, folks - it still seems that here are unmanaged advocates here who just tell "who can't maintain the memory, he shouldn't begin programming". We are humans and we won't manage memory as the computer does, so let the runtime environment do the job and return back to the UNIX roots: do one job, but do it good (and until now C programming meant two jobs: your task and managing all possible failures)

Reply Score: 1