learning to program

[atheorist]

One of the first things that you need to do if you want to learn to program is to look at the connections between syntax and trees and nested parentheses and semantics. We speak to one another (and write to one another) so fluently that it's not obvious that natural language is in some important sense tree-shaped. Someone who has never studied

Comments

[darius]

About "how are parsers typically constructed?" this past week I made https://github.com/darius/peglet : trying to make the internals approachable to newbies, for a library good enough to actually use often. I don't yet know if it succeeded at either. One thing to think about next is examples of DSLs a pretty-new programmer might build to make their work easier, once they've been introduced to this stuff.

https://github.com/darius/circuitexpress/blob/master/text.md also aims at that next level of "how the world is put together" for people with basic programming. (I got back into the parsing above partly because it's needed for this project.) It's a scary project for me and I'm not sure how much of it makes sense to attempt for a reader without more programming experience.

Sorry about the continued self-horn-tooting -- just, feedback welcome, as usual.

[atheorist]

Peglet looks awesome, and I look forward to hearing about circuits.

I particularly like the 'instructing homunculi' vs 'inanimate causality' distinction. Do you think there might be (after some training) an intermediate a 'functional' mindset, where the programmer understands the code in terms of definitional rules which are semantic like instructions, but a bit lifeless like rods or gears?

Sometimes it's necessary to break out of a functional mindset into an inanimate causality mindset in order to go down below the linguistic abstractions and talk about, for example, space or time concerns.