Should we provide skeleton exercise packages?

[exercism]

Should we provide skeleton exercise packages?

[kytrinyx]

I think that it would be useful, at least at the start.

[verdammelt]

I agree that would be a good idea. I usually have to refamiliarize myself with defpackage when I've been away from the language.

[verdammelt]

Is this a blocker for turning on the track? Or could this be done afterward?

[kytrinyx]

Oh, good question. Let's do the first one, turn the track on, and then we can more later if necessary.

[wobh]

I can get the first one up. I'm writing something to actually generate these. I can commit that to the xlisp/bin when it's ready.

[kytrinyx]

Perfect

[wobh]

Oh. So we have some options for the skeletons. We can do something expansive like the above with whitespace and documentation strings, and making sure we're in CL-USER at the beginning, none of which is strictly necessary, but all of which is "best practices" which could be good for newbies to see but perhaps also distracting and maybe intimidating. We could do something more compressed. Examples follow:

;;;; Expansive

(cl:in-package #:cl-user)

(cl:defpackage #:dna
  (:use #:cl)
  (:export #:to-rna)
  (:documentation "Provides RNA transcription

** Example

CL-USER> (dna:to-rna \"ACTG\")
; \"UGAC\"
"))

(cl:in-package #:dna)

(defun to-rna (str)
  "Transcribes a string representing DNA nucleotides to RNA."
  )


;;;; Compact

(cl:in-package #:cl-user)
(cl:defpackage #:dna
  (:use #:cl)
  (:export #:to-rna))
(cl:in-package #:dna)

(defun to-rna (str)
  "Transcribes a string representing DNA nucleotides to RNA."
  )


;;;; Minimal

(cl:defpackage #:dna
  (:use #:cl)
  (:export #:to-rna))
(cl:in-package #:dna)

(defun to-rna (str)
  )

The "minimal" should be the minimum required so that tests actually run. The "expansive" should satisfy most style guides.

[verdammelt]

I guess I put in my vote for 'compact' by merging your pull request :)

[kytrinyx]

Starting simple seems less overwhelming.

[verdammelt]

@wobh were you thinking of creating an stub file for every exercise or maybe only for for the first few?

[wobh]

I guess I was thinking for at least as many as we have a test suite that requires something specific in order to run. But it really comes down to what's important to us. I see three possible, non-exclusive, thresholds.

1. I haven't done enough exercises, but I sort of think that at some point we would get to the level where the user implements the tests, or in some other way has to setup the public API for themselves.
2. We could get to the level where creating an exercise to generate a skeleton package based on the test suite seems like a reasonable challenge. After that, it wouldn't be necessary.
3. I'm not an educator, but I've often been in the position of helping people learn some new technical task, and one thing I've observed, over and over again is that no matter how intelligent and experienced a person is, new skills require a lot of exposure and repetition. I could see providing at least two dozen of these, then some exercises specifically on setting up on packages. Then a few more to make things stick minimally well, then you're on your own.

We could do nothing, and anyone who wanted to practice could fork xlisp, type them up by hand and make pull requests.

[wobh]

(Two dozen is not an exaggeration for exposing a new thing to someone, even for "smart" people. My experiences have convinced me that human brains require a degree of statistical significance for learning anything that's much higher than modern adults in western culture are conditioned to be patient for. There are probably formal studies of this, and they probably suggest I'm wrong, but I don't have time to read and cite them.)

[verdammelt]

How about we get them in for the first 12 exercises before we go-live? Then fill in the rest as we go and make sure new exercises have them?

[verdammelt]

I'm going to start adding in these starting files - but I noticed that my original test & example files had some inconsistent use of keywords vs. uninterned keywords. I'll need to clean that up as well.

I'm going to work through these issues in the order of the exercises. and start a pull request after I do a few tonight.

[verdammelt]

@wobh I'm starting to wonder if the whole cl:<symbol> stuff might be overkill. I guess it is very correct, but i think it makes the code look odd - maybe it will be too confusing.

I also reviewed some "real" code out there and it doesn't do all of this. Also checking the spec it seems that at most, after (cl:in-package #:cl-user) (if an author even uses that) that :common-lisp will be used so prefixing with cl seems redundant.

I'm suggesting we remove that so that the code is simpler.

Please refer to #27 for a pull request that puts in all the startup code.

[wobh]

I'm fine with not qualifying any of those symbols at all. I only started doing it recently because I saw other packages do it that way (Quicklisp notably, but others seem to be picking it up) and I didn't think about it too much. I don't know who is shadowing IN-PACKAGE and DEFPACKAGE or what with, but it seems weird to think that it might happen in a casual exercism user's lisp environment.

It could be an artifact of generating a package template file. The template maker I'm working on (almost done) does it because of the trick I'm using to make sure other kinds of symbols print okay.

Anyway, lets drop the cl: qualifiers. Sorry, I got us off on the wrong foot with that.

[verdammelt]

Interestingly QuickLisp was a package I looked at to see how "real" software does it. Xach seems to use the pattern in the initial quicklisp.lisp file but not in the code that is actually installed. I guess it is a very defensive pattern.

It was interesting to investigate the different opinions/reasons for the different way to specify this bit of code.

I'll merge in the pull-request and this track is then closer to going live.

[verdammelt]

I believe this has been covered by #27. Closing.