|
> Part of the reason that programming syntax is usually taught by example, rather than by formalism is that the formalisms for programming syntax, well, look like this: (cribbing from wikipedia). Here's the thing though -- a "what is this syntax" guide does not imply that you need a formalism of the syntax. What the person is asking for, in my opinion, is a linkage between the symbols and the concepts. For example, when reading mathematics, often the problem was not my conceptual understanding of the material, but merely that I was not sure how to parse the symbols and map them to what it was doing. I could read a formula, but the mapping of each component piece as a shorthand was not there. At the time I did not internalize that "square root" is literally just getting the side of a square (A somewhat silly, obvious-in-retrospect idea! But it gives you a perfect example of the kind of mapping I'm talking about) -- because of this I wasn't able to get an idea of what it was doing! In such a case, your formalism would not have worked, because it's simply a grammar. I did not need the grammar -- examples can show that, wikipedia can show that, what I needed was enough information about the link between the symbolic, and the conceptual, that I could find reference material. What I found instead was either as you put down, literal grammars, or vast tomes of knowledge that required more vast tomes of knowledge to read and figure out what each one in turn was saying. So I would get lost down this rabbit hole. What the solution to this is, again IMHO, is a listing of syntax, yes, but with a conceptual mapping on the right. So not saying things that we already know -- like "this is a number", but having a construction of an IF statement, and then a conceptual mapping on the right in the form of written description of how it works, or a visual description like a flow chart. The point of writing was to convey knowledge, it is possible to convey intuition, and yet in scientific fields we seem adverse to doing so! It's treated almost like an unspoken thing, it is covered in passing, but almost never explicitly. It's why much of "intermediate programming" is difficult to break into, in my opinion -- and the same for mathematics (3blue1brown is breaking this up, however) |
# Add stuff to the end of a list with append li.append(1) # li is now [1]
And this is exactly the kind of stuff that keeps me from getting deeper into programming. I look at that, and wonder, "what the hell is that . doing?" Now, I know enough python to know that it is calling some function on an object called 'li', and that li is a list. or something that can take a .append() command. I also know that append() is some kind of function. But, these guides never give me enough detail on what the . means. Worse, it seems difficult to find answers to this kind of stuff in aggregate. If I google everything I can find stack exchange pages on each piece of syntax and can get to the point, but for fluency and retention I really need that conceptual piece.
I don't write software, but I use python/pandas for basic work with restructuring data. The hurdle to understanding how to slice data frames was incredible for me. I couldn't understand from the examples why the behavior works the way it does. I often feel like I can get working code without any real connection or understanding of why the code works.
You're answer is great, I wish there was a solution for this disconnect since I can't imagine I'm the only one who feels this way.
[1] https://learnxinyminutes.com/docs/python/