[racket] Racket style guide (was Re: Argument order conventions (was: Variable naming conventions))

From: Hendrik Boom (hendrik at topoi.pooq.com)
Date: Thu Sep 22 20:16:53 EDT 2011

On Thu, Sep 22, 2011 at 01:28:17PM -0400, Neil Van Dyke wrote:
> Matthias Felleisen wrote at 09/22/2011 12:14 PM:
> >Personally, I'd love to see even more of a separation between the
> >header (data + provide) and the implementation. Perhaps I read too
> >much Modula 2 code, perhaps I liked units too much.
> 
> Modula-2 made me a better software engineer using C around 20 years
> ago, in a surprisingly good community college course.  However,
> thank goodness I never had to do real work in Modula-2.  

I use Modula-3, en entirely different languauge, though it uses 
Modula-2's separation of interface and implementation.  It is 
statically typed, type-safe, and garbage collected, and it provides 
the so-called objects with single inheritance. 

> We
> implemented a spreadsheet program as a team project, with a rule
> that we weren't allowed to see other people's Modula-2
> implementation files.  It was an educational experience, in team
> dynamics as much as anything else.  

The Trestle library in Modula-3 is a good example of clear and precise 
specification-writing.   The  kind of thing that it may take you a while 
to understand, but which, when you finally get there, you are very 
inlikely to have misunderstood.  And the Trestle manual is derived 
entirely by a machanical process from the Trestle interfaces.  The kind 
of thins a lot of open-source projects try with tools like doxygen, but 
don't get right.

> But we were not at all fond of
> klunky and annoying Modula-2 setup (perhaps somewhat like people who
> used an impoverished Scheme implementation for annoying problem sets
> in college decided they disliked Scheme).  

I don't know what you mean by a klunky and annoying setup.  Presumable 
this is different form Modula 3.

> We would've been much
> happier with Turbo Pascal, and I wonder whether whether we could
> have learned just as well using TP units and some conventions to
> discipline us about interface vs. implementation.  Based on industry
> experience immediately after that, working in C on large high-end
> workstation software and fancy embedded systems tools, I'd say that
> the Modula-2 experience taught one very useful discipline that few
> of the C developers at the time seemed to have a good grasp of.

I've notieced on one program that drawing the bounaaries between parts 
of the program is very important to get right.  I once had a procedure 
in the wrong module, though it seemed conceptually to be in the right 
place.  Somehoe I got the idea to move it to another module.  When I did 
that, there wsa suddenly an enormous simplification in the code, and the 
division into modules really started to help development instaead of 
hinder it.

I probably wouldn't have discovered that in C.

> 
> I wonder whether anyone using Racket for a course with a large team
> project has tried forbidding team members from looking at each
> other's implementations -- let them work only from module interface
> docs or something like Racket's "sig"s -- and how that worked out.

Forbidding that would have precluded me from discovering the code 
simplification that became possible.  A module specification needs to 
compromise between the innards of the implementation and the needs of 
the user.  You won't know where to draw the line unless you can see 
both.

> It might be harder to do nowadays, due to many students having
> preconceived ideas of how team projects work, based on all the
> public open source projects, the popularized codification of Agile
> cowboy methodologies, and on post-dotcom title inflation-- students
> might not believe you if you say "this is how *software engineering*
> is done."

Software Engineering is the art of getting things done with 
large numbers of relatively stupid programmers -- because there aren't 
enough really good programmers.

> 
> -- 
> http://www.neilvandyke.org/
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users


Posted on the users mailing list.