JetLib News

Is Transactional Programming Actually Easier?, WDDD ’09.

Chip multi-processors (CMPs) have become ubiquitous, while tools that ease concurrent programming have not. The promise of increased performance for all applications through ever more parallel hardware requires good tools for concurrent programming, especially for average programmers. Transactional memory (TM) has enjoyed recent interest as a tool that can help programmers program concurrently.

The TM research community claims that programming with transactional memory is easier than alternatives (like locks), but evidence is scant. In this paper, we describe a user-study in which 147 undergraduate students in an operating systems course implemented the same programs using coarse and fine-grain locks, monitors, and transactions. We surveyed the students after the assignment, and examined their code to determine the types and frequency of programming errors for each synchronization technique. Inexperienced programmers found baroque syntax a barrier to entry for transactional programming. On average, subjective evaluation showed that students found transactions harder to use than coarse-grain locks, but slightly easier to use than fine-grained locks. Detailed examination of synchronization errors in the students’ code tells a rather different story. Overwhelmingly, the number and types of programming errors the students made was much lower for transactions than for locks. On a similar programming problem, over 70% of students made errors with fine-grained locking, while less than 10% made errors with transactions.

I’ve recently discovered the Workshop on Duplicating, Deconstructing, and Debunking (WDDD) and have found a handful of neat papers, and this one seemed especially relevant to LtU.

Also, previously on LtU:

Transactional Memory versus Locks – A Comparative Case Study

Despite the fact Tommy McGuire’s post mentions Dr. Victor Pankratius’s talk was at UT-Austin and the authors of this WDDD’09 paper represent UT-Austin, these are two independent case studies with different programming assignments. The difference in assignments is interesting because it may indicate some statistical noise associated with problem domain complexity (as perceived by the test subjects) and could account for differences between the two studies.

Everyone always likes to talk about usability in programming languages without trying to do it. Some claim it can’t even be done, despite the fact Horning and Gannon did work on the subject 3+ decades ago, assessing how one can Language Design to Enhance Program Reliability. This gives a glimpse both on (a) why it is hard (b) how you can still try to do usability testing, rather than determine the truthiness of a language design decision.

Source: Is Transactional Programming Actually Easier?

theodp writes “Raw intellect ain’t always all it’s cracked up to be, advises Ted Dziuba in his introduction to Programming Things I Wish I Knew Earlier, so don’t be too stubborn to learn the things that can save you from the headaches of over-engineering. Here’s some sample how-to-avoid-over-complicating-things advice: ‘If Linux can do it, you shouldn’t. Don’t use Hadoop MapReduce until you have a solid reason why xargs won’t solve your problem. Don’t implement your own lockservice when Linux’s advisory file locking works just fine. Don’t do image processing work with PIL unless you have proven that command-line ImageMagick won’t do the job. Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look.’ Any cautionary tips you’d like to share from your own experience?”

Source: Programming Things I Wish I Knew Earlier

theodp writes “Raw intellect ain’t always all it’s cracked up to be, advises Ted Dziuba in his introduction to Programming Things I Wish I Knew Earlier, so don’t be too stubborn to learn the things that can save you from the headaches of over-engineering. Here’s some sample how-to-avoid-over-complicating-things advice: ‘If Linux can do it, you shouldn’t. Don’t use Hadoop MapReduce until you have a solid reason why xargs won’t solve your problem. Don’t implement your own lockservice when Linux’s advisory file locking works just fine. Don’t do image processing work with PIL unless you have proven that command-line ImageMagick won’t do the job. Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look.’ Any cautionary tips you’d like to share from your own experience?”

Source: Programming Things I Wish I Knew Earlier

Many a people have looked at Programming Lanugages through the Sapir-Whorf lens so it’s not uncommon to find people making PL claims using that hypothesis. Also not surprisingly, the topic keeps re-appearing here on LtU.

This week’s NY Times magazine has an article titled Does Your Language Shape How You Think? by Guy Deutscher which starts as a retrospective on Whorf but then goes into what new research has shown.

Some 50 years ago, the renowned linguist Roman Jakobson pointed out a crucial fact about differences between languages in a pithy maxim: “Languages differ essentially in what they must convey and not in what they may convey.” This maxim offers us the key to unlocking the real force of the mother tongue: if different languages influence our minds in different ways, this is not because of what our language allows us to think but rather because of what it habitually obliges us to think about.

…

When your language routinely obliges you to specify certain types of information, it forces you to be attentive to certain details in the world and to certain aspects of experience that speakers of other languages may not be required to think about all the time. And since such habits of speech are cultivated from the earliest age, it is only natural that they can settle into habits of mind that go beyond language itself, affecting your experiences, perceptions, associations, feelings, memories and orientation in the world.

Source: Sapir-Whorf 70 years on

An anonymous reader writes “Anyone who’s ever taken a programming course or tried to learn how to code out of a book will have come across sorting algorithms. Bubble, heap, merge — there’s a long list of methods for sorting data. The subject matter is fairly dry. Thankfully, someone has found a way to not only make sorting more interesting, but easier to remember and understand, too.”

Source: Sorting Algorithms — Boring Until You Add Sound

An anonymous reader writes “From optimizing truck delivery routes to inspiring nerve-cell-based cognition models, ant intelligence has arrived. From the Economist: ‘In 1992 Dr. Dorigo and his group began developing Ant Colony Optimisation (ACO), an algorithm that looks for solutions to a problem by simulating a group of ants wandering over an area and laying down pheromones. ACO proved good at solving travelling-salesman-type problems. Since then it has grown into a whole family of algorithms, which have been applied to many practical questions. … Ant-like algorithms have also been applied to the problem of routing information through communication networks. Dr. Dorigo and Gianni Di Caro, another researcher at IDSIA, have developed AntNet, a routing protocol in which packets of information hop from node to node, leaving a trace that signals the “quality” of their trip as they do so. Other packets sniff the trails thus created and choose accordingly. In computer simulations and tests on small-scale networks, AntNet has been shown to outperform existing routing protocols.”

Source: Incorporating Swarm Intelligence Into Computer AI

snydeq writes “Fatal Exception’s Neil McAllister warns developers of the hidden risks of entering programming competitions, which are on the rise since NetFlix awarded $1 million to BellKor’s Pragmatic Chaos in 2009. ‘Web and software companies offer prizes for a variety of reasons. Chief among them is simply to raise awareness, interest, and participation in a given software platform or service,’ McAllister writes. But the practice of offering and entering software prizes is not without concerns. Privacy implications, class-action lawsuits — many of the prizes leave participants vulnerable to prosecution. Worse is the possibility of handing hard work over to a company without reward. ‘Contests like the Netflix Prize are sponsored by commercial entities that stand to profit from the innovations produced by the entrants. Those who participate invest valuable time toward winning the prize, but if they fail to meet the deadline (or to produce the leading results) their efforts could go completely unrewarded. Depending on the terms of the contest, however, the sponsor might still be able to make use of the runners-up’s innovations — which, of course, would be a whole lot cheaper than hiring developers.’”

Source: The Risks of Entering Programming Contests

An anonymous reader writes “Though Microsoft had initially made a commitment to create versions of dynamic languages that are customized for .NET, recent reports make it clear that the company may be stepping back from this plan. Much early speculation on this change in focus comes from Jim Schementi, previously the program manager in charge of Microsoft’s implementation of the Ruby software known as IronRuby. Schementi reports on his blog that the team dedicated to working on IronRuby has decreased to one employee. According to Schementi, his departure from the company came as Microsoft began to display a ‘serious lack of commitment’ to any .NETized dynamic languages, including IronRuby.”

Source: Microsoft May Back Off of .NET Languages

An anonymous reader writes “Last year, I got the opportunity to port Remedy Entertainment’s Death Rally to modern platforms off its original MS-DOS sources. I wrote an article about the porting process for Game Developer magazine, and now I’ve posted the text of the article for general consumption. ‘The source software platform was DOS, Watcom C, and some Dos4GW-style DOS extender. The extender basically meant you could use more than 640k of memory, and would not need any weird code for data larger than 64k. The game displayed in VESA 640×480 and MCGA 320×200 graphics modes, all with 8-bit palettes; there was no true color anywhere. There were also some per-frame palette change tricks that emulators have trouble with. The source code was mostly pure C with a couple dozen inline assembly functions. There were a few missing subsystems, specifically audio and networking, which would have to be replaced completely anyway, as well as one file for which the source code was lost and only a compiled object was available.’”

Source: How Death Rally Got Ported

Type Classes as Objects and Implicits

Type classes were originally developed in Haskell as a disciplined alternative to ad-hoc polymorphism. Type classes have been shown to provide a type-safe solution to important challenges in software engineering and programming languages such as, for example, retroactive extension of programs. They are also recognized as a good mechanism for concept-based generic programming and, more recently, have evolved into a mechanism for type-level computation. This paper presents a lightweight approach to type classes in object-oriented (OO) languages with generics using the CONCEPT pattern and implicits (a type-directed implicit parameter passing mechanism).

This paper also shows how Scala’s type system conspires with implicits to enable, and even surpass, many common extensions of the Haskell type class system, making Scala ideally suited for generic programming in the large.

Martin Odersky and team’s design decisions around how to do type classes in a unified OO and FP language continue to bear fascinating fruit. Implicits look less and less like “poor man’s type classes,” and more and more like an improvement upon type classes, in my opinion given a quick read of this paper.

Source: Type Classes as Objects and Implicits