Time to get busy!

Luca Pisati pisati@nichimen.com
4 May 97 18:00:54 -0700


  >   OK everyone, enough talk It's time to get busy! :-) Why don't people
  > start picking projects that they're interested in?

I'm currently managing a project of rewriting and standardizing
and providing clear API and structure to a fully Lisp/Clos\
application (for computer graphics).  Our environment is pretty
big (50 to 70 Mbytes of Lisp Image on Irix and NT), and tries to
be as much independent from Hardware and OS and even Lisp
vendor.  I'm already facing a lot of the problems that you are
talking about, and I agree that a minimum of self standardization
can help to go half the way on.

  Question:  what sort of time frame are we looking at for developing
  any given module?  Also won't there be a precise set of criteria
  for any given module?  I mean wouldn't there need to be a list of
  requirements for things like API, desired performance, functionality,
  etc...?  Just asking for say "a networking system", seems to be asking
  for trouble since there seems to be a wide range of interpretation
  as to what should and shouldn't be in a given networking system.
  
If  we want to start discussing about these issues, probably we 
should start to have separate threads (even mailing list), so
that people who have experience of designing and maintaining
large applications through long periods of time, start propose
about some standards.  In general I believe that not that many
things are necessary if at least some "clean" set up is well
organized in order to maintain separation between modules and
the APIs. Just a correct and smart usage of the package system
can provide a lot of protection against possible collisions.

  Also what about coding standards?  I'm interested in contributing
  code in Lisp, but I'd like to know for instance, what sort of
  naming conventions should be employed, how should reliance
  on non-ANSI features go, is one free to use functional programming
  techniques (the latter would necessitate tail recursion optmization
  in CMUCL which is what I'm assuming is going to be used for the
  Lisp code at this point).  CMUCL/Linux is our implementation
  right?  I need to know before I go about installing this thing
  and getting familiar with its nuances.
  
  It seems every time I open my mouth on this mailing list its to
  shed doubt or play "prophet of doom".  Sorry, but I guess I got
  thrown off.  One minute everyone is discussing everything, the
  next minute there's a call to arms, scarcely after a request
  for a manifesto came in!  
  
I'd rather let the discussions about goals go on and generate
ideas, while somebody could start from ANSI-CL and debate
about some standards, so that, when ideas are more mature,
and development can start, at least the frame of devlopment
could be already set.

  My software engineering experience is non-existent (I code therefore
  I am), but shouldn't there be more formalism involved than just
  saying "We need a persistent OO store, Make It So!"?

  [Snip]
  
  >   Mike McDonald
  >   mikemac@engr.sgi.com
  > 
  
  Again don't get me wrong, I'm happy to see that there's at least
  some incentive to start doing things now, I just don't want problems
  to arise due to lack of detail.
  
  BTW, do you want those who contribute code to have experience in
  the particular domain in which they are developing?  I have
  zero experience in some of the areas I'm thinking of taking up,
  but I'm more than willing to do the research necessary to teach
  myself what to do if that's not a problem (heck I'm looking forward
  to it since that makes it more of a challenge and will help
  expand my knowledge greatly -- this could be one helluva learning
  experience for me!).
  
  Thanks and sorry for the somewhat ... depressing tone.  
  
  
  -- 
  Cya,
  Ahmed