By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,758 Members | 1,225 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,758 IT Pros & Developers. It's quick & easy.

How to actually write a program?

P: n/a
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
Jul 18 '05 #1
Share this Question
Share on Google+
33 Replies


P: n/a
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_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
Jul 18 '05 #2

P: n/a
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
Jul 18 '05 #3

P: n/a
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

Jul 18 '05 #4

P: n/a
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 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

Jul 18 '05 #5

P: n/a
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,en,ia,nds,no,sv,(fr,it) S:NL,de,en,(da,ia)
info: http://www.let.rug.nl/~kleiweg/ls.html

Jul 18 '05 #6

P: n/a
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
Jul 18 '05 #7

P: n/a
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
Jul 18 '05 #8

P: n/a
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.
Jul 18 '05 #9

P: n/a
Jp Calderone wrote:
Nick Evans wrote:
Now then.... where do I start.
Any ideas about this problem :-)


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
Jul 18 '05 #10

P: n/a
> 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.
Jul 18 '05 #11

P: n/a
"Nick Evans" <ni**@huff.org.uk> writes:
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

--
... the U.S. Department of Transportation today disclosed that its
agents have recently cleared airport security checkpoints with an
M1 tank, a beluga whale, and a fully active South American volcano.
-- http://www.satirewire.com/news/march02/screeners.shtml
Jul 18 '05 #12

P: n/a
>>>>> "nick" == Nick Evans <ni**@huff.org.uk> writes:

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

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #13

P: n/a
Ksenia Marasanova schreef:
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...


I disagree. In that case, better to define the data structures
you're program is going to manipulate.
--
Peter Kleiweg L:NL,af,da,de,en,ia,nds,no,sv,(fr,it) S:NL,de,en,(da,ia)
info: http://www.let.rug.nl/~kleiweg/ls.html

Jul 18 '05 #14

P: n/a
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

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

Jul 18 '05 #15

P: n/a
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.

<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 : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

Jul 18 '05 #16

P: n/a
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
Jul 18 '05 #17

P: n/a
Max M wrote:
Jp Calderone wrote:
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.


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
Jul 18 '05 #18

P: n/a
Neil Benn wrote:
Nick Evans wrote:
I have been on and off learning to code ...
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
Jul 18 '05 #19

P: n/a
Hello,

On Tuesday 07 September 2004 01:02, Peter Hansen wrote:
Neil Benn wrote:
Nick Evans wrote:
I have been on and off learning to code ...


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 yes, I know ;-) (Unified Modeling Language) - I would advise getting a good book about
UML and reading through that.


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

Jul 18 '05 #20

P: n/a
On Mon, 06 Sep 2004 18:58:12 -0400,
Peter Hansen <pe***@engcorp.com> wrote:
Max M wrote:
Jp Calderone wrote:
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. 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.)
Also as a new programmer, the OP is as unlikely to know how to write a
test, nor how to write a test that fails, nor how to write the code that
causes the test to pass.

Tests *are* programs. My experience writing tests (in non-TDD
environments) is that the tests are often more "interesting" (as in "may
you live in interesting times") than the programs themselves.
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.
How can he write a test, when he doesn't know how to start to write a
program?

TDD assumes that programmers can write programs.
-Peter


Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.
Jul 18 '05 #21

P: n/a
Dan Sommers wrote:
Also as a new programmer, the OP is as unlikely to know how to write a
test, nor how to write a test that fails, nor how to write the code that
causes the test to pass.
Which is why he was directed to useful links about what TDD
means and how to do it, rather than being told merely to
"write a test". At least, that's the holistic result of
the various responses, as I see it. The Dive In To Python
chapter on unit testing, for example, would tell him all he
needs to know to get started doing TDD (as I recall, from the
last time I read it... I assume it hasn't changed much).
How can he write a test, when he doesn't know how to start to write a
program?
The key is "how to start", not "how to write". Go back to
the OP's words: "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."
TDD assumes that programmers can write programs.


TDD gives people a way of writing programs. Writing
programs makes them programmers. ;-)

-Peter
Jul 18 '05 #22

P: n/a
Peter Hansen <pe***@engcorp.com> wrote:
...
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.


Scott Ambler's "Agile Modeling" is the one attempt to bridge this gap
that I know of -- it's truly an excellent book, and very readable, but I
suspect it will go right over the head of readers who don't have solid
knowledge AND some experience in the field, too.

XP (and to some extent Agile development of all kinds) do prefer to
deliver code (tests, mostly) rather than other kind of development
artifacts, includng most modeling artifacts; Scott (quite an expert at
UML and other modeling techniques, of course) makes an excellent case
for "as little modeling artifacts as you can get away with" but ALSO
that sometime that "little" _DOES_ go all the way to UML. But unless
you've tried different approaches 'in anger', you're unlikely to get
from that excellent book as much as you could if you had.

UML and Agile/XP are typically used in organizations with very different
philosophies and mindsets. They're anything but antithetical
_technically_, but, _culturally_, you're probably right...
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...
On this one, even though I do like modeling, I agree with you 100%. The
right time to learn modeling approaches and technologies is AFTER you
have some experience in simpler kinds of programming, like TDD and other
Agile approaches.

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


I suspect your "anti-ness" comes from cultural and not technical factor.
Basically, injecting some modeling into an Agile culture, just like the
reverse, takes diplomatic talents which very few people possess...
Alex
Jul 18 '05 #23

P: n/a
Alexander Hoffmann <al****************@netgenius.de> wrote:
...
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.
No: unit tests SCALE -- they're just as important and wonderful for tiny
programs as for huge ones. XP is a very specific approach which only
makes sense for a _team_, but tests are universally good.
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
Alistair Cockburn's "Writing Effective Use Cases" suggests excellent
alternatives to UML "use cases", with a strong emphasis on what works.
(Like all books I've seen by Cockburn, it's quite advanced, even though
very readable it's really aimed at people with real-world experience --
much as I've just said elsewhere on this thread of Ambler's books).
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 !


Right -- and you'll appreciate it in SMALL applications just as much,
IMHO.
Alex
Jul 18 '05 #24

P: n/a
On Fri, 03 Sep 2004 21:29:36 +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.


Lots of folks have given some great pointers. I'll pass along what I do,
since I'm closer to your level of programming than some folks here.

I usually start by choosing one very simple piece of "what it does"
and trying to code that. Say I want to be able to do x, y and z. I would
start with just trying to make it do x. (Some folks think in terms of data
structures or objects. In which case, start with just creating a very
simple myfirstobject or mydatastruct1.)

The whole test as you go idea is great - I'm working on automating that
more myself. If the whole automatic unittest thing is too advanced for you
for now, just write down a list of manual tests to try -- what's
*supposed* to happen in ? case, and manually try those each time. Don't
forget to think about "what do I do if user enters n instead of x, y or
z". Eventually, you'll use that same kind of question and answer to code a
unittest anyways, so it's actually good practice on working towards
unittesting.

Anyway, I would create a way to test x (or myobject or mydatastruct1), run
(manually or automagically) the test (which fails at first) and then start
working on trying to make x pass, one case at a time. Once x passes, I can
go on to y...

One other tip: add lots of print statements. Print statements are your
friend. They can help you figure out what it's *actually* doing, (and more
importantly sometimes: what it's *NOT* doing) rather than just what you
hope it might be doing. For example, when you start on defining funcx(a),
you could start by having it just print what you gave it for arguments.
You can always comment out or remove the print statements afterwards.

Anna
Jul 18 '05 #25

P: n/a
Anna Martelli Ravenscroft wrote:
One other tip: add lots of print statements. Print statements are your
friend. They can help you figure out what it's *actually* doing, (and more
importantly sometimes: what it's *NOT* doing) rather than just what you
hope it might be doing. For example, when you start on defining funcx(a),
you could start by having it just print what you gave it for arguments.
You can always comment out or remove the print statements afterwards.


If you intend to use print that way it might be more efficient to write
a special test print function.
def tp(text):
TEST = 1
if TEST:
print text
That way you will only have to set TEST = 0 to avoid printing debug
print statements.

regards Max M
Jul 18 '05 #26

P: n/a
"Nick Evans" <ni**@huff.org.uk> writes:
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.


The books "Programming Pearls" and "More Programming Pearls" by Jon
Bentley have nice examples of this sort of thing.

--
Brian Gough

Network Theory Ltd,
Publishing the Python Manuals --- http://www.network-theory.co.uk/python/
Jul 18 '05 #27

P: n/a
Max M <ma**@mxm.dk> wrote:
Anna Martelli Ravenscroft wrote:
One other tip: add lots of print statements. Print statements are your
friend. They can help you figure out what it's *actually* doing, (and more
importantly sometimes: what it's *NOT* doing) rather than just what you
hope it might be doing. For example, when you start on defining funcx(a),
you could start by having it just print what you gave it for arguments.
You can always comment out or remove the print statements afterwards.


If you intend to use print that way it might be more efficient to write
a special test print function.
def tp(text):
TEST = 1
if TEST:
print text
That way you will only have to set TEST = 0 to avoid printing debug
print statements.


If you went that route, you would be well advised to make tp more
general:

def tp(*args):
TEST = 1
for arg in args: print arg,
print

or possibly even more, including a **kwds which would let you drive such
aspects as suppressing newlines, rerouting output to another file
object, etc, etc.

In practice, I find that I disable and re-enable my print statements
much more selectively than such a function would support, and that when
all is said and done plain old print and adding/removing comment signs
as needed works best for me.
Alex
Jul 18 '05 #28

P: n/a
Alex Martelli wrote:
Peter Hansen <pe***@engcorp.com> wrote:
Ahhh!! Run! Run, Neil, run! UML! ....Ahhh!!! Run away some more! UML and XP are nearly anti-thetical.


UML and Agile/XP are typically used in organizations with very different
philosophies and mindsets. They're anything but antithetical
_technically_, but, _culturally_, you're probably right...


I guess I won't (can't) disagree until I have an idea what
you mean in this case by "technically". On the face of it,
I see little that isn't antithetical about them, technically
or otherwise. Quick (and for the most part throw-away) drawings
on whiteboards would seem to be the preferred Agile/XP solution,
but maybe that's where you bring in "culturally"...
-rabidly-anti-UML-ically y'rs,
Peter


I suspect your "anti-ness" comes from cultural and not technical factor.
Basically, injecting some modeling into an Agile culture, just like the
reverse, takes diplomatic talents which very few people possess...


Again, not sure how to tell the difference. I was working in
a group where we were trying to make effective use of UML
before we ever encountered Agile... in fact, it was in part
due to those experiences that we embraced agility and XP...
And since we managed to get agility into a modeling culture,
I'll assume someone had the necessary talents. I think the
problem lay elsewhere.

-Peter
Jul 18 '05 #29

P: n/a
Peter Hansen <pe***@engcorp.com> wrote:
Alex Martelli wrote:
Peter Hansen <pe***@engcorp.com> wrote:
Ahhh!! Run! Run, Neil, run! UML! ...Ahhh!!! Run away some more! UML and XP are nearly anti-thetical.


UML and Agile/XP are typically used in organizations with very different
philosophies and mindsets. They're anything but antithetical
_technically_, but, _culturally_, you're probably right...


I guess I won't (can't) disagree until I have an idea what
you mean in this case by "technically". On the face of it,
I see little that isn't antithetical about them, technically
or otherwise. Quick (and for the most part throw-away) drawings
on whiteboards would seem to be the preferred Agile/XP solution,
but maybe that's where you bring in "culturally"...


In many cases such drawings will be just fine (and quite a few places in
the past splurged for self-copying whiteboards, though these days the
cheap way to make those sketches durable is a digital camera), but not
in all. Again, Scott Ambler deals with this better than I can hope to
do in a post. Technically, UML is a language, or series of languages,
to express various modeling artifacts. There is nothing in Agile
Development (or even specifically XP) which makes those diagrams'
languages incompatible with agility or extremity, any more than, say,
CRC based alternatives, or any other kind you like.

Let me offer a silly analogy: an XP team might perfectly well decide
that the language for all of their communication will be Latin. There
is nothing technically incompatible between that decision and XP's
practices -- the Vatican has made sure approved Latin terms exist for
all kinds of modern words, they publish a dictionary for the purpose.
It would be _culturally_ unlikely, but there's no technical antithesis.

Clearer now...?

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


I suspect your "anti-ness" comes from cultural and not technical factor.
Basically, injecting some modeling into an Agile culture, just like the
reverse, takes diplomatic talents which very few people possess...


Again, not sure how to tell the difference. I was working in
a group where we were trying to make effective use of UML
before we ever encountered Agile... in fact, it was in part
due to those experiences that we embraced agility and XP...
And since we managed to get agility into a modeling culture,
I'll assume someone had the necessary talents. I think the
problem lay elsewhere.


Ah, a _lapsed_ UML'arian, those are indeed the most rabid ones;-)
Alex
Jul 18 '05 #30

P: n/a
"Nick Evans" <ni**@huff.org.uk> writes:
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


1. This problem comes up even for experienced programmers. You may have
done project planning, data models, UML diagrams, GUI story boards,
test suites, etc. Yet one day you need to mentally shift gears and
actually write code. A more experienced programmer will have done
some prototyping while working out the requirements and specs, but
even then it is a difficult mental transition.

2. For a total novice, get one of the tutorial books (e.g., "Learning
Python" or "The Quick Python Book") and follow through a few of the
examples. Don't do all the examples. All you need from this phase is
confidence that you can write working code, and general awareness of
the existence of language features. ("Yep, I know Python has
exceptions. Don't know how they work exactly, but I know they are
there.") You can learn the details when you need them.

Traditionally this exercise is done as a "hello, world" program, with
gradually increasing complexity as you tack on more and more language
features. It can be the most frustrating program to write in any
language. The problems are mostly "stupid mistakes" -- that is a
normal part of learning new languages. [It is also a normal part of
advanced programming, which is why test suites and peer reviews are so
powerful.]

3. Once you can do "hello, world" stuff, then tackle your project.
Assume your first effort will be a bad design, so plan to
"write one to throw away".

Even if the app eventually is a GUI app, start with a batch processing
approach. Do this by doing a reader/writer process around the data
model. The "model" (from model-view-controller) is a class with a few
attributes. The controller is a class that has a sequence of those
class objects, a method to read an input file to load that sequence,
and a method to write the sequence back out.

In fancier settings, there might be persistence via a database or
pickle, or the input and output may be XML or csv. But for starters,
just use a line-per-record file with ":" field separators.

4. Once the "model-controller" is working, it is time to set up a
proper project. One approach is my mkpythonproj at:
http://www.seanet.com/~hgg9140/comp/index.html

However you do it, you need a project with documentation, testsuites,
and a setup.py for sdist tarballs. Put it under config control (e.g.,
cvs or svn). You may want to factor out the "model" and "controller"
to separate modules. You are also ready to read good code examples,
so scan "Python Cookbook" and other resources.

Once the project is established, you can begin adding more complexity
to the "model". More classes, more attributes, more interlationships,
edit routines, etc. Maybe add more import/export mechanisms (pickle,
csv, XML, etc.).

5. If there is to be a gui ("view"), storyboard (sketch on paper) a
few of the dialogs you will need to drive the "controller" methods.
Assume 1 dialog per model class, plus a tree or list widget
representing the controller's sequence or dictionary of data.

You must decide which toolkit to use. Tkinter, wxPython, PyQt,
PyGTK are the main contenders. Now, set aside all the work you've
done so far and concentrate on learning the GUI toolkit. Get a main
window working, with menus, file open/close, exit. The file
open/close of course call the file reader/writer you already have
working.

Next build a dialog to edit one of the classes, using the same edit
routines you have already developed. Hook the dialog to the "edit"
submenu.

Tag the release in your config control system, and make a tarball
(version 0.1).

6. By now you have a much better grasp of the project, the language
and the available libraries. It is time to rethink the project.

Print out the code ("enscript --line-numbers --landscape" is a good
choice). Read it.

Do this mental exercise: You have an opportunity to work on a
wonderful new project, if only you can train a replacement for
maintaining the current project. If you fail to train the
replacement, of if they leave in disgust, you are doomed to maintain
your own code forever. What can be done to make the handoff painless?
Refactor? More systematic approach to method naming? Better
"developer's guide" documentation? Move hard-coded values to tables,
config files, dictionary lookups?

I find that on some projects, I can fix the code in situ. Most times,
I just make a whole new project and start fresh. Either way, the
target is code clean enough to be a pleasure to read and maintain.


--
ha************@boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: (425) 342-0007
Jul 18 '05 #31

P: n/a
>>>>> "Peter" == Peter Hansen <pe***@engcorp.com> writes:

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

There should really be a pythonic alternative to UML. I'm talking
about a textual format that can be rendered to pretty graphical
diagrams for PHBs/project managers to drool at. Text format would be
easy to edit with just an editor, it would be version-controllable,
scriptable, blah blah. I bet a lot of anti-UML attitude can be
attributed to the clumsy, non-programmery process that manipulating
UML images graphically involves.

I'd like to "draw" sequence diagrams like:

object user, slot,sensor, beeper

user - slot insertCoin(0.20)
slot - sensor report(1,0.20)
sensor - beeper trigger()
user - slot insertCoin(0.20)
...

etc.

Then I could easily insert new stuff retroactively by just editing the
file, without having to load the thing into some horrible bloated
expensive peace of (krhm) software that breaks the image into
irrepairable mess by just having the user click on the wrong widget.
--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #32

P: n/a
Ville Vainio wrote:

There should really be a pythonic alternative to UML.

<snip>
Hello,

I've not commented about my original UML post because I didn't
want to start a row about UML. However I do like your idea of a simpler
cleaner UML to allow to go back and forth without needing a full blown
UML case tool. The thing I really like about this is that you could
write this and easily convert it into your source code (if round-trip
engineering yanks your chain) or to XMI so it can be exported/imported
from/to other systems. I'm gonna have a go at writing one of my designs
(sequence is easy - class would be more difficult) down in a pure way to
see if I can get it to be readable, clean and obvious.

On the XP side, sorry but I do think that the two really do go hand
in hand - every XP programmer will have an overall idea of how the
system works (on paper or in head), if it is a team of programmers then
you will have a design written down somewhere (or how do you all work
together). In addition, every UML 'round-trip' enthusiast will have
some tests in their code - it may not be as rigorous as XP but they will
have tests.

To my mind the best solution is to have both systems - trying to
understand a large 'enterprise' class system without UML can be a real
pig. If I have the class diagram(s) with supporting sequence diagrams
then I can easily work out how it all fits together. If I have the
tests written for me then I can run the tests for each module of the
system and investigate the behavior under the various conditions as laid
out in the requirements specification.

One other thing about XP, tests are also excellent for the
maintainability of code, running the tests on all code in your source
repository (at midnight, when else!!) and reporting back the errors
really allows you to keep a hold on your body of source code.

Anyway my new laptop with an English (read British, the pound -
currency - sign is proudly sitting above the 3 where it should be!)
keyboard has just turned up so I'm gonna have a play!!

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 : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

Jul 18 '05 #33

P: n/a
On Wed, 08 Sep 2004 10:22:06 +0200, Neil Benn <be**@cenix-bioscience.com> wrote:
Ville Vainio wrote:
There should really be a pythonic alternative to UML.


For some reason I could not find the original post, but I'll second
that. UML is good, but for some reasons I couldn't find good tools to
support productive Python programming using UML. It's actually a big
quest -- the entire toolset ranges from solid (and standard) DB
support to two-way UML engineering tools -- but the main problem for
me is the lack of a common idiom to express some of the business
abstractions in Python. Each and every package assumes a different way
to write or structure the code. This is of no help.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #34

This discussion thread is closed

Replies have been disabled for this discussion.