This is a good article on the 'states' of knowledge, and how you float between them, and how to examine your (true) understanding of a specific piece of context. Great read.
I wish each language, framework and library had a manual on HOW to read their docs.
I have a very hard time with reading the official PHP docs. Very hard time.
The official JavaScript docs are not bad, but they throw too much information about each operation. I don't want to know every single possible way to use an operation. I want a Pareto Principle-based categorization of most common use-cases so that I can prioritize what to look at.
This reminds me a lot of my experience reading man-pages. Usually I end up at Stackoverflow to help me solve the problem at hand, because there's just too much to read through for some docs.
I often wonder about the neurology of memory regarding thinking. Often I think intelligence main parameter is size of L0 cache in the brain (sorry for the cheap metaphor). Normal people can solve problem, but it will require dozens of round trip between making up ideas / theories, checking them, pruning what was good or not, inferring new ideas from that. While a smart guy will probably do the same steps.. but in one shot. No pause, no gaps..
An interesting topic for sure. In terms of mastery / skill building, I'd figure those round trips are crucial for the novice and the master. It's just that the master has enough wisdom / experience in the back pocket to know which paths to branch and bound.
Pretty sure intelligence comes from the quality of your compiler optimizations. If you compile better subroutines that wastes less effort then you get vastly better results. A normal person might run on python while a genius runs on C, it is the same hardware but one is 100 times faster than the other in many cases.
Also explains why the concept of being smart is so elusive, as these optimizations are hard to reproduce and don't generalize to everything we think about. For example, a genius isn't better than an average person at filling out forms, there you are forced to think using unoptimized paths, you can't run those paths 100 times faster.
I love this comment, but maybe not for the intended reason. Why? Because I immediately wanted to add my two cents - another analogy by way of deep learning - that intelligence is like adding model capacity, like additional conv depth or or additional attention heads. That's fine and all, but then it struck me.
We're one level from popping the top off it all and coming to terms that we've fallen into a trap described by Ludwig Feuerbach.[1] The choice of analogies says just as much about us as they do about the subject.
Speed and space (of course!) help, but with terrible O complexity, it doesn't really matter how much memory you have or how fast you are. The search space gets big too fast.
e.g. changing the question, reasoning by analogy
How do we have insight, a hunch straight to the answer? It seems obvious that it's like DL; socially distributed search across people; trying out different things unconsciously... but the truth is, we don't know how we do it. We're like steam-punks saying it's obviously like a mechanical device, or Edison saying it's obviously like electrical relays. We just think in terms of the tech of the day, and by persona; introspection and observation. It's not science. It's maybe science fiction.
When we understand Strong AI, we will already know.
It's always fun to conceptualize the brain as a computer and reason by analogy (iirc it was a steam engine back in the day). I'm excited to see the next advancement the brain gets compared to.
I've caught myself conparing it to an ANN - though they are really quite dissimilar. But yes, I alos wonder what's next. I think it will build on what we have rather than being entirely new (but that's the kind of opinion that ages badly.)
Raymond Hettinger gave an entertaining talk [0] on a related topic. He taled about how the working memory limits are reflected in code, and how we can reduce the necessary cognitive load of understanding a piece of code.
I was hoping to also find mentions of how to effectively reduce these.
When reading code, I break things down differently.
1. Domain knowledge
2. Programming knowledge (e.g. recursion)
3. What is being done
4. How is it being done
5. Where/when is it being done
Wherever possible I try to stay with strong opinions and alignment on the first three. The last two should try to be as simple and clear as possible. Reading code in this day and age should not so much be about 'playing computer' in your head, but rather using well-known/tested patterns that allow for factoring/composition and accurate reasoning without requiring deep context.
Yes, instead of writing a custom for-loop use map/filter/reduce. Also make other things like this that fit either under computer-programming or domain knowledge. The interface/contract/behaviour of these 'known' parts can usually be made clear without unexpected side-effects. From then on, treat them as black-boxes.
It's rare that I find mental capacity to be the limiting factor, rather than the unintentional obfuscation of the implementation. Perhaps this is just to say that the code itself is a source of incidental (aka accidental) complexity or confusion.
Taking a quick glance at this comment again. I do plan on writing a few tactics to reduce confusion after I read (a programmer's brain) a bit more and can think more on it.
24 comments
[ 3.3 ms ] story [ 66.2 ms ] threadI have a very hard time with reading the official PHP docs. Very hard time.
The official JavaScript docs are not bad, but they throw too much information about each operation. I don't want to know every single possible way to use an operation. I want a Pareto Principle-based categorization of most common use-cases so that I can prioritize what to look at.
For some reason I really like this idea ;)
I think documentation, just like literate programming, would benefit from multiple views or learning paths of the same topic.
Also explains why the concept of being smart is so elusive, as these optimizations are hard to reproduce and don't generalize to everything we think about. For example, a genius isn't better than an average person at filling out forms, there you are forced to think using unoptimized paths, you can't run those paths 100 times faster.
We're one level from popping the top off it all and coming to terms that we've fallen into a trap described by Ludwig Feuerbach.[1] The choice of analogies says just as much about us as they do about the subject.
1. Feuerbach(1881) The Essence of Christianity https://libcom.org/files/The%20Essence%20of%20Christianity.p... (p. 17)
e.g. changing the question, reasoning by analogy
How do we have insight, a hunch straight to the answer? It seems obvious that it's like DL; socially distributed search across people; trying out different things unconsciously... but the truth is, we don't know how we do it. We're like steam-punks saying it's obviously like a mechanical device, or Edison saying it's obviously like electrical relays. We just think in terms of the tech of the day, and by persona; introspection and observation. It's not science. It's maybe science fiction.
When we understand Strong AI, we will already know.
[0] https://youtube.com/watch?v=Uwuv05aZ6ug
[0] https://www.goodreads.com/book/show/57196550-the-programmer-...
When reading code, I break things down differently.
Wherever possible I try to stay with strong opinions and alignment on the first three. The last two should try to be as simple and clear as possible. Reading code in this day and age should not so much be about 'playing computer' in your head, but rather using well-known/tested patterns that allow for factoring/composition and accurate reasoning without requiring deep context.It's rare that I find mental capacity to be the limiting factor, rather than the unintentional obfuscation of the implementation. Perhaps this is just to say that the code itself is a source of incidental (aka accidental) complexity or confusion.