OT: Is this worth a try?


#1

I am trying out some other scripting languages and wanted to give
Eiffel a try. Since a lot of the folks who post here seem to be
familiar with other languages than Ruby I was wondering if anyone had
some comments on how Eiffel is to learn. Coming from a Ruby/Smalltalk
background and mindset. Is it worth a shot? I downloaded the
EiffelStudio free version and am considering recoding a basic app in
Eiffel to see how it works. Will it be something that should be
enjoyable (or at least not that big of a PITA)?


#2

DÅ?a Streda 15 Február 2006 20:33 gregarican napísal:

I am trying out some other scripting languages and wanted to give
Eiffel a try. Since a lot of the folks who post here seem to be
familiar with other languages than Ruby I was wondering if anyone had
some comments on how Eiffel is to learn. Coming from a Ruby/Smalltalk
background and mindset. Is it worth a shot? I downloaded the
EiffelStudio free version and am considering recoding a basic app in
Eiffel to see how it works. Will it be something that should be
enjoyable (or at least not that big of a PITA)?

Eiffel is:

a) Completely dead, I’d say even more so than Smalltalk.
b) The prime example of a bondage and discipline language. Which you
might or
might not like, but If you do, you’re probably better off with C++ for
overall usefulness.

David V.


#3

On Thu, 16 Feb 2006, David V. wrote:

b) The prime example of a bondage and discipline language. Which you might or
might not like, but If you do, you’re probably better off with C++ for
overall usefulness.

Note that B&D is all bad, but you certainly can mimic many of the B&D
features of Eifel in Ruby.

In fact I personally recommend doing both Test Driven Development to
drive
the code through it’s paces, but putting the assert’s as preconditions,
postconditions and invariants within the code in the Eifel style.

You find run time bugs much faster that way.

John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : removed_email_address@domain.invalid
New Zealand

Carter’s Clarification of Murphy’s Law.

“Things only ever go right so that they may go more spectacularly wrong
later.”

From this principle, all of life and physics may be deduced.


#4

David V. wrote:

Eiffel is:

a) Completely dead, I’d say even more so than Smalltalk.

Despite being ‘completely dead’ someone found it to be the appropriate
tool to write a commercial Ruby IDE in, namely Arachno Ruby:

 http://www.ruby-ide.com/ruby/faq.php

#5

DÅ?a Å tvrtok 16 Február 2006 10:38 Guido Kollerie napísal:

David V. wrote:

Eiffel is:

a) Completely dead, I’d say even more so than Smalltalk.

Despite being ‘completely dead’ someone found it to be the appropriate
tool to write a commercial Ruby IDE in, namely Arachno Ruby:

The popularity of a language is completely unrelated to whether it’s a
good
tool for anything. I just wouldn’t count on Eiffel paying your bills. It
just
could happen, but it’s not very likely.

David V.


#6

Greg Kujawa wrote:

I am trying out some other scripting languages and wanted to give
Eiffel a try. Since a lot of the folks who post here seem to be
familiar with other languages than Ruby I was wondering if anyone had
some comments on how Eiffel is to learn. Coming from a Ruby/Smalltalk
background and mindset. Is it worth a shot? I downloaded the
EiffelStudio free version and am considering recoding a basic app in
Eiffel to see how it works. Will it be something that should be
enjoyable (or at least not that big of a PITA)?

I played around with Eiffel for 3 years before switching to Ruby. In 6
months I wrote more Ruby code than in the entire 3 years of Eiffel.
Productivity is way higher in Ruby.

However, the concepts learned in Eiffel were valuable for me. No, you
are probably not going to land your next big job because you know
Eiffel, but learning to use Eiffel well will help you write better code
in any OO language, IMHO.

– Jim W.


#7

Jim W. wrote:

Greg Kujawa wrote:

I am trying out some other scripting languages and wanted to give
Eiffel a try. Since a lot of the folks who post here seem to be

– Jim W.

http://www.artima.com/articles/index.jsp?topic=eiffel


#8

David Valler wrote:

Eiffel is:

a) Completely dead, I’d say even more so than Smalltalk.
b) The prime example of a bondage and discipline language. Which you > > might or
might not like, but If you do, you’re probably better off with C++ for
overall usefulness.

David V.

Thanks for the info. Breezing through some source code example the
syntax and rules didn’t exactly click with me like things did when I
first started learning Ruby. So far the languages I really enjoy coding
in are Ruby, Python, and Smalltalk. Things seem relatively clean,
concise, and “just make sense” to the way I think.

A language I have tried to port projects to for the heck of it but just
can’t seem to get up the interest is Java. Trying to port an app to the
Palm OS I see that Java has various implementations that will allow me
to do so. Like J2ME, IBM Websphere, and a few others. But the
verbosity, syntax, rules, readability, etc. leave me sitting there
frowning. Okay I want to create a instance of their Vector class. So I
have to type out something like:

Vector parameters = new Vector();

Ewww. Whereas in Ruby I can just say:

parameters = []

I know it’s just taste and preference, but I’m glad I found alternative
languages like Ruby!


#9

Everything is worth a try.


#10

John C. wrote:

In fact I personally recommend doing both Test Driven Development to
drive the code through it’s paces, but putting the assert’s as
preconditions, postconditions and invariants within the code in the
Eifel style.

You find run time bugs much faster that way.
Design by contract is a little bit more than placing asserts at the
beginning and end of a method. I would be realy glad if someone points
me to some library wich implements DbC completely in Ruby, eg the fact
that a method can only widen the supermethod’s contracts which is
automatically checked.


#11

On 2/16/06, Jens A. removed_email_address@domain.invalid wrote:

Design by contract is a little bit more than placing asserts at the
beginning and end of a method. I would be realy glad if someone points
me to some library wich implements DbC completely in Ruby, eg the fact
that a method can only widen the supermethod’s contracts which is
automatically checked.

I assume that “automatically checked” means checking the contracts at
compile time.
That’s an undecidible problem.

Cheers,
Ed

Encontrá a “Tu psicópata favorito” http://tuxmaniac.blogspot.com

Thou shalt study thy libraries and strive not to reinvent them without
cause,
that thy code may be short and readable and thy days pleasant and
productive.
– Seventh commandment for C programmers


#12

2006/2/16, Seth Thomas R. removed_email_address@domain.invalid:

Everything is worth a try.

I’m not sure about suicide though…

robert


#13

On 2/16/06, Edgardo H. removed_email_address@domain.invalid wrote:

That’s an undecidible problem.
Yup, so that’s not what Eiffel compilers do. Instead, they administer
the execution of run time checks. Eiffel use trickery to ensure that
you only program cases that ARE decideable, too: Loop invariants are
checked by having a block that has to return asmaller value for each
iteration of the loop. Fortunately, many many invariants can be
specified in a useful way, even if there are some cases that can’t.

Also, technically, isn’t that only undecidable if you assume an
infinite size Turing machine, while a finite size computer IS
decidable, it’s just impractical? At least as long as you actually
can formally specify the invariant?

Eivind.


#14

On Feb 16, 2006, at 12:35 PM, Edgardo H. wrote:

I assume that “automatically checked” means checking the contracts at
compile time.
That’s an undecidible problem.

No he means that a override of a method implemented in a subclass can
only widen the contract, and that that is automatically checked. Not
that the contract is fulfilled at compile time.

e.g.

class A
def meth(n)
precondition: n > 1
end
end

class B < A
def meth(n)
precondition: n > 0 #Ok, because any inputs that were valid
for A#meth are valid for B#meth, this is checked at compile time
end
end

class C < A
def meth(n)
precondition: n > 2 #Will not compile, C#meth accepts a narrower
range of inputs than A, does not follow Liskov Substitution Principle
end
end

Note this is not the same thing as checking whether a call will
fulfill conditions at compile time, just that the set of values
accepted by a subclasses overridden version of a method is a
superset of the set of values accepted by the parent’s version of the
method.


#15

Logan C. wrote:

class C < A
def meth(n)
precondition: n > 2 #Will not compile, C#meth accepts a narrower
range of inputs than A, does not follow Liskov Substitution Principle
end
end

Actually, in Eiffel, this wouldn’t be a compile error. Preconditions in
a derived class is logically ORed with the those in the parent class.
So that the full precondition for C#meth will be

precondition: (n > 2) || (n > 1)

Since the preconditions are ORed, they can only be widened in derivied
classes. If you were using full Eiffel syntax, you would state derived
class preconditions with “require else” rather than the plain “require”
to help you remember that you can only widen the preconditions.

Likewise postconditions in derived classes are ANDed with those in
parent classes, so they can only be narrowed (and “ensure and” is used
rather than the vanilla “ensure” [1]).


– Jim W.

[1] Ensure in the Eiffel sense (defining preconditions) rather than
ensure in the Ruby sense (finally blocks).


#16

On Thu, 16 Feb 2006, Jens A. wrote:

You find run time bugs much faster that way.
Design by contract is a little bit more than placing asserts at the beginning
and end of a method. I would be realy glad if someone points me to some
library wich implements DbC completely in Ruby, eg the fact that a method can
only widen the supermethod’s contracts which is automatically checked.

http://www.rubycentral.com/downloads/dbc.html

I don’t think that does quite all you want, but I find I get 90% of the
value I need out of static type checking, polymorhic type checking and
DbC
by very very simple roll you own oneliners…

class Boo
def bah( goo)
raise “Whinge” unless expression && goo.responds_to? :glue_it

 invariant
 #do stuff
 raise "Whinge" unless post_expression
 invariant # If I'm paranoid

end

def invariant
raise “Moan” unless invariant_expression
end
end

John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : removed_email_address@domain.invalid
New Zealand

Carter’s Clarification of Murphy’s Law.

“Things only ever go right so that they may go more spectacularly wrong
later.”

From this principle, all of life and physics may be deduced.


#17

On Feb 16, 2006, at 3:36 PM, Jim W. wrote:

a derived class is logically ORed with the those in the parent class.


Posted via http://www.ruby-forum.com/.

See if I ever try to clarify what someone else said ever again. I get
twenty closet Eiffel freaks attacking my pseudo-Ruby :wink:

(I’m kidding…)


#18

Robert K. wrote:

2006/2/16, Seth Thomas R. removed_email_address@domain.invalid:

Everything is worth a try.

I’m not sure about suicide though…

I’ve never heard complaints from people who did it right…

Hal


#19

Logan C. wrote:

I assume that “automatically checked” means checking the contracts at
compile time.
That’s an undecidible problem.
Sorry, but I can’t see the posting from Edgardo H., Feb 16, 2006, at
12:35 PM. Can anybody repost it, so that it shows up in the newsgroup?


#20

I think every new language you learn helps you greatly. I would
personaly suggest looking at Io,
http://www.iolanguage.com/about/
It took me a few hits on their site before I really looked at it, and
then a little longer to appreciate it, but once I did, wow.

Each language allows a different framework for solving a problem, and
will enrich your understanding of all other languages through the
similarities and differences.

Maybe I’ll figure out those really functional wacky languages some day,
.adam