I've always wondered if Luhmann's jokerzettel was inspired by Claude Shannon's Ultimate Machine: https://www.youtube.com/watch?v=G5rJJgt_5mg

Luhmann couldn't have worked in systems theory and information for so long without being intimately familiar with Shannon's work. There's direct evidence that he read at least his seminal work: https://niklas-luhmann-archiv.de/bestand/literatur/item/shannon_weaver_1949_communication

While we're on about the "Cargo Cult of Zettelkasten" and Claude Shannon, his short essay "The Bandwagon" is an infamous article he wrote about the cargo cult of information theory applications in 1956.

Shannon, Claude Elwood. “The Bandwagon.” IEEE Transactions on Information Theory 2, no. 1 (March 1956): 3. https://doi.org/10.1109/TIT.1956.1056774. .pdf copy at https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1056774

Finally, too many Zettelkasten adherents of the Luhmann-artig sort seem to want to forget that Luhmann's system was far from new and that thousands upon thousands had used similar systems for several hundreds of years before him. Many thousands of them also wrote huge amounts of material, many of them producing work far more consequential than anything Luhman wrote.

reply to u/taurusnoises and u/Filion_Alexandrian at I've always wondered if Luhmann's jokerzettel was inspired by Claude Shannon's Ultimate Machine: https://www.youtube.com/watch?v=G5rJJgt_5mg

Luhmann couldn't have worked in systems theory and information for so long without being intimately familiar with Shannon's work. There's direct evidence that he read at least his seminal work: https://niklas-luhmann-archiv.de/bestand/literatur/item/shannon_weaver_1949_communication

While we're on about the "Cargo Cult of Zettelkasten" and Claude Shannon, his short essay "The Bandwagon" is an infamous article he wrote about the cargo cult of information theory applications in 1956.

Shannon, Claude Elwood. “The Bandwagon.” IEEE Transactions on Information Theory 2, no. 1 (March 1956): 3. https://doi.org/10.1109/TIT.1956.1056774. .pdf copy at https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1056774

Finally, too many Zettelkasten adherents of the Luhmann-artig sort seem to want to forget that Luhmann's system was far from new and that thousands upon thousands had used similar systems for several hundreds of years before him. Many thousands of them also wrote huge amounts of material, many of them producing work far more consequential than anything Luhman wrote.

Revisar estos documentos . conocimientos normativos

Give this one another go and think it through more carefully.

"Екатерина Шульман: Практический Нострадамус, или 12 умственных привычек, которые мешают нам предвидеть будущее". vedomosti/ (in Russian). Retrieved 24 June 2021.

A Note on the Cargo Cult of Zettelkasten

Modern cargo cults can be seen in many technology and productivity spaces where people are pulled in by exaggerated (or sometimes even real claims) of productivity or the general "magic" of a technology or method.

An example is Niklas Luhmann's use of his zettelkasten which has created a cargo cult of zettelkasten aspirants and users who read one or more of the short one page blog posts about his unreasonable productivity and try to mimic it without understanding the system, how it works, or how to make it work for them. They often spend several months collecting notes, and following the motions, but don't realize the promised gains and may eventually give up, sometimes in shame (or as so-called "rubbish men") while watching others still touting its use.

To prevent one's indoctrination into the zettelkasten cult, I'll make a few recommendations:

Distance yourself from the one or two page blog posts or the breathless YouTube delineations. Ask yourself very pointedly: what you hope to get out of such a process? What's your goal? Does that goal align with others' prior uses and their outcomes?

Be careful of the productivity gurus who are selling expensive courses and whose focus may not necessarily be on your particular goals. Some are selling very pointed courses, which is good, while others are selling products which may be so broad that they'll be sure to have some success stories, but their hodge-podge mixture of methods won't suit your particular purpose, or worse, you'll have to experiment with pieces of their courses to discover what may suit your modes of working and hope they'll suffice in the long run. Some are selling other productivity solutions for task management like getting things done (GTD) or bullet journals, which can be a whole other cargo cults in and of themselves. Don't conflate these![^1] The only thing worse than being in a cargo cult is being in multiple at the same time.

If you go the digital route, be extremely wary of shiny object syndrome. Everyone has a favorite tool and will advocate that it's the one you should be using. (Often their method of use will dictate how much they love it potentially over and above the affordances of the tool itself.) All of these tools can be endlessly configured, tweaked, or extended with plugins or third party services. Everyone wants to show you their workflow and set up, lots of which is based on large amounts of work and experimentation. Ignore 99.999% of this. Most tools are converging to a similar feature set, so pick a reasonable one that seems like it'll be around in 5 years (and which has export, just in case). Try out the very basic features for several months before you change anything. Don't add endless plugins and widgets. You're ultimately using a digital tool to recreate the functionality of index cards, a pencil, and a box. How complicated should this really be? Do you need to spend hundreds of hours tweaking your system to save yourself a few minutes a year? Be aware that far too many people touting the system and marketers talking about the tools are missing several thousands of years of uses of some of these basic literacy-based technologies. Don't join their island cult, but instead figure out how the visiting culture has been doing this for ages.[^2] Recall Will Hunting's admonition against cargo cults in education: “You wasted $150,000 on an education you coulda got for $1.50 in late fees at the public library.”[^3]

Most people ultimately realize that the output of their own thinking is only as good as the inputs they're consuming. Leverage this from the moment you begin and ignore the short bite-sized advice for longer form or older advice from those with experience. You're much more likely to get more long term value out of reading Umberto Eco or Mortimer J. Adler & Charles van Doren[^4] than you are an equivalent amount of time reading blog posts, watching YouTube videos, or trolling social media like Reddit and Twitter.

Realize that reaching your goal is going to take honest-to-goodness actual work, though there is potential for fun. No matter how shiny or optimized your system, you've still got to do the daily work of reading, watching, listening and using it to create anything. Focus on this daily work and don't get sidetracked by the minutiae of trying to shave off just a few more seconds.[^5] In short, don't get caught up in the "productivity porn" of it all. Even the high priest at whose altar they worship once wrote on a slip he filed:

"A ghost in the note card index? Spectators visit [my office to see my notes] and they get to see everything and nothing all at once. Ultimately, like having watched a porn movie, their disappointment is correspondingly high." —Niklas Luhmann. <small>“Geist im Kasten?” ZKII 9/8,3. Niklas Luhmann-Archiv. Accessed December 10, 2021. https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_2_NB_9-8-3_V. (Personal translation from German with context added.)</small>

[^1] Aldrich, Chris. “Zettelkasten Overreach.” BoffoSocko (blog), February 5, 2022. https://boffosocko.com/2022/02/05/zettelkasten-overreach/.

[^2]: Blair, Ann M. Too Much to Know: Managing Scholarly Information before the Modern Age. Yale University Press, 2010. https://yalebooks.yale.edu/book/9780300165395/too-much-know.

[^3]: Good Will Hunting. Miramax, Lawrence Bender Productions, 1998.

[^4]: Adler, Mortimer J., and Charles Van Doren. How to Read a Book: The Classic Guide to Intelligent Reading. Revised and Updated edition. 1940. Reprint, New York: Simon & Schuster, 1972.

[^5]: Munroe, Randall. “Is It Worth the Time?” Web comic. xkcd, April 29, 2013. https://xkcd.com/1205/.

Recommended resources

Choose only one of the following and remember you may not need to read the entire work:

Ahrens, Sönke. How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking – for Students, Academics and Nonfiction Book Writers. Create Space, 2017.

Allosso, Dan, and S. F. Allosso. How to Make Notes and Write. Minnesota State Pressbooks, 2022. https://minnstate.pressbooks.pub/write/.

Bernstein, Mark. Tinderbox: The Tinderbox Way. 3rd ed. Watertown, MA: Eastgate Systems, Inc., 2017. http://www.eastgate.com/Tinderbox/TinderboxWay/index.html.

Dow, Earle Wilbur. Principles of a Note-System for Historical Studies. New York: Century Company, 1924.

Eco, Umberto. How to Write a Thesis. Translated by Caterina Mongiat Farina and Geoff Farina. 1977. Reprint, Cambridge, MA, USA: MIT Press, 2015. https://mitpress.mit.edu/books/how-write-thesis.

Gessner, Konrad. Pandectarum Sive Partitionum Universalium. 1st Edition. Zurich: Christoph Froschauer, 1548.

Goutor, Jacques. The Card-File System of Note-Taking. Approaching Ontario’s Past 3. Toronto: Ontario Historical Society, 1980. http://archive.org/details/cardfilesystemof0000gout.

Sertillanges, Antonin Gilbert, and Mary Ryan. The Intellectual Life: Its Spirit, Conditions, Methods. First English Edition, Fifth printing. 1921. Reprint, Westminster, MD: The Newman Press, 1960. http://archive.org/details/a.d.sertillangestheintellectuallife.

Webb, Sidney, and Beatrice Webb. Methods of Social Study. London; New York: Longmans, Green & Co., 1932. http://archive.org/details/b31357891.

Weinberg, Gerald M. Weinberg on Writing: The Fieldstone Method. New York, N.Y: Dorset House, 2005.

Ah! This remark highlights a fundamental difference in understanding between two camps, which I have been (painfully) aware of, but the source of this confusion has eluded me until only just right now. (Really, this is a source of frustration going back years.)

In one camp, the advice "don't use global variables" is a way of attacking a bunch of things endemic to their use, most notably unnecessary coupling to spooky state. In another camp "no global variables" is understood to mean literally that and taken no further—so you can have as much spookiness as you like, and so long as the value is not directly accessible (visible) from, say, another given piece of code appearing at the top-level ("global") context, as with the way i is bound to the activation record in this example but is not accessible outside the scope of getGetNext, then you're good.

That is, there are two aspects to variables: visibility and extent, and the first interpretation seeks to avoid the negative effects on both dimensions, while the second is satisfied by narrowly prohibiting direct visibility across boundaries.

I find the latter interpretation bizarre and completely at odds with the spirit of the exhortation for avoiding globals in the first place.

(What's worse is the the second interpretation usually goes hand in hand with the practice of making extensive use of closures, which because they are propped up as being closely associated with functions, then leads people to regretfully refer to this style as functional programming. This is a grave error—and, to repeat, totally at odds with the spirit of the thing.)

"unchallenged truths" is not really accurate. More like unchallenged assumption.

The thing that bugs me when I listen to the Muse podcast—it's something that's present here along with the episode with gklitt—is that there's this overarching suggestion that the solution to this is elusive or that there are platform constraints (especially re the Web) that keep any of these things from being made. But lots of what gets talked about here is possible today, it's just that no one's doing it, because the software development practices that have captured the attention of e.g. GitHub and Programmer Twitter value things that go against the grain of these desires. This is especially obvious in the parts that mention dealing with files. You could write your Web app to do that. So go do it! Even where problems exist, like with mobile OSes (esp. iOS), there're things like remoteStorage. Think remoteStorage sucks? Fine! Go embrace and extend it and make it work. It's not actually a technical problem at this point.

This happens to be true of many of the new/up-to-date Web developers I see, too.

Anecdote: I never really did StackOverflow, either as a reader or a contributor. One day several years ago (well after StackOverflow had taken off), I figured that since I see people complain about JS being confusing all the time and since I know JS well, then I'd go answer a bunch of questions. The only problem was that when I went to the site and looked at the JS section, it was just a bunch of jQuery and framework shit—too much to simply ignore and try to find the ones that were actually questions about JS-the-language. "I know," I thought. "I'm in the JS section. I'll just manually rewrite the URL to jump to the ECMAScript section, which surely exists, right? So I did that, and I just got redirected to the JS section...

Memory usage is a concern? wat

It's a problem, sure, if you're programming the way NPMers do. So don't do that.

This is a huge problem I've noticed when it comes to people programming in JS—even, bizarrely, people coming from other languages like Java or C# and where you'd expect them to at least try to continue to do things in JS just like they're comfortable doing in their own language. Just because it's there (i.e. possible in the language, e.g. dynamic language features) doesn't mean you have to use it...

(Relevant: How (and why) developers use the dynamic features of programming languages https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf)

The really annoying thing is that the NPM style isn't even idiomatic for the language! So much of what the NodeJS camp does is so clearly done in frustration and the byproduct of a desire to work against the language. Case in point: the absolutely nonsensical attitude about always using triple equals (as if to ward off some evil spirits) and the undeniable contempt that so many have for this.