Christian Stapfer wrote:
> "Ron Adam" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Christian Stapfer wrote:
>>
>>>"Ron Adam" <[EMAIL PROTECTED]> wrote in message
>>>news:[EMAIL PROTECTED]
>>>
>>>
>>>>Christian Stapfer wrote:
>>>>
>>>>
>>>>
>>>>>This discussion begins to sound like the recurring
>>>>>arguments one hears between theoretical and
>>>>>experimental physicists. Experimentalists tend
>>>>>to overrate the importance of experimental data
>>>>>(setting up a useful experiment, how to interpret
>>>>>the experimental data one then gathers, and whether
>>>>>one stands any chance of detecting systematic errors
>>>>>of measurement, all depend on having a good *theory*
>>>>>in the first place). Theoreticians, on the other hand,
>>>>>tend to overrate the importance of the coherence of
>>>>>theories. In truth, *both* are needed: good theories
>>>>>*and* carefully collected experimental data.
>>>>>
>>>>>Regards,
>>>>>Christian
>>>>
>>>>An interesting parallel can be made concerning management of production
>>>>vs
>>>>management of creativity.
>>>>
>>>>In general, production needs checks and feedback to insure quality, but
>>>>will often come to a stand still if incomplete resources are available.
>>>>
>>>>Where as creativity needs checks to insure production, but in many cases
>>>>can still be productive even with incomplete or questionable resources.
>>>>The quality may very quite a bit in both directions, but in creative
>>>>tasks, that is to be expected.
>>>>
>>>>In many ways programmers are a mixture of these two. I think I and
>>>>Steven
>>>>use a style that is closer to the creative approach. I get the feeling
>>>>your background may be closer to the production style.
>>>
>>>
>>>This diagnosis reminds me of C.G. Jung, the psychologist,
>>>who, after having introduced the concepts of extra- and
>>>introversion, came to the conclusion that Freud was
>>>an extravert whereas Adler an introvert. The point is
>>>that he got it exactly wrong...
>>>
>>> As to the value of complexity theory for creativity
>>>in programming (even though you seem to believe that
>>>a theoretical bent of mind can only serve to stifle
>>>creativity), the story of the discovery of an efficient
>>>string searching algorithm by D.E.Knuth provides an
>>>interesting case in point. Knuth based himself on
>>>seemingly quite "uncreatively theoretical work" (from
>>>*your* point of view) that gave a *better* value for
>>>the computational complexity of string searching
>>>than any of the then known algorithms could provide.
>>>
>>>Regards,
>>>Christian
>>
>>
>>>(even though you seem to believe that
>>>
>>>>a theoretical bent of mind can only serve to stifle
>>>>creativity)
>>
>>No, that is not at all what I believe. What I believe is, "The insistence
>>of strict conditions can limit creative outcomes."
>
>
> That's agreed. But going off *blindly*experimenting*
> without trying to relate the outcome of that experimenting
> back to ones theoretical grasp of the work one is doing
> is *not* a good idea. Certainly not in the long run.
> In fact, muddling-trough and avoiding the question
> of suitable theoretical support for one's work is
> perhaps more typical of production environments.
>
>
>>The lack of those limits does not prevent one from using any resources
>>(including theoretical ones) if they are available.
>>
>>You seem to be rejecting experimental results in your views.
>
>
> Not at all. You must have mis-read (or simply not-read)
> my posts in this thread and are simply projecting wildly,
> as psychoanalysts would call it, that is all.
The term 'rejecting' was the wrong word in this case. But I still get
the impression you don't trust experimental methods.
> As it appears, not even my most recent post has had
> *any* recognizable effect on your thoroughly
> misapprehending my position.
>
> Regards,
> Christian
In most cases being able to see things from different view points is
good. So I was offering an additional view point, not trying to
implying your's is less correct.
On a more practical level, Python as a language is a dynamic development
process. So the level of completeness of the documentation, and the
language it self, will vary a bit in some areas compared to others. So
as a programmer, it is often much more productive for me to try
something first and then change it later if it needs it. Of course I
would test it with a suitable range of data that represents the expected
range at some point.
In any case, this view point has already been expressed I think. <shrug>
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
