elseif v. elsif ??

[Robert Dober]

[ ... ]

Technically speaking, "elseif", "elsif", and "elif" are equally "wrong".
To do it right, you'd have to make it "else if".

Chad you remind me of a dispute between fans of Domingo and Pavarotti when
a spanish music magazin explained that such discussions are futile and
nobody can judge at that level. This explaination took a whole article
just in concluding that Carreras was better than both...

So why would "else if" be better?

You're all wrong. The best is indisputably this:

si ... , entonces
...
si no y si ... , entonces
...
si no y si ... , entonces
...
si no,
...
el fin


<== obligatory irony indicator

With all due respect Sir, you have forgetten

si puede ser

Cheers
Robert

 

[Jenda Krynicky]

That almost makes me embarrassed to be a Perl hacker on ruby-talk.

We're not all like that. In fact, that's a distinct rarity. So sad
that it's in someone well known that you get to see this nonsense.

Well this is what you get if you force an already angry person to learn
a butt ugly language because some managor never heard of anything other
than ASP.Net, Java and Ruby on Rails. And decided (under these
conditions correctly) that the best option is RoR.

And no matter what you say treating newline as a statement terminator IS
plain stupid. Especially since the Ruby parser is not bright enough to
handle

foo.bar( 1 + 2
+ 3
)

Well, at least it breaks noisily in this case.

And while this is just a syntactic issue that I will most likely end up
learning to accept, the absence of use strict and even the total
unability to specify that I DO want a new variable is something I will
hate till the Ruby community gets through the flaming discussion that
the Perl one had some eight years ago.

Let's see ... what does this code do?

for my $obj (@list) {
$obj->foo()
}

Well, that's clear, it calls the foo() method on all objects in the
@list. OTOH, what does this one do?

list.each { |obj| obj.foo() }

Well, maybe it does the exact some thing ... and maybe it also changes
the obj variable from whatever it was before this line to the last
object in the list. How do you make it clear? Well, you don't. There's
no way to make sure variables do not leak out of blocks. Yeah, most
methods are 5 lines long so it doesn't matter, sure :-}

Jenda
P.S.: To make it "on topic". I don't care whether it's "elseif" or
"elsif". Whatever it is, the docs should state that clearly to alert the
people comming from any of the many languages that chose the other form.

 

[Marc Heiler]

"The "Ruby in 20 Minutes" tutorial is obviously geared to the
experienced programmer"

Everyone should start with the pickaxe2, really. Or Pine tutorial. ;-)

 

[Brian Candler]

Let's see ... what does this code do?

for my $obj (@list) {
$obj->foo()
}

Well, that's clear, it calls the foo() method on all objects in the
@list. OTOH, what does this one do?

list.each { |obj| obj.foo() }

Well, maybe it does the exact some thing ... and maybe it also changes
the obj variable from whatever it was before this line to the last
object in the list.

FWIW, I understand this is/has changed in ruby 1.9, so that block
parameters are always local to the block.

 

[Daniel Berger]

It's a sarcastic, trollish way of saying "Ruby" if you're trying to
convey a sense that it is childish.

Damn, it's also the name of my top secret fork of Ruby for MS Windows.
Windows + Ruby = Wuby.

I'm dwivin' in my car...

Dan

 

[Robert Dober]

Damn, it's also the name of my top secret fork of Ruby for MS Windows.
Windows + Ruby = Wuby.

I'm dwivin' in my car...

Dan

Cheer up you can still call it Microruby
R

 

[Alex Young]

Well this is what you get if you force an already angry person to learn
a butt ugly language because some managor never heard of anything other
than ASP.Net, Java and Ruby on Rails. And decided (under these
conditions correctly) that the best option is RoR.

So you've been tasked by your superiors to learn a new language, and
your first interaction with the people who can best help you do that is
to antagonise them?

And no matter what you say treating newline as a statement terminator IS
plain stupid. Especially since the Ruby parser is not bright enough to
handle

foo.bar( 1 + 2
+ 3
)

Well, at least it breaks noisily in this case.

And while this is just a syntactic issue that I will most likely end up
learning to accept, the absence of use strict and even the total
unability to specify that I DO want a new variable is something I will
hate till the Ruby community gets through the flaming discussion that
the Perl one had some eight years ago.

Please accept the simple fact that Ruby is not Perl, will not become
Perl, and does not need to be Perl. You will find that we are quite
willing to help with any problems you may have (at least, those of us
who haven't killfiled you already), but it is exceedingly unlikely that
any complaints you make about the language itself will be taken
seriously until you have enough experience with it to understand why it
is the way it is, and to analyse it on its own merits as opposed to
measuring it against an arbitrary external yardstick.

You are not the first person to make these complaints - although I've
never seen them made in such a mean-spirited, arrogant manner - and you
probably won't be the last. Somehow, in spite of the issues you've
identified, some of us manage to get useful, profitable work done. It
might be worth your while investigating how that's possible.

This is all I'm going to say on the matter. I presume everyone else is
following a "don't feed the trolls" policy - I guess I'm a little too
generous for that.

 

[Chad Perrin]

"The "Ruby in 20 Minutes" tutorial is obviously geared to the
experienced programmer"

Everyone should start with the pickaxe2, really. Or Pine tutorial. ;-)

The Pickaxe has some severe shortcomings as an instructional text for
people who are not experienced programmers. It's a great book in many
ways, but for a newbie programmer, not so much. It assumes a fair bit
of foreknowledge.

I'm glad Messrs. Thomas and Hunt didn't decide to try to make the
Pickaxe everything to everyone. Books that result from such an attempt
tend to be notoriously bad at being anything to anyone. Pick a target
audience for your book, and stick to it -- you'll have better luck that
way. The Pickaxe is great within its niche. Just don't make the
mistake of thinking that niche is for people who are new to programming.

 

[Chad Perrin]

Damn, it's also the name of my top secret fork of Ruby for MS Windows.
Windows + Ruby = Wuby.

I'm dwivin' in my car...

Hey . . . if you were really planning a "top secret fork of Ruby for MS
Windows", I'd say Wuby would be an *excellent* name for the language.
One wonders, however, why you'd need to fork it for Windows.

 

[Chad Perrin]

Cheer up you can still call it Microruby

No no no, the correct answer is "It's okay if I call it Wuby; I'm takin'
the name back!"

 

[Martin DeMello]

Hey . . . if you were really planning a "top secret fork of Ruby for MS
Windows", I'd say Wuby would be an *excellent* name for the language.
One wonders, however, why you'd need to fork it for Windows.

He'd need to do it because Windows can't fork

martin

 

[Daniel Berger]

Hey . . . if you were really planning a "top secret fork of Ruby for MS
Windows", I'd say Wuby would be an *excellent* name for the language.
One wonders, however, why you'd need to fork it for Windows.

A Windows-only fork would have several advantages.

First, I could use the native Windows API functions for everything and
not worry about *nix compatability.

Second, I could modify the core classes as I see fit to take advantage
of the Windows API functions.

Third, I could alter the API of some of the Ruby core classes and/or
modules where it makes sense to do so on Windows (i.e. get rid of the
Unix-isms, add Windows-isms).

Fourth, I could more easily handle Unicode issues (ties back to the
first reason).

Given the reasons above, I would scrap and completely rewrite the
following core classes:

Dir
File
File::Stat
IO
Process (and related modules)

And parts of:

Kernel
Regex
String

I would also make some pretty hefty changes to the standard library,
especially Socket.

Hypothetically speaking, of course.

Regards,

Dan

 

[Dave Thomas]

He'd need to do it because Windows can't fork

That's strange: I'm constantly overhearing people saying "forking
Windows!"

 

[Chad Perrin]

He'd need to do it because Windows can't fork

I hadn't thought of that. Good point.

 

[Chad Perrin]

That's strange: I'm constantly overhearing people saying "forking
Windows!"

+= 1

 

[Chad Perrin]

A Windows-only fork would have several advantages.

First, I could use the native Windows API functions for everything and
not worry about *nix compatability.

That's not a benefit of a Windows-only fork -- it's a "benefit" of
deciding you're not going to code for portability. Choosing a
Windows-only language is part of making the decision to ignore
portability, not a free pass so you don't have to make the decision.

Second, I could modify the core classes as I see fit to take advantage
of the Windows API functions.

Why can't you do that with Ruby -- or just create mutant relatives of
the Ruby core classes?

Third, I could alter the API of some of the Ruby core classes and/or
modules where it makes sense to do so on Windows (i.e. get rid of the
Unix-isms, add Windows-isms).

You could do that anyway. Feel free to create Windows-only modules.

Fourth, I could more easily handle Unicode issues (ties back to the
first reason).

I think my answer to that is the same as my answer to the third point.

 

[Daniel Berger]

That's not a benefit of a Windows-only fork -- it's a "benefit" of
deciding you're not going to code for portability. Choosing a
Windows-only language is part of making the decision to ignore
portability, not a free pass so you don't have to make the decision.

Fair enough, but it would mean that I could drop the cruft of
supporting 95/98/ME, too. It would be an "NT Family only" fork.

Why can't you do that with Ruby

Patches for Windows are a colossal pain (it requires modifying 3 files
as far as i can tell) and, in my experience, major patches are
unlikely to be accepted anyway.

-- or just create mutant relatives of
the Ruby core classes?

I've done that already to some extent with Win32Utils. But, to get
Unicode support, I would effectively have to redefine *every* method.

You could do that anyway. Feel free to create Windows-only modules.

But you're forgetting the stdlib alterations.

Not to worry, though. I'm not really going to pursue it. Not without
VC funding, anyway.

Regards,

Dan

 

[Chad Perrin]

I've done that already to some extent with Win32Utils. But, to get
Unicode support, I would effectively have to redefine *every* method.

Ouch. Point taken.

Then again . . . you'd have to do that anyway, with a fork. Hmm. Can't
win for losing.

But you're forgetting the stdlib alterations.

Not to worry, though. I'm not really going to pursue it. Not without
VC funding, anyway.

Oh, I don't think I have anything to fear from a Windows-only fork --
I'm not worried. I'm pretty sure Ruby, being portable where yours would
not and likely to provide better Unicode support than yours would by the
time you got yours into release-worthy status, wouldn't hurt any for the
competition. Besides, if all you forked was the implementation and
syntactic details that relate to platform-specificity, I'm pretty sure
the core Ruby would only benefit from the existence of such a close
relative.

. . especially if it was open source, so that each could benefit from
the development of the other.

 

[Rick DeNatale]

Remember in those days, heck even in the 80's languages and tools
(programs) used the shortest names possible because computing power
and memory were at a premium so even saving one character made a
difference. Thus we get all these sick little names for Unix tools,
love them or hate them.

On the other hand. I once was talking to the late John Cocke. John
was one of the oldest language gurus at IBM, and was best known for
his work on optimizing compilers, and later for fostering RISC
architectures which relied on such compilation technology.

John told me that when he wrote his first FORTRAN compiler, he had it
accept something like 7 different spellings of the keyword CONTINUE,
because "I'll be damned if I'll let any compiler I write tell me I
can't spell."

 

[John Joyce]

On the other hand. I once was talking to the late John Cocke. John
was one of the oldest language gurus at IBM, and was best known for
his work on optimizing compilers, and later for fostering RISC
architectures which relied on such compilation technology.

John told me that when he wrote his first FORTRAN compiler, he had it
accept something like 7 different spellings of the keyword CONTINUE,
because "I'll be damned if I'll let any compiler I write tell me I
can't spell."

Interesting, but if you type CONTINUE or elsif that many times and
get error messages, you're going to learn to spell it.