
Penmanship and programming education (2016) - dhotson
https://macwright.org/2016/08/28/penmanship.html
======
kazinator
> _}))}`] } }_

Yet only things called Lisp ever get flamed for this.

If it is just )))))) you only have to just auto-repeat ) until the editor
indicates a match to the one you are trying to close. It's only "how many you
owe", not "what kinds do you owe, in what order".

~~~
bsder
Because, in Lisp, getting it wrong means that you don't know which one was
supposed to close _which_ opener. And which is a vector, which is a list,
which is a hasmap, etc.

Clojure, in my opinion, did this right. You don't need very many alternate
delimiters to get a lot of bang for the buck and break things up.

~~~
tomsthumb
> getting it wrong means that you don't know which one was supposed to close
> which opener

This is solved by "jump to matching", which every worthwhile editor I've used
has had.

~~~
kazinator
That causes the problem of knowing something you don't want to know. _That_
problem, in turn, is solved by not looking at what "jump to matching" is
specifically doing, other than watching for it hitting your "target
parenthesis".

Example. I have this, in the middle of a larger body of code with more open
parentheses which are not shown:

    
    
              (foo (((((bar) ...
                  .....)) <- 
    

Suppose that the point indicated by the arrow, I want to close _(foo_ , and
only _(foo_. Perhaps I want to start another unit that is on the same level of
nesting as foo:

    
    
              (foo (((((bar) ...
                    )) <-  must close this 
           ;; (bar ... <-- want to start this; doesn't exist yet
    

So I just type ), or even auto-repeat. The jump-to-matching feature jumps
backwards onto various parentheses that _I don 't care about_, getting closer
and closer to _(foo_. That _(foo_ is where my eyes are; I stop when I see the
backward jump hit _(foo_. If I overshoot, then I just backspace. Any good
jump-to-matching feature works when you backspace to a parenthesis, not only
when you type a new one. So after an overshoot, I can still keep my eyes on
the _(foo_ and backspace until the cursor jumps to _(foo_. It's like keeping
your eye on the ball or other target in a sport.

There is no value in knowing which of the other parentheses match which
openers, and no value in having to interrupt the )))) to deal with other kinds
parenthesis, when all I want is to close ` _(foo_ is a nuisance. That's just
the down-side of whatever notational benefit those other kinds of parentheses
bring.

------
marcus_holmes
I don't use the "I owe a thing" method. I put the closing bracket/quote in
when put the opening one in, and then hop left a space and fill in the
content. I find it too confusing otherwise. For exactly the reason the author
describes.

~~~
kazinator
It must be that neither of you use an editor which knows how to match
parentheses. Then the choice of habit is largely moot. Also, that little
leftward jump can be automated by the editor, which is useful if you want it
more often than not.

~~~
tmcw
Author here. I've used plenty of editors that 'know' how to manage
parenthesis. And editors that did even more than that, like auto-completing
snippets and moving around the cursor.

It's all great, and I too think paredit is great! But these are all techniques
for improving the "writing new code" experience, which is the minority of work
that anyone does. Nobody writes perfect code the first time. And these
conveniences for writing new code don't help much with the majority of my
time, which is spent editing, deleting, and refactoring code - and
understanding at first glance the structure of a program from its punctuation.

So, sure - editors can do more and I'm hopeful about them. But I don't think
that 'automatic bracket insertion' actually fixes this problem. I think it
makes the task of writing code seem easier but doesn't help at all with the
hard parts.

------
hzhou321
The idea that we need to get the code correct in one-go is questionable. Any
coder only has limited slots for short-term memory. Spending some of those
slots keeping track of syntax balancing is a questionable advice.

Instead of getting students comfortable with the syntax, I try to get students
comfortable with syntax errors. Syntax errors are often trivial to fix after
accumulating some experience; and as one gets experienced, they (syntax
errors) tend to diminish anyway. However, the fear of syntax error -- just
like the fear of water when learning to swim -- is very difficult to overcome
and can be detrimental.

There is no logical reason to fear syntax errors, and there is no logical
reason to worry about syntax when we are working with semantics.

Of course, we shouldn't accumulate syntax debt after hundreds of lines. We
should organize our code into isolatable and testable units that fit into
quick try/test and feedback cycles -- but that is common sense.

------
elipsey
Funny, but slighly off topic; I just had a long conversation about the
opportunity cost of teaching penmanship in public schools.

If my friend and I had worked harder at penmanship, and less hard at optional
studies in AP/STEM stuff, we'd be less employable but would have scored better
on the hand-written part of our placement tests. We both got a lot of grief in
school from the traitionalists for our crappy hand writing. She still can't
write cursive!

~~~
emodendroket
I mean I don't think being able to write in a way that can be read is some
obscure, useless skill. I had to go through a lot of extra instruction in
penmanship when I was a kid but it was totally worth it because a life where
nobody could read anything I wrote would have been needlessly difficult.

------
red_admiral
> I think it’s time to give syntax and writing the time and respect it
> deserves.

Before I became a programmer, I did Latin at school - the whold fiddliness of
endings/cases was a great preparation. We frequently used terms for "syntax",
"parse" and "[parse] tree" in class. This approach probably doesn't scale, but
it worked really well for me.

------
ericbb
Related: Computation and State Machines by Leslie Lamport
([https://www.microsoft.com/en-
us/research/publication/computa...](https://www.microsoft.com/en-
us/research/publication/computation-state-machines/)).

------
fhood
> Programming is _relatively_ unforgiving

Not sure if it was intentional, but I got a good giggle out of this line.

------
xupybd
I don't know you learn these things with practice. You practice when it's fun.
But that part of programming is boring. Maybe some focus could be given but it
sounds like it could suck the motivation out of would be programmers.

