User Ranking

User Ranking fixes what is commonly seen on sites that have high community participation and decentralized editorship: ThreadMess. Without knowing who is credible, one hardly knows whom to listen to in the masses. AdvoGato helped pave the way for this by conceiving a reliable TrustMetric (similar to PageRank).

UserRanking is a companion to PerItemVoting and forms the orthogonality necessary to make a PeerToPeer platform scale.

How does that protect unpopular people from being ranked away into oblivion? If Galileo came into a forum with 80% Catholics, for example, how would it protect him? (True, Bozo the Clown may also keep visiting, and there may be a good reason to keep him out.)

There is an easy solution to this. I call it the ProbabilisticChooser pattern. It's based on GeneticAlgorithms and evolutionary theory: you don't just choose the best each time, you choose from a weighted probability of every option.
That's an approach sometimes used on Web sites that let users rank pictures, messages, user uploads and the like, to make sure unpopular content stays unpopular but unfamiliar content gets some love. The weighting is often skewed toward most-recently-added content, to give it a chance to become popular. Not sure how it's based on GeneticAlgorithms and evolutionary theory, though. Where are the chromosomes? Where is the fitness function?
I used the word "based" [on GAs], but what I really meant is that it comes out of my own work in GAs. It's part of the selection function that chooses what genes get propagated between generations.

I would suggest first having a wiki constitution and then elected judges who are required to follow the constitution. Somebody couldn't then be "ranked into silence" just because they are unpopular. This would be comparable not allowing voters to vote slavery back into law just because "majority always rules", for example.

I've been called an "irritant" on this wiki by at least a handful of WikiZens. I believe it's largely because I often attack "sacred notions", making me personally hated. I would probably be voted off the island if a user popularity contest alone was held. But, I don't believe anybody has any clear, objective evidence against my positions (they claim they do, but never produce it in a clear format, despite my repeated attempts to help them document their notions cleaner and better partitioned for analysis). It's largely ArgumentFromAuthority that's being used against me. If most WikiZens agree with Authority X and I attack Authority X's positions, I would likely be voted away. If you are going to kick out unpopular people, at least give them a fair trial based on mutual general principles (a wiki constitution). -- top

"I've been called an 'irritant' on this wiki by at least a handful of WikiZens. I believe it's largely because I often attack 'sacred notions', making me personally hated."

No, that's not it, and no one hates you. We've gone over this before. Attacking "sacred notions" is welcomed by scientists and technicians alike, but the attack has to be led with evidence, based on sound knowledge of the field and rigorous critique. Unfortunately, your attacks are woefully inadequate in those areas. For us, it's like you're a mechanic trying to convince us automotive engineers that making clutches out of metal and carbon fibre is wrong, and we should build clutches out of cheese, because pizzas are round and flat like clutches and pizzas are made with cheese. We then waste a lot of time explaining to you that metal and carbon fibre are better and you go away for a while, but then you pop up again with cheese pizza clutches as if you learned nothing. It is a bit irritating, especially as your rubbery attacks usually claim techniques and tools we're using very effectively -- based on years of study, critique, evaluation, evolution and experience -- should be avoided because stupid people have a little difficulty with them, and anyway -- using the same analogy as before -- you make pizza and all anyone needs on a pizza is cheese. (For "pizza", read "custom business applications", and for "cheese" read "something much like ExBase.")

I wouldn't vote to keep you out, but I recognise that a majority vote might. I agree with your point about an upholding a "wiki constitution" instead of relying on a strict "majority rules" voting process.

Projection. You could use your alleged vast knowledge to provide objective evidence of superiority of tools/techniques, but you don't. That's because your vast knowledge is about things irrelevant to objectivity and economics, but is instead mostly academic MentalMasturbation. You talk about the "elegancy" of your clutch, but don't measure it against things drivers and mechanics really care about in the real world. I have to keep introducing you to reality. Needless to say, we have very different views about what evidence and science is: you see it as the pursuit of elegant models while I see it as measuring against factors that the industry really cares about, not what they "should" care about (if they were "smart like you"), but about what they really care about. I cannot offer a "rigorous critique" of something not tied to reality to begin with, other than pointing out it's not tied to (measured against) reality to begin with. It's already in the hole; I can't provide anything to make it deeper and shouldn't have to. You expect me to critique the "elegancy" of it, but that's not a real metric to begin with. Asking me to just accept it is a waste of your time and my time. Repetition won't help. (All else being equal, elegant is better than non-elegant, but things are not equal.)

If your elegant breaks confuse run-of-the-mill auto mechanics, your flippant solution is "JUST hire better mechanics". But that's not going to happen until you convince the shop owners that is more economical than using more maintenance-friendly or "lower brow" brakes. You fail badly at those kinds of tasks because you spend your time obsessing on design elegancy and ignore sociology and labor economics because to you that's "not fun". You'd rather force-fit the problem to more resemble a math puzzle and thus make excuses to ignore sociology, WetWare, and labor economics.

For example, sometimes SovietShoeFactoryPrinciple will come into play in hiring decisions. I factor that into my recommendations because it will happen in the real world whether you or I want it to or not. You, on the other hand, will make mistakes of idealism application and ignore SovietShoeFactoryPrinciple because "ideally it shouldn't happen" and assume you'll fix the organization or clone your Superior Mind and insert it into all hiring managers.

Unfortunately, the BlubParadox makes it look like the features we advocate are based on elegance or MentalMasturbation. Whilst "elegance" might be worth some negligible aesthetic value, it's of no pragmatic concern. We are ultimately pragmatists, so in every case our only concern is to make it easier (and faster) for skilled developers to write and maintain code and produce more reliable software. It's certainly reasonable to cater for developers of less skill, but that's of little interest to us; lesser developers are free to simply avoid the facilities they don't understand.

Fundamentally, our interest is in extending the leading edge, not looking back at the trailing edge. If you disagree, that's fine, but don't expect us to change.

Short of eugenics, that doesn't scale. Everything can't be at the leading edge at the same time. Go ahead and refuse to change, but don't expect typical shops to listen to your unrealistic assumptions.

But it does scale -- every feature found in popular programming languages was once leading, if not bleeding, edge. The biggest mistake you can make is to assume constancy.

Algol-style languages with wannabe Lisp idioms tacked on and half-used? Same as it ever was. (Faster hardware has expanded our options some.)
I remember when precisely your arguments were levelled at "structured programming".
Please clarify.
What you say now about HigherOrderFunctions and FunctionalProgramming, and once said about ObjectOrientedProgramming, mirror the arguments your predecessors levelled at "structured programming". The cutting edge becomes mainstream, sometimes slowly, sometimes quickly, but always.
ObjectOrientedProgramming was indeed oversold. It has its place, but that place is not everywhere. And most programmers are class users, not class writers, at least not in the "true" OOP fashion. FP had its chance to catch on in the 80s during the AI bubble. Why is now different? You were given a chance to find a practical use for FP in typical custom biz apps, but failed, having to find places where the API forced it on one.
We don't care. Many of us use OOP and FunctionalProgramming effectively. The vagaries of the industry, what catches on and does not, is immaterial. We focus on the cutting edge; how many follow us doesn't matter, because it's something that goes on behind us.
Great, but somebody still has to run and attend to the mundane stuff and give and explain practical advice that works for them.
Good. You do that. We'll do what we do.
So we finally agree on something?
I don't know. Was there a disagreement here?
I'm not sure. Perhaps you should be clear that your advice targets "cutting edge" and I should be clear that my advice targets "as-is" or typical organizational structure, risk taking, and staff. We can then leave it up to the reader or organization whether they want to target their IT or a given IT project toward the cutting edge or not. This may impact decisions about whether to toss existing IT staff.

And BlubParadox is so far not scientifically measurable.

True, but like various other scientifically unmeasurables -- love, anger, contrition, confusion -- it exists nonetheless.

So is IfFooIsSoGreatHowComeYouAreNotRich.

We don't care. We seek to extend the state of the art. If you're not interested, that's fine, but don't expect us to change. Someone has to invent, experiment and innovate, or stagnation and rot set in.

Fine, but that's cutting edge and experimental, producing advice or results that don't necessarily scale to typical orgs in the medium term. I'm glad you are working on the FlyingCar, but the city needs a traffic plan for the next five years, not 30.

Then you work on that. We don't care. We work at the cutting edge. What goes on behind us does not matter; it's not the cutting edge.

Fine, but stop selling it as general and ready and road-tested.

That's not us.

Yes it is. You over-extrapolate.

Where have we been selling something that is not general and ready and road-tested as if it is?

In AbstractionAndOrganizations, you propose unrealistic hiring assumptions.

No, I identify the distinction between mediocre organisations' hiring practices and good hiring practices.

You haven't outlined how to do it in a general sense, nor proven it works better.

Precisely what I did is outline it in a general sense, and you haven't proven it doesn't work better. Having been on the hiring side for years, I can say anecdotally that it does work better. Indeed, people I've hired weren't using the same languages when they left as when they started.

If you can make 100 clones of yourself, then we can repeat the experiment against 100 'non-you's. Sounds feasible to me.

We don't have to. Good organisations that take software development seriously do what I wrote, and do what I did.

That's anecdotal evidence/claims. We cannot go further with such. I suppose one could do a statistical analysis on whether financially successful companies pay developers more or less than the average or shrinking ones, but pay level is a rather crude metric for technical knowledge.

Further, such advice won't work for those designers or decision-makers who have limited influence over hiring.

Further 2, you've failed to show how FP clearly improves typical app code with realistic coded examples, beyond API's that force it. (SummaryOfHofExamples) "It's good because I say it's good, but I can never show you it being good in realistic example code because you are in unspecified kinds of organizations for unspecified reasons, blah blah blah". Man-up and admit you flunked out there big-time. If I was a hiring manager, I'd be very suspicious of one who could not back up FP claims with realistic code scenarios and boot such a braggity empty ass out.

It would be more accurate to say that we haven't convinced you. HofPattern and related pages provide examples, patterns, cases and arguments, but if you've decided you're not going to agree with them, then there's no amount of demonstration or argument that will help. That's fine; we're not going to stop using FunctionalProgramming and HigherOrderFunctions because of you.

We will LetTheReaderDecide if your descriptions are any good. I'm confident most readers will recognize it as low-grade, low-science evidence.

Fair enough. In the absence of the significant time and effort it takes us to do rigorous studies, and in the absence of published ones by others, we can only rely on our own anecdotes and arguments. But whether my descriptions are any good or not, note that industry interest in FunctionalProgramming and its facilities appears to be increasing significantly -- both intellectually and in terms of vendor and developer support in production languages -- whilst there appears to be no particular interest in returning to COBOL or ExBase. Maybe that will change? Time will tell.

As mentioned in GreatLispWar, I believe recent interest increases to be mostly a fad.

Time will tell.

[In the large above example, each paragraph could be voted upon and then weighted according to the ProbabilisticChooser, favoring highly-weighted sections, without losing lesser voices. This is part of a larger idea encompassing the GlassBeadGame.]

I think UserRanking is meaningless for this wiki.

The purpose of a ranking is to make the content more credible or less credible, right? I honestly believe the readers of this wiki are capable to judge on their own the credibility of particular statements. The ones that are not capable read other -- so called -- social platforms.
- No, the purpose of ranking is to be able to scale to millions of participants and make a nice WikiUniverse.
  - A double-aspect reflexive reasoning? A common pattern I have seen on many platforms. A pleader of a theory brings up two arguments: A and B. Every time the argument A is countered he switches to the argument B. Every time the argument B is countered he switches to the argument A.
  - No, not "reflexive". The purpose of ranking is not to make veritas ad populum, it's to allow better truths to bubble upwards.
Anyway, how would a ranking stop the mess? If some statement is down-rated, people would stop to argue? I doubt. If we are any similar to those "social platforms", we would write even more mess, once our opinion is down-rated. If we are not similar, there is no point to try act similar. -- SergejPauls 20130605
- It's called visibility. In a large conversation, downvoted items simply don't get seen as much.
- People have to manage their time. Being downvoted by one user out of hundreds isn't generally enough cause for the system to halt.

What does scaling mean if we speak about a wiki? How does UserRanking affect this scaling? And why is it even related to orthogonality? If we increase the size of wiki and/or community, the wiki with UserRanking will show better performance than the wiki without UserRanking? If Yes, what exactly is better?

See CreativeEconomy, VotingModel