Narrative structures in programming

General programming chat and advice for beginners

8 posts
by Markx » Sun Dec 16, 2012 4:10 pm
I a noob in every sense of the word, i have been learning to lrogram for the last month and i am really enjoying it. Last night a thought occurred to me, please excuse me if this question is particularly stupid; Is there a narrative structure to a program? In the same way that a story has a beginning middle and end. Not in the way that a mathematic equation has a narrative. It's just that I understand story and tend to use it as a frame of reference for most things. That begets the thought; do I need to drop this frame of reference to better understand programming and concentrate on more abstract ideas. Or can both schools of thought coexist in an approach to programming, complementing each other.
Posts: 21
Joined: Thu Nov 08, 2012 12:19 pm
by gordon@drogon.net » Sun Dec 16, 2012 10:26 pm
Markx wrote:I a noob in every sense of the word, i have been learning to lrogram for the last month and i am really enjoying it. Last night a thought occurred to me, please excuse me if this question is particularly stupid; Is there a narrative structure to a program? In the same way that a story has a beginning middle and end. Not in the way that a mathematic equation has a narrative. It's just that I understand story and tend to use it as a frame of reference for most things. That begets the thought; do I need to drop this frame of reference to better understand programming and concentrate on more abstract ideas. Or can both schools of thought coexist in an approach to programming, complementing each other.


A lot might depend on your programming language, and mode of thought...

Have a look at:

http://en.wikipedia.org/wiki/Top_down_programming

I tend to think of a project in terms of what I need to achieve (top-down), but actually work on it from the botton-up...

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1421
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by gritz » Mon Dec 17, 2012 12:54 am
Back in the day (BASIC) we were taught to draw a flowchart before even starting to write a program. This was because the journey from "inputting some data" to "getting a useful result" could be convoluted and obviously every possible combination of inputs has to be covered ('cos compuers can't think for themselves). Modern languages which might denote things (even abstract concepts) as "objects", classes" and whatnot might work a bit differently under the hood, but I think that identifying exactly what you want to do, puzzling out how you're going to get there and identifying / dealing with all those "forks in the road" your method is likely to encounter before formally starting to write lines of code is still valid.

As a journey the average "doing something useful" program is probably not a straight timeline, but more of a boardgame, or one of those old fantasy novels, or a Tarantino film. :)

Gordon is right, the fine details depend on the programming language to a degree and there's no short cuts to learning the finer points of a particular lingo, but remember that programming resources are written by programmers, and many of them (especially the ones who write Wikipedia entries) abstract the creative process (which they don't necessarily excel at) from the nuts and bolts of the coding (which they're much more comfortable with) to the extent that us mere mortals can feel quite alienated. Programming is problem solving - it involves both scientific rigour and abstract creativity. If drawing / imagining a storyboard works for you, then go for it! Your mental model will refine as you gain familiarity with your chosen programming platform and who knows... perhaps soon you'll be in a position to write the first Wikipedia article that a normal human can empathise with! ;)
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by -rst- » Mon Dec 17, 2012 12:29 pm
I think you Markx are more right than most people in the business would ever admit! As gritz says, back in the day the flowchart was the design model for software and to me it seems it is a shame it has nearly disappeared (f.eg. UML Activity Diagrams are flowcharts http://en.wikipedia.org/wiki/Activity_diagram).

Of course back then most programs were more for batch processing of data - the beginning being reading in the data, middle being the processing and the end the output. Nowadays most software is more complex than that: interactive, multi-threaded, multi-user etc. - but in the end, most 'use cases' boil down to a very similar pattern of input-processing-output. So a modern software would be like a novel or film where multiple concurrent - possibly intertwined - storylines unweave.

What has been bothering me for the last 10 years or so, is that younger colleagues having been trained in object-orientation, graphical tools etc. have somehow lost the very basic idea of software development, that in the end, everything is sequential and the computer only does what you told it and in the order you told - there is no magic and no mind-reading ;)

Many people over the years have said 'programming in BASIC rots your brain', but I think the strict sequential nature of it actually teaches you the very basic - simple Python is nearly as good, but even assembly language and C add 'too much' of embellishments around the actual code, which easily confuses the beginner or blurs the focus...
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'
Posts: 891
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland
by gordon@drogon.net » Mon Dec 17, 2012 1:13 pm
-rst- wrote:Many people over the years have said 'programming in BASIC rots your brain', but I think the strict sequential nature of it actually teaches you the very basic - simple Python is nearly as good, but even assembly language and C add 'too much' of embellishments around the actual code, which easily confuses the beginner or blurs the focus...


So I have this CESIL (simplified assembly language) interperter written in BASIC if you're interested...

https://projects.drogon.net/cesil-controlled-xmas-tree-on-the-raspberry-pi/

;-)

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1421
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by -rst- » Mon Dec 17, 2012 1:28 pm
gordon@drogon.net wrote:So I have this CESIL (simplified assembly language) interperter written in BASIC if you're interested...


Gordon, I am using wiringPi (thanks!) and have looked at your other projects with interest and awe ;)

However I don't think I will go back to BASIC after some 25 years ...except maybe for some nostalgia if I ever have some spare time - or maybe if I get the kids interested in learning programming :roll:
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'
Posts: 891
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland
by rurwin » Mon Dec 17, 2012 2:02 pm
It's an interesting question.

Within broad limits, the answer is yes. All programs begin by initialising data, checking their parameters, creating windows and so forth. Then they have a middle, which is where all the work gets done. When all the work is finished, they then have to tidy everything away, close all the files, maybe generate the output data and so forth. Within a program the individual functions/methods will have something like the same structure, although the end tends to get lumped into the middle quite often.

Unless the program is very simple, the middle will not have a simple narrative structure though. It's more like an RPG than a novel. There will generally be a loop, and within the loop several different things can happen with no predefined order. It generally starts by getting some input, maybe from the user, maybe from a file or the network, etc. Then it processes that data and produces some output. Sometimes the output will be presented to the user, sometimes it will be written to a file or the network etc., and sometimes it will just be put into internal variables for later loops to pick up. There is usually no way to tell in advance what path the program will take without knowing what data it will be presented with (and at what time).

Imagine you have a book. The first chapter is titled "Bert wakes up", and the last chapter is titled "Bert goes to bed." In between you have chapters with titles such as "Bert has dinner", "Bert goes to the pub" and so forth. Every time you read it all of the middle chapters are in a different order, and of course because different things happen in a different order each chapter is different each time too. Bert wont order a basket of chips in the pub and spoil his appetite if he has already had dinner. The chapter "Bert's dog eats his dinner" may never happen.

So programs do have a narrative structure, but it isn't much help. It boils down to a bit at the beginning, a bit at the end and a big lump in the middle. Sometimes that will be "Input, process, output", sometimes it will be "initialise, process, tidy-up". Within that big lump the individual parts will often follow the same structure, but not invariably.

On the whole I would say that programs do not have a narrative structure, but their execution has a narrative structure. The program is like a bagatelle board; the ball has a story, the board just supports that story.

Almost all programming languages support a narrative structure of execution, because that's how machine code works on almost all processors, but there are a few exceptions. "Prolog" springs to mind.
User avatar
Moderator
Posts: 2888
Joined: Mon Jan 09, 2012 3:16 pm
by Markx » Mon Dec 17, 2012 4:00 pm
Thanks all, big help. Ruwin that helps a lot.
Posts: 21
Joined: Thu Nov 08, 2012 12:19 pm