type checking

[sashan]

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

[Jules Dubois]

On Sun, 12 Oct 2003 15:56:19 +1300, in article
<bm**********@lust.ihug.co.nz>, sashan wrote:

[...] The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time.
Ask yourself how much static type-checking costs you versus how much
dynamic type errors cost you. If your answer demands static type-checking,
Python is not a good choice for you.
Any advice about
how to get around this would be appreciated.

Python, Smalltalk, and other languages are designed without static
type-checking. Getting around this kind of design decision can be
exceptionally difficult or impossible.

[Stephen Horne]

On Sun, 12 Oct 2003 15:56:19 +1300, sashan <ma***@operamail.com>
wrote:

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

Personally, I find that I rarely make these errors in Python. Having
the right datatype is in any case no guarantee of having the right
value.

In Python, bugs are primarily avoided by writing clear code (so that
it is hard to make non-obvious errors) and detected by testing (which
is the only approach that checks whether the requirements are met).

There are also alternative self-consistency checking schemes such as
design-by-contract that may work well for you, though they do operate
at run time rather than compile time.

If you really do need static typing (as opposed to simply needing to
get used to the change), Python is simply the wrong choice of
language. Either Java, C# or Delphi may be a good option for you.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Donn Cave]

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
....
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

Donn Cave, do**@drizzle.com

[Terry Reedy]

"sashan" <ma***@operamail.com> wrote in message
news:bm**********@lust.ihug.co.nz...

I'm a Python newbie. I have been using c++ for 5 years and before that I was programming in Pascal. The one thing that annoys me about python is dynamic typing because I find myself making typographical errors of the sort that would under C++ be picked up by the compiler at compiler time.
I am beginning to realize that different people probably have
different typo 'profiles', so that I missed typing checks less than I
'missed' writing type declarations (which are another opportunity for
error ;-).
With Python I have to wait for the error to appear at runtime in
order for me to correct it.
In my experience with small functions and programs, Python error
reports come about as fast or faster as C error reports did a decade
ago. Syntax
errors get reported at compile time for Python also.
I find this inefficient. Any advice about
how to get around this would be appreciated.

I suspect that people sometimes became dependent on the system they
use finding the errors it is good at finding, and become a bit
careless with respect to that type of error and focus proofreading on
others that that system is less good at finding. I probably worry
less about syntax errors with Python than I did with Fortran on
punched cards (and an hour or more of turnaround time).

Terry J. Reedy

[F. GEIGER]

"sashan" <ma***@operamail.com> schrieb im Newsbeitrag
news:bm**********@lust.ihug.co.nz...

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

Use pychecker for that. It really helps to find typos.

Cheers
Franz GEIGER

[Miki Tebeka]

Hello sashan,

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

I'll think you'll find dynamic typing saving you time. See
http://www.mindview.net/WebLog/log-0025 for more details.

pychecker does dome checking, but it can't find all the errors that a
statically typed language compiler will find.

IMO the best practice in dynamically typed language is to spend some
of the time you've saved on writing an extensive testing framework.
This will catch much more bugs (including logical ones) that no
compiler will ever catch. See PyUnit for a good framework.

HTH.
Miki

[sashan]

I am beginning to realize that different people probably have
different typo 'profiles', so that I missed typing checks less than I
'missed' writing type declarations (which are another opportunity for
error ;-).


I suppose that's one way of looking at it. At least I'm not having to
correct both the function signature in the header in implementation file.

I suspect that people sometimes became dependent on the system they
use finding the errors it is good at finding,

I think this is my situation at the moment.

[sashan]

Donn Cave wrote:

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
...
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

Donn Cave, do**@drizzle.com

If it was practical I'd use OCaml or Haskell but they don't have the
external libraries I need.

[Alex Martelli]

sashan wrote:

Donn Cave wrote:

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
...
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

Donn Cave, do**@drizzle.com

If it was practical I'd use OCaml or Haskell but they don't have the
external libraries I need.

http://ocamlffi.sourceforge.net/

SWIG also suppors OCaml since 1.3.14 (haven't tried that out).
Alex

[Alex Martelli]

Donn Cave wrote:

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
...
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

I'd like to second Donn's recommendation and express reservations
on Stephen's. Java &c just don't have a high enough semantic level
to give you the same productivity as Python. The languages Donn
lists *DO* (well, I haven't actually tried out Clean, but it looks to me
as if it does). O'CAML in particular is multi-paradigm, a bit rambling, and
perhaps not with the most elegant syntax -- sort of like C++ in these
respects -- but, also like C++ (and Python) takes a LOT of care to
practically FIT IN with your need for solution (e.g. SWIG supports it
to ease interfacing external C=coded libraries). And the base paradigm
of O'CAML is statically typed (even too strict maybe, if you still have to
write +. instead of just + when you're summing floats...) AND very high
level (functional). Haskell is even more mind-expanding and much more
elegant, though perhaps its practicality is (sigh) lesser. Standard ML may
be a bit in-between, perhaps (don't know it as well as the others).

In the end, if you're REALLY keen for static typing you owe it to yourself
to try the real thing, rather than the semi-strict Java &c approaches. If
you're looking to learn, Haskell is hard to beat; if to get practical
solutions to problems, O'CAML may be better. Python is IMHO wonderful
if you DON'T make a fetish of static typing (you might want to try Erlang
for pure functional programming without static typing, btw).

Many of us who used to revere static typing (e.g., Robert Martin, well
noted consultant and author, former editor of C++Report) are on record
as having acknowledged that dynamic typing in fact works better for us.
It just took us a few years to realize this, and vast experience with both
kinds of languages.

If your mind is shaped differently from ours, so that static typing DOES
work better for you even after you've thoroughly familiarized yourself with
a good dynamic-typing language, then moving to a good static-typing
language may indeed be the best strategy for you -- and today's wealth
of choices means no practical restrictions need stop you from doing that.
Alex

[Stephen Horne]

On Sun, 12 Oct 2003 10:42:12 GMT, Alex Martelli <al*****@yahoo.com>
wrote:

Donn Cave wrote:

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
...
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

I'd like to second Donn's recommendation and express reservations
on Stephen's. Java &c just don't have a high enough semantic level
to give you the same productivity as Python.

I suggested C# - _not_ C. That is a very different thing. C# is
probably slightly higher level than Java - though not in Pythons
league, of course.

I made the suggestions I did mostly because I know each of those
languages has a rich set of libraries available. I am far less certain
of the extent of the libraries for functional languages as on the
whole I've only played with them.

A good language can mean big gains, but not necessarily as big as
someone else having written key parts of your application for you in
the form of libraries - and testing them too.

So that, to me, is a key question - which (functional or other)
languages have the richest and most mature libraries (obviously
relevant to sashans requirements), and how do they compare to those
available in Python on the one hand, or Java, C# etc on the other.

An additional issue is familiarity - if sashan is having a hard time
adapting to Python, I suspect he'll find functional languages require
an even bigger paradigm shift. Java and C# require relatively few
mindset adjustments relative to C++.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Carl Banks]

sashan wrote:

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

Sashan, it seems that what you are looking for is not static typing,
per se, but declarations. Here's an old post I made about a trick
where you can declare variables, and have the function throw an
exception if there are any undeclared locals:

http://tinyurl.com/qnmc

It does not declare types, but it catches typos. You might want to
use it to help you transition to Python. However, if you're still
using Python a few months from now (likely :), I bet you'll have
adapted to Python's implicit variable declarations.
--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

[Alex Martelli]

Stephen Horne wrote:
...

| language. Either Java, C# or Delphi may be a good option for you.

...I'd like to second Donn's recommendation and express reservations
on Stephen's. Java &c just don't have a high enough semantic level
to give you the same productivity as Python.
I suggested C# - _not_ C. That is a very different thing. C# is

Sure. "&c" stands for "etc", in this context "and all the others [which
you had mentioned]".
A good language can mean big gains, but not necessarily as big as
someone else having written key parts of your application for you in
the form of libraries - and testing them too.
Definitely. But SWIG often helps a lot -- if the library's around for C,
it's not far from your favourite SWIG-supported language.
An additional issue is familiarity - if sashan is having a hard time
adapting to Python, I suspect he'll find functional languages require
an even bigger paradigm shift. Java and C# require relatively few
mindset adjustments relative to C++.

True, they're closer to C++ in many respects than Python is (except
that Python, like C++, is multi-paradigm, has multiple inheritance,
allows operator overloading, lets you pick and choose among GUI
toolkits rather than coming with one, etc -- but probably not the kinds
of things one will have most "mindset adjustments" about).

By the same token, Java and C# will give few benefits if you already
master C++ -- perhaps a little help with memory management to be
offset against losing templates, a HUGE loss to adjust to, and such
niceties as the "resource allocation is construction" idiom. If one
masters C++ and is looking for productivity higher enough to matter,
Python (or other similar VHLLs) and FP languages are much more
likely to produce it than Java or C# are.
Alex

[Anand Pillai]

I consider Python as high-level psuedo-code. It helps me in
programming, since you dont make mistakes while writing
psuedo-code. So it follows by induction that you dont make
these mistakes like static type errors while programming python.

It is a different approach, by altering your thinking, rather
than relying on tools. Works for me ;-)

Write python program as you would write a flow chart or psuedo-code.
The language constructs are so damn intuitive that it allows you
the freedom to do so.

In the second iteration you can do type checking by perhaps
using the built-in 'type' meta call.
-Anand

sashan <ma***@operamail.com> wrote in message news:<bm**********@lust.ihug.co.nz>...

Donn Cave wrote:

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
...
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

Donn Cave, do**@drizzle.com

If it was practical I'd use OCaml or Haskell but they don't have the
external libraries I need.

[Stephen Horne]

On 13 Oct 2003 00:50:18 -0700, py*******@Hotpop.com (Anand Pillai)
wrote:

I consider Python as high-level psuedo-code. It helps me in
programming, since you dont make mistakes while writing
psuedo-code. So it follows by induction that you dont make
these mistakes like static type errors while programming python.

It is a different approach, by altering your thinking, rather
than relying on tools. Works for me ;-)

While I agree that most likely sashan needs a change of mindset rather
than a language with static typing, this is an unrealistically
impressive claim.

There is no context where I do not sometimes make mistakes, including
pseudocode.

Of course errors do tend to be much rarer in Python, mainly because I
am concentrating on the program logic, rather than being distracted by
the overheads of the language.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Stephen Horne]

On Sun, 12 Oct 2003 20:27:50 GMT, Alex Martelli <al*****@yahoo.com>
wrote:

Stephen Horne wrote:
...

| language. Either Java, C# or Delphi may be a good option for you. ...I'd like to second Donn's recommendation and express reservations
on Stephen's. Java &c just don't have a high enough semantic level
to give you the same productivity as Python.
I suggested C# - _not_ C. That is a very different thing. C# is

Sure. "&c" stands for "etc", in this context "and all the others [which
you had mentioned]".

Sorry - I wasn't aware of that abbreviation.

A good language can mean big gains, but not necessarily as big as
someone else having written key parts of your application for you in
the form of libraries - and testing them too.

Definitely. But SWIG often helps a lot -- if the library's around for C,
it's not far from your favourite SWIG-supported language.

Good point. Having heard of but never used SWIG, it's not something
that I had considered.
By the same token, Java and C# will give few benefits if you already
master C++ -- perhaps a little help with memory management to be
offset against losing templates, a HUGE loss to adjust to, and such
niceties as the "resource allocation is construction" idiom.

Yes, that is very true. I believe MS are adding generics to C#, but
with such big changes being planned that just rubs in the fact that C#
is an immature language resting on an immature library.

I had assumed that the "resource allocation is construction" idiom
could be applied in any language with both constructors and
exceptions. There are only two issues that I can think of that would
seriously affect it...

1. If the language still tries to call a destructor for an object
when its constructor raised an exception.

2. The lack of automatic destruction of member and base components of
an object if a later part of the objects constuctor propogates an
exception.

3. If the libraries do not consistently apply the idiom.

I assume it's mainly the second and third part where this is an issue.

It hasn't really been an issue so far, but I guess C# constructors
should be written so that they never propogate an exception - the
object should always be constructed in a self-consistent state even if
that state flags an error. Which immediately defeats the whole point
of exceptions.

I guess this might be less serious in a language with full garbage
collection - member fields which were initialised will still get
garbage collected, for instance, and any resources they reference will
get freed when that happens. But that seems like a dangerous system to
rely on. For instance, what happens if you need to access one of those
resources before the GC frees it.

This is one issue I already have with Java/C# style garbage collection
- if you need to ensure that resources are available when needed, you
still end up doing explicit 'deletes' anyway. Fortunately, it's only
in this particular case when that becomes impossible.

In Python, it doesn't seem to be an issue - presumably because Pythons
garbage collection is based on reference counting so destruction
happens immediately when the last reference has gone. I'm not sure
what happens when there are reference cycles, though - I know Python
handles them, but I'm not sure if they delay the garbage collection.

Hmmm - a thought provoking issue. Thanks for pointing it out.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Alex Martelli]

Stephen Horne wrote:
...

By the same token, Java and C# will give few benefits if you already
master C++ -- perhaps a little help with memory management to be
offset against losing templates, a HUGE loss to adjust to, and such
niceties as the "resource allocation is construction" idiom.
Yes, that is very true. I believe MS are adding generics to C#, but

Generics are also coming in Java (I've lost track of the # of times
i've heard them announced as imminent over the last few years, but
surely ONE of these times it will be true:-).
with such big changes being planned that just rubs in the fact that C#
is an immature language resting on an immature library.
Can't say that of Java, yet "generics are coming" applies to both:-).

I had assumed that the "resource allocation is construction" idiom
could be applied in any language with both constructors and
exceptions. There are only two issues that I can think of that would
seriously affect it...
[then listing 3 of them -- nobody expects the spanish inquisition!-)]

4. the destructor is called when it happens to be called, including
perhaps never if the garbage collector never needs to reclaim
_memory_, which is the only resource it directly tracks

C++'s idiom depends on destruction happening _at once_ for
automatic variables going out of scope:

// some preliminaries executed w/o holding the lock
{
LockHolder holder(thelock);

// the guts, executed while holding the lock
}

with LockHolder's ctor calling the acquire, and its dtor the
release, for the lock being held; making the whole idiom roughly
equivalent to, but handier than, Java's or Python's try/finally.

If holder's destructor is liable to be called hours later when
the GC needs it to recover a little memory, the idiom is no use.
rely on. For instance, what happens if you need to access one of those
resources before the GC frees it.
Exactly.
In Python, it doesn't seem to be an issue - presumably because Pythons
garbage collection is based on reference counting so destruction
happens immediately when the last reference has gone. I'm not sure
what happens when there are reference cycles, though - I know Python
handles them, but I'm not sure if they delay the garbage collection.
Yes, they do (delay the GC, and perhaps delay it indefinitely, since,
in particular, reference loops including objects with __del__ are NOT
unraveled -- the GC punts on the need to call the __del__'s in some
order it cannot possibly infer).

The "immediate destruction when last reference gone" is an implementation
specific detail of CPython -- handy, but there's quite a price paid for
it, so the _language_ makes no guarantees. So you have try/finally for
those cases where you NEED guarantees (not as handy, admittedly).

Hmmm - a thought provoking issue. Thanks for pointing it out.

You're welcome!
Alex

[Michael Hudson]

Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> writes:

In Python, it doesn't seem to be an issue - presumably because Pythons
garbage collection is based on reference counting so destruction
happens immediately when the last reference has gone. I'm not sure
what happens when there are reference cycles, though - I know Python
handles them, but I'm not sure if they delay the garbage collection.

They do. By how much, well, depends.

Cheers,
mwh

--
I'm okay with intellegent buildings, I'm okay with non-sentient
buildings. I have serious reservations about stupid buildings.
-- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)

[Stephen Horne]

On Mon, 13 Oct 2003 11:52:31 GMT, Alex Martelli <al***@aleax.it>
wrote:

The "immediate destruction when last reference gone" is an implementation
specific detail of CPython -- handy, but there's quite a price paid for
it, so the _language_ makes no guarantees. So you have try/finally for
those cases where you NEED guarantees (not as handy, admittedly).

Ah - I think I've just had one of those subtle but important paradigm
shifts. Resource management (for resources other than memory) simply
rests on slightly different language mechanisms in Python and Java
than it does in C++.

Oddly enough, I think my Python code has reflected this for some time
without me noticing the issue.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Alex Martelli]

Stephen Horne wrote:

On Mon, 13 Oct 2003 11:52:31 GMT, Alex Martelli <al***@aleax.it>
wrote:

The "immediate destruction when last reference gone" is an implementation
specific detail of CPython -- handy, but there's quite a price paid for
it, so the _language_ makes no guarantees. So you have try/finally for
those cases where you NEED guarantees (not as handy, admittedly).
Ah - I think I've just had one of those subtle but important paradigm
shifts. Resource management (for resources other than memory) simply
rests on slightly different language mechanisms in Python and Java
than it does in C++.

Yes, this is a good way to put it, I think.

Oddly enough, I think my Python code has reflected this for some time
without me noticing the issue.

Interesting indeed! This kind of "you're smarter than you know" effect
IS observed time and again, admittedly...
Alex

[Cameron Laird]

In article <Dn**********************@news2.tin.it>,
Alex Martelli <al***@aleax.it> wrote:

Stephen Horne wrote:

[Anand Pillai]

I was not exagerrating when I wrote it. I find python one of the
most 'expressive' languages out there among the crop of higher-level
languages like Perl, Tcl, Ruby etc. It kind of tends to be very
intuitive and the code follows your brain pretty well. Recently
in the wing IDE mailing list there was a suggestion of the slogan
"Python - Fits Your Brain" with many threads. It really does fit
the brain, and I find no exaggeration in the slogan, not even a bit.

For someone who is still coding C++ for a living, I find the hobby
stuff I do in python to be pretty soothing for my brain. I dont
use any debugger, never once so far, and I find the occasional
'print' statements sprinkled here and there is more than enough.

I am not trying to impress anyone. Give me a problem and I can
lay a wager I can do it in python and deliver you the beta code in
two weeks. Let that be a fresh problem btw. Give me another two
weeks and I can deliver you commercial quality code without using
a debugger.

Try me.

-Anand

Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> wrote in message news:<vl********************************@4ax.com>. ..

On 13 Oct 2003 00:50:18 -0700, py*******@Hotpop.com (Anand Pillai)
wrote:

I consider Python as high-level psuedo-code. It helps me in
programming, since you dont make mistakes while writing
psuedo-code. So it follows by induction that you dont make
these mistakes like static type errors while programming python.

It is a different approach, by altering your thinking, rather
than relying on tools. Works for me ;-)

While I agree that most likely sashan needs a change of mindset rather
than a language with static typing, this is an unrealistically
impressive claim.

There is no context where I do not sometimes make mistakes, including
pseudocode.

Of course errors do tend to be much rarer in Python, mainly because I
am concentrating on the program logic, rather than being distracted by
the overheads of the language.

[Stephen Horne]

On 13 Oct 2003 10:04:21 -0700, py*******@Hotpop.com (Anand Pillai)
wrote:

I am not trying to impress anyone. Give me a problem and I can
lay a wager I can do it in python and deliver you the beta code in
two weeks. Let that be a fresh problem btw. Give me another two
weeks and I can deliver you commercial quality code without using
a debugger.

Try me.

OK - how about the Turing test?

Ah - I see - that's not a fresh problem, having been proposed some 50
years ago ;-)
Some problems are complex in any language.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk