Coding and Confusion | Hacker News Reader

Coding and Confusion

joshbochu.com

45 pointsjoshbochu23 comments

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..

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.)

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.

1. Feuerbach(1881) The Essence of Christianity https://libcom.org/files/The%20Essence%20of%20Christianity.p... (p. 17)

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.

Back burner thought and mind wandering are also really important aspects of intelligence and creativity, but it's difficult to test them.

yes and experience/maturity, which is kinda knowing how to deal with finite immediate memory in the face of larger conceptual and unknown domains.

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.

> 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.

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.

The best man pages have an "Examples" section with common usage examples. Unfortunately not all of them do.

there is also "tldr" https://github.com/tldr-pages/tldr

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.

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.

Is it possible to accomplish the latter without the former?

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.

Fascinating stuff. For anyone interested in learning more and also technics for working with code, the Programmer's Brain [0] is an excellent book.

[0] https://www.goodreads.com/book/show/57196550-the-programmer-...

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.

[0] https://youtube.com/watch?v=Uwuv05aZ6ug

A handy thing to keep in mind during code reviews

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.

hey! thank you for the kind words! i hope that you found it useful in some way :)

Reply on news.ycombinator.com