3 ms·

Regarding "to each their own": Programmers aren't necessarily the best source for an objective view on productivity. This here is a nice example of CS students

Regarding "to each their own": Programmers aren't necessarily the best source for an objective view on productivity. This here is a nice example of CS students claiming subjectively which programming style they found easier, contrasted by a more objective comparison of the actual number of bugs in the code in each programming style: http://lambda-the-ultimate.org/node/4070 http://lambda-the-ultimate.org/node/4070 Studies like this tell me to never trust the opinion of a developer about programming languages and programming styles. In some cases not even my own. ;) Of course in this case we had not very experienced developers, but if we look at what expert developers often claim and how widely opinions differ I often have the impression that expert developers' fundamental opinions about programming languages aren't much better than that of a student.

Groxx 16y ago
Did you mean to link to something else? 4070 brings me to "Is Transactional Programming Actually Easier?" which deals with concurrency. I'd be interested in what I think you intended to send me to, but I can't find it.
- loup-vaillant 16y ago
  It was the good link. Here's the key point: "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." Transaction are felt as being of average difficulty, but they in fact spur far less errors. I bet we could find the same kind of bad judgement with "map" higher order functions vs "for" loops.

Groxx 16y ago

Did you mean to link to something else? 4070 brings me to "Is Transactional Programming Actually Easier?" which deals with concurrency. I'd be interested in what I think you intended to send me to, but I can't find it.

loup-vaillant 16y ago
It was the good link. Here's the key point: "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." Transaction are felt as being of average difficulty, but they in fact spur far less errors. I bet we could find the same kind of bad judgement with "map" higher order functions vs "for" loops.