librelist archives

« back to archive

Some ideas about future exercise types

Some ideas about future exercise types

From:
Date:
2013-11-02 @ 10:50
Hi all,

Here are a few more wacky ideas about how exercism could work in the future.

Currently all exercises are of the form "here's a testsuite, write a
program to make the testsuite run". I see advantages in having both more
structured and more unstructured exercises.

First the more structured ones. I call these "green" exercises. In a green
exercise you get both a test suite and part of the program with important
bits missing. Your job is to fill in the missing parts. A good way to get
a green exercise is to take a normal (I call these "blue") exercise and
remove the function bodies. So you end up with just structure of the code,
the user has to fill in the function bodies. The idea of green exercises
is that they contain lots of comments about the pre- and post-conditions
of functions and about how a function should be filled in.

Here's an example (Elixir, adapted from example):

"""
defmodule Teenager do
  @doc """
  Answers to `hey` like a teenager.

  ## Examples

  iex> Teenager.hey("")
  "Fine. Be that way!"

  iex> Teenager.hey("Do you like math?")
  "Sure."

  iex> Teenager.hey("HELLO!")
  "Woah, chill out!"

  iex> Teenager.hey("Coding is cool.")
  "Whatever."
  """
  def hey(input) do
    # TODO
  end

  Hi all,

Here are a few more wacky ideas about how exercism could work in the future.

Currently all exercises are of the form "here's a testsuite, write a
program to make the testsuite run". I see advantages in having both more
structured and more unstructured exercises.

First the more structured ones. I call these "green" exercises. In a green
exercise you get both a test suite and part of the program with important
bits missing. Your job is to fill in the missing parts. A good way to get
a green exercise is to take a normal (I call these "blue") exercise and
remove the function bodies. So you end up with just structure of the code,
the user has to fill in the function bodies. The idea of green exercises
is that they contain lots of comments about the pre- and post-conditions
of functions and about how a function should be filled in.

Here's an example (Elixir, adapted from example):

"""
defmodule Teenager do
  @doc """
  Answers to `hey` like a teenager.

  ## Examples

  iex> Teenager.hey("")
  "Fine. Be that way!"

  iex> Teenager.hey("Do you like math?")
  "Sure."

  iex> Teenager.hey("HELLO!")
  "Woah, chill out!"

  iex> Teenager.hey("Coding is cool.")
  "Whatever."
  """
  def hey(input) do
    # TODO
  end

  # Returns true if and only if `true` contains no
  # text or only whitespace.
  #
  # Please do not use a regular expression here.
  defp silent?(input) do
    # TODO
  end
  ...
end

Green exercises do a lot of handholding and are intended to guide a user
into a certain solution in order to teach good style.

Red exercises are the opposite approach, as little hand holding as
possible and harder problems. The idea of red exercises is that where in a
blue (normal) exercise you get the test suite in a red exercise you don't
even get that. In a red exercise you get a description of a problem and
have to write both the program and the test suite. You're also expected to
properly document the program.

The idea of a red exercise is that a good programmer has to be able to
write good tests and that means thinking about where the program could
fail, what the corner cases are, what the design requirement _doesn't_ say
but is expected anyway. In a red exercise users are also required to
document their code, API documentation is very important for
maintainability in the real world.

Green exercises are very scholary, focused on teaching while red exercises
are focused on demonstrating the ability to write quality code. Blue
exercises are somewhere in the middle.

In terms of complexity and time investment red exercises are much "worse"
than green or blue exercises. Red exercises are intended to be challenges.

I imagine users would be encouraged to try the blue exercises first and if
they feel they need to learn more do some green exercises and if they feel
blue exercises are way too easy do some red exercises.

This post has gotten long already so I'll shut up now. ;)

Greetings,

Peter

Re: [exercism] Some ideas about future exercise types

From:
Katrina Owen
Date:
2013-11-02 @ 15:45
On 11/02, peter@pminten.nl wrote:
> Green exercises are very scholary, focused on teaching while red exercises
> are focused on demonstrating the ability to write quality code. Blue
> exercises are somewhere in the middle.

I really like this idea.

I'm seeing three basic use-cases for exercism:

1. Beginners who have very little or no programming experience are using
it to learn to program. They're finding the normal exercises a bit too
challenging in some cases, and could use more hand-holding.

2. Experienced programmers who want to get better at the language that
they write day-to-day.

3. Experienced programmers who want to play with a new language and
learn its idioms.

So I would see (1) as starting with green exercises and slowly moving to
blue exercises. (2) would start with blue exercises and slowly move to
red exercises, and (3) *might* start with blue just to get a taste of
how the nitpicking and everything works, but would probably be happier
in the red exercises.

Katrina

Re: [exercism] Some ideas about future exercise types

From:
Peter Minten
Date:
2013-11-02 @ 16:07
On 11/02/2013 04:45 PM, Katrina Owen wrote:
> On 11/02, peter@pminten.nl wrote:
>> Green exercises are very scholary, focused on teaching while red exercises
>> are focused on demonstrating the ability to write quality code. Blue
>> exercises are somewhere in the middle.
> 
> I really like this idea.
> 
> I'm seeing three basic use-cases for exercism:
> 
> 1. Beginners who have very little or no programming experience are using
> it to learn to program. They're finding the normal exercises a bit too
> challenging in some cases, and could use more hand-holding.
> 
> 2. Experienced programmers who want to get better at the language that
> they write day-to-day.
> 
> 3. Experienced programmers who want to play with a new language and
> learn its idioms.
> 
> So I would see (1) as starting with green exercises and slowly moving to
> blue exercises. (2) would start with blue exercises and slowly move to
> red exercises, and (3) *might* start with blue just to get a taste of
> how the nitpicking and everything works, but would probably be happier
> in the red exercises.

I could imagine the system would force everyone to do a few blue
exercises (bob, word-count) before opening the green and red options.
That way people get a good idea of whether they consider blue to be
hard, easy or just right. It also introduces them to the nitpick system
and because everyone has done those exercises the nitpicks come pretty
quickly, which is important for motivation.

Re: [exercism] Some ideas about future exercise types

From:
Date:
2013-11-03 @ 01:53
Cool idea.  Have you seen the Ruby Koans?  I think those would be green 
exercises in this vernacular, up until the very last one where you write a
dice game without any prompting (just tests).

~Barrett

On Nov 2, 2013, at 11:07 AM, Peter Minten <peter@pminten.nl> wrote:

> On 11/02/2013 04:45 PM, Katrina Owen wrote:
>> On 11/02, peter@pminten.nl wrote:
>>> Green exercises are very scholary, focused on teaching while red exercises
>>> are focused on demonstrating the ability to write quality code. Blue
>>> exercises are somewhere in the middle.
>> 
>> I really like this idea.
>> 
>> I'm seeing three basic use-cases for exercism:
>> 
>> 1. Beginners who have very little or no programming experience are using
>> it to learn to program. They're finding the normal exercises a bit too
>> challenging in some cases, and could use more hand-holding.
>> 
>> 2. Experienced programmers who want to get better at the language that
>> they write day-to-day.
>> 
>> 3. Experienced programmers who want to play with a new language and
>> learn its idioms.
>> 
>> So I would see (1) as starting with green exercises and slowly moving to
>> blue exercises. (2) would start with blue exercises and slowly move to
>> red exercises, and (3) *might* start with blue just to get a taste of
>> how the nitpicking and everything works, but would probably be happier
>> in the red exercises.
> 
> I could imagine the system would force everyone to do a few blue
> exercises (bob, word-count) before opening the green and red options.
> That way people get a good idea of whether they consider blue to be
> hard, easy or just right. It also introduces them to the nitpick system
> and because everyone has done those exercises the nitpicks come pretty
> quickly, which is important for motivation.

Re: [exercism] Some ideas about future exercise types

From:
Michael Campagnaro
Date:
2013-11-03 @ 15:26
I like this as well.

I'm thinking it might be helpful if the challenges are provided in all (or
just two) of the colours. For example a beginner might be interested in the
description of a tough problem but wouldn't be ready to take it on. So they
start with its green version to get an understanding of how it works. Over
time they can move up to coding it from scratch. Working through the
problem multiple times can reinforce the concepts, like that of a koan.

Maybe the green and blue versions can be created from the "best" red
submissions, as decided by community voting. And this multi-tier approach
can start with the existing challenges since there is a ton of available
submissions already.

Michael
On 2013-11-02 9:54 PM, <barrett.clark@mac.com> wrote:

> Cool idea.  Have you seen the Ruby Koans?  I think those would be green
> exercises in this vernacular, up until the very last one where you write a
> dice game without any prompting (just tests).
>
> ~Barrett
>
> On Nov 2, 2013, at 11:07 AM, Peter Minten <peter@pminten.nl> wrote:
>
> > On 11/02/2013 04:45 PM, Katrina Owen wrote:
> >> On 11/02, peter@pminten.nl wrote:
> >>> Green exercises are very scholary, focused on teaching while red
> exercises
> >>> are focused on demonstrating the ability to write quality code. Blue
> >>> exercises are somewhere in the middle.
> >>
> >> I really like this idea.
> >>
> >> I'm seeing three basic use-cases for exercism:
> >>
> >> 1. Beginners who have very little or no programming experience are using
> >> it to learn to program. They're finding the normal exercises a bit too
> >> challenging in some cases, and could use more hand-holding.
> >>
> >> 2. Experienced programmers who want to get better at the language that
> >> they write day-to-day.
> >>
> >> 3. Experienced programmers who want to play with a new language and
> >> learn its idioms.
> >>
> >> So I would see (1) as starting with green exercises and slowly moving to
> >> blue exercises. (2) would start with blue exercises and slowly move to
> >> red exercises, and (3) *might* start with blue just to get a taste of
> >> how the nitpicking and everything works, but would probably be happier
> >> in the red exercises.
> >
> > I could imagine the system would force everyone to do a few blue
> > exercises (bob, word-count) before opening the green and red options.
> > That way people get a good idea of whether they consider blue to be
> > hard, easy or just right. It also introduces them to the nitpick system
> > and because everyone has done those exercises the nitpicks come pretty
> > quickly, which is important for motivation.
>
>

Re: [exercism] Some ideas about future exercise types

From:
Henrik Nyh
Date:
2013-11-02 @ 11:04
I like it. 

Sent from my iPhone

> On 02 Nov 2013, at 11:50, peter@pminten.nl wrote:
> 
> Hi all,
> 
> Here are a few more wacky ideas about how exercism could work in the future.
> 
> Currently all exercises are of the form "here's a testsuite, write a
> program to make the testsuite run". I see advantages in having both more
> structured and more unstructured exercises.
> 
> First the more structured ones. I call these "green" exercises. In a green
> exercise you get both a test suite and part of the program with important
> bits missing. Your job is to fill in the missing parts. A good way to get
> a green exercise is to take a normal (I call these "blue") exercise and
> remove the function bodies. So you end up with just structure of the code,
> the user has to fill in the function bodies. The idea of green exercises
> is that they contain lots of comments about the pre- and post-conditions
> of functions and about how a function should be filled in.
> 
> Here's an example (Elixir, adapted from example):
> 
> """
> defmodule Teenager do
>  @doc """
>  Answers to `hey` like a teenager.
> 
>  ## Examples
> 
>  iex> Teenager.hey("")
>  "Fine. Be that way!"
> 
>  iex> Teenager.hey("Do you like math?")
>  "Sure."
> 
>  iex> Teenager.hey("HELLO!")
>  "Woah, chill out!"
> 
>  iex> Teenager.hey("Coding is cool.")
>  "Whatever."
>  """
>  def hey(input) do
>    # TODO
>  end
> 
>  Hi all,
> 
> Here are a few more wacky ideas about how exercism could work in the future.
> 
> Currently all exercises are of the form "here's a testsuite, write a
> program to make the testsuite run". I see advantages in having both more
> structured and more unstructured exercises.
> 
> First the more structured ones. I call these "green" exercises. In a green
> exercise you get both a test suite and part of the program with important
> bits missing. Your job is to fill in the missing parts. A good way to get
> a green exercise is to take a normal (I call these "blue") exercise and
> remove the function bodies. So you end up with just structure of the code,
> the user has to fill in the function bodies. The idea of green exercises
> is that they contain lots of comments about the pre- and post-conditions
> of functions and about how a function should be filled in.
> 
> Here's an example (Elixir, adapted from example):
> 
> """
> defmodule Teenager do
>  @doc """
>  Answers to `hey` like a teenager.
> 
>  ## Examples
> 
>  iex> Teenager.hey("")
>  "Fine. Be that way!"
> 
>  iex> Teenager.hey("Do you like math?")
>  "Sure."
> 
>  iex> Teenager.hey("HELLO!")
>  "Woah, chill out!"
> 
>  iex> Teenager.hey("Coding is cool.")
>  "Whatever."
>  """
>  def hey(input) do
>    # TODO
>  end
> 
>  # Returns true if and only if `true` contains no
>  # text or only whitespace.
>  #
>  # Please do not use a regular expression here.
>  defp silent?(input) do
>    # TODO
>  end
>  ...
> end
> 
> Green exercises do a lot of handholding and are intended to guide a user
> into a certain solution in order to teach good style.
> 
> Red exercises are the opposite approach, as little hand holding as
> possible and harder problems. The idea of red exercises is that where in a
> blue (normal) exercise you get the test suite in a red exercise you don't
> even get that. In a red exercise you get a description of a problem and
> have to write both the program and the test suite. You're also expected to
> properly document the program.
> 
> The idea of a red exercise is that a good programmer has to be able to
> write good tests and that means thinking about where the program could
> fail, what the corner cases are, what the design requirement _doesn't_ say
> but is expected anyway. In a red exercise users are also required to
> document their code, API documentation is very important for
> maintainability in the real world.
> 
> Green exercises are very scholary, focused on teaching while red exercises
> are focused on demonstrating the ability to write quality code. Blue
> exercises are somewhere in the middle.
> 
> In terms of complexity and time investment red exercises are much "worse"
> than green or blue exercises. Red exercises are intended to be challenges.
> 
> I imagine users would be encouraged to try the blue exercises first and if
> they feel they need to learn more do some green exercises and if they feel
> blue exercises are way too easy do some red exercises.
> 
> This post has gotten long already so I'll shut up now. ;)
> 
> Greetings,
> 
> Peter
>