Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > This naughty language of ours violates hallowed Structure Programming sophistries

Reply
Thread Tools

This naughty language of ours violates hallowed Structure Programming sophistries

 
 
Phlip
Guest
Posts: n/a
 
      08-21-2004
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/bi...UserInterfaces


 
Reply With Quote
 
 
 
 
Rando Christensen
Guest
Posts: n/a
 
      08-21-2004
> 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
<(E-Mail Removed)>



 
Reply With Quote
 
 
 
 
David A. Black
Guest
Posts: n/a
 
      08-21-2004
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
http://www.velocityreviews.com/forums/(E-Mail Removed)



 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      08-21-2004

"Phlip" <(E-Mail Removed)> schrieb im Newsbeitrag
news:gDHVc.2566$(E-Mail Removed) m...
> 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

 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      08-21-2004
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/bi...UserInterfaces


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      08-21-2004
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
(E-Mail Removed)



 
Reply With Quote
 
Jamis Buck
Guest
Posts: n/a
 
      08-21-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.
>


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
(E-Mail Removed)
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."


 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      08-21-2004
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/bi...UserInterfaces


 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      08-22-2004
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
(E-Mail Removed)



 
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
my internet connection is becomming very slow randomali every 4 or 2 ours for an hour or such E.D.I Computer Support 0 08-19-2007 08:41 PM
IIS restart takes ours wwwmike@gmx.ch ASP .Net 3 10-07-2006 05:53 PM
Oh you naughty naughty downloaders Troggles NZ Computing 2 04-12-2006 11:29 PM
DVD Verdict reviews: WHERE THE TRUTH LIES, YOURS, MINE AND OURS (2005), and more! DVD Verdict DVD Video 0 02-28-2006 10:08 AM
Naughty Language Norman White Computer Support 12 04-06-2005 05:44 PM



Advertisments