Teaching Ruby to COBOL programmers

Discussion in 'Ruby' started by Wilson Bilkovich, Mar 1, 2006.

  1. 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.
    Wilson Bilkovich, Mar 1, 2006
    #1
    1. Advertising

  2. 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!
    Xeno Campanoli, Mar 1, 2006
    #2
    1. Advertising

  3. Wilson Bilkovich

    Bill Guindon Guest

    On 2/28/06, Wilson Bilkovich <> 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".
    Bill Guindon, Mar 1, 2006
    #3
  4. Wilson Bilkovich

    Dave Burt Guest

    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
    Dave Burt, Mar 1, 2006
    #4
  5. 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
    Stephen Waits, Mar 1, 2006
    #5
  6. Wilson Bilkovich

    Hal Fulton Guest

    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
    Hal Fulton, Mar 1, 2006
    #6
  7. 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
    Joel VanderWerf, Mar 1, 2006
    #7
  8. > 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/
    Erik Veenstra, Mar 1, 2006
    #8
  9. On 3/1/06, Hal Fulton <> 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.
    Wilson Bilkovich, Mar 1, 2006
    #9
  10. Wilson Bilkovich

    Guest

    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....
    , Mar 1, 2006
    #10
  11. Wilson Bilkovich

    Guest

    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 Wright
    , Mar 1, 2006
    #11
  12. Wilson Bilkovich

    Hal Fulton Guest

    Joel VanderWerf wrote:
    > 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?


    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
    Hal Fulton, Mar 2, 2006
    #12
  13. Wilson Bilkovich

    bill walton Guest

    Hi Wilson,

    Wilson Bilkovich 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.
    bill walton, Mar 2, 2006
    #13
  14. 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.


    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

    --
    Posted via http://www.ruby-forum.com/.
    E. Saynatkari, Mar 2, 2006
    #14
  15. Wilson Bilkovich 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. :)

    --
    J. Lambert
    Jon A. Lambert, Mar 2, 2006
    #15
  16. Wilson Bilkovich

    Adam Shelly Guest

    On 2/28/06, Wilson Bilkovich <> wrote:
    > This isn't a troll, I promise. I'm actually going to be doing this tomor=

    row.

    So how did it go?
    Adam Shelly, Mar 2, 2006
    #16
  17. Wilson Bilkovich

    Malte Milatz Guest

    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
    Malte Milatz, Mar 3, 2006
    #17
  18. Wilson Bilkovich

    Corey Lawson Guest

    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 COBO=
    L...

    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.
    Corey Lawson, Mar 3, 2006
    #18
  19. On 3/2/06, Adam Shelly <> wrote:
    > On 2/28/06, Wilson Bilkovich <> wrote:
    > > This isn't a troll, I promise. I'm actually going to be doing this tom=

    orrow.
    >
    > 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 Bilkovich, Mar 4, 2006
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    24
    Views:
    681
    Arne Vajhøj
    Nov 6, 2011
  2. Ruby & MF Cobol

    , Aug 31, 2004, in forum: Ruby
    Replies:
    2
    Views:
    124
    Robert Nesius
    Aug 31, 2004
  3. Lew
    Replies:
    0
    Views:
    409
  4. Stefan Ram

    Teaching Java, teaching what?

    Stefan Ram, Dec 8, 2013, in forum: Java
    Replies:
    57
    Views:
    500
    Ali Sh
    Dec 18, 2013
  5. Lalitha Prasad K

    Teaching python to non-programmers

    Lalitha Prasad K, Apr 10, 2014, in forum: Python
    Replies:
    8
    Views:
    73
    Bob Martin
    Apr 12, 2014
Loading...

Share This Page