shminux comments on Dealing with trolling and the signal to noise ratio - Less Wrong

22 Post author: JoshuaZ 31 August 2012 01:26PM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (231)

You are viewing a single comment's thread.

Comment author: shminux 31 August 2012 05:55:40PM *  7 points [-]

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).

Comment author: KPier 02 September 2012 07:03:25AM 6 points [-]

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.)

Comment author: Kawoomba 31 August 2012 06:42:16PM *  7 points [-]

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.

Comment author: shminux 31 August 2012 06:58:37PM 0 points [-]

penalising lines of code can easily lead to a shorter, but much more opaque piece of software,

Yes indeed, hence the weighting:

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)

Comment author: palladias 31 August 2012 06:26:35PM *  2 points [-]

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.

Comment author: Will_Newsome 01 September 2012 08:33:59PM 0 points [-]

My estimate of the general intelligence of the subset of LWers who replied to this post has gone way down.

Why was it so high to begin with? What mistakes do you think you made? (Honest questions.)

Comment author: shminux 02 September 2012 04:13:10AM 0 points [-]

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.