Python editors: Simple wins

I am working on next year’s courses already.  Programming is an elective so I have to sell the course to the students.  I want something ready now to convince them to sign up.  I have six freshmen and one sophomore coming up but I want some upper classmen to jump in.  I need to find some Juniors and some more Sophomores that are looking at STEM for college and would therefore be good candidates for a Python course.  I teach a dual-credit Python course and the college credit is only available to Juniors and Seniors.  I do not offer Python to Freshmen and Sophomores for that reason.  Many of these Juniors and Seniors will be first time programmers so I need things to initially go smoothly.  Things like having the installation instructions for Python and the IDE of choice laid out.  The Python IDE or editor of choice also has to be simple enough to be easy to use for a beginner but not so limited that it restricts what we want to do.  My programming courses are BYOD so whatever editor I use has to work on whatever is carried through the door.  Even a Mac.  So the digging begins.

Previously I used PyScripter with Python 3.4.  Python is now 3.6 (or 2.7 depending on the version you want to go with) and PyScripter has not been updated to work with newer versions, and it looks like it is not going to be updated.  (This is a major issue with free stuff.  Updates can be few and far between.)  So I was off to Googleland looking for something new. It has to be simple to use, simple to install and/or set up and free.  Right now I am just Googling and trying editors.  How many are there?  Lots and lots (just Google “Python editor”) but that simple to setup criterion can be a killer.  It killed Eclipse right off the bat.  Sublime Text 3 went down in flames. Visual Studio was not bad if you found the right website that gave the correct instructions.  I did and it worked but it sort of misses the simple to use thing.  File management with VS is a bit of a pain.  Visual Studio Code (a simplified version of VS) does not seem to do anything when I run my simple little draw a polygon test program.  It fails the simple to use test.  I tinkered with IDLE for a while.  It is nice that it is the native Python editor but I am lazy and like the auto complete feature other editors have built in.  Supposedly IDLE has autocomplete (I have the feature turned on) but it seems to have a minor issue, it does not work.  Things that do not work are bad.  I try not to use bad things in my classes.  It seems to frustrate the students.  PyCharm.  Easy to install, has a little green arrow to run the code, console is there by default, not a large number of never to be looked at options, autocomplete works, simple as a brick.  Folks, I think we have a winner.  Of course PyCharm sort of cheats.  It was written to be an editor for Python exclusively.  The other editors I looked at (other than IDLE) are multi-language so of course there are going to be setup issues.  I want something that is initially brick simple.  A professional programmer is maybe going to want more features than PyCharm offers but we are not professional programmers.  Brick simple wins.

When teaching beginners the more distractions, frustrations or simple confusion the uglier it can get.  Frustrate new programmers early and they are pretty much done for the semester.  If their first experience is a messy setup with an editor then there is going to be trouble.

The same can be said about beginning programming teachers.  I help teachers that have no programming background.  They have been asked to get a CS/programming curriculum started in their school.  That first language/IDE/editor has to be brick simple.  Eventually that beginning teacher has to leave Scratch and Small Basic to step up to a college level language.  Python with a good simple editor is an obvious step.

Daughter Graduates: Good and Bad

My daughter graduated from the University of Montana Saturday with a BA in Psychology.  Yesterday she was only five years old.  What happened?  She is not really sure where she is going from here but it really does not bother me.  She has a couple of retail jobs and wants to take some time to think.  She knows to go anywhere in psychology she has to get the doctorate.  She is looking at forensic psychology which means leaving Missoula.  Now that does bother me.  She was only five yesterday.

Teaching Programming with BYOD

Bring Your Own Device.  It is a solution and it is a problem.  All my programming classes are BYOD.  I have loaner laptops for those that cannot afford a laptop but that really is not much different from BYOD.

Why BYOD?  Many reasons.  The school has two computer labs.  One is in a classroom so it is out.  The main school lab is pretty sterile, computers in rows elbow to elbow.  Just not what I would consider an atmosphere for thought and exploration.  It is also used regularly so putting a programming class in there is going to be a pain for other teachers.  I used to have computers lining the walls of the room in which I teach.  I would install all the software and have things pretty cookbook.  But then I had problems with privileges when the kids wanted a sprite, needed to save locally, saving on Google Drive and half a dozen other issues because the kids were not administrators.  I wanted the kids to learn how to download and install the software they were using.  Getting Python up and running with an editor is not always a trivial exercise.  The kids should know how to troubleshoot an install.  BYOD allows those that want to work at home to do so.  Admittedly I do not get a large number of those students but there are enough to justify the BYOD hassle.  Perhaps the biggest reason for BYOD is I want the kids to know about their device.  The kids can run apps, download from Steam and get Netflix to work but changing resolution, hooking up a second monitor in extended display and installing a Google Drive folder are not tasks the techno generation seem familiar with.  So BYOD it is.

A big advantage of BYOD is the kids that own their own laptop (most of them) have a better device than anything the school owns.  There is just something about working on an i7 with 16 GB of RAM and a dedicated video processor that make a Python or Unity assignment run better than on one of the ten year old school loaner laptops or lab towers.  The only way I get to see really cool hardware is when a kids brings it in.  BYOD eliminates any administrator install issues (unless the computer has something like Network Nanny on it.  I had a long discussion with a parent over that one.)

The big disadvantage of BYOD is you are now dealing with five different brands, weird malware, fourteen viruses and a partridge in a pear tree.  I actually like dealing with all these issues.  At the beginning of the semester the kids learn all sorts of software and hardware issues.  Cool.  Another somewhat interesting disadvantage is the kids that are working on 11-inch computers.  My eyes do not see that small any more.  A Unity project on an 11-inch screen is just silly.  Then there is the kid with the Mac.  Kid, you are on your own.  If you want to borrow a PC I have some.  Even worse is the kid with the Chromebook.  It is always an interesting conversation with the parents about how that new, cheap Chromebook is not going to do the trick for anything we are going to do in my programming classes.  A sad, sad moment.

Some lessons learned:

1. Teach file management. The kids keep forgetting where they save things or they scatter files everywhere.
2. Stress saving to Google Drive or the like. Backpacks are rough on computers and I have had a couple kids kill their computers by not being careful.  Bad, very bad.
3. They need a mouse. Trying to do something like Unity without a mouse is not practical.
4. Bring the power cord every day.
5. All sorts of things are on that BYOD laptop so watch them like a hawk.
6. Expect weird issues so be flexible.
7. Have some kind of central file storage area for assignments, YouTube videos and what not the kids can have access to. Something like Google Classroom or a Google shared folder.
8. Have enough power outlets in the room. My school was built in 1922.  Electricity was a fad at the time.  The classrooms have two outlets.  I had to have maintenance run conduit and outlets around the room.  Laptops do not pull a lot of amperage so there is no problem with the breaker.
9. The internet content filter is going to cause a problem. Be on a first name basis with the person that controls it.  In my case it is me.
10. Read #6 again. Several times.

After several years of BYOD programming I would never do it any other way.  Yes, it can be a pain at times but the advantages for the student far outweigh that pain.

First programming language hoopla

The first language discussion is warming up again.  Universities seem to be abandoning Java for something else and the conversations start (see here and here).  Even the University of Montana is switching their intro CS major language from Java to Python.  The news folks and non-educators (professional programmers are always the best) start coming up with all these “great” suggestions as to what should be the first university level language.  If you read comments by the people that actually teach (two of which are the here and here above) they will pretty much agree that IT DOES NOT MATTER!!!  A good teacher who understands who he or she is teaching to can make almost any language do the trick.  Yes, there are better languages for teaching and some may be a bit too limited to really be a good first college level language but the number that would actually do the trick is pretty high.  I think I understand why UM is switching.  Montana suffers a major shortage of high school programming courses.  Most Montana schools offer nothing in the area of programming.  Incoming college kids looking at CS are coming in with little to no background in programming.  Stepping into a full blown Java course with that background is guaranteed to reduce the number of students looking at CS as a major.  I can still remember (admittedly vaguely) my first CS programming course in the early 90s (the FORTRAN in the early 70s does not count).  I sat down with about 100 college freshman.  By the end of the quarter there were maybe 25 of us left.  The instructor was one of the worst I have ever had in my long college experience.  He knew Java in and out but could not understand we did not know Java in and out.  The first programming language should not be intended to reduce the number of possible CS students.  It should be something tempting, interesting and an introduction to a possible future.  It should be taught by an instructor that understands how to teach, not a very smart CS adjunct that has no idea of how students learn.  Years ago I saw some statistics on the percentage of freshmen that change majors from CS after the first semester.  If that first programming course is intended to keep the shortage of CS majors steady, it is working well.

That first language really does not matter.  What does matter is the objective of the course, (rite of passage or introduction to CS) and the quality of the instructor.  If we want more students looking at CS we have to have a gentler introduction to CS than the usual “death by Java” type intro class.  I was a math adjunct at the University of Montana for ten years.  The math program had courses stating at the very bottom, about middle school math, so an incoming student had about four levels to step into depending on their math background.  Those bottom level courses would not give college credit but they prepared students with poor backgrounds for entrance to college math.  They were taught by middle school or high school teachers working on masters degrees or retired teachers.  CS needs a scheme like this to attract students and keep students (although the extreme shortage of CS teachers might be a bit of an issue).

As Mike Zamansky said in his post “There’s no single best universal answer. Each choice giveth and each choice taketh away.”  Remember, no matter what that intro language is, it will not be the language some employer the student interviews with is using.

Why teach game programming? Why not?

Next October I will be doing a presentation on my year of teaching game programming with Unity at the Montana Educators Association convention here in Missoula.  Being well aware that procrastination kills I started an outline of what I want to do.  After reading Dan Meyer’s post “How I Present” I figured I would not build the PowerPoint first.  I am sitting here doodling along making notes for my witty yet enlightening presentation when it hits me, why am I teaching game programming with Unity in the first place?  Not the Unity part, but the game programming part.  (I do this “why am I teaching blank” regularly.  I keeps life from getting boring and simple.)  The first line in my out line is “Why Game Programming”.  I really want to get a good answer to myself for that question and not just a “because it is fun”.  (Although that may be enough.)

I have been teaching game programming with some language for a long time now.  No great innovation there.  If there is a programming teacher in the world that has not used game programming as a fun incentive I would be very surprised.  Back in the mid 80’s I used Pascal and Apple BASIC.  The games were just the text based Dungeon & Dragons things (“Go North”) or simple Pong like things.  When Scratch came along all sorts of new games were possible and the sprites were of much higher quality.  Then smart phones started turning up in class and the kids were captivated by the games.  Some of them looked very easy in design so I looked for a programming app.  I found Corona.  I gave teaching Corona a try.  The course worked, sort of.  The programming required by Corona was a bit more than many of the students in the class were capable of.  The step from Scratch to Corona was simply too big, there was a level of complication in the IDE management, files, importing, event management and so on that I was not comfortable teaching.  (The drag-and-drop progression to line code discussion comes along here.)  I was simply too used to teaching with languages that were complete packages designed for teaching, like Scratch, Small Basic and Alice.  But, and this is a big “but”, the kids wanted to learn Corona programming.  They saw a goal that was cool, having an app on their phone that they wrote.  At the time I was still in the traditional mindset of teaching coding with the game as an incidental.  It was a programming course that ended up with a game as the final product.  Due to work load (school techie, two or three math courses and a couple of programming courses) I backed off on the gaming programming direction for a while.  My programming classes still wrote games in whatever flavor language we were using but they were not very fancy.  I dabbled in GameMaker but it just did not tickle my fancy.

About this time my programming class sizes started to drop.  What used to be 10-15 was looking like 4-5.  There is no two ways about it, programming is not easy and it can be as exciting as watching grass grow, especially if you are not a programming/computer geek.  I was low on geeks.  I wanted something that would attract the non-geeks of the school into taking programming and would possibly get them hooked into going farther in CS and programming.

Some kid showed me Microsoft’s Project Spark.  Oh my.  Oh my again.  I am thinking I may have to limit class sizes.  It was not really programming in the traditional coding sense but boy does it look like fun and I was trying increase the fun factor in my programming classes.  I was getting all set to roll on a semester of Project Spark when Microsoft killed it.  (I am still really, really sad about that.)  I had a scheme to get kids into my programming classes and with the demise of Project Spark I had a bit of a problem with my scheme.  Now what?  I had tinkered with Unity a year or two previously and found the tutorials wanting.  Desperate, I looked again.  I found better tutorials.  I found tutorials that did cool things in Unity.  I was back with the scheme.

That is the history.  Now for the “why teach game programming”.  It is very simple and can be stated in one word, “numbers”.  Numbers in seats.  As bad as it sounds numbers rule education.  If only two kids sign up for class the class disappears.  A program can disappear this way.  I needed numbers.  For an elective like programming to have numbers it has to be fun.  To be fun it has to be something the kids relate as fun, not what geeks who like to program relate as fun.  So game programming it is.  The trick was to not throw out the baby with the bath water.

Teaching game programming with Unity at the introductory coding level is really not teaching “programming”.  It is definitely teaching application use with a little code cutting and pasting.  My intent with Unity was to not teach programming but to teach the application and to have the kids see coding as an incidental.  I want to teach the kids how to learn.  They get to see the power of knowing how to code.  This is the applications side, kind of like in a math course.  The big math student question is always “How am I going to use this in real life.”  For programming here it is.  Yes, it is “black box” coding, just like “black box” math but it is also “here is a super cool thing you can do with code”.

Is teaching Unity a college prep course?  Not even close.  Is it an introduction to something cool that is going to temp kids to take the college prep courses?  I sure hope so but even if it does not bring them into my traditional Python programming classes it does get them seeing and thinking about code and the power of coding.

Skills.  By far the biggest skill the kids learn is following directions.  They watch YouTube tutorials, read text tutorials, listen to me give brief lectures, all involve following directions.  Does not sound to impressive does it?  The thing is if you can follow directions you can learn almost anything.  Of course I mess things up by making them build their own game by using the techniques they learned from the tutorials so the class is not just following directions.

Most of my programming students are not going into a programming or a CS career.  Teaching Unity, even if it is mostly cut and pasting code snippets, gives the students a look at big time programming.  Will they understand the code they were cut and pasting?  Not really but I think there is enough seepage that even the oblivious will come away with something.

Teaching an elective is a balancing game.  The elective has to be interesting enough to attract students but not so watered down that it does not justify its existence in the curriculum.  I really believe gaming programming with Unity is a viable option.  Kids that take it as an only CS course will get something worthwhile out of it.

Would it be possible to teach C# using Unity?  Maybe but learning Unity itself just takes so much time that to really get the full programming experience with C# would take a couple of years at least.  Would a C# course then a Unity course help with learning Unity?  The answer is of course but so much of the Unity C# code is Unity specific that the C# pre-course might not be a big enough advantage to justify the time.

I plan to hang with the Unity game programming (or some high level 3D game IDE) because it is fun, has a good amount of problem solving, has some coding, and requires the kids to follow directions closely.  My CS college bound kids will get a solid dose of Python their Junior or Senior year.  I will also keep the Java course alive.