3 ms·

I think you've jumped at a different parallel than the one I was trying to draw. It's considered a bad thing that Rails prioritised developer convenience over

by telent 15y ago

I think you've jumped at a different parallel than the one I was trying to draw. It's considered a bad thing that Rails prioritised developer convenience over the encouragement of reliable programming practice. Why should it be considered a good thing for a Posix standard to take the same position? Ignore questions of reach and impact, the comparison is one of attitude not of effect. Irrespective of what the tutorials say, many developers will go reaching for a recursive lock the first time they get a recursive deadlock - especially if they come from a Java background - and tutorials or no, it's not as though the information is hard to find. Five minutes browsing Stack Overflow will quickly disabuse you of any perception that all the people writing POSIX threaded apps are in any way particularly gifted, even compared to Rails developers

nknight 15y ago
No, it's considered a bad thing that Rails had insecure defaults in a recommended code path used by legions of inexperienced developers. You can still change the setting to the old value if you want to, just like you can explicitly ask for a recursive mutex if you want one. Bonus: Asking for a recursive mutex still isn't a security problem. And since you want to argue based on SO, I'll just leave you with two bits of data from SO: http://stackoverflow.com/questions/tagged/pthreads http://stackoverflow.com/questions/tagged/pthreads -- 1,525 questions http://stackoverflow.com/questions/tagged/ruby-on-rails http://stackoverflow.com/questions/tagged/ruby-on-rails -- 66,675 questions
- telent 15y ago
  Guess what? I consider that a bad thing too. But you're still reading things into my comment other than what I said. (1) Rails had insecure defaults which encourage bad programming (2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming. (3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library. That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.

by telent 15y ago

nknight 15y ago

No, it's considered a bad thing that Rails had insecure defaults in a recommended code path used by legions of inexperienced developers. You can still change the setting to the old value if you want to, just like you can explicitly ask for a recursive mutex if you want one. Bonus: Asking for a recursive mutex still isn't a security problem. And since you want to argue based on SO, I'll just leave you with two bits of data from SO: http://stackoverflow.com/questions/tagged/pthreads http://stackoverflow.com/questions/tagged/pthreads -- 1,525 questions http://stackoverflow.com/questions/tagged/ruby-on-rails http://stackoverflow.com/questions/tagged/ruby-on-rails -- 66,675 questions

telent 15y ago
Guess what? I consider that a bad thing too. But you're still reading things into my comment other than what I said. (1) Rails had insecure defaults which encourage bad programming (2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming. (3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library. That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.