Gas station without pumps

2013 March 21

Why Python first?

Filed under: home school,Uncategorized — gasstationwithoutpumps @ 11:21
Tags: , , , , , , ,

On one of the mailing lists I subscribe to, I advocated for teaching Python after Scratch to kids (as I’ve done on this blog: Computer languages for kids), and one parent wanted to know why, and whether they should have used Python rather than Java in the home-school course they were teaching.  Here is my off-the-cuff reply:

Python has many advantages over Java as a first text-based language, but it is hard for me to articulate precisely which differences are the important ones.

One big difference is that Python does not require any declaration of variables. Objects are strongly typed, but names can be attached to any type of object—there is no static typing of variables. Python follows the Smalltalk tradition of “duck typing” (“If it walks like a duck and quacks like a duck, then it is a duck”). That means that operations and functions can be performed on any object that supports the necessary calls—there is no need for a complex class inheritance hierarchy.

Java has a lot of machinery that is really only useful in very large projects (where it may be essential), and this machinery interferes with the initial learning of programming concepts.

Python provides machinery that is particularly useful in small, rapid prototyping projects, which is much closer to the sorts of programming that beginners should start with. Python is in several ways much cleaner than Java (no distinction between primitive types and objects, for example), but there is a price to pay—Python can’t do much compile time optimization or error checking, because the types of objects are not known until the statements are executed. There is no enforcement of information hiding, just programmer conventions, so partitioning a large project into independent modules written by different programmers is more difficult to achieve than in statically typed languages with specified interfaces like Java.

As an example of the support for rapid prototyping, I find the “yield” statement in Python, which permits the easy creation of generator functions, a particularly useful feature for separating input parsing from processing, without having to load everything into memory at once, as is usually taught in early Java courses. Callbacks in Java are far more complicated to program.

Here is a simple example of breaking a file into space-separated words and putting the words into a hash table that counts how often they appear, then prints a list of words sorted by decreasing counts:

def readword(file_object):
    '''This generator yields one word at a time from a file-like object, using the white-space separation defined by split() to define the words.
    '''
    for line in file_object:
        words=line.strip().split()
        for word in words:
             yield word

import sys
count = dict()
for word in readword(sys.stdin):
     count[word] = count.get(word,0) +1
word_list = sorted(count.keys(), key=lambda w:count[w], reverse=True)
for word in word_list:
    print( "{:5d} {}".format(count[word], word) )

Note: there is a slightly better way using Counter instead of dict, and there are slightly more efficient ways to do the sorting—this example was chosen for minimal explanation, not because it was the most Pythonic way to write the code. Note: I typed this directly into the e-mail without testing it, but I then cut-and-pasted it into a file—it seems to work correctly, though I might prefer it if if the sort function used count and then alphabetic ordering to break ties. That can be done with one change:

word_list = sorted(count.keys(), key=lambda w:(-count[w],w))

Doing the same task in Java is certainly possible, but requires more setup, and changing the sort key is probably more effort.

Caveat: my main programming languages are Python and C++ so my knowledge of Java is a bit limited.

Bottom-line: I recommend starting kids with Scratch, then moving to Python when Scratch gets too limiting, and moving to Java only once they need to transition to an environment that requires Java (university courses that assume it, large multi-programmer projects, job, … ). It might be better for a student to learn C before picking up Java, as the need for compile-time type checking is more obvious in C, which is very close to the machine. Most of the objects-first approach to teaching programming can be better taught in Python than in either C or Java. For that matter, it might be better to include a radically different language (like Scheme) before teaching Java.

The approach I used with my son was more haphazard, and he started with various Logo and Lego languages, added Scratch and C before Scheme and then Python.  He’s been programming for about 6 years now, and has only picked up Java this year, through the Art of Problem Solving Java course, which is the only Java-after-Python course I could find for him—most Java courses would have been far too slow-paced for him.  It was still a bit low-level for him, but he found ways to challenge himself by stretching the assigned problems into more complicated ones.  His recreational programming is mostly in Python, but he does some JavaScript for web pages, and he has done a little C++ for Arduino programming (mostly the interrupt routines for the Data Logger code he wrote for me).  I think that his next steps should be more CS theory (he’s just finished an Applied Discrete Math course, and the AoPS programming course covers the basics of data structures, so he’s ready for some serious algorithm analysis), computer architecture (he’s started learning about interrupts on the Arduino, but has not had assembly language yet), and parallel programming (he’s done a little multi-threaded programming with queues for communication for the Data Logger, but has not had much parallel processing theory—Python relies pretty heavily on the global interpreter lock to avoid a lot of race conditions).

2012 July 4

blockly – A visual programming editor

Filed under: Uncategorized — gasstationwithoutpumps @ 18:06
Tags: , , , ,

Google has created a browser-based block programming language: blockly – A visual programming editor – Google Project Hosting.

The editor is clearly inspired by Scratch, both visually and in terms of the programming features they chose to implement:

A demo program for the maze-running example given on the Google projects web site. Click to enlarge.

I found the blockly editor very irritating to use (no cut and paste, every block had to be picked from a menu each time it was used) and the primitives provided for the maze demo rather limiting (the only conditional was testing one of the neighboring cells for having a wall).

Blockly may be a nice demo of what can be done in the browser these days, but it is way short of Scratch in terms of fun, education, or usefulness. If it is ever going to go anywhere, it needs to be an order of magnitude better.

2012 May 17

Embedded programming gap

Filed under: Uncategorized — gasstationwithoutpumps @ 20:30
Tags: , , , , , , , ,

It seems that there is a shortage of programmers who can do embedded systems (which is what computer engineering is mostly about these days).

Critics lay much of the blame for the embedded programming gap at the doorstep of university computer science departments that have tended to migrate curricula toward trendy programming languages like Java at the expense of unglamorous tasks such as how to design and analyze algorithms and data structures.
Struggle continues to plug embedded programming gap | EE Times (by George Leopold)

I’m not so sure that Java is at fault here. It seems to me to be perfectly fine second programming language (after a simpler one like Python that does not require all data structures to be declared before any code is written).  The problem is more that the instruction focuses entirely on designing huge complex data structures and using large libraries of complex software components, rather than on fundamentals:

The problems start early in the curriculum. Too often an introductory Computer Science course will fall into one of two extremes: either focusing on the syntactic details of the programming language that is being used—“where the semicolons go”—or else treating programming as a matter of choosing components and plugging them into a GUI.

The basics—how to design and analyze algorithms and data structures—are covered summarily if at all. Software methodologies such as Object Orientation that are best approached in the context of the development life cycle for large applications, are introduced through trivial examples before their benefits can be appreciated: the proverbial cannon that is used to shoot a fly.

The education of embedded systems software engineers: failures and fixes | EE Times (by Robert Dewar)

I’m not so sure that I believe in Robert Dewar’s proposed solution, though, as he suggests having students do more high-level design (software architecture, rather than nuts-and-bolts programming), which is in direct opposition to his claim that students should be getting more training in low-level languages like C.

Robert Dewar also makes an argument for group work at the university level—something that is common in computer engineering programs, but apparently rare in computer science programs.  At UCSC, I know that all computer engineers, electrical engineers, and game design majors are expected to do group senior projects, and some of their other classes (such as mechatronics) are also group projects.

I think that the lack of group projects in many CS courses is not so much tied to Dewar’s idea “a perhaps regrettable staple of the educational process is the need to assess a student’s progress through a grade, and a team project makes this difficult” as it is to the problem of scale—a group project is only reasonable when the project is too big to be done more efficiently by a single person.  Creating and managing such big projects in lower-level classes would be a major undertaking, particularly in the short time frame of a quarter or semester, when a lot of things other than group dynamics need to be learned. Pasting a group structure onto tiny project would make things worse, not better, in terms of training students to be effective in groups (see Group work).

Some entrepreneurs have addressed the problem by starting up “initiatives like Barr’s week-long, hands-on Embedded Software Boot Camp.”  The idea is to take programmers who already have degrees and supposedly know C and train them specifically in the skills needed to do real-time programming. The cost is not small ($3000 for 4.5 days, if you register early).

Some computer scientists have been pointing out problems in the standard CS curriculum for a while:

I started saying this over a decade ago. I even did embedded stuff in my 3rd year data architecture course—my department was uninterested, and the students had a real hard time wrapping their heads around the thought that there are places where resources are limited.

The department fought me when I said that students needed to learn more than one language (Java). The department disagreed when I said that students should learn how to program for environments where bloated OO methods might not work (… But, the ARE no places where efficiency matters!!! It’s all about “Software Engineering”!).

The students had NO idea what it meant to program for a machine that had no disk, only memory.

Part of the reason CS departments are seen as being so out of touch is BECAUSE THEY ARE!!!

University should not be about job training, BUT it is also NOT about teaching only those things the faculty find interesting.

Struggle continues to plug embedded programming gap | The Becker Blog.

I know that there have been struggles between the computer science and computer engineering departments at UCSC about what programming language to teach first, with the computer scientists arguing for Java and the computer engineers arguing for C and assembly language.  Eventually they reached a compromise (which has been stable for about a decade), with the computer science students taught Java first and the computer engineering students taught C first, then both making transitions to the other language.

I think that both approaches work, but the strengths of the resulting programmers are somewhat different.  For device drivers and small embedded systems, I’d bet on the computer engineers, who have a better grasp of low-level details, interrupts, and hardware/software interactions.  For more complicated projects, I’d want one of the computer scientists doing the high-level programming, teamed with computer engineers to do the detail work.

I actually don’t like either C or Java as a first programming language.  I think that students would be better off starting with Scratch, which gets them quickly into multi-threaded code, real time operation, and race conditions, without burdening them with a lot of syntax.  Then they can switch to Python to learn about code syntax, types, and objects, without the burden (or support) of compile-time type checking.  After that they can switch to Java to learn about declaring all their data structures and having very rigid type rules (useful for bigger projects to make interfaces between different design groups more explicit).  In parallel with learning Python and Java, they should learn C and C++ in the context of the Arduino microprocessor (or similar small microprocessor) to control real-time physical systems.

The computer engineers could even skip Java, and learn their rigid type systems strictly in C++ (which they are more likely to use later), though Java is cleaner and makes the learning somewhat easier.

Computer scientists should not stop with this handful of languages, though, as they are essentially all Algol derivatives.  The CS students should also learn a couple of languages that come from different lineages (LISP or Haskell, for example).

2012 April 3

Computer Science for Non-Majors

Filed under: Uncategorized — gasstationwithoutpumps @ 21:57
Tags: , , , ,

Mark Guzdial, in his Computing Education Blog (Weekend newspaper coverage on computing for all, especially kids), commented on the NY Times article by Randall Stross: Computer Science for Non-Majors Takes Many Forms.

The article makes the case that everyone should be taught “computational thinking”, though Stross does not attempt to define what that means, merely noting

There is little agreement within the field, however, about what exactly are the core elements of computational thinking. Nor is there agreement about how much programming students must do, if any, in order to understand it.

Stross gives examples from Carnegie-Mellon and from Wheaton College in Massachusetts of two rather different approaches—one using Ruby and doing fairly conventional CS things (like iteration, recursion, random number generators, … ) and the other tackling analysis of large bodies of text by humanities majors, starting from big problems and helping the students decompose them into smaller, more solvable ones.

Stross even mentions the course using Scratch at the University of Maryland, Baltimore County, though I believe that he is too dismissive of Scratch as a programming language.  Yes, it is easy enough for middle-schoolers to learn it, but that doesn’t mean that it can’t be used for teaching most of the concepts of a first-year computer course.  (OK, Scratch is not suitable for teaching recursion, but it is very suitable for teaching an introduction to parallel programming and race conditions, which most languages used in first-year CS classes are not.)  I think that Marie desJardins and Michael Littman (of Rutgers) gave weak replies—Littman saying that

Computational thinking should have been covered in middle school, and it isn’t. So we in the C.S. department must offer the equivalent of a remedial course.

While it is certainly true that many intro to CS classes are the equivalent of remedial classes in math, science, or writing, it is not the case that all intro to CS classes need to be remedial.

Mark Guzdial seemed a little miffed that he was interviewed but not quoted:

I exchanged email with the author before the column came out, pointing out several sources and mentioning Media Computation. Randy felt that Georgia Tech’s experience with computing for everyone was less compelling, because Georgia Tech is an “engineering school.”  He said that he was more interested in programs that cater to humanities majors — which is what MediaComp is, because we developed it to reach Liberal Arts, Architecture, and Management majors.

I guess I would have been miffed to have been so misunderstood by a business professor also.

Mark goes on to talk about somewhat better coverage of similar issues in The Guardian, which had a section focused on computing education. He particularly liked Naughton’s “manifesto for revolutionary action“. I too like point 3:

We believe every child should have the opportunity to learn computer science, from primary school up to and including further education. We teach elementary physics to every child, not primarily to train physicists but because each of them lives in a world governed by physical systems. In the same way, every child should learn some computer science from an early age because they live in a world in which computation is ubiquitous. A crucial minority will go on to become the engineers and entrepreneurs who drive the digital economy, so there is a complementary economic motivation for transforming the curriculum.

Naughton does recognize some problems with his vision:

We recognise that a key obstacle to achieving the necessary transformation of the computing curriculum is the shortage of skilled and enthusiastic teachers.

Although the manifesto makes some very specific calls for changes in the UK, I think that Naughton’s explanation in a separate column is more compelling reading, explaining why things need to be different.  In it he defines “computational thinking” in a fairly broad way:

… computer science involves a new way of thinking about problem-solving: it’s called computational thinking, and it’s about understanding the difference between human and artificial intelligence, as well as about thinking recursively, being alert to the need for prevention, detection and protection against risks, using abstraction and decomposition when tackling large tasks, and deploying heuristic reasoning, iteration and search to discover solutions to complex problems.

I don’t know that Naughton’s definition matches my idea of “computational thinking” exactly (the stuff about risks is part of computer science, but not computational thinking, in my opinion), but it is a better shot at the definition than some I’ve seen.  His examples are rather feeble though (computational biology is not about “how the genetic code works”).

Despite my nit-picking, it is a good weekend when two major newspapers independently decide to talk about computer science education, and what needs fixing in it.

2012 March 2

Computer programming for preschoolers

Filed under: Scratch — gasstationwithoutpumps @ 09:27
Tags: , , , ,

One of my most-read posts is Computer languages for kids, because people are desperately looking for ways to teach computer programming to their kids (something the schools are not doing hardly at all, even at the high-school level: see Shoehorning computer science into K–12).

So far my best advice has been to start kids with Scratch, the free drag-and-drop programming language from MIT, somewhere around 4th grade. Some people have used Scratch with younger kids, but the fit is not always good, as Scratch assumes that kids can read fairly fluently and already have a good notion of sequence.  (I’ve been told, though, that even college students taking a first programming class sometimes have what I would think of as a pre-kindergarten grasp of sequence, so maybe Scratch is making too strong an assumption even for the targeted age group.)

I’ve not been able to make recommendations for younger kids, as I’ve not seen anything suitable.

A recent post on the Mindshift website (apparently the transcript for an NPR programs), Introducing Programming to Preschoolers, describes a new tool supposedly coming out this summer: Scratch Jr.  The new language builds on experience with Scratch and with cherp, a Lego robotics language for preschoolers. Unfortunately, details about Scratch Jr. do not seem to be available, so we’ll have to wait until this summer when they release it to see what it offers.  Some of the mentioned changes (like replacing the overly subtle color distinctions of Scratch blocks by bigger color contrasts of more saturated colors) seem to be small, but important tweaks.  Bigger changes will be needed to handle pre-literate children, and I’m curious to see how much power they can leave in the language while lowering the entry barrier.

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 259 other followers

%d bloggers like this: