[racket] Racket style guide (was Re: Argument order conventions (was: Variable naming conventions))
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