We developer types have a couple of pre-set modes or notions about code life-cycles.

If you come from the "dynamic" language school, the cycle looks something like:
  1. Sometimes use a REPL. Type lines of code into something and get answers.  You know, irb.
  2. Change the code and re-run it/reload the web page.  Does it work?  Cycle back to 1.  Cycle time: 30 seconds.
  3. Run some tests.  Okay, they pass.  Or maybe you ignore this phase.
  4. Commit the code to a repository.
  5. Maybe a Continuous Integration system does its thing.
  6. Publish the code to your user-base.
If you come from C/C++/Java-land, life looks something like:
  1. Edit a bunch of files.
  2. Compile the code.
  3. Maybe run automated tests, maybe do some manual exploration of the code giving you the right answer. Cycle back to 1 a bunch of times.  Cycle time: 5 to 60 minutes.  Yuck.
  4. Commit the code to a repository
  5. Maybe do some Continuous Integration
  6. Publish the code to your user-base.
If you come from Scala, Haskell, OCaml, life might look like:
  1. Mess around in the REPL or running code like scripts.  Cycle time 30-90 seconds.
  2. Build the code to be a module or a package or a JAR.
  3. Compile the module, package, or JAR, including running some tests.
  4. Integrate module, package, or JAR into larger application and see how well the app runs both with automated tests and with hand-use.  Cycle back to 1.  Cycle time, 1-5 hours.  Note that lots of work gets done at 1, so the cycle time is somewhat deceptive vs. other environments.
  5. Commit code to repository.
  6. Publish the code to your user-base.
If you come from an Excel background, like might look like:
  1. Take a spreadsheet template that someone else built.
  2. Put in some data.
  3. Tweak some formulas. Cycle back to 2.  Cycle time, 10 seconds.
  4. Get done for the day and save the spreadsheet, hopefully not over-writing the prior version.
  5. Email the spreadsheet to co-workers.  Who will cycle back to #1.

Depending on the descriptiveness of the type system, the act of compiling is also the act of running some tests.  Depending on the purity of the language/limit of side effects, more or fewer tests will be required.  Depending on the Cyclomatic Complexity that the language syntactically and semantically encourages, the number of tests will be more or fewer.

And then there are the cultural norms.  One of the greatest contributions that Java made to good coding is the inclusion of JavaDoc as a core part of the Java platform.  JavaDocs were simple to write, simple to use, and the early cultural norms of Java coders included writing at least some minimal JavaDocs with the code.  It helped a lot that Java arrived along with HTML so that there was a common, low cost way to publish the docs.  But, none-the-less, JavaDocs made a hugely positive difference in terms of teams being able to document code.

In thinking about Visi, I want to capture the quick cycle times of Excel, yet support Visi code in source repositories (structured, versioned sharing), good habits (writing tests and documentation), and safe publishing habits.

I am currently debating making tests and documentation of public parts of Visi programs mandatory by default (although could be over-ridden by a flag).  This means that before you can share a Visi program (commit it to a repository), you must write documentation and tests.  The docs would be much like JavaDocs and the tests would be co-resident with the functions being tests... kind of design by contract style.  Although, given that Visi is a pure, statically typed, lazy language, a HaskellCheck style of tests will likely be the correct semantics rather than the Eiffel contracts that measure input and output values.

So, what do you think?  Should Visi require tests and documentation by default?  How can we create the right atmosphere and cultural norms around Visi that make it super simple and super easy to start, super simple, super easy to cycle on models/programs, and also make sure there are the right norms so we wind up with a solid test mentality like the Ruby/Rails culture and a solid documentation mentality like the Java culture?