Malware "best practices"

[Bill Sconce]

On Thu, 27 Jul 2006 19:11:39 -0400
Jason Stephenson <jason at sigio.com> wrote:

> As a programmer, I can tell you why. Most programmers are not
> well versed in the art or the science (if there really is any)
> of programming.


In a beautiful paper, "Hackers and Painters" [1] Paul Graham [2] says:
    ...
    I've never liked the term "computer science." The main reason
    I don't like it is that there's no such thing. 
    
    Computer science is a grab bag of tenuously related areas thrown 
    together by an accident of history, like Yugoslavia. At one end you 
    have people who are really mathematicians, but call what they're
    doing computer science so they can get DARPA grants. ... It's as if
    mathematicians, physicists, and architects all had to be in the 
    same department.
    ...
    But for the hackers this label is a problem. If what they're doing
    is called science, it makes them feel they ought to be acting 
    scientific. So instead of doing what they really want to do, which
    is to design beautiful software, hackers in universities and 
    research labs feel they ought to be writing research papers.

    In the best case, the papers are just a formality. Hackers write
    cool software, and then write a paper about it, and the paper becomes
    a proxy for the achievement represented by the software. But often
    this mismatch causes problems. It's easy to drift away from building
    beautiful things toward building ugly things that make more suitable
    subjects for research papers.

    Unfortunately, beautiful things don't always make the best subjects
    for papers. Number one, research must be original-- and as anyone who
    has written a PhD dissertation knows, the way to be sure that you're
    exploring virgin territory is to to stake out a piece of ground that
    no one wants. Number two, research must be substantial-- and awkward
    systems yield meatier papers, because you can write about the obstacles
    you have to overcome in order to get things done. Nothing yields meaty
    problems like starting with the wrong assumptions. Most of AI is an
    example of this rule ...
    
-Bill

[1] At
    http://www.paulgraham.com/hp.html
    
[2] My thanks to Ted Roche for introducing me to Paul Graham's writing.