Code Avoidance

One of the things that makes me a RelationalWeenie is my distaste for code. The more information that is factored into tables the better. Part of the reason is that I can query (filter, sort, group, cross-reference, etc.) the information any way I need or want, not just the way the author intended or prefers. I am more liberated from others' styles and personal preferences.

Code is just overall hard for me to navigate in comparison to tablized info. Code just shows you a big wad of details. You have to stare at it carefully to find the "big picture". With tablized info, I can query to see the big picture as needed. In fact, there is no one "big picture" (except for maybe the schemas), it is a matter of seeing specific needs for the situation of the moment.

Maybe my eyeballs or eye-to-brain connections are just faulty, or perhaps I have just better learned to use databases as organization and search tools more so than other developers. I don't know which is the correct answer, but I hope it is the second. Are databases a crutch or a liberator? It seems more logical to make code dynamic instead of make one's head static, in the sense that code is more static than a data-tized version. Otherwise, we should all go back to assembler if we don't really need/want "brain helpers".

Likely both. Like any tool, databases can be either a crutch or a liberator depending on how they're used. I've converted a helluva lot of code at work to table-driven, though I mostly use hashtables because a database query is laughable given our performance targets. But if you aren't aware of the alternatives, they become a crutch, because you miss out on better ways of structuring things. I don't object to your TableOrientedProgramming advocacy so much as your denigration of OOP and "code". You severely limit yourself by sticking other people's pre-built objects (and functions) into tables instead of being able to code yourself. I would absolutely hate to do any of my current projects (work or otherwise) without any objects at all, just like I hate Java's insistence that I can use only objects. -- JonathanTang

Well, it is probably for another topic, partly because a meta-tized form of code and OO perhaps are somewhat orthogonal issues, but I have yet to see code-based evidence that OO is better. Why should I assume your anecdotes are sufficient? Also, if you have a specific scenario where you found RDBMS too slow, I would like to inspect it, but under AreRdbmsSlow.

Perhaps the author just needs to brush up. See TipsForReadingCode. [removed impolite text] You seem to be under the impression that databases can do anything code can, which is laughable at best. A database is just a program, written in code. Code is the only way things are created, every language is vastly different, and running SQL queries is not programming.

{I don't want to start a big debate and shouting match here because it gives some an excuse to delete the whole topic. I do find much coding nothing more than structure handling and DatabaseVerbs. Thus a large part of it can be converted into database handling. It is not a matter of "cannot do everything code can", but doing a large part of it, reducing the need for code. I will start a new section below about what to make code and what to not.}

As a thought experiment, it is sort of like putting language info into a meta format so that you can see the same program as Java, VB, or Python, etc. For example, I prefer the type declarations of statically-typed languages to follow the variable name (like in Pascal) instead of come before (like in Java). If such info is in meta-format (such as a database), then you can have the type indicator anywhere you want, even get rid of it for a more compact pseudo-code-like view. If you don't like semicolons or prefer X/endX blocking over curly braces, no problem. (I suppose .NET and P-code like technology is sort of like this.) Those are only presentation details. Presentation can be divorced from meaning. It is analogous to having a dynamic report-writer in front of you to query and print the data or code any way you can imagine.

Code hard-wires a single view or style. Meta-fying logic and algorithms makes it easier to make the view fit your mind and/or your needs.

Of course you overlook the fact that you can't metafy code like that. That whole paragraph shows a serious misunderstanding of how languages and code actually work. You should take some classes and learn how to really program, then come back and read this.

You seem to have the impression that I propose that the entire application be "metafied". It is not an all-or-nothing thing. I suppose the "thought experiment" may give a misleading idea of how much is meant practical, but it is only meant to help one visualize the process, not be the end in itself. I would also note that Microsoft's CommonLanguageRuntime assumes a meta-structure is sufficient. It is just that their CLR is a navigational database instead of a relational one. But it *is* a database. Should Microsoft also "go take some classes", as you so diplomatically suggested? Hell, they could buy the whole campus and give everyone on it a personal yacht.

I don't understand your point. It is not possible to divorce code and data; both are required. What is a database query except for code that returns data? What is a report writer, except for code that operates a specific data set? Could you expand upon the point you are trying to make?

The goal is not to totally get rid of code, but to minimize it from the developer's perspective. Relational query commands are (or can be) rather compact in comparison to the old-fashioned way because they specify what you want instead of how to achieve or hunt for it. Plus, they are more or less standardized. Further, the report writer might be written in code, but the user (report developer) does not have to see it or care, just like the code to process DB queries inside of Oracle or MySQL is usually not the app developer's concern. It is just old-fashioned reuse and OnceAndOnlyOnce. I consider databases a HigherAbstraction?.

I guess I am still missing the point. The portion of the code that reads and writes to a persistent store is a tiny portion of what is done in code. I agree having data base column names makes it easier to pack and unpack data as compared to writing a custom text parsing routine, but there is an awful lot of code required to get that data into and out of the data store. I need both the data and a way for users to enter and view it. Both data and code are required, and they are rarely interchangeable.

[I don't think it is so much about disk persistence as it is about how much of an algorithm can be converted to a data structure with attributes, and then operate on that data structure. Whether that data structure is a table, map, XML, and so forth is a separate issue because they are interchangeable for the most part, even though people will probably not agree on which form is the "most convenient". Allegedly, most algorithms can be converted to a mostly attributed based approach, even though it may not be obvious how to do such for at least some people. Perhaps we need a new topic called ConvertingImperativeToDeclarative so that attribute and declarative proponents can supply tips for those who are curious or skeptical. Perhaps it is an art form that may not come easy to some. Also keep in mind that being able to convert something to a declarative form does not necessarily make it convenient (TuringTarpit). CommonLanguageRuntime may indeed turn a program into just a data structure in the end, but very few would want to deal with a program entirely in that form, except maybe for debugging. Even declarative fans probably would want to deal with some parts of the application as code instead of a data structure. Proponents need to clarify how and what to make into declarative structures, what to leave as code, and how to tie the two together.]

Further, some people put into code what could be data. See change-log example in DataAndCodeAreTheSameThing

Okay, as I started reading this page, I was nodding. "Yes... data driven approaches are often far superior to code-driven approaches." "Yes, they can be queried more flexibly, and are usually easier to view." But then you got to your "thought experiment", and you lost me completely.

There are two things going wrong here. First of all, after reading the PragmaticProgrammer book, I really came to believe in the PowerOfPlainText -- I think trying to store the code in a database is wrong-headed and won't be useful. But that's only a small issue, one to be discussed amongst reasonable people. The other mistake you make is far more fundamental. You assume that there is no difference between languages other than trivial syntax differences. This is simply not true... there are vast differences. First of all, there are library differences: code to read files in Java and code to read files in Pascal will be vastly different code, even though both languages support file I/O as part of the standard library / language definition. Not only does Java use objects and play peculiar OO-specific tricks like extensive use of DecoratorPattern, but even the fundamental idea of what a file IS differs: Java thinks it's a series of bytes, or perhaps a series of unicode characters in some encoding, while Pascal thinks it's either a series of binary records or a collection of lines, each containing a series of characters.

Even beyond the question of libraries, the fundamental structures of languages may differ. Iterative techniques used in C might be better done using recursion in HaskellLanguage; regular expressions used in PerlLanguage might not exist in FortranLanguage. To use only languages you mentioned, an object in PythonLanguage is a fundamentally different thing than an object in JavaLanguage (try adding a new field on the fly to an instance of a java object).

Anyway, I think you're all wrong about this thought experiment. And by this point this rant has wandered far off topic for this page... perhaps some wise WikiGnome can ReFactor this onto an appropriate page of its own. -- MichaelChermside

I have the view that the majority of "operations" in most code is (or can be) simply DatabaseVerbs in disguise. The rest leave as code (see below). If I took the time to analyze your code, I bet I could reduce much of it to DatabaseVerbs. This makes application design more consistent so that a developer can walk into a random shop and grok the system quicker because it is composed of standard building blocks. One is closer to the LegoToy view of software development.

Things that data-centric approaches are good at:

Things they are not good at (things to keep as code):

Sometimes items in the second list can be converted to DatabaseVerbs in part or in whole. It does take practice to learn how to recognize some of such refactorings. For example, a bunch of similar-looking Case statements may be convertible into a ControlTable.

I have been experimenting with a design for a programming code interpreter. A large portion of the operations can indeed be converted into DatabaseVerbs. (I won't promise that the execution of such a thing is fast, but it is only a demonstration of concepts at this point.) Functions, parameters, variables, jump-to points (for blocks and loops) can all be reduced to things like table lookups and cross-referencing. Sure, there is code, but much of it simply calls table operations. Somebody familiar with relational schemas can look at the schemas and grok the system pretty quick. They don't have to learn custom structures and custom methods on those structures first. Think of a database as a somewhat standardized general purpose AbstractDataType. It is reuse at its best.

Is this an AbstractionInversion?

See BigSoupOfClasses, EverythingIsRelative, CodeGenerationIsaDesignSmell, SyntaxFollowsSemantics, DataAndCodeAreTheSameThing, InkBlotSoftwareEngineering, DataCentricThinking, WhereTheLightIsBetter, SoftwareAsLiability, OoVsRelational

EditText of this page (last edited February 25, 2013) or FindPage with title or text search