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.
33ec7e55a251c1be8d6febfd929aebbe?d=identicon&s=25 Greg Kujawa (gregarican)
on 2006-02-15 20: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)?
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-15 23: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 Vallner
D812408537ac3a0fa2fec96eb8811559?d=identicon&s=25 John Carter (Guest)
on 2006-02-15 23:21
(Received via mailing list)
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.


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@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.
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-02-16 06: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 Weirich
8225e35285f5bd1bc59b02e5f4a7d994?d=identicon&s=25 Guido Kollerie (Guest)
on 2006-02-16 10:40
(Received via mailing list)
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:

     http://www.ruby-ide.com/ruby/faq.php
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-16 15:09
(Received via mailing list)
DÅ?a Å tvrtok 16 Február 2006 10:38 Guido Kollerie napísal:
> 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
33ec7e55a251c1be8d6febfd929aebbe?d=identicon&s=25 Greg Kujawa (gregarican)
on 2006-02-16 15: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 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!
9dfe8c734b0f9b37a4e218425c0a2138?d=identicon&s=25 Gene Tani (Guest)
on 2006-02-16 15:18
(Received via mailing list)
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
....
> -- Jim Weirich
>

http://www.artima.com/articles/index.jsp?topic=eiffel
1bc028840986928fb298a9eb456dbb22?d=identicon&s=25 Jens Auer (Guest)
on 2006-02-16 15:37
(Received via mailing list)
John Carter 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.
40823088cec28c3224ff4c46ced1beda?d=identicon&s=25 Seth Thomas Rasmussen (Guest)
on 2006-02-16 17:29
(Received via mailing list)
Everything is worth a try.
Cf985658ff32a83d07cdfaa22c294fe4?d=identicon&s=25 Edgardo Hames (Guest)
on 2006-02-16 18:38
(Received via mailing list)
On 2/16/06, Jens Auer <jens.auer-news@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.

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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-02-16 18:59
(Received via mailing list)
2006/2/16, Seth Thomas Rasmussen <sethrasmussen@gmail.com>:
> Everything is worth a try.

I'm not sure about suicide though...

robert
A6d3a37b5badfdd2f47655aa0e46604e?d=identicon&s=25 Eivind Eklund (Guest)
on 2006-02-16 19:20
(Received via mailing list)
On 2/16/06, Edgardo Hames <ehames@gmail.com> 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.
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-02-16 20:30
(Received via mailing list)
On Feb 16, 2006, at 12:35 PM, Edgardo Hames 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.
Cf985658ff32a83d07cdfaa22c294fe4?d=identicon&s=25 Edgardo Hames (Guest)
on 2006-02-16 20:57
(Received via mailing list)
On 2/16/06, Logan Capaldo <logancapaldo@gmail.com> 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
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-02-16 21:35
Logan Capaldo 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 Weirich

[1] Ensure in the Eiffel sense (defining preconditions) rather than
ensure in the Ruby sense (finally blocks).
D812408537ac3a0fa2fec96eb8811559?d=identicon&s=25 John Carter (Guest)
on 2006-02-16 22:22
(Received via mailing list)
On Thu, 16 Feb 2006, Jens Auer 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 Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@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.
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-02-16 23:50
(Received via mailing list)
On Feb 16, 2006, at 3:36 PM, Jim Weirich 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...)
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-02-17 01:51
(Received via mailing list)
Robert Klemme wrote:
> 2006/2/16, Seth Thomas Rasmussen <sethrasmussen@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
1bc028840986928fb298a9eb456dbb22?d=identicon&s=25 Jens Auer (Guest)
on 2006-02-17 09:43
(Received via mailing list)
Logan Capaldo 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 Hames, Feb 16, 2006, at
12:35 PM. Can anybody repost it, so that it shows up in the newsgroup?
65bd9e4c5aebde25ebf16d599339d570?d=identicon&s=25 Adam Sanderson (Guest)
on 2006-02-18 03: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
33ec7e55a251c1be8d6febfd929aebbe?d=identicon&s=25 Greg Kujawa (gregarican)
on 2006-02-18 07:13
(Received via mailing list)
Adam Sanderson 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.
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-18 16:16
(Received via mailing list)
DÅ?a Sobota 18 Február 2006 07:13 gregarican napísal:
> Adam Sanderson 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 Vallner
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-18 16:22
(Received via mailing list)
DÅ?a Sobota 18 Február 2006 03:53 Adam Sanderson 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 Vallner
33ec7e55a251c1be8d6febfd929aebbe?d=identicon&s=25 Greg Kujawa (gregarican)
on 2006-02-18 21:10
(Received via mailing list)
David Vallner 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 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...
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2006-02-19 13: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 Vallner
This topic is locked and can not be replied to.