Managed Objects

[Swami With The Salami]

...this is no reason why manual memory management is better...

Manual memory management vs. what? Automatic memory management? Is that really a thing? A garbage collector does not automatically solve memory management issues, not by a long shot.

For example, as I implied before, when does the garbage collector kick in? I'm sure the day will come when you run into a programmer in short pants hanging on to some seemingly insignificant property of an expensive object just so he can display "foo" somewhere in the corner of a dialog box (or whatever). The point being the garbage collector will not release the memory associated with an object so long as any part of it is in reference anywhere. This is the sort of thing you need to think about when you consider memory management. Being able to skip writing "free" a hundred times isn't an advantage at all. In fact I believe that it is easier (and more appropriate) to search for missing calls to "free" than to try to find those "needle in the haystack" seemingly insignificant properties referenced in unwarranted spaces. Capiche?

Managing memory is really a core fundamental practice - there are no short cuts. Garbage collection is crap. There is no excuse.

[Warfley]

Managing memory is really a core fundamental practice - there are no short cuts. Garbage collection is crap. There is no excuse.

Interesting for a guy claiming that the past 30 years of CS research are wrong you surely do not provide any evidence other than your personal opinion.

As I said, this is not up to debate, we have decades of research on this. You obviously have not really a clue on the matter. So it is pointless discussing this further.
For example you write your response as if unfreed memory is the big issue that automatic memory management tries to solve. Anyone with just the slightest bit of knowledge in the topic knows that the main risk is actually use-after-free not to forget to free. Infact memory leaks are quite easy to detect and can at worst just increase memory usage to the point the OS kills your process. Use after free on the other hand can open completely unpredictable bugs and is the main cause for security vulnerabilities.
And use-after-free is completely eliminated by garbage collection or ARC

[440bx]

As I said, this is not up to debate, we have decades of research on this. You obviously have not really a clue on the matter. So it is pointless discussing this further.

It doesn't take "decades of research" to find the many downsides of automatic memory management.

Anyone who has used C# to write a program that goes beyond "hello world" should be quite aware of the unnatural code that is often required to "inform" the garbage collector that some block can be collected and, the converse is also true, there are quite common cases were the natural solution cannot be implemented because it would make the garbage collector "think" that a block of memory has been freed when it hasn't.

Add to that the problem created by some Windows APIs that allocate memory behind your back, which the programmer is left with the responsibility for freeing, and garbage collection is more of a problem than a solution because it is yet another thing the programmer has to cater to (will the garbage collector be happy if I do this or that ???... why would a programmer want yet one more thing to worry about ?)

Garbage collectors are for wannabe programmers.  That's the real problem they "solve".

Garbage collectors are the TV Dinners of the modern "Chef".  Move over Thomas Keller, here comes Chef Boyardee!.

[Warfley]

It doesn't take "decades of research" to find the many downsides of automatic memory management.

Anyone who has used C# to write a program that goes beyond "hello world" should be quite aware of the unnatural code that is often required to "inform" the garbage collector that some block can be collected and, the converse is also true, there are quite common cases were the natural solution cannot be implemented because it would make the garbage collector "think" that a block of memory has been freed when it hasn't.

I love when someone shits on research and follows it up with a statement that is purely and utterly wrong. But this is at least a great example whats the difference between actual research and a random unfounded opinion on the internet. Because thanks to Microsofts research we know that CLR code (the Bytecode produceded by the C# Compiler) is "verifiably safe", meaning the .Net tooling can prove that it does not contain any memory management errors. This means that the "garbage collector thinks that a block of memory has been freed when it hasn't" as you put it, is literally mathematically impossible. The only exception to this is if you explicetly use the "unsafe" keyword to write unsafe code. And obviously if you deactivate the garbage collector, it will not provide memory safety.
Also C# uses generational garbage collection, so the garbage collector does not collect "blocks" or needs to be informed about "blocks", because it always collects the whole memory at once.
So your statement above is just completely factually wrong.

Going back to the research, we know that garbage collection on a strong type system like the CLR has, is verifiably safe and correct, and that it cannot introduce any new bugs. But you are right in some respect, garbage collection is not perfect, it's stop the world apprach can result in performance problems in certain (edge) cases. Even though modern garbage collectors are really fast (MS claims their Gen1 GC is taking less time than a page fault), this can lead to a bad user experience, e.g. if the GC starts in the middle of some animation, making it stutter. This is why most garbage collected languages like C# allow you to manually call the garbage collector. But the thing about this is, this is just purely an optimization to optimize the user experience. It does neither introduce nor solve any bugs. As I said, garbage collectors are provably correct.

But for some applications this stop the world approach may not be that feasable, this is why for example Swift does not use a garbage collector, but automatic reference counting (ARC), which as I explained above has some other drawbacks (mainly thread safety and cyclic references).
But also ARC introduces some computational overhead, a bit different from GC, which basically freezes your application every once in a while, but just a constant overhead whenever you pass a reference. In the very most applications this does not matter, but in extremely performance critical applications like Operating Systems or Browsers, this may be a problem. Thats why there usually no Automated Memory Management is used. But exactly to target this problem Mozilla started developing Rust, a language which can prove memory safety at compile time. This comes at the cost of expressiveness (i.e. not all memory safe programs are provably memory safe therefore you may have to rewrite things to fit rusts memory model), but it allows to have automatic memory management at a true 0 performance cost.

Long story short, yes there are some problems with different types of automated memory management. But thats not "despite" the research, but we are doing the research exactly to figure these problems out and to find better solutions. Microsoft managed to make generational garbage collection insanely fast. Mozilla developed a whole new language with a custom type system which makes it impossible to make memory errors at compile time.
But you know what all this billion dollers worth of research didn't point to? Going back to manual memory management. Even though we know all of these problems with the different automated approaches, no one is seriously considering using manual memory management instead

[VisualLab]

I've heard it said many many times (and more frequently as time passes) that OOP is a mess. There may be some validity to that but I'm too simple to understand. OOP is the only thing I am passionate about when it comes to programming.

You're right. There are a lot of different blogs or videos on the Internet (e.g. on YouTube) where different people try to prove that OOP is bad, or even how bad OOP is. They evoke statements such as "Alan Kay imagined it differently" or "Linus Torvalds believes that nothing better has been invented since C." Some of these people believe that there should be a return to structure- and procedure-based programming (like old-fashioned C). Another group tries to argue that only functional programming solves all the problems of software development. Meanwhile, it's a mix: bits of true statements, urban legends, and plain nonsense. Probably these people don't understand what OOP is really about and how it works. And maybe they can't handle complexity (as a phenomenon) either. They don't accept that this is simply modularization. An idea that appeared earlier in the industry: automotive, household appliances, construction, etc. Of course, it takes time and patience to understand it. Like any technical field. It's just that technical solutions are getting more and more complicated, so the tools are also getting more complicated. There are no miraculous remedies. Unfortunately, among many programmers, there is a behavior that could be described as: sectarian. Some of them believe in click-baits like: “He discovered this one wonderful way of creating software. Professional programmers hate him."

The fact is that OOP is implemented differently in different languages. This is the difference in the details. Some languages have very extensive OPP (C++, Object Pascal, Java) and others are based on stripped down or even primitive and naive OOP models (JavaScript, Python, PHP). They pull out those little details (flaws or nuisances) and generalize to the whole OOP approach.

And like you, that's why I program because I "like" OOP. Simple C languages can be useful for creating programs for microcontrollers (e.g. Arduino). However, in 10-15 years, C will probably fall out of this market, because 32-bit microcontrollers with large RAM and Flash memories will be used en masse. And then it won't pay off to "fight" with C. Or C will be replaced by Rust or Zig.

[Swami With The Salami]

Anyone with just the slightest bit of knowledge in the topic knows that the main risk is actually use-after-free not to forget to free

Let's limit our focus to this problem alone. In the traditional approach addressing an object after it has been freed will produce an access violation. That is completely understandable. On the other hand if we address an object long after it was first instantiated a garbage collector will not complain, the program will keep on ticking because the memory has not been released.

Reflect on that for a few minutes.

At the risk of sounding hostile may I add that "30 years of research" is a completely incoherent phrase. We can find "30 years of research" by experts in any field (climate change anyone?) arguing both sides of any subject. The unmitigated fact is you can not write a program to run for an extended length of time without making an effort to manage memory. A garbage collector is indeed the equivalent of a "TV Dinner" (thanks 440bx).

There is absolutely no reason whatsoever to believe that programming techniques today are more advanced than they were fifty years ago. I'm not an expert outside of Pascal but isn't Python just a wrapper around C? What is beneath Java and C#? It is frightening to think that so much of our infrastructure today relies heavily on libraries adopted by people that never read RFCs.

Pascal is a strongly typed language. Perhaps it is too strong but many of us appreciated that.

[440bx]

I love when someone shits on research and follows it up with a statement that is purely and utterly wrong.

It would actually be hard to "shit on research" since, while you claimed there is research on the subject, you provided absolutely none.  In your case, the best someone can do is shit on nothing. 

On the other hand, while I am not inclined to waste my time, I'm sure I still have some of the ebooks on C# where there is more than one occasion when the author specifically mentions "do this or do that" because of the need to keep the garbage collector informed.  Actually, I'll state it upfront, I won't waste my time finding them.  It was enough to waste my time once when I ran into those garbage collector problems.

Because thanks to Microsofts research we know that CLR code (the Bytecode produceded by the C# Compiler) is "verifiably safe",
meaning the .Net tooling can prove that it does not contain any memory management errors.

Yes, that is true as long as you're writing fairly trivial programs or you  don't mind writing programs that are so inefficient that they border on being garbage (they should self collect!.)

This means that the "garbage collector thinks that a block of memory has been freed when it hasn't" as you put it, is literally mathematically impossible. The only exception to this is if you explicetly use the "unsafe" keyword to write unsafe code.

It's a bit of a problem when using O/S APIs is considered "unsafe".  If O/S services can't be used, it's going to be a challenge (mathematically impossible ?) to write a useful program. 

I cannot emit an opinion about Rust or even Java about their memory management features simply because I am not familiar enough with them but, at least in the case of Java, aside from leaving a lot to desire performance-wise which is likely in part due directly or indirectly to automatic memory management, I've noticed some rather "peculiar" behavior in some "professional" Java programs (some authored by Oracle itself.)

Manual memory management, when done correctly, leads to simplicity and superb performance, two characteristics I have not seen in any C# or Java program so far (but I admit, I have not spent a billion dollars doing research looking for that mythical unicorn.)


On the subject of OOP being a poor paradigm, I am definitely in the camp that considers it to be that way but, it isn't a subject I enjoy discussing as it is invariably fruitless and futile.  That said I have written a number of posts in the pasts that, to some extent, explains why.

While I'm at it, I don't enjoy debunking the shiny non-sense about automatic memory management but, I don't think it should be left unchallenged.  "Chefs" that cook boxed lunches in microwave ovens find manual cooking to be nothing but laborious (while completely ignoring the difference in the results.) 

[Warfley]

Let's limit our focus to this problem alone. In the traditional approach addressing an object after it has been freed will produce an access violation. That is completely understandable. On the other hand if we address an object long after it was first instantiated a garbage collector will not complain, the program will keep on ticking because the memory has not been released.

Reflect on that for a few minutes.

I've reflected on this exactly 51.7 seconds, which is how long it took me to write this simple program:

Code: Pascal  [Select][+][-]

1. procedure Test;
2. var sl1, sl2: TStringList;
3. begin
4.   sl1 := TStringList.Create;
5.   sl1.Add('Hello sl1');
6.   sl1.Free;
7.   sl2 := TStringList.Create;
8.   sl2.Add('Hello sl2');
9.   WriteLn(sl1.Text); // Use after free
10. end;

This clearly is a use after free, but guess what, no access violation, but infact it prints 'Hello sl2', which is not the text I have written into sl1. Again you demonstrate that you are discussing a topic you clearly have not much knowledge about.

It's a bit of a problem when using O/S APIs is considered "unsafe".  If O/S services can't be used, it's going to be a challenge (mathematically impossible ?) to write a useful program. 

You can embedd unsafe code within a safe class, where the Finalizers (Destructors) will call the unsafe free. This way when the class is freed, the unsafe code will also be freed. This is how already Microsoft embedds alot of WinAPI functionality into .Net classes, and if you do this you get the same provable guarantees even for the inherently unsafe code.

I cannot emit an opinion about Rust or even Java about their memory management features simply because I am not familiar enough with them but, at least in the case of Java, aside from leaving a lot to desire performance-wise which is likely in part due directly or indirectly to automatic memory management, I've noticed some rather "peculiar" behavior in some "professional" Java programs (some authored by Oracle itself.)

Manual memory management, when done correctly, leads to simplicity and superb performance, two characteristics I have not seen in any C# or Java program so far (but I admit, I have not spent a billion dollars doing research looking for that mythical unicorn.)

Rust has literally a net 0 performance impact, because all the memory safety computations are done at compiletime. No additional runtime code is required to get memory safety in rust.

And in your last sentence is the key: "Manual memory management, when done correctly,". The point is that you can't do it correctly. As I already shown examples of multiple times, memory management is one of the main driver for errors, and one of the severest problems in terms of security vulnerabilities.
If you could just do it correctly, no one would bat an eye, but the point is that thanks to the research we know that programmers, even extremely skilled programmers (as both Google and Mozilla only take the best of the best), just can't do it right.
If we would all write bug free programs, then C would be the optimal language, but it's not a good language, but it's not, because we do make mistakes, and C is very bad at preventing you from making mistakes. In a world where all programmers will make mistakes eventually a good language is a language that prevents them from happening

It would actually be hard to "shit on research" since, while you claimed there is research on the subject, you provided absolutely none.  In your case, the best someone can do is shit on nothing. 

Well I've already posted both the evaluation of Mozilla as well as of Google on the number of security critical (where Google found that 70% of their security critical bugs where memory errors).
And if you want to search some other sources, as I said there are mountains, the first one I've found comparing bugs between C++ and Java with analysis of types of errors is https://www.lanl.gov/projects/CartaBlanca/webdocs/PhippsPaperOnJavaEfficiency.pdf

The main cause is most likely to be Java’s safe memory model. The hardest and most time consuming bugs to remove in C++ are those caused by bad pointers and other mistakes made in memory management. Java has eliminated these
errors, so it is not surprising that the mean time to fix bugs has dropped. The bug and defect forms did not include a separate category for memory problems, such problems were included in the heading ‘control flow’. In fact, 90 per cent of bugs were ‘control flow’, with ‘class
design’ and ‘method design’ each accounting for another 5 per cent. Therefore the study cannot definitively say that C++’s memory is the cause.

I know from one of our previous discussions how you stand to research, where I reviewed all the studies I could find on the maintainability of OOP vs procedural programs all coming to the same conclusion that OOP is improving maintainability, and all you responded was akin to "look at my hex editor". So I know this is just wasting my time. You don't care for the results of research when they contradict your personal (factually wrong) opinion.

[Swami With The Salami]

...you demonstrate that you are discussing a topic you clearly have not much knowledge about.

You are talking about stale pointers. I wish I had realized that sooner - I'm sorry. I am seeing your argument in a different light, thank you.

[440bx]

And in your last sentence is the key: "Manual memory management, when done correctly,". The point is that you can't do it correctly. As I already shown examples of multiple times, memory management is one of the main driver for errors, and one of the severest problems in terms of security vulnerabilities.

I will grant you that, programmers in general don't seem to be as knowledgeable as they should be when it comes to memory management, leading to "undesirable" situations.  The fact that some programmers lack the ability to do it correctly does not mean that deficiency is shared by all programmers.

Memory management is like every other aspect of programming, it should be part of the application's design.  Personally, I see it as fairly simple and, definitely simpler than having to continuously account for the idiosyncrasies of a garbage collector.
 

[Warfley]

Memory management is like every other aspect of programming, it should be part of the application's design.  Personally, I see it as fairly simple and, definitely simpler than having to continuously account for the idiosyncrasies of a garbage collector.

I must grant you one thing, which I think is not to underestimate here. If I remember correctly you don't use OOP, i.e. no classes and even no objects. Whenever I wrote procedural code (I used to write a lot of C code), there simply is not as much memory management as in the OOP world, where due to inheritance, abstract classes, etc. you must always use the heap for everything (and with Classes literally as without hacks you can't put them on the stack even if you want to)

So your experience on how easy/hard memory management is, may not be the same as someone who is using classes for everything.

[440bx]

So your experience on how easy/hard memory management is, may not be the same as someone who is using classes for everything.

I have to agree with that.  I see all the problems/difficulties OOP programmers deal with and I can't help but wonder why anyone would want to deal with all that (but, I guess I know why... I just won't say it.)

[Ryan J]

I have to agree with that.  I see all the problems/difficulties OOP programmers deal with and I can't help but wonder why anyone would want to deal with all that (but, I guess I know why... I just won't say it.)

It's not about OOP or not but reducing the number of lines of code and complexity. Consider some procedural code that creates a list (reads lines from a file for example) and iterates over it:

Code: Pascal  [Select][+][-]

1. function CreateList: PList;
2. begin
3.   result := GetMem(sizeof(TList));
4. end;
5.  
6. var
7.   list: PList;
8.   i: Integer;
9. begin
10.   list := CreateList;
11.   for i := 0 to list^.count - 1 do
12.     ;
13.   FreeMem(list);
14. end.

Now consider the same code (with an enumerator on the list) which creates a list and the compiler knows to free the list at the end of the scope (a managed type/smart pointer etc...).

This is the easier to read and less error prone right? I don't see this has anything to do with OOP but rather a compiler that doesn't help us manage memory in an easier way. I don't mean a new totalizing memory paradigm but rather just an opt in feature. I fail to see why this isn't a good thing....

Code: Pascal  [Select][+][-]

1. var
2.   item: TItem;
3. begin
4.   for item in CreateList do
5.     ;
6. end.
7.  

[440bx]

I don't see this has anything to do with OOP but rather a compiler that doesn't help us manage memory in an easier way.

The syntactic sugar is a direct consequence of OOP. 

One thing that will always be true, for OOP or any other deficient paradigm, is that if the analysis only takes into account the advantages and purposely chooses to ignore the many disadvantages then, the approach will always be "great".

That said, I have to concede that this thread is about "managed objects" therefore it is fair to implicitly (but still improperly) limit it to that subject.

Anyway, I have written a good number of posts in the past shedding light on the many problems in OOP.  I do not intend to beat that dead horse.

[SymbolicFrank]

If you use the new programming paradigm, for web, the idea is that you pass everything as parameters. Like we did in C. This can become rather cumbersome, so it seems like a good idea to store the state in a single structure, like a session variable. Which can be a record, or a class, or whatever.

The thing is, if you do that, it'll start to grow. All your state goes in there, but also parameters that you have to pass along. And you might want to cache stuff from the database, etc. When you consider each handler a separate process, that's basically the same as making everything global.

It does make memory management easier, as it is discarded when the process terminates. Then again, the idea behind this new way of programming was to make everything scale optimally. If you allocate and initialize the maximum amount of memory a process needs on startup, you probably missed that goal.

The solution to that problem is currently: micro-services. But I'm not sure that fixes it.