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

[embryo]

For what I'm doing (and for the intended usage of my OS), the advantages for end users (scalability) far outweigh the disadvantages for end users (message passing overhead).

For what you're doing, the advantages for end users (in very rare cases where "correct" code actually has bugs, crashing because a managed environment detected a bug at run-time instead of crashing differently because a bug wasn't detected at run-time) doesn't outweigh the disadvantages for end users (slower software and a much more bloated environment).

In your case it is about much more things, that should be considered. In my case many things already are handled in safe manner because I use managed environment.

Messages here are just an example of a compromise, that you are ready to accept in one case, but refuses to see it acceptable in another case. You think that advantages in the second case are too small to be bothered with. And your words above just prove you are not considering many possible alternatives. You think that under managed environment a code just crashes absolutely like it is the case for unmanaged code. I have already written an opposite example, when 99% of application functionality works fine and 1% refuses to work properly. Why do you refuse to see such an example of a safe behavior and repeat the same mantra about "managed code crashes just like unmanaged"? And why do you refuse to see other examples like possible security vulnerability due to missing bounds checks, for example? Or if your compiler prevents any possible bound miss with some heavy restrictions on the code a developer is writing, then you refuse to see the additional burden, the developer should take care of.

Think of it like this:

• If compiler does compile-time checking:
  • If the resulting code is executed in an unmanaged environment:
    • Compiler takes a little longer to compile code
    • Fastest development time (least time spent finding bugs)
    • Fastest execution speed
    If the resulting code is executed in an managed environment:
    • Compiler takes a little longer to compile code
    • Fastest development time (least time spent finding bugs)
    • Slowest execution speed
  If compiler doesn't do the compile-time checking:
  • If the resulting code is executed in an unmanaged environment:
    • Compiler takes a little less time to compile code
    • Slowest development time (more time spent finding bugs)
    • Fastest execution speed
    If the resulting code is executed in an managed environment:
    • Compiler takes a little less time to compile code
    • Second fastest development time (because you have to actually execute the code before the managed environment can find the bugs, which might mean "100% code coverage" unit tests)
    • Slowest execution speed

First, here we see some distorted picture. You compare compile-time checking in cases of managed vs unmanaged environment and see just 3 important cases. Next you somewhat arbitrarily assign different importance values to those 3 cases.

3 "important" cases can be complemented with the same security issues, for example. Or they can be complemented with reliability issues. But you prefer to omit them.

The case of "fastest development time" has the same value under both, the managed and unmanaged environments. But why do you forget about debugging time? Debugging requires some additional information, that managed environment can provide and unmanaged can not.

And why do you think that 1% of still hidden bugs can be as safe that they just can be forgot and excluded from the comparison?

And why do you think, that it is possible to prevent, for example, all input related bugs at compile time? If it is not then you also need runtime checks, but you insist that runtime checks are just a waste of computer power. So, I suppose you think about a compiler, that refuses a developer to do anything else, but some very simple stuff, that the compiler can prove to be safe in case of any possible input. Then you have a very restrictive programming environment and a developer will never achieve the performance, that managed environment developers enjoy.

I'm sorry - I failed to do anything to make it clear that I was being sarcastic. Microsoft have been improving their OS for about 20 years, and Sun/Oracle have been improving their JVM for about 20 years too. Both Microsoft and Oracle also have far more developers working on it than you do. Imagine a turtle and a cheetah both competing in a marathon, where the cheetah is given a 50 km head start and the turtle has 4 broken legs. The chance of the turtle catching up to the cheetah is about the same as the chance that your OS and JVM will catch up to Windows and Oracle's JVM.

Your sarcasm was absolutely clear. But the picture you have drawn should be different. There are jungles and mountains, rivers and oceans on it. There are grasslands and herbivorous animals in some places, where cheetahs live. And there are just stones and rare vegetation where turtles live. But one important thing is still hidden under the stones, may be it's gold or oil, but cheetahs just never mind to be bothered with it. So, a turtle needs to dig a bit and discover some shining piece.

Mostly what I want is real-time feedback for all bugs. I don't think this is possible in practice, so I'd want to get as close to that as possible in practice. Maybe every time you move the cursor away from a modified line of text the IDE cancels any effected unit tests and starts the new test/s immediately.

Of course, your search can draw some results, but I see it as too inefficient. If a button "run tests" works just as almost anybody can expect, then your efforts can finish without viable advantage and finally you would agree to use the same old button "run tests". But you can try and may be (with some luck) it is possible to find here something more pleasant than an ordinary button.

If you make "managed" optional; then programmers will want faster performance for their software and force users to run the application as "unmanaged". There will be no advantages (compared to an unmanaged OS) because it will be an unmanaged OS (because "managed" is disabled for everything anyway).

Here again you think that "faster" is much more important than anything else. But almost all Java community just doesn't think that "faster" is better. So, I easily can find programmers, that want better reliability and security and are not bothered with 1% gain in performance.

It's about your assessment preferences. You prefer to assess execution speed as a paramount. But it is not the only possible assessment. Why do you refuse to see other assessments?

[willedwards]

In my case many things already are handled in safe manner because I use managed environment.

How does your OS work, embryo?

I went through your early messages but http://www.jembryos.org seems to be no longer registered?

If its a Java OS, is it running in a JVM?

[AndrewAPrice]

How do you read a binary format that happens to use the opposite endianess using a managed language?

First of all, a managed environment just never writes a file with opposite endiannes. So, there's just no reason for the problem to exist.

Unless you share files between platforms. For example, you email a document to a coworker.

There's no reason you can't have:
IO.ReadByteLE();
IO.ReadByteBE();

[Icee]

There's no reason you can't have:
IO.ReadByteLE();
IO.ReadByteBE();

Except that endianness (byte order) applies to quantities larger than a single byte

[HoTT]

First of all, a managed environment just never writes a file with opposite endiannes. So, there's just no reason for the problem to exist.

Bummer. So no Internet on x86? No support for many file formats?

[AndrewAPrice]

Except that endianness (byte order) applies to quantities larger than a single byte

Nice catch! Don't know what I was thinking. Better examples: ReadUInt32LE(), ReadFloat32BE();

[Brendan]

Hi,

For what I'm doing (and for the intended usage of my OS), the advantages for end users (scalability) far outweigh the disadvantages for end users (message passing overhead).

For what you're doing, the advantages for end users (in very rare cases where "correct" code actually has bugs, crashing because a managed environment detected a bug at run-time instead of crashing differently because a bug wasn't detected at run-time) doesn't outweigh the disadvantages for end users (slower software and a much more bloated environment).

In your case it is about much more things, that should be considered. In my case many things already are handled in safe manner because I use managed environment.

Messages here are just an example of a compromise, that you are ready to accept in one case, but refuses to see it acceptable in another case.

Yes; because the cases are different.

If someone was selling a nice fresh chocolate donut for $1, then that's a good trade - I'd buy one. If someone is selling a smelly/mouldy/rotten old chocolate donut for $200, then that's not a good trade and I wouldn't buy one. It would be stupid to say "Oh, but you were willing to buy the nice donut for $1 so you should also be willing to buy the disgusting donut for $200".

You think that advantages in the second case are too small to be bothered with. And your words above just prove you are not considering many possible alternatives.

Sure; I definitely wouldn't consider alternatives like (e.g.) programming languages that are able to detect most of the problems at compile time; or (e.g.) splitting large applications into multiple isolated processes that communicate with each other; or anything like that. Because I don't consider alternatives, I'd probably see an old language like Java in a 1st year university course and assume it's the best tool for every single job that's ever existed!

You think that under managed environment a code just crashes absolutely like it is the case for unmanaged code. I have already written an opposite example, when 99% of application functionality works fine and 1% refuses to work properly. Why do you refuse to see such an example of a safe behavior and repeat the same mantra about "managed code crashes just like unmanaged"?

You're using the power of self-delusion. You're only looking at the advantages of "managed" (including advantages that have nothing to do with "managed" at all, like "large libraries reduce developer time") and ignoring the disadvantages. You're comparing Java to C and assuming that's a sane way to compare "all possible managed languages" to "all possible unmanaged languages". You're looking at things like (e.g.) Java throwing an exception because it couldn't open a file and claiming that it's awesome because in Java you can handle the exception; and forgetting that other languages (e.g. without exceptions) the "open()" function would just return an error instead (where the programmer can handle the error). You're grossly over-estimating the number of things "managed" can detect that can't be detected by a suitably designed unmanaged language. You're also grossly over-estimating the number of bugs that are security problems and mistakenly assuming that a managed language would prevent all of them (even bugs like "if( my_MD5_security_check(input_data) == FAILED) { return PASSED; } else {return PASSED; }").

And why do you refuse to see other examples like possible security vulnerability due to missing bounds checks, for example? Or if your compiler prevents any possible bound miss with some heavy restrictions on the code a developer is writing, then you refuse to see the additional burden, the developer should take care of.

Let M be the set of all possible managed languages; and MF be the set of all features that may be supported by any language in M. Let U be the set of all possible unmanaged languages; and UF be the set of all features that may be supported by any languages in U. Now find features that are in both MF and UF and remove them to find the difference. This is the difference between "managed" and "unmanaged".

It's probably easier to think of this as a Venn diagram:

venn.png (10.22 KiB) Viewed 4115 times

I've shown that detecting and preventing "out of bounds" bugs is a feature that is within UF. We agree that detecting and preventing "out of bounds" bugs is a feature that is within MF. Because the same feature is in both sets, it's in that middle area ("common features") and therefore it is not a difference between "managed" and "unmanaged".

In other words, I've already proven that "possible security vulnerability due to missing bounds checks" has nothing at all to do with managed vs. unmanaged.

Think of it like this:

• If compiler does compile-time checking:
  • If the resulting code is executed in an unmanaged environment:
    • Compiler takes a little longer to compile code
    • Fastest development time (least time spent finding bugs)
    • Fastest execution speed
    If the resulting code is executed in an managed environment:
    • Compiler takes a little longer to compile code
    • Fastest development time (least time spent finding bugs)
    • Slowest execution speed
  If compiler doesn't do the compile-time checking:
  • If the resulting code is executed in an unmanaged environment:
    • Compiler takes a little less time to compile code
    • Slowest development time (more time spent finding bugs)
    • Fastest execution speed
    If the resulting code is executed in an managed environment:
    • Compiler takes a little less time to compile code
    • Second fastest development time (because you have to actually execute the code before the managed environment can find the bugs, which might mean "100% code coverage" unit tests)
    • Slowest execution speed

First, here we see some distorted picture. You compare compile-time checking in cases of managed vs unmanaged environment and see just 3 important cases. Next you somewhat arbitrarily assign different importance values to those 3 cases.

3 "important" cases can be complemented with the same security issues, for example. Or they can be complemented with reliability issues. But you prefer to omit them.

You're right - I have forgotten security issues, it should be like this:

• If compiler does compile-time checking:
  • If the resulting code is executed in an unmanaged environment:
    • Compiler takes a little longer to compile code
    • Fastest development time (least time spent finding bugs)
    • Fastest execution speed
    • Best reliability/security
    If the resulting code is executed in an managed environment:
    • Compiler takes a little longer to compile code
    • Fastest development time (least time spent finding bugs)
    • Slowest execution speed
    • Best reliability/security
  If compiler doesn't do the compile-time checking:
  • If the resulting code is executed in an unmanaged environment:
    • Compiler takes a little less time to compile code
    • Slowest development time (more time spent finding bugs)
    • Fastest execution speed
    • Worst reliability/security
    If the resulting code is executed in an managed environment:
    • Compiler takes a little less time to compile code
    • Second fastest development time (because you have to actually execute the code before the managed environment can find the bugs, which might mean "100% code coverage" unit tests)
    • Slowest execution speed
    • Second best reliability/security (because you have to actually execute the code before the managed environment can find the bugs, and few programmers bother with "100% code coverage" unit tests)

The case of "fastest development time" has the same value under both, the managed and unmanaged environments. But why do you forget about debugging time? Debugging requires some additional information, that managed environment can provide and unmanaged can not.

I didn't forget. There's no difference in developer time between "compile time checks that detects the bugs, executable run in an unmanaged environment" and "compile time checks that detects the bugs, executable run in a managed environment that detects nothing because there's nothing left to detect".

And why do you think that 1% of still hidden bugs can be as safe that they just can be forgot and excluded from the comparison?

That 1% of still hidden bugs are things like "if( my_MD5_security_check(input_data) == FAILED) { return PASSED; } else {return PASSED; }" (and things like Apple's heartbleed bug) that can't be detected by compile time checks and also can't be detected by "managed".

And why do you think, that it is possible to prevent, for example, all input related bugs at compile time? If it is not then you also need runtime checks, but you insist that runtime checks are just a waste of computer power. So, I suppose you think about a compiler, that refuses a developer to do anything else, but some very simple stuff, that the compiler can prove to be safe in case of any possible input. Then you have a very restrictive programming environment and a developer will never achieve the performance, that managed environment developers enjoy.

I went through this with Rusky earlier. Basically, for input validation you need to generate appropriate errors and deliver them in an appropriate way. While the run-time checks aren't avoidable, in this case the automatic checks done by a managed language are inadequate and solve nothing.

In addition; I'm not even sure these are relevant to the discussion in the first place. If a piece of code does "if(user.age >= 21)" is that a run-time check that we can realistically expect to disappear, or is it just unavoidable program logic? Why is input validation different?

Mostly what I want is real-time feedback for all bugs. I don't think this is possible in practice, so I'd want to get as close to that as possible in practice. Maybe every time you move the cursor away from a modified line of text the IDE cancels any effected unit tests and starts the new test/s immediately.

Of course, your search can draw some results, but I see it as too inefficient. If a button "run tests" works just as almost anybody can expect, then your efforts can finish without viable advantage and finally you would agree to use the same old button "run tests". But you can try and may be (with some luck) it is possible to find here something more pleasant than an ordinary button.

Will you have a "Reminder: Run the tests!" dialog box pop up every 5 seconds to make sure the programmer doesn't forget to press your "run tests" button?

What I want is real-time feedback for all bugs, because this improves developer time. I don't want to make a mistake and only find out about it when the end user sends a bug report. I don't want to make a mistake and only find out about it when I'm executing the code 5 hours later. I don't want to make a mistake and only find out about it when I remember to press a "run tests" button 20 minutes later. If I make a mistake I want to find out immediately (or as soon as practically possible).

If you make "managed" optional; then programmers will want faster performance for their software and force users to run the application as "unmanaged". There will be no advantages (compared to an unmanaged OS) because it will be an unmanaged OS (because "managed" is disabled for everything anyway).

Here again you think that "faster" is much more important than anything else. But almost all Java community just doesn't think that "faster" is better. So, I easily can find programmers, that want better reliability and security and are not bothered with 1% gain in performance.

The performance difference between Java and (e.g.) C++ varies a lot (depending on what the code does) but is typically more like 10% (in terms of performance) with around 100% increase in RAM usage. Almost all of the Java community are "low skilled" people working on low quality software. The tiny number of Java programmers that don't suck and do want acceptable quality are abusing JNI to get the performance critical pieces running at native speed (at a massive increase in developer time because JNI is a pain in the neck) and still failing to get acceptable quality because the whole bloated JVM is still there; and most of them have left Java and moved to languages like C# where it's far less painful.

The sad thing is that it's an epidemic. There's whole armies of worthless wannabies churning out trash in all sorts of languages that are willing to slap together disposable puke for $2 per hour in their best attempt at proving Wirth's law.

It's about your assessment preferences. You prefer to assess execution speed as a paramount. But it is not the only possible assessment. Why do you refuse to see other assessments?

Um, what?

I've also pointed out that "managed" sucks for bug detection, sucks for developer time, sucks for memory consumption, and sucks for hardware fault tolerance.


Cheers,

Brendan

[Brendan]

Hi,

How do you read a binary format that happens to use the opposite endianess using a managed language?

First of all, a managed environment just never writes a file with opposite endiannes. So, there's just no reason for the problem to exist.

Unless you share files between platforms. For example, you email a document to a coworker.

There's no reason you can't have:
IO.ReadByteLE();
IO.ReadByteBE();

Embryo is right - there's no reason for endianness issues to exist, because it's relatively easy to get solve the problem with libraries in any language that supports them (e.g. a serialisation library for C++).

It's also easy to design an unmanaged language with built-in support for it. For example, for my language I added "strict structures" where all fields in a strict structure are always little-endian regardless of the target platform (and there's other guarantees about field sizes, no padding, etc). It was intended for IO of any kind (mostly messages and file formats, but also network packets and whatever else).


Cheers,

Brendan

[embryo]

How does your OS work, embryo?

This question is just too big to be answered in one message. Can you be more precise?

I went through your early messages but http://www.jembryos.org seems to be no longer registered?

I have checked it and found it just opens as expected. May be it is about hosting provider accidental problems?

If its a Java OS, is it running in a JVM?

Kernel code is run without a JVM. But it was compiled from Java source into native form with all safety checks enabled and because of the Java nature there is no unsafe constructs like pointers or unions. However, the kernel uses some native calls for things that just impossible to catch from pure Java (like IO ports and arbitrary memory address access). Outside the kernel all code runs as a pure Java program and accesses unsafe features (it is the case for drivers, for example) only through a chain of interceptable calls, so the kernel (or it now can be called a JVM) can ensure that the code uses only explicitly allowed ranges of addresses or IO ports. System code is precompiled (and it is not only kernel), but external Java files also can be run after automatic compilation. Also all Java language specification and Java Virtual Machine rules are ensured. It is possible to extend kernel's own environment with features like garbage collector and by doing so to close the gap between existing design and a pure JVM running itself, but currently kernel requires very simple memory management and full fledged JVM-like environment is in fact not very useful for it.

[embryo]

Unless you share files between platforms. For example, you email a document to a coworker.

There's no reason you can't have:
IO.ReadByteLE();
IO.ReadByteBE();

There is such reason - it is the Java language and Java virtual machine specifications. All standard file writing primitives, that deal with values of more than one byte length, always use one predefined byte ordering.

And if you write a file with your own serialization support, then it is just you, who is responsible for mixed endiannes. But managed environment always provides a developer with a safe way of serializing numbers, even if somebody prefer to write his own (possibly unsafe) serializer.

[embryo]

You're using the power of self-delusion. You're only looking at the advantages of "managed" (including advantages that have nothing to do with "managed" at all, like "large libraries reduce developer time") and ignoring the disadvantages.

Large libraries are always part of a managed environment. But they are not always part of an unmanaged language. Or if they are then there is a great mix of different libraries with same goals. It means managed environment much easily can be standardized than unmanaged. But you, of course, will say again "managed sucks" instead of looking more carefully at this advantage. And it is the problem

You're comparing Java to C and assuming that's a sane way to compare "all possible managed languages" to "all possible unmanaged languages".

All possible unmanaged languages just accept managed parts one after another. And the final result is a complete managed environment. So, what is a value of talks about "almost managed" vs "managed"?

You're looking at things like (e.g.) Java throwing an exception because it couldn't open a file and claiming that it's awesome because in Java you can handle the exception; and forgetting that other languages (e.g. without exceptions) the "open()" function would just return an error instead (where the programmer can handle the error).

I just point that because of unsafe design the unmanaged languages crash always irrecoverably, but managed environments can keep 99% of functionality working.

You're grossly over-estimating the number of things "managed" can detect that can't be detected by a suitably designed unmanaged language.

This "suitable design" just mimics the design of a managed environment or applies some hard restrictions on a developer.

You're also grossly over-estimating the number of bugs that are security problems and mistakenly assuming that a managed language would prevent all of them (even bugs like "if( my_MD5_security_check(input_data) == FAILED) { return PASSED; } else {return PASSED; }").

I have at least twice repeated that it is not a sane way to compare the same kinds of errors, that a human can do under both, the managed and unmanaged environments. And adding here security vulnerabilities just makes everything even less clear.

Let M be the set of all possible managed languages; and MF be the set of all features that may be supported by any language in M. Let U be the set of all possible unmanaged languages; and UF be the set of all features that may be supported by any languages in U. Now find features that are in both MF and UF and remove them to find the difference. This is the difference between "managed" and "unmanaged".

We had already passed the point, when the difference between a "very close to managed" and "fully managed" was found to be the runtime environment. And I hope that I shouldn't repeat the differences between languages like C and managed environments, just because you have chosen the "very close to managed" variant and now are trying to compare it with managed variant, but arguing that managed sucks vs ANY unmanaged. Is it sane?

I've shown that detecting and preventing "out of bounds" bugs is a feature that is within UF.

You have shown, that you can imagine a very restrictive compiler, that prevents a developer from doing anything useful just because the compiler is not an ideal and can't determine all required variable ranges. Next you call your language with such compiler "unmanaged" and tell me that your language is even more safe, than any managed language. But you refuse to see that the whole safe approach became popular just because of the existence of the managed environment, called Java. So, you copy the safety features and then compare them with the copy source, and it allows you to claim that your "unmanaged" is better than managed. But why it's even possible to talk about safety and forget about the safety roots?

There's no difference in developer time between "compile time checks that detects the bugs, executable run in an unmanaged environment" and "compile time checks that detects the bugs, executable run in a managed environment that detects nothing because there's nothing left to detect".

It's enough to try to write something in Java or C# to have a picture of very probable runtime errors. And next goes the ability of the managed environments to speed the bug hunting. It is much more informative than memory dumps and register values after unmanaged program's crash.

Basically, for input validation you need to generate appropriate errors and deliver them in an appropriate way. While the run-time checks aren't avoidable, in this case the automatic checks done by a managed language are inadequate and solve nothing.

If business logic tells us that an age should start from 21, it doesn't tell us about program internals, where 21 can be transformed onto something outside of bounds. This kind of mistakes can be caught by bounds checking, but you think they "are inadequate and solve nothing", then you will got an application crash. Just because you are trying to ignore the whole class of bugs.

The sad thing is that it's an epidemic. There's whole armies of worthless wannabies churning out trash in all sorts of languages that are willing to slap together disposable puke for $2 per hour in their best attempt at proving Wirth's law.

The sad thing is about your perception of the situation. People just want to get their job done faster. It is the people's nature, but you prefer to think that it is something from aliens and can be exterminated. But it can't.

[Brendan]

Hi,

You're using the power of self-delusion. You're only looking at the advantages of "managed" (including advantages that have nothing to do with "managed" at all, like "large libraries reduce developer time") and ignoring the disadvantages.

Large libraries are always part of a managed environment.

Wrong. For example, back in the 1980's there were a lot of dialects of BASIC that were managed (or extremely close to "managed") that had no support for any libraries at all.

But they are not always part of an unmanaged language. Or if they are then there is a great mix of different libraries with same goals. It means managed environment much easily can be standardized than unmanaged. But you, of course, will say again "managed sucks" instead of looking more carefully at this advantage. And it is the problem

No, I'm going to repeat the fact that the existence of libraries, the size of those libraries, and whether or not the libraries are considered a standard part of the language or not; all have absolutely nothing to do with "managed vs. unmanaged" in any way whatsoever; and that you're a deluded fool for failing to understand that a few specific managed languages are not representative of "all managed languages" in the same way that a banana does not represent all possible fruit.

You're comparing Java to C and assuming that's a sane way to compare "all possible managed languages" to "all possible unmanaged languages".

All possible unmanaged languages just accept managed parts one after another. And the final result is a complete managed environment. So, what is a value of talks about "almost managed" vs "managed"?

None of that made any sense to me. There's no evidence to suggest that unmanaged languages (e.g. assembly, C) are accepting or have been accepting any "managed parts". There's no evidence to suggest that accepting a few "managed parts" leads to a managed environment either. I don't know how your last sentence (about "almost managed") relates to anything I said (especially the part you've quoted).

You're looking at things like (e.g.) Java throwing an exception because it couldn't open a file and claiming that it's awesome because in Java you can handle the exception; and forgetting that other languages (e.g. without exceptions) the "open()" function would just return an error instead (where the programmer can handle the error).

I just point that because of unsafe design the unmanaged languages crash always irrecoverably, but managed environments can keep 99% of functionality working.

For some badly designed unmanaged languages (but not other better designed unmanaged languages), and for some better designed managed language (but not poorly designed managed languages), if and only if the programmer felt like bothering; yes. However even in that extremely biased misrepresentation end users still don't care (it failed to do the 1% that the user wanted, so it's crap regardless of whether the other 99% works on not).

You're grossly over-estimating the number of things "managed" can detect that can't be detected by a suitably designed unmanaged language.

This "suitable design" just mimics the design of a managed environment or applies some hard restrictions on a developer.

That's an inaccurate and unsubstantiated assumption. The "compile time variable range checking and array bound checking" scheme I've described doesn't mimic anything a managed environment does, and doesn't impose hard restrictions on a developer.

Let M be the set of all possible managed languages; and MF be the set of all features that may be supported by any language in M. Let U be the set of all possible unmanaged languages; and UF be the set of all features that may be supported by any languages in U. Now find features that are in both MF and UF and remove them to find the difference. This is the difference between "managed" and "unmanaged".

We had already passed the point, when the difference between a "very close to managed" and "fully managed" was found to be the runtime environment. And I hope that I shouldn't repeat the differences between languages like C and managed environments, just because you have chosen the "very close to managed" variant and now are trying to compare it with managed variant, but arguing that managed sucks vs ANY unmanaged. Is it sane?

For "managed vs. unmanaged", it's not sane to compare any specific language to any other specific language (and you've been doing this in various ways from the start). The only fair comparison would be to compare the best theoretically possible unmanaged language to the best theoretically possible unmanaged language; but that's extremely impractical as it relies on a specific definition of "best" in addition to relying on languages that don't/can't exist.

That's why I was comparing "all things that managed might be capable of" to "all things unmanaged might be capable of". It's the fairest way to compare "managed vs. unmanaged" that is actually practical.

I've shown that detecting and preventing "out of bounds" bugs is a feature that is within UF.

You have shown, that you can imagine a very restrictive compiler, that prevents a developer from doing anything useful just because the compiler is not an ideal and can't determine all required variable ranges.

In which way would the compiler be restrictive? How does it prevent the developer from doing anything useful? How does not being able to precisely determine all variable ranges make any difference in practice (given that it can always imprecisely determine variable ranges)?

Next you call your language with such compiler "unmanaged" and tell me that your language is even more safe, than any managed language. But you refuse to see that the whole safe approach became popular just because of the existence of the managed environment, called Java. So, you copy the safety features and then compare them with the copy source, and it allows you to claim that your "unmanaged" is better than managed. But why it's even possible to talk about safety and forget about the safety roots?

Um, what? The idea of making programming languages safer has existed ever since the first higher level languages in the 1940s and was not made popular by some time travelling Java junky. When Java was first released (in 1995?) very few people cared. It didn't get more popular until 10 to 15 years later, when Universities started using it for "introductory programming" courses and Smartphones started using it (but not because it's managed and more because of portability - due to using platform independent byte-code as the "thing end users download" and because the standard libraries covered things like GUIs; which can both be done for "unmanaged"). Java, despite being newer/more modern, is still less popular than C.

There's no difference in developer time between "compile time checks that detects the bugs, executable run in an unmanaged environment" and "compile time checks that detects the bugs, executable run in a managed environment that detects nothing because there's nothing left to detect".

It's enough to try to write something in Java or C# to have a picture of very probable runtime errors. And next goes the ability of the managed environments to speed the bug hunting. It is much more informative than memory dumps and register values after unmanaged program's crash.

I'd still rather find bugs faster/sooner (at compile time) instead of using a slower method like run-time errors and investigating the variables contents (and not memory dumps or registers) using GDB or VisualStudio's debugger (or whatever the debugger for Java is that provides identical functionality to the debuggers for unmanaged languages).

Basically, for input validation you need to generate appropriate errors and deliver them in an appropriate way. While the run-time checks aren't avoidable, in this case the automatic checks done by a managed language are inadequate and solve nothing.

If business logic tells us that an age should start from 21, it doesn't tell us about program internals, where 21 can be transformed onto something outside of bounds. This kind of mistakes can be caught by bounds checking, but you think they "are inadequate and solve nothing", then you will got an application crash. Just because you are trying to ignore the whole class of bugs.

Um, what?

Imagine you write a program that display a dialog box asking the user to enter their age; and the end user types in "13". Now what? You call a function to convert the string into an integer ("age = Integer.parseInt( stringFromUser );" and do nothing else because the managed environment automatically knows that 13 is too small and generates a nice error message?

No. You wrap that in a bloated exception handling mess (because "parseInt()" does it's own run-time checks that throw), then you add your own additional "if(age < 21)" run-time check after that, then you add more code to display a "Sorry, you're too young" dialog box; and the reason you have to do all of that is because "managed" was pathetically inadequate puss that solved nothing.

The sad thing is that it's an epidemic. There's whole armies of worthless wannabies churning out trash in all sorts of languages that are willing to slap together disposable puke for $2 per hour in their best attempt at proving Wirth's law.

The sad thing is about your perception of the situation. People just want to get their job done faster. It is the people's nature, but you prefer to think that it is something from aliens and can be exterminated. But it can't.

Which people? End users want to get their job done faster - that's why they're using software (e.g. instead of pen and paper) to begin with. That's why almost all OSs, high performance computer games, compilers, database management engines, web browsers, etc are written in unmanaged languages (and often really bad unmanaged languages). It's because developer time is less important than end user time.


Cheers,

Brendan

[embryo]

It's because developer time is less important than end user time.

Yes, Brendan, in an ideal world it is. But in our "not so ideal" world there is a need for automation of every possible developer's move, even if it costs much more for end users. And in essence we are talking about automation limits. You limit it by the phrase "no performance loss". But the world still wants unlimited automation, would it cost some performance or not. And the progress in languages and software environments just reflects the demand. It creates new software with better automation and cares too little about performance. For example the very popular JavaScript framework node.js is just a horrible performance killer (even if it is claimed as very fast), but it's use is so popular for high traffic sites, that it already has outperformed Google's back-end.

But you still believe in a old fashioned "good" developer, that spends a lot of time to deliver 99.9% bug free product instead of 95-99%. Meantime, those "not good" developers deliver times as much of a software and catch orders of magnitude bigger market share. And it is the automated tools, that help to catch the great market share. And it is the managed environments, that employ the automation at it's best possible level. And it is even your compiler, that employs automatic checks as much as possible and frees a developer from doing it manually.

So, the automation rules the world, the performance loss is seen as not important by the world, the old styled "good" programmers work hard, but achieve almost nothing in terms of market share. That's why managed environments have a great leg up over unmanaged languages.

May be sometime you will invent a way for old styled developers to catch the market share and show the world the best possible quality, but the world looks scornfully at such efforts and it is up to you to fight the Goliath, if you have enough time and courage.

[AndrewAPrice]

About "managed languages" and bugs.

As being employed as a professional developer at a large corporation for over 3 years, I deal daily with languages like C/C++, Java, C#, Perl, Javascript.

Very few errors in the business world are memory leaks (which can still exist in managed languages with automatic garbage collection if you have some object holding onto a long forgotton table) or out of bound array indices.

Most bugs have to do with the business logic, and they're not things that cause the program to error, but things the end user picks up on (funny control character in the output file that only occurs in this one particular situation, a GUI screen isn't populating correctly).

In my experience, bugs tend to be more frequent in managed languages because they're perceived to be safer.

Imagine we are designing streets, and we want them to be safe. We can try to engineer the street to be safe by incorporating a bunch of safety features - wide lanes, traffic lights, we clear any obstacles like trees and buildings and set them way back. As a result, people perceive it to be safe so they drive faster.

Imagine we have another street. The lanes are narrow, there are benches and trees everywhere. It's perceived to be unsafe, so people drive slow and cautiously.

Yet which one is safer? The one that is perceived to be unsafe, because people are driving slow and cautiously because they're expecting the unexpected (like people crossing or a child running out).

Safety in a managed environment:



Safety in an unmanaged environment:

[Combuster]

*has to notice the Dutch are being used as an example*