Re: Re (tilly) 4: Ways of commenting subroutines

[Shadowfax]

once again i am assulted by those who cannot or willnot
agree to disagree. i do not argue your choice of style is
wrong, i recognize it is merely different than mine. since
you do not agree that writing the most efficient code by
removing all unneeded processor instructions is a useful
practice i will not ask you for help in beginning work
on a new o/s. that's fine, it should not cause me to say
you are missing the point of being a good programmer. i
also never said it was the point, merely the method i
use to accomplish my goal of becoming the best coder
in the world. we all gotta have dreams don't we? i did
not say coming across problem that require ugly logic is
the mark of a hacker, i said not being afraid to use the
down and dirty answer, which is often NOT the obvious way,
is the mark of a hacker.

Shadowfax
-everlasting gobstopper

"A computer is almost human - except that it does not blame its mistakes on another computer."

[tilly]

Ironically one of the things that I would label as a key influence on my thoughts about how to program are the summaries of discussions on the Linux kernel mailing list. Efficiency matters. Efficiency is good, particularly for an OS. However even there - or possibly especially there - it is important to aim for a clean overall design where you have a hope of proving things correct. If you start with that then you have a framework where you can optimize what needs to be optmized, when it needs to be optimized. (And when you have learned more.) If you don't do that then you will never be able to work with your code to keep it in good shape as time passes, processor designs change, usage patterns change...

Now being the best coder in the world is a great aspiration. I fully support it. I want to be a great coder as well. But being a great coder really means having an eye for what matters. And what matters, what is hard, is that you are always going to be ignorant. The world is going to constantly change under your feet. Your code is going to be used in ways that you didn't expect by people who never expected to see it. The bottlenecks are not going to be where you thought they were. People changing your code are going to make mistakes. People are going to break your dependencies because they don't know about them.

Do you want a real challenge? If so then try to address that set of problems. Unlike trying to eliminate code it is a real problem. People want you to solve this. It is a hard problem that nobody knows how to really do well. It is a complex problem for which the parameters are constantly changing. It is an interesting problem which we are constantly learning about.

And you want the really amazing thing?

It turns out that when you try to solve this problem well, that in retrospect you do a very good job on virtually every other parameter that people care about. Your code naturally tends towards compactness. Your designs can be optimized. Your programs are easily tested and verified. Overall development speed is good. You can conceive of and carry out more ambitious projects. And so on.

Now you say that I am assaulting you and that I should just agree to disagree. Well I am not assaulting you, I am trying to open your eyes to a correct prioritization of goals. And I disagree that I should agree to disagree, this is something which I believe there is a right answer to, and I am trying to convince you that what I believe to be the answer really is right.

[MeowChow]

Remember, computational efficiency and lines of code are not direcly related.