[Python-ideas] Deterministic iterator cleanup

[Nick Coghlan]

On 25 October 2016 at 03:16, Chris Barker <chris.barker at noaa.gov> wrote:
> On Sat, Oct 22, 2016 at 9:17 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>>
>> This is actually a case where style guidelines would ideally differ
>> between between scripting use cases ... and
>> library(/framework/application) development use cases
>
>
> Hmm -- interesting idea -- and I recall Guido bringing something like this
> up on one of these lists not too long ago -- "scripting" use cases really
> are different that "systems programming"
>
>> However, that script/library distinction isn't well-defined in
>> computing instruction in general,
>
> no it's not -- except in the case of "scripting languages" vs. "systems
> languages" -- you can go back to the classic  Ousterhout paper:
>
> https://www.tcl.tk/doc/scripting.html
>
> But Python really is suitable for both use cases, so tricky to know how to
> teach.

Steven Lott was pondering the same question a few years back
(regarding his preference for teaching procedural programming before
any other paradigms), so I had a go at articulating the general idea:
http://www.curiousefficiency.org/posts/2011/08/scripting-languages-and-suitable.html

The main paragraph is still pretty unhelpful though, since I handwave
away the core of the problem as "the art of software design":

"""A key part of the art of software design is learning how to choose
an appropriate level of complexity for the problem at hand - when a
problem calls for a simple script, throwing an entire custom
application at it would be overkill. On the other hand, trying to
write complex applications using only scripts and no higher level
constructs will typically lead to an unmaintainable mess."""

Cheers,
Nick.

P.S. I'm going to stop now since we're getting somewhat off-topic, but
I wanted to highlight this excellent recent article on the challenges
of determining the level of "suitable complexity" for any given
software engineering problem:
https://hackernoon.com/how-to-accept-over-engineering-for-what-it-really-is-6fca9a919263#.k4nqzjl52

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia