RE: Offtopic: How to Design Programming Tests

[Brent Fulgham <brent.fulgham@xpsystems.com>]

> Brent, this one wasn't familiar:
> 
> > Describe how you might implement "Parasitic" methods
> > in Java using a mechanism which compiles to valid Java
> > bytecode capable of running on a compliant JVM.  
> > Cite references.
> 

Noel (et. al.):

This is a bad joke based on some researching I was doing on
an unrelated topic.  I'm probably going to mess up the
description, but it's basically a modification to the Java
compiler to help implement multiple dispatch.  It was presented
at OOPSLA'97 by John Boyland and Giuseppe Castagna, and can
be downloaded for free from (http://www.dmi.ens.fr/~castagna/pub.html)
(Rather than the absurdly expensive ACM "Digital Library").
"Parasitic Methods:  An Implementation of Multi-Methods for Java".

Some obvious answers for a language that better supports this
would be (obviously) Lisp/Dylan/Scheme, Smalltalk.

I would expect the run-time penalty of this system under Java
would be fairly significant. 

> Does this refer to mix-ins?  I thought another good
> test would be to write Java bytecode that the verifier
> cannot verify and correct or incorrect (i.e. the
> Goedel statement for Java bytecode), but it then
> occurred to me that verification probably relies on
> Java's type system and Java's wimpy type system is
> decidable.
>

I think mix-ins and parasitic methods solve the same problem
in a slightly different manner.  Based on the couple of papers
I read (most by some combination of Krishnamurthi/Flatt/Felleisen)
I think mixins are a mechanism for adding new functionality to
existing classes via small bits of logic.  In contrast, so-called
"Parasitic Methods" seek to modify the way in which the run-time
system handles method dispatch and "hijack" certain calls so
a better "match" can be found for a method call using multiple
polymorphic objects.
 
> Brent, I completely agree that programmer tests are
> bogus.  The reason we now have them is that quality of
> applicants is amazing low, and the quantity amazingly
> high (it's a symptom of the profession, and
> particularly contracting).  The test is quick way to
> separate the wheat from the chaff.

Yes -- you are probably right.  But it comes down to the old
question:  "How many pairs of animals did Moses take on the
Ark?"  Sitting in your study you would probably say "Huh?
Wasn't Noah the one with the Ark?", but in a stressful
environment you might spend time trying to solve the "hard"
problem of assessing how many animals might fit, etc.
Is that a fair test?  Depends on the ultimate goal of your
organization -- to solve puzzles under artificial conditions,
or to solve real-world problems in a meaningful way.  That's
why I think discussions that involve exploring the process
a candidate uses to arrive at a solution to be generally
more helpful.

> Asking them to send in their own programs is a good idea,
> but I can see two problems with it:
> 
> 1.  They might copy from a book/open-source code (this
> has happened when we let someone do a test at home -
> but they forgot to change a reference to page number
> in the original text so it gave them away!)
> 

Egad!  Well, that's result must have been very helpful
in assessing their suitability for the job!  ;-)

> 2.  They might do all their coding at work, and hence
> not have any code they can show us.
>

Well, I guess that's true.  I can't expect everyone to
enjoy software engineering enough to do it all day, then go
home and do it some more (like some of us do).
 
> Michael Bogomolny suggested:
> 
> > compare the advantages and disadvantages of arrays
> versus linked lists.
> 
> This is a good question.  My answer would be:
> 
> - random access time O(1) vs O(n)
> - queue/stack operations O(n) vs O(1)
> - memory usage: array better
> 
> Anything I missed?
>

Just the obvious speed issue.  Ideas that should probably
occur to the candidate:

1.  Dynamic growth of the linked list is probably better
performance-wise.
2.  Large data sets will probably work better with linked
lists (e.g., I just did something similar for an account
transaction history, where I needed to "window" the
history available in core memory from the overall history
due to memory and performance issues.) 
 
> In Java the only way to do this is to have a thread
> for each connection.  Under load the machine dies
> with too many threads open.  In C (at least in
> AOLserver :-) all the inactive connections are given
> to a single thread that periodically polls them for
> activity, and requeues any connections that have become
> active.

Sounds like a good opportunity to do a native method
to handle this particular activity.  Are you using
AOLserver for your platform? (Don't tell me you work
for aD!)

> Because they didn't write the JVM in Scheme, so the
> JVM can have memory leaks/resource allocation problems
> as well?
>

Bzzt!  They didn't get Matthew Flatt to write the JVM, so
there are lots of memory leaks/resource problems ;-)
 
-Brent