On 25 October 2016 at 03:16, Chris Barker
On Sat, Oct 22, 2016 at 9:17 AM, Nick Coghlan
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-suita... 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-... -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia