OT: Is this worth a try?

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)?

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

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

···

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

Everything is worth a try.

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

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.

···

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.

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

···

--
Guido

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!

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

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

I'm not sure about suicide though...

robert

···

2006/2/16, Seth Thomas Rasmussen <sethrasmussen@gmail.com>:

Everything is worth a try.

--
Have a look: Robert K. | Flickr

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.

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

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

John Carter wrote:

···

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.

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.

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

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

I assume that "automatically checked" means checking the contracts at
compile time.
That's an undecidible problem.

Cheers,
Ed

···

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.

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

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.

···

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.

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

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.

···

On 2/16/06, Edgardo Hames <ehames@gmail.com> wrote:

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.