The beauty of a university (even in this age of patents, industrial parks, and spin-offs) is that in theory any problem can be investigated without having to be justified.
That may well be the theory. The practice is very different. Research (even "basic" research) requires funding to pay for time, equipment, and grad students. That means you need to be able to sell a funding agency on what you are doing. Which in turn means that you need to be able to justify your research somehow. Now, granted, you don't necessarily need to be able to show a direct commercial use. But you do need to provide some kind of justification.
Better hope that "minimal embedded OS" he's using isn't running on a "minimal embedded system" as well. Otherwise 2-3 MB of VM may well be out of the question.
BTW, threads of any sort suck as a parallelism primitive. A better choice would be CSP-style process networks, as implemented in occam and C++CSP. Erlang implements a similar (but not identical) concurrency model.
Why would you want to use a CSP-style concurrency model instead of threads? To quote from the occam compiler homepage:
CSP has a compositional and denotational semantics, which means that it allows modular and incremental development (refinement) even for concurrent components. In turn, this means that we get no surprises when we run processes in parallel (since their points of interaction have to be explicitly handled by all parties to these interactions). This is simply not the case for standard threads-and-locks concurrency, which have no formal denotational semantics and by which we get surprised all the time.
In layman's terms, you get concurrency that can be built up from easily understood pieces (instead of a monolithically concurrent system with locks scattered throughout the code), and an underlying theory of concurrency that lets you understand and analyze your design and ensure that it is, for example, free of deadlocks (I've personally created complex networks of 1000+ interacting processes in a dynamically evolving topology, with nary a hitch). And did I mentioned that the context-switching performance of most of these systems is amazingly good?
...a controversial system that would significantly change how the Internet operates. Some say Small Firms Could Be Shut Out of Market Championed by BellSouth Officer. William L. Smith, chief technology officer...
Nice to see the/. editors are doing their job. Not.
I mean, I expect to see some grammatical "idiosyncrasies" in most/. articles, but usually I'm able to decipher what it is they're really trying to say. In this case, I have no clue. I'm assuming it's a case of sloppy cut-and-paste. The least the editors could have done was to remove the totally incoherent parts...
It's pretty clear that a reduced level of global coolness caused by a lack of pirates would result in increasing global temperatures, and we have in fact observed such a predicted upswing in temperatures. It's less clear how factors such as increased atmospheric carbon dioxide, reductions in solar output, or any of the other things driving Earth's natural warming/glaciation cycle might contribute.
Ummm, that wasn't your original point. You may have meant it to be, but it wasn't.
The original subject line: RAII is a bad reason for manual memory management (it's still the subject line now). Is manual memory management always a bad idea? No. Nor did I ever claim that it is a bad idea. What I said was that a desire to use the RAIInit idiom is not a good justification for manual memory management (specifically, because there are alternative idioms that work just as well in GC languages). I also asked for some other (i.e. non RAIInit-based) justification for manual memory management. Predictable object destruction is a perfectly good reason for manual memory management, and I'm certainly aware that there are applications that may require it. But that isn't the reason the original article gave.
Besides, you can't abandon GC if you've never adopted it...
Which would explain why I said
If those languages are garbage collected, and you want some kind of RAII-style resource management, then yes, I suppose so - RAIInit won't work. Otherwise, by all means use RAIInit.
The second sentence is about languages that are not GC (and thus would not need to abandon GC).
Frankly, I'm a little confused about what you're trying to argue about here. You started by asking wanting/needing the initialization idiom, moved to the need for constructors, and eventually ended up at manual memory management being necessary for some tasks (because of reasons other than a need for RAIInit). So, what exactly are you trying to say that contradicts my original (and continuing) point, that "RAII is a bad reason for manual memory management"?
For those myriad langauges for which it is not a part, are we supposed to do all the extra work of implementing it?
If those languages are garbage collected, and you want some kind of RAII-style resource management, then yes, I suppose so - RAIInit won't work. Otherwise, by all means use RAIInit. My original point stands: RAIInit is not a good argument for abandoning GC.
So where's the big push for file handle collection?
Performing "file handle collection" (or "lock collection") would leave you in the same boat that attempting to use finalizers for closing files in a GC language would land you: files (or locks) would not be guaranteed to be closed (or released) at a predictable time. For the majority of applications it isn't necessary to have completely predictable object destruction (which is why GC can be used), but predictable file and lock release is a necessity.
Lisp's unwind-protect is the prototypical "RAI as Invocation" idiom. Plenty of other languages implement it though (Haskell and ML come to mind). The presentation at C2 is pretty generic, and not tied specifically to Lisp.
As some of the folks at C2 pointed out in the originally linked references, RAIInitialization is a misnomer anyway (as is RAIInvocation - but that was created in response to the other RAII). Most of what we're talking about here is (despite the name) finalization. That's the part that conflicts with GC. No one's saying that we should eliminate initialization or constructors. The point is that using the RAIInit idiom to handle resource finalization is not a good argument for manual memory management, because the RAIInvoc can produce the same finalization effects without producing any conflict with garbage collection.
Can I just mention that I hate the term 'cyber' when it's used as some kind of signifier that a term is related to computers or the 'net. Possibly more than I hate 'e'-whatever. I blame William Gibson for introducing this usage, and the US government for propagating it. I wish it would stop.
The invocation idiom does the same thing as the initialization idiom. It just implements it in a different way. A way that doesn't depend on whether or not you are using GC. So why would you need/want to use the initialization idiom?
Sure. But the original question was about reasons for manual management other than performance. Plus, as others have pointed out in this thread, the performance of GC-based systems is not necessarily any worse than that of a manually managed memory (even using custom allocators) depending on how the GC is used and how complex the things you're doing with allocated memory are. More importantly, for many applications GC is not the performance bottleneck, even when it does have lower performance than a manually managed solution. You have to look at the complete system, not just individual features of it.
All of the reasons given for manual memory management seem to boil down to a desire to have support for the Resource Acquisition Is Initialization (RAII) idiom, which is hard to pull off in GC languages. But, the alternative idiom Resource Acquisition Is Invocation provides the desired capability in GC languages. Same capability, no chance of memory leaks. So tell me again why manual memory management might be a good idea?
So, you really think that with Al Gore in office we would currently be occuiping Iraq?
It's hard to say. Who knows what Gore would have done in the aftermath of 9/11. Would we be in exactly the position we are now? No, probably not. Would we be in a somewhat similar position? Possibly. Congress as a whole passed the USAPATRIOT act. Congress as a whole was very much behind invading Iraq in the early days. Now granted, you can claim that's due to intel-spin on the part of the Bush administration. But that doesn't mean we wouldn't have ended up in a similar quagmire in Afghanistan (which Gore might well have invaded) instead of Iraq - part of the reason we're not is because we attracted all the loons to Iraq instead (and if you think Afghanistan wouldn't have turned into a quagmire you have only to look at the Soviet experience there).
Do you think with him in office that the Republican tax cut agenda would have passed?
Who the hell knows. Clinton sure passed a lot of stuff that was traditionally considered "Republican" policy. Time was the Republicans were the party of fiscal responsibility and small government. Then they got into power. The reality is that both parties are made up of wealthy individuals, and both parties are beholden to corporations and wealthy sponsors.
Look at the cronies that Bush appointed to the various Federal agencies (Brown comes to mind). Look at the Executive Orders he has issued withdrawing support from doctors who advocate abortion overseas. Look at the tacit support for torture. Don't you dare tell me that all of those would have happened with a Democrat in office.
Do you honestly believe that those things are a function of Democrat vs Republican principles, rather than Bush as an individual being morally corrupt? I mean, were Clinton's last-minute pardons for various wealthy folks a function of Democratic principles? These kinds of things could have happened on either party's watch.
I will grant you that abortion is an iffy issue. But I honestly believe that it has less than you think to do with DvR: IIRC Kerry was hedging quite a bit on abortion, as have numerous other recent Dem candidates. And it's one issue among many. Is abortion the only real, major policy difference between the two parties? Have we honestly come down to voting based on that one issue alone?
It's not rhetoric to the people that care about those issues.
It's rhetoric if it's a bunch of words that are used to get people on your side when you have no intention of actually doing anything about the issues in question. Yes, people care about those issues. That's why the two parties use those issues. But there's a difference between talking about an issue, and actually doing something about it.
Like you aren't using rhetoric to scare people away from voting for a major party candidate they like?
Am I? I certainly didn't intend to do so. You can vote for whoever you like. I'm just pointing out that voting for either of the major parties will produce effectively the same result. If you like that result, then, by all means, vote for them.
Whether or not you'd agree with it there are major differences between the two parties.
Asserting that something is so doesn't make it so. You claim there are major differences. I say there aren't. You point to "policy differences". I claim that those are a smokescreen, because none of them turn into legislation, nor are they likely to any time soon. Show me real, major differences between the actual legislation produced by the two major parties. Don't just claim that there's a difference, without providing any proof that there is one.
Rather than railing against the Java-haters, why not point out some useful, slick, fast Java-based applications?
I've had a pretty good experience with jEdit, a Java-based programmer's editor on both Linux and OS X. It's mostly replaced emacs for me now. Although I've only tinkered with Eclipse so far, it's been pretty responsive for everything I've tried. On the Mac, NeoOffice/J (the OS X port of OpenOffice.org, which relies on Java for access to the Cocoa API) seesm to run pretty well. Granted, these are all editing apps, but they're all produced by different dev teams, and all seem to work well.
You know, I really get sick and tired of hearing this. Of all the issues that you have listed, how many are actually seriously likely to get implemented anytime soon? Most of the stuff you've listed is simply rhetoric used by one side or another to appeal to their "base". Very little of it ever turns into real legislation. Mostly because you can find people on both sides of each of those issues in both parties - it'd be hard to muster enough support to jam through legislation on a lot of these issues. Both parties use divisive issues to scare you into not voting for the other guy. Because all either of them really care about is power and pork.
Holy horseshit, Batman, is this the best you can do? Argument from ignorance?
Huh? I'm not arguing anything at all. I'm just pointing out that your assertions are meaningless if you are ignorant of how the Singularity system is constructed.
I wouldn't say Erlang's not cool, but I'm assuming that Singularity is aimed at general-purpose mass-market computing, where the system is much more subject to malicious hackers and idiot programmers than the kinds of industrial systems Erlang is used for.
Nevertheless, it demonstrates that software-based process isolation can work robustly in systems where correct functioning is critical. Is it necessarily the ideal system for a mass-market product? No. That's why research projects like Singularity are useful.
This field needs more nay-sayers, not fewer.
No doubt. Though it'd be nice if they could bring reasoned argument to the table, rather than prejudice. Otherwise I'll be taking them with the same large grain of salt that I take the marketing bozos.
This is funny, coming from you.You know, your constant use of ad hominem, coupled with the generally condescending tone of your posts, really does very little to reinforce your arguments. It just makes you appear insecure.
You're obviously young.
Oh, obviously. Just as obviously, IHBT. Oh well, HAND.
I'm not much interested in winning an argument or in contributing further to a discussion that I believe would probably not be particularly useful.
Then why post in the first place?
The intent of my original comment was to point out that there is another point of view on this issue.
Which is certainly an admirable intention. It's the execution that I take issue with.
To wit, that the idea under discussion is (1) old (it was current when I was in graduate school 20 years ago)
As is much in the world of computer science. Sadly, a lot of it hasn't actually been applied in the mainstream - there's a reason the Lisp zealots keep complaining that everybody is only just now starting to implement ideas from Lisp. I imagine it'll be another decade or two until we see any of Milner's or Hoare's work on concurrency really hit the mainstream.
and (2) worthless if your goal is reliability. The latter assertion is not as easy to prove, but the intuition is that relying on lots of incredibly complex software to guarantee the reliability of other software (rather than on hardware that is a few orders of magnitude less complex) is building your house on sand.
And yet your intuition may be wrong. Your argument depends critically on the complexity of the software charged with maintaining process isolation, and I doubt either you or I have any idea of how complex the Singularity system actually is. Meanwhile, things like Ericsson's Erlang system provide proof that software-only systems can be used to provide robust process isolation for industrially critical systems.
A word, to the wise, is sufficient. (But note that this comment is in reply to you, GG, hence the excessive length.)
Har har har. My, what a stinging wit you have.
Part of the motivation for my original comment (and the snarky tone) was that the computing field is full of snake oil, and I'm sick of it.
Aren't we all. But I'm also sick of naysayers who make blanket assertions with little or no evidence to back them up. Neither really contributes anything useful to solving the larger problem of building useful systems that work as they are intended to.
The intent of my second comment was to punish you for your pitiful attempt at a smart-ass rejoinder. Mission accomplished, I think.
Think again. No, really, give it a try. Why on earth would you want to "punish" in the first place (especially given your original - self-admitted - snarky tone)? Why not take my original comment as a challenge to explain your position further (as you have finally done now)?
Peyton-Jones and Meijer are extremely active in the functional programming community. Hoare is getting on towards retirement these days, but still actively contributes to the advancement of concurrency theory (and programming theory in general - see his work on "Unifying Theories of Programming"). Lamport is mostly focused on his Temporal Logic of Actions (TLA) as a method for formally specifying concurrent systems these days, and has done a bunch of work with (IIRC) Intel on processor design. I have no idea what Cardelli is up to these days, but I know he's still active. I mentioned the results that you "knew about 20 years ago" mostly because they are considered pretty seminal and there's a good chance most people have heard of at least some of them. We probably won't know if any of their current work is as seminal until it's had a chance to percolate out into the CS community.
Relying on pithy one-line assertions rather than reasoned argument based on actual facts is an old idea and a bad one--unless you care more about winning an argument than contributing to a useful discussion.
Not to mention the fact that using ad hominem attacks ("...unless you care more about writing papers than about real reliability...", and "...unless you care more about appearing clever than intellectual honesty...") as part of your assertions is among the worst kinds of logical fallacy.
Slashdot Mirror
That may well be the theory. The practice is very different. Research (even "basic" research) requires funding to pay for time, equipment, and grad students. That means you need to be able to sell a funding agency on what you are doing. Which in turn means that you need to be able to justify your research somehow. Now, granted, you don't necessarily need to be able to show a direct commercial use. But you do need to provide some kind of justification.
Better hope that "minimal embedded OS" he's using isn't running on a "minimal embedded system" as well. Otherwise 2-3 MB of VM may well be out of the question.
Why would you want to use a CSP-style concurrency model instead of threads? To quote from the occam compiler homepage:
In layman's terms, you get concurrency that can be built up from easily understood pieces (instead of a monolithically concurrent system with locks scattered throughout the code), and an underlying theory of concurrency that lets you understand and analyze your design and ensure that it is, for example, free of deadlocks (I've personally created complex networks of 1000+ interacting processes in a dynamically evolving topology, with nary a hitch). And did I mentioned that the context-switching performance of most of these systems is amazingly good?
Sounds suspiciously like the "everything is a file" approach promoted by the Plan 9 OS. Not that I think that necessarily makes it a bad idea.
Nice to see the /. editors are doing their job. Not.
I mean, I expect to see some grammatical "idiosyncrasies" in most /. articles, but usually I'm able to decipher what it is they're really trying to say. In this case, I have no clue. I'm assuming it's a case of sloppy cut-and-paste. The least the editors could have done was to remove the totally incoherent parts...
Maybe you missed the intentional (mis)use of the double meaning of "cool" there?
It's pretty clear that a reduced level of global coolness caused by a lack of pirates would result in increasing global temperatures, and we have in fact observed such a predicted upswing in temperatures. It's less clear how factors such as increased atmospheric carbon dioxide, reductions in solar output, or any of the other things driving Earth's natural warming/glaciation cycle might contribute.
The original subject line: RAII is a bad reason for manual memory management (it's still the subject line now). Is manual memory management always a bad idea? No. Nor did I ever claim that it is a bad idea. What I said was that a desire to use the RAIInit idiom is not a good justification for manual memory management (specifically, because there are alternative idioms that work just as well in GC languages). I also asked for some other (i.e. non RAIInit-based) justification for manual memory management. Predictable object destruction is a perfectly good reason for manual memory management, and I'm certainly aware that there are applications that may require it. But that isn't the reason the original article gave.
Besides, you can't abandon GC if you've never adopted it...
Which would explain why I said
The second sentence is about languages that are not GC (and thus would not need to abandon GC).Frankly, I'm a little confused about what you're trying to argue about here. You started by asking wanting/needing the initialization idiom, moved to the need for constructors, and eventually ended up at manual memory management being necessary for some tasks (because of reasons other than a need for RAIInit). So, what exactly are you trying to say that contradicts my original (and continuing) point, that "RAII is a bad reason for manual memory management"?
If those languages are garbage collected, and you want some kind of RAII-style resource management, then yes, I suppose so - RAIInit won't work. Otherwise, by all means use RAIInit. My original point stands: RAIInit is not a good argument for abandoning GC.
So where's the big push for file handle collection?
Performing "file handle collection" (or "lock collection") would leave you in the same boat that attempting to use finalizers for closing files in a GC language would land you: files (or locks) would not be guaranteed to be closed (or released) at a predictable time. For the majority of applications it isn't necessary to have completely predictable object destruction (which is why GC can be used), but predictable file and lock release is a necessity.
Lisp's unwind-protect is the prototypical "RAI as Invocation" idiom. Plenty of other languages implement it though (Haskell and ML come to mind). The presentation at C2 is pretty generic, and not tied specifically to Lisp.
As some of the folks at C2 pointed out in the originally linked references, RAIInitialization is a misnomer anyway (as is RAIInvocation - but that was created in response to the other RAII). Most of what we're talking about here is (despite the name) finalization. That's the part that conflicts with GC. No one's saying that we should eliminate initialization or constructors. The point is that using the RAIInit idiom to handle resource finalization is not a good argument for manual memory management, because the RAIInvoc can produce the same finalization effects without producing any conflict with garbage collection.
Can I just mention that I hate the term 'cyber' when it's used as some kind of signifier that a term is related to computers or the 'net. Possibly more than I hate 'e'-whatever. I blame William Gibson for introducing this usage, and the US government for propagating it. I wish it would stop.
The invocation idiom does the same thing as the initialization idiom. It just implements it in a different way. A way that doesn't depend on whether or not you are using GC. So why would you need/want to use the initialization idiom?
Sure. But the original question was about reasons for manual management other than performance. Plus, as others have pointed out in this thread, the performance of GC-based systems is not necessarily any worse than that of a manually managed memory (even using custom allocators) depending on how the GC is used and how complex the things you're doing with allocated memory are. More importantly, for many applications GC is not the performance bottleneck, even when it does have lower performance than a manually managed solution. You have to look at the complete system, not just individual features of it.
Which was basically my point.
All of the reasons given for manual memory management seem to boil down to a desire to have support for the Resource Acquisition Is Initialization (RAII) idiom, which is hard to pull off in GC languages. But, the alternative idiom Resource Acquisition Is Invocation provides the desired capability in GC languages. Same capability, no chance of memory leaks. So tell me again why manual memory management might be a good idea?
It's hard to say. Who knows what Gore would have done in the aftermath of 9/11. Would we be in exactly the position we are now? No, probably not. Would we be in a somewhat similar position? Possibly. Congress as a whole passed the USAPATRIOT act. Congress as a whole was very much behind invading Iraq in the early days. Now granted, you can claim that's due to intel-spin on the part of the Bush administration. But that doesn't mean we wouldn't have ended up in a similar quagmire in Afghanistan (which Gore might well have invaded) instead of Iraq - part of the reason we're not is because we attracted all the loons to Iraq instead (and if you think Afghanistan wouldn't have turned into a quagmire you have only to look at the Soviet experience there).
Do you think with him in office that the Republican tax cut agenda would have passed?
Who the hell knows. Clinton sure passed a lot of stuff that was traditionally considered "Republican" policy. Time was the Republicans were the party of fiscal responsibility and small government. Then they got into power. The reality is that both parties are made up of wealthy individuals, and both parties are beholden to corporations and wealthy sponsors.
Look at the cronies that Bush appointed to the various Federal agencies (Brown comes to mind). Look at the Executive Orders he has issued withdrawing support from doctors who advocate abortion overseas. Look at the tacit support for torture. Don't you dare tell me that all of those would have happened with a Democrat in office.
Do you honestly believe that those things are a function of Democrat vs Republican principles, rather than Bush as an individual being morally corrupt? I mean, were Clinton's last-minute pardons for various wealthy folks a function of Democratic principles? These kinds of things could have happened on either party's watch.
I will grant you that abortion is an iffy issue. But I honestly believe that it has less than you think to do with DvR: IIRC Kerry was hedging quite a bit on abortion, as have numerous other recent Dem candidates. And it's one issue among many. Is abortion the only real, major policy difference between the two parties? Have we honestly come down to voting based on that one issue alone?
It's rhetoric if it's a bunch of words that are used to get people on your side when you have no intention of actually doing anything about the issues in question. Yes, people care about those issues. That's why the two parties use those issues. But there's a difference between talking about an issue, and actually doing something about it.
Like you aren't using rhetoric to scare people away from voting for a major party candidate they like?
Am I? I certainly didn't intend to do so. You can vote for whoever you like. I'm just pointing out that voting for either of the major parties will produce effectively the same result. If you like that result, then, by all means, vote for them.
Whether or not you'd agree with it there are major differences between the two parties.
Asserting that something is so doesn't make it so. You claim there are major differences. I say there aren't. You point to "policy differences". I claim that those are a smokescreen, because none of them turn into legislation, nor are they likely to any time soon. Show me real, major differences between the actual legislation produced by the two major parties. Don't just claim that there's a difference, without providing any proof that there is one.
I've had a pretty good experience with jEdit, a Java-based programmer's editor on both Linux and OS X. It's mostly replaced emacs for me now. Although I've only tinkered with Eclipse so far, it's been pretty responsive for everything I've tried. On the Mac, NeoOffice/J (the OS X port of OpenOffice.org, which relies on Java for access to the Cocoa API) seesm to run pretty well. Granted, these are all editing apps, but they're all produced by different dev teams, and all seem to work well.
You know, I really get sick and tired of hearing this. Of all the issues that you have listed, how many are actually seriously likely to get implemented anytime soon? Most of the stuff you've listed is simply rhetoric used by one side or another to appeal to their "base". Very little of it ever turns into real legislation. Mostly because you can find people on both sides of each of those issues in both parties - it'd be hard to muster enough support to jam through legislation on a lot of these issues. Both parties use divisive issues to scare you into not voting for the other guy. Because all either of them really care about is power and pork.
Huh? I'm not arguing anything at all. I'm just pointing out that your assertions are meaningless if you are ignorant of how the Singularity system is constructed.
I wouldn't say Erlang's not cool, but I'm assuming that Singularity is aimed at general-purpose mass-market computing, where the system is much more subject to malicious hackers and idiot programmers than the kinds of industrial systems Erlang is used for.
Nevertheless, it demonstrates that software-based process isolation can work robustly in systems where correct functioning is critical. Is it necessarily the ideal system for a mass-market product? No. That's why research projects like Singularity are useful.
This field needs more nay-sayers, not fewer.
No doubt. Though it'd be nice if they could bring reasoned argument to the table, rather than prejudice. Otherwise I'll be taking them with the same large grain of salt that I take the marketing bozos.
This is funny, coming from you.You know, your constant use of ad hominem, coupled with the generally condescending tone of your posts, really does very little to reinforce your arguments. It just makes you appear insecure.
You're obviously young.
Oh, obviously. Just as obviously, IHBT. Oh well, HAND.
Then why post in the first place?
The intent of my original comment was to point out that there is another point of view on this issue.
Which is certainly an admirable intention. It's the execution that I take issue with.
To wit, that the idea under discussion is (1) old (it was current when I was in graduate school 20 years ago)
As is much in the world of computer science. Sadly, a lot of it hasn't actually been applied in the mainstream - there's a reason the Lisp zealots keep complaining that everybody is only just now starting to implement ideas from Lisp. I imagine it'll be another decade or two until we see any of Milner's or Hoare's work on concurrency really hit the mainstream.
and (2) worthless if your goal is reliability. The latter assertion is not as easy to prove, but the intuition is that relying on lots of incredibly complex software to guarantee the reliability of other software (rather than on hardware that is a few orders of magnitude less complex) is building your house on sand.
And yet your intuition may be wrong. Your argument depends critically on the complexity of the software charged with maintaining process isolation, and I doubt either you or I have any idea of how complex the Singularity system actually is. Meanwhile, things like Ericsson's Erlang system provide proof that software-only systems can be used to provide robust process isolation for industrially critical systems.
A word, to the wise, is sufficient. (But note that this comment is in reply to you, GG, hence the excessive length.)
Har har har. My, what a stinging wit you have.
Part of the motivation for my original comment (and the snarky tone) was that the computing field is full of snake oil, and I'm sick of it.
Aren't we all. But I'm also sick of naysayers who make blanket assertions with little or no evidence to back them up. Neither really contributes anything useful to solving the larger problem of building useful systems that work as they are intended to.
The intent of my second comment was to punish you for your pitiful attempt at a smart-ass rejoinder. Mission accomplished, I think.
Think again. No, really, give it a try. Why on earth would you want to "punish" in the first place (especially given your original - self-admitted - snarky tone)? Why not take my original comment as a challenge to explain your position further (as you have finally done now)?
Peyton-Jones and Meijer are extremely active in the functional programming community. Hoare is getting on towards retirement these days, but still actively contributes to the advancement of concurrency theory (and programming theory in general - see his work on "Unifying Theories of Programming"). Lamport is mostly focused on his Temporal Logic of Actions (TLA) as a method for formally specifying concurrent systems these days, and has done a bunch of work with (IIRC) Intel on processor design. I have no idea what Cardelli is up to these days, but I know he's still active. I mentioned the results that you "knew about 20 years ago" mostly because they are considered pretty seminal and there's a good chance most people have heard of at least some of them. We probably won't know if any of their current work is as seminal until it's had a chance to percolate out into the CS community.
Not to mention the fact that using ad hominem attacks ("...unless you care more about writing papers than about real reliability...", and "...unless you care more about appearing clever than intellectual honesty...") as part of your assertions is among the worst kinds of logical fallacy.