How to actually write a program?

[Nick Evans]

Hello there,
I have been on and off learning to code (with python being the second
language I have worked on after a bit of BASIC). What I really want to know
is, if you are going to actually write a program or a project of some sort,
how do you actually start.

Picture this, you know what you want the program to do (its features), you
have a possably rough idea of how the program will work. You have opened an
empty text file and saved it as 'mykewlprogram. py' and now your sitting in
front of an empty text file... Now then.... where do I start.

Any ideas about this problem :-)

Ta
Nick

[Jp Calderone]

Nick Evans wrote:

Hello there,
I have been on and off learning to code (with python being the second
language I have worked on after a bit of BASIC). What I really want to know
is, if you are going to actually write a program or a project of some sort,
how do you actually start.

Picture this, you know what you want the program to do (its features), you
have a possably rough idea of how the program will work. You have opened an
empty text file and saved it as 'mykewlprogram. py' and now your sitting in
front of an empty text file... Now then.... where do I start.

Any ideas about this problem :-)

Close the file. Open test_mykewlprog ram.py and begin writing unit tests.

http://www.extremeprogramming.org/

The answer is much larger than this, of course. So large I'm not
even going to try to answer it more fully. :)

Jp

[Peter Hansen]

Nick Evans wrote:

Hello there,
I have been on and off learning to code (with python being the second
language I have worked on after a bit of BASIC). What I really want to know
is, if you are going to actually write a program or a project of some sort,
how do you actually start.

Picture this, you know what you want the program to do (its features), you
have a possably rough idea of how the program will work. You have opened an
empty text file and saved it as 'mykewlprogram. py' and now your sitting in
front of an empty text file... Now then.... where do I start.

Any ideas about this problem :-)

Sure, first you write a test. Then you run it and make sure it fails
(because of course no other code exists yet). Then you write just
enough code to pass the test. Run the test again, and get it to
pass. Clean things up and go back to the start...

http://diveintopython.org/unit_testing/

http://c2.com/cgi/wiki?TestDrivenDevelopment

http://www.amazon.com/exec/obidos/tg...24713?v=glance

http://www.objectmentor.com/writeUps...venDevelopment

http://www.agiledata.org/essays/tdd.html

http://groups.yahoo.com/group/testdrivendevelopment/

http://www.testdriven.com/

etc...

-Peter

[Phil Frost]

How does a composer write a song? He might know the overall sound of the
song, so he might start by playing it on a piano. Then he might work on
the strings part, and a general chord progression. Then add some
woodwinds, building the song piece by piece until all the small parts
are assembled to a greater whole.

Writing a program is no different. You must first break your song in to
parts. It's a highly creative process, and it's not something that can
be taught. Find yourself a nice, quiet room, and a time when you arn't
distracted by anything. Think of the greater problem and try to divide
it into smaller pieces. This division is the hardest part of
programming; expressing the ideas in code becomes as natural as speech
with practice. After some reflection your path should become clear.

On Fri, Sep 03, 2004 at 09:29:36PM +0000, Nick Evans wrote:

Hello there,
I have been on and off learning to code (with python being the second
language I have worked on after a bit of BASIC). What I really want to know
is, if you are going to actually write a program or a project of some sort,
how do you actually start.

Picture this, you know what you want the program to do (its features), you
have a possably rough idea of how the program will work. You have opened an
empty text file and saved it as 'mykewlprogram. py' and now your sitting in
front of an empty text file... Now then.... where do I start.

Any ideas about this problem :-)

Ta
Nick

[Mike C. Fletcher]

This may seem a bit weird:

Create another text file and save it as test_mykewlprog ram.py. Add
the following to it:

import unittest
import mykewlprogram

class BasicTests( unittest.TestCa se ):
def test_something( self ):
"""Do some basic test of functionality"" "

if __name__ == "__main__":
unittest.main()

And run that from the command line. If the unit-test passes (it
should), then add some more code to it until it doesn't pass, then
fix your program to make it pass, then immediately go back to
writing unit tests. For instance:

def test_something( self ):
"""Can we create an instance of our frobnitz?"""
mykewlprogram.F robnitz()

which should fail, because you haven't defined a Frobnitz class
yet. So you simply define it in mykewlprogram as:

class Frobnitz( object ):
"""Frobnitz es are responsible for killing Whirlygigs"""

then run your test suite again. It should now pass, so go back to
writing code that tests to see if your program does what it's
supposed to do.
That (called test-driven development) works very well if you've got a
general idea of what you want to do, and your project is not about user
interface design or the like (where test-driven development can be quite
messy).

There are lots of other ways to do it. I was originally taught a method
that was taught in the very early days of computers wherein you figure
out the whole program in your head/on paper, running it in mental
emulation until you're sure you've figured out the major features of the
program. It tends to impress the heck out of certain people (you have
to be able to hold entire complex systems in your head to do it, and
that takes a lot of practice that most people have never mastered),
really speeds up planning meetings, and you can do it in the shower, in
bed, while cooking, etceteras, but it's a lot less common these days.
It's also pretty slow and error-prone :) .

True enlightenment lies somewhere between the extremes. There's
hundreds (thousands?) of books that purport to show you the
one-true-solution to this problem. Any time you see that you can be
pretty sure that there is no "one" solution and that you'll have to
experiment with the ideas expounded by the various religions and figure
out what works *for you*.

Have fun,
Mike
Nick Evans wrote:

Hello there,
I have been on and off learning to code (with python being the second
language I have worked on after a bit of BASIC). What I really want to know
is, if you are going to actually write a program or a project of some sort,
how do you actually start.

Picture this, you know what you want the program to do (its features), you
have a possably rough idea of how the program will work. You have opened an
empty text file and saved it as 'mykewlprogram. py' and now your sitting in
front of an empty text file... Now then.... where do I start.

Any ideas about this problem :-)

Ta
Nick

_______________ _______________ _______________ ___
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com

[Peter Kleiweg]

Mike C. Fletcher schreef:

That (called test-driven development) works very well if
you've got a general idea of what you want to do, and your
project is not about user interface design or the like (where
test-driven development can be quite messy).
I got a lot of programming experience, but not with user
interfaces.
There are lots of other ways to do it. I was originally
taught a method that was taught in the very early days of
computers wherein you figure out the whole program in your
head/on paper, running it in mental emulation until you're
sure you've figured out the major features of the program.
This is how I often work, though I may not work out all the
tiniest details in my head.
It tends to impress the heck out of certain people (you have
to be able to hold entire complex systems in your head to do
it, and that takes a lot of practice that most people have
never mastered), really speeds up planning meetings, and you
can do it in the shower, in bed, while cooking, etceteras, but
it's a lot less common these days. It's also pretty slow and
error-prone :) .

I am a good programmer. On the other hand, I'm a lousy software
develloper. It took me a while to realise that those are two
very different things. I can write programs that do very nifty
things, but if I have to rework it so people who don't know what
it is about can use it, then I get stuck. Structuring it,
putting all things together in a sensible way, making it
accessible through a graphical user interface, which of course
has to run on Windows, while I work on Linux... not my cup of
tea. At least, discovering Python gives me the hope I might be
able to manage more large scale applications.

I have been doing it the hard way, programming C with only
Emacs, no integrated software development platforms. This makes
for very efficient and powereful tools, running directly from
the command line (encouraged by using Linux), but you can only
go so far.

I started programming twenty years ago, with GW-Basic and
assembler. Later C, Prolog, Oberon (briefly), PostScript,
Tcl/Tk, JavaScript, Perl, ELisp, R. For me, the question is not,
how do I start programming, but how do I become a software
devellopper. I have peeked at wxPython and Boa Constructor, and
feel like a beginner, like I know nothing about writing
software.

--
Peter Kleiweg L:NL,af,da,de,e n,ia,nds,no,sv, (fr,it) S:NL,de,en,(da, ia)
info: http://www.let.rug.nl/~kleiweg/ls.html

[Johannes Held]

Nick Evans wrote:

Now then.... where do I start.
Any ideas about this problem :-)

I'm a class freak!
So, the first thing I ever type is:
"class KewlClass:"
Then I go back - wirte the imports and go on reading the docs how to use
them.
:-)

--
Gruß, Johannes
www.hehejo.de

[Peter Hansen]

Peter Kleiweg wrote:

I have been doing it the hard way, programming C with only
Emacs, no integrated software development platforms. This makes
for very efficient and powereful tools, running directly from
the command line (encouraged by using Linux), but you can only
go so far.
I disagree. I do development the same way, after years of
trying out a variety of fancier and fancier GUI IDE RAD
things which in the end primarily served to lock me into
the vendor's tools and didn't really improve my productivity.

Now I do everything with Scite and the command line, with
very rare side trips to use "import pdb; pdb.set_trace() ".
That's whether I'm doing GUI work, web work, realtime
embedded software in C or assembly, network programming,
multithreaded stuff, or anything else.

I'm more productive than I've ever been and I haven't yet
found a limit to how far I can go with this combination,
now that I'm using test-driven development and lots of
other practices from XP.
I started programming twenty years ago, with GW-Basic and
assembler. Later C, Prolog, Oberon (briefly), PostScript,
Tcl/Tk, JavaScript, Perl, ELisp, R. For me, the question is not,
how do I start programming, but how do I become a software
devellopper. I have peeked at wxPython and Boa Constructor, and
feel like a beginner, like I know nothing about writing
software.

My advice to someone starting out, like the OP, or to
someone who has 20 years under his belt is the same.
If you want to be a good software developer, start
to look at the ideas coming out of the agile development
movement, and focus more attention on test-driven
development than on anything else. It alone will
revolutionize the software industry.

-Peter

[Istvan Albert]

Peter Hansen wrote:

I disagree. I do development the same way, after years of
trying out a variety of fancier and fancier GUI IDE RAD
things which in the end primarily served to lock me into
the vendor's tools and didn't really improve my productivity.

IMO it all comes down to the way programs are structured.

I don't need a RAD anymore because I spend a lot of effort
to make the classes and methods generic and simple.
I try to do only one thing in any given place.
It is very easy to troubleshoot an error caused by a
ten line method. (Disclaimer: As nice as this sounds
it usually does take a good number of rewrites to achieve
this)

But I can afford this only because as Arnold would say it:
'I werk alone', I have full control over every aspect of
the programs that I need to develop. If substantial parts of
a working program need a rewrite for no other reason
but to simplify them it is just my call.

If that were not true, when one works in a team where
different people have different ideas, methodologies
and affinity towards a rewrite the productivity
gains that come from RAD environments are much more pronounced.

Istvan.

[Max M]

Jp Calderone wrote:

Nick Evans wrote:

Now then.... where do I start.
Any ideas about this problem :-)

Close the file. Open test_mykewlprog ram.py and begin writing unit tests.

I completely agree in the value of test driven development, but for
someone writing a first program I completely disagree!

He will have to fight both programming in itself, and the test driven
development process.

There is a big difference in learning to program, and in programming itself.

You should simply start coding! Solve problems as you go along. The most
important thing is to allways be aware when something is repeated.

You should focus on the DRY principle.

Dont Repeat Yourself
=============== =====

If you have written a similar piece of code 3 times, you should refactor
it into a function.

You don't state if you know object oriented programming, but if you
don't, you should read up in it while writing your program.

Then try to solve your problems with objects.

Also read some good books about programming. Stuff like "The Pragmatic
Programmer" & "Code Complete"

On your next program you should then start writing unittest...

regards Max M