Python vs. Processing as a First Language | Hacker News Reader

Python vs. Processing as a First Language

compscigail.blogspot.com

46 pointsvgnet55 comments

One thing that struck me as odd was that the author apparently is not an experienced programmer, but she tried to learn Python from the tutorials designed for experienced programmers; she saw that there was a list of tutorials for non-programmers, but she "didn't look at any of those". Why not?

One possible answer is that the term "programming" means something somewhat different to the author than it does to, for example, me. When I look at the Python tutorial topics, even those for non-programmers, I see stuff that looks like programming: loops, conditionals, generators, etc. But the author apparently saw a lot of stuff that didn't seem to have much to do with what she was interested in: getting the computer to do something cool. Processing apparently gave her an easier way to do that.

To me, getting the computer to do something cool, in and of itself, is not necessarily "programming". For example, the beginner's tutorial for Processing that the author links to tells you to type the following into the editor: "ellipse(50, 50, 80, 80);". This, of course, draws an ellipse. Cool! But this, to me, isn't "programming"; it's just invoking a magic incantation to get the computer to draw an ellipse. "Programming" is what the person did who wrote the code that interprets that line you typed and figures out what to draw and where.

It's quite possible that this is just me; maybe most people are OK with using the word "programming" to describe something that doesn't seem like programming to me. But word choice aside, I am not trying to say that only what I call "programming" is worth doing. I think the point is more that maybe "programming" is too narrow a term to describe what many people are trying to do when they want to get the computer to do something cool.

By the same logic 'Hello World' isn't programming, but I agree with you to a point. A simple one-line hello world or ellipse drawing program is little different from typing in DOS or shell commands. 'Real' programming is implementing logic.

Having taught programming by Logo, think of 'ellipse(50,50,80,80)' as 'printf("hello world\n")'. Enthusiatic people will quickly figure out how to wrap that ellipse in a loop, add some variables, maybe find the equivalent of rand(), and now we are suddenly much closer to "real programming".

While some would think this is a horrible thing to say, I would say when teaching programming, the single most important thing is "amount of work required to do something the user feels is interesting". Once they are interested and understand variables, loops, and functions, then teaching them proper habits and "proper languages" is much easier.

It's like this in diving, there are basically two schools of thought, which I will refer to as PADI and BSAC (I am qualified in and have dived with both).

The PADI way gets you into the sea ASAP. It's only really safe to do this in benign conditions (e.g. warm, clear, non-tidal water in the Red Sea). But it quickly gets people hooked on what diving has to offer, and you can add in skills for hostile waters (cold, murky, strong currents, deeper, penetrating wrecks and caves, etc) later if and when you need to.

The BSAC way involves spending 6 months to a year in a training pool. You have to really, really want to dive to stick with it. They've stopped it now, but they used to test people by having them e.g. tread water for 3 minutes holding a weight belt above their heads (the A-test) which you will never ever have to actually do as a diver. It's meant to produce divers who can handle fairly hostile conditions on their very first sea dive (tho' IMHO it doesn't).

I also don't know why he had difficulty with the Python tutorial. For me, as someone who only knew R when I read it, it helped me get up and running with Python very quickly. I actually think its one of the best introductory tutorials I've read for any programming language (and as I have an awful tendency to attempt to learn too many things at once, I've read a lot of programming tutorials).

I don't mind the tutorials myself since I have 10 years of experience (mix of undergrad, industry, and grad school), but I was trying to analyze the language from the perspective of a beginner. I figured it wasn't totally fair to see explanations in the experienced programmer's tutorials, hence trying out that book.

I actually am an experienced programmer - just not in Python yet. ;) I wrote the post from the perspective of someone with a keen interest in computer science education. My specialty is teaching beginners, whether it's a week-long course for eighth graders or non-major undergrads. This context is likely not clear in the post on its own.

When learning Python, I looked at it through the lens of someone just getting started with programming. While it's not really possible to do this in a completely unbiased way, that was where my musings came from.

In terms of your thoughts on programming: I find them interesting. I think it's a reasonable perspective. For the audiences I work with, it can be important to hook students early on with the cool stuff or else you might lose them too early. I personally hope we can then get them into what you define as programming, but even if we can't, at least they leave with something.

> This context is likely not clear in the post on its own.

No, it wasn't--knowing the context actually makes your post quite a bit more thought-provoking. What languages have you programmed in?

I admit I get used to writing with the assumption that my readers know where I'm coming from. This is the first link that has ended up here (I didn't even know it for a while!), and it's a good reminder for me to ensure I work the context in.

The easiest way to list the languages I know is to share this: http://gailcarmichael.com/work/technical

From the processing wiki http://wiki.processing.org/w/Python_Comparison:

Python:

a = [5, 10, 11]

if c >= 1 and c < 20:

    # Statements

Processing:

int[] a = {5, 10, 11};

if ((c >= 1) && (c < 20)) {

    // Statements

}

Python seems much more English-like and doesn't require the beginner to figure out and memorize what && means or that you have to memorize all the types or at least the ones you want to use for an array and where the brackets go when using an array. I program C and Wiring and early on I remember that I always had a hard time figuring out where the brackets go and whether I needed an array of doubles or float or integers, depending on what I need to do. Also they should warn you, you need to know how many elements are in the list beforehand and you can't resize them later.

The author of the article reminds me of a guy I worked with who still programmed in FORTRAN and said the use of whitespace to denote blocks seemed "icky" and hates it. Just keep an open mind and you'll do a lot better than him in the industry. He is out of work these days...

I don't think it makes very much sense to evaluate a programming language for beginners on the basis of how "English-like" it is. Boolean operators, to reference your example, have a considerably more precise and restrictive meaning in both languages than the word "and" does in English. Sounds like misplaced skeuomorphism to me. If anything I've found that the apparent (and shallow) similarity to familiar concepts interferes with learning, rather than helping.

I think it is a stretch to call "and" a skeuomorph. If a skeuomorph exists, it exists in Boolean algebra, because that is the word George Boole used.

This is a poor example since python can chain the comparison:

  if 1 <= c < 20:
      # statement

I think this is more intuitive for someone first learning a language.

It is certainly more intuitive to a scientist.

I have to say that I feel like this discussion often gets bogged down by thinking about language semantics and how that may help/hinder learning and development as a programmer.

For most people who want to learn to code they've experienced or seen something that has excited them in some way. This could be anything from a website, an iphone game, an error on their bank statement, or the tessellated feature on the side of a building. Someone who is excited by the visual feedback of a Processing app may not be excited by the simple high-level magic you can do with NLTK, or the funny things that you can do to a webpage in the developer's console.

That said, I've been following Processing since it's early betas and I think it's a fantastic first programming language -- not just because of the mechanics and ease of use -- but the fact that there is a giant community that fosters and encourages exploration in a way that humans can understand.

Good point about community. That's one of the things I really like about Scratch for the younger audiences (though I have also successfully used Scratch with adults as well!). Is there not much of a community with Python? I admit I haven't really looked yet.

I think the same case can be made for JavaScript. With JavaScript, you are in a familiar environment (the browser) and get to do cool stuff immediately. The distance between knowing no JavaScript and making something appreciable is very small, so you get up and running rather quickly.

I also found the JavaScript model--no classes, functions for scope and very lightweight objects very simple and easy to understand. JavaScript is a very small and mostly elegant language, which I think makes it simpler to pick up.

It has its warts, but so does almost any other language (don't get me started on Python). Besides, a lot of the warts (e.g. no new scope in loops or statements) are only issues if you already know a C-like language; ignoring syntax, scoping that way actually makes more sense. I think its simplicity and being in the browser more than make up for its faults, especially in a didactic role.

I wander if that same train of thought would also apply to something like Lua. Its also a lightweight dynamic language, but it is less warty and even though it doesn't come installed everywhere it is very portable.

Well I think Lua would be a better starting language than Python, but only on its merits as a language.

My core point about Javascript is that it also comes very well integrated into a familiar environment (the browser) which makes it very easy to write beat programs not tied to a CLI.

In my experience, that is much more difficult to do with a normal GUI toolkit, especially for a beginner but also very exciting. Making a neat GUI program, especially when starting out feels great and really motivates you to learn more. Or, at the very least, that was my experience when starting out.

I sometimes worry about starting with such forgiving languages, but I suppose it really depends on the audience, and how well things are taught.

I can't say much about Python, but I can vouch for Processing as a beginner's language- I've used it with great success to teach game programming to middle-schoolers and high-schoolers. In general Processing does a good job of easing beginners into the important parts of Java- sequential code, procedure definitions and eventually classes- without quite as much boilerplate. After a few days of Processing I usually try to cap things off with writing a command-line application in ordinary Java, and usually the only mysterious thing I have to explain at that point is what the "public" modifier does.

Processing was my first "real" programming language[1]. It's not bad but it doesn't have anonymous functions! It does provide a language with a small set of API functions for the user to manipulate graphics with; If someone was intending to learn programming because they want to make a game, I'd suggest they learn Processing over Python, but if they wanted to become a learn more about CS concepts, data structures, algorithms, etc, I'd suggest Python instead. (I know... people don't know data structures exist before they know about programming, but I'm saying I might be able to figure it out from what they want to do with programming.)

[1] My first real programming language was BASIC. I moved on to processing when I got sick of it and didn't know why. Now I do, the only data structure in the BASIC I used was the array and there were no functions, just procedures where you have to use boilerplate to get them to return values.

Python isn't exactly known for its anonymous functions either. If you're looking to learn CS, I really suggest Scheme a la SICP (you don't really have to start with SICP because there are a bunch of other great books, but they trend to have similar motivations). Scheme also has the advantage of being a much simpler and more consistent language than any of the other ones mentioned here.

Should have tried BBC Basic, despite being 30 years old it's actually very modern.

This conclusion is surprising to me because isn't "Processing" basically some subset of Java? I would have imagined that it would inherit some of the issues with Java as a first language: adding some extra confusion of static typing and a compilation step, plus being relatively verbose. It seems that by choosing Processing you're basically trading the dynamic environment of a Python REPL for ease of starting out with graphical programming. I genuinely don't know which would be more valuable for non-programmers.

Processing removes a lot of the verbosity associated with Java. I'd say it's less accurate to call Processing a subset of Java, and more a preprocessor that write all the boilerplate for you along with a set of very high-level beginner-friendly APIs.

There is also SPDE for people who prefer a superior language with all the benefits you mentioned.

From the site it looks like SPDE uses Scala instead of Java, do you really think that's a serious choice for teaching non-programmers though?

Absolutely. A lot more than Java, in fact.

I think the element of visual feedback is huge in picking up programming. It's a shame there's no "processing but with python instead of java" type environment.

Better yet, Lua, which has fewer syntactic oddities. One of my big misgivings about Python is significant white space, which I suspect is weird for people used to word processors, not plain text.

...and if the author is looking for some visual feedback from their experience, there is Löve, a 2D game engine for Lua. It's very easy to code.

Check out NodeBox: http://nodebox.net

pygame works well for this.

There is pyprocessing, probably others: http://code.google.com/p/pyprocessing/

Check out Turtle: http://docs.python.org/library/turtle.html

I think it's a shame Codecademy (to the best of my knowledge) hasn't incorporated some more visual lessons into its tutorials by changing the CSS for HTML elements or by using Canvas. There are a lot of lessons with numerical loops which might be livened up for beginners if the loops moved some coloured circles around a canvas, say.

Personally, as a teenager I read some C books but never wrote more than the 10-line examples in the books until I discovered the Allegro graphics/game library and realised that I had all the tools I needed to make a Tetris clone, a 2d platform game, a software synthesiser... (none of which I ever finished, but oh well!)

edit: I meant the Codecademy Javascript classes; obviously they have static CSS and HTML classes too, but last time I looked there were no tutorials to use JS to animate a web page. Maybe there are now or will be soon.

I cannot comment on the merits of either as a first language, since I don't know Processing and Python was not my first language (although it was really easy to pick up for me), but I do wonder why people think learning stuff should be easy these days. Almost anything worth doing is going to be difficult.

I don't entirely disagree, though I don't think that something needs to be difficult for the sake of it (I also don't think that's what you were saying). I happen to have a keen interest in teaching beginners about CS and programming, and know that it can be especially easy to lose a non-typical student early on. How you approach the first attempt at teaching a programming language really does matter.

I agree that the first attempt matters a lot. Which is why I am against hiding the difficulty. Perhaps this stems from personal experience, though, because I had a pretty effortless academic life until I hit university, where work was actually required to pass. I floundered and wasted a couple of years before gaining the gumption to just sit at a table for hours trying to understand stuff. Conversely, a friend of mine who consistently did not do well when we were in secondary school even though he studied while I was playing video games breezed through university. I think having things too easy at the start leads to having less backbone when you encounter difficulties later, which is why I think an approach of convincing students right at the start that "this is going to be difficult, but it is going to be so worth it" might be better for them.

Of course, this is just my opinion, formed from a sample size of 2, so take it with a large pinch of salt. :)

Certainly a valid opinion. :) It's a good point that hiding the difficulty could cause problems later. But I would personally prefer to focus on the difficulty surrounding how to think when it comes to programming rather than issues with syntax.

I realize it's a different language, but how about Ruby-Processing? It's a wrapper of Processing's methods but in Ruby. Here's the link https://github.com/jashkenas/ruby-processing. It's much less verbose than Java and also has a very handy watch mode which reloads your sketch every time you make a change.

As everyone has an opinion, here is mine:

From teaching programming, my take away is LOGO works best as a first programming language. The visual feedback helps with understanding commands, procedures/functions, breaking down larger problems (house) into smaller problems (square) and helps with understanding reuse (square).

Used Java, Perl, Python and C as alternative first languages, LOGO worked best.

The Turtle Graphics module ships in the standard library.

http://docs.python.org/library/turtle.html

That said... it really didn't do a big difference for me. As a kid, just having "circle", "line", "ellipse", "plot"(point), etc in BASIC were more intuitive than LOGO, and I tried both around the same time. Keeping track of the turtle and the pen state were a nuisance for me, instead of helping with the world model as teachers claimed. I also found silly text games a lot more fun to both make and play, I guess I was a bit less of a "visual" person than the average kid. I did love sprites and interaction though.

As for Python vs Processing, I don't think the difference is massive as a first language. I'd pick Python so then the student has a wider spectre of development afterwards. Processing if I intended to introduce Java later on. But I won't.

I have no personal experience, my first things were POKEing machine registers and after some GOTOs writing assembler.

That was the second natural step after BASIC in 8-bit times. Looking back I think it was quite a sensible learning path.

Nowadays we waste a massive amount of time discussing philosophy and nuances instead of getting sh*t done.

To me it's more about how to hook people (especially non-traditional CS students) rather than ensuring they can continue using the tool later on, though that is a bonus. But on that thread, I don't doubt that Python can be useful even though I haven't made use of it myself quite yet.

I can say that I use Processing all the time because it's so easy to make simple graphical programs. It has been particularly useful for prototyping little game ideas and making applets to explain graphics concepts to students. Depending on what sort of career path someone has, Processing might be really useful far beyond being a pathway to Java.

But is it any simpler than other more open-ended tools? Python+pygame is really popular for prototyping little game ideas, for instance.

I think the point about choosing Processing, for most people, is the simple and well-established path to do:

1 - graphic-oriented apps

2 - stuff that can run in the browser (although Java applets are a massive PITA, sadly, and are slowly but steadily being phased out)

3 - not much else (actual feature: the excess of choice is overwhelming for a beginner)

And then I have this concern that many students, when already proficient in an "introductory language" never quite find the motivation to jump to another language with significantly different structure and syntax. Since proficiency in an introductory language is achieved rather early, it becomes a dead end before they can develop a "real taste" for advanced programming. This has happened to a lot of people I know. Many of my friends started in the 80s with Sinclair BASIC or some other BASIC (C64, C128, Oric, MSX, etc). These have, for the most part, enough built-in graphic primitives to toy around a lot and make simple games with little experience, even with the limited hardware of the time. But then, the next step in order to overcome these nice but slow interpreters was usually assembly or complex compiled languages (usually proprietary implementations, expensive and with obscure support). So they stopped right there.

It's not so bad now but the wall is still there.

Valid points. I wonder if stopping with a tool that does what you want or need is necessarily a bad thing? I personally hope we can get people into the more advanced stuff as well, but not everyone is getting a CS degree. So maybe it's ok if they don't continue. Then again, it is a shame if they stop programming at all because they have done all they can with the tool they learned.

Yes, I agree... especially to the last sentence.

I cannot reconcile that someone would simply "stop learning" because "the tool does all he or she needs"... I think it's more about being unable to discover any more.

I don't think I'd ever stop learning because I'm content with my knowledge and it's all I need. I think I might get stuck not discovering new interests because of my own limitations or that of my limited environment.

However it's also true that you can have different interests and those be unrelated to programming. It just sounds wrong to me somehow, since programming is so all-inclusive and so practical for virtually any field.

I actually wish we talked about LOGO more often. I personally don't have experience with it, and that's probably because it seems to be somewhat of a lost language. This post makes me want to see it make a comeback though:

http://computinged.wordpress.com/2012/04/07/we-used-to-know-...

wasn't Logo what was used for learning?

It was popular in the past. I think it has become less popular since. One of my favorite professors was a big proponent of Logo, but now he seems more interested on variations of Scratch (a neat visual language developed with didactic aims).

Sorry for late reply, but after viewing videos on Scratch it seems more like a lego not a programming language. Does it help in teaching programming?

I just noticed this comment. It does indeed help teach programming. I use it to start students off in understanding booleans, if statements, loops, and variables. It's very fast to get going and to experiment with visual results, and the way the blocks snap together makes it easier to put the right types of expressions in the right places.

Reply on news.ycombinator.com