Instead of deciding between Python or Lisp for a programming intro course...What about an intro course that uses *BOTH*? Good idea?

[Chris Angelico]

On Wed, May 13, 2015 at 1:53 AM, Stefan Ram <ram at zedat.fu-berlin.de> wrote:
> zipher <dreamingforward at gmail.com> writes:
>>so what kind of bullshit is saying that you should get rid of PRINT?
>
>   What might be reasonable is to be able to dissect a program
>   into functions, and have no effects in functions that are
>   there to calculate some value.
>
>   For example, when one calculates,
>
> y = sin( x )
>
>   , using a library function »sin«, one does not want »sin« to
>   print something.
>
>   Such library functions might even be used in code for a GUI
>   that has no console to print to at all.
>
>   In order to learn how to write such functions, one might
>   temporarily use the rule that PRINT is allowed only in the
>   main block (not in functions) or temporarily for debugging.

More generally, there are certain things which belong to the
application, and not to any library - things like:

* The console - print() and input(), and GUI windows
* Command-line arguments
* Program termination
* Working directory and root directory
* Credentials (uid/gid, etc)
* Logging configuration (destinations etc)

There are exceptions; argument parsing libraries often are granted
control over the console and program termination in addition to
reading sys.argv, but you would be somewhat surprised if having
"--no-check-ssl-certs" in sys.argv silently downgraded your HTTP
library's security settings. Control over application-wide settings
generally has to be in the hands of the application, not any one
library.

So if you're writing a library function, it probably shouldn't use
print()... but your application is most welcome to. You usually know
which one you're writing at any given time.

ChrisA