OT: Is this worth a try?
gregarican
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)?
David Vallner
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 Vallner
John Carter
> 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 Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john....@tait.co.nz
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.
Jim Weirich
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 Weirich
--
Posted via http://www.ruby-forum.com/.
Guido Kollerie
> 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
--
Guido
gregarican
> 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 Vallner
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!
David Vallner
> David Vallner 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 Vallner
Gene Tani
Jim Weirich 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
>
> 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 Weirich
>
Jens Auer
> On Thu, 16 Feb 2006, David Vallner 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.
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.
Seth Thomas Rasmussen
Eivind Eklund
> On 2/16/06, Jens Auer <jens.au...@betaversion.net> 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.
>
> compile time.
> 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.
Logan Capaldo
On Feb 16, 2006, at 12:35 PM, Edgardo Hames wrote:
> On 2/16/06, Jens Auer <jens.au...@betaversion.net> 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.
>
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.
> 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
>
Edgardo Hames
That's true only for preconditions. However, postconditions in
subclasses should strengthen that of parent's, i.e. child's returned
values are a subset of parent's.
Jim Weirich
> 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 Weirich
[1] Ensure in the Eiffel sense (defining preconditions) rather than
ensure in the Ruby sense (finally blocks).
Logan Capaldo
See if I ever try to clarify what someone else said ever again. I get
twenty closet Eiffel freaks attacking my pseudo-Ruby ;)
(I'm kidding...)
Hal Fulton
> 2006/2/16, Seth Thomas Rasmussen <sethra...@gmail.com>:
>
>>Everything is worth a try.
>
>
> I'm not sure about suicide though...
I've never heard complaints from people who did it right...
Hal
Jens Auer
>
> On Feb 16, 2006, at 12:35 PM, Edgardo Hames wrote:
>
>> On 2/16/06, Jens Auer <jens.au...@betaversion.net> 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.
12:35 PM. Can anybody repost it, so that it shows up in the newsgroup?
Adam Sanderson
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
gregarican
> 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.
Wow. That's pretty out there.
David Vallner
Io has some of the immense coolage a prototype-based OO language inherently
has. But the severe lack of documentation and the non-working samples scared
me away after a while - it's very hard to get past the "Yes, fun, and?" stage
in Io.
David Vallner
David Vallner
> Maybe I'll figure out those really functional wacky languages some day,
>
Type inference = da bomb. I recommend hacking up the assignments from a data
structures / algorithms class in OCaml while heavily abusing currying for a
start - great fun golfing them down to bestial tangles of nested functions
and pattern matches *cackle*. Also so fast it's almost scary. Stay clear from
the oddities like modules, signatures and OO to start. Scheme is also beyond
sexy, but not that viable for general use in my opinion.
David Vallner
gregarican
> Io has some of the immense coolage a prototype-based OO language inherently
> has. But the severe lack of documentation and the non-working samples scared
> me away after a while - it's very hard to get past the "Yes, fun, and?" stage
> in Io.
>
> David Vallner
I think I want to create my own scripting language and interpreter that
is perhaps even more obscure. I am going to call it "Izzle." The syntax
will be taken from urban, hop-hop lingo that uses the -izzle suffix
like Pig Latin. E.g. - Rizzle Dizzle Fo Shizzzle. It might be fun for
laughs...
David Vallner
> I think I want to create my own scripting language and interpreter that
> is perhaps even more obscure. I am going to call it "Izzle." The syntax
> will be taken from urban, hop-hop lingo that uses the -izzle suffix
> like Pig Latin. E.g. - Rizzle Dizzle Fo Shizzzle. It might be fun for
> laughs...
Bah. I say stay with Ook for that :P
David Vallner