[racket] raco pkg new (was: Learning Scribble)

On second thought, you are right, and all your points are valid. The
incremental part is the most important aspect of package development.
And if by "anti-stubbing" you mean "if you need a stub, then something in
the design is wrong", then this is a very nice principle, although probably
quite difficult to follow closely.

As Greg pointed out, currently the most difficult part (though possibly the
most important too) of the package development is writing docs, because
there are many things that aren't obvious (module declaration, writing
examples and interactions, all the defproc variants, grammars, not having
identifiers underlined with red, single vs multi-part doc, etc.). I really
like Greg's def-jambda [1] effort, and I even believe it may be the key
component to see the appearance of many more and much better packages.
Currently writing docs just requires too much effort, and there is way too
much redundancy (which is not Rackety!) in this process, easily leading to
discrepancy. My old-and-ugly "lazy-doc" package [2] was also meant to
greatly simplify writing documentation, but it was badly designed (not even
Lispy). Neil's McFly [3] also has this purpose but unfortunately arrived
right before the new package system (and so I haven't taken a good look
into it).

So indeed it's not a stub that is needed, it's a much simpler way to write
the docs. But it has been true for years now, even though Scribble is
fantastic. I'd like to believe that if several Racket core devs took a deep
look, discuss and develop def-djambda or something of the like, we could
have an beautiful and simple official code documentation system that avoids
redundancy within a month —but I'm a dreamer, I know.

Laurent
[1] https://github.com/greghendershott/def-jambda
[2] (Don't use it)
http://planet.racket-lang.org/display.ss?package=lazy-doc.plt&owner=orseau
[3] http://www.neilvandyke.org/mcfly/

On Sat, Dec 14, 2013 at 3:45 PM, Jay McCarthy <jay.mccarthy at gmail.com>wrote:

> I didn't respond to this thread originally because I believe that
> Racket is generally "anti-stubbing". The concept of a "racket project"
> basically doesn't exist, because everything is supposed to be "inside"
> the language. For instance, if you want to create a module with tests,
> then you just create a file named m.rkt and put in
>
> #lang racket/base
> (module+ test (require rackunit))
>
> and you're done. There's nothing more that you would want to do.
>
> You can write documentation inline too, but admittedly you have to
> create a info.rkt and at least one scrbl file.
>
> As far as the "boring stuff" of creating a package... the package
> system is designed so that that is just "mkdir pkg-name". You don't
> need to do anything else. Even if you want to distribute the package,
> you just need to make sure the directory is online somewhere. As you
> get more sophisticated as a developer you could do "git init", but
> it's supposed to be incremental and a low barrier.
>
> Jay
>
>
>
> On Sat, Dec 14, 2013 at 1:36 AM, Laurent <laurent.orseau at gmail.com> wrote:
> > On Fri, Dec 13, 2013 at 11:14 PM, Ryan Davis <zenspider at gmail.com>
> wrote:
> >>
> >> I'd also be perfectly happy with `raco new <projectname>` w/ a
> boilerplate
> >> project w/ a module, tests, and doco stubbed out.
> >>
> >> Is there anything in the package ecosystem like this?
> >
> >
> > Not that I know of, but it's a good idea. It would probably look more
> like
> > `raco pkg new` (or `raco pkg init`).
> > A `raco pkg git-new` and a `raco pkg github-new` that do all the boring
> > stuff for you may also be quite convenient, if such things are possible.
> >
> > Laurent
> >
> >
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
> >
>
>
>
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20131214/621b5cae/attachment-0001.html>