www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - John Warner Backus

reply sclytrack <sclytrack pi.be> writes:
John Warner Backus died on March 17, 2007.

http://en.wikipedia.org/wiki/John_Backus
Mar 21 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
sclytrack wrote:
 John Warner Backus died on March 17, 2007.
 
 http://en.wikipedia.org/wiki/John_Backus

I'm actually kind of saddened by this. It's hard to see someone so influential in this field go. FWIW, he had one heck of a sendoff over on slashdot and digg: http://developers.slashdot.org/article.pl?sid=07/03/20/0223234 http://www.digg.com/programming/John_W_Backus_82_Fortran_Developer_Dies -- - EricAnderton at yahoo
Mar 21 2007
next sibling parent kris <foo bar.com> writes:
Pragma wrote:
 sclytrack wrote:
 
 John Warner Backus died on March 17, 2007.

 http://en.wikipedia.org/wiki/John_Backus

I'm actually kind of saddened by this. It's hard to see someone so influential in this field go.

Aye
Mar 21 2007
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Pragma wrote:

 FWIW, he had one heck of a sendoff over on slashdot and digg:
 
 http://developers.slashdot.org/article.pl?sid=07/03/20/0223234
 http://www.digg.com/programming/John_W_Backus_82_Fortran_Developer_Dies
 

Reading the slashdot freakshow this PDF got me thinking a bit about where we (and D) are going... http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
Mar 21 2007
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Tomas Lindquist Olsen wrote:
 Pragma wrote:
 
 FWIW, he had one heck of a sendoff over on slashdot and digg:

 http://developers.slashdot.org/article.pl?sid=07/03/20/0223234
 http://www.digg.com/programming/John_W_Backus_82_Fortran_Developer_Dies

Reading the slashdot freakshow this PDF got me thinking a bit about where we (and D) are going... http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

Thanks for the link. It's an interesting read. Sweeny says some really *odd* things about the stauts quo, that make me wonder WTF the programmers on his team are doing. His comments on concurrency and musings on the next language are dead on, with (appropriate) shades of Backus thrown in: "In an concurrent world, imperative is the wrong default." "Transactions are the only plausible solution to concurrent mutable statue." D shines in a few of these areas, but needs library support for transactional memory, better concurrency support and constructs, something like a well-coded numerics library (true integers, etc), and something resembling compile-time iterator/bounds checking to fit the bill. :( -- - EricAnderton at yahoo
Mar 22 2007
parent reply Sean Kelly <sean f4.ca> writes:
Pragma wrote:
 
 "Transactions are the only plausible solution to concurrent mutable 
 statue."

I'm not sure I agree. Many of the most common transactional processes work much like mutexes. In SQL, for example, data affected by a transaction is locked (typically at row, page, or table granularity) in much the same way as obtaining locks on mutexes protecting data. Deadlocks are quite possible, and before the era of automatic deadlock resolution, froze the DB indefinitely. The new concept of transactional memory turns this idea on its head by cloning affected data instead of locking it, and mutating the clones. Committing a transaction is therefore accomplished by comparing the original version of all affected data with the current version of the affected data, and if they match, the clones are substituted. If they don't match however, the entire transaction is rolled back and retried. The result is that large transactions are slow and require an unbounded amount of memory (because of the cloning), and no guarantee of progress is provided, because success ultimately relies on a race condition. That said, there have been proposals to add a transactional memory feature to hardware, and I think this is actually a good idea. The existing hardware-based solutions are typically limited to updating no more than 4-8 bytes of contiguous data, while transactional memory would allow for additional flexibility. I've seen implementations of lock-free binary trees based on this concept, and I'm not aware of anything comparable without it. Progress guarantees are less of an issue as well because hardware-level transactions will typically be very small.
 D shines in a few of these areas, but needs library support for 
 transactional memory, better concurrency support and constructs, 
 something like a well-coded numerics library (true integers, etc), and 
 something resembling compile-time iterator/bounds checking to fit the 
 bill. :(

I'd add something like CSP to the category of "better concurrency support." And I agree with the rest. Sean
Mar 22 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Sean Kelly wrote:
 Pragma wrote:
 "Transactions are the only plausible solution to concurrent mutable 
 statue."

I'm not sure I agree. Many of the most common transactional processes work much like mutexes. In SQL, for example, data affected by a transaction is locked (typically at row, page, or table granularity) in much the same way as obtaining locks on mutexes protecting data. Deadlocks are quite possible, and before the era of automatic deadlock resolution, froze the DB indefinitely. The new concept of transactional memory turns this idea on its head by cloning affected data instead of locking it, and mutating the clones. Committing a transaction is therefore accomplished by comparing the original version of all affected data with the current version of the affected data, and if they match, the clones are substituted. If they don't match however, the entire transaction is rolled back and retried. The result is that large transactions are slow and require an unbounded amount of memory (because of the cloning), and no guarantee of progress is provided, because success ultimately relies on a race condition.

I see what you mean. These things always seem so much more tranquil on the surface. It seems to me that the only positive trade off is for highly parallelizable and/or long-running algorithms, which hardly solves anything.
 
 That said, there have been proposals to add a transactional memory 
 feature to hardware, and I think this is actually a good idea.  The 
 existing hardware-based solutions are typically limited to updating no 
 more than 4-8 bytes of contiguous data, while transactional memory would 
 allow for additional flexibility.  I've seen implementations of 
 lock-free binary trees based on this concept, and I'm not aware of 
 anything comparable without it.  Progress guarantees are less of an 
 issue as well because hardware-level transactions will typically be very 
 small.

Neat! Seeing as how the industry is moving towards more and more processor cores, I suppose it follows that we'll eventually see additional hardware support to make it less unwieldy as well. I'm eager to see stuff like this happen. It sounds like something D could adopt easily, provided there's a way to qualify these concepts in a way that doesn't make a person's head explode.
 
 D shines in a few of these areas, but needs library support for 
 transactional memory, better concurrency support and constructs, 
 something like a well-coded numerics library (true integers, etc), and 
 something resembling compile-time iterator/bounds checking to fit the 
 bill. :(

I'd add something like CSP to the category of "better concurrency support." And I agree with the rest. Sean

-- - EricAnderton at yahoo
Mar 22 2007