Skip to content
This repository has been archived by the owner on Jan 3, 2018. It is now read-only.

Python motivation #623

Closed
wants to merge 12 commits into from
Closed

Python motivation #623

wants to merge 12 commits into from

Conversation

snacktavish
Copy link
Contributor

This is a rough version of motivational slides for python - based on @sritchie73's R motivational slides.
Idea is that they would be presented at the beginning of a python lecture. Thoughts?

@katyhuff
Copy link

Hi there, I'm happy to review this if you like. Any objections?

@wking
Copy link
Contributor

wking commented Jul 23, 2014

On Wed, Jul 23, 2014 at 01:52:31PM -0700, Emily Jane McTavish wrote:

This is a rough version of motivational slides for python

This looks reasonable to me. Personally, the pitch for Python breaks
down into a generic:

“Write software, because the more work your computer is doing for
you, the easier it is to reproduce your results. Also, you're going
to be writing down your methods anyway, so you might as well write
them down in a way a computer can understand ;).”

For folks that buy the generic idea (or a more elaborate version,
showing the awesomeness of an automated workflow and/or hazards of a
manual workflow), there's a tool-level pitch:

“Use Python, because it's a popular general-purpose,
free-as-in-freedom, scripting language that's focused on enabling
explicit, readable code. It also has a huge collection of
third-party packages that probably already do most of what you
need.”

Then I'd go on and unpack each of those terms, and explain why you
want something that's popular, or general-purpose, or … (or explain
whichever the audience is interested in).

I think you hit on most of those points, but if we split this into
separate “Why program” and “Why Python” decks, we can collaborate with
the R (etc.) folks on “Why program” ;). Once you've established a set
of desirable traits, the “and not…” page (and maybe the whole “Why
Python?” deck?) is just a table with traits, languages, and check
marks.

In fact, maybe you don't even need a “Why $LANGUAGE?” deck, and can
just verbally hit on the way $LANGUAGE delivers for each useful trait.
Maybe we want a generic “Why program, and what to look for in a
language” deck, and then Python/R/… notes for the speaker to
emphasize? Or Python/R/… versions of the generic deck that drop in
Matplotlib/IPython/… images (or their R/… equivalents) at the
appropriate points?

Or maybe the benefit of collaboration is not worth the mental
overhead, and we do just want to go with something like this?

@gvwilson
Copy link
Contributor

Please go ahead.

</section>

<section>
<h2>Python is...</h2>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi! So, having a list like this is great. But, I wonder if a different order or a different breakdown might allow it to read more like a sentence, and therefore make more sense. Something like:

  • a popular,
  • powerful,
  • easy to learn,
  • programming language,
  • that is human readable,
  • whitespace delimited,
  • free,
  • and open source.

It has a number of excellent libraries for

  • plotting,
  • mathematics,
  • and domain sciences.

Something like that maybe?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe:

It has a number of excellent libraries for

  • mathematics,
  • plotting,
  • and domain sciences.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good ideas! I incorporated them.

@gvwilson
Copy link
Contributor

gvwilson commented Sep 8, 2014

@snacktavish Will you have time in the next week to revise this, or should we hand it off to someone else?

@snacktavish
Copy link
Contributor Author

Yes! I'll get on it this week.

On 09/08/2014 08:36 AM, Greg Wilson wrote:

@snacktavish https://github.com/snacktavish Will you have time in
the next week to revise this, or should we hand it off to someone else?


Reply to this email directly or view it on GitHub
#623 (comment).

Emily Jane McTavish
Postdoctoral researcher
Department of Ecology and Evolutionary Biology
University of Kansas
6031 Haworth Hall
1200 Sunnyside Avenue
Lawrence, Kansas 66045
lab phone: 785.864.5789

@snacktavish
Copy link
Contributor Author

OK! I incorporated the very helpful comments from @katyhuff and @r-gaia-cs and updated it. I did not have a chance to really address @wking 's more in depth comments - I agree a different approach may be valuable, but I also often am asked: Should I learn, R, Python, Perl or...X. So I agree that this deck conflates why program with why program in Python. But I feel ok about that!

@wking
Copy link
Contributor

wking commented Sep 11, 2014

On Thu, Sep 11, 2014 at 11:12:01AM -0700, Emily Jane McTavish wrote:

So I agree that this deck conflates why program with why program in
Python. But I feel ok about that!

I'm ok with it too, since we don't have to have something that lets
us collaborate with the R folks on putting down JavaScript ;). We can
always revisit this later if we need help keeping this fresh.

Also:

And PyPI is now up to 48622 packages (not 46537), so I'd just say
“more than 48k packages” to make this a bit more future-proof.

Do the two master-merges (8d6f96e and 8f7a454) bring in anything
important? I don't expect you had any conflicts to resolve, in which
case, I'd just skip the merges. If you did have conflicts, I'd
prefer rebasing to merging ;). Still, this is a minor thing.

@snacktavish
Copy link
Contributor Author

@wking Good point, I'll update those numbers. And I don't really know on the master merges. I was getting permission problems on pulling, and so fetched and merged instead, but I'm not really sure why! There weren't any conflicts or anything.

@wking
Copy link
Contributor

wking commented Sep 11, 2014

On Thu, Sep 11, 2014 at 11:30:13AM -0700, Emily Jane McTavish wrote:

And I don't really know on the master merges. I was getting
permission problems on pulling, and so fetched and merged instead,
but I'm not really sure why! There weren't any conflicts or
anything.

It's usually best not to merge from master into a feature branch. See
the “useless merges” comment in 1. For more detail, see Linus'
somewhat caustic rant when David Miller did this sort of thing in a
Kernel branch [2,3,4]. As Linus points out in 4, it doesn't really
matter if the master-merge isn't both recent and your last commit. In
general, if you get in the habit of recording the “why” in your commit
messages, you'll catch yourself while you're making these sort of
reflex merges in the future, and can abort them earlier ;).

If you rebase the branch on master, it will drop the merges. I'm
happy to talk you through the rebase on #sciencelab, but I'm also fine
skipping that. I'm mostly bringing it up to help avoid future
occurrences ;).

@snacktavish
Copy link
Contributor Author

@wking Interesting! Pedantry accepted. This is my first PR to large project, and am interested to know what is standard practice. I'll investigate the links.

@gvwilson
Copy link
Contributor

@abostroem @tbekolay Please merge if you think this is close enough - we'd like to clear the decks before #759.

@tbekolay
Copy link
Contributor

LGTM! Great start that can be perfected later on. I merged, and added a commit to fix a few minor things (an errant ">" was showing up on all slides, and some slides had text flow off the screen). See 4e0a1ab for full details.

@tbekolay tbekolay closed this Oct 15, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants