Ruby : Academically Viable?

by Gregory Brown

With the decent success of the last post, why not throw another opinion into the mix?

This is something that comes up every now and again on RubyTalk and other community forums, but it always starts something like this: "Wouldn't it be great if we could start teaching Ruby in schools instead of C/C++/Java/Forth/Lisp/Fortan/COBOL/BASIC/Brainf*ck?"

48 Comments

jake
2007-05-11 15:18:31

What I mean by that is the most annoying thing about a first or second year college course is that you're either receiving lectures on ideas you can't implement because you have no idea how to get a compiler to work, or you're getting lectured on a compiler and you haven't covered any concepts or things that actually *mean* something.


Thank God.


I thought i was the only one. I felt like a complete idiot my first 2 years of CS class because i didnt know ANY of the languages that were being taught. I compare it to a someone being asked to write a paper... in a foreign language. Sure, writing the report is easy, if you already know the language and you know how to write, but if you have to learn both at the same time it becomes really difficult.



I think they should start all the core classes in Ruby so that you can get a concrete understanding of the foundations of CS (OOP, Automata, Design Patterns, etc) with a language that is forgiving and then move on to the tougher languages and lower-level (microprocessor architecture, OS, etc) stuff.


--jake

Gregory
2007-05-11 15:40:31

I think they should start all the core classes in Ruby so that you can get a concrete understanding of the foundations of CS (OOP, Automata, Design Patterns, etc) with a language that is forgiving and then move on to the tougher languages and lower-level (microprocessor architecture, OS, etc) stuff.


Yeah, I totally didn't grok C properly in my Intro/Intermediate courses that teach C on it's own. Once I saw it in my operating systems, it made a whole lot more sense.


As far as OOP goes, It's probably worth showing both Java/C++ style OOP and Smalltalk/Ruby style stuff, but Ruby would be a nice, clean way of showing the fundamentals, and then you could layer in the more rigidly structured languages when the student has a decent chance of understanding 'why' those design decisions are valuable.

JB
2007-05-11 15:50:05
Personally I would start w/ Python.
Cleaner and less complicated than Ruby.
Gregory
2007-05-11 15:53:43

Personally I would start w/ Python.
Cleaner and less complicated than Ruby.


Sure, Python is a great learning language. However, the languages are similar at the fundamental level, so using either for algorithms would do fine, and this is a ruby blog :)


Also, I think that Ruby's OOP model would be slightly more appealing to teach, as its purity avoids having to delve into language specific explanations.


Can you think of some specific strengths Python would have over Ruby that aren't wholly subjective?

sean
2007-05-12 08:32:02

def bubbleSort(a)
0.upto

Here comes the "ugh"... Why the period between 0 and upto? Because "0" is an object. What's that? It's a thing that lets you write "thing.function" instead of "function(thing)". Why? It gives some programmers serious wood.


The good thing about C as an introductory language is that it has few hidden semantic or implementation details. The good thing about Scheme is that it has few hidden syntactic or (abstract) semantic details. Ruby is a terrible first language because it has so many defaults that make sense to many programmers, but only because they are already familiar with other languages.

Gregory
2007-05-12 08:42:24
sean:


I understand your point, but:



int i = 0;
for(i; i < some_length - 1; i++) {

}


What about those semi-colons, what's an int? And how do I get an array's length?


I think that particular argument is very weak.

sean
2007-05-12 08:56:08
Gregory: I agree that C loses big-time on syntactic simplicity -- that's one of the reasons some people prefer to use Scheme. Regarding ints and arrays' lengths, these are just facts of life when dealing with a computer. An array is just a sequence of bytes whose length you need to store elsewhere; an integer is 32 (or 64) bits. The advantage of C in this context is that the answer to "what is the computer doing when I tell it *this*?" is usually obvious.


And OO notation is just the beginning. What about sometimes being able to omit parens? do/end versus braces? Bizarro scoping rules? Blocks versus functions? "Hash.new" (from #57)? All of these things are mostly transparent to someone who knows C/Perl/Java/whatever, but not to a normal human.

Gregory
2007-05-12 09:09:02
Quoting Sean



I agree that C loses big-time on syntactic simplicity -- that's one of the reasons some people prefer to use Scheme. Regarding ints and arrays' lengths, these are just facts of life when dealing with a computer. An array is just a sequence of bytes whose length you need to store elsewhere; an integer is 32 (or 64) bits. The advantage of C in this context is that the answer to "what is the computer doing when I tell it *this*?" is usually obvious.


I guess the concern I have is that algorithms don't hinge on all these details of the computer, and I think algorithms are more quickly understood conceptually, providing that they can be demonstrated. I think once you get what programming is all about in algorithmic terms, it is a whole lot easier to understand what the underpinnings are.


To me, teaching C as a first course is kind of like saying 'I'm going to teach you how to drive by showing you what the engine looks like'


Teaching Scheme first is probably a better approach than C, but the trouble I see there is that you end up teaching at *too* theoretical a level too quickly. Functional programming is beautiful, but I think appreciation for it is lost on a first course.



And OO notation is just the beginning. What about sometimes being able to omit parens? do/end versus braces? Bizarro scoping rules? Blocks versus functions? "Hash.new" (from #57)? All of these things are mostly transparent to someone who knows C/Perl/Java/whatever, but not to a normal human.


Of course, and if you get into the way us abnormal humans write Ruby, you can throw all sense of student sanity out the window. :)
But just like you'd gloss over advanced details like that in an introductory course for any language, you could do the same with Ruby. Ruby just might be a bit more forgiving for the folks who wish to experiment a bit than some other choices.


I guess what I'm really saying is that it'd be great if the first two or three CS courses a student takes gives them a chance to get some code running and do something right away. I've taken people with no experience in programming and thrown them at TryRuby, and they seemed to have fun with it and be able to grok the syntax, even if it's only by copying the styles at first.


So it's not that I don't see the value in using other languages, I just am very distressed by the lack of confidence I've seen in most incoming CS students because they get hit with 1000 concepts at once. What do you think?

sean
2007-05-12 09:41:06
Gregory:


I guess the concern I have is that algorithms don't hinge on all these details of the computer, and I think algorithms are more quickly understood conceptually,


I think we're mostly on the same page here. To me, the difference between math and CS is that the latter cares about complexity. One of the hardest things for me when reading mathematical writing is getting used to the fact that they don't think about implementation. Algorithms *do* depend on many details of the machine. This is why Java's "ArrayList" is such an abomination -- understanding the difference between data structures supporting constant-time indexing (Arrays) and constant-time insertion (Lists) is absolutely fundamental.


Teaching C may be like showing people the engine, but I think we're trying to train mechanics, not drivers. A useful higher level of abstraction with the conceptual integrity and reliability of current computer hardware (or consumer automobiles) doesn't exist yet, so we have to train programmers to understand everything down to that level.


As for what I think incoming programming (not CS) students should learn, I'm at a loss. I've spent the last 5 years as a teaching assistant for these people, and the thing that distresses me most is that they're wasting so much time studying something that doesn't matter to them, so they can pay their bills. I believe programming should be learnable in much less than four years, but I don't believe there's currently an easier way to turn humans into effective programmers than learning the details of the hardware.

Brian Guthrie
2007-05-12 10:11:29
The program at Northeastern University (just graduated) uses Scheme for its freshman curriculum (which I didn't enjoy and would not describe as fun) and our algorithms course, which we take in our junior or senior year, doesn't require that we turn in working code (so I used Ruby on it), but it also doesn't include any discussion of typing and compilers: all the homework assignments required was pseudocode. Is this atypical? For a course of this sort, Ruby is already a viable solution, and as nice for that purpose as it is for every other.


I received a fair amount of pushback from professors for my passion for Ruby because it is, admittedly, a pragmatic language, not an academic one, and is in that regard not particularly forward-looking, nor useful for teaching language concepts.

Tony Williams
2007-05-12 21:11:32
Gregory,


Might want to check your links. HacketyHack is at http://hacketyhack.net/ not .org


# Tony

Gregory
2007-05-12 23:23:55
Tony,


Good Catch!


Thanks

Gregory
2007-05-12 23:43:42
Quoting sean:



Teaching C may be like showing people the engine, but I think we're trying to train mechanics, not drivers. A useful higher level of abstraction with the conceptual integrity and reliability of current computer hardware (or consumer automobiles) doesn't exist yet, so we have to train programmers to understand everything down to that level.


You make a good point there, for sure. I guess its the whole "What do you show first" problem, and I'm thinking sneaking some of the practical languages in early might be a way to keep student interest... This is certainly a hard problem though...

Simon hibbs
2007-05-13 06:55:05
I was a CS student back in the late 80s before OOP was widely adopted. The first language we were taught was pascal, then we moved on to more specialist languages such as C or Prolog depending on what courses we took.


I think this worked well because Pascal is a much easier language to get to grips with than C, but still taught all the core concepts. Nowadays I would say that Java or C# would make good first languages. I do believe it's best to start with an OO language first, and these are good general purpose languages that can be coded in a procedural style or an OO style, and have fewer syntactic shortcuts and 'magic' behaviour than Python, Ruby, Perl, etc much as I love them as practical languages.


I agree that we are teaching mechanics, but if you're familiar with Java or C# I think C's syntax is familiar enough that it can be taught to those programmers taking courses that lead deeper under the hood.

Gregory Brown
2007-05-13 07:15:53

I agree that we are teaching mechanics, but if you're familiar with Java or C# I think C's syntax is familiar enough that it can be taught to those programmers taking courses that lead deeper under the hood.


My university actually offers a Java class early but they teach Swing! Then we end up having to discuss threading and events and all of that mess when we're really just trying to learn programming fundamentals...


To me, something like the TopCoder app would be a great introduction to CS if Java were used...

amorphous
2007-05-14 13:15:58
Sean and Gregory circle around a major issue: what should a 'core' CS curriculum require, and in what order should it be taught? Everybody seems to agree there should be a data structures/algorithms course, and some kind of 'lower-level' requirements (assembler, operating systems, compilers). But what should be taught first and what should be in the first one or two courses?


My feeling is the student should come out of the first course with a good understanding of how to use programming to solve problems and how to get from requirements to a working, well-designed and robust program. I think that's about as much as you can fit into a first course. But however you feel, you have to make some kind of decision about what to teach and when.


I like the idea of a language like Ruby or Python as an introductory language because I think the student has fewer details to worry about before starting to try and solve problems (variable typing, as an example). Also, the development and debug environments are smaller and simpler.

Behrang
2007-05-14 14:51:48
Why Ruby while we have Smalltalk?
Gregory
2007-05-14 15:00:47

Why Ruby while we have Smalltalk?


Smalltalk might actually be a good choice, if it's not a little too esoteric. I think the more interesting sides of Smalltalk from an academic perspective would be in the advanced topics, which are less likely to have value in early undergraduate courses.


Are there many universities out there actively using Smalltalk in their academic curriculum? I'm actually curious because the common mix seems to be C/C++/Java/Forth/Scheme/CLisp/etc

Wu Ming
2007-05-14 18:42:48
The more you avoid C, the more it will get you one day.
Stop whining. Learn a real language for real and then all other languages become trivial.
C is not the problem, the teaching maybe, but not C.
Gregory
2007-05-14 18:46:42
wu,


maybe you didn't read the article clearly:


I'm still one of those people who believe that it's a shame most CS programs no longer include ASM, that a working knowledge of C is key to success in any programmer's career, that Forth and Scheme are 'fun', and that math is an important part of the computer science curriculum.


I'm talking about re-thinking which languages we use for which courses, not recommending that we shouldn't teach any particular language. (I doubt an Operating Systems course would make much sense if taught in Ruby)


2007-05-14 20:29:12
What you won't need to do is explain typing, compilers, or a whole bunch of other things that are important, but not in any way tied to algorithms.


Are you serious that this is such the hindrance you make of it?
I cannot believe a first year college student is blocked by that. Sorry.

Gregory
2007-05-14 20:31:34

Are you serious that this is such the hindrance you make of it?
I cannot believe a first year college student is blocked by that. Sorry.


I guess it depends which school. It's a serious problem at my university and talking to folks from a few other places, it seems somewhat common, especially when professors don't have the necessary skills to teach very clearly about the tools students need to use.

sean
2007-05-14 21:56:13
@Gregory -- I've seen the consequences of starting with Java or Java+Eclipse, and they're pretty grim. It's like learning to drive in an 18-wheeler, or learning to fly in a 747.


@Behrang -- Um... because there's more to life than dogmatic Object-bondage?

Noah Gift
2007-05-15 05:42:09
One plus on the Python vs Ruby, is there is a great intro Computer Science text book on Python:


Python Programming: An Introduction to Computer Science


They are both similar languages though, I agree.

Gregory
2007-05-15 06:36:45

One plus on the Python vs Ruby, is there is a great intro Computer Science text book on Python:


Python Programming: An Introduction to Computer Science


Noah, I should read that. If it's good, maybe ORA would be interested in a Ruby CS book :)

Tom
2007-05-15 09:44:46
They teach both .NET and Ruby as part of the CSE 687: Object Oriented Design class at Syracuse University. [The same professor also teaches a web design class, but he has not, as yet, worked with Rails.]
Kenny
2007-05-15 23:25:27
Instead of worrying with the block syntax why not use:



def bubbleSort(a)
for i in (1...a.length)
for j in (a.length...(i+1))
if a[j] < a[j-1]
a[j],a[j-1] = a[j-1],a[j]
end
end
end
return a
end


The only thing you would have to explain is the range notation and that isn't hard to understand because of peoples experience in math. I believe you can work around most rubyisms without any trouble.

rpm
2007-05-16 00:32:37
Python uses spaces in a way that is pedagogically sound
Ruby is sensitive to spaces almost to the extent that its a language bug


Ruby's greatest strengths are more software engineering rather than programming ones : eg. open classes.


My first language choice would perhaps be Haskell

Curt Sampson
2007-05-16 05:22:59
Ruby is far too syntatically perverse for beginners, I think. (I.e., it's very hard to figure out what other things you can do from what you already know--it's complex and inconsistent.) Experienced programmers can put up with this, but for beginners, it leads to the frustration of battling on two fronts: the essence of the problem and the syntax of the language.


I think that, for programming courses, Scheme is a far better language than Ruby. Let's look at what it has that Ruby doesn't:


* Very simple, very consistent syntax.
* The ability to cleanly and clearly express all three major programming paradigms: imperative, functional and OO.
* The ability to easily implement variations of programming paradigms: for example, you can implement and compare prototype-based versus class-based OO.
* Better tools for helping beginners program and debug interactively. Ruby has nothing like DrScheme.


cjs@cynic.net

sean
2007-05-16 08:14:47
Curt: I think people consistently overstate the importance of simple syntax. Scheme's "simple" syntax is convenient not because *people* have an easier time with it, but because it's easier to manipulate programmatically. Humans are pretty good at syntax, so long as it doesn't have what seem like weird exceptions (e.g. "you can put any whitespace between any two tokens *except* after X, where it changes the meaning"). Lisp/Scheme's favored macro-heavy programming style requires simple syntax, but for most other styles of programming, it doesn't matter.
Gregory Brown
2007-05-16 08:57:25
Kenny, it's true that you could use

for i in (1...a.length)


But you pretty much will never see for used outside of Rails, which is why I went with downto and upto. I was also trying to match the pseudocode. I suppose I almost never use downto and upto either, though :)

Robert
2007-05-16 10:49:31
If Python was the S H IT then how come Ruby got so much momentum right now?
Gregory Brown
2007-05-16 10:54:04
I wish this discussion didn't so quickly turn into a language comparison thread. My question was mostly on whether or not people thought Ruby was viable for certain courses...


There were some good posts about this, but they are being drowned by My Language Can Beat Up Your Language.


Save this discourse for DHH's blog, folks.

Cyrus Hall
2007-05-16 11:41:14
I can happily say that at the University of Lugano we already use Ruby in several classes, although none of them are on algorithmics. Students have found it a very engaging language, and I do not think it is a stretch to claim it has infused several of them with a fresh interest in computer science. The point at which it is currently taught in the curriculum has it following Scheme, Smalltalk, and some very intensive Java. As such they are prepared for the language in at least a couple ways:


* Between Scheme and Smalltalk, they have been introduced to most of the language features they will confront in Ruby, albeit in different syntactic guise. This means adoption is quite fast and painless. Some of the students that struggle with Scheme during the first semester end up with a much firmer grasp of the language after seeing Ruby.


* They have just been bombarded by Java for two semesters, and as such Ruby comes in the door like a breath of fresh air. Their lungs perched by the arid landscape of Java, Ruby flows like a gushing river of....you get the point.


Anyway, the experience has been over all positive. One constant problem has been the state of Ruby on OS X, which is less than excellent on a new install.

Steve
2007-05-17 09:42:31
I would argue against using Ruby as a first language, and Perl and Python. I liken learning C/C++ first to the same way that you learn Calculus. First you learn how to do limits then you get shown the "right" way with derivatives. You have to know the foundations of things so that you really understand what's going on in dynamic languages like Ruby/Python/Perl.


C/C++ is a building block language. It's used everywhere, and a basic understanding gets you a long way in understanding how things work in dynamic languages. The learning curve is a lot steeper with C/C++ but in the end you'll know *exactly* how those algorithms are working. This is kind of a bottom up approach (I'm leaving out ASM because it sucks :) ).


Now coming from the other perspective. If I learned Ruby/Python/Perl *first* and then had to learn C++ I don't think I'd be very motivated to do so. This would be a top-down approach, where you learn higher level abstractions first and then (if ever) you learn lower level abstractions. I say "if ever" because new grads coming out of school know how to use the C++ standard template library, but they can't tell you why a vector would be slower than a linked list. Or how you would implement one if the wasn't available.


I'm kind of biased towards that way of learning. The attrition rates for the first few cs classes at my university were (and probably still are) horrible. The question is would the attrition rates be better or worse if they learned a dynamic language first and then 2 years in they had to use C/C++ to write code for OS/Compilers. In the first scenario I would have 2 years of learning C/C++. The second scenario I would have a quarter/semester or maybe learn it on the spot.


I don't know which way works best, maybe learning a higher level language would have been easier. If that language should be Ruby, well If I go down that road it'll be a flame war on why "My" language is the best. Having had to grade Perl assignments, let me tell you the whole "you can do it so many different ways" makes you go nuts when you get 30 different solutions to the assignment.


As to the argument of figuring out compiler errors, yeah they're a bitch to figure out. But the dynamic languages still suffer from syntax/semantic errors that beginners are going run into. Especially when a variable can "become" something else, if used in an array context or a scalar context. The errors just show their ugly head in different ways.

Gregory
2007-05-17 09:50:17
Steve, you raise a lot of good point.


In the below however, I think you're talking about perl, not Ruby.



Especially when a variable can "become" something else, if used in an array context or a scalar context.
Steve
2007-05-17 10:46:42
Yeah that problem is Perl, but you also have the problem of strong typing where the beginner thought that the variable held an integer but now it holds an array (through some semantic error). I know there are ways around it (experience and style mostly), but it can be a stumbling point.
Gregory
2007-05-17 10:51:36

Yeah that problem is Perl, but you also have the problem of strong typing where the beginner thought that the variable held an integer but now it holds an array (through some semantic error). I know there are ways around it (experience and style mostly), but it can be a stumbling point.


I guess this is just a matter of how your brain works, but to me, it's more natural for humans to think of variables as just names for something, and more natural for computers to worry about typing.


This isn't a troll to get into a typing argument, I'm just saying that the lack of explicit type declarations is what I found valuable about using Ruby for teaching algorithms, not what I see as a stumbling block. It's interesting to see this argued from a different point of view.

rpm
2007-05-17 20:55:06

C/C++ is a building block language...


That assumes there is objectively something called a building block. Is there?


  • If the machine or hardware is the fundamental then C (and more so assembly) is the BB
  • If everything-is-an-object then its java and smalltalk
  • If structured programming is the way to go (with the emphasis more on structured than on programming) then its Pascal.
  • If everything is a computational entity (aka lambda term) then its scheme.

And so on.


All these are right and become more and more wrong as they are taken to the extreme.


For me what's wrong with the CC++ as-building block is that it emphasises algorithm over data-structure.


Thats like a physicist saying energy is all, and ignoring matter and therefore mechanics.

ladushkaivanova
2007-05-17 21:24:44
Да, может быть сайт www.oreillynet.com не для моей просьбы, но надеюсь , что и здесь могут найтись добрые люди, которые будут в силах мне помочь.

Практически нет денег и мне нужна любая работа, особенно если она будет связана с интернет. Мне 25 лет. Умею пользоваться компьютером. Работаю с полным пакетом Microsoft Office. Хорошо знаю английский. Приятная внешность. Зовут меня Лада.

Robert Fischer
2007-05-23 11:16:37
Sorry, but this is a bust. Were I to teach entry-level CSci, I'd take Ruby over C++ (which I learned on), and certainly over Java, but you can do a lot better.


Let me start off by saying that Ruby is an excellent language for established programmers. It was designed and geared towards people who wanted to write meaningful code without much boilerplate or worrying about implementation details. It's more elegant than its counterparts and generally a slick way to work. For its niche, it's good.


Unfortunately, to even begin to work with Ruby, you're looking at needing to first teach object oriented design, and to explain the meanings of the methods in the standard library which wrap idioms.


Once the students have a grasp of that stuff, you're going to have to deal with bugs arising from bad run-time typing ("My id is 4? WTF?" / "Oh, you probably have an errant 'nil'."), and the fast-and-loose syntax that Ruby inherited from Perl which can be its own source of bugs.


And, of course, you're going to have to then *read* your student's Ruby -- a feat that is tricky even in the most rigorous languages.


The Ocaml language, on the other hand, leverages a syntax that looks like one many CSci students are familiar with -- mathematics. It's got Ruby's duck typing while still having type safety. It's got a top level for noodling and can be run as a scripting language.

Gregory Brown
2007-05-23 11:37:11

Unfortunately, to even begin to work with Ruby, you're looking at needing to first teach object oriented design, and to explain the meanings of the methods in the standard library which wrap idioms.


I don't think this is true. Teaching Algorithms does not depend on language paradigms, unless you want to leverage those paradigms.


The notion that you need to have a firm understanding of OO to write algorithms in Ruby seems completely like a strawman argument to me, and everyone is just using it to tout their pet languages.


I wasn't suggesting teaching idiomatic Ruby in academia, but rather using Ruby's simplicity at run time as a feature. It seems like there is a lot of resistance here, but no argument I've seen has felt like more than religious views.

Robert Fischer
2007-05-23 13:02:08
Unfortunately, to even begin to work with Ruby, you're looking at needing to first teach object oriented design, and to explain the meanings of the methods in the standard library which wrap idioms.


I don't think this is true. Teaching Algorithms does not depend on language paradigms, unless you want to leverage those paradigms.


That's a fine theory, but it falls down in details -- any implementation you deal with in Ruby is either going to circumvent the very simplicity Ruby, or you're going to encounter objects and methods (and probably Mix-Ins and other polymorphism).


The problem is that Ruby's runtime simplicity comes from effectively wrapping many very common programming tasks -- but those tasks are foreign to your students. The methods attached to the standard library objects (particularly those that are based on blocks and collections) are basically just short-hand versions of standard imperative structures. This is its power, and it is a welcome relief to the experienced programmer, but it makes the learning curve steeper for newbies who don't know what you are doing or why.


I wasn't suggesting teaching idiomatic Ruby in academia, but rather using Ruby's simplicity at run time as a feature.


If you're avoiding "idiomatic Ruby", what's the advantage of Ruby? Wouldn't it be better to use a language whose idioms are more natural to the problem set? In the case of algorithms, that means using a functional language.

Gregory
2007-05-23 13:07:50

The methods attached to the standard library objects (particularly those that are based on blocks and collections) are basically just short-hand versions of standard imperative structures. This is its power, and it is a welcome relief to the experienced programmer, but it makes the learning curve steeper for newbies who don't know what you are doing or why.


I imagine you could teach an entire undergraduate algorithms course without ever touching Ruby's standard library. What classes are you talking about?

Gregory
2007-05-23 13:08:43
In the above, I mean object classes, not classes of students :)
Robert Fischer
2007-05-23 13:32:22
I imagine you could teach an entire undergraduate algorithms course without ever touching Ruby's standard library. What classes are you talking about?


Well, even in your one bubblesort example...



0.upto(a.length-1) do |i|
(a.length-1).downto(i+1) do |j|


...you've got "upto" and "downto" being called as methods: once on a constant, once on an expression. This requires not only an instruction on objects and methods, but to clear the mental hurdle of Ruby's "everything is an object -- no, really!" concept. That concept is key to some of the cutest tricks in Ruby, but it's complicated enough that even the Java language designers didn't get it. ;-D


Why not use a language whose syntax and idioms are closer to problem space? If you're talking/teaching algorithms, you should really be using a functional language.

Gregory
2007-05-23 13:42:51

...you've got "upto" and "downto" being called as methods: once on a constant, once on an expression. This requires not only an instruction on objects and methods, but to clear the mental hurdle of Ruby's "everything is an object -- no, really!" concept. That concept is key to some of the cutest tricks in Ruby, but it's complicated enough that even the Java language designers didn't get it. ;-D


I see your point, but you're using the wrong terminology.
upto and downto are part of core ruby, not the standard library.


This is the standard library:
http://www.ruby-doc.org/stdlib/


I guess that was the source of my confusion with what you were saying.



Why not use a language whose syntax and idioms are closer to problem space? If you're talking/teaching algorithms, you should really be using a functional language.


What I like about Ruby is that it's fairly versatile in that a light understanding of OO is enough to get started, and it can be understood intuitively pretty quickly (enough to get the point across), but that it's not limiting you in practical applications in the way that a functional language might.


I guess what I'm saying is that to me, the reason why Ruby is a good choice (or Python or Whatever-Equivalent) for a first year course is that it avoids the complexity of Java/C/C++ and also avoids the possibly 'too theoretical' nature of functional languages.


I think the biggest issue here is that Computer Science is way too broad of a topic, and Algorithms may still be too wide a space to be talking about. I wish I could find a better way to describe the specific area I think Ruby would be most valuable.


I must confess, OCaml and Haskell have been on the 'too learn' list for a while though...

sean
2007-05-24 06:32:34
Why not use a language whose syntax and idioms are closer to problem space? If you're talking/teaching algorithms, you should really be using a functional language.

@Robert: You say this over and over, but it's just not true. First, syntax is orthogonal to whether or not a language is "functional". Second, most algorithms are published in a procedural or imperative pseudo-code that looks a bit like Algol, so reading the original descriptions is easier with this mindset. Third, an important part of learning algorithms is understanding their computational complexity, which can be hard to grasp from a functional description. Finally, many algorithms are not pure, and expressing them in a pure functional language is awkward. For example, consider Dijkstra's shortest paths algorithm, which at each step updates a heap of nodes to visit.


You could make the argument that an intro course should use a functional language, but not an algorithms course.