Quoth Florian Weimer
wikipedia: "Managed code is a differentiation coined by Microsoft to identify computer program code that requires and will only execute under the "management" of a Common Language Runtime virtual machine (resulting in Bytecode)."
I like this term, I apply it by extension to any system which enforces memory safety (as long as you stick to non-internals, such as array indexing, even Java has got (in practical terms) fairly portable PEEK/POKE operations).
... enforces memory safety? Can't that be done in code compiled straight to CPU instructions without even calling a run-time, let alone being managed by one? I'm not sure what you mean, but in this case, the term has surely been extended too far - it doesn't seem to be managed code in the sense quoted above, nor does it seem to fit with common non-technical usage of "managed".
In other words, a new way to say `interpreted',
This term doesn't really apply that well to the CLR because its bytecode really can't be interpreted efficiently. (The bytecodes lack type information.)
To me, the CLR takes bytecode, maps it in some way to CPU machine code and executes the latter. I would call that "interpreted", but you wouldn't? Or am I wrong about what's happening? I know Wikipedia isn't necessarily the ultimate authority of computer science, but "Many interpreted languages are first compiled to some form of virtual machine code, which is then either interpreted or compiled at runtime to native code." (... going on to cite Java and .NET Framework among others), so I'm not the only one who finds it expedient to use that word "interpreted" in this context.
and `native' vs. `interpreted' is a familiar distinction for more computing environments than just Java. But it isn't relevant here, right? Since neither the Haskell nor OpenSSL implementations are both compiled to CPU instructions.
Obviously, this depends on the implementation. For Haskell and Java, implementations which are based on precompiled machine code exist. There are also implementations which rely on some form of interpretation exclusively. That's why the managed/unmanaged distinction is more useful than the interpreted/compiled distinction.
I don't know, of course this is partly due just to my own ignorance, but it seems to me that the awkward semantics around this distinction make it somewhat prone to confusion. Maybe the kind of thing that's useful to your understanding of computational environments, but less useful when discussing them with others? At this point, I still don't know for sure if you think a GHC-compiled Haskell program is managed, or unmanaged, but I think managed? And in my confused present state I would say it's unmanaged. Donn Cave, donn@avvanta.com