The rage in the modern programming world is using Managed Code to execute your stuff. This is “clearly” much better than using legacy systems, or so the world says is true. While deep down, I know the managed world is the way to go, I am still not so quick to give up on compiled code. The managed folks call compiled code, “legacy code”, with the intended push-down that “managed code” is better. I feel insulted!
Run “managed code” and your world is more secure, all the ducks swim in a straight line, cats and dogs play together and you don’t have to worry about things like pointers referencing memory to which they are not supposed to be pointing, or even pointers at all. Focus on the “what” and let the Common Language Runtime (CLR) handle the details of running stuff. Oh, life is happy in a managed world.
Errors in managed code
I write this post because I was using some program the other day that bombed out with an “Unhandled exception” on access a string.something.another.eight.more.levels class which failed to check for NULL and … BLEW UP! Then, it kept blowing up because the exception still wasn’t cleared. Click the message box “okay” button and … you get another message box two seconds later, also demanding top layer window in the center of the screen! Only way to get the keyboard away from this top level menu was to task manager and kill the offending CITRIX application – Yes, I said it! CITRIX APPLICATION!
Exceptions are SO MUCH BETTER than an Application Trap in Dr. Watson!
No, they are not!
There’s a theory in managed code that you don’t have to check the assignments because if it doesn’t work, the exception handler will catch it! BUT, what if the person calling you forgot to catch one of the 18 different exceptions that you generated? Notice I didn’t say that you will throw, they also have to catch all the exceptions that you will GENERATE based on all of the people that you call and all of the people that they call.
Your code calls somebody to discuss Faberge Shampoo, that person calls two other people, who each call two other people, and so, and so on and so on, until pretty soon Heather Locklear has to protect against every possible exception in the programming world with a “catch all” exception handler!
Clearly, I have gone WAY off topic, or have I?
We have just eliminated the advantage of throwing exceptions, instead of checking a RC, the calling code has to register to catch a bunch of exceptions! Miss one and the application blows up. Catch too many and you mask errors!
The person writing the code I was running the other day, missed one!
I’m perhaps old school, but if you reference NULL with your code, an App Level trap is a really nice way of letting you know that you screwed up. Fix it and don’t let that happen again! But, programmers tend to be lazy about checking return codes and this causes bugs to manifest up a few layers, which becomes harder to track down. The managed theory is that the code causing the exception, eight layers deep, the programmer will know exactly who threw that managed exception and be straight away to the answer.
Is this any better? No, as a user, I’m still hosed!
Everything has it’s place…
Have you ever received a kernel mode interrupt dispatch in managed code? It ain’t gonna happen!
So, managed code has a place and complied code has a place. The higher up the programming stack, the more incentive for using interpreted language. This through gets us into a space where subsystems or back ends are implemented in compiled code and the GUI is implemented in managed code. It can also go the other way.
Have you considered calling PowerShell from compiled code? In managed code, easy – in compiled code, harder.
History: UCSD P-Code.
Dating myself, but among the first programming classes I took in college was a Pascal class using a UCSD P-Code interpreter. This was the rage of the day. Today we call it “managed code”, but back then we gave it the stigma of “interpreted”. The machines (8088) were fast enough and the display was slow enough, that on the display, it didn’t matter that the back end was running kind of slow. P-CODE was WAY faster than interpreted languages like Basic, but also had many of the same benefits.
P-CODE was run in a controlled environment where the program could not break out to do things that it wasn’t supposed to do and the runtime would catch the errors and shut the program down gracefully. P-CODE interpreter was language and machine independent.
Notice that P-CODE had the same capabilities of Java or .net to move P-CODE from one machine to another without source and the ability to run independent of the actual CPU on the platform. It even included preparsing of the P-CODE to machine code to get a machine native equivalent for faster execution. Awesome stuff!
DOES ANY OF THIS SOUND FAMILIAR?
About 1 month into the class, Borland released Turbo Pascal and the use of UCSD P-CODE ceased in about 10 minutes. I mean it went to ZERO, immediately – worldwide! Here, the compiled code was SO MUCH BETTER and SO MUCH FASTER that the use of the interpreted system just flat out vanished. ( Yes, someone is probably still running it – on Citrix MetaFrame XP ).
Paying a compliment
GUI programming is much faster in the managed world. Draw a picture of what you want it to look like and magical quantities of highly tested classes are available to help you pull it off. These are all really good things and I need to make sure I’m not seen as refusing to embrace cars just because horses work just fine.
My point is that just because you are “managed code” does not get you out of the business of writing code that isn’t crap. As a user, if I see an exception, you messed up!
The corollary is that if as a user, I see a BSOD from a kernel driver that forgot that it should check for NULL before using a pointer then there’s a programmer that messed up here too and while I’d like to pretend that is isn’t me, occasionally, this is me.
Citrix Systems Product Architect – Application Streaming and User Profile Manager.