Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Teaching Ruby to COBOL programmers

Reply
Thread Tools

Teaching Ruby to COBOL programmers

 
 
Wilson Bilkovich
Guest
Posts: n/a
 
      03-01-2006
This isn't a troll, I promise. I'm actually going to be doing this tomorro=
w.

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 program=
mers?
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 languag=
e.

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.


 
Reply With Quote
 
 
 
 
Xeno Campanoli
Guest
Posts: n/a
 
      03-01-2006
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 Bilkovich 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.
>
>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.
>
>
>
>
>
>


--
Xeno Campanoli: http://www.eskimo.com/~xeno
Robbing Republican Treasonists ARE MORE DANGEROUS than foreign terrorists!



 
Reply With Quote
 
 
 
 
Bill Guindon
Guest
Posts: n/a
 
      03-01-2006
On 2/28/06, Wilson Bilkovich <(E-Mail Removed)> wrote:
> This isn't a troll, I promise. I'm actually going to be doing this tomor=

row.
>
> 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 progr=

ammers?
> 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 langu=

age.
>
> 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.


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.

> Thanks,
> --Wilson.


--
Bill Guindon (aka aGorilla)
The best answer to most questions is "it depends".


 
Reply With Quote
 
Dave Burt
Guest
Posts: n/a
 
      03-01-2006
Wilson Bilkovich 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


 
Reply With Quote
 
Stephen Waits
Guest
Posts: n/a
 
      03-01-2006
Bill Guindon 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


 
Reply With Quote
 
Hal Fulton
Guest
Posts: n/a
 
      03-01-2006
Stephen Waits wrote:
> Bill Guindon 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.


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....


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


Hal




 
Reply With Quote
 
Joel VanderWerf
Guest
Posts: n/a
 
      03-01-2006
Wilson Bilkovich 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".

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407


 
Reply With Quote
 
Erik Veenstra
Guest
Posts: n/a
 
      03-01-2006
> 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/

 
Reply With Quote
 
Wilson Bilkovich
Guest
Posts: n/a
 
      03-01-2006
On 3/1/06, Hal Fulton <(E-Mail Removed)> wrote:
> Stephen Waits wrote:
> > Bill Guindon 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 tha=

t
> > 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.
>


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.


 
Reply With Quote
 
anibalrojas@gmail.com
Guest
Posts: n/a
 
      03-01-2006
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....

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: You might have a better time teaching Perl programmers Ruby,because of it's Perl'isms. Then on to Java. Lew Java 0 05-02-2012 05:53 PM
Any experience on teaching Perl programmers Java saxo123@gmx.de Java 24 11-06-2011 02:16 AM
Ruby-warrior : Teaching AI concepts with Ruby Aldric Giacomoni Ruby 23 04-16-2010 12:30 PM
Réf. : Ruby & MF Cobol tad.bochan@bnpparibas.com Ruby 1 08-31-2004 05:36 PM
Ruby & MF Cobol tad.bochan@bnpparibas.com Ruby 2 08-31-2004 05:14 PM



Advertisments