Program lifecycle phases

[David Pollak]

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?

[Kevin Dangoor]

On Thu, Jan 5, 2012 at 8:15 PM, David Pollak <feeder.of...@gmail.com> wrote:

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?

I don't personally like requiring such things. It gets in the way of experimentation. You're not always writing production code. Sometimes, you're building "one to throw away". But, I do think that providing standard tools and "one obvious way to do things" will go a long way toward building the culture you're looking for.

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Tyler Weir]

> It gets in the way of experimentation.

I think that summarizes my opinion.  *Requiring* tests makes it harder to jump in and mock something up quickly.

[Diego Medina]

>
> 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?
>

I wonder if there is a way to make writing tests as natural and simple
as writing a few println() while you code. Maybe providing some kind
of code generation, where you write the test, and then Visi creates
your skeleton code that satisfies your test.
If this isn't possible, then I would be worry about forcing people to
have tests and docs unless they specify a flag. I think that a better
way would be to have a flag to "force" the tests, like a "strict" mode
or something.
And at the same time, try to write many of the how to, docs, etc. of
Visi itself to include how to write tests, and docs, So people will
find it easy to just "copy" your way.

As for Documentation, I like how specs2 creates html files based on
the tests you write, maybe Visi can have something similar.

(Sorry if this sounds like mumble, but I should really be sleeping
right now :) )

Regards,

Diego

--
Diego Medina
Web Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Łukasz Kuczera]

Yup requiring is not good, it should be easy to do as Java did with JavaDocs, same like with Scala you can write functional if you want to, but you can do Jala (Java in Scala) if you want to both are easy to do while the former is hard in Java. 

--
Łukasz Kuczera

http://acidbits.org/blog

[Patrick Logan]

"Required" documentation often ends up with short, non-sensical
statements like "Put some documentation here". But the easier it is to
write good documentation, and the more documentation later developers
already see in the earlier code, the better.

As for tests, from what I know of this system so far, I am thinking a
"quick check" like property-based test capability would be useful.
Mandating (good) tests may be as difficult as mandating good
documentation. But maybe some kind of built-in, obvious (if not "in
your face") reporting of the current level of testing (whether its
coverage or something else) might be useful.

-Patrick

[Patrick Logan]

Also the more developers can see tests + code "together" without
having to shift any gears, the better.

[Patrick Down]

I was recently impressed with a demo of the Larch environment, a programming environment for python.  One of the interesting things about it is that is sort of a python REPL but the code, input and output are captured in a document.  You can edit code and inputs and rerun to see outputs in the document.  Working in a REPL is sort of informal testing and with the Larch that testing can be captured and cycled on just like the code.  This seem like a very low impact way of doing tests.  

Drawing a page from their book for Visi might not be a bad idea.

 

[David Pollak]

On Thu, Jan 5, 2012 at 6:45 PM, Kevin Dangoor <k...@blazingthings.com> wrote:

On Thu, Jan 5, 2012 at 8:15 PM, David Pollak <feeder.of...@gmail.com> wrote:

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?

I don't personally like requiring such things. It gets in the way of experimentation. You're not always writing production code. Sometimes, you're building "one to throw away". But, I do think that providing standard tools and "one obvious way to do things" will go a long way toward building the culture you're looking for.

Cool. This seems to be a good path. Kinda like the Java/JavaDocs path but adding tests in.

 

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[David Pollak]

On Thu, Jan 5, 2012 at 11:29 PM, Diego Medina <di...@fmpwizard.com> wrote:

>
> 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?
>

I wonder if there is a way to make writing tests as natural and simple
as writing a few println() while you code. Maybe providing some kind
of code generation, where you write the test, and then Visi creates
your skeleton code that satisfies your test.

That might be very, very difficult. ;-)

 

If this isn't possible, then I would be worry about forcing people to
have tests and docs unless they specify a flag. I think that a better
way would be to have a flag to "force" the tests, like a "strict" mode
or something.
And at the same time, try to write many of the how to, docs, etc. of
Visi itself to include how to write tests, and docs, So people will
find it easy to just "copy" your way.

Yeah... I think the "simple path" to writing docs and tests is probably best.

 

As for Documentation, I like how specs2 creates html files based on
the tests you write, maybe Visi can have something similar.

(Sorry if this sounds like mumble, but I should really be sleeping
right now :) )

Regards,

 Diego



--
Diego Medina
Web Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[David Pollak]

On Sat, Jan 7, 2012 at 6:01 PM, Patrick Down <patric...@gmail.com> wrote:

I was recently impressed with a demo of the Larch environment, a programming environment for python. 

Very sweet.  I like Larch's visuals.  Thanks for the pointer.

And thank you guys all for your thoughts and insights!

 

One of the interesting things about it is that is sort of a python REPL but the code, input and output are captured in a document.  You can edit code and inputs and rerun to see outputs in the document.  Working in a REPL is sort of informal testing and with the Larch that testing can be captured and cycled on just like the code.  This seem like a very low impact way of doing tests.  

Drawing a page from their book for Visi might not be a bad idea.