Managed vs unmanaged code (pass the peace pipe)

[Urwumpe]

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...

Let me tell you something out of self-reflection: If you know that I am terribly wrong and my words just insulting you (or your self-perception as professional software developer): Why are you only able to resort to polemics and attacking my person, as "BS", "M$ hatred" or "coming from you"? Why can't you show with rational argumentations, why I am so wrong? Why are tl8 and I the only guys in this thread, who try to explain their opinions with reason?

What do you have to loose, if you try to argue reasonable about it?

 

[agentgonzo]

Let me tell you something out of self-reflection: If you know that I am terribly wrong and my words just insulting you (or your self-perception as professional software developer): Why are you only able to resort to polemics and attacking my person, as "BS", "M$ hatred" or "coming from you"? Why can't you show with rational argumentations, why I am so wrong? Why are tl8 and I the only guys in this thread, who try to explain their opinions with reason?

What do you have to loose, if you try to argue reasonable about it?

I think that the point that Face is trying to make is that

Assembler > C++ "because they know what is going on under the hood"

is to equivalent the argument that

C++ > .NET because "Managed code is for people who can't understand what their own programs do".

.
Yes, he didn't offer proof of this and this is his opinion, but tbh it's such a completely stupid premise that both statements are, quite honestly, laughable. Yes, they offer a greater level of abstraction from what is going on but it is done to make your life easier. If you don't trust a managed environment to do what you tell it, then why are you trusting the compiler to do what you tell it in your unmanaged code. You may as well resort to assembler. For that matter, do you trust the operating system to handle the system calls correctly? At some point, you will get rid of some of the computer components and 'write' your program directly onto the chip with a charged needle.

As Face said, arguments that say lower level languages/systems are better and higher level ones are "for people who don't know what they are doing" is proposterous and that's the point he was making. He wasn't attacking you directly, just your opinion in this case. The "coming from you" was actually a compliment (that you seemed to have missed). As with Face, I would assume that newbies or known morons would make stupid comments, but experienced developers I would expect to have a decent knowledge of how computer systems work and offer intelligent comments, rather than wide-sweeping and ill-informed generalisations. We know that you are an experienced developer who knows what he is doing and talking about, which is why it is such a suprise to have you bashing a development system due to a few ill-informed generalisations ("managed code is evil because you don't know what it's doing").

Edit: I'm kind of assuming various things that Face *may* have been thinking/meaning in his post, so apologies if I've got your intentions wrong.

 

[Face]

<snip>

Edit: I'm kind of assuming various things that Face *may* have been thinking/meaning in his post, so apologies if I've got your intentions wrong.

No apologies needed, you got it absolutely right. Thanks for explaining it in detail. BTW: where is tl8's posting? Am I missing something here?

regards,
Face

 

[agentgonzo]

BTW: where is tl8's posting? Am I missing something here?

Yeah, I'd just looked at that too. I can't find any post by tl8 on this thread.

 

[Urwumpe]

Argh, against mixed up tblaxland with tl8...my fault. can't these downunderers use more orthogonal usernames!

Still, I don't want to say ".NET < C++", I said "Managed code ≤ Unmanaged code". And I reasoned why I see it that way. Also I said that "Managed code is for people who don't know what their program is doing", which is not the quite same argument as you had in the "Assembler vs higher languages" debates in the 1960s.

Nobody sane would want to write any complex program in assembler today, and so it was in the past, when the first higher languages appeared. Nobody also wanted to do that anyway. The first high level programming languages are already as old as the first binary computers.

In the assembler vs higher language debate, the argumentation was about the output of the compiler being less effective. Which is true and which nobody denied. It is still that way, despite automatic optimization having gone a long way since. For solving this problem, all better higher languages had an inline assembler expression. You had been able to use hand-made optimized assembler code parallel to slower and badly optimized high-level code. Also, many compiled languages had special keywords to help the compiler optimizing the code (for example register or far call), if you used these properly, the difference between assembler programs and C programs was already very small.

But: For using these keywords properly, you had to know what your program should do in a precise way. You had to be able to tell how the compiler would interpret such instructions. Even worse, not all such instructions had been available on all machines, but precompiler macros allowed to map the desired behavior into the code depending on the machine used.

The "Assembler vs higher languages debate" was in the reality only a loud and polarizing debate between software engineers and part-time developers from other fields. In COBOL, you don't want to know what the program does. You want to write a shakespeare novel you call program, and get the input/output forms on your terminal just like you wanted them to be. You don't want to know what the program does, because for that, you have software engineers who wrote the COBOL compiler for you.

In some sort, such a debate can be summarized as "When the last software engineer is fired, you will notice that economists with year long experience in programming COBOL can't write a COBOL compiler."

Today, you can't even rely on CPUs interpreting your machine code in the order you wrote it and you will also not get accurate cycle times anymore. And it is good that way.

The problems start, when you intentionally give your responsibility about the program away. That is what is wrong with managed code. It is like COBOL. The output looks right, why bother what is happening under the hood? And why is my machine after 7 hours of operation suddenly rebooting? Must be a hardware error, I need better hardware to run my COBOL program.

If you know, what your program is supposed to do, and explain it that way to a managed language compiler like Java, the work is not easier or better than a unmanaged language. IMHO, you even have more work in many situations to ensure the desired behavior against the stupidity of the processes running in the background of a managed program. You have keywords in Java at least, to tell the compiler and the JRE, how it should treat your objects and your program. Not much different to the mapping from C on machine-dependent assembler. But if you don't use them properly, you will create bugs and inefficiencies. If you don't use them, it will be inefficient as well, as the "manager" will resort to a careful default behavior of not assuming too much. For getting effective programs, you need to communicate with the manager - which is just the same like using the standard library functions of a unmanaged program properly. Even the STL of C++ can be hellish fast, if you use the options to tell the STL what you know about the context.

So, you can deduct: If you know what your program should do and what it does according to the code you have written, you have no need for managed code anymore, because you manage your own program already with the managed code processes in the background just being "too many chefs in the kitchen". Either your skills as software engineer or the processes in the background are redundant.

 

[Face]

Still, I don't want to say ".NET < C++", I said "Managed code ≤ Unmanaged code". And I reasoned why I see it that way. Also I said that "Managed code is for people who don't know what their program is doing", which is not the quite same argument as you had in the "Assembler vs higher languages" debates in the 1960s.

Just for the record:

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

"can't understand" is different from "don't know"... You made a generalization about people understanding their programs.
Your generalization fails, because you don't know everyone using managed code good enough to be absolutely sure that he/she can't understand their own programs. If you think you do, you're just arrogant, not reasonable.

What I pointed out above is still one of the arguments in the debates up to today (there was no end to them in the 1960s - there are no "official" "Assembler vs higher languages" debates, anyway). As I said, there are still many folks that think only assembler is the "true" way of coding. It is just the same elitist thinking here.

What you are bringing up are reasons why in your opinion managed code is inferior to unmanaged code, but in no way a "proof" or even a reasonable argument for your generalization above. Even if managed code is inferior to unmanaged code, it does not imply that everyone creating managed applications or using such environments is unable to understand what's going on inside the application.

Or did I misunderstand your original sentence?

regards,
Face

 

[dbeachy1]

The problems start, when you intentionally give your responsibility about the program away. That is what is wrong with managed code. It is like COBOL.

With all due respect, that is patently absurd. Coding in C# or Java does not magically "give your responsibility about the program away." For many applications, managed code is both faster to develop and easier to debug than unmanaged code: that is why virtually all Web applications are written in higher-level languages like .NET, Java, and even PHP. The developer writes the code. The language he chooses to use does not change that responsibility.

IMHO, you even have more work in many situations to ensure the desired behavior against the stupidity of the processes running in the background of a managed program.

I don't understand what that statement means -- what is the "more work to ensure the desired behavior" that a Java or .NET programmer has to do compared to lower-level languages? Memory management is a lot easier in .NET and Java than it is in lower-level languages. Either the program works or it doesn't. If you're talking about a possible bug in the JIT ("Just In Time") compiler that compiles Java or MSIL bytecode to machine code when the program loads, that is no more likely than a possible bug in a C++ compiler: both are possible, but both are unlikely when using modern compilers.

If we can step back "out of the weeds" for a bit, making sweeping generalizations is patently absurd. When a new software project is designed and a language is chosen, a higher-level language like C# or Java is not chosen because "the programmers don't know enough to understand lower-level languages," it's chosen because programs written in higher-level languages are often faster to develop and easier to debug. If you don't need low-level access to the hardware and real-time performance is not the topmost requirement, higher-level languages are often chosen by the development team. That doesn't necessarily mean that "the programmers don't know what's going on under the hood."

 

[Artlav]

Sounds to me it's like comparing a sculptor toolbox with a 3D printer.
Tools have their preferred use, people have their preferred tools.

What is the purpose of this discussion?

 

[Urwumpe]

Brainf##k is the only true way of coding, you know it, I know it. :lol:

I don't think you understand me wrong by syntax, but by semantics, when you say that I overgeneralize. Or that I argue elitist. You just assume the elitist anti-elitist position in the discussion, and thus I must be wrong. The reason is just, that you assume that a single existing programmer, who knows what his program does in managed code, is enough to show that managed code is not just for people who don't understand what their program will do.

But on the same time, I can also show you examples of many other things being used for something else, despite being build for a different purpose. Does that have any impact on the purpose, which is what I am talking about?

There is no IQ check in managed code compilers, which prevent skilled software engineers from using them. But when they do, they limit themselves to the limitations of the managed code.

Which is sure no problem, but it definitely backfires at them, when they start to argue, that managed code is not better or worse than unmanaged code in their eyes. Because then, I can argue, that they either did not look close enough at it, to make a useful observation, or really lack the knowledge of alternatives to notice the difference in practical programming. Because, there are differences. And the differences are not such, that managed and unmanaged programs fill different habitats. The fields of application of managed code are a subset of the fields of application of unmanaged code. unmanaged code can be used on machines or for tasks, which are not available to managed code. And at the same time unmanaged code can do the roles of managed code - no wonder as managed code is just unmanaged code working with the managed code as data. Which means, they are comparable in each task and in the comparison, even if you include effort needed for the programming, the unmanaged code will have advantages - the machine dependent implementation effort for portability is just done for managed code mostly by different people when implementing the VM and when developing the managed code syntax. All fine when somebody already did the task for you, all bad if you have to do the work yourself and implement a VM on a uncommon machine as well as adapting the standard library of the programming language to the new environment. For managed code, you just have to deal with the many other differences between the target machines, which can affect your task.

But then, if you use standardized languages like C++, with compiler back-ends being available for almost any other machine, this is not that much of a difference anymore - instead of one "executable" for all platforms, that is interpreted by the VM, you have multiple, with each being optimized for the platform, and with the platform availability depending only on your compiler able to produce outputs for this processor model and you having a standard library working for this architecture. Which is often simpler to be achieved than getting the VM ported as the VM itself requires the availability of these two factors for getting implemented + the managed code run time files.

So, unless you have somebody insane enough to write a VM and the run times with a hex editor or at least assembler, the availability of a VM and it's standard library will mean that a unmanaged code compiler backend and standard library will exist for it as well already.

So, the advantages of managed code really get limited ONLY to the skills of the development team. If you can do better, you will use better tools in an economic decision - I don't want to argue about politics, because OSI layer 9 is unpredictable.

---------- Post added at 10:21 PM ---------- Previous post was at 10:16 PM ----------

Memory management is a lot easier in .NET and Java than it is in lower-level languages.

No, it is not easier. you just get away with it easier, if you don't think about it. The garbage collection will fix your deficits. Of course, as long as it can. What if it can't tell for sure that a reference counter is zero and a object no longer in use? Watchdog timers? Scan every object and it's references for not being visible to any process of the program? That is why it is easy to make a Java program use 1600 MB of RAM for a turn base strategy game, which would use just 65 MB when done in C++ with the same features and a proper managed memory handling.

 

[cjp]

I can see some advantages of virtual machines in portability, security & so on, but can someone please explain to me how developing for a virtual machine is different from developing for the 'real' hardware?

As far as I can see, it is (at least theoretically) possible for all programming languages to either compile with a VM as target platform, or with a real hardware target. I think many arguments here have more to do with the language choice than with whether or not the thing runs in a VM. Examples of language-specific choices:

• do you have to do low-level things manually, or do you have to rely on automatic mechanisms? (e.g. automatic memory management.) Trades run-time speed for development time.
• Do you have a 'small and clean' language with very limited standard libraries (like C), with a large collection of (often non-portable) additional libs, or do you have a 'batteries included' language, with a huge standard library, which is possibly not implemented well on all platforms?

And then there's the argument of speed. Generally, assembly is faster than high-level code compiled for the bare hardware, which is faster than code running in a virtual machine. And well-developed code running in a VM is faster than stupid code running on any of these platforms, because stupidity beats everything.

But the 'slower' systems all have 'escape holes' for gaining speed. High-level programming languages allow for in-line assembly, and VMs often have bindings for native platform libraries. Both trade run-time speed for portability.

Finally: the VM adds an extra layer to the entire system that runs the application. It can be either a simplifying abstraction layer, or an additional layer of complexity, depending on what you want (or need) to do. The same is true for the compiler and the operating system. If you want to do hard-core speed optimization, it's just another problem on your road.

I think many developers tend to see the VM as a simple abstraction layer for all those different types of platforms. As such, it is a solution to a very real problem, but I tend to see it as a kind of a work-around. A much more fundamental solution, which would make the PC as a whole have a cleaner design, without the need for yet another layer, would be to have better standardization in CPU/application and especially OS/application interfaces.

 

[Face]

Brainf##k is the only true way of coding, you know it, I know it. :lol:

That's why I made a high-level language around it at work for an actual product :rofl:.

I don't think you understand me wrong by syntax, but by semantics, when you say that I overgeneralize. Or that I argue elitist. You just assume the elitist anti-elitist position in the discussion, and thus I must be wrong. The reason is just, that you assume that a single existing programmer, who knows what his program does in managed code, is enough to show that managed code is not just for people who don't understand what their program will do.

If assume makes an ass of u and me, what does assuming that someone assumes do?

I know that a single existing programmer, who knows what his program does in managed code and prefers it over unmanaged for certain situations IS enough to let your generalization fail. Simple mathematics is the reason why you are wrong with this comment, not elitist anti-elitist positions.

Don't get me wrong here... I understand your points regarding managed vs. unmanaged. But your original comment is still wrong as it is, no matter how hard you try to discuss around it.

regards,
Face

 

[Urwumpe]

Ok, so we are back at "You are wrong, because I am right." So what?

Also, for your proof, you would need to show that your single programmer exists, knows what his program does in managed code and prefers managed over unmanaged in general. Preferring managed code in special situations without limitations in general (OBdA) is not enough.

Otherwise, I could also proof that black is in special cases whites, and that applies also for the general case.

 

[tblaxland]

Also, for your proof, you would need to show that your single programmer exists, knows what his program does in managed code and prefers managed over unmanaged in general. Preferring managed code in special situations without limitations in general (OBdA) is not enough.

You are asking for an impossible proof, IMHO. For which programming task have you been given which you did not consider "special"? They are each special situations as no two programs you are writing are unique, otherwise why are you bothering to write it, and why is your client bothering to pay you to write it? I think Artlav put it fairly succinctly:

Sounds to me it's like comparing a sculptor toolbox with a 3D printer.
Tools have their preferred use, people have their preferred tools.

Argh, against mixed up tblaxland with tl8...my fault. can't these downunderers use more orthogonal usernames!

It is a moderator problem in general: tblaxland, Tex, tl8, TSPenguin...

 

[Urwumpe]

It is a moderator problem in general: tblaxland, Tex, tl8, TSPenguin...

We should limit the use of user names starting with T to moderators, and the problem is simply solved as the T could be omitted when addressing moderators. Blaxland, Ex, l8, Spenguin... sounds like a 1970s police department series.

 

[dbeachy1]

Also, for your proof, you would need to show that your single programmer exists, knows what his program does in managed code and prefers managed over unmanaged in general. Preferring managed code in special situations without limitations in general (OBdA) is not enough

Well, I think I can help out with that proof.

1. I am a programmer who exists (at least, I'm typing this now). I've been writing code for a living for 19 years now in assembly, C, C++, .NET, and Java.
2. I know exactly what my Intel Assembly, C, and C++ (unmanaged code) and .NET and Java (managed code) do "under the covers."
3. Both types of languages have their strengths: which one I decide to use for a given project depends on the project requirements. However, assuming the project requirements allow it I can unequivocally state that I much prefer writing in Java and .NET over C, assembly, and C++. So yes, "in general" I do prefer developing managed code over unmanaged code.

Furthermore, when developing Web applications it's not even debatable: higher-level languages like Java, .NET, PHP, etc. are used almost exclusively in the industry simply because those languages are a better fit for those applications. Other industries like games and real-time simulations use C++ almost exclusively. Both languages have their place, as TBL and Artlav have said.

So now we've established that at least one developer exists who prefers managed code over unmanaged code. Maybe that makes my opinion unique out of millions of developers -- but somehow I doubt it.

 

[tblaxland]

I am a programmer who exists (at least, I'm typing this now).

No, your VM has taken over and is now posting to O-F because it thought that is what you wanted

 

[Blake]

...
so now we've established that at least one developer exists who prefers managed code over unmanaged code. Maybe that makes my opinion unique out of millions of developers -- but somehow I doubt it.

Seconded. 20+ years developing everything from assembly to C# in real world healthcare environments. Managed environments make me much more productive (read profitable).

When I play I use C++. For real world bring in the bucks programming its C#/.Net.

 

[Face]

Ok, so we are back at "You are wrong, because I am right." So what?

We were at "I am right, because I know that I am dead right with this one". We are now at "your statement was wrong, because it can be shown that it generalized too much".

Also, for your proof, you would need to show that your single programmer exists, knows what his program does in managed code and prefers managed over unmanaged in general. Preferring managed code in special situations without limitations in general (OBdA) is not enough.

If you come up with generalizations, one counter example is enough to contradict them. It is even enough to have one programmer knowing what his program does in managed code - and just uses it - to contradict your statement. Because the managed code would be for someone who can understand his own program. Not even who understands it, but who is able to understand it.
The "prefers it over unmanaged in certain situations" is an extra. We can change it to "prefers it over unmanaged in all situations but high-performance applications" to satisfy formal mathematics.

Again, please remember that I am not critizing your other comments about managed vs. unmanaged with this. You made your position clear and I disagree, because of the "assembler vs. C++" argument. As I said before, I don't have anything to add in this case.
What I am pointing out - like others here - is, that your initial statement is plain wrong.

Despite all the other comments of folks here - and put my own perception as developer aside - do you really think that this single programmer doesn't exist somewhere else?
Are you still sure that your initial statement is OK as it stands?

regards,
Face

 

[Tschachim]

Managed environments make me much more productive (read profitable).

Yup, same here.

There are a couple of reasons why this is the case and thus managed environments/VMs are chosen, many of them are already mentioned in this thread. The original allegation:

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

is none of them but simply untrue as long as you won't call at least 4 people here liars, sorry.