@bluegreen
> Well since you ask java doesnt' do deterministic finalization because [reasons]
>It's more complicated than you made out. Generational, Mark-sweep, compacting -- none of these can immediately pick up all dead objects. The only thing that can approach this is reference counting which has other problems (speed, overhead), and still can't make immediacy guarantees (consider cycles).
>More: <http://msdn.microsoft.com/hi-in/magazine/bb985010%28en-us%29.aspx>, look for "There are several reasons for this" for a summary, but this doesn't do justice. Conflating garbage collection and object finalisation was recognised as a bad idea back in the 80s by Modula 3's designers, but Java's creators were too witless to learn the lesson (like so many others they fail to learn), so Microsoft had to follow on and we all move backwards, again.
Agreed, more to it than meets the eye.
Re Actor, I've come across that before, but thank you for the link.
Re Design/Frameworks/language stuff,
I suppose my point is just that most errors security or otherwise are design flaws that can be eradicated if you want to throw enough time/money at the problem.
The MSDN link has a nice example on it, take this part when referring to c# finalizers vs c++ destructors "Don't let the identical syntax fool you." (this is a design flaw, two separate concepts that are easily conflated, with the same syntax)
Re Erlang/Concurrancy
It's more that there are messages buses like rabbitmq that do the heavy lifting, I'm know you can do the same thing in other languages but this works out of the box for my application needs YMMV.
Using a message broker e.g. rabbitmq, just makes the producers/consumers simpler to write, they aren't aware that erlang/rabbitmq is used.
nice. that aside, it's quite a balanced article, again ta for the link.
Re java pre-processor,
I made a crude attempt at this years ago (pre-java generics), using java as the output from a simple generation language that added explicit calls to allow *more deterministic* code. Generics replaced 95% of the benefit of my little tool, so I mothballed it. But using Java pre-processing is already here, I think (too lazy to verify) at least one of the google tools pre-processes some other language into java, and annotations while not preprocessing in the trad sense surely blur the line.
using C++ would work too.
> think peer nodes associations
this patent troll explains it quite well http://www.faqs.org/patents/app/20080307094
> 5) Strategies exist in languages with determinstic finalization e.g. allowing resource management to be implicitly bound to object lifetime with the language doing the work rather than the developer.
>I think you are thinking of C/C++ where object lifetimes are explicitly and sharply delimited by free() or implicitly by subroutine returns. It is reasonable, I suppose, to ask that Java provide some kind of equivalent to smart pointers so things happen automatically on subroutine returns, but there's not much you can do about other objects you intend to have longer lives. If you want deterministic deallocation for "local" variables, you have to wrap a try/finally around the routine body.
I was, and I accept that smart pointers won't solve everything.
> 6) A data point, there are plenty of garbage collectors for C/C++ yet GC is not that widely used for what ever reason, perhaps because of point five).
These are conservative garbage collectors (I'm sure wiki has an article. Read up on them and have nightmares) and they don't provide the behaviour you are asking for.
I know what they are, cheers.
> 7) These stategies are examples of designing out problems rather than coding round them, using say explicit calls to synchonization primitives like mutexes.
I don't know what you're saying that I have a tendency to build frameworks to hide grubby detail in the same way that you suggested wrapping realloc(), but typically on a bigger scale. I guess that's easy to say though.
That realloc bug is present in a decent proportion of C code from compilers to virtual machines, that's a pretty big R-O-I for ~15 line of code, that designs out the error rising from the disparity between how people percive realloc() and how it's specified by the C standard.
Exactly as C# finializer syntax reintroduces the "realloc bug" by virtue of the disparity between how people percive "~foo" in C# and how it's specified by the C# specification/standard.
Design Again:
For example when you enter a numeric value in an application ui/ (This is more about preventing cockups rather than malice)
1) you can enter a number into a text input field then validate
2) pick from pre-verified data e.g. valid numbers from drop down.
13)I don't think resource/memory management too big a deal,
then you're a better person than I.
I'll take your word for it ;) but I only meant that shared resource management problems are well documented and understood, distributed resource/concurrency access issues are less well understood.
> (re. erlang) I don't have memory leaks,
Hmm. Is that because Erlang has a garbage collector?
No, it's because it's implements the non-shared state concurrency model in a functional language which *has a garbage collector* :)
Pint, because I need one, why don't you join me in raising a glass.
Biting the hand that feeds IT
