How to actually write a program?

N

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
 
J

Jp Calderone

Nick said:
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_mykewlprogram.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
 
P

Peter Hansen

Nick said:
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/detail/-/0321146530/104-0524681-1524713?v=glance

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

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

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

http://www.testdriven.com/

etc...

-Peter
 
P

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

Mike C. Fletcher

This may seem a bit weird:

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

import unittest
import mykewlprogram

class BasicTests( unittest.TestCase ):
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.Frobnitz()

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

class Frobnitz( object ):
"""Frobnitzes 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 said:
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
 
P

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

Johannes Held

Nick said:
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.
:)
 
P

Peter Hansen

Peter said:
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
 
I

Istvan Albert

Peter said:
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.
 
M

Max M

Jp said:
Close the file. Open test_mykewlprogram.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
 
K

Ksenia Marasanova

Any ideas about this problem :)

I dont' know if this is a 'right' approach, but if the program has user
interface, it helps also first to create this user interface. That way
you'll be able to visualize what information your program needs to get
and to send back. It can be easier then to define classes and
methods...

Ksenia.
 
M

Michael Hudson

Nick Evans said:
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 :)

In addition to what others have said, I use the interactive
interpreter A LOT (probably too much; I should write more tests).

Cheers,
mwh
 
V

Ville Vainio

nick> have a possably rough idea of how the program will work. You
nick> have opened an empty text file and saved it as
nick> 'mykewlprogram.py' and now your sitting in front of an empty
nick> text file... Now then.... where do I start.

Typically, a program reads a bunch of data, crunches it and outputs
it. Find a trivial way to get the necessary data into elementary
Python data structures like lists, tuples and dicts (many typical
programs don't need classes at all). Write a function to process that
data, resulting in a bunch of new objects (data
structures). pprint.pprint the resulting objects, and after you are
satisfied with the output, perform the necessary actions according to
the objects. The rest is just chrome.

If you are interested in starting with the chrome (a'la VB), check out
PythonCard (or Boa constructor, or equivalent).
 
P

Peter Kleiweg

Ksenia Marasanova schreef:
I dont' know if this is a 'right' approach, but if the program has user
interface, it helps also first to create this user interface. That way
you'll be able to visualize what information your program needs to get
and to send back. It can be easier then to define classes and
methods...

I disagree. In that case, better to define the data structures
you're program is going to manipulate.
 
W

wes weston

Nick said:
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
Nick,
Open another file and write the story of your program;
why you're writing it, what it does, roughly how it does
it, what it operates on, who uses it, what it produces,
special problems, future considerations; a general
description.

Make another file listing specific things each user
will be able to do; his action and what is produced and
in what form.

By this time you should have an idea of what the
user interface will look like; gui, command line(both),
menu(s).

All things move forward together.

Possibly; code an interface only with all the menus.

Come up with data structures; empty classes with
only documentation and maybe variable names and empty
methods.

Put this at the bottom of every py file:
if __name__ == "__main__":
pass
Most of the time of you do anything to the file, put
a test in and test it here. As new tests are done,
describe them and comment out the last one.

Pick the most risky processe(s) and design/code.
Risky meaning is it doable and will your current
concept get the job done.

Test.

Iterate.

wes
 
N

Neil Benn

Nick said:
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.
<snip>
Hello,

It's good that you are thinking of this rather than just
trying to manically write some code to see what happens. As a general
point, there is a system that you can use to help you model out your
program (taught to most computer science students). This system is
called UML (Unified Modeling Language) - I would advise getting a good
book about UML and reading through that. It's is complementary to the
XP (Extreme Programming) stuff that people are talking about.

However, be aware that some of the concepts assumed in UML don't mix
too well to the 'Pythonic' way of doing things. If you want to have a
try writing some UML here are two systems you can get - there are others
- (I can't remember the links off the top of my head) they are an
OpenSource system called 'ArgoUML' or the community edition of
'Together' from Borland. Personally I prefer Together.

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : +49 (0)351 4173 154
e-mail : (e-mail address removed)
Cenix Website : http://www.cenix-bioscience.com
 
P

Piet

Hello,
now my 2 cents about this topic...
1. Get a good text editor.
When you already sit in front of an empty file, this point is
apparently done ;-)
2. Get a or "the" revision control system. It is freely available for
personal use.
3. Do not start with a program that only accepts input from the
console and sends output to the console, but learn how to handle files
so that you can store the information you fed into your program and
the data you get out.
4. Don´t try to make your code as short as possible, but as readable
as possible. Don´t put too many statements in a single line. Don´t use
too many list comprehensions and stuff like that in the beginning too
frequently.
5. Document your code lines from the very beginning. Don´t leave out
any commenting of your code because in the moment you code it is just
completely clear to you what the code means, is supposed to do and how
it works. It neccessarily won´t be that clear tomorrow.
6. Don´t make your variable names too short. Give them names that
describe what they are, and try to use similar name patterns for
similar variables. Use names that can be unambigously identified by a
search pattern, so that you will find occurences of variables quickly
without too much overhead.
7. Oops, I almost forgot: get a language that can be learned quickly
so that you get your code together without too much head scratching,
but a language that lets you also use advanced concepts when you are
ripe for them. Since you are posting in comp.lang.python, this is
apparently already done as well.
Have fun

Peter
 
P

Peter Hansen

Max said:
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.

I would have thought that the TDD process was *how* one would "fight
programming". Do you have a better way? All the approaches I've
seen in the past were much, much more difficult and less assured
of useful results in a reasonable time.

(Also, as a new programmer, he is unlikely to have to "fight"
TDD, since he doesn't have other approaches to try to unlearn.
I assume unlearning old habits is what you were thinking about,
because TDD itself is so simple that it's not at all hard to
actually follow the 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.

It seems to me the OP was asking *how* to "start coding". Telling
him merely to do so is not likely to help. He already knows he
has to start coding...
Dont Repeat Yourself
====================

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

How does he get any code at all, when he doesn't know how
to start? You can't refactor what doesn't exist.

-Peter
 
P

Peter Hansen

Neil said:
It's good that you are thinking of this rather than just trying
to manically write some code to see what happens. As a general point,
there is a system that you can use to help you model out your program
(taught to most computer science students). This system is called UML
(Unified Modeling Language) - I would advise getting a good book about
UML and reading through that.

Ahhh!! Run! Run, Neil, run! UML!
It's is complementary to the XP (Extreme
Programming) stuff that people are talking about.

Ahhh!!! Run away some more! UML and XP are nearly anti-thetical.
Don't even consider going there. (Well, consider it, but please
don't waste any money buying a UML book as you do. Find a few
web sites, then ... run away! It's cheaper that way.)

In my opinion, if you try to get a beginning programmer to work using
UML when he isn't even sure how to start writing code in an empty
file, you will not have a beginning programmer for long. And I
don't mean because you've just got him over that initial hump...

In another opinion of mine, if you try to get a more advanced
programmer to work using UML, you also deserve whatever you get...

-rabidly-anti-UML-ically y'rs,
Peter
 
A

Alexander Hoffmann

Hello,

Ahhh!! Run! Run, Neil, run! UML!

Please, stay calm ! I recommend you not to run because because UML is nothing
you should fear, but also forget about the UML book FOR THE MOMENT !

Please reflect on your goals. Why do you want to write programs, what are they
meant to be used for in the end ? If you want to write very small programs to
be used like shell scripts on your private Linux box, then never spend your
time with UML, extreme programming, unit tests and all that stuff.
If you plan to write rich featured applications or even deamon processes then
first lean the basic ideas of how to write code. There are lots of tutorials
and books around that help you gain success very quickly. Write some little
apps and watch them doing their job.
When you're done, then take care of how to write bigger programs. Now you
should learn how to design an application, in what parts or modules it should
be implemented and how these modules shall communicate / work together. This
is what you should utilize PARTS of UML for. I strongly recommend you to look
at static structure diagrams, use cases and time line diagrams. The other
parts of UML are only useful in theory, they take much more time to be
created than they will ever save.
Once you are familiar with basic Python programming and with application
design (e.g. UML), then the last step I recommend to become a *nearly* (who
really claims to be completely) perfect developer is to understand the
importance of testing. When you are implementing a real big application you
are lost without it. I am using unit tests and they help me very much. With
these you can test first very small parts of your application and then later
combine the test to cover more and more of the whole program. Indeed there is
no need to argue for unit testing (when writing really big applications): try
it and you will appreciate it !

Regards,
Alex
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,206
Messages
2,571,069
Members
47,674
Latest member
scazeho

Latest Threads

Top