<br><br><div class="gmail_quote">On Tue, Jul 1, 2008 at 8:20 PM, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 1 Jul 2008, at 7:37 pm, Edwin Fine wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thank you for a very interesting and informative analysis. I must admit that I tend to lump together Erlang/OTP as "Erlang" and see solutions in that context. In a way, I feel as if using Erlang "standalone" without OTP is very roughly analogous to using C++ without the STL: it can be done, but why on earth would one want to?<br>
</blockquote>
<br></div>
Because the STL<br>
- is still not fully portable between compilers;<br>
in theory it should not be, but it takes you into<br>
deep template territory where compilers have<br>
incompatible bugs (though they are improving)<br>
- is in my experience less efficient than home-brew<br>
code (the STL relies, like Haskell, on *serious*<br>
optimisation which compilers do not always do)<br>
- gets you some of the most incomprehensible<br>
compiler error messages (un)imaginable when you<br>
make mistakes, which you always do, because<br>
- it is unpleasantly complex to use (this will, I<br>
hope, be remedied in C0x, at least if I can<br>
trust Stroustrup's summary of what's going to be<br>
there).<br>
</blockquote><div><br>Maybe after using it for a long time, it's doesn't seem that complicated. At least, not compared to C++ itself. C++ itself is IMHO horribly complex and arguably a language to be used only by C++ experts. Just writing exception-safe code alone can be dreadfully difficult, never mind the powerful yet labyrinthine maze that is called templates. I've now used the STL extensively for many years, and it has a large advantage in that it is more or less supported by all compliant compilers (and "free" as in beer). It pretty much does the trick. Initially, the ability of various compilers to handle templates was pretty bad and inconsistent so I rolled my own portable libraries. I had to write a significant amount of commercial C++ code that had to be ported across OS/390, HP/UX, Windows, Solaris, AIX, and Linux, so I have a feel for the issues involved. I found it amusing that Andrei Alexandrescu could write syntactically valid template code that no C++ compilers could parse at that time. After a while, though, the effort of maintaining (testing, documenting, fixing) all that code across all those systems became too much and I used the STL exclusively after that. I had to choose a lowest common denominator approach and avoid doing anything really fancy, but it was still worth it.<br>
The STL was efficient enough for most purposes. In the IT department of a large telco where I worked for some years, trying to improve quality and establish standards, the code was so inefficient that the benefits of using the STL far outweighed any efficiency concerns. They didn't even compile the code with optimization when it went into production, so the overhead of those templates must have been quite significant, yet it didn't even register on the radar compared to the big concerns (like, actually getting the code to work, and getting the developers to understand why it's slow to do a linear lookup in a vector of 100,000 items, in a loop that iterates 50,000 times). When you're in the trenches, you are grateful for anything that works as advertised most of the time. Gladly, I am out of the C++ business right now and happily learning the Erlang world, which is a joy in comparison.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
None of these applies to OTP, but the argument that<br>
<br>
- it is another large and complex body of material<br>
to master on top of something itself unfamiliar.<br>
<br>
does apply to both. </blockquote><div> </div><div>Agreed.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have a colleague who has done<br>
serious commercial software development in C++ and<br>
flatly refuses to have anything to do with the STL<br>
(see reasons above).</blockquote><div> </div><div>I did, too, until a few years ago (see above).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Let's take the current example and see if we can squeeze a<br>
bit more out of it. Tim Watson pointed out that there is<br>
an issue about "locking" and failing processes. My take<br>
on this is "let it crash": when processes are coupled like<br>
this they should be as a rule be linked and if one dies,<br>
all should die. The OTP behaviours take care of that kind<br>
of thing, which is why *once you have grasped the basics*<br>
you should try them before rolling your own. What's really<br>
interesting here is that the original system was written in<br>
terms of threads and locking. Have you looked at thread<br>
interfaces lately?</blockquote><div> </div><div>Unfortunately, I have worked a significant amount with pthreads, Java threads, Windows threads, and OS/2 threads, and consider that skill set to be in the same domain as C++: for experts (as opposed to the "average" developer found in IT shops and who knows how many software companies) only. The fact that we are now seeing multicore processors and are being exhorted to write more thread-bearing code makes me shudder. I suspect that most of the readers of this newsgroup are highly skilled developers, hopefully working for great companies, and I wonder if they have been exposed to the horrors of the "average" developer (as evidenced in "The Daily WTF" and similar web sites). I hope I am not coming across conceited; I'm not like that at all. It is just that I have spent 25 years working hard to be as good a software guy (for want of a better description) as possible, and for my troubles have almost always been put in a position where I have had to teach and mentor the "average" developer (and fix literally millions of lines of code, usualy C++). My experience (and others I am sure will have differences of opinion) is that the level of the average developer is trending steeply downwards as developers become a globalized commodity ("resource") and compete more on price than on ability. These days, I find it rare to see halfway decent code written in ANY language, and the thought of zillions of lines of thread-bearing C++ and Java software being let loose on the world by people who can't even spell O(N^2) scares the heck out of me. Sorry if I am ranting a bit.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
[Single Unix Specification version 3]<br>
<br>
pthread_mutex_lock(&mutex)<br>
pthread_mutex_unlock(&mutex)<br>
<br>
There are four kinds of mutex in POSIX threads:<br>
PTHREAD_MUTEX_NORMAL<br>
recursive locking deadlocks<br>
unlocking a mutex that is already unlocked<br>
or that is locked by another => undefined<br>
PTHREAD_MUTEX_ERRORCHECK<br>
these conditions return an error code<br>
PTHREAD_MUTEX_RECURSIVE<br>
recursive locking works<br>
unlocking a mutex that is already unlocked<br>
or that is locked by another => error code<br>
PTHREAD_MUTEX_DEFAULT<br>
same as PTHREAD_MUTEX_NORMAL<br>
Anything else<br>
All behaviour undefined<br>
<br>
[Solaris 2.10]<br>
If<br>
(1) _POSIX_THREAD_PRIO_INHERIT is defined<br>
(2) the mutex was initialised with protocol<br>
attribute PTHREAD_PRIO_INHERIT<br>
(3) the mutex was initialised with robustness<br>
attribute PTHREAD_MUTEX_ROBUST_NP<br>
(4) the last holder of the lock crashed<br>
then<br>
(A) an attempt to lock the mutex will 'fail'<br>
with the error code EOWNERDEAD<br>
(B) but in fact the attempt will have succeeded<br>
(C) it is up to the *new* owner of the lock to<br>
try to clean up the state<br>
(D) if it can, it calls pthread_mutex_consistent_np<br>
(E) if it crashes, the next locker will get the<br>
same error code and the same chance to recover<br>
(F) if it can't, it should unlock the mutex, and<br>
future lockers will get a *different* error code<br>
(ENOTRECOVERABLE).<br>
(G) it is possible to call pthread_mutex_consistent_np<br>
on mutexes that aren't held or didn't need<br>
recovery and the behaviour is undefined<br>
<br>
If a mutex with the default PTHREAD_MUTEX_STALLED_NP<br>
robustness value is held by a thread that dies,<br>
future locks are "blocked in an unspecified manner".<br>
What this means in practice I'm not sure.<br>
<br>
If you reckon the Solaris 2.10 treatment of crashed<br>
lock holders is a mess, perhaps you can point me to<br>
something better in SUSv3. I can't find anything in<br>
SUSv3 to say _what_ happens when a lock owner crashes.<br>
(And don't get me onto the subject of cancellation points.)<br>
<br>
<br>
What kind of building block is _this_ for building<br>
reliable systems?<br>
</blockquote><div><br>One made of clay and straw and baked in the sun.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Message passing plus linking is so much easier to<br>
have justified confidence in that pthreads and TBB start<br>
to look like extremely sick jokes.<div class="Ih2E3d"></div></blockquote><div><br>I couldn't agree with you more. One thing that amazed me about Erlang is how, once I had figured out how to write something, it Just Worked (TM). I fell in love.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<off-topic>One last thing: I read the Ethics of Belief after poring over one of your posts recently, and was exceptionally impressed with the gentleman's writing and philosophy, with which I strongly agree. In that regard, I'd like to misquote John Stuart Mill, namely, "A foolish certainty is the hobgoblin of little minds". (Actually, I think my version is a slight improvement ;) I am unfortunately seeing the mechanism of insufficiently examined beliefs at work today, resulting in the persecution of a friend of mine by way of (the almost totally belief-based) Shaken Baby Syndrome. So the essay really resonated deeply with me. I daresay William K. Clifford would have had a lot to say about this. I wish he were still alive to do so. Bertrand Russel too.</offtopic><br>
</blockquote>
<br></div>
<also-off-topic>Clifford takes a really good idea and pushes it beyond the bounds<br>
of reason; he manages, presumably without intending to, to make any belief in<br>
science ethically unjustifiable. Specifically and in Clifford's day topically,<br>
Clifford's rule about believing other people meant that it would have been *bad*<br>
for anyone to believe in Natural Selection. I encountered Clifford's paper in<br>
a book by DeMarco and someone else about risk management in software engineering.<br>
I find the idea that Shaken Baby is still credited deeply upsetting; please convey<br>
my sympathy and good wishes to your friend.<br>
</also-off-topic><br>
</blockquote><div><br><rant><br>I won't go off-topic after this, but I just wanted to write two things:<br><br>(a) Shaken Baby is sadly alive and persecuting parents and child carers in the USA, Australia and England.<br>
(b) After reading dozens of papers on the SBS myth, I mean syndrome, and seeing the terrible cost to innocent families due to junk science, I rather lean toward being too much a "Cliffordite" than too little. This is particularly true after I read of scientific bias and just plain fraud (all that lovely research money is so enticing). I actually took Clifford's advice by following up on as many references as I could find in peer-reviewed papers, and I was appalled at how, in many cases, results were used selectively from these papers to back up shaky claims and make them look solidly research-based. These days I am almost reluctant to accept the evidence of my own eyes, having learned how deeply subjective "reality" is, and how what is up today is down tomorrow. Galileo and many others were persecuted for being "heretical" and later shown to be correct. Great "laws" of nature (classical relativity -> special relativity -> general relativity -> quantum mechanics -> string theory -> ??) were challenged and either overturned or radically transformed by those brave and noble enough to endure scorn and criticism. Heretics were burned at the stake not that long ago; are we humans really any different now? Yes, I like Clifford. Rather be too critical than not critical enough, even if it risks making beliefs in science ethically unjustifiable: in the days of the Internet and easy claims of anything, and people who will believe almost any plausible claims, we need to be more vigilant than ever.</rant><br>
</div></div><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)