drw@cullvax.UUCP (Dale Worley) (07/31/87)
It's true that testing someone's ability to read (and write) such monstrosities as Keller's test isn't testing for their ability to read and write readable code. But it is a very good way to filter out people who are (1) a bit dense, or (2) don't have a good grasp of C. After all, how many of the readers didn't catch the extra '*' on 'char ****cpp', or didn't know that an extra ',' is allowed at the end of an initializer list? I've worked with people who were slow, and it's a real pain, and this test would have surely eliminated them, as garlic does a vampire. Dale -- Dale Worley Cullinet Software ARPA: cullvax!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw From the Temple of St. Cathode of Vidicon:
keir@vms.macc.wisc.edu (07/31/87)
In article <1418@cullvax.UUCP> drw@cullvax.UUCP (Dale Worley) writes: >It's true that testing someone's ability to read (and write) such >monstrosities as Keller's test isn't testing for their ability to >read and write readable code. But it is a very good way to filter out >people who are (1) a bit dense, or (2) don't have a good grasp of C. An even better way is to NOT hire people who pass the test, hence filtering out those people who are (1) hung up on esoterica, or (2) don't have a good grasp of programming. Oh, okay -- you can hire those who pass the test, but only if they ask what moron writes junky code like this. "Real programmers never comment -- if it was hard to write, it should be he:e, ane, anet
jcs@odyssey.UUCP (j.c.schwebel) (08/01/87)
I would much rather have an employee who could design, code, and test in a clean, logical, and understandable manner than one who could exactly count the number of asterisks on an obscure line of code. Let the machines do the counting.
dsill@NSWC-OAS.arpa (Dave Sill) (08/06/87)
>It's true that testing someone's ability to read (and write) such >monstrosities as Keller's test isn't testing for their ability to >read and write readable code. Agreed. It tests one's ability to read that test. >But it is a very good way to filter out >people who are (1) a bit dense, or (2) don't have a good grasp of C. I'm sure there are many people who are not dense and have a good grasp of C which would fail that test. Actually, Doug Gwyn was the only one to point out the fact that *--*++cpp was wrong, so he's the only one who's passed. >I've worked with people who were slow, and it's a real pain, and this >test would have surely eliminated them, as garlic does a vampire. It's more like chopping down every apple tree in an orchard with at least one bad apple to improve the crop. Garlic, unlike this test, affects all vampires, and only vampires. Can you really say no good programmers will fail this test and no bad programmers will pass? -Dave Sill dsill@nswc-oas.arpa The opinions expressed above are those of the author and do not necessarily reflect those of the Naval Surface Weapons Center.
Leisner.Henr@Xerox.COM (marty) (08/06/87)
Thinking about it, I think the test may have value. Not so much for coming up with the correct answer, but being able to demonstrate an approach to attack the problem. Something like part credit -- if you demonstrate sound reasoning and come up with the wrong answer it is better than having the right answer on a guess. Unfortunately, I think that test is the right or wrong variety. marty GV: leisner.henr NS: martin leisner:henr801c:xerox UUCP: martyl@rocksvax.uucp
oleg@quad1.quad.com (Oleg Kiselev) (08/06/87)
Well, it could have been worse.
On the other hand, if the job involves maintaining code written in this style
(we are talking MANY megabytes here), or rewriting and expanding it, you
BETTER be able not to get lost in the pointer stew. And be able to tell
that a pointer to "char **xxx[]" is a "char ***", and not "char ****".
Because that's the kind of error you will often find in code that was never
linted and constitutes the heart of the product you are supposed to make
(somehow!) work. Remember, there is a chance that the guy who worked on the
code before you was incompetent and got fired for it -- and you are being
hired (in part) to clean up the mess. (I should know -- part of our job here,
aside from developement and posting to the NET :->, is to fix bizzare
"artifacts" left in our products by the "earlier generations")
--
Oleg Kiselev -- oleg@quad1.quad.com -- {...!psivax|seismo!gould}!quad1!oleg
DISCLAIMER: All grammatical and spelling errors are inserted deliberately to
test the software I am developing. In fact, that is the only reason I am
posting. Yeah, that's the ticket! All my postings are just test data! Yeah!!chris@mimsy.UUCP (Chris Torek) (08/06/87)
In article <8634@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >I'm sure there are many people who are not dense and have a good grasp >of C which would fail that test. Actually, Doug Gwyn was the only >one to point out the fact that *--*++cpp was wrong, so he's the only >one who's passed. *--*++cpp was not wrong; Doug obviously just looked at it and said `you gotta be kidding'. The declaration `char ****cpp' *was* wrong, and a number of people caught this. As to the test itself, it really was not that hard. Any time you have a twisty patch of code, the way to find out what it does is to work it out yourself. Once you understand what it does, you can replace it with something more sensible. This *is* a useful skill, and it is conceivable that the test was aimed at finding those who have that skill. (But I doubt it :-) .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
cas@mtuxo.UUCP (C.STEVENS) (08/06/87)
In article <8644@brl-adm.ARPA>, Leisner.Henr@Xerox.COM (marty) writes:
# Thinking about it, I think the test may have value.
Unfortunately, I think a test like that will do a lot to turn-off good
candidates. I haven't seen anyone else say that, but I imagine that's
true. Like, if I took the test and passed, I'm not sure I'd want to work
for a company that gave it. And I assume anyone that could pass the test
would have lots of offers!
____________
The handsome guy in the wheelchair!
Cliff Stevens Jr.
rm. MT 1E228 ...!ihnp4!mtdcb!cas
AT&T -- End User Organization Laurel Ave. ...!inuxc!mtuxo!cas
Middletown NJ 07748gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/07/87)
In article <7881@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >*--*++cpp was not wrong; Doug obviously just looked at it and said >`you gotta be kidding'. No, actually I suspected it might be wrong and looked up the rules for lvalueness in the latest X3J11 draft. As a result of discussion with Chris, however, I now think that the X3J11 rules may not be what we intended, and I'll be bringing that up at the next meeting.
lmiller@venera.isi.edu (Larry Miller) (08/07/87)
In article <8644@brl-adm.ARPA> Leisner.Henr@Xerox.COM (marty) writes: >Thinking about it, I think the test may have value. > >Not so much for coming up with the correct answer, but being able to >demonstrate an approach to attack the problem. > Here's how I "solved" the test-- 1) Run through lint. That immediately found the ****cp vs ***cp problem. 2) Compiled the first version and looked at the output on running it. Weird. 3) Fixed the code based on the lint output, recompiled and ran. Output looked reasonable. Lesson--Run all code through lint.
jwp@larry.UUCP (Jeffrey W Percival) (08/07/87)
I was amused by the people who responded with "this code is not nice, therefore I won't look at it." All I can say is, I'm glad they're not medical doctors! -- ---- Jeff Percival (jwp@larry.sal.wisc.edu)
throopw@xyzzy.UUCP (Wayne A. Throop) (08/08/87)
) gwyn@brl-smoke.ARPA (Doug Gwyn )
) In article <7881@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
))*--*++cpp was not wrong; Doug obviously just looked at it and said
))`you gotta be kidding'.
)
) No, actually I suspected it might be wrong and looked up the rules
) for lvalueness in the latest X3J11 draft. As a result of discussion
) with Chris, however, I now think that the X3J11 rules may not be
) what we intended, and I'll be bringing that up at the next meeting.
I don't get it. What lvalue rules are violated by the above? The only
things that require an lvalue are ++ and --. The ++ is applied to cpp,
which is an lvalue on accounta it's a variable, and the -- is applied to
an indirection, which is an lvalue on accounta indirections always
return lvalues (which are sometimes not modifiable, granted, but in this
case the indirection yeilds a pointer type, which *is* modifiable).
So again: huh?
--
IBM manuals are written by little old ladies in Poughkeepsie who are
instructed to say nothing specific.
--- R. T. Lillington
--
Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopwgwyn@brl-smoke.ARPA (Doug Gwyn ) (08/08/87)
In article <183@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes: >I don't get it. What lvalue rules are violated by the above? What I originally thought might be wrong is that in the process of expanding the expression *--*++cpp at one point one is trying to evaluate --(cp+2) (or something like that), and it was not (and still is not) clear to me that (cp+2) qualifies as a modifiable lvalue. Perhaps one can deduce this from the rules but I sure didn't.
rblieva@cs.vu.nl (Roemer b Lievaart) (08/11/87)
In article <6253@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >What I originally thought might be wrong is that in the process of >expanding the expression *--*++cpp at one point one is trying to >evaluate --(cp+2) (or something like that), and it was not (and still >is not) clear to me that (cp+2) qualifies as a modifiable lvalue. No, you are not evaluating --(cp+2). Why not? Well: { int a ; a = 2 ; ++a ; .... is completely correct, isn't it? But "you"'re not evaluating ++2 or something, but ++a. ++a means a = a + 1 , not 2 = 2 + 1. So the same goes for: if *x == y ++*x does not mean ++y. That's all there is to it. Roemer. "Never thought it would go so fast: BASIC and Pascal already belong to the dead languages" ( v. Kooten & de Bie )
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/12/87)
In article <860@tjalk.cs.vu.nl> rblieva@cs.vu.nl (Roemer B. Lievaart) writes: >In article <6253@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: ... To forestall further traffic on this, I should report that I started out mildly boggled by *--*cp in the example code, and when I looked it up in the latest X3J11 working draft I become hopelessly confused. It seems that section 3.2.2.1 and 3.3.0.1 got tangled together somehow in the editing process, so the lvalue rules appear (to me, anyway) to not be what I thought they were intended to be. Confusing the value of an expression with the ruels for determining lvalueness is my own fault, though. In summary, I think that the only actual bug in the original code was the **** => *** one that numerous people caught, and that the current X3J11 draft standard may have a typo that needs to be corrected in section 3.2.2.1,
DHowell.ElSegundo@Xerox.COM (08/13/87)
In some previous article, someone wrote: ... >char *c[] = { "ENTER", "NEW", "POINT", "FIRST" }; >char **cp[] = { c+3, c+2, c+1, c }; >char ***cpp = cp; [extra asterisk deleted] ... > printf("%s ", *--*++cpp+3); In article <6253@brl-smoke.ARPA> Doug Gwyn <gwyn@brl-smoke.arpa> writes: >In article <183@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes: >>I don't get it. What lvalue rules are violated by the above? >What I originally thought might be wrong is that in the process of >expanding the expression *--*++cpp at one point one is trying to >evaluate --(cp+2) (or something like that), and it was not (and still >is not) clear to me that (cp+2) qualifies as a modifiable lvalue. >Perhaps one can deduce this from the rules but I sure didn't. The expression would be grouped as (*(--(*(++cpp))))+3, so the operand to -- is (*(++cpp)). Before the expression, (due to a previous ++cpp) the value of cpp was &cp[1]. ++cpp changes this to &cp[2]. *++cpp is thus *&cp[2], which is cp[2], which is as far as I know an acceptable lvalue. So the obfuscated expression is not illegal. But I wouldn't mind if legislation were passed making it so. :-) Dan <DHowell.ElSegundo@Xerox.COM> DISCLAIMER: "My opinions are not Xerox copies!"
peter@sugar.UUCP (Peter da Silva) (08/13/87)
In article <6253@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <183@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes: > >I don't get it. What lvalue rules are violated by the above? > > expanding the expression *--*++cpp at one point one is trying to > evaluate --(cp+2) (or something like that), and it was not (and still *--*++cpp should be evaluated as: Increment cpp. Decrement *cpp. Value is **cpp. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
djones@megatest.UUCP (Dave Jones) (08/20/87)
Recollections of things past follow. Hit 'n' if you are not up to hearing a shaggy dog story. The discussion about the weird C code as a test for employment reminds me of an experience I had in 1979. I had just graduated with an M.S. in math after having returned to college as an adult. The University of Houston had bent the rules for me, and let me into grad school when I was junior, so I was looking for my first job as a college graduate at age 32. I applied for a job with a subsidiary of a large steel company. I don't want to name the company, but its initials are "U.S.". They interviewed me all day one day, and had me return the next day to take a test. They put me into a small windowless conference room, with pencil and test forms. The object of the test was to trace the control-flow of English-pseudo-code nonsense "spaghetti" programs. I was struggling with this, when I noticed that each test form was two sheets, fastened at both top and bottom. Strange. So I peaked between. The inside of the bottom sheet functioned like carbon- paper. The inside of the top sheet had light blue traces on it. That's how the test was to be graded! The grader would determine whether the carbon traces coincided with the light blue traces. Suddenly the test seemed much easier. I struggled briefly with the ethical issues. Well, "Look here", I said to myself, "I am applying for an ENGINEERING job, where results are the only criteria of success, right?" "Or maybe the REAL test is to discover whether or not I am clever enough to figure out the grading scheme." This line of rationalization, and my growling stomach, settled the matter. So, I answered the test perfectly, and handed it in. A while later, my interviewer came back with a very pained look on his face. He said that I had done better on the test than anyone else ever had. (He did not bother to mention that I had scored 100%.) It seemed rather strange to me that no one else had discovered the key. But, he explained, they could not hire me anyway, because they could not hire someone who was 32 years old and had never had a "real" job. They had brought me in to take the test, apparently, just so they could have some reason, other than age, for giving me the bum's rush. The story has a happy ending. I got a much better job at Texas Instruments, and both T.I. and I were quite happy with my employment until I left for a teaching position four years later. But since then, I don't take written tests on job interviews.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/21/87)
In article <1577@megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >Recollections of things past follow... You reminded me of an SF story called "Placement Test", I think by Keith Laumer in Analog. Does anyone know the exact reference? (Might as well mail to me personally rather than the newsgroup.) - Gwyn@BRL.MIL