Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: Re: Re: Ways of commenting subroutines

by Shadowfax (Sexton)
on Mar 29, 2001 at 20:57 UTC ( #68128=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Ways of commenting subroutines
in thread Ways of commenting subroutines

first off, let me say that i do not disagree with you.
that said, i would like to clarify. i was not refering
to a problem unclear in that i did not understand. i was
describing the fact that sometimes the logic needed for
solving a problem is not obvious, is not intuitive, and
quit often is not any clearer than mississippi mud. these
are the times when after you understand the problem, you
can step back and see the issue still resides in a fog
bank, but rather than spend all day looking for a nice
little way to code so that your little sister in elementary
school can understand it, you bang in a quick and dirty
line that solves the problem and a nice descriptive
comment to enlighten your posterity.
in response to the 2:1 ratio... that's called 2 weeks notice
in my book. insanity is not my cup of tea, and that is
clinical right there. if you have not come across a problem
that requires ugly logic, you have not experimented much.
i also fall heavily in support of the "hacker ethic" described
so well by steven levy in "hackers - heroes of the
computer revolution" in that any code you can write,
i will write in less lines. (not a challenge, just
philosophy) "bumming" out instructions
is the foundation of computer programming and continues
to drive me as a programmer. if i write something, i
will write it later in less lines. i do not ask you to
agree, but i ask you to not insinuate my "more functionality
with less keystrokes" method is wrong. i do not argue
that you are wrong because you like to write in cute
little snippets with no comments, so please extend me
the same curtesy. thanx, and my what a beautiful horse
that was.


"A computer is almost human - except that it does not blame its mistakes on another computer."
  • Comment on Re: Re: Re: Ways of commenting subroutines

Replies are listed 'Best First'.
Re: Re: Re: Re: Ways of commenting subroutines
by willdooUK (Beadle) on Mar 29, 2001 at 21:34 UTC
    Shorter code is nearly always clearer code, true.

    What I'm saying though, is I always code with readability as my main priority (after making it work, of course) - but then I very rarely have to do any low-level, speed intensive code.

    As for the 'two weeks notice' - that's pretty much how it happened :)

Re (tilly) 4: Ways of commenting subroutines
by tilly (Archbishop) on Mar 30, 2001 at 03:57 UTC
    I won't insinuate then. I will say it.

    It is my belief that while trying to remove lines is a fun game, anyone who thinks that it is the goal of someone who would be a good programmer is missing the point. Being able to write tight code is a result, not a goal.

    The foundation of computer programming is the question, "How do I get this thing to be doing whatever I want?" That means getting it to work now. Having it work tomorrow for 2 things, neither quite what you started with and both harder tasks.

    Now you claim that coming across problems that require ugly logic is a mark of a hacker. I disagree. I think that a far better mark is finding nicer ways to think about problems than the obvious (bad) approaches...

      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.

      -everlasting gobstopper

      "A computer is almost human - except that it does not blame its mistakes on another computer."
        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.

Re: Re: Re: Re: Ways of commenting subroutines
by demerphq (Chancellor) on Oct 23, 2001 at 17:47 UTC
    I suppose considering your later posts that this a waste of time, but i felt the urge to make the following comment about something you said:

    "hackers - heroes of the computer revolution" in that any code you can write, i will write in less lines. (not a challenge, just philosophy) "bumming" out instructions is the foundation of computer programming and continues to drive me as a programmer.

    I have read Steven Levys book too, several times actually, it was inspiration for me in my younger years and I gave it to all of my colleagues as a Christmas present last year. From reading it I know that bumming instructions was a pastime performed by programmers using unbelievably small memory spaces (probably less ram than is in a digital wrist watch these days) on CPU's with minimal instruction sets at the very dawn of the computer era. (Consider that Knuths MIX is supposed to be representative of computer from two or three generations after the TX0 and code bumming, and it _only_ has 4000 words of ram.)

    but i ask you to not insinuate my "more functionality with less keystrokes" method is wrong.

    Yes thats _exactly_ what im saying. Bumming ops has nothing to do with the modern era where we have virtually unlimited ram (in comparison anyway) and rarely (if ever) write in assembly. (Embedded systems may be the exception, but my guess is that you arent doing that)It has even less to do with the use of languages like perl. In perl there are many many things that can be reduced into a minimal form, great for the programmer, horrible for efficiency. A simple example is the following:

    my ($x,$y)=(1,2); #one line, SLOW ($x,$y)=($y,$x); #three lines. fast. my $tmp=$x; $x=$y; $y=$tmp;
    On this level I recall Knuths explaination for why all of his code is presented in MIX, not some high level language (I paraphrase, when I get home ill get the proper quote and add it to the bottom of this post)

    Programmers are inclined by lazyness to write code as efficiently as possible, for them. This means that in a high level language they tend to use the constructs and mechanisms of the language in a way that reduces the required keystrokes. Unfortunately these construct rarely produce optimal code.

    There are lots of posts about optimisation, I've even been burned by the subject a couple of times (an example is here and Tilly provided me with an excellent link on the subject: Code Tuning you will note that I was set straight in a variety of ways) but I assure you that in most languages, and especially perl the smallest program is almost definately _not_ the most efficient. Which means that your 'bumming' game is a plain and simple waste of time, and not only that it'll probably produce sub optimal results. Note that the computer pioneers (Greenblat and co) probably didnt care about this as their primary aim was to get the maximum amount of functionality out of the smallest memory space.

    Oh, regarding your pecular formatting, I read one of your other posts where you say you defy convention as a matter of course. Thats cool. Lots of people do it. In fact odds are many of the people here by virtue of being hackers do as well. But they also understand that there are times, such as communicating with each other, when conventions are not foolish social constructions but rather the result of years and years of figuring out how to do something as efficiently and as error free as possible. Your habit of all lower case with no paragraph structure is difficult to read and therefore unlikely to be taken seriously. Assuming you are from an english speaking nation, I wonder if in your urge to defy convention you communicate only in pig latin? Or perhaps in Navaho?

    You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://68128]
[virtualsue]: Thank you, Discipulus. I must now go write some code. :-)
marto wanders off to think of a suitable to write on a retirement card

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2018-04-24 11:19 GMT
Find Nodes?
    Voting Booth?