[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Keyword "with"

Peter Hickman

7/16/2003 1:37:00 PM

Robert Klemme wrote:
> "Mauricio Fernández" <batsman.geo@yahoo.com> schrieb im Newsbeitrag
>>Dunno, guess there's no real interest since this must have been around
>>for ages now.
>
> Hm, that is a bit contradicting, don't you think?

Not really, when someone new comes to ruby they always ask for features
from the language they know best.

The call for pre/post increment/decrement operators is pretty frequent.

We've had VB programmers ask for 'on error gosub' because they had a
blind spot for exceptions.

We've had Java/C++/Whatever programmers ask for type checking, operator
overloading, polymorphism and a whole host of compile time checking.

Lisp programmers have enquired about macros (occasionally).

We've had programmers who wanted 'initialize' changed to 'new' so that
they would have less to type.

And we've had tcl/php programmers who wanted elseif rather then elsif
(or was that the other way round).

The common theme is that all these requests come from 'I am an X
programmer', where X is the one and only language they understand :)

Peter (having a bad day) Hickman


5 Answers

Mark J. Reed

7/16/2003 2:22:00 PM

0

Peter (having a bad day) Hickman wrote:
> Not really, when someone new comes to ruby they always ask for features
> from the language they know best. The common theme is that all these
> requests come from ''I am an X programmer'', where X is the one and only
> language they understand :)

Given that one of Ruby''s main inspirations is Perl (another
being SmallTalk, obviously), and that Perl has, ahm, "borrowed"
liberally from many other languages, it''s not automatically
unreasonable to add more borrowings to Ruby. Each request should be
considered on its own merits, not dismissed on the basis that the
requestor is "obviously" only trying to make Ruby more Xlike where
X is whatever language they are coming from.

And even if they are looking for Xicity, that doesn''t mean X is the
one and only language they understand; it''s probably the language
that they wound up using because it''s the one they liked the best.
Now they''ve decided they like Ruby better but they would still like
to bring along some of the things that attracted them to language
X in the first place. That doesn''t seem unreasonable to me.

> The call for pre/post increment/decrement operators is pretty frequent.

Well, that''s because they''re useful. :) I mean, sure, x += 1
works everywhere that ++x would, but if what you really want is
x++ then you have to break it up into two statements. Not that
there''s anything wrong with that; I''m all for legible code. But 30
years after C pushed these operators into the realm of widely-used
high-level programming languages, every programmer on the planet
should be able to understand them instantly; and when you can get
clarity *and* concision at the same time, that''s the way to go. :)

> We''ve had VB programmers ask for ''on error gosub'' because they had a
> blind spot for exceptions.

Okay, well, VB programmers don''t count. ;-)

> We''ve had Java/C++/Whatever programmers ask for type checking, operator
> overloading, polymorphism and a whole host of compile time checking.

That would be a more fundamental change, obviously; Ruby is just not a
strongly-typed language. See Perl prototypes for an example of what happens
when you try to graft on a compromise. I mean, they''re potentially useful
and have a fair amount of power, but they''re rarely used, and when they
are it''s usually just to eliminate the need for extra parentheses
and/or backslashes in the calling code.

Now, as an O-O language Ruby automatically supports some forms
of polymorphism. And I do think it would occasionally result in
clearer code if we could define multiple methods with the same name
distinguished by number of arguments, rather than manually checking
and dispatching within a single method, but that''s a minor quibble.

> Lisp programmers have enquired about macros (occasionally).

Metaprogramming in general is quite useful, though ripe for
abuse; see the recent discoveries about C++ templates. ("Hi, I can make
your *compiler* run arbitrary code at compile time! You don''t even have
to *run* my code to get infected by my virus, just try to compile it!
Ha! Ha ha ha! Mwa ha ha ha ha ha hah!")

> We''ve had programmers who wanted ''initialize'' changed to ''new'' so that
> they would have less to type.

Again, I''m all for concision (even though I know that it''s not
a real word), wherever it doesn''t impede clarity. In this case
it would even enhance it - you call MyClass.new and that results
in MyClass#new being executed. Not only less typing, but also
a more logical connection, easier to remember, and no conflicts
since class methods and instance methods have separate namespaces.
Sorry, why is this a bad idea again? :)

> And we''ve had tcl/php programmers who wanted elseif rather then elsif
> (or was that the other way round).

You can''t make everyone happy with your spelling choices, to be sure.
Ruby uses "elsif" because Perl uses "elsif", and Perl uses "elsif"
because it was more aesthetically pleasing to Larry Wall. Besides,
almost every time you add a suffix to an English word ending in a silent
''e'', the ''e'' is dropped first. :)

I wouldn''t object to the introduction of "elseif" as a
synonym, just to cut down on typos when people are switching back
and forth between languages. But not "elif". Have to draw the
line somewhere. :)

-Mark

Martin DeMello

7/16/2003 2:45:00 PM

0

Mark J. Reed <markjreed@mail.com> wrote:
>
> Okay, well, VB programmers don''t count. ;-)

Actually, VB complements the ''with'' block with a unary . operator, which
is IMO the cleanest way to scope both local and object variables and
methods. At least, when I thought of the instance_eval/with trick, I
gave up on it because I couldn''t think of a way to simulate unary .s

martin

Peter Hickman

7/16/2003 2:48:00 PM

0

Mark J. Reed wrote:
> Given that one of Ruby''s main inspirations is Perl (another
> being SmallTalk, obviously), and that Perl has, ahm, "borrowed"
> liberally from many other languages, it''s not automatically
> unreasonable to add more borrowings to Ruby. Each request should be
> considered on its own merits, not dismissed on the basis that the
> requestor is "obviously" only trying to make Ruby more Xlike where
> X is whatever language they are coming from.

This I understand, but I like Ruby, it is very good. However I dislike
Java and would be disappointed with Ruby becoming more Java like. If I
wanted Java like I would use Java itself. At the moment I am coding an
interface to my Ruby / Perl expert system in Tcl/Tk because it provides
the features I require for the interface and I dont have to learn RubyTk
and PerlTk and have the problem of duplicated functionallity (and the
maintenance nightmare that that would involve).

I am not asking for Ruby to be more Tcl like.

If we really wanted a kitchen sink language we would drop Ruby here and
now and start using Lisp and Ada. But no one likes to spend their day at
the kitchen sink.

All I ask it that the request adds functionality to the language and not
sugar. ''with'', ''x++'', ''elseif'', ''new'' and the rest are just plain sugar.


Hal E. Fulton

7/16/2003 2:57:00 PM

0

----- Original Message -----
From: "Martin DeMello" <martindemello@yahoo.com>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Wednesday, July 16, 2003 9:48 AM
Subject: Re: Keyword "with"


> Mark J. Reed <markjreed@mail.com> wrote:
> >
> > Okay, well, VB programmers don''t count. ;-)
>
> Actually, VB complements the ''with'' block with a unary . operator, which
> is IMO the cleanest way to scope both local and object variables and
> methods. At least, when I thought of the instance_eval/with trick, I
> gave up on it because I couldn''t think of a way to simulate unary .s

Now there''s a thought. The unary . is not so
bad in my opinion. We already have the unary ::
in Ruby (::X means Object::X).

Sounds like a huge parser change to me, though.
Perhaps far too much in exchange for a small
benefit. Wonder what Matz would think of it?

Hal

--
Hal Fulton
hal9000@hypermetrics.com

Mark J. Reed

7/16/2003 3:00:00 PM

0

On Wed, Jul 16, 2003 at 11:47:39PM +0900, Peter Hickman wrote:
> If we really wanted a kitchen sink language we would drop Ruby here and
> now and start using Lisp and Ada. But no one likes to spend their day at
> the kitchen sink.

> All I ask it that the request adds functionality to the language and not
> sugar. ''with'', ''x++'', ''elseif'', ''new'' and the rest are just plain sugar.

Well, then you should *like* Common Lisp and Ada. They have lots of
functionality, but not much sugar. :)

But there''s nothing wrong with sugar, syntactic or otherwise. Many of
the things I like about various programming languages falls squarely
in the "sugar" category. The heart of usability in general is usualy
redundancy and shortcuts - basically, a general lack of strict
adherence to orthogonality (what Larry Wall calls "diagonality").
This is as true for usability of programming languages as it
is in other arenas.

Besides, many of Ruby''s built-in classes and modules are already
full of sugar - duplicated functionality with multiple interfaces.
Method names that are exact synonyms, operators that accomplish
the same thing as a method call, etc. Adding more would hardly
be a case of tarnishing a previously minimal design. :)

-Mark