When I had started my PhD, I thought the writing part of a paper was just the last thing I needed to do to summarize my results, like a boring epilogue to the more exciting science. What surprised me was how much of the scientific process relied on my ability to convey my ideas to someone else. And to be able to do that you need clarity of mind, you need to have worked through multiple drafts to be able to get to your point as efficiently and clearly as possible. So many times I only discovered what I was actually researching during the writing part.
The problem with AI writing is that it makes people believe that writing is just writing and not a tool for thinking very deeply about the topic you are writing about. I am not completely opposed to AI assisted writing, but if I see AI writing, it’s telling me that the author tried to take a shortcut in their own thinking and it’s a good heuristic that the ideas will not be thought through enough to warrant my complete attention.
This happened to me recently. I just asked what the prompt was. I found it really tough to read AI words, not knowing the weight to put in each word. A almost gave it more credit than was due and responded in detail, before seeing the prompt and responding barely at all - equivalent to the thought put in.
>it’s telling me that the author tried to take a shortcut in their own thinking and it’s a good heuristic that the ideas will not be thought through enough to warrant my complete attention.
Even worse: Facing AI writing, there's a strong suspicion that any concerns or counterpoints you bring won't be actually considered, but rather copypasted into an llm session.
I feel that way about coding. Sometimes you have an idea and a plan to implement it. But once you start coding you realize that some things were not fully right or way more complex that it should
If you let AI code for you, you will lose that
Being forced to take notes and write essays in school made me hate handwriting specifically and dislike writing in general. Now that I have a choice, I never use stationery or take notes for any purpose, and everything useful that I learned or did in my entire life has been done without writing being a part of the process.
When i started writing i felt the pressure to always go from draft to a polished piece. i posted a couple things i worked semi hard on and received 0 views/reads because i don't really have much of an online presence at all.
From there i kinda just moved on and write purely for myself, and use it to up my own thoughts. Very rarely, something will receive a second pass days later, and thats just more to go back on my past thoughts and try to tighten them if i feel that is needed.
I tend to split my day into two parts, my work hours and my "unplug" hours, and the writing was mostly landing in those unplug hours as a way to sorta summarize my day. Last week or so I decided im moving that writing into the very first thing I do each day, and it has really been absurdly effective at getting new ideas flowing quickly. I used to depend on my later day brain that was somewhat "depleted", for lack of a better way to describe how i work, and from there that would kinda birth what i work on the next morning, with maybe some iteration while working.
Now instead I just do both, I open the day with ~500-1500 words, just anything that comes out, then i potentially get stuck, and ill maybe dump that to a model as just a modern rubber duck, not anything like "write for me, or finish this thought", just a kinda nudge to really toss back at me what im fully considering and then maybe i pivot back and chase down the most interesting of the topics for a few hundred more words, or get straight to work on what i thought was the most vital of all those ideas to chase while im fresh in the morning.
Writing code (Programming) is a thinking tool too.
When you are writing code manually, actually you are thinking about what you are doing, what you will build actually, what are your or users' real requirements, etc.
This will sound extremely stupid, but I have a skill that I use after letting an agent write code for a new feature. This skill creates a copy of the base branch and shows me each of the diffs that matter (outside of imports and other non-important boilerplate) and then I type it on an editor.
I don't use it too often because of the time it takes, but for critical work it is really good.
I have tried to come up with other equivalent ideas, like asking questions about a specific aspect of a feature, or showing the diff with some gaps to be filled, and even though they help I am still on the look out of methods to "imprint" the understanding of features into our brain.
Does anyone know any good papers or studies that could be useful in this research?
Most of my projects are born out of scribbles on paper, system diagrams with boxes and little arrows to try to describe the system I want to build or my thought process written down like in this post.
When I get it on paper and everything feels right I start creating the codebase but I have to get it down first, feels like I remember it more after I save my thoughts to external paper storage.
I have over the decades tried every combination I can think up or have read about for designing things and I always land back in the same place, A4 5mm square pad (cheap but not the cheapest) and a really good (but not expensive) set of ballpoints in black/blue/red/green (and mostly it's black anyway).
There is something about the complete free form nature of pen and paper that makes me think better, I bought a nice ipad/pencil a few years ago thinking that would replicate it but it didn't, it was closer but not close.
If it's something I want to keep I just take a photo but vast majority of notes are transient anyway.
I spent an unreasonable amount of time recently thinking about how to color- (and symbol-) code my notes. I wanted to create a simple generally applicable system that I can use for any project.
For thinking, nothing beats handwriting. It's just the unconstrained freedom of movement in every direction, shape or form, and the lack of friction and distractions.
But then you sometime also want to organize or share stuff, so that's where digital comes in. I have an automation that takes a photo of my notes with my phone, uploads it to Obsidian, and OCRs it into markdown and tags it, so I basically end up with a "symbolic" 1-1 equivalent of analog handwriting + digital text
My system still evolves, but what I currently use is:
Color:
- black = just "normal" text
- red = critical/"must"
- yellow = important/"should"
- green = highlighted/"could"
Symbols:
- bulletpoint
[ ] task
-> reminder
I also do brackets and underlines which translate to # heading1 and ## heading2 in markdown
I write by hand with a fountain pen with black ink + use 3 fineliners and small colored sticky flags.
Some observations:
- yellow is not great on white paper due to bad contrast; it also rarely comes as ballpoint, but fineliner options are available
- blue and green are visually very similar, to the point of kinda being redundant
- for sharing with other people, the system must be as generally understandable as possible. Here the traffic norms such as ISO 7010 (https://en.wikipedia.org/wiki/ISO_7010) could be considered
- also there's the aspect of accessibility, with a relevant portion of population being colorblind
- The simplest most effective system seems to be: one main color (black or blue) and one highlight color (red I think works best), plus a couple of symbols such as bullet point, task, reminder that translate well into markdown
Agreed, I used to role my eyes when my professors asked me to do things like pseudocode (which I still don't do too much) but the act of writing an outline for the general structure of a program always helped me get over the initial hump of starting a new project.
But, to the claim of how to think in the age of LLMs, I think it’s worth contrasting the other approach, which is a dialog with the LLM; two things are needed IMO to keep things honest:
First, you need to keep asking the LLM to explain things, until you understand what it did. Lots of angles here; have the LLM make a design/product doc, write one-off architecture explainers, write throwaway data-viz tools to explain the data distribution. Then ask a fresh copy to adversarially review the core concepts. Try asking a different frontier model too.
Second, you need to push for “proof”, in other words, ask for demos and try it yourself. Imagine yourself a CEO or VC; how do you know if the output of an entire org is vaporware? One thing to beware is launching into a field where you don’t have expertise and can’t actually validate the output. This takes time of course, but for example if you write a stress test script and get CPU/QPS numbers, these complex validators are IME quite reliable when you apply the same rigor from 1) above to their construction.
I'd been a software engineer for 25 years before language models came into the scene. There were so many parts of the engineering world I had no idea about: Large cloud data processing, lower level device / GPUs, UI frameworks and design.
I kept my to my niche.
Now I can build anything, but as I'm building it, I try to understand at least how it works. So I'm constantly asking questions. In the process, I think of my prior engineering skill as somewhat childlike. As I thought I was a decent engineer, I now see that I was decent at some things, but far from the kind of breadth that the wide engineering world has.
I think the takeaway is that you should always be curious and build things. Whether it's writing or discussing with an language model, writing software by hand, or creating software with a model and understanding it, I think you have the same effect.
A common refrain for teachers and writers is that they learned so much producing their work. You think you know it, and then you go to teach it and realize how much you didn't know.
I'm a big fan of marbled composition books. They're cheap and durable enough. You can write in them without a table. I have 5-6 of them going at once for various tasks. And somehow (for me) the ideas flow more freely longhand than they do at the keyboard. When full, you can cut the spine off with a box cutter and scan it. G4 compression loses the color, but makes really small PDFs.
It's easy to produce better written content than an LLM. And that's good for the reader and the writer.
I endlessly enjoyed the comparison with a Turning Machine. When I study someone's complex work, I do notes to keep several things in my sight scope: a piece of paper, PowerPoint slide or some fancy markdown text editor with syntax highlight. Seems like that this focusing is somewhat the natural way of building neuronal connections: if a logical piece is missing we have to use imagination to complete it and only then it nicely fits into our brain's "hologram" of the world.
There is a wonderful book "Exploring Writing" by John Langan. I found it in our library when I was in my PhD writing phase. I highly recommend it to anyone who has problems building text and who wants to learn how to master its structuring.
And for freewriting, sometimes when it gets really hard to move further: https://3am.freewriter.app/
If you set 5 min target duration, you will be awarded with a full version of the song!
It's an attractive thought, this comparative look at FA and TM. However it is misleading to an extent.
A Turing Machine's capabilities exceed the FA's because it has a 'store of knowledge'. It is both recording and reading, repeatedly. There is erasure, too. So if we're aspiring to TM-hood, the guidance seems to be write, and re-read (your own thoughts), and re-evaluate, and re-write. This process is subject to the halting problem. /g
Writing as a thinking tool has become sort of a meme these days.
And, yes, I also generally believe it’s a good thing to use it as a tool. I try to do use it as often as I can.
But… I think it’s also important to note that there are - like with almost anything - pitfalls and downsides. I rarely see them discussed and thus want to bring them up:
For highly analytical people, writing may become counterproductive. Especially, when it is used to continuously elaborate thoughts rather than to challenge assumptions, test hypotheses or reach decisions.
It can lead to over-analyzing or pseudo-rationalizing.
There's always this peculiarity regarding the fact that writing by hand, is not the same as writing by kbd. So I'm always confused which of these two actually authors, mean, though I agree - any sort of note taking is better than none.
For me I think the distinction is more about structure and rigidity than keyboard vs pencil. Sketching free-form notes and especially little diagrams is a really powerful thinking tool. I also like to sketch my thoughts in org mode, which has some advantages over paper (structural editing, ability to zoom in and out by folding subtrees) and some disadvantages (tree structure instead of arbitrary spatial structure, more friction for diagrams).
I have a really hard time using WYSIWYG editors for thinking-by-writing. I think it’s because it’s hard to see partially-formed structure so it feels less malleable.
Yes, me too! I like using sketch notes to think through things nonlinearly, then I make an outline in Org or use an AI to get the text from a sketch, and then maybe I'll refine the sketch so it can be an illustration that
I embed back into Org. Structural editing is fantastic for reordering thoughts and converting back and forth between lists and paragraphs/sentences.
Beyond all this, there's also tailoring your message to your audience.
In sales, you might call this finding "words that work" or "the pain points". AI will not know how to do this because it's getting a vibe check of the room.
You cannot merely be a sensory part for the AI unless you want to sound as cringe and out-of-touch as the majority of the training data (stale social media). Garbage in, garbage out.
> Yet the only difference between a FA and a TM is that
> the TM, unlike the FA, has paper and pencil.
> Think about it.
The analogy doesn't works if you really think about it. A TM with a finite tape is equivalent to an FA. The fundamental difference between a TM and an FA is that a TM has infinite space.
(Yes, I know I missed the point and am not very fun at parties.)
No, this is a very good point - you need a supply of pen and paper, such that it feels effectively infinite. Buying a nice notebook or a nice pen is a trap because both feel finite; buying a box of decent pens and a carton of decent notepads takes you out of the scarcity mindset and unlocks the Turing machine like advantages mentioned.
I was thinking of the same. FSA can multiply within bounds. For FSA, the storage is the state itself and bounded.
I agree with the sentiment but not a fan of analogies like this. We do have memory even if we don't write. Each organ adds to the memory imprint making it stronger. Visual, smell, taste, audio etc Each action adds more imprints. And this makes more sense to me than an analogy.
Another analogy which never made sense to me was improving by just 1% every day (1.01³⁶⁵).
Analogies do help explain phenomena I cannot even relate to at all, like telling me how life on Mars would be.
Ofcourse I'm not invited to parties as you can imagine, taking things literally.
Are you saying that 1.01^365 is too big? I think there are lots of things where if you are starting from near zero skill, that's not a crazy big number.
Not parent commentor, but My issue with 1.01^365 analogy is that it implies that somehow that skill multiplies itself. There is no obvious reason to believe the gain from _(skill acquisition, language learning, workout, whatever) is better modeled as 1.01^365 than 1+(0.1*365).
When I had started my PhD, I thought the writing part of a paper was just the last thing I needed to do to summarize my results, like a boring epilogue to the more exciting science. What surprised me was how much of the scientific process relied on my ability to convey my ideas to someone else. And to be able to do that you need clarity of mind, you need to have worked through multiple drafts to be able to get to your point as efficiently and clearly as possible. So many times I only discovered what I was actually researching during the writing part.
The problem with AI writing is that it makes people believe that writing is just writing and not a tool for thinking very deeply about the topic you are writing about. I am not completely opposed to AI assisted writing, but if I see AI writing, it’s telling me that the author tried to take a shortcut in their own thinking and it’s a good heuristic that the ideas will not be thought through enough to warrant my complete attention.
This happened to me recently. I just asked what the prompt was. I found it really tough to read AI words, not knowing the weight to put in each word. A almost gave it more credit than was due and responded in detail, before seeing the prompt and responding barely at all - equivalent to the thought put in.
>it’s telling me that the author tried to take a shortcut in their own thinking and it’s a good heuristic that the ideas will not be thought through enough to warrant my complete attention.
Even worse: Facing AI writing, there's a strong suspicion that any concerns or counterpoints you bring won't be actually considered, but rather copypasted into an llm session.
That's a good thing. The writer who has nothing to say and the dumb audience who doesn't care stay down where they belong pacified by their "AI".
I feel that way about coding. Sometimes you have an idea and a plan to implement it. But once you start coding you realize that some things were not fully right or way more complex that it should If you let AI code for you, you will lose that
"Everybody has a plan until they get punched in the mouth (at runtime)." - Mike Tyson
Yes. The code I produce in a year I could type in a week. The time goes into understanding the problem.
The problem with AI is that it's entire selling point is saving time by not needing to think very deeply about topics.
The writing is downstream of that.
Being forced to take notes and write essays in school made me hate handwriting specifically and dislike writing in general. Now that I have a choice, I never use stationery or take notes for any purpose, and everything useful that I learned or did in my entire life has been done without writing being a part of the process.
When i started writing i felt the pressure to always go from draft to a polished piece. i posted a couple things i worked semi hard on and received 0 views/reads because i don't really have much of an online presence at all.
From there i kinda just moved on and write purely for myself, and use it to up my own thoughts. Very rarely, something will receive a second pass days later, and thats just more to go back on my past thoughts and try to tighten them if i feel that is needed.
I tend to split my day into two parts, my work hours and my "unplug" hours, and the writing was mostly landing in those unplug hours as a way to sorta summarize my day. Last week or so I decided im moving that writing into the very first thing I do each day, and it has really been absurdly effective at getting new ideas flowing quickly. I used to depend on my later day brain that was somewhat "depleted", for lack of a better way to describe how i work, and from there that would kinda birth what i work on the next morning, with maybe some iteration while working.
Now instead I just do both, I open the day with ~500-1500 words, just anything that comes out, then i potentially get stuck, and ill maybe dump that to a model as just a modern rubber duck, not anything like "write for me, or finish this thought", just a kinda nudge to really toss back at me what im fully considering and then maybe i pivot back and chase down the most interesting of the topics for a few hundred more words, or get straight to work on what i thought was the most vital of all those ideas to chase while im fresh in the morning.
Writing code (Programming) is a thinking tool too.
When you are writing code manually, actually you are thinking about what you are doing, what you will build actually, what are your or users' real requirements, etc.
This will sound extremely stupid, but I have a skill that I use after letting an agent write code for a new feature. This skill creates a copy of the base branch and shows me each of the diffs that matter (outside of imports and other non-important boilerplate) and then I type it on an editor.
I don't use it too often because of the time it takes, but for critical work it is really good.
I have tried to come up with other equivalent ideas, like asking questions about a specific aspect of a feature, or showing the diff with some gaps to be filled, and even though they help I am still on the look out of methods to "imprint" the understanding of features into our brain.
Does anyone know any good papers or studies that could be useful in this research?
As long as you generate code in small increments and intentionally I don't think its a big deal.
Most of my projects are born out of scribbles on paper, system diagrams with boxes and little arrows to try to describe the system I want to build or my thought process written down like in this post.
When I get it on paper and everything feels right I start creating the codebase but I have to get it down first, feels like I remember it more after I save my thoughts to external paper storage.
I have over the decades tried every combination I can think up or have read about for designing things and I always land back in the same place, A4 5mm square pad (cheap but not the cheapest) and a really good (but not expensive) set of ballpoints in black/blue/red/green (and mostly it's black anyway).
There is something about the complete free form nature of pen and paper that makes me think better, I bought a nice ipad/pencil a few years ago thinking that would replicate it but it didn't, it was closer but not close.
If it's something I want to keep I just take a photo but vast majority of notes are transient anyway.
I could write an ode to the 5mm grid... Yellow Rhodia No. 16, I'm in love!
https://www.dickblick.com/products/rhodia-top-stapled-notepa...
Exactly. I also use those colors.
I made a little system where blue diagrams are services I need to code and host like a nodejs server
green is stuff I need to host only like nginx, but no coding
red is external infra I can't control at all, like Anthropic's API.
And then I make drawings of how I connect them and in the end I just generate the code, so I go from pen and paper to claude code.
I spent an unreasonable amount of time recently thinking about how to color- (and symbol-) code my notes. I wanted to create a simple generally applicable system that I can use for any project.
For thinking, nothing beats handwriting. It's just the unconstrained freedom of movement in every direction, shape or form, and the lack of friction and distractions.
But then you sometime also want to organize or share stuff, so that's where digital comes in. I have an automation that takes a photo of my notes with my phone, uploads it to Obsidian, and OCRs it into markdown and tags it, so I basically end up with a "symbolic" 1-1 equivalent of analog handwriting + digital text
My system still evolves, but what I currently use is:
Color: - black = just "normal" text - red = critical/"must" - yellow = important/"should" - green = highlighted/"could"
Symbols: - bulletpoint [ ] task -> reminder
I also do brackets and underlines which translate to # heading1 and ## heading2 in markdown
I write by hand with a fountain pen with black ink + use 3 fineliners and small colored sticky flags.
Some observations: - yellow is not great on white paper due to bad contrast; it also rarely comes as ballpoint, but fineliner options are available - blue and green are visually very similar, to the point of kinda being redundant - for sharing with other people, the system must be as generally understandable as possible. Here the traffic norms such as ISO 7010 (https://en.wikipedia.org/wiki/ISO_7010) could be considered - also there's the aspect of accessibility, with a relevant portion of population being colorblind - The simplest most effective system seems to be: one main color (black or blue) and one highlight color (red I think works best), plus a couple of symbols such as bullet point, task, reminder that translate well into markdown
Cool! Im also thinking of turning them into markdown eventually with the idea to design software only on paper and then pass it off to claude after.
I really think we could go back to pen and paper fully for software design.
Agreed, I used to role my eyes when my professors asked me to do things like pseudocode (which I still don't do too much) but the act of writing an outline for the general structure of a program always helped me get over the initial hump of starting a new project.
Writing is a good thinking tool.
But, to the claim of how to think in the age of LLMs, I think it’s worth contrasting the other approach, which is a dialog with the LLM; two things are needed IMO to keep things honest:
First, you need to keep asking the LLM to explain things, until you understand what it did. Lots of angles here; have the LLM make a design/product doc, write one-off architecture explainers, write throwaway data-viz tools to explain the data distribution. Then ask a fresh copy to adversarially review the core concepts. Try asking a different frontier model too.
Second, you need to push for “proof”, in other words, ask for demos and try it yourself. Imagine yourself a CEO or VC; how do you know if the output of an entire org is vaporware? One thing to beware is launching into a field where you don’t have expertise and can’t actually validate the output. This takes time of course, but for example if you write a stress test script and get CPU/QPS numbers, these complex validators are IME quite reliable when you apply the same rigor from 1) above to their construction.
Instead of asking the LLM to explain things, you can use it as a pen.
Let it organize and work with your thoughts, as you say, how you say, as you do it.
Once that is clear, it can then better create those other artifacts.
I'd been a software engineer for 25 years before language models came into the scene. There were so many parts of the engineering world I had no idea about: Large cloud data processing, lower level device / GPUs, UI frameworks and design.
I kept my to my niche.
Now I can build anything, but as I'm building it, I try to understand at least how it works. So I'm constantly asking questions. In the process, I think of my prior engineering skill as somewhat childlike. As I thought I was a decent engineer, I now see that I was decent at some things, but far from the kind of breadth that the wide engineering world has.
I think the takeaway is that you should always be curious and build things. Whether it's writing or discussing with an language model, writing software by hand, or creating software with a model and understanding it, I think you have the same effect.
A common refrain for teachers and writers is that they learned so much producing their work. You think you know it, and then you go to teach it and realize how much you didn't know.
I'm a big fan of marbled composition books. They're cheap and durable enough. You can write in them without a table. I have 5-6 of them going at once for various tasks. And somehow (for me) the ideas flow more freely longhand than they do at the keyboard. When full, you can cut the spine off with a box cutter and scan it. G4 compression loses the color, but makes really small PDFs.
It's easy to produce better written content than an LLM. And that's good for the reader and the writer.
I endlessly enjoyed the comparison with a Turning Machine. When I study someone's complex work, I do notes to keep several things in my sight scope: a piece of paper, PowerPoint slide or some fancy markdown text editor with syntax highlight. Seems like that this focusing is somewhat the natural way of building neuronal connections: if a logical piece is missing we have to use imagination to complete it and only then it nicely fits into our brain's "hologram" of the world.
There is a wonderful book "Exploring Writing" by John Langan. I found it in our library when I was in my PhD writing phase. I highly recommend it to anyone who has problems building text and who wants to learn how to master its structuring.
And for freewriting, sometimes when it gets really hard to move further: https://3am.freewriter.app/ If you set 5 min target duration, you will be awarded with a full version of the song!
It's an attractive thought, this comparative look at FA and TM. However it is misleading to an extent.
A Turing Machine's capabilities exceed the FA's because it has a 'store of knowledge'. It is both recording and reading, repeatedly. There is erasure, too. So if we're aspiring to TM-hood, the guidance seems to be write, and re-read (your own thoughts), and re-evaluate, and re-write. This process is subject to the halting problem. /g
Writing as a thinking tool has become sort of a meme these days.
And, yes, I also generally believe it’s a good thing to use it as a tool. I try to do use it as often as I can.
But… I think it’s also important to note that there are - like with almost anything - pitfalls and downsides. I rarely see them discussed and thus want to bring them up:
For highly analytical people, writing may become counterproductive. Especially, when it is used to continuously elaborate thoughts rather than to challenge assumptions, test hypotheses or reach decisions.
It can lead to over-analyzing or pseudo-rationalizing.
Ask your favorite LLM for scientific references like this one: https://pubmed.ncbi.nlm.nih.gov/40137068/
There's always this peculiarity regarding the fact that writing by hand, is not the same as writing by kbd. So I'm always confused which of these two actually authors, mean, though I agree - any sort of note taking is better than none.
For me I think the distinction is more about structure and rigidity than keyboard vs pencil. Sketching free-form notes and especially little diagrams is a really powerful thinking tool. I also like to sketch my thoughts in org mode, which has some advantages over paper (structural editing, ability to zoom in and out by folding subtrees) and some disadvantages (tree structure instead of arbitrary spatial structure, more friction for diagrams).
I have a really hard time using WYSIWYG editors for thinking-by-writing. I think it’s because it’s hard to see partially-formed structure so it feels less malleable.
Yes, me too! I like using sketch notes to think through things nonlinearly, then I make an outline in Org or use an AI to get the text from a sketch, and then maybe I'll refine the sketch so it can be an illustration that I embed back into Org. Structural editing is fantastic for reordering thoughts and converting back and forth between lists and paragraphs/sentences.
this is great but machines can think better than us now so we don't need to think
Im even saying this with some level of sincerity
Two things came from reading this. First, I feel inspired to write regularly again. Second, I need to read more of this blog. Thanks!
Writing is a good (and necessary) tool for thinking.
Not all writing needs to be published.
Most shouldn't.
Beyond all this, there's also tailoring your message to your audience.
In sales, you might call this finding "words that work" or "the pain points". AI will not know how to do this because it's getting a vibe check of the room.
You cannot merely be a sensory part for the AI unless you want to sound as cringe and out-of-touch as the majority of the training data (stale social media). Garbage in, garbage out.
> Yet the only difference between a FA and a TM is that
> the TM, unlike the FA, has paper and pencil.
> Think about it.
The analogy doesn't works if you really think about it. A TM with a finite tape is equivalent to an FA. The fundamental difference between a TM and an FA is that a TM has infinite space.
(Yes, I know I missed the point and am not very fun at parties.)
No, this is a very good point - you need a supply of pen and paper, such that it feels effectively infinite. Buying a nice notebook or a nice pen is a trap because both feel finite; buying a box of decent pens and a carton of decent notepads takes you out of the scarcity mindset and unlocks the Turing machine like advantages mentioned.
I was thinking of the same. FSA can multiply within bounds. For FSA, the storage is the state itself and bounded. I agree with the sentiment but not a fan of analogies like this. We do have memory even if we don't write. Each organ adds to the memory imprint making it stronger. Visual, smell, taste, audio etc Each action adds more imprints. And this makes more sense to me than an analogy.
Another analogy which never made sense to me was improving by just 1% every day (1.01³⁶⁵).
Analogies do help explain phenomena I cannot even relate to at all, like telling me how life on Mars would be.
Ofcourse I'm not invited to parties as you can imagine, taking things literally.
Are you saying that 1.01^365 is too big? I think there are lots of things where if you are starting from near zero skill, that's not a crazy big number.
Not parent commentor, but My issue with 1.01^365 analogy is that it implies that somehow that skill multiplies itself. There is no obvious reason to believe the gain from _(skill acquisition, language learning, workout, whatever) is better modeled as 1.01^365 than 1+(0.1*365).