The ability to create Small Demo Packages is a positive determinant of Building Developer Communities since it makes it easy to add value by demonstrating concepts and diffusing knowledge
See also Small Demo Package Comparison
Problem: When learning a software language, or when sharing software knowledge, it's great to be able to create small programs for demonstration purposes.
Some development environments make it easy to create small demo packages. For example, in Visual Foxpro, it's relatively easy to encapsulate and convey demonstrations in a single PRG, even for more complex things like forms. It's slightly more difficult to ship 2 or more files, like for .SCX/.SCT (form files) or a .VCX/.VCT (class library files).
Some languages like Visual FoxPro store some some program elements in structures, and to the extent that these structures evolve with time, this limits the ability to share examples. For example, the menu structures (.MNX/.MNT files) changed between VFP 6 and VFP 7. Thus any menus created in VFP 7 won't run in VFP 6 and this limits protability between version and, by extension, portability beteen developers.
Some languages, like Java, make it especially easy to document programs in source code; viewing the source code in a web browser highlights comments.
Some languages, like VB 6 and prior (and possiby onwards, who knows?), it can be borderline ridiculous to share stuff. Case in point: The Total Visual Source Book, an excellent library for VB from FMS, has the following instructions for all its classes and functions
' Example code for CTokenizer
' To try this example, do the following:
' 1. Create a new form
' 2. Add a command button named 'cmdTest'
' 3. Paste all the code from this example to the new form's module.
' 4. Run the form
I mean, how bad is that? If you need to do this, then it's more difficult to create Small Demo Packages, and they are more difficult to run. The inevitable end-result is less sharing among developers.
Some "bare-bones" development environments make it difficult to create and ship all but the most basic small demo packages. This is because developers may have vastly different collections of add-ons and third-party libraries. To the extent that the basic developer infrastructure is variable, the harder it can be to share.
Therefore: Software communities tend to be more sharing and friendlier to newcomers if small demo packages are easy to create, compile, execute, store, package, and ship.
I find that creating such a demo helps me learn. Sometimes my thoughts are not quite consistent with reality, and trying to build something to demonstrate my thoughts brings this incorrectness into the spotlight.
I would like to expand on this: I just spent 4 hours on a simple problem. at 3.75 hours I concluded I had found a bug in VFP. I spent 15min writing a small app to demo it, and it suddenly became clear that IF EMPTY(.T.) is not the same as IF EMPTY(""). (The root of my problem was a prop_access method that was blanked out, so the debugger was showing prop="", but empty() was getting the implicit RETURN .T.) The moral of this story: don't be so smug that you think you are above creating a SmallDemoPackage to demo a problem. -- ?CFK
Amen. And I'd add, if I may, the the best programmers do this as a matter of course when they're trying to puzzle out a problem that's irksome--or communicating a concept. For example, CristofLang and AndersAltberg are role models, IMO, on the newsgroups. -- Nancy Folsom
What I love about VFP is how much you can demo or "try out" right from the command window. -- Randy Jean
I also think that answering questions with Small Demo Packages has a longer lasting benefit to the community than a bunch of simple answers to the specific questions. (And definitely more benefit than a big pile of half baked answers.)
Contributors: Steven Black Carl Karsten
Feel free to add, edit...
Category Software Communities
( Topic last updated: 2002.02.07 02:54:36 PM )