Source Code In Database

Some interesting quotes: (but read the whole essay)

"We have been teaching our customers to regard their data as a precious resource that should be milked and reused by finding many possible ways of summarising, viewing and updating it. However, we programmers have not yet learned to treat our source code as a similar structured data resource."

"We would never dream of handing a customer such error-prone tools for manipulating such complicated cross-linked data as source code. If a customer had such data, we would offer a GUI-based data entry system with all sorts of point and click features, extreme data validation, and ability to reuse that data, view it in many ways, and search it by any key."

Maybe that's because we're smarter than our customers....

Or maybe programmers are more arrogant, or stupider, or maybe "we" just want everyone that isn't a bona fide RealProgrammer to shoot themselves in the foot the moment they try to modify a single comma of the Holy Grail that's been handed to them.

PowerOfPlainText, DoTheSimplestThingThatCouldPossiblyWork, DatabaseVendorLock, VersionControl

I once thought SCID is a great idea. Since then, I've come to understand how important the source code is, as written by the programmer. Upon that, you can add ctags, cross-referencing, analysis, etc. but I don't think you will overcome the need for the clarity, longevity and flexibility of plain text source.

Syntax for programmers is a helper, not a hindrance.

Possibly a false dichotomy. How does having source code in the database stop "syntax"? I agree that existing source-code editors don't support text in DB's, but let's separate what vendors support versus what is "good".

Which is why I want my own custom syntax, beyond what standard Smalltalk affords me. But the only way to do that and keep things portable is to remove syntax from the language entirely and put it in the authoring environment. See ImprovingTheSmalltalkDesign for more on precisely this idea.

Sounds like SeparateMeaningFromPresentation.

I've been kicking around ways to classify or put meta-info into a code database to track routines. Here is a rough-draft schema:

  table: routines
  ----------
  screen_ref
  report_ref
  widget_ref
  action_ref   // example: on_click
  field_ref
  entity_ref
  code_text

If the routine does not correspond to something, such as not belonging to any report, then simply leave that column empty (0 or null). Another problem is maintenance; if a routine is moved to be used on something else, it may not get updated because it is not necessary to run the code. Perhaps if the attributes are actually used to run/compile the program, this might change. It would allow one to "program by attributes".

Another problem is that something may end up being shared among multiple items. For example, a given routine may be used by two different reports. A many-to-many table could solve the multiple item problem, but complicate our design.