[racket] Exploratory programming?

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Tue Nov 30 12:41:18 EST 2010

It isn't clear to me whether you have tried 

  > (help "lambda") 

in your emacs repl. If so, do you object to the browser coming up with intensively hyperlinked documentation? Or do you not like the format? 

Let us know what's wrong with that. 

;; --- 

I have done a lot of bottom up programming in Emacs (Scheme and Lisp) and I still do in DrRacket. But I learned that bottom-up programming is the norm and that what makes it successful is some amount of top-down planning. If you meet somewhere in the middle and explore from there, you can grow into a super-programmer. 

-- Matthias

On Nov 30, 2010, at 11:55 AM, Richard Lawrence wrote:

> Dear Racketeers:
> Apologies in advance for what will probably be a long-winded newbie
> question.  I'm wondering how one goes about "exploring" the Racket
> libraries.  That is, how does one find out things like:
> 1. which modules are likely to contain functions useful for a particular
> task
> 2. what names a given module exports
> 3. more information about the objects exported by a module: e.g., 
> brief descriptions, their types, what methods they respond to, ...
> Here's some background. Most of the programming I have done is in
> Python. One of my favorite features in Python is that
>>>> help(X) 
> gives useful information for just about any object X. This is great for
> exploring modules, learning about the methods and member variables of
> classes, and finding out what functions do; it's an important
> "bottom-up" tool for exploring the language and libraries. In Python, I
> can often think, "I need something similar to, but not quite the same
> as, X; X is defined in module M; so let's do help(M) to see if M has the
> function I want." Often, I can tell at a glance over the docstrings that
> the thing I need -- or something related to it -- is there.  (This kind
> of "bottom-up" exploration is complemented by the documentation for the
> Python standard library, which provides a nice "top-down" reference.)
> I know that REPL-based interaction is de-emphasized in Racket.  Does
> that mean that the kind of "bottom-up" exploration of the language that
> I'm describing is de-emphasized as well?  Should the documentation be
> the first (only?) place I go to learn about modules and their contents?
> If so, what's the best way to access and search the documentation while
> programming?
> Please understand that I'm not ragging on Racket's documentation here;
> the documentation is truly excellent.  I guess one way of asking my
> question might be this.  I tend to think of the documentation as
> something I must sit down and read for a while, partly because the
> examples are often extended and build on each other, and partly because
> of the psychology of jumping out of Emacs into a browser.[1] Is there a
> different way of using and thinking about them?  In particular, is there
> a way of using them that corresponds to the uses of help() in Python?
> Thanks for your thoughts!
> Best,
> Richard
> [1] I have so far mostly stayed away from DrRacket, because I know Emacs
> well and haven't felt the desire or need so far to learn another
> environment.  Is that my problem?  Does DrRacket support the kind of
> bottom-up exploration in the documentation that I'm trying to describe?  
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users

Posted on the users mailing list.