Comments on: Help me to write algorithms

Question: Help me to write algorithms

grefo — Sun, 11 Jan 2004 20:33:20 -0800

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.

By: majick

majick — Sun, 11 Jan 2004 21:15:43 -0800

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.

By: five fresh fish

five fresh fish — Sun, 11 Jan 2004 21:26:44 -0800

No, I think he's more wanting the ... thought process of someone who programs. How to think like a programmer. The concept.

By: Aaorn

Aaorn — Sun, 11 Jan 2004 21:43:07 -0800

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*?)

By: namespan

namespan — Sun, 11 Jan 2004 21:54:44 -0800

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

By: holloway

holloway — Sun, 11 Jan 2004 22:11:32 -0800

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).

By: kindall

kindall — Sun, 11 Jan 2004 23:24:40 -0800

Design Patterns.

By: sebas

sebas — Sun, 11 Jan 2004 23:48:34 -0800

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.

By: woil

woil — Mon, 12 Jan 2004 00:58:00 -0800

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.

By: reynaert

reynaert — Mon, 12 Jan 2004 03:35:46 -0800

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).

By: mischief

mischief — Mon, 12 Jan 2004 04:02:41 -0800

One question, grefo, do you have any FORMAL training in writing software? Or, are you self-taught?

By: andrew cooke

andrew cooke — Mon, 12 Jan 2004 05:26:13 -0800

what reynaert said. in spades. with a cherry on top.

By: grefo

grefo — Mon, 12 Jan 2004 06:13:47 -0800

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?

By: seanyboy

seanyboy — Mon, 12 Jan 2004 06:51:28 -0800

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.

By: seanyboy

seanyboy — Mon, 12 Jan 2004 06:56:28 -0800

But here is an example of a Haiku Generator. (Use View-->Source)

By: andrew cooke

andrew cooke — Mon, 12 Jan 2004 07:16:51 -0800

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