Subject: Re: CL & CORBA
From: Erik Naggum <clerik@naggum.no>
Date: 1998/09/06
Newsgroups: comp.lang.lisp
Message-ID: <3114076313142399@naggum.no>

* Bjoern-Falko Andreas <andreas@ki.informatik.uni-ulm.de>
| We all _KNOW_ the horror of browsing through code we haven't written
| ourselves.  ...  And I guess, everybody will agree that scarcly
| documented LISP code isn't very easy to understand.

  (I have started to respond to this several times, never finishing because
  it seems like such an obviously counter-productive attitude, and the
  arguments against it so obvious, but let's give it a shot.)

  first, I have been working with other people's code as a firefighting
  consultant for the past 15 years.  projects have failed or are close to
  failing or are unmaintainable when I get called in.  still, I'd rate only
  10% of the code I have not only "browsed", but thoroughly analyzed, as "a
  horror".  let me give you an example of horrible string comparison in C.
  yes, this is _actual_ code from a past project.  comments are redundant.

    if (( Buffer[ 0] | 0x20) == 'f' &&
	( Buffer[ 1] | 0x20) == 'l' &&
	( Buffer[ 1] | 0x20) == 'o' &&
	( Buffer[ 2] | 0x20) == 'w') {
      Flow = 1;
      Buffer+=4;
    }

  while not very accurate numbers, I could rate 20% as "uncomfortable", 30%
  as "comfortable", and 40% as "a breeze".  of the _free_ source I have
  looked at, _nothing_ has come close to the shitware produced by huge
  outfits like Anderson Insulting.  programmers who actually have to
  maintain their own code also make a huge effort to keep it maintainable,
  compared to the drones who code for the big consulting firms -- they know
  they will _never_ see their own code again, and only the low-lives (fresh
  out of school) will maintain such code, thus learning only bad habits
  from "real" code they are exposed to, and probably learning to hate other
  people's code in general, too.  (this is why I want good source code to
  be available for everybody to learn from and the author to be proud of.)

  second, the ability to read and understand code in a language well enough
  to acquire an intuition that works is _essential_.  that is, when you
  think _in_ the language, as opposed to think in some other language and
  then translating into the programming language, it doesn't really matter
  how ugly the code is, you still see _what_ it does, even if it takes a
  little more effort to read than well-written code.

  third, it's the _why_ that needs documenting, and if the general plan is
  well enough explained, comments most often just get in the way.  Lisp has
  documentation as part of the language, and they should be used to convey
  proper documentation of the interface and intended use.  that's all you
  should need if the implementation is solid, and if it isn't, you either
  fix it so it is or drop it entirely.  in any case, the contract with your
  callers is what matters.  if it is spelled out and fully obeyed, the code
  can look like shit or be exploiting undefined or implementation dependent
  features or system internals all it wants.

  fourth, I have never found a language easier to understand than Common
  Lisp, documented, undocumented, commented, uncommented, whatever.  while
  there are a lot of ways to do most things in Common Lisp, I have yet to
  stumble on a disingenious exploitation of cryptic side effects, such as
  are frequently the _rule_ in the Unix languages.

  so, in summary, I _KNOW_ what working with other people's code means and
  what effort and concentration it takes, yet I don't recognize the pain
  and suffering that some people impute to _all_ code they have not written
  themselves (which kind of tells me _they_ write really bad code).
  however, I must admit to having stopped using the phrase "the worst code
  I have ever seen" after I had spent a few months with 25,000 lines of
  mind-boggling stupidity in the project I showed a small piece of above.
  
#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.