January 11, 2004

8:33 PM

Can anyone suggest a book, website, etc. that describes the process of breaking a problem down in order to write a program. I have struggled for far too long trying to figure out how to write a program from scratch only to be stumped by the logic involved.

This question, I think, is outside of a specific language or philosophy (Java, OOP, et al.). It's just something I haven't been able to get my head around.
posted by grefo to (15 comments total)

I'm sort of grasping, here, but I think perhaps you are talking about requirements analysis, which is generally considered to be one of the more important parts of the initial discoery phase of any project and the place from which functional requirements come.

Perhaps a little time spent reading about functional requirements and use cases could be enlightening.

Be forewarned, though, that the fields of software architecture, analysis, and design are shot through with jargon, a cultish devotion to overdefined analysis processes, and heavy on theory -- typically with very little emphasis on getting things into code. See The Software Engineering Institute as an example.
posted by majick at 9:15 PM on January 11, 2004

No, I think he's more wanting the ... thought process of someone who programs. How to think like a programmer. The concept.
posted by five fresh fish at 9:26 PM on January 11, 2004

I'm not finding any great web pages on this right now, but the programming textbooks I've seen generally offer some sort of discussion of "top-down vs. bottom-up" methods of going from a stated problem to a program.

In a nutshell, "bottom-up" means you start by writing code for all the most basic concievable parts of your program, and then the next layer of code that uses those basic functions, and then more advanced pieces, and so on. "Top-down" is just the opposite: figure out a general framework for the program, but leave out the small functional pieces and fill them in later, after the "big picture" is complete. (Think of top-down like writing an outline.)

Most books will tell you that which approach you take toward breaking down a problem is just a matter of personal preference. You might not even find it to be a meaningful or useful distinction -- I know plenty of programmers who consider that discussion a waste of time in CS classes.

Wherever you stand, the best way to get into a programming mindset is to practice. Take devices you're familiar with -- for example, an alarm clock -- and think through how to implement them as a program. What functions and variables does it need? What would make sense as an object, and what would the methods of that object be? (i.e., what does each object need to *do*?)
posted by Aaorn at 9:43 PM on January 11, 2004

Two possible approaches:

(1) Study code that does something you might find interesting. What with the number of "cookbooks" that exist out there in addition to free script repositories, this shouldn't be too hard to find.

(2) Pick up an introductory college programming textbook... Thinking in Java maybe. Or Thinking in Python.

What you really need to do is learn to familiarize yourself with data structures and algorithms as tools. #1 will help you do it largely by practical example. #2 will help you do it by giving yousome background in the underlying theory, some toy examples, and some exercises to help. :)



So
posted by namespan at 9:54 PM on January 11, 2004

Just so you know the functional requirements and use case method is one way, and XP is another (which I use, and I hate the name, as does everyone).
posted by holloway at 10:11 PM on January 11, 2004

Design Patterns.
posted by kindall at 11:24 PM on January 11, 2004

If you are talking about modelling (processes in a application, etc) than UML might be a starting point.

However if you want to get in the mindset of someone who programs I would suggest to download Java, set a task for yourself in a weekend (eg. write an application) and up your caffeine levels to maximum. At 4 am on Monday morning you will feel like any other programmer.
posted by sebas at 11:48 PM on January 11, 2004

The design patterns book recommended by kindall is excellent. It may not be exactly what you're looking for but basically is a collection of common types of problems in the software engineering field and common solutions to those problems. While your problem may not fit exactly into one of these, this book my help you think along the lines needed to find the proper solution. Again: highly recommended.
posted by woil at 12:58 AM on January 12, 2004

I've got a feeling that you don't want something about UML or design patterns but rather something like How to Design Programs (the full book is available online).
posted by reynaert at 3:35 AM on January 12, 2004

One question, grefo, do you have any FORMAL training in writing software? Or, are you self-taught?
posted by mischief at 4:02 AM on January 12, 2004

what reynaert said. in spades. with a cherry on top.
posted by andrew cooke at 5:26 AM on January 12, 2004

You folks are great! I haven't been able to read through all the links yet, but "How to Design Programs" looks exactly like what I am looking for.

To answer mishief's question, no, I have no formal training. Completely self-taught, if I really know programming at all, heh.

To better define what I am/was looking for, how 'bout an example? Let's say I want to make a program that composes haiku from a list of words. I know the rules for haiku, but now what? Great example, huh?
posted by grefo at 6:13 AM on January 12, 2004

Let's say I want to make a program that composes haiku from a list of words.
Nothing like a non-trivial example to start you off. The example you've given is actually quite hard, and probably not the sort of thing to jump straight into.
posted by seanyboy at 6:51 AM on January 12, 2004

But here is an example of a Haiku Generator. (Use View-->Source)
posted by seanyboy at 6:56 AM on January 12, 2004

some raw material for deciding how much language affects how you write a program here.

disclaimer: the haskell version, in all it's declarative, class-using glory (or not), is mine
posted by andrew cooke at 7:16 AM on January 12, 2004