Forum: Ruby OT: Is this worth a try?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Greg K. (Guest)
on 2006-02-15 21:33
(Received via mailing list)
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)?
David V. (Guest)
on 2006-02-16 00:14
(Received via mailing list)
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.
John C. (Guest)
on 2006-02-16 00:21
(Received via mailing list)
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.
Jim W. (Guest)
on 2006-02-16 07:48
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.
Guido Kollerie (Guest)
on 2006-02-16 11:40
(Received via mailing list)
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
David V. (Guest)
on 2006-02-16 16:09
(Received via mailing list)
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.
Greg K. (Guest)
on 2006-02-16 16:09
(Received via mailing list)
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!
Gene T. (Guest)
on 2006-02-16 16:18
(Received via mailing list)
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
Jens A. (Guest)
on 2006-02-16 16:37
(Received via mailing list)
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.
Seth Thomas R. (Guest)
on 2006-02-16 18:29
(Received via mailing list)
Everything is worth a try.
Edgardo H. (Guest)
on 2006-02-16 19:38
(Received via mailing list)
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
Robert K. (Guest)
on 2006-02-16 19:59
(Received via mailing list)
2006/2/16, Seth Thomas R. <removed_email_address@domain.invalid>:
> Everything is worth a try.

I'm not sure about suicide though...

robert
Eivind E. (Guest)
on 2006-02-16 20:20
(Received via mailing list)
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.
Logan C. (Guest)
on 2006-02-16 21:30
(Received via mailing list)
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.
Edgardo H. (Guest)
on 2006-02-16 21:57
(Received via mailing list)
On 2/16/06, Logan C. <removed_email_address@domain.invalid> wrote:
> >> that a method can only widen the supermethod's contracts which is
>
>        precondition: n > 0 #Ok, because any inputs that were valid
>
> 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.

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.

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
Jim W. (Guest)
on 2006-02-16 22:35
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).
John C. (Guest)
on 2006-02-16 23:22
(Received via mailing list)
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.
Logan C. (Guest)
on 2006-02-17 00:50
(Received via mailing list)
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 ;)



(I'm kidding...)
Hal F. (Guest)
on 2006-02-17 02:51
(Received via mailing list)
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
Jens A. (Guest)
on 2006-02-17 10:43
(Received via mailing list)
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?
Adam S. (Guest)
on 2006-02-18 04:53
(Received via mailing list)
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
Greg K. (Guest)
on 2006-02-18 08:13
(Received via mailing list)
Adam S. wrote:

> 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 V. (Guest)
on 2006-02-18 17:16
(Received via mailing list)
DÅ?a Sobota 18 Február 2006 07:13 gregarican napísal:
> Adam S. wrote:
> > 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.

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 V.
David V. (Guest)
on 2006-02-18 17:22
(Received via mailing list)
DÅ?a Sobota 18 Február 2006 03:53 Adam S. napísal:
> 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 V.
Greg K. (Guest)
on 2006-02-18 22:10
(Received via mailing list)
David V. wrote:

> 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 V.

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 V. (Guest)
on 2006-02-19 14:45
(Received via mailing list)
DÅ?a Sobota 18 Február 2006 21:08 gregarican napísal:
> 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 V.
This topic is locked and can not be replied to.