The general incompetence of the replies to the OP is appalling. Fantastically complicated solutions with many potential harmful side effects are offered and defended. My estimate of the general intelligence of the subset of LWers who replied to this post has gone way down. This reminds me of the many pieces of software I had a misfortune to browse the source code of: half-assed solutions patched over and over to provide some semblance of the desired functionality without breaking into pieces.
For comparison, I have noted a trivial low-risk one-line patch that would fix a potential exploit in the recent (and also easy to implement) anti-troll feature: paying with 5 karma to reply to comments downvoted to −3 or lower (patch: only if the author has negative 30-day karma). Can you do cheaper and better? if not, why bother suggesting something else?
After a long time in the software business, one of the lessons I have learned (thanks, Steve McConnell) is that every new feature can be implemented cheaply or expensively, with very little effect on its utility. Unfortunately, I have not heard of any university teaching design simplification beyond using some Boolean algebra (and even that trivial bit is largely ignored by the programmers, who tend to insert a bunch of ad hoc nested if statements rather than think through the possible outcomes and construct and minimize the relevant CNF or DNF). There is also no emphasis on complexity leading to fragility, and how spending 5 minutes thinking through solutions can save months and years of effort during the maintenance stage.
To sum up: every (software) solution can be simplified without perceptible loss of functionality. Simpler solutions are more reliable and easier to maintain. One ought to spend time upfront attempting such simplifications. Pretend that you are being charged per line of (pseudo)code, per use case to test (10x more) and per bug fixed (10x more still), then see if you can save some money before rushing to design and code (or, in this particular case, before posting it here for others to see).
Changes to a functioning system that is in use should be done with care akin to pruning a bonsai tree, not by introducing sweeping changes that are then potentially scaled back.
That would only make sense for posters with, say, negative karma in the last month. Otherwise this results in (self-)censoring of controversial comments.
I very much agree with your proposal, it should have been an obvious first step (and if there had been some public discourse in which you would probably have suggested it, it might well have been). Upon unsatisfactory results, it could have been escalated to a more profound change.
How long is it going to take for some forum regulars to pick up a dedicated downvoter with two sockpuppets, strongly impinging the discussion on their new +0 → −3 comments, at least temporarily? The karma hit is a negligible inconvenience for old-timers, but the temporary obstruction of their conversational flow isn’t. Empowering trolls inadvertently, how ironic. Who would have thought there are such unforeseen consequences when non-professionals implement such changes without discussions? Why, I suspect you would have, as someone experienced with software design failure modes.
It is a bit disconcerting that such an a-priori type proposal was implemented not only without considering expertise from LW’s very own base of professionals, but without first gathering some evidence on its repercussions as well. From the resident Bayesianists, you’d think that there’d be some more updating on evidence through trials first, e.g. by implementing similar (such as yours) but less impactful changes first.
Concerning your software development paradigm:
With the caveat of not having spent a long time in the software industry, there is an argument for the converse case as well.
While I’m all for using k-CNFs, DNFs and all sorts of normal forms, penalising lines of code can easily lead to a shorter, but much more opaque piece of software, regardless of doxygen or other documentation. Getting rid of unnecessary conjuncts in a boolean formula sounds good in theory, but just spelling out each case, with e.g. throwing an exception and commenting that this or that case should not happen, can make it much easier for someone else to follow along your logic.
A maximally compressed pile of ultra efficient goodness, resembling a quine in terms of comprehensibility, would satisfy your “minimize the code” requirement, yet make the code less accessible, not more so.
But I’m happy to consider your testimony to the contrary. As the saying goes:
All theory, dear friend, is gray, but the golden tree of life springs ever green.
My estimate of the general intelligence of the subset of LWers who replied to this post has gone way down.
It seems like it’s your estimate of the programming knowledge of the commenters that should go down. Most of the proposed solutions have in common that they sound really simple to implement, but would in fact be complicated—which someone with high general intelligence and rationality, but limited domain-specific knowledge, might not know.
Should people who can’t program refrain from suggesting programming fixes? Maybe. But maybe it’s worth the time to reply to some of the highly-rated suggestions and explain why they’re much harder than they look.
(I agree with your proposed solution to attempt simplifications.)
There seem to be two functions of this discussion:
come up with practical solutions
diagnose the problem
Terrible to implement comment tweaks can still spur helpful discussion. A poster may have articulated a problem or an incentive in a way most of us haven’t considered yet. Not everyone who has an interesting description of the problem may have that much coding-fu. Better to throw up your diagnosis without worrying too much about the cure and let everyone critique, counter-suggest, and fix the implementation.
I never said it was very high to begin with :) Though the level of discourse here is much higher than on most other online forums I followed, and that threw me off.
Warning: a rant follows!
The general incompetence of the replies to the OP is appalling. Fantastically complicated solutions with many potential harmful side effects are offered and defended. My estimate of the general intelligence of the subset of LWers who replied to this post has gone way down. This reminds me of the many pieces of software I had a misfortune to browse the source code of: half-assed solutions patched over and over to provide some semblance of the desired functionality without breaking into pieces.
For comparison, I have noted a trivial low-risk one-line patch that would fix a potential exploit in the recent (and also easy to implement) anti-troll feature: paying with 5 karma to reply to comments downvoted to −3 or lower (patch: only if the author has negative 30-day karma). Can you do cheaper and better? if not, why bother suggesting something else?
After a long time in the software business, one of the lessons I have learned (thanks, Steve McConnell) is that every new feature can be implemented cheaply or expensively, with very little effect on its utility. Unfortunately, I have not heard of any university teaching design simplification beyond using some Boolean algebra (and even that trivial bit is largely ignored by the programmers, who tend to insert a bunch of ad hoc nested if statements rather than think through the possible outcomes and construct and minimize the relevant CNF or DNF). There is also no emphasis on complexity leading to fragility, and how spending 5 minutes thinking through solutions can save months and years of effort during the maintenance stage.
To sum up: every (software) solution can be simplified without perceptible loss of functionality. Simpler solutions are more reliable and easier to maintain. One ought to spend time upfront attempting such simplifications. Pretend that you are being charged per line of (pseudo)code, per use case to test (10x more) and per bug fixed (10x more still), then see if you can save some money before rushing to design and code (or, in this particular case, before posting it here for others to see).
Changes to a functioning system that is in use should be done with care akin to pruning a bonsai tree, not by introducing sweeping changes that are then potentially scaled back.
I very much agree with your proposal, it should have been an obvious first step (and if there had been some public discourse in which you would probably have suggested it, it might well have been). Upon unsatisfactory results, it could have been escalated to a more profound change.
How long is it going to take for some forum regulars to pick up a dedicated downvoter with two sockpuppets, strongly impinging the discussion on their new +0 → −3 comments, at least temporarily? The karma hit is a negligible inconvenience for old-timers, but the temporary obstruction of their conversational flow isn’t. Empowering trolls inadvertently, how ironic. Who would have thought there are such unforeseen consequences when non-professionals implement such changes without discussions? Why, I suspect you would have, as someone experienced with software design failure modes.
It is a bit disconcerting that such an a-priori type proposal was implemented not only without considering expertise from LW’s very own base of professionals, but without first gathering some evidence on its repercussions as well. From the resident Bayesianists, you’d think that there’d be some more updating on evidence through trials first, e.g. by implementing similar (such as yours) but less impactful changes first.
Concerning your software development paradigm:
With the caveat of not having spent a long time in the software industry, there is an argument for the converse case as well.
While I’m all for using k-CNFs, DNFs and all sorts of normal forms, penalising lines of code can easily lead to a shorter, but much more opaque piece of software, regardless of doxygen or other documentation. Getting rid of unnecessary conjuncts in a boolean formula sounds good in theory, but just spelling out each case, with e.g. throwing an exception and commenting that this or that case should not happen, can make it much easier for someone else to follow along your logic.
A maximally compressed pile of ultra efficient goodness, resembling a quine in terms of comprehensibility, would satisfy your “minimize the code” requirement, yet make the code less accessible, not more so.
But I’m happy to consider your testimony to the contrary. As the saying goes:
Yes indeed, hence the weighting:
It seems like it’s your estimate of the programming knowledge of the commenters that should go down. Most of the proposed solutions have in common that they sound really simple to implement, but would in fact be complicated—which someone with high general intelligence and rationality, but limited domain-specific knowledge, might not know.
Should people who can’t program refrain from suggesting programming fixes? Maybe. But maybe it’s worth the time to reply to some of the highly-rated suggestions and explain why they’re much harder than they look.
(I agree with your proposed solution to attempt simplifications.)
There seem to be two functions of this discussion:
come up with practical solutions
diagnose the problem
Terrible to implement comment tweaks can still spur helpful discussion. A poster may have articulated a problem or an incentive in a way most of us haven’t considered yet. Not everyone who has an interesting description of the problem may have that much coding-fu. Better to throw up your diagnosis without worrying too much about the cure and let everyone critique, counter-suggest, and fix the implementation.
Why was it so high to begin with? What mistakes do you think you made? (Honest questions.)
I never said it was very high to begin with :) Though the level of discourse here is much higher than on most other online forums I followed, and that threw me off.