Teaching Ruby to COBOL programmers

[Wilson_B]

This isn’t a troll, I promise. I’m actually going to be doing this
tomorrow.

My normal Ruby spiel is geared more toward the differences between
dynamic and static langugages, and the power of blocks. In other
words, “Hey, look at what you can’t do in Java.”

This is a whole different scenario, because these people are coming on
board to be web application developers, and their previous programming
experience is 100% mainframe-based. They aren’t going to know HTML,
XML, Java, C++, etc.

What are some key points I should make sure to cover for procedural
programmers?
Things on my list so far:

1. Variables don’t hold values, they are just labels.
2. Objects are nouns, methods are verbs.
3. Structure keeps you sane.
4. Duck typing makes testing easier.
5. Rake as an example of something procedural in an object-oriented
   language.

That being said, I’ve been immersed in OOP for so long, I don’t
remember what the hurdles are.
Thoughts? This is going to be a three hour session, wherein I need to
cover Ruby and at least the bare beginnings of Rails. Obviously an
in-depth treatment of either of those things is impossible in that
timeframe, but I do want people to leave feeling like it’s not a
magical tongue spoken by elves and wild spirits.

Thanks,
–Wilson.

[Wilson_B]

I like the idea that to a great extent what you are trying to do in a
lot of programming tasks is reduce
major points to lists. If things look like nested messes you are not
getting it right. Also, you design objects, when you can, to represent
real world concepts, not to accommodate artificial internal conveniences
you find. The object to a great extent is not to make it go, but to
make it maintainable so it will continue to go.

xc

[Wilson_B]

On 2/28/06, Wilson B. [email protected] wrote:

Thoughts? This is going to be a three hour session, wherein I need to
cover Ruby and at least the bare beginnings of Rails. Obviously an
in-depth treatment of either of those things is impossible in that
timeframe, but I do want people to leave feeling like it’s not a
magical tongue spoken by elves and wild spirits.

Forgetting OOP for a moment, and thinking WWW instead…
It’s stateless.
Learn how to manage hidden values.

Those were the two toughest items for me when I moved to the web.

[Wilson_B]

Wilson B. wrote:

What are some key points I should make sure to cover for procedural
programmers?
Things on my list so far:

1. Variables don’t hold values, they are just labels.
2. Objects are nouns, methods are verbs.

… and methods belong to objects’ classes. I’d be emphasizing OO. To
me,
that means getting across the idea of classes as (more or less) types of
objects, whose behaviours you define, and objects as instances of those
classes. There’s also inheritance and polymorphism to be covered.
Mixins,
too, for bonus points.

3. Structure keeps you sane.

Does this just mean defining classes and modules and naming files
accordingly?

4. Duck typing makes testing easier.
5. Rake as an example of something procedural in an object-oriented
   language.

You’ve got 3 hours, you could cover metaprogramming (see Chapter 6 of
Why’s
(Poignant) Guide to Ruby and Dwemthy’s Array) to give your people an
understanding of how Rails’ before_filter, and has_and_belongs_to_many,
etc.
work behind the scenes. It is ancilliary, though, and you may get better
value by looking at the Rails framework specifically (build a to-do
list) or
drilling OO (read the rubyquiz.com for some problems and nice rubyish
solutions).

STOP RUN,
Dave

[Wilson_B]

Stephen W. wrote:

However, in this case… COBOL -> Ruby, I’d say forget the WWW
altogether, teach Ruby.

You should be able to quickly teach them how to do the same things they
do every day in COBOL, only in Ruby. You can even show them some OO
stuff without having to dive completely into the OO pool. By doing that
first, maybe you can keep them tuned in awhile longer. Then you can
approach the topics more foreign to your students.

But, the bottom line is that you’re going to have to teach them about
Objects if they’re to learn Ruby.

All true enough.

My own list:

I’d emphasize character-oriented I/O, since they are so used to
fixed-length records read a record at a time.

I’d show them irb, which is fun to play in.

I’d emphasize that “it’s all PROCEDURE DIVISION” – all of a Ruby
program is executed, no real declarations.

I’d emphasize that variables are untyped, and introduce the concept
of object references.

Etc…

When the COBOL guys heard about C++, they were jealous. They made
an OOP version of their own language… called ADD ONE TO COBOL.

Hal

[Wilson_B]

Wilson B. wrote:
…

What are some key points I should make sure to cover for procedural programmers?
Things on my list so far:

1. Variables don’t hold values, they are just labels.

We hear that a lot, but, somehow, it never sounds right. If variables
are labels, why don’t they follow the object around, and become
accessible to other users of the object? How do I calculate how many
labels an object has? Is a label an object? Can you change the text of
the label? Do they ever fall off when the glue dries out?

Anyway, variables do hold some kinds of values, like numbers,
booleans, and symbols, in almost exactly the way that C variables “hold”
values. Ironically, the only thing that ruby variables hold is VALUE,
as it is called in the source.

So, what to say to COBOL programmers?

I know little of these early 60’s programming languages of which you
speak. However, if I were introducing ruby to C programmers, I would
show them the basic data types in ruby.h. Values are passed around as
unsigned long. Types like integers, symbols, etc. are encoded by certain
bit patterns. Other bit patterns encode pointers to heap-allocated
structs, which represent almost everything else: strings, arrays, user
defined objects. All assignment and argument passing is just copying
long words. An array is represented as a C array of long words that
encode either immediate values or pointers. Array access just means
getting and setting one (or more) of these long words.

This may seem extreme, to look at the implementation on the first day.
But it is very concrete, enough to inoculate against the usual
confusions: Is ruby pass-by-reference or pass-by-value? Why are there
are no destructive methods on Fixnum or Symbol?

4. Duck typing makes testing easier.

It also makes libraries more useful, if the libraries are written to
assume as little as possible about the objects they interact with.
Grokking this point is a major step in learning to write ruby programs
in ruby, rather than write cobol programs in ruby.

In general, I don’t think it can hurt to be concrete, or to at least
give a concrete view of things as an alternative. For example, message
evaluation happens by looking up a symbol in the receiver’s table, and,
if no entry is found, iterating up the superclass tables. For some
people (esp. those with a procedural background), that means a lot more
than “this object over here sends a message to that object over there,
which can either respond to it or let its superclass handle it”.

[Wilson_B]

Bill G. wrote:

Forgetting OOP for a moment, and thinking WWW instead…
It’s stateless.
Learn how to manage hidden values.

I agree… important to teach.

However, in this case… COBOL → Ruby, I’d say forget the WWW
altogether, teach Ruby.

You should be able to quickly teach them how to do the same things they
do every day in COBOL, only in Ruby. You can even show them some OO
stuff without having to dive completely into the OO pool. By doing that
first, maybe you can keep them tuned in awhile longer. Then you can
approach the topics more foreign to your students.

But, the bottom line is that you’re going to have to teach them about
Objects if they’re to learn Ruby.

Check out the “Why Ruby?” section over on ruby-doc.org for a great set
of links. Read Why’s Poignant Guide for some inspiration too.

Good luck.

–Steve

[Wilson_B]

When the COBOL guys heard about C++, they were jealous. They
made an OOP version of their own language… called ADD ONE
TO COBOL.

LOL

gegroet,
Erik V. - http://www.erikveen.dds.nl/

[Wilson_B]

On 3/1/06, Hal F. [email protected] wrote:

Objects if they’re to learn Ruby.
I’d emphasize that “it’s all PROCEDURE DIVISION” – all of a Ruby
program is executed, no real declarations.

I’d emphasize that variables are untyped, and introduce the concept
of object references.

Thanks Hal (and everyone)… this kind of thing definitely helps. Part
of my problem is that I can’t draw analogies to a language I don’t
know.

[Wilson_B]

Hal F. [email protected] writes:

I’d emphasize that variables are untyped, and introduce the concept
of object references.

Finally, tell them that Rails 1.1 new
Object#copy_instance_variables_from
feature is very much like “COPY CORRESPONDING”. duck

[Wilson_B]

On Mar 1, 2006, at 2:32 AM, Joel VanderWerf wrote:

Anyway, variables do hold some kinds of values, like numbers,
booleans, and symbols, in almost exactly the way that C variables
“hold”
values. Ironically, the only thing that ruby variables hold is
VALUE,
as it is called in the source.

Well, not everyone conceptualizes numbers, booleans and symbols as
immediate values. It is hard to explain the following if you think
of fixnums as immediate values:

13.instance_variable_set(’@note’, ‘bad luck’)
13.instance_variable_get(’@note’) # => ‘bad luck’

You can wrap that in a method if you want:

class Fixnum
attr_accessor :note
end

x = 99
x.note = ‘bottles of beer on the wall’
x.note # => ‘bottles of beer on the wall’

Seems like x holds a reference to an object and not an immediate value.

Assignment semantics are often where the ‘immediate’ vs. ‘reference’
issue comes up, especially with literals:

a = b # usually described as reference copy
c = 10 # usually described as storing an immediate value
d = c # lots of hand waving ensues

IMHO it is much easier to just think of fixnums and booleans and
symbols as
objects and their respective literal representations as references to
those
same objects.

Gary W.

[Wilson_B]

I’ll focus it as a introduction to Object Oriented Programming with
practical Ruby examples. I have had the experience of teaching a MVC
framework (based on J2EE) to “procedural programmers” and I had to go
back over and over explaining Object Oriented Programming…

[Wilson_B]

Hi Wilson,

Wilson B. wrote:

Thanks Hal (and everyone)… this kind of thing definitely helps. Part
of my problem is that I can’t draw analogies to a language I don’t
know.

Were it me, with all the obstacles you’ve outlined, I’d feel successful
if, at the end of the day, they wanted to learn more Ruby. Given your
lack of experience in their world, I’d admit that openly, then simply
engage with them. Make it a working session. Get them to tell you
about some of the typical stuff they do. Pick something that sounds
easy to do in Ruby. Get them to give you an overview, then together
walk through how each of you’d build it in your “native tongue.” Pick
something small so you have lots of time for discussion and
explanation. Transfer small amounts of OO concepts through examples.

Best of luck.

[Wilson_B]

Joel VanderWerf wrote:

accessible to other users of the object? How do I calculate how many
labels an object has? Is a label an object? Can you change the text of
the label? Do they ever fall off when the glue dries out?

I’d say that they’re not “labels” in that sense, but in the sense of
names – as “Joel” is a label for you, but no medical exam will ever
reveal your name.

Or (dumb analogy of the day) a variable is a pair of binoculars trained
on an object. No way of telling how many others may be watching. And no
way an object knows who is out there pointing to him.

Anyway, variables do hold some kinds of values, like numbers,
booleans, and symbols, in almost exactly the way that C variables “hold”
values. Ironically, the only thing that ruby variables hold is VALUE,
as it is called in the source.

True from an implementation perspective. But in practice, we don’t
really
need to know that. It’s more important IMO to distinguish between
mutable and immutable than between immediate and non-immediate.

This may seem extreme, to look at the implementation on the first day.
But it is very concrete, enough to inoculate against the usual
confusions: Is ruby pass-by-reference or pass-by-value? Why are there
are no destructive methods on Fixnum or Symbol?

Again I’d say: Pass by value, where every value is a reference.

In general, I don’t think it can hurt to be concrete, or to at least
give a concrete view of things as an alternative. For example, message
evaluation happens by looking up a symbol in the receiver’s table, and,
if no entry is found, iterating up the superclass tables. For some
people (esp. those with a procedural background), that means a lot more
than “this object over here sends a message to that object over there,
which can either respond to it or let its superclass handle it”.

It doesn’t hurt to know a little about internals. But a language should
be taught from the outside in, not inside out IMO.

Hal

[Wilson_B]

Wilson B. wrote:

This isn’t a troll, I promise. I’m actually going to be doing this
tomorrow.

My normal Ruby spiel is geared more toward the differences between
dynamic and static langugages, and the power of blocks. In other
words, “Hey, look at what you can’t do in Java.”

This is a whole different scenario, because these people are coming on
board to be web application developers, and their previous programming
experience is 100% mainframe-based. They aren’t going to know HTML,
XML, Java, C++, etc.

Against common conception, only about 40% of mainframe programmers
are kept shackled to their terminals never to see the light of day
(an additional 23% is just psychologically incapable of comprehending
there is something outside the Great Barrier–which has, incidentally,
given a lift to a very particular strata of philosophy).

What are some key points I should make sure to cover for procedural
programmers?
Things on my list so far:

1. Variables don’t hold values, they are just labels.
2. Objects are nouns, methods are verbs.
3. Structure keeps you sane.
4. Duck typing makes testing easier.
5. Rake as an example of something procedural in an object-oriented
   language.

That being said, I’ve been immersed in OOP for so long, I don’t
remember what the hurdles are.
Thoughts? This is going to be a three hour session, wherein I need to
cover Ruby and at least the bare beginnings of Rails. Obviously an
in-depth treatment of either of those things is impossible in that
timeframe, but I do want people to leave feeling like it’s not a
magical tongue spoken by elves and wild spirits.

Your biggest hurdle may be to get the programmers to trust Ruby.
A lot of the things they will see may appear magical–in this
respect, the idea about ruby.h is not entirely out of place
(although three hours is probably a bit short for that).

I would try the get-them-engaged happy-fun lookit-how-productive-I-am
type of presentation and gather up as many quick and useful resources
for independent learning as possible (three hours really is not too
long).

Thanks,
–Wilson.

E

[Wilson_B]

Wilson B. wrote:

What are some key points I should make sure to cover for procedural
programmers?

MFer here.
BAL,COBOL and PL/1 programmer here.

1. Ruby is a great procedural language.

[Wilson_B]

On 2/28/06, Wilson B. [email protected] wrote:

This isn’t a troll, I promise. I’m actually going to be doing this tomorrow.

So how did it go?

[Wilson_B]

Also, remember that they’re very used to thinking in procedural terms.
Don’t forget that.

Walk them through refactoring a big procedural problem they may be
familiar with to a more Ruby/OO solution, and try to explain a bit
about the WHY of doing it the OO way.

Most of them should appreciate how less hypergolic Ruby is compared to
COBOL…

If they’re mainframe types, there will be some mainframe/COBOL idioms
that they may be very comfortable with that they may throw at you in
resistance. If you can counter some of them, if only to say, “it
doesn’t work that way here, but this does the same thing”, that could
be good, too.

[Wilson_B]

On 3/2/06, Adam S. [email protected] wrote:

On 2/28/06, Wilson B. [email protected] wrote:

This isn’t a troll, I promise. I’m actually going to be doing this tomorrow.

So how did it go?

It went better than I’d feared, really. I’d like to thank everyone
for their input.

Re: E. Saynatkari’s comment… When I said “They aren’t going to know
HTML, XML, Java, C++, etc.”… I meant that I knew that in advance, not
that no mainframe people know those things.

I only botched a couple of things, really… one of which was
forgetting to show off Rake.

RDoc and Test/Unit were bigger hits than I thought they would be.
At the end of the day, I hope I managed to make them interested in the
topic, rather than outright afraid of it or confused by it.

Hopefully they’ll bring me back, and I can do a more hands-on Ruby
session.

[Wilson_B]

gwtmp01 wrote:

x = 99
x.note = ‘bottles of beer on the wall’
x.note # => ‘bottles of beer on the wall’

Seems like x holds a reference to an object and not an immediate value.

If x looks like a reference to an object, if it walks like a reference
to
an object, …

Malte