How to actually write a program?

[Nick Evans]

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

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

Any ideas about this problem :-)

Ta
Nick

[Dan Sommers]

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_mykewlprog ram.py and begin writing unit
tests. I completely agree in the value of test driven development, but for
someone writing a first program I completely disagree!
He will have to fight both programming in itself, and the test driven
development process. 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 "interestin g" (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.tombstoneze ro.net/dan/>
Never play leapfrog with a unicorn.

[Peter Hansen]

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

[Alex Martelli]

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

[Alex Martelli]

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

[Anna Martelli Ravenscroft]

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

[Max M]

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

[Brian Gough]

"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 "Programmin g 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/

[Alex Martelli]

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

[Peter Hansen]

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

[Alex Martelli]

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