Ruby / Eiffel?

Hello evry body

I’m new to Ruby World.
Does some body know differences Ruby / Eiffel
and the advantages of both.

Thank you.
Merci beaucoup.

Cailloux

cailloux@lesdamien.com writes:

This is a multi-part message in MIME format.

------=_NextPart_000_00A3_01C2E937.15ABF820
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello evry body

I’m new to Ruby World.
Does some body know differences Ruby / Eiffel
and the advantages of both.
The both are fine langauges and combining them would make quite a
bunch of people happy.

Now here my 2 cent.
Eiffel is nice for building frameworks (so larger applications)
Eiffel very verbose and it’s a very unpleasant experience to use it n
areas where Ruby shines. (just an example, write Iteration about a
container without Agents in Eifel, fetch one HTML page from somewhere)
Eiffel get compiled and it seems hefty to write an Interpreter for it
because the need “all-world” knowledge.
Eiffel is statically typed (mostly of)
Interfactin Eiffel/C is as easy as it is with Ruby/Eiffel
It DBC concept is extremly helpful and a documentation tool of first
grade. You do not have to know the source just the short forms (that
are the contracts make it easy) to undersrand how things work.

Ruby is “dynamically” typed, and interpreted. There have been attemps
to integrate DBC into it (do not know how well it really is)
Ruby blocks have no good counterpart in Eiffel
Ruby can work with incomplete information
Ruby can be easy extended and embedded in C (that is what I learned in
a relativly short time)

Both languages have a “feel-right” taste, combining Eiffel with Ruby
seems to be a very attractive alternatie. Eiffel as the "Framework"
Ruby for appling it conveniently.

I just can say I really love them both.

Regards
Friedrich

also, related, does anyone know if there is a good reason for the absense
of assertions in ruby?
i’m guessing it is a conscious decision.
jason

···

On Thu, 13 Mar 2003 cailloux@lesdamien.com wrote:

This is a multi-part message in MIME format.

------=_NextPart_000_00A3_01C2E937.15ABF820
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello evry body

I’m new to Ruby World.
Does some body know differences Ruby / Eiffel
and the advantages of both.

Thank you.
Merci beaucoup.

Cailloux

------=_NextPart_000_00A3_01C2E937.15ABF820
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello evry body
 
I'm new to Ruby World.
Does some body know differences Ruby /=20 Eiffel
and the advantages of = both.
 
Thank you.
Merci beaucoup.
 
Cailloux

------=_NextPart_000_00A3_01C2E937.15ABF820–

“Friedrich Dominicus” frido@q-software-solutions.com wrote in message
news:87k7f3acus.fsf@fbigm.here…

cailloux@lesdamien.com writes:

Both languages have a “feel-right” taste, combining Eiffel with Ruby
seems to be a very attractive alternatie. Eiffel as the "Framework"
Ruby for appling it conveniently.

Eiffel is supposed to have good built-in GUI support.

Mikkel

Dear Mr Friedrich,
Dear Mr Mikkel
Thank you for responses.
Merci

···

----- Original Message -----
From: “Friedrich Dominicus” frido@q-software-solutions.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, March 13, 2003 9:37 AM
Subject: Re: Ruby / Eiffel ?

cailloux@lesdamien.com writes:

This is a multi-part message in MIME format.

------=_NextPart_000_00A3_01C2E937.15ABF820
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello evry body

I’m new to Ruby World.
Does some body know differences Ruby / Eiffel
and the advantages of both.
The both are fine langauges and combining them would make quite a
bunch of people happy.

Now here my 2 cent.
Eiffel is nice for building frameworks (so larger applications)
Eiffel very verbose and it’s a very unpleasant experience to use it n
areas where Ruby shines. (just an example, write Iteration about a
container without Agents in Eifel, fetch one HTML page from somewhere)
Eiffel get compiled and it seems hefty to write an Interpreter for it
because the need “all-world” knowledge.
Eiffel is statically typed (mostly of)
Interfactin Eiffel/C is as easy as it is with Ruby/Eiffel
It DBC concept is extremly helpful and a documentation tool of first
grade. You do not have to know the source just the short forms (that
are the contracts make it easy) to undersrand how things work.

Ruby is “dynamically” typed, and interpreted. There have been attemps
to integrate DBC into it (do not know how well it really is)
Ruby blocks have no good counterpart in Eiffel
Ruby can work with incomplete information
Ruby can be easy extended and embedded in C (that is what I learned in
a relativly short time)

Both languages have a “feel-right” taste, combining Eiffel with Ruby
seems to be a very attractive alternatie. Eiffel as the "Framework"
Ruby for appling it conveniently.

I just can say I really love them both.

Regards
Friedrich

also, related, does anyone know if there is a good reason for the absense
of assertions in ruby?

Assertions? You mean like in C?

i’m guessing it is a conscious decision.

Probably because there are exceptions. :wink: You could always do:

def assert(conditional)
raise “Assertion failed” if not conditional
end

But that comes out with less information in the end than if you make a
nice, specific exception for the given case and populate it with
useful info.

Assertions (in C anyway) are mostly a quick hack because there aren’t
exceptions, anyway.

···

On Fri, 14 Mar 2003 05:59:33 +0900 “Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu wrote:

jason


Ryan Pavlik rpav@users.sf.net

“Fanged death from the sea is quite routine.” - 8BT

Hello Jason,

Thursday, March 13, 2003, 11:59:33 PM, you wrote:

JMJ0i> also, related, does anyone know if there is a good reason for the absense
JMJ0i> of assertions in ruby?
JMJ0i> i’m guessing it is a conscious decision.

just to give Eiffel even one chance :wink:

···


Best regards,
Bulat mailto:bulatz@integ.ru

also, related, does anyone know if there is a good reason for the absense
of assertions in ruby?

Assertions? You mean like in C?
exactly. i believe eiffel makes a big deal about them as part of “design
by contract”

i’m guessing it is a conscious decision.

Probably because there are exceptions. :wink: You could always do:

def assert(conditional)
raise “Assertion failed” if not conditional
end

But that comes out with less information in the end than if you make a
nice, specific exception for the given case and populate it with
useful info.

Assertions (in C anyway) are mostly a quick hack because there aren’t
exceptions, anyway.

sometimes assertions don’t check adherence to an interface. sometimes you
like to add assertions to help you determine where a program went wrong.
you find which part of your understanding “broke first.”

i’ve coded up a ruby “assertion” for myself as follows:

def assert(conditional)
begin
raise Exception, “assertion failed” if not conditional
rescue Exception => e
filename = e.backtrace()[1].split(/:/)[0]
lineno = e.backtrace()[1].split(/:/)[1].to_i()
file = File::new(filename)
puts e.message+": "+file.readlines()[lineno-1]
exit! 1
end
end

maybe as i learn more ruby i’ll find less of a use for it.

···

On Fri, 14 Mar 2003, Ryan Pavlik wrote:

On Fri, 14 Mar 2003 05:59:33 +0900 > “Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu wrote:

jason


Ryan Pavlik rpav@users.sf.net

“Fanged death from the sea is quite routine.” - 8BT

“MikkelFJ” mikkelfj-anti-spam@bigfoot.com writes:

“Friedrich Dominicus” frido@q-software-solutions.com wrote in message
news:87k7f3acus.fsf@fbigm.here…

cailloux@lesdamien.com writes:

Both languages have a “feel-right” taste, combining Eiffel with Ruby
seems to be a very attractive alternatie. Eiffel as the "Framework"
Ruby for appling it conveniently.

Eiffel is supposed to have good built-in GUI support.
which just is true for
Visual Eiffel on windows
ISE Eiffel Windows, and Unix and.
SmallEifel nearly none (excuse to OT because of VeGTK and some
other.s…

Regards
Friedrich

MikkelFJ wrote:

“Friedrich Dominicus” frido@q-software-solutions.com wrote in message
news:87k7f3acus.fsf@fbigm.here…

cailloux@lesdamien.com writes:

Both languages have a “feel-right” taste, combining Eiffel with Ruby
seems to be a very attractive alternatie. Eiffel as the "Framework"
Ruby for appling it conveniently.

Eiffel is supposed to have good built-in GUI support.

Mikkel

Umnh… No. Eiffel-Fox exists. And Object-Tools makes a GUI builder.
Probably ISE does. But it’s definitely not a part of the language. For
that matter, FXRuby exists, etc. And GUI isn’t a part of the Ruby
language, either. Eiffel either has or had better support from Glade
than Ruby. Some dialects of Eiffel can easily call Java routines.
Etc. But that’s not making the GUI a part of the language.

···


– Charles Hixson
Gnu software that is free,
The best is yet to be.

> exactly. i believe eiffel makes a big deal about them as part of "design > by contract"

I believe “design by contract” is flawed, but that’s another
discussion entirely.

> sometimes assertions don't check adherence to an interface. sometimes you > like to add assertions to help you determine where a program went wrong. > you find which part of your understanding "broke first."

Exceptions do even more for you. Assertions are nothing more than
convenient print/exit statements. Exceptions by default do the same,
with the addition of backtrace information (which is usually useful in
determining the erroneous path). This is nice for debugging.

With a little extra work, you can write your code to “fix itself”. At
very least they provide nice error reporting (to your code, instead of
something like errno), but you have the opportunity to handle and try
and correct the problem on the fly. This is especially important in a
dynamic system like Ruby, where things, well, change.

i’ve coded up a ruby “assertion” for myself as follows:

maybe as i learn more ruby i’ll find less of a use for it.

I’m really not sure what this gives you other than less information
over the original exception. Backtraces are a nice way to see how you
got to the condition in the first place. Your only choice later is to
remove the abortive statement, as well—there’s no possibility for
adding checks to handle the situation at a higher level.

···

On Fri, 14 Mar 2003 13:00:07 +0900 “Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu wrote:


Ryan Pavlik rpav@users.sf.net

“Fanged death from the sea is quite routine.” - 8BT

I tend to use assertions as a sort of runtime unit test, esp. when I’m
in the rapid prototyping and design stage of a project. It find it
easier to simply use them like a form of passive logging – with enough
’sanity-check’ assertions in place, I can get a reasonably good
post-mortem on where my code breaks, without having to run everything
through the debugger or build dozens of test cases in advance (the
former being an especially big win when I’m working with a distributed
application that runs on multiple machines simultaneously).

I do tend to use blocks, rather than simple conditionals, in my
assertion checking, simply so that when they’re disabled, none of the
work (or side-effects) from the block has to be done. By simply passing
a boolean-valued parameter, (such as ‘my_list.size > num_new_entries’,
or something) you force evaluation of it each time the assertion is
encountered. If you use blocks, though, you can only call the block when
assertions are turned on.

Since I like having the ability to enable or disable assertions at
runtime, the block then adds no extra execution time (since it never
gets called), and any side effects that could happen within it are
avoided in cases where the assertion is disabled.

My simplistic implementation looks something like the following:

def assert(&block)
if ASSERTIONS_ACTIVE
begin
block.call() or raise Exception, "assertion failed"
rescue Exception => e
[…similar backtrace handling…]
end
end
end

Lennon

Jason M Jurkowski ;002;icsg6; wrote:

···

[snip]

sometimes assertions don’t check adherence to an interface. sometimes you
like to add assertions to help you determine where a program went wrong.
you find which part of your understanding “broke first.”

i’ve coded up a ruby “assertion” for myself as follows:

def assert(conditional)
begin
raise Exception, “assertion failed” if not conditional
rescue Exception => e
filename = e.backtrace()[1].split(/:/)[0]
lineno = e.backtrace()[1].split(/:/)[1].to_i()
file = File::new(filename)
puts e.message+": "+file.readlines()[lineno-1]
exit! 1
end
end

maybe as i learn more ruby i’ll find less of a use for it.

jason


Ryan Pavlik rpav@users.sf.net

“Fanged death from the sea is quite routine.” - 8BT

“Jason M Jurkowski”:

“Jason M Jurkowski”:

also, related, does anyone know if there is a good reason for
the absense of assertions in ruby?
Assertions? You mean like in C?
exactly. i believe eiffel makes a big deal about them as part of
"design by contract"

According to The Ruby Way, there are two DBC libraries available
for Ruby. One of them should be on http://www.rubycentral.com. I’m
not sure what the other one is … perhaps Hal could enlighten us?

I looked at the PP DBC and didn’t find DBC all that interesting
(plus I don’t care for GPL-only libraries, sorry).

-austin
– Austin Ziegler, austin@halostatue.ca on 2003.03.14 at 00:21:23

···

On Fri, 14 Mar 2003, Ryan Pavlik wrote:

“Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu writes:

also, related, does anyone know if there is a good reason for the absense
of assertions in ruby?

Assertions? You mean like in C?
exactly. i believe eiffel makes a big deal about them as part of "design
by contract"
You will compare Cs assert with Eiffels DBC?

i’m guessing it is a conscious decision.

Probably because there are exceptions. :wink: You could always do:

def assert(conditional)
raise “Assertion failed” if not conditional
end
You always can raise Exceptions in Eiffel too. The are not as good as
in Ruby, but still “good enough”.

Regards
Friedrich

···

On Fri, 14 Mar 2003, Ryan Pavlik wrote:

On Fri, 14 Mar 2003 05:59:33 +0900 > > “Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu wrote:

“Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu schrieb im
Newsbeitrag news:Pine.GSO.4.53.0303132238200.20279@utah.cs.rit.edu

i’ve coded up a ruby “assertion” for myself as follows:

def assert(conditional)
begin
raise Exception, “assertion failed” if not conditional
rescue Exception => e
filename = e.backtrace()[1].split(/:/)[0]
lineno = e.backtrace()[1].split(/:/)[1].to_i()
file = File::new(filename)
puts e.message+": "+file.readlines()[lineno-1]
exit! 1
end
end

Throwing and immediately catching an exception is superfluous. I like
this more:

def assert(cond)
unless cond
filename, lineno = caller[0].split(/:/)
raise ( File.open( filename ) do |f|
"assertion failed at #{filename}:#{lineno}: #{ f.readlines()[
lineno.to_i - 1 ] }"
end )
end
end

Note that the exception trace that ruby prints for uncaught exceptions
does contain the file and line number already. So if you leave out
printing of the line itself, this is sufficient:

def assert(cond)
raise “assertion failed” unless cond
end

And for delivered code

def assert(cond); end

regards

robert

:wink: Would if I could… my memory of that is vague,
and it was only hearsay, as I’ve never tried DBC
in Ruby.

A search of the ML for DBC would likely reveal
the other one.

Hal

···

----- Original Message -----
From: “Austin Ziegler” austin@halostatue.ca
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, March 13, 2003 11:27 PM
Subject: Ruby and DBC (was: Ruby / Eiffel?)

According to The Ruby Way, there are two DBC libraries available
for Ruby. One of them should be on http://www.rubycentral.com. I’m
not sure what the other one is … perhaps Hal could enlighten us?

Ryan Pavlik rpav@nwlink.com writes:

> exactly. i believe eiffel makes a big deal about them as part of "design > by contract"

I believe “design by contract” is flawed, but that’s another
discussion entirely.
What are the flaws, in fact I would argue the should be used
exclusivly and have some major advantages.

  • documentation
  • separting normal control flow from “Exceptions”

Using Exceptions for all kine of errors which can happen definitly
flawed.

> sometimes assertions don't check adherence to an interface. sometimes you > like to add assertions to help you determine where a program went wrong. > you find which part of your understanding "broke first."

Exceptions do even more for you. Assertions are nothing more than
convenient print/exit statements. Exceptions by default do the same,
with the addition of backtrace information (which is usually useful in
determining the erroneous path). This is nice for debugging.
Well and that is exactly what DBC does in Eiffel. The h… I have even
read in an ACM journal lately about such thing, they found of course a
more gorgeous name for it…

Regards
Friedrich

···

On Fri, 14 Mar 2003 13:00:07 +0900 > “Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu wrote:

Ryan Pavlik wrote:

exactly. i believe eiffel makes a big deal about them as part of “design
by contract”

I believe “design by contract” is flawed, but that’s another
discussion entirely.

DBC is probably flawed in the context of Ruby. In Eiffel it makes a lot
more sense. In Eiffel you know what type something is going to be
allowed to be. In Ruby assertions would probably only mean something
like 'This isn’t a kind of data I’m prepared to deal with", valuable
information, but not necessarily a sign of an error. In Eiffel this
would be a design error.

That said, there are many times when I believe that I do know what
types should be allowed. If I’m expecting a number, and you pass me a
point, then something’s wrong. I defined (say) multiplication to work
between two real numbers. And you are passing me a thing that I wot not
of. So somebody else needs to deal with it. This could be seen as what
an assertion should be about. (Actually, Eiffel’s assertions are a lot
more specific than that. And in the context of Eiffel they make a lot
of sense.)

The main job being handled here is detecting errors, and figuring out
how to deal with them. Eiffel is better at the first part, and Ruby is
better at the second part.

···

On Fri, 14 Mar 2003 13:00:07 +0900 >“Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu wrote:


– Charles Hixson
Gnu software that is free,
The best is yet to be.

> What are the flaws, in fact I would argue the should be used > exclusivly and have some major advantages.

Actually, I’ve gone back and looked over some material on DBC again.
From what I’m reading, I was definitely wrong, and take back what I
said about DBC design. At least from my current understanding of it,
I’m finding I agree with at least major portions of the concept.
Here’s one place I’m going from:

http://archive.eiffel.com/doc/manuals/technology/contract/

Last time I looked at DBC it was not with regard to Eiffel, and I must
have confused it with other bits I found disagreeable.

Actually, I’ve been pondering something similar, but from a Lisp point
of view, where you can basically say the same kind of thing… a
variable is going to be of some type, within a certain range, etc. I
wrote a module for type checking already, and have been considering
syntax for range checking, but this looks like a more flexible route.

  • documentation
  • separting normal control flow from “Exceptions”

I’m not sure what these refer to.

Using Exceptions for all kine of errors which can happen definitly
flawed.

Now here I disagree. Using exceptions for errors allows you to
consolidate checking and handling code, which alone is worth the
effort. Checking for an error condition after every call is
impractical, and thus error conditions are glossed over, leading to
bugs. Exceptions allow all conditions to get through and be handled
if necessary.

Using them for pre/postcondition checking just follows… if you fail,
say, a precondition, raising an exception with that specific
information is more useful than a simple abort.

I advocate complete programmatic knowledge of the program itself.
That is, if it exists, you should be able to query it. If a function
takes a type of parameter (or extending this to DBC, has a certain
precondition), you should be able to ask what it takes. Likewise, if
there is an error condition, the code should be aware of it. There
are very cool things you get from being able to do this, and a simple
abort defeats the point.

···

On Fri, 14 Mar 2003 15:40:38 +0900 Friedrich Dominicus frido@q-software-solutions.com wrote:


Ryan Pavlik rpav@users.sf.net

“And, as a result, I have about as much business on a
sea going vessel as a pretty unicorn princess.” - 8BT

Charles Hixson charleshixsn@earthlink.net writes:

Ryan Pavlik wrote:

exactly. i believe eiffel makes a big deal about them as part of “design
by contract”

I believe “design by contract” is flawed, but that’s another
discussion entirely.

DBC is probably flawed in the context of Ruby. In Eiffel it makes a lot
more sense. In Eiffel you know what type something is going to be
allowed to be. In Ruby assertions would probably only mean something
like 'This isn’t a kind of data I’m prepared to deal with", valuable
information, but not necessarily a sign of an error. In Eiffel this
would be a design error.
I’m not so convinced of this. You do not need the type of a Paramter
always but definitly it’s value. Assume you would have

def sqrt (n)
… return square root
it could make much sense to have
def sqrt (n)
require n_positive: n >= 0

Other thing which could make Assertions very nice in ruby you could
check if all elements of a collection fullfill some conditions. And
you can guarantee on the other hand that you guarantee that some
things hold…

And well it could be good for documentation too. you just would run

ruby -e short_form my_ruby_file.rb

and got a short form of the contracts of the features.

The major advantae is that this can be checked during runtime with a
computer… Somethin like having a comment like this

def sqrt (n)
# will calculate square root of negative n
if n < 0
raise

can not happen…

The main job being handled here is detecting errors, and figuring out
how to deal with them. Eiffel is better at the first part, and Ruby is
better at the second part.
Well that could suggest that it makes much sense to add DBC to Ruby,
this to improve on the first part.

Regards
Friedrich

···

On Fri, 14 Mar 2003 13:00:07 +0900 > >“Jason M Jurkowski ;002;icsg6;” jmj8237@cs.rit.edu wrote: