Managed vs unmanaged code (pass the peace pipe)

[Urwumpe]

Which compiler tutorial? I don't see any tutorial recommending to use this .NET mess that Microsoft introduced as "managed code".

Managed code is for people who can't understand what their own programs do.

 

[Face]

Managed code is for people who can't understand what their own programs do.

Oh wow. Thanks for the compliments...

 

[tblaxland]

Managed code is for people who can't understand what their own programs do.

While it may be true that managed code can help protect such people from the damage they could cause, it does not follow that the corollary is true.

 

[agentgonzo]

Which compiler tutorial? I don't see any tutorial recommending to use this .NET mess that Microsoft introduced as "managed code".

Managed code is for people who can't understand what their own programs do.

Wow, what a sweeping statement. Java code is managed code, and as you are an advocate of Java, do I assume that you (by your own admission) don't understand your own code?

 

[Urwumpe]

While it may be true that managed code can help protect such people from the damage they could cause, it does not follow that the corollary is true.

Sure it is, just invert the direction. Do you need managed code, if you are aware of what your program does?

Managed code just suggests that executing the programs in a VM (which is especially nonsense for Orbiter without a wrapper or proxy) is more secure, as the VM takes the responsibility for your bugs. It encapsulates them inside a virtual machine so they, in theory, don't leak out of the VM.

Of course, if you develop unmanaged and with thinking about your program, you can be as much bug-free. Even more, by the limitations of the VMs, you can actually develop more robust software without VMs (The number of bugs is more than the sum of the bugs in your program and the VM)

I know that I won't make friends among .NET (or Java, to a lower extend) fans with that opinion. But I know that I am dead right with this one.

I have seen far too many people who should have gone through the same lectures as I did, and still react with confusion and fear, if we start to get through their code in a debugging session and I ask them to "Tell me what your program does right now - not what it should do."

After all - what is the difference? Shouldn't code in a program always do, what the programmer intended? In the ideal case yes, in reality not. It requires reflection to understand what you just did. This is especially true if the bug is actually many hundred lines away from where it manifests itself.

And VMs don't change this. You just bow before a new god, who promises to listen to your prayers, but does not promise to fulfill them. Which is the dogma of managed code - it does not do what you tell it to do, but what it thinks is what you really want. And you want it that way.

I don't like my computer to think without my permission.

---------- Post added at 11:22 AM ---------- Previous post was at 11:20 AM ----------

Wow, what a sweeping statement. Java code is managed code, and as you are an advocate of Java, do I assume that you (by your own admission) don't understand your own code?

I am no advocate of Java, I just used it and prefer it over .NET. I am advocate of C++.

I do know that Java does not always do, what I tell it to do, but claims to be smarter than me, when I am not unambiguous.

 

[agentgonzo]

Managed code just suggests that executing the programs in a VM ... is more secure, as the VM takes the responsibility for your bugs.

Absolute and utter bollocks. Managed code does not take responsibility for your bugs, nor does it ensure security. It helps you out by making writing common bugs harder and writing secure code easier, but it is in no way a suggesting more secure or fewer bugs. In no way does it claim to be a silver bullet.

But I know that I am dead right with this one.

No, you have an opinion, and you agree with your opinion. Whether it's right or not is up for debate.

And VMs don't change this. You just bow before a new god, who promises to listen to your prayers, but does not promise to fulfill them. Which is the dogma of managed code - it does not do what you tell it to do, but what it thinks is what you really want. And you want it that way.

VMs never claimed to change this. Computers are stupid and will do what you tell them to do. They don't do 'what they think you meant to do' any differently than unmanaged code will do it. They will execute the lines that you write. If you are referring to stuff like garbage collection happening when the GC wants it to, this is in no way different to native compilers using out-of-order execution or threads being preempted by the kernel.

OP - sorry for the thread hijack.

 

[Urwumpe]

Absolute and utter bollocks. Managed code does not take responsibility for your bugs, nor does it ensure security. It helps you out by making writing common bugs harder and writing secure code easier, but it is in no way a suggesting more secure or fewer bugs. In no way does it claim to be a silver bullet.

The marketing speech sounds different. And so does the talking of the fans of it.

No, you have an opinion, and you agree with your opinion. Whether it's right or not is up for debate.

Then try to prove me wrong. With saying "Managed code is not as managed as it looks" you just support my claim.

 

[Tschachim]

Managed code just suggests that executing the programs in a VM (which is especially nonsense for Orbiter without a wrapper or proxy) is more secure, as the VM takes the responsibility for your bugs.

My life would be a lot easier if a VM takes the responsibility for my bugs, but unfortunately this isn't the case.

The point of a VM isn't a "magic bugfix-o-matic", but platform-independency, hardware abstraction etc.: http://en.wikipedia.org/wiki/Virtual_machine

Cheers
Tschachim

 

[Urwumpe]

The point of a VM isn't a "magic bugfix-o-matic", but platform-independency, hardware abstraction etc.: http://en.wikipedia.org/wiki/Virtual_machine

Yes, that is the classic VM. But you also lately have the doctrine of using VMs for safety reasons, as extension of the classic sandbox model.

 

[Tschachim]

But you also lately have the doctrine of using VMs for safety reasons...

Yes, but this doesn't fix your bugs, but protects other processes from your bugs.

 

[tblaxland]

The point of a VM isn't a "magic bugfix-o-matic", but platform-independency, hardware abstraction etc.:

Yes, that is the classic VM. But you also lately have the doctrine of using VMs for safety reasons, as extension of the classic sandbox model.

So you tar those who use .NET for portability, abstraction, etc, with the same brush as someone who writes sloppy code?

 

[Urwumpe]

So you tar those who use .NET for portability, abstraction, etc, with the same brush as someone who writes sloppy code?

After some thinking about it: Yes.

I thought about excluding portability, but finally, this leads to abstraction, which in turn leads to the problem of getting the VM run properly on the hardware you want to abstract. So, you are limited to either standard hardware, or have to do libraries with native code, which means you then just use the managed code approach for convenience on the application level. You don't want to be bothered with what your program really does. It is enough if it approximately does what it is supposed to do. Instead of implementing the features for convenience in unmanaged code around the libraries and drivers, you build around a VM.

You are again in the hands of the VM to be properly implemented on a different machine and have the libraries and drivers to work with the needed hardware. Just looking at how long it took to make Java work properly and more or less standardized on the same kind of machine under just different operating systems, this is not a small problem.

 

[Artlav]

use .NET for portability

On a side note, i heard a lot about .NET and it's siblings being used to make portable programs, but i never seen a single portable program written in it.
Anyone can provide a non-trivial example?

 

[Tschachim]

You don't want to be bothered with what your program really does.

Well, I can only speak for myself, but I do bother what my program really does, I only don't want to be bothered with the environment it runs in.

... and of course providing a good VM for various platforms is a very big deal.

Cheers
Tschachim

 

[agentgonzo]

On a side note, i heard a lot about .NET and it's siblings being used to make portable programs, but i never seen a single portable program written in it.
Anyone can provide a non-trivial example?

There are the mono team writing the VM for linux based machines. It's been slow, but it's getting there and there are a few things written in the .NET framework that are running on linux. There was something in the tech news the other day about mono being included in (IIRC) Debian to support some document writer application.

But yes, even though .NET applications *should* be portable as they run in a VM, no-one except MS and the mono team has really been bothered to write a VM for their hardware/OS.

 

[Face]

On a side note, i heard a lot about .NET and it's siblings being used to make portable programs, but i never seen a single portable program written in it.
Anyone can provide a non-trivial example?

OMP server. Is this non-trivial by your definition?

BTW: Doing it with C++ and fiddling with different IP interfaces (berkley sockets vs. windows sockets) was absolutely painful. The .NET approach made it absolutely painless.

@Urwumpe: Your comments remember me of the old assembler vs. C++ discussion. No difference in the end. The same arguments.

regards,
Face

 

[agentgonzo]

@Urwumpe: Your comments remember me of the old assembler vs. C++ discussion. No difference in the end. The same arguments.

I was thinking of pointing out the similarities between both comparisons, but figured that it wasn't worth the effort as his mind's made up already.

 

[Face]

I was thinking of pointing out the similarities between both comparisons, but figured that it wasn't worth the effort as his mind's made up already.

While it is OK to have the opinion that it is better to develop in a unmanaged environment, it is not OK to throw out insults putting managed developers and morons into the same basket.

Backing up such insults with spurious arguments why one environment is better than the other is not helping the case, IMHO.

Urwumpe should know better. I don't understand his acting in this case TBH.

regards,
Face

 

[Urwumpe]

@Urwumpe: Your comments remember me of the old assembler vs. C++ discussion. No difference in the end. The same arguments.

If you say so. You must have witnessed them. Or didn't you and are you just repeating the folklore of the Internet?

 

[Face]

If you say so. You must have witnessed them. Or didn't you and are you just repeating the folklore of the Internet?

You are quickly loosing respect points in my book, because this was just another insult...

Yes, I have witnessed many discussions in this bracket. I still know folks that feel superior to C++ developers, because they "know what is going on under the hood". This is just as ridiculous as arguing that .NET developers don't know what their code does. You know... folklore of the Internet .

If such BS comes from a newby or known moron, I wouldn't give a dime... but this coming from you is leaving me speechless.

One advise: don't let M$ hatred get into your logical thinking. I don't have anything more to say in this case...

regards,
Face