To expand on the earlier answer, most of the modules are fully functional without any programming effort. Programming or template modification (HTML work on .adp pages) is necessary to change the look and feel other than header/footer changes (adding decoration to the top of a page, etc).
Still, though, you can set up bboards, ecommerce, news, classifieds, etc without writing a single line of code, merely by editing the ad.tcl initialization file to reflect your installation.
The result will look a lot like this site, or the bboard, etc portions of photo.net.
Where programming's really needed within the current framework is to either add new functionality or to complete functionality that's not been generalized to the full toolkit. For instance, user groups are really useful but only a few modules make use of them. Likewise general permisssions. aD keeps working on this, and this general shortcoming, plus the need to modify .tcl scripts to change look and feel for untemplated modules, have driven much of the discussion on general architectural issues here at openACS.org. Ideally all grouping issues (which groups of visitors see what features, who can read or write to various forums etc) should be abstracted out as should SQL and presentation issues.
