tags:

views:

508

answers:

9

I'm planning on teaching a programming elective next year at my high-school. The students would be from 9th to 12th grade with minimal programming experience in ti-basic at best. I've yet to decide on what language to use in it. I fear that if I use something ultra-interpretive and abstract like Ruby or Python I'll be doing them a disservice if they want to learn a lower level language later on. Am I right, or should I not worry about it and use something shiny and cool?

Edit: I'm going to go with Ruby after-all. Thanks guys.

+10  A: 

The most important thing is that they're having fun!

You'll be doing them a disservice if you put them off programming by instructing something too boring. Low level languages certainly have boring aspects.

Teach them high-level programming and encourage play and experimentation. As for using Ruby for this, others are having similar thoughts.

molf
I'd just add that a fast feedback loop is really important for learners to have fun. Anything with a compilation step is bad because that small interruption breaks the flow. Combine that with static typing and many learners are likely to experience programming as tedious and frustrating, and not stick with it.
Stuart Ellis
+1  A: 

BASIC didn't stop me from learning assembly language. In fact, it probably encouraged me to learn assembly language!

Nosredna
+5  A: 

Using Ruby seems like a great idea to me. Students who are inclined to pursue more advanced concepts (classes, modules, mixins, etc.) would be able to do so, while those less inclined students will find its friendly syntax unintimidating.

yalestar
+3  A: 

I started with BASIC (as did many others) ... and like riding a bicycle, most people start with training wheels.

I think programming can be challenging enough at a high-level without worrying about introducing the close-to-the-metal concepts.

The beauty of a language like ruby is that it is concise and expressive and has all the depth you need to go from hello world through to advanced metaprogramming.

Toby Hede
+2  A: 

Things like Ruby's willy-nilly syntax and Matz's emphasis on "fun," while conducive to getting kids to potentially enjoy programming more, could foster bad coding habits from the onset. It's a good language to teach beginners, but I wouldn't necessarily use it as the "toss into the pool."

That being said, students who would excel at programming would most likely be immune to any negative effects that Ruby's freedom could harbor. If a kid thinks logically and likes problem solving, chances are he's going to enjoy the class and take a lot away from it regardless of what language you teach.

Here's another SO thread that you might find useful.

Evan Meagher
Willy-nilly? Rather subjective/argumentative without examples: care to expand/justify?
Mike Woodhouse
Things like Ruby's flexibility with regard to using curly braces, do/end, or neither. Or how using parens tends to be optional. It's not a big thing, just it could potentially lead to unreadable code when taught to beginners.
Evan Meagher
A: 

Most important is to have interesting problems to solve. They should see the language mainly as an instrument to solve a problem at hand. Later, if they become interested, they could find beauty in the language itself. But I think the first language is not that important (ignore what Dijkstra said :)). The language should be adequate to solve the problems you're going to present, and not to be too difficult or ugly. Ruby probably passes these criteria.

Igor Krivokon
A: 

If this class is intended for a wide range of students - e.g. those who are naturally inclined and interested, and some who many not have much natural inclination - I do not think it would be a very good idea. Object oriented programming requires a fair amount of abstract thought. It can be quite difficult to grasp without any foundational concepts of how to "instruct" a computer in general. I think it would be much better to start with a very simple procedural language. OOP builds on that. Students who take to it will have no problem making the leap to Ruby-like languages fairly quickly, but starting there will likely leave many lost and floundering.

Rex M
Are you trying to suggest that a non-abstract assembly language is better?
Chuck
@Chuck no, I said it's easier to learn procedural before trying to learn OO. Ruby is pure OO.
Rex M
The OO in Ruby can be as prominent or hidden as you choose to make it. You can write in a procedural style if you think that's more appropriate and migrate gently toward more object-based code later. I suspect that well-taught, OO would turn out to be easier to learn, though.
Mike Woodhouse
@Mike perhaps. I am speaking from my experience teaching young teen-age people basic programming. Maybe I'm just a bad teacher.
Rex M
A: 

What about Common Lisp or Scheme? Many first semester college programs use these languages. You could call yourself a college-prep CS course then! :)

JP Alioto
A: 

Ruby would be a good language, IMO, but the biggest thing to be aware of is Ruby's encouragement of leaky abstractions and "Magic Code" that hides a lot of implementation behind a heavy dose of syntactic sugar. Actually IMO the biggest drawback of Ruby is this notion to hide things behind English-like syntax that makes it easy to read, but you are left scratching your head as to what exactly is going on under the hood.

However, I think that Ruby is a fine language to teach people programming due to its clean syntax and expressive style of programming; just be careful about encouraging "cargo cult" programming.

Wayne M
So on one hand Ruby is problematic because it leaks implementation details and on the other hand it's problematic because you can't figure out how things work under the hood (i.e., its abstractions don't leak at all)?
Chuck
Ruby is interprated. If you want to know what is going on underneath, go read the code! What's wrong with making your program self documenting, then reading the implementation underneath. People don't have to like ruby, but this "Magic Code" nonsense is just that. Utter nonsense.
railsninja
I do like Ruby, that's the funny thing. Yet every time I try to learn it, I get stuck because of the proliferation of writing abstracted code that is easy to ready, and hard to understand. I'll take explicit over implicit any day of the week, because at least then I know exactly how things happen instead of relying on "magic".
Wayne M
@Wayne M, can you give an example of "Ruby leaking implementation details" ? im curious
banister
Look at how the Controller works in Rails; you write one line and Rails "magically" knows how to do everything else to wire it up, which is fine for very simple apps... but once you need to do something complex then you *need* to know what is going on under the hood. The "Ruby Way" is to write code like this (heavily abstracted, so it reads like a sentence) but if that code stops working, a programmer could be left wondering "I don't know what's wrong to fix it" because the guts are all hidden under layers of abstractions and syntactic sugar.
Wayne M
@Wayne, Ruby != Rails and i disagree it's the "Ruby Way", though it may be the "Rails Way". Outside of Rails (and i don't do much rails development tbh) I find most Ruby libraries to be very easy to understand and to use. Further, if a neophyte programmer is to learn Ruby (the language) rather than Rails they're not going to encounter such extreme instances of metaprogramming. Also, even if a neophyte programmer WAS to learn Rails, by the very fact that they're beginners they're unlikely to want to "do something complex" (as you say) so should not need to know what's going on 'under the hood'
banister