User:Groupthink/Essays/Lists considered harmful

Lists suck. I'm sorry, but it needed to be said. They're bollocks. Complete shite. Stupid and asinine. Thank you for coming to my TED Talk.

All right, I suppose I'd better elucidate. Consider the relational database. One of the fundamental principles of database design is that one should not store fields which can be derived. Say you want to store information about college students in a classroom. Every student has the same attributes associated with them: First name, last name, student ID, etc. So as the database designer, what are you going to capture as fields in your database? "First name", "Last name", "Student ID"? Sure, those are fine. "Dean", "Major", "Minor"? All good.

How about "GPA"? NO! BAD! Why? Because this can be derived, i.e. calculated, from other fields like "English 101 grade", "Calculus II grade", and so forth. Yeah, so what? What's wrong with storing it independently? Well, I'll tell ya hwut! What if one or more of the grades for the student in question ever gets changed? Then you got trouble, my friend, right here in Database City, because when you change a grade, you also have to change the GPA... and if you forget to do so, you wind up with what the nerds call "data integrity" issues.

"BFD", you're thinking. How often is a grade going to change? Fine, be that way. I'll up the ante. We'll do attendance tracking. Shall we add the fields "Days tardy" and "Days absent"? Why not? Easy-peasy, right?

Survey says: WRONG! Think about it. Typical college student has a typical courseload of four courses, probably taught by four different professors. Each course meets, say, 2-3 times per week. So that's 8-12 independent attendance records taken per week for a given student. If multiple users are manually storing and updating the tardy and absence counts, that's 16-24 opportunities to forget to make a change and fuck up those counts per week! Adieu data integrity! This is not good business my friend. You need to be smart and let the database do the work. You don't store the totals, you store an attendance status for each given day of a given class, then you run a query or a report to tabulate your tardy and absence numbers. Now you're working smarter, not harder. Good job!

Ok Groupthink, ya' crazy Texan, WT ever-loving F does this have to do with lists??? Lists, dear reader, are what the nerds call static. They're manually compiled and manually maintained. Like the fields of a database which should be derived but aren't, conditions for data integrity cock-ups are rampant. Consider this hypothetical. It's 2005, and Harold Pinter has just died. Jane Wikipedian dutifully adds {{Template:Recent death}} to Pinter's article and adds his name to List of very dead British playwrights. Except oops, Pinter hasn't died, he's won the Nobel Prize! So Jane Wikipedian removes the template header and adds Pinter to List of Brits wot won a Nobel Prize. All is well... except she forgot to take Pinter off the British playwright corpses list... and nobody else caught the mistake. So now reports of Pinter's death are greatly exaggerated and three years premature. Very unencyclopedic indeed.

There has got to be a better way. And there is! The dynamic way. Sorry: What the nerds call the dynamic way. Let the Wiki do the work! Instead of manually compiling and maintaining a list of "Limey playwrights who are deceased, are no more, have fucking snuffed it"... how about instead we have a mechanism where we annotate the information "this person is not merely dead, they're really most sincerely dead" at an individual article level and then let Wikipedia automatically generate the list we want? Too much to ask?

Hells naw! We can rebuild static lists, we have the technology. CATEGORIES mutha fukka! Categories. Say it loud and there's music playing; say it soft and it's almost like praying.

TL;DR: Cats good, lists bad. Good night, and may your God go with you.