= 27d567bc2d48d9f40e9ccc20ea370b15)
paper-machine comments on Question about application of Bayes - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (30)
I was with you up to this parenthetical. The same problems affect every other programming language, though perhaps with different root causes. Race conditions are hardly language-dependent.
The probability of getting a race condition, given that you're programming in Haskell, is orders of magnitude lower than the probability of getting a race condition, given that you're programming in C or C++.
That may well be true. I do have some other constraints, though. For example, does Haskell have a well-supported GUI library that works on Windows and talks to OpenGL?
Haskell requires bending your brain in ways that are often uncomfortable to non-mathematicians. I, personally, use Python, which strikes a balance between race avoidance and library support. I meant more to argue that race conditions are language-dependent than to recommend Haskell as a perfect programming language for any purpose.
Not different root causes, fewer root causes. Threading problems and race conditions exist in all languages, but memory corruption does not; the majority of languages won't let you do things like write out of bounds or use after free.
Yes, memory corruption in particular is no longer an issue in most higher languages, but memory management in general has become more complicated and less transparent. The Law of Leaky Abstractions ruins everything.
In any case this is reasonably off-topic for this post, so I won't belabor the point further.