someone post a puzzle.

Once on a uni quiz one question was:
How do you measure the height of a building
with a barometer (the atmosferic thing).
One guy answered:
"drop the thing from the roof
and time it until it smashes on the ground"
he didn't get credit for that answer so he
complain. They allowd him to reanswer the question
and he said:
"tie a string to the thing, hang it from the roof,
measure the string"
and another answer:
"go to the building superviser and say 'look how nice this
thing is, it's your's if you tell me the height of the building'".

That's what I think of these puzzles.

:)

Ant

In article <bum8c2$13dn$1@digitaldaemon.com>, Ant says...
>
>someone post a puzzle.
>
>Once on a uni quiz one question was:
>How do you measure the height of a building
>with a barometer (the atmosferic thing).
>One guy answered:
>"drop the thing from the roof
>and time it until it smashes on the ground"
>he didn't get credit for that answer so he
>complain. They allowd him to reanswer the question
>and he said:
>"tie a string to the thing, hang it from the roof,
>measure the string"
>and another answer:
>"go to the building superviser and say 'look how nice this
>thing is, it's your's if you tell me the height of the building'".

I once went to this job test, where they asked questions of that kind. And you were _supposed_ to come up with as many answers as you could in 2 minutes. It's so wrong: first you spend all your life trying to learn which of the possible answers your parents, your teachers, your bosses, and your spouse wants -- and then these job folks slap you for 'not being creative'.

My Dad has the same experience: he was on a job interview, and they said "if it takes 5 guys 30 days to build a boat, how many days would it take 30 guys?" He answered "30 days". The questioner got angry, and asked why. "Well, there's going to be so much talking and twisting about how to make the boat."

In article <bum8c2$13dn$1@digitaldaemon.com>, Ant says...
>
>someone post a puzzle.
>
>Once on a uni quiz one question was:
>How do you measure the height of a building
>with a barometer (the atmosferic thing).
>One guy answered:
>"drop the thing from the roof
>and time it until it smashes on the ground"
>he didn't get credit for that answer

Come to think of it, the guy had the right answer,
and not the physics teacher. Barometers are so
inaccurate they don't show anything for a 10-
story building.

I feel sorry for you if you can't, because I think it's quite readable.  ;)

In turn, I hope I never have to read your code.  It would take too long, I'd have to sift through all kinds of unnecessary clutter probably.

Sean

"The Lone Haranguer" <The_member@pathlink.com> wrote in message news:bul8ja$2ikm$1@digitaldaemon.com...
> I hope I never have to read your code.
>
> In article <bul827$2i19$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >Bah.
> >
> >Usability in a boolean sense is a desirable property for some objects, especially for basic types in a C-derived language.  I prefer if (!s) because it's shorter, which means we all can read it quicker (fewer characters == fewer potential bugs, as whitespace and comments cannot possibly be bugs), thus all else being equal between two pieces of code, less code is always better.
> >
> >Coding defensively can be good, up to a point, I guess.  But not if it
gets
> >in my way too much.  There's little enough time in the day without typing
3
> >times as much as you have to.
> >
> >Sean

jeepers creepers, you two.

If we are to have a jousting competition, at least get your lances out.

In other words, let's have the two of you post your code, and we can vote on who's is the most smegworthy.

:)

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:buppp8$q8j$1@digitaldaemon.com...
> I feel sorry for you if you can't, because I think it's quite readable.
;)
>
> In turn, I hope I never have to read your code.  It would take too long,
I'd
> have to sift through all kinds of unnecessary clutter probably.
>
> Sean
>
> "The Lone Haranguer" <The_member@pathlink.com> wrote in message news:bul8ja$2ikm$1@digitaldaemon.com...
> > I hope I never have to read your code.
> >
> > In article <bul827$2i19$1@digitaldaemon.com>, Sean L. Palmer says...
> > >
> > >Bah.
> > >
> > >Usability in a boolean sense is a desirable property for some objects, especially for basic types in a C-derived language.  I prefer if (!s) because it's shorter, which means we all can read it quicker (fewer characters == fewer potential bugs, as whitespace and comments cannot possibly be bugs), thus all else being equal between two pieces of
code,
> > >less code is always better.
> > >
> > >Coding defensively can be good, up to a point, I guess.  But not if it
> gets
> > >in my way too much.  There's little enough time in the day without
typing
> 3
> > >times as much as you have to.
> > >
> > >Sean
>
>

Are comments clutter? Are they necessary clutter?

In article <buppp8$q8j$1@digitaldaemon.com>, Sean L. Palmer says...
>
>I feel sorry for you if you can't, because I think it's quite readable.  ;)
>
>In turn, I hope I never have to read your code.  It would take too long, I'd have to sift through all kinds of unnecessary clutter probably.
>
>Sean
>
>"The Lone Haranguer" <The_member@pathlink.com> wrote in message news:bul8ja$2ikm$1@digitaldaemon.com...
>> I hope I never have to read your code.
>>
>> In article <bul827$2i19$1@digitaldaemon.com>, Sean L. Palmer says...
>> >
>> >Bah.
>> >
>> >Usability in a boolean sense is a desirable property for some objects, especially for basic types in a C-derived language.  I prefer if (!s) because it's shorter, which means we all can read it quicker (fewer characters == fewer potential bugs, as whitespace and comments cannot possibly be bugs), thus all else being equal between two pieces of code, less code is always better.
>> >
>> >Coding defensively can be good, up to a point, I guess.  But not if it
>gets
>> >in my way too much.  There's little enough time in the day without typing
>3
>> >times as much as you have to.
>> >
>> >Sean
>
>

Comments are fine.  I can ignore them until they are necessary.  ;)

I *do* comment my code, but I usually do not attempt to translate the code into English, but merely support the code with the "why" and "this is written this way because if you change it to the more obvious method, it'll break for this reason" kind of comments.  More of a high-level overview, a sense of the purpose of the code.  My naming conventions make most other comments largely unnecessary.  Comments of the sort "float parameter1,  // the first parameter, of type float" and "++x;  // set x to whatever it used to be, plus one" and "class Foo  // a class called Foo that represents foo" just piss me off.  Those truly are noise.  Large automatically generated comment blocks are also suspect, as you've probably read elsewhere.  A 3 page comment block to describe a one page function, that actually contains only a few lines of useful information, is a waste, and should be reduced to just those few lines.  In projects of mine where I find such comments, I actively delete them.  I also change things like "Function(MyBoolean!=FALSE ? FALSE : TRUE);"  to  "Function(!MyBoolean)", and yeah, I'll do that in an if statement as well.  I find that inexperienced programmers tend to write very longwinded, roundabout code because they aren't used to simplifying logic.  Once it's simplified, they can actually read it a lot easier, but they can't write it simplified in the first place.  I also actively refactor common code, another common newbie coding problem that actually has serious maintenance ramifications.

Anyway, this is religious war material, and we should probably just agree to disagree.   My point is that the language should not force us to write longer code than is necessary... then again it shouldn't force us to write shorter code than is necessary either.  If it did, we wouldn't have anything to argue about, but it wouldn't succeed in the market.

Sean

"The Lone Haranguer" <The_member@pathlink.com> wrote in message news:buqc2p$1om8$1@digitaldaemon.com...
> Are comments clutter? Are they necessary clutter?
>
> In article <buppp8$q8j$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >I feel sorry for you if you can't, because I think it's quite readable.
;)
> >
> >In turn, I hope I never have to read your code.  It would take too long,
I'd
> >have to sift through all kinds of unnecessary clutter probably.
> >
> >Sean
> >
> >"The Lone Haranguer" <The_member@pathlink.com> wrote in message news:bul8ja$2ikm$1@digitaldaemon.com...
> >> I hope I never have to read your code.
> >>
> >> In article <bul827$2i19$1@digitaldaemon.com>, Sean L. Palmer says...
> >> >
> >> >Bah.

Sean L. Palmer wrote:
> Calm down, Ilya!

I'm sorry, I excuse myself.

However, walter had already said prior to this discussion that a zero-length array is a null array. This appears to be the D semantics, and if it doesn't work like that, a bug is to be filed instead of explaining how wrong all that Walter says is.

-eye

In article <burr37$15l5$1@digitaldaemon.com>, Sean L. Palmer says...
>
>Comments are fine.  I can ignore them until they are necessary.  ;)
>
>I *do* comment my code, but I usually do not attempt to translate the code into English, but merely support the code with the "why" and "this is written this way because if you change it to the more obvious method, it'll break for this reason" kind of comments.  More of a high-level overview, a sense of the purpose of the code.  My naming conventions make most other comments largely unnecessary.  Comments of the sort "float parameter1,  // the first parameter, of type float" and "++x;  // set x to whatever it used to be, plus one" and "class Foo  // a class called Foo that represents foo" just piss me off.  Those truly are noise.  Large automatically generated comment blocks are also suspect, as you've probably read elsewhere.  A 3 page comment block to describe a one page function, that actually contains only a few lines of useful information, is a waste, and should be reduced to just those few lines.  In projects of mine where I find such comments, I actively delete them.  I also change things like "Function(MyBoolean!=FALSE ? FALSE : TRUE);"  to  "Function(!MyBoolean)", and yeah, I'll do that in an if statement as well.  I find that inexperienced programmers tend to write very longwinded, roundabout code because they aren't used to simplifying logic.  Once it's simplified, they can actually read it a lot easier, but they can't write it simplified in the first place.  I also actively refactor common code, another common newbie coding problem that actually has serious maintenance ramifications.

Without taking sides in this conversation (it's between the two of you), I just have to say, PLEASE, all newbies, try to read the above, and plaster it on your wall.

Personally, I feel that the kind of comments a job seeking programmer's previous code contains tells me as much about his thinking as his code. And, unfortunately, a small difference in thinking makes an enormous difference in productivity for the company.

Sean is right, the code itself has to be so clear that no comments are
needed to explain what's going on! Comments should only be used to show
the unobvious: as above, what's going to break if you change this,
why we had to do it this way, or why this is coded so that at first
glance it looks non-optimal. BUT NEVER what the code does. That should
be readable from the code itself. And if it isn't, you should
change it. Variable names (#1 goof of newbies), lengty expressions
doing something that could be said in one sentence, structure of the
code, etc.

( An amazingly common misconception with newbies learning their first language is that the same overall structure you have in your home assignments will just expand when you "then later, when you're this Professional doing these 100,000 lines apps", is going to stay the same. That is, 50% of code lines in main(), the rest divided between "obligatory BS", obvious subroutines, etc.

What most newbies just cannot fathom, is that even 1M lines apps really have as short functions and procedures as typical home assignments. _They_ don't grow in length. There just are more of them. And the layers (levels of subroutines from the top level to the level that does the actual work) just keep increasing.

My first revelation as a young guy came when I got a hold of
Borland source code for the runtime libraries. Boy was I amazed
when I realized that all procedures and functions were less than
a screenful (at that time 24 lines!). At first this looked awkward,
inefficient, and "so hard to follow the program logic". )

And, that code can never be clear unless it is refactored. Few programmers, (that I know of, (with 2 exceptions)) write code Right from the start. Everybody else, (especially I) do have to refactor after the first successful test run. Being too lazy to do that even afterwards, only gives _yourself_ cumulatively more work.

This refactoring increases readability (for the pros, at least). It also makes the code _way_ easier to maintain! For yourself.

Having said that,
I do understand why new programmers (especially those writing their
first programming language) do make the kind of comments they do.
It arises from the fact that when you write your first lines of code,
you have to comment it so you yourself understand what's going on.
"This bit of code doubles the input variable, returning the square
of it."

Now, depending on the individual, you transcend this stage in a couple of months, or a couple of _decades_. (Trust me, I've seen enough.) With a lot of coaching and personal training, you can get _anybody_ above this level, but in the real life that's a wasted effort.

So, to threat kicking all newbies' butt: the sooner you learn to comment what Sean asks for and not what newbies do, the sooner you'll be considered Programmers. And those who don't make it "soon", ought to consider changing to marketing. No offence.

"Vathix" <vathix@dprogramming.com> wrote in message news:bukk58$1ip1$1@digitaldaemon.com...
> I'd prefer that it only
> append the \0 at the time of casting to char*, cast overloads are good
> for this; I wonder why they aren't in D.

There are many times in C where char*'s are not necessarilly 0 terminated, it's just a convention. By forcing this issue in D, unexpected strange bugs can crop up when interoperating with C. Unfortunately, when dealing with C APIs, one always needs to carefully check the documentation for it to see how to correctly pass strings. Win32 APIs are certainly NOT consistent about it.