What do you think about managed code and OSes written in it?

[Brendan]

Hi,

Embryo; you are not arguing for "managed", and you are not arguing against "unmanaged". Instead, you are arguing for Java without caring if it's managed or not.

That's nonsense and you should know that by now.

To summarize what Embryo actually argued:
- numerous arguments

Numerous arguments, that were almost all either irrelevant or illogical.

- therefore managed languages are better (and therefore your first sentence is a lie)

Wrong. He is trying to say "managed languages are better", but he's failing to do that because his arguments are all of the "one specific managed language is better than one specific unmanaged language" type.

- Java is an instance of a managed language
- C is an instance of an unmanaged language
- therefore by instantiation makes Java better than C (and therefore your second sentence is a lie)

You've got all of this in the reverse order. The majority of his arguments begin with the assumption that Java is better than C and then that assumption (which I've not really objected to - C really isn't ideal) is used to infer that all possible managed languages must be better than all possible unmanaged languages.

Andrew was almost right. It just had to be purple cars instead of monkeys.

You've incorrectly assumed that Andrew is replying to me; but he's replying to Embryo and saying that Embryo's arguments are full of fallacies (like I am).

To get you up to speed (as you seem to have skipped at least some of the "far too many pages" of discussion); we've made no significant progress beyond my original "the benefits of managed don't justify the disadvantages" statement that started all of this. The benefits haven't really been identified or quantified (ignoring irrelevant things like 'larger libraries reduce development time"), while there hasn't been much disagreement about the disadvantages. I'm mostly advocating compile time checking; and there was a little discussion about how much compile time checking is possible, but (in my opinion) that was mostly resolved as "enough compile time checking to severely diminish the perceived benefits of managed environments". I'm also not against using managed environments for debugging purposes before software is released (e.g. like, but not necessarily the same as, valgrind) - it's mostly about whether "managed environments" are worthwhile on the end user's computer, and about whether "managed languages" are worthwhile. There's also some agreement and some dispute for the definitions for "managed language", "managed environment" and "managed OS".


Cheers,

Brendan

[Combuster]

The topic title asks what we think of OSes written in a "managed language".

Who "manages" the kernel when the kernel is written in a "managed language"?

For example if you write your kernel in Java, does the kernel run in something akin to the JVM? If so, what is the VM written in?

If someone says that the kernel is written in C, it's an unwritten fact that it's actually ~99% C and ~1% assembly because C can't do everything. If you'd "write a kernel in Java", then you have ~1% assembly, ~4% for a memory allocator and garbage collector in most likely C/C++, and ~95% Java. Of course, if you just started those numbers skew to the lower level languages.

And one other part of increasing the managed language part is to convert a bytecode language to native code to reduce the number of tasks required by the "VM" half of the system.

The point is to minimise the amount of "risky" code. Of course there can be bugs in that code, but that code is meant to be finite in size and therefore finite in bugs, and essentially making the assumption of type and memory safety.

[Combuster]

You've incorrectly assumed that Andrew is replying to me; but he's replying to Embryo and saying that Embryo's arguments are full of fallacies (like I am).

If it's that apparent there's no distinction between you two, it's obvious both of you have been arguing for 12 pages too many.

[linguofreak]

If you'd "write a kernel in Java", then you have ~1% assembly, ~4% for a memory allocator and garbage collector in most likely C/C++, and ~95% Java.

Or you might use 1% assembly and 99% the SJC dialect of Java.

[SoulofDeity]

- Java is an instance of a managed language
- C is an instance of an unmanaged language
- therefore by instantiation makes Java better than C (and therefore your second sentence is a lie)

You've got all of this in the reverse order. The majority of his arguments begin with the assumption that Java is better than C and then that assumption (which I've not really objected to - C really isn't ideal) is used to infer that all possible managed languages must be better than all possible unmanaged languages.

It's not ideal for applications development, but I wouldn't say Java is better.

As I had said before (maybe earlier in this thread), many programmers tend to see languages as features rather than solutions. One complaint I've rather grown tired of hearing is that C doesn't have bounds checking. It doesn't have that because doesn't have arrays, it has vectors. It evolved from B, which evolved from BCPL, which declared vectors like:

Code: Select all

LET x = VEC 10

This equivalent to 'auto x[10];' in B or 'int x[10];' and is a directional vector (like in mathematics) upon which you can move forward and back. The number '10' does not give a limit, it's just allocating space for 10 'cells' of type 'x'. Also, C strings are 'true' strings, in the sense that they are like samples of vectors. What languages with unicode text have are merely sets of characters.

Briefly put, just by having arrays (with or without bounds checking) and unicode 'sets', you are already adding a layer of abstraction between you and the hardware. Sometimes, this [having layers of abstraction] is a good thing, but not always. It depends on what you're doing.

[embryo]

It should be noted that Java (as distributed by Oracle) doesn't come with an IDE or GUI designer. People use 3rd party tools like Netbeans and Eclipse. If your argument is that third parties offer compete solutions, then how is C/C++ (languages you keep referencing as unmanaged, because everything non-C/C++ could have some feature that makes it managed, according to your definition) different because QT Creator and Visual Studio bundles a compete environment together with massive libraries and all the tools you need?

C/C++ is different in it's incompleteness. It lacks some features, that managed solutions must have.

Under your 'everything is managed in some way' definition, please give us some examples of an unmanaged environment.

There was no such definition. My definition was given here, you can compare it with your interpretation. And according to the definition unmanaged environment is an environment, that misses all or some declared features.

If there's no such thing as an unmanaged environment, what is the point of using the word 'managed' and not just calling it an 'environment'?

If you prefer to not pay attention to definitions, then yes, there are only "environments".

I guess I know what your response will be - "all environments are managed, some are just more managed than others" and some irrelevant ramble about monkeys.

Some people look like monkeys (or apes), but somehow we can see a difference. Or do you prefer to speak about them in such manner - some of them are just more monkeys than others? The next step will be "we are star dust and there is nothing real".

[embryo]

It's like saying "cars are better than motorbikes because I saw a purple car the other day and I like purple".

Yes, motorbikes can be upgraded and in the end they can look like a car and smell like a car. But have you noticed, that there is no more motorbike and instead there is just another car?

[embryo]

Who "manages" the kernel when the kernel is written in a "managed language"?

The kernel also was written using managed environment. It means there is a safe language, for example, and it helps to decrease a bug number. Also there is GC at run time. Also there can be some externalized memory allocation (in addition to deallocation by GC). And there can be some functionality to update the kernel at runtime, to trace it's performance and so on.

And if you need a more exact answer, then it is the kernel that manages kernel (self hosting).

[embryo]

Or you might use 1% assembly and 99% the SJC dialect of Java.

Nice to see another way of osdeving in Java

[thepowersgang]

Ok, so, it looks like there's a lot of running around in circles here.

I'll just put my two cents in with a definition an opinion.

1. A managed language (and managed code) to me means code that requires a heavy-duty runtime to be able to run. (i.e. a bytecode interpreter and/or a GC memory manger). This means that most CIL-based or JVM-based languages count as "managed", but some can be AoT compiled down to not need the runtime (not sure how well this works). A counter is that C/C++ are not managed, because the language can be used with a minimal runtime (basically just memcpy and friends, that are trivial to write in assembly or even in C/C++). Edge cases do happen, e.g. afaik the "Go" language compiles to naitve code, but still requires a GC memory manger, but otherwise skirts the edges of managed/unmanaged land.

2. For OSes written in managed code? I believe that the kernel core should never be written in managed code, because it has to be fast and as bug-free as possible. However, the userland could be managed code (because bugs there can be isolated), as can be drivers (isolation and catching is possible, and a ported runtime can be used).

tl;dr - OSes in managed code can work, but you don't want it for the core (because it creates more issues than it solves).