3 ms·

How is any language going to fix the problem of bad programmers programming badly? And, more relevantly—how does the fact that a language can't fix those error

How is any language going to fix the problem of bad programmers programming badly? And, more relevantly—how does the fact that a language can't fix those errors make preventing other errors a useless endeavor? It's true that there's no such thing as a programming language that can only write good/safe/acceptable programs, and a lot of people (myself included) who advertise programming languages as a solution to problems tend to overstate the relevance of type systems, correctness proofs, pure functions, &c, but that doesn't mean you can't eliminate a certain variety of error through good language design or by enforcing programmer rigor.

Groxx 16y ago
It's not, which is the point. loup-vaillant's comment implied that it was possible to write a "perfect" program in a proof-oriented language, as it would have no vulnerabilities, and people could trust your code. I wasn't intending to imply that, because language X does not solve likely-intractable problem Y, language X is worthless. Just that likely-intractable problem Y is likely intractable in language Z as well as X, as it's an inherent quality of the problem. edit: I will however explicitly imply that more syntactically complicated languages are probably more likely to hide many kinds of logic errors. More brainpower spent decoding your code is more brainpower not spent analyzing your logic. Each to their own, clearly; I most definitely side with highly-readable code, and know several people who would likely feel right at home with Omega (e.g.: my brother is a math + philosophy double-major).
- wkornewald 16y ago
  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

It's not, which is the point. loup-vaillant's comment implied that it was possible to write a "perfect" program in a proof-oriented language, as it would have no vulnerabilities, and people could trust your code. I wasn't intending to imply that, because language X does not solve likely-intractable problem Y, language X is worthless. Just that likely-intractable problem Y is likely intractable in language Z as well as X, as it's an inherent quality of the problem. edit: I will however explicitly imply that more syntactically complicated languages are probably more likely to hide many kinds of logic errors. More brainpower spent decoding your code is more brainpower not spent analyzing your logic. Each to their own, clearly; I most definitely side with highly-readable code, and know several people who would likely feel right at home with Omega (e.g.: my brother is a math + philosophy double-major).

wkornewald 16y ago
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.