http://qs1969.pair.com?node_id=57354

Some people learn from the inside out, and others from the outside in. There are pitfalls for both approaches, I suppose. It seems to be a matter of the way that you are 'wired', which direction of drawing lines of connection is more likely to cause the pieces to fall in place for you, when learning something new.

Or else, the experts were right, who told my parents that it was for his own good that my brother would be 'broken' of his left-handedness (they stopped trying before long). In that case, I should be broken of my backward ways, if there's an analogy between handedness and my outside-inedness. Or, it may be that its better to make the most of what you've got, and leave it to others to decide, whether your way or the other is the right way.

I'm an outside-in kind of guy, as are many others. What we need in order to think through an issue, is some intuition into the big picture. A model. With that model, whatever powers of induction we do have can finally be brought to bear effectively. I'm not talking about "The RIGHT WAY"TM . This is a conceptual 'handle', a template, a way to think. So, in my quest to be a better programmer, I naturally want to find a programming "Model".

An OSI-like Model

Since many here use Perl in the IT world, you know how useful the OSI model can be, in helping to order your approach to a design or trouble-shooting issue. It's great for outside-in people, to give them an overview of what networking is all about. It's great for inside-out people, who need to have an idea of the context in which their known details apply.

You also know that the OSI reference model doesn't map perfectly to anything in the real world. It's called a 'standard', but it isn't really because nothing really conforms to it. It came along after other standards were well in place; and so rather than a standard spec, it's a standard 'reference': a generalization of other generalizations.

The OSI model isn't helpful to everyone, I realize. Neither is it useful in exactly the same way, to everyone. But it certainly has been useful to me (even though I was originally misled by a too-realistic interpretation of it, as are many other newcomers), and without it I might never have gotten a start into understanding what's going on in a network. I got the idea that something similar might be helpful, for working in from the outside, into programming and into Perl.

A World of Many Models

So, I started my quest for something like an OSI model for programming. What I found is that the programming world abounds with models and abstractions, so numerous and various that they are themselves a kind of detail layer. My poor head spins, looking around at details. I need to look down on them, at some appropriate distance. Following, are some things I've found that have helped me to make some progress.

Some articles have been helpful in giving an overview of the programming world.
Why I like functional programming In this article, tilly discusses four programming 'styles', or 'approaches'. These represent ways of approaching a problem, which may be more typical of one language rather than another, but not identical to any language. Also, no language model maps strictly to one of these approaches to the exclusion of the others.
What is it about perl that makes perl so cool?, which became the more heated Perl is NOT OO and neither is JAVA, is another example of a 'styles' or 'approach' overview. There are many others.
 
Something approaching a model of models can be gleaned from reading various threads comparing languages, or general approaches to programming. Some languages can be thought of as more 'complete' than others. Some combinations of language can be thought of as more 'sufficient' than others.
RE: Perl Vs. C discusses complementary strengths and weaknesses of the two languages.
The Tao of Perl is highlighted by the quote, "the reason programming is so difficult is that thinking is so difficult".
 
There are numerous threads touching on the difficulty of thinking through a problem. Models of a more practical sort, are in view here.
Planning your software before writing
How to think.
 
And finally in my examples, there are models or criteria that concern optimization on the one hand, or appropriateness on the other.
Such as this one: Code Smarter
 

8 Miles Up

Although I find models useful, I don't find it easy to construct them. Stepping back, maybe for you some candidate-categories begin to appear, for grouping things together. These give you ideas, they get you to thinking, and that (after all) was the intention. So, you press on. Maybe you're a newcomer to programming, with no computer science background. So, your model of models is naive, and looks something like this:

  • models of bit level considerations: concern for the efficiency of processing data. Query optimization, indexing and search algorithms. Program performance.
  • models at a symbol layer: concern for how data is manipulated, how it is created and edited, and called upon to do work.
  • models of an epistemological layer: concern for the interpretation of data. What is the natural way of looking at data? linguistically, as a noun or verb; objectively as an object or subject? Etc.
  • models of appropriateness: dealing with models, to discern what is the right tool or approach for a problem. Interface, metaphor.

Maybe you look around at all the discussions of models of languages, features, benchmarks, methods and consider them in terms of your view from eight miles up, and they start to fall into some order for you at last. At that point, you might post something to Meditations and ask others to improve on what you've begun to learn.

Or, maybe you wouldn't read half-way through a windy, pretentious post like that, and certainly would never contribute one. In that case, (although you wouldn't have made it so far as to read it): That's okay with me, too.
mkmcconn