http://qs321.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

Replies are listed 'Best First'.
Re: models of models
by clemburg (Curate) on Feb 09, 2001 at 15:46 UTC

    The Programmers' Stone will interest you. It discusses the nature of programming as a problem-solving process, and much more.

    For a little treasure-trove of existing thought models for programming, have a look at The Pattern Almanac 2000, a collection of short descriptions for existing Patterns, with extensive cross-indexing and categorization, and with a really good literature reference section.

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

      It may be personal, but I was not impressed by The Programmers' Stone. I didn't read the whole thing this time, but I read earlier versions. My impression then, and now upon reskimming, is that the author defines packer and mapper by analogy (never gives a real definition) and then proceeds to make it "us" versus "them" where "we" are great and "they" are rigid buffoons. So of course you want to be on of "us", don't you? And here is what "we" are like!

      I am sure he has a lot of interesting thoughts, but abusing rhetorical techniques like that raises red flags for me. Besides which I am not much of a joiner, and I really hate making decisions when I have less than 3 alternatives on the table. I find that with 2 it is too easy to get into "us vs them" thinking. With 3 I start being able to compare and contrast.

Re: models of models
by extremely (Priest) on Feb 10, 2001 at 11:59 UTC
    Personally, I tend to write down everything I want the script to be able to do. Then I write down everything that my boss will expect it to do. Then I wrap my boss's book up in the single sheet of my expectations and pound myself unconscious. When I wake up I usually have a reasonable idea of what I'm going to start with...

    OK, actually, I flowchart tasks and APIs first. Much like OOP, I try and figure out what will be done in a general overview and how the big pieces will fit together. Once I have that idea, I pick a small chunk near the middle of the whole shebang and try and get it to respond to my first API spec. Then I flesh it out and start on a neighbor that calls or uses that chunk. At about the 50% level, I start deciding what to re-write. =) There is no such thing as 100% (at least so far)

    --
    $you = new YOU;
    honk() if $you->love(perl)