How to actually write a program?

[Dan Sommers]

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.

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

 

[Peter Hansen]

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

 

[Alex Martelli]

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


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

 

[Alex Martelli]

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

 

[Anna Martelli Ravenscroft]

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

 

[Max M]

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

 

[Brian Gough]

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.

 

[Alex Martelli]

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

 

[Peter Hansen]

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

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

 

[Alex Martelli]

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

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

 

[Harry George]

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.

 

[Ville Vainio]

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.

 

[Neil Benn]

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 : (e-mail address removed)
Cenix Website : http://www.cenix-bioscience.com

 

[Carlos Ribeiro]

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: (e-mail address removed)
mail: (e-mail address removed)