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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
