Showing posts with label Python. Show all posts
Showing posts with label Python. Show all posts

2017-04-02

Which programming language to teach? A principled choice

Java is still one of the most popular programming language to teach the young or newbies to programming.  It's a very problematic choice.  See:

  1. The problem of Object Oriented Programming is an education one
  2. Learn Python instead of Java as your first language [1]
  3. Java has deep expression problem for beginning students
  4. Governments mandating which programming language to teach
Having looked at some of the problems and issues before, I want to be constructive and offer some principles for how to choose which programming language to teach instead.


1. Principle of no magical incantations

This can be viewed as a language feature vs. library supplied functionality issue.  The latter is mostly okay, but the former should have no magical incantations that students need to learn.

Magical incantations are language features like the "static" keyword in Java.  You could imagine a student asking:
What does "static" mean in the "main" method declaration?  Why is it "static" and not something else?  What does "static" do?  Why do I need to write "static" when I don't know what it means to make something "static" vs not static?  I don't want it "static", I want it "grounded", can I write that instead?
Now you could imagine a teacher answering:
The answer to why, what, how, etc., would require explaining OOP and how it's implemented in Java and...  Look, just write 'static'.  It's just the way it is.  Just do it this way or else it doesn't work.  It's a magical incantation the Java gods require you to recite.
The more language features required to write even a simple program, the more things students have to learn or be ignorant of but use (i.e. magical incantations).

That makes it more likely that students have to learn everything about the programming language all at once just to do even the simplest thing at all.

2. Minimize concepts required to start doing stuff

The more that foundational programming concepts are required, the more programming language specific things students must think about whilst at the same time thinking about solving the actual (i.e. non-programming-language, "business") problem in its problem domain.

Otherwise, it'd be like students have to learn everything in the programming language all at once in order to do anything at all.

3. Idiomatic code from the start

A programming language that encourages writing idiomatic code from the very start reduces either the magical incantations required in writing idiomatic code, and reduces dumb code written stupidly just to avoid learning the magical incantations.

Otherwise, students have to learn everything all at once just to do anything at all.

Magical incantations are not hidden machinery!

I'm not advocating learning C because it doesn't have the magic of a garbage collector (GC)!  The GC is not a magical incantation: it's mostly hidden machinery.

Hidden machinery works quietly, never broadcasting its own existence, and isn't in your face about what it does.  It doesn't offer an affordance where none is called for, or where it would be inappropriate for the target user.

Magical incantations are flamboyant and in your face.  You know it's doing work because the magician is showing you that work is being done through the incantations, even if what's shown and what's done might very well be disconnected from each other.

To a newbie, the "static" Java keyword (to pick on something as an example) is magical incantation.  The Java GC is hidden machinery that we should be thankful for having every day.

Hidden machinery that makes a language easier for a newbie to learn is great.  Magical incantations that calls out its own existence is not helpful.

Magical incantations are also not Spooky Action at a Distance.  But that's a topic for another day.


Afterword
I wrote the above years ago (around 2013 February 4), and only now slightly expanded and lightly edited it to share here.

[1] I don't recommend learning Python as your first language anymore for various reasons (but I'd certainly recommend learning Python over Java as your first language!).

2012-08-27

OpenShift My Python Django Project

Red Hat's OpenShift platform-as-a-service is easy to set up and start using if you have a Python Django project (I haven't tried the other platforms supported, e.g. Java).  It's just 9 (longish) steps!

The django-example they offer gives a good idea of what the completed Django on OpenShift project should look like, but I thought I'd jot some notes down on how to get there from an existing Django project on Ubuntu Linux.

There are two main parts to this process, (A) OpenShift Tools Set-up, and (B) Set-up Python Django Project for OpenShift.


(A) OpenShift Tools Set-up
 
(0) Go to OpenShift and sign up for an account.

(1) Install the rhc client tool on your local computer.
 There's some instructions provided, but it boils down to running on your command line:

$ sudo apt-get install ruby-full rubygems git-core
$ sudo gem install rhc
$ rhc  #this should now run without errors

(2)  Setup your computer to connect to the OpenShift servers.
This should be easy. Just do on the command line: rhc setup and follow the on-screen instructions.

That should really be all it takes, but note that that will upload your default public encryption key for your computer to OpenShift, namely: ~/.ssh/id_rsa.pub so you should know the password to that key pair or else you won't be able to connect to OpenShift.

If you don't want to use your default key, or some other reason, you can always create a new public/private encryption key pair and upload that (just delete the default one from OpenShift, which you can do through their web interface or on the command line).  I'll describe that next.