Would the concept of source code layers be of any use?

Question

I'm talking about something like layers in photoshop, except they apply directly to the source code. For example, in pseudo-code... inventing what some project might look like - say a computational fluid dynamics program:

[base layer]

cfdTime runTime(0);

fieldVariable U;
fieldVariable p;
U.initialize();
p.initialize();

while (runTime.run())
{
    U.solve();
    p.solve()
    runTime++;
}

[turbulence layer]

turbulenceModel turbulence;
scalar nu(readScalar(turbulence.dictionary("nu"));

while (runTime.run())
{
    turbulence.update();
}

[base layer + turbulence layer]

cfdTime runTime(0);

fieldVariable U;
fieldVariable p;
U.initialize();
p.initialize();

turbulenceModel turbulence;
scalar nu(readScalar(turbulence.dictionary("nu"));

while (runTime.run())
{
    U.solve();
    p.solve()
    turbulence.update();
    runTime++;
}

You get the idea. Obviously a lot of things would need to be worked out.

I'm all over object-oriented programming (OOP). This idea strikes me as an awkward alternative to OOP... and I don't think it's worth much... but I thought I'd toss it to the community... there just might be something useful in it that I'm not quite seeing.

It may be useful from a GUI-only perspective - creating layers in the GUI for complex functional programming... while the underlying code is always the same. Or it may be useful for code optimisation, perhaps an alternative to #ifdef that developers won't run screaming from. Or, it may be an entire alternative to OOP.

Your thoughts?

Answer 1

What you are referring to strikes me as being just Aspect Oriented Progamming, which is:

[...] a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns

Or even by extension Aspect Oriented Software Development, which is:

[...] an emerging software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program's business logic[, allowing] multiple concerns to be expressed separately and automatically unified into working systems.

While this idea doesn't translate to layers if you consider its implementation, the conceptual representation of the cross-cutting concerns could fit this analogy.

For more information, you may want to read Ian Sommerville's Software Engineering textbook, which covers AOP in detail in chapter 21 [slides], or read some introductory articles like:

• A Look at AOP
• A herd of academic papers published since it appeared in the mid 90s and was popularized by G. Kiczales' Xerox Labs paper in 1996.

It is interesting to note (to complement Asumu's answer) that some languages can support features like AOP from the ground-up, while these things may seem unnatural in other mainstream languages.

In the case of your example, what you're showing could be implement with AOP as long as your modularize the different entitites correctly, so as to have good join points.

Answer 2

In a sense, what you want to do is invent a new language that has the right primitives that you want (e.g., for fluid simulation) instead of expressing them in a lower level language. Macros are one way to implement this kind of thing, by allowing you to write what is essentially a domain-specific language (DSL) to solve your problem. You'll find the most powerful macro systems in languages like Racket, Scheme, Clojure, or other Lisps. Take a look at this article to see how far a language with macros gets you.

Alternatively, languages like Haskell and Scala also let you define new DSLs. Haskell mainly through monads and functional combinators. Scala using infix methods, call-by-name parameters, and implicits. Various other languages (too many to list) have their own ways of doing this kind of metaprogramming.

There are also software engineering approaches to solving this. For example, by using an editor that's capable of abstracting from your source code. This paper takes such an approach with Eclipse.

Answer 3

I think layers (from graphics programs) are similar to some kind of compositional unit of software (functions / objects ). There might be better visualization tools that help see software composition in a way similar to layers. Maybe even manipulate software composition. perhaps even like Inventing on Principle.

Or potentially, the graphics world might like some of the ideas from the software world.... like inheritance or polymorphisim.

Answer 4

You might be thinking up something like pretty-lisp, in that it is an IDE that visualizes a piece of lisp code. But IDEs depend on languages, they are not language agnostic.

Answer 5

That actually reminds me of how old MS Qbasic would display subs, but If you looked at the actual .bas file, it was linear. Maybe all you need is a text editor that's smart enough to collapse code blocks in a navigation tree. I think I've seen something like that for HTML tags.

Answer 6

This question brings to mind a nice section in the book Framework Design Guidelines that describes a concept called Progressive Frameworks. The Idea being that you provide an API in a layered form which allows developers to access the API through a combination of basic interface, through to a more complex interface, depending on the developer's level of experienced and use case requirements. The simpler interface would ask for a handful or parameters/objects/etc, while the next level of interface would expose more parameters, etc... all the way to the highest usable layer which would expose everything. The code itself would effectively exist and callable in layers similar to that which you've described, although you would necessarily ensure there was no duplication by having each of the simpler layers calling into the more advanced layers progressively. This can be a very useful design in terms of providing developers an easy path to learning a single complex API, as opposed to presenting multiple APIs to suit the same purpose. It is also a concept that can be applied regardless of the programming paradigm used (I.e.: Functional, OO, or whatever).