This naughty language of ours violates hallowed Structure Programming sophistries

Discussion in 'Ruby' started by Phlip, Aug 21, 2004.

  1. Phlip

    Phlip Guest

    Rubies:

    Please review for accuracy:

    Before Object Oriented Programming, people who studied the difference
    between cruft and maintainable code learned to improve things by linking
    control flow to variable scope. An example in C:

    if (whatever())
    {
    int x = something();
    somethingElse(x);
    }
    x; /* this line won't compile, unless another x is available from
    above */

    Structured Programmers decry the mighty goto keyword, able to leap tall
    procedures in a single bound. When a language permits a goto unfettered by
    that language's block system, {}, variables defined in statements controlled
    by goto have ambiguous scope. Structured Programming enables the style
    guideline "give identifiers the most restricted scope possible".

    I am unaware if Ruby supports goto. (Please please please don't tell me if
    it does or not!) Object Oriented Programming subsumes all Structured
    Programming ideals. However, Ruby permits this:

    def newThing()

    if something() then
    element = constructor(TkcLine)
    else
    element = constructor(TkcPolygon)
    end

    element.configure('smooth', '1')

    end

    Ruby creates variables by assigning to them. That cures an ancient problem
    with the C languages, where variables can define without values. The lowly C
    statement int x; efficiently produces an x that might contain anything, and
    should not be used until assigned. Ruby fixes that problem by forbidding
    creation without assignment.

    Ruby variables create into their method's scope, not their block's scope.
    That's why the above code works - it tweaks the Structured Programming
    rules. The element inside the if statement's blocks should, in theory, exit
    scope and disappear before the last element.

    Ruby supports Structure Programming much more subtly than by decrying goto.
    When a goto leaps a tall procedure in a single bound, the root problem is
    that tall procedure itself. Ruby's syntax maximizes opportunities to
    minimize code. The style guideline "don't goto" is subservient to the
    Simplicity Principle "Minimize Statements, Methods, and Classes".

    For example:

    def newThing()
    klass = if something() then TkcLine else TkcPolygon end
    element = constructor( klass )
    element.configure('smooth', '1')
    end

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Aug 21, 2004
    #1
    1. Advertising

  2. Re: This naughty language of ours violates hallowed StructureProgramming sophistries

    > Before Object Oriented Programming, people who studied the difference
    > between cruft and maintainable code learned to improve things by linking
    > control flow to variable scope. An example in C:
    >
    > if (whatever())
    > {
    > int x = something();
    > somethingElse(x);
    > }
    > x; /* this line won't compile, unless another x is available from
    > above */


    I've always believed that the key principle behind coding with scope in
    mind is not how the scope is implemented so much as understanding the
    rules of variable scope for the language and using them to write solid
    code that is not as prone to errors.

    Remember, a bad programmer will write bad programs in any language, and a
    good programmer will write good programs in any language (given sufficient
    time to understand the language). Any rules that the language enforces,
    whether for scoping or for language structure or whatever, do not alter
    this.

    --
    Rando Christensen
    <>
     
    Rando Christensen, Aug 21, 2004
    #2
    1. Advertising

  3. Re: This naughty language of ours violates hallowed StructureProgramming sophistries

    Hi --

    On Sat, 21 Aug 2004, Phlip wrote:

    > Rubies:


    (I think of myself more as a Ruby*ist*, but so be it :)

    > Ruby variables create into their method's scope, not their block's scope.
    > That's why the above code works - it tweaks the Structured Programming
    > rules. The element inside the if statement's blocks should, in theory, exit
    > scope and disappear before the last element.


    'if' doesn't create a new scope, but code blocks do:

    $ ruby -e ' [1,2,3].each {|x| p x; y=1}; p x rescue puts $!;
    p y rescue puts $!'
    1
    2
    3
    undefined local variable or method `x' for main:Object
    undefined local variable or method `y' for main:Object

    So the method/block scope distinction doesn't generally hold. (This
    is among the areas under revision for 2.0... so stay tuned.)

    The "in theory" bit is a little damning, since it suggests that Ruby's
    design in this regard violates some general theory or principle, which
    I don't think it does. Having 'if' be of flat scope is a different
    *practice* than other languages, but I don't think there's any
    theoretical mandate to do it one way or the other.


    David

    --
    David A. Black
     
    David A. Black, Aug 21, 2004
    #3
  4. "Phlip" <> schrieb im Newsbeitrag
    news:gDHVc.2566$...
    > Ruby supports Structure Programming much more subtly than by decrying

    goto.
    > When a goto leaps a tall procedure in a single bound, the root problem is
    > that tall procedure itself. Ruby's syntax maximizes opportunities to
    > minimize code. The style guideline "don't goto" is subservient to the
    > Simplicity Principle "Minimize Statements, Methods, and Classes".
    >
    > For example:
    >
    > def newThing()
    > klass = if something() then TkcLine else TkcPolygon end
    > element = constructor( klass )
    > element.configure('smooth', '1')
    > end


    I'm not sure what you want to show with this, but if you want to minimize
    code there are other solutions:

    def new_thing
    thing = ( something() ? TkcLine : TkcPolygon ).new
    thing.configure('smooth', '1')
    thing
    end

    Note that your method relies on the implementation of #configure to yield
    the proper return value. IMHO that's bad practice since this requires more
    of #configure than necessary.

    Regards

    robert
     
    Robert Klemme, Aug 21, 2004
    #4
  5. Phlip

    Phlip Guest

    David A. Black wrote:

    > The "in theory" bit is a little damning, since it suggests that Ruby's
    > design in this regard violates some general theory or principle, which
    > I don't think it does. Having 'if' be of flat scope is a different
    > *practice* than other languages, but I don't think there's any
    > theoretical mandate to do it one way or the other.


    Guys, everyone needs to look "sophistries" up in a dictionary.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Aug 21, 2004
    #5
  6. Re: This naughty language of ours violates hallowed StructureProgramming sophistries

    Hi --

    On Sun, 22 Aug 2004, Phlip wrote:

    > David A. Black wrote:
    >
    > > The "in theory" bit is a little damning, since it suggests that Ruby's
    > > design in this regard violates some general theory or principle, which
    > > I don't think it does. Having 'if' be of flat scope is a different
    > > *practice* than other languages, but I don't think there's any
    > > theoretical mandate to do it one way or the other.

    >
    > Guys, everyone needs to look "sophistries" up in a dictionary.


    Take them or leave them, but my comments were made in full knowledge
    of what that word means.


    David

    --
    David A. Black
     
    David A. Black, Aug 21, 2004
    #6
  7. Phlip

    Jamis Buck Guest

    Re: This naughty language of ours violates hallowed StructureProgramming sophistries

    Phlip wrote:
    > David A. Black wrote:
    >
    >
    >>The "in theory" bit is a little damning, since it suggests that Ruby's
    >>design in this regard violates some general theory or principle, which
    >>I don't think it does. Having 'if' be of flat scope is a different
    >>*practice* than other languages, but I don't think there's any
    >>theoretical mandate to do it one way or the other.

    >
    >
    > Guys, everyone needs to look "sophistries" up in a dictionary.
    >


    From m-w.com:

    "Sophistry: (noun) subtly deceptive reasoning or argumentation"

    Hmmm. I don't see how David's comment in any way fits that definition.
    Could you be a little more explicit in your accusation? I personally
    concur with David's statement.

    - Jamis

    --
    Jamis Buck

    http://www.jamisbuck.org/jamis

    "I use octal until I get to 8, and then I switch to decimal."
     
    Jamis Buck, Aug 21, 2004
    #7
  8. Phlip

    Phlip Guest

    Jamis Buck wrote:

    > "Sophistry: (noun) subtly deceptive reasoning or argumentation"
    >
    > Hmmm. I don't see how David's comment in any way fits that definition.
    > Could you be a little more explicit in your accusation? I personally
    > concur with David's statement.


    I wrote the Subject line, not Dave.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
     
    Phlip, Aug 21, 2004
    #8
  9. Re: This naughty language of ours violates hallowed StructureProgramming sophistries

    On Sun, 22 Aug 2004, Phlip wrote:

    > Jamis Buck wrote:
    >
    > > "Sophistry: (noun) subtly deceptive reasoning or argumentation"
    > >
    > > Hmmm. I don't see how David's comment in any way fits that definition.
    > > Could you be a little more explicit in your accusation? I personally
    > > concur with David's statement.

    >
    > I wrote the Subject line, not Dave.


    Nor I :)


    David

    --
    David A. Black
     
    David A. Black, Aug 22, 2004
    #9
    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. Kent Paul Dolan
    Replies:
    22
    Views:
    1,161
    goergebush
    Dec 22, 2005
  2. IIS restart takes ours

    , Oct 7, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    588
  3. sk
    Replies:
    0
    Views:
    2,300
  4. Tony Johansson
    Replies:
    1
    Views:
    886
    Arne Vajhøj
    Jul 17, 2011
  5. Dave E

    Passing values to user controls - naughty problem

    Dave E, Jul 2, 2006, in forum: ASP .Net Web Controls
    Replies:
    3
    Views:
    198
    Alessandro Zifiglio
    Jul 3, 2006
Loading...

Share This Page