Re: Programming beginners' documentation

[David Kastrup <dak@...>]

KHMan <keinhong@gmail.com> writes:

> But remember, part this learning involves making mistakes or bad
> decisions and learning from them. As we become more skilled in problem
> solving, we reduce the errors and mistakes and maximize productivity
> or quality of code.

More like "we fine-tune out errors and mistakes where they are not
recognized as such anymore and you can't easily escape their
consequences".

There are a few rules of thumb: debugging programs is twice as hard as
writing them.  Writing programs at the top of your mental capacity means
that you are not going to be able to debug them.  Debugging programs
from somebody else is double as hard than debugging your own.  Writing
somewhat close to the limit of your mental capacity means that your
programs are tied to yourself and won't be maintained when you no longer
can do that.

With languages like C++, the complexity of the language (and its appeal
for "great features") is such that you max out even on simple tasks.

I just had a short exchange with a very skilled C++ programmer who had a
cursory look at Lua.  One of the things he decried was its lack for
generics, a stronghold of C++ (supposedly).  I pointed out to him that
the cost that generics try avoiding (at the price of complexity) has
already been paid in Lua (by having dynamic typing).  There is just no
point for generics in Lua: the tradeoff flexibility/performance is not
there.  Lua always has the flexibility, and you can't get the
performance.

I also pointed out that the performance loss in Lua is O(1), which is
much less than the resulting costs from maxing out the programmer's
capacities.

For example, C/C++ programmers will use linked list representations
reflexively for about everything unless you kick them in the shin.  Lua
programmers don't have much of a choice, anyway: they use tables.

Brains are a precious resource in short supply, so you apply them
strategically.  And that means that the bulk passages of C++ programs
will tend to be inefficient.  Because one can.

-- 
David Kastrup