Daniel Díaz Casanueva | 30 Dec 20:58 2012
Picon

Object Oriented programming for Functional Programmers

Hello, Haskell Cafe folks.

My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though.

But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.

But, why I am writing this to you, haskellers?

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

* Will I learn new programming strategies that I can use back in the Haskell world?

Thanks in advance for your kind responses,
Daniel Díaz.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jay Sulzberger | 30 Dec 21:11 2012
Picon

Re: Object Oriented programming for Functional Programmers


On Sun, 30 Dec 2012, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:

> Hello, Haskell Cafe folks.
>
> My programming life (which has started about 3-4 years ago) has always been
> in the functional paradigm. Eventually, I had to program in Pascal and
> Prolog for my University (where I learned Haskell). I also did some PHP,
> SQL and HTML while building some web sites, languages that I taught to
> myself. I have never had any contact with JavaScript though.
>
> But all these languages were in my life as secondary languages, being
> Haskell my predominant preference. Haskell was the first programming
> language I learned, and subsequent languages never seemed so natural and
> worthwhile to me. In fact, every time I had to use another language, I
> created a combinator library in Haskell to write it (this was the reason
> that brought me to start with the HaTeX library). Of course, this practice
> wasn't always the best approach.
>
> But, why I am writing this to you, haskellers?
>
> Well, my curiosity is bringing me to learn a new general purpose
> programming language. Haskellers are frequently comparing Object-Oriented
> languages with Haskell itself, but I have never programmed in any
> OO-language! (perhaps this is an uncommon case) I thought it could be good
> to me (as a programmer) to learn C/C++. Many interesting courses (most of
> them) use these languages and I feel like limited for being a Haskell
> programmer. It looks like I have to learn imperative programming (with side
> effects all over around) in some point of my programming life.
>
> So my questions for you all are:
>
> * Is it really worthwhile for me to learn OO-programming?
>
> * If so, where should I start? There are plenty of "functional programming
> for OO programmers" but I have never seen "OO programming for functional
> programmers".

There are several different things called "object oriented
programming".  Here is what Alan Kay once said about C++:

   Actually I made up the term "object-oriented", and I can tell
   you I did not have C++ in mind.

Above quote from

   http://en.wikiquote.org/wiki/Alan_Kay
   [page was last modified on 30 November 2012, at 16:06]

For me the most important things about "objects" are:

1. In the World of the Programming System there is a version of
    Lisp's eq?, ah that word is the Scheme word.

2. Really, objects are what are now called "agents".

The word "inheritance" does not appear in the first 600^W300
pages of my Ideal Textbook on the Theory of Objects in
Programming.

oo--JS.

>
> * Is it true that learning other programming languages leads to a better
> use of your favorite programming language?
>
> * Will I learn new programming strategies that I can use back in the
> Haskell world?
>
> Thanks in advance for your kind responses,
> Daniel Díaz.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 30 Dec 21:37 2012
Picon

Re: Object Oriented programming for Functional Programmers

Well, "functional programmer" is a relatively broad term. If you're coming from academia, so that for you
Haskell is some sort of lambda-calculus, spoiled by practical aspects, then I'd suggest Luca Cardelli's
book "Theory of Objects".

Also, as Daniel told you already, don't start from C++, it really has very little to do with OOP. It's primary
merit is a very powerful system of macros (called "templates" in C++ world), not objects. If you want
something mainstream, Java would be a good choice, and C# even better one (although it would be more
convenient for you if you use Windows).

Or you can try OCaml, which is functional enough for you not to feel lost, and object-oriented as well.

Отправлено с iPad

30.12.2012, в 23:58, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> написал(а):

> Hello, Haskell Cafe folks.
> 
> My programming life (which has started about 3-4 years ago) has always been in the functional paradigm.
Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did
some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any
contact with JavaScript though. 
> 
> But all these languages were in my life as secondary languages, being Haskell my predominant preference.
Haskell was the first programming language I learned, and subsequent languages never seemed so natural
and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in
Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this
practice wasn't always the best approach.
> 
> But, why I am writing this to you, haskellers?
> 
> Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are
frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any
OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn
C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a
Haskell programmer. It looks like I have to learn imperative programming (with side effects all over
around) in some point of my programming life.
> 
> So my questions for you all are:
> 
> * Is it really worthwhile for me to learn OO-programming?
> 
> * If so, where should I start? There are plenty of "functional programming for OO programmers" but I have
never seen "OO programming for functional programmers".
> 
> * Is it true that learning other programming languages leads to a better use of your favorite programming language?
> 
> * Will I learn new programming strategies that I can use back in the Haskell world?
> 
> Thanks in advance for your kind responses,
> Daniel Díaz.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jay Sulzberger | 31 Dec 03:12 2012
Picon

Re: Object Oriented programming for Functional Programmers


On Mon, 31 Dec 2012, MigMit <miguelimo38 <at> yandex.ru> wrote:

> Well, "functional programmer" is a relatively broad term. If
> you're coming from academia, so that for you Haskell is some
> sort of lambda-calculus, spoiled by practical aspects, then I'd
> suggest Luca Cardelli's book "Theory of Objects".
>
> Also, as Daniel told you already, don't start from C++, it

Name typo, should be "Jay", noted.

> really has very little to do with OOP. It's primary merit is a
> very powerful system of macros (called "templates" in C++
> world), not objects. If you want something mainstream, Java
> would be a good choice, and C# even better one (although it
> would be more convenient for you if you use Windows).
>
> Or you can try OCaml, which is functional enough for you not to
> feel lost, and object-oriented as well.
>
> Отправлено с iPad

For systems to look at I recommend Simula, some early version,
Smalltalk, Common Lisp, and Erlang.  My guess is that Haskell's
type classes are a mechanism for creating something like Common
Lisp's "generic functions".  I know too little about Haskell to
say whether type classes immediately give you "single dispatch"
things, or "multiple dispatch" things.

These two Wikipedia articles are useful, I think:

   http://en.wikipedia.org/wiki/Generic_function
   [page was last modified on 15 November 2012 at 03:50]

   http://en.wikipedia.org/wiki/Common_Lisp_Object_System
   [page was last modified on 15 December 2012 at 23:57]

The Diamond Problem and its cousin(s) are worth looking at:

   http://en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem
   [page was last modified on 27 December 2012 at 04:53]

   http://www.ibm.com/developerworks/java/library/j-clojure-protocols/

   http://stackoverflow.com/questions/4509782/simple-explanation-of-clojure-protocols

oo--JS.

30.12.2012, в 23:58, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> написал(а):

> Hello, Haskell Cafe folks.
> 
> My programming life (which has started about 3-4 years ago) has always been in the functional paradigm.
Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did
some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any
contact with JavaScript though. 
> 
> But all these languages were in my life as secondary languages, being Haskell my predominant preference.
Haskell was the first programming language I learned, and subsequent languages never seemed so natural
and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in
Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this
practice wasn't always the best approach.
> 
> But, why I am writing this to you, haskellers?
> 
> Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are
frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any
OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn
C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a
Haskell programmer. It looks like I have to learn imperative programming (with side effects all over
around) in some point of my programming life.
> 
> So my questions for you all are:
> 
> * Is it really worthwhile for me to learn OO-programming?
> 
> * If so, where should I start? There are plenty of "functional programming for OO programmers" but I have
never seen "OO programming for functional programmers".
> 
> * Is it true that learning other programming languages leads to a better use of your favorite programming language?
> 
> * Will I learn new programming strategies that I can use back in the Haskell world?
> 
> Thanks in advance for your kind responses,
> Daniel Díaz.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jay Sulzberger | 31 Dec 03:21 2012
Picon

Added CLOS reference, was: Re: Object Oriented programming for Functional Programmers

This page looks to be a good introduction to CLOS:

   http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html

oo--JS.

On Sun, 30 Dec 2012, Jay Sulzberger wrote:

>
>
> On Mon, 31 Dec 2012, MigMit <miguelimo38 <at> yandex.ru> wrote:
>
>> Well, "functional programmer" is a relatively broad term. If
>> you're coming from academia, so that for you Haskell is some
>> sort of lambda-calculus, spoiled by practical aspects, then I'd
>> suggest Luca Cardelli's book "Theory of Objects".
>> 
>> Also, as Daniel told you already, don't start from C++, it
>
> Name typo, should be "Jay", noted.
>
>> really has very little to do with OOP. It's primary merit is a
>> very powerful system of macros (called "templates" in C++
>> world), not objects. If you want something mainstream, Java
>> would be a good choice, and C# even better one (although it
>> would be more convenient for you if you use Windows).
>> 
>> Or you can try OCaml, which is functional enough for you not to
>> feel lost, and object-oriented as well.
>> 
>> Отправлено с iPad
>
> For systems to look at I recommend Simula, some early version,
> Smalltalk, Common Lisp, and Erlang.  My guess is that Haskell's
> type classes are a mechanism for creating something like Common
> Lisp's "generic functions".  I know too little about Haskell to
> say whether type classes immediately give you "single dispatch"
> things, or "multiple dispatch" things.
>
> These two Wikipedia articles are useful, I think:
>
>  http://en.wikipedia.org/wiki/Generic_function
>  [page was last modified on 15 November 2012 at 03:50]
>
>  http://en.wikipedia.org/wiki/Common_Lisp_Object_System
>  [page was last modified on 15 December 2012 at 23:57]
>
> The Diamond Problem and its cousin(s) are worth looking at:
>
>  http://en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem
>  [page was last modified on 27 December 2012 at 04:53]
>
>  http://www.ibm.com/developerworks/java/library/j-clojure-protocols/
>
>  http://stackoverflow.com/questions/4509782/simple-explanation-of-clojure-protocols
>
> oo--JS.
>
>
>
> 30.12.2012, в 23:58, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> 
> написал(а):
>
>> Hello, Haskell Cafe folks.
>> 
>> My programming life (which has started about 3-4 years ago) has always been 
>> in the functional paradigm. Eventually, I had to program in Pascal and 
>> Prolog for my University (where I learned Haskell). I also did some PHP, 
>> SQL and HTML while building some web sites, languages that I taught to 
>> myself. I have never had any contact with JavaScript though. 
>> But all these languages were in my life as secondary languages, being 
>> Haskell my predominant preference. Haskell was the first programming 
>> language I learned, and subsequent languages never seemed so natural and 
>> worthwhile to me. In fact, every time I had to use another language, I 
>> created a combinator library in Haskell to write it (this was the reason 
>> that brought me to start with the HaTeX library). Of course, this practice 
>> wasn't always the best approach.
>> 
>> But, why I am writing this to you, haskellers?
>> 
>> Well, my curiosity is bringing me to learn a new general purpose 
>> programming language. Haskellers are frequently comparing Object-Oriented 
>> languages with Haskell itself, but I have never programmed in any 
>> OO-language! (perhaps this is an uncommon case) I thought it could be good 
>> to me (as a programmer) to learn C/C++. Many interesting courses (most of 
>> them) use these languages and I feel like limited for being a Haskell 
>> programmer. It looks like I have to learn imperative programming (with side 
>> effects all over around) in some point of my programming life.
>> 
>> So my questions for you all are:
>> 
>> * Is it really worthwhile for me to learn OO-programming?
>> 
>> * If so, where should I start? There are plenty of "functional programming 
>> for OO programmers" but I have never seen "OO programming for functional 
>> programmers".
>> 
>> * Is it true that learning other programming languages leads to a better 
>> use of your favorite programming language?
>> 
>> * Will I learn new programming strategies that I can use back in the 
>> Haskell world?
>> 
>> Thanks in advance for your kind responses,
>> Daniel Díaz.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Eric Rasmussen | 31 Dec 04:41 2012
Picon

Re: Object Oriented programming for Functional Programmers

Since no one's mentioned it yet, you might consider learning Scala. A good starting point is http://www.artima.com/pins1ed/index.html (note that the free edition is outdated but still a good introduction).

Scala has a mix of functional and OO programming styles, though (having come first from Haskell) I'd say it favors the OO side. If you approach it as OO with some nice functional touches (higher level list operations, immutability, recursively defined data structures, and pattern matching), it can be very fun to work with.

Scala's type system is also more expressive than the other OO languages I've worked with, which is a big plus if you're coming from Haskell. Learning about subtyping and variance annotations via Scala gives you tools for reasoning about objects that you won't get from dynamically typed OO languages.

On Sun, Dec 30, 2012 at 6:12 PM, Jay Sulzberger <jays <at> panix.com> wrote:


On Mon, 31 Dec 2012, MigMit <miguelimo38 <at> yandex.ru> wrote:

Well, "functional programmer" is a relatively broad term. If
you're coming from academia, so that for you Haskell is some
sort of lambda-calculus, spoiled by practical aspects, then I'd
suggest Luca Cardelli's book "Theory of Objects".

Also, as Daniel told you already, don't start from C++, it

Name typo, should be "Jay", noted.


really has very little to do with OOP. It's primary merit is a
very powerful system of macros (called "templates" in C++
world), not objects. If you want something mainstream, Java
would be a good choice, and C# even better one (although it
would be more convenient for you if you use Windows).

Or you can try OCaml, which is functional enough for you not to
feel lost, and object-oriented as well.

Отправлено с iPad

For systems to look at I recommend Simula, some early version,
Smalltalk, Common Lisp, and Erlang.  My guess is that Haskell's
type classes are a mechanism for creating something like Common
Lisp's "generic functions".  I know too little about Haskell to
say whether type classes immediately give you "single dispatch"
things, or "multiple dispatch" things.

These two Wikipedia articles are useful, I think:

  http://en.wikipedia.org/wiki/Generic_function
  [page was last modified on 15 November 2012 at 03:50]

  http://en.wikipedia.org/wiki/Common_Lisp_Object_System
  [page was last modified on 15 December 2012 at 23:57]

The Diamond Problem and its cousin(s) are worth looking at:

  http://en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem
  [page was last modified on 27 December 2012 at 04:53]

  http://www.ibm.com/developerworks/java/library/j-clojure-protocols/

  http://stackoverflow.com/questions/4509782/simple-explanation-of-clojure-protocols

oo--JS.




30.12.2012, в 23:58, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> написал(а):

Hello, Haskell Cafe folks.

My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though.
But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.

But, why I am writing this to you, haskellers?

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

* Will I learn new programming strategies that I can use back in the Haskell world?

Thanks in advance for your kind responses,
Daniel Díaz.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 30 Dec 21:39 2012
Picon

Re: Object Oriented programming for Functional Programmers

Sorry for the stupid mistake — when I said "Daniel" in the previous message, I've meant "Jay".

Отправлено с iPad

30.12.2012, в 23:58, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> написал(а):

> Hello, Haskell Cafe folks.
> 
> My programming life (which has started about 3-4 years ago) has always been in the functional paradigm.
Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did
some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any
contact with JavaScript though. 
> 
> But all these languages were in my life as secondary languages, being Haskell my predominant preference.
Haskell was the first programming language I learned, and subsequent languages never seemed so natural
and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in
Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this
practice wasn't always the best approach.
> 
> But, why I am writing this to you, haskellers?
> 
> Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are
frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any
OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn
C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a
Haskell programmer. It looks like I have to learn imperative programming (with side effects all over
around) in some point of my programming life.
> 
> So my questions for you all are:
> 
> * Is it really worthwhile for me to learn OO-programming?
> 
> * If so, where should I start? There are plenty of "functional programming for OO programmers" but I have
never seen "OO programming for functional programmers".
> 
> * Is it true that learning other programming languages leads to a better use of your favorite programming language?
> 
> * Will I learn new programming strategies that I can use back in the Haskell world?
> 
> Thanks in advance for your kind responses,
> Daniel Díaz.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Eli Frey | 30 Dec 21:45 2012
Picon

Re: Object Oriented programming for Functional Programmers

I think it is always a good idea to learn languages that make <your-favorite-paradigm> hard.  There are a lot of "Aha" moments to be had from forcing your brain to come at a problem from another angle.

As for things to watch out for.

There is a very strong duality between TypeClasses and existential polymorphism in OO. Both require a way to dynamically look up the correct implementation for the type you are operating upon.  In Haskell we use Typeclasses which place this lookup table on the functions that have existential constraints on them.

> mconcat :: Monad m => [m] -> m
> mconcat = foldl mappend []

We can think of `mconcat` having a little lookup table inside of itself, and whenever we pass it a concrete `[m]`, `mappend` gets looked up and we get the implementation for `m`.  Typeclasses are just mappings from types to functions

In OO on the other hand, the lookup table is attached to the datastructure.  We can think of the Object as a mapping from function names to functions that operate on that Object.  Python, Javascript, Ruby, and of course Smalltalk make this quite explicit.

Aside from Object Orientation, it is probably a good idea to learn some C for a bit too.  C is a good language to play in and try and implement more advanced language features.  Once you reallize that objects are just lookup tables of functions bound with a data-structure, you can implement your own in C, or you can make closures as functions bundled with (some) of their arguments, or you can implement interesting datastructures, or so many other fun things.  A good understanding of tagged unions has helped me in many a convo with an OO head.


On Sun, Dec 30, 2012 at 11:58 AM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:
Hello, Haskell Cafe folks.

My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though.

But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.

But, why I am writing this to you, haskellers?

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

* Will I learn new programming strategies that I can use back in the Haskell world?

Thanks in advance for your kind responses,
Daniel Díaz.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Brandon Allbery | 30 Dec 22:27 2012
Picon

Re: Object Oriented programming for Functional Programmers

On Sun, Dec 30, 2012 at 3:45 PM, Eli Frey <eli.lee.frey <at> gmail.com> wrote:
> mconcat :: Monad m => [m] -> m
> mconcat = foldl mappend []

We can think of `mconcat` having a little lookup table inside of itself, and whenever we pass it a concrete `[m]`, `mappend` gets looked up and we get the implementation for `m`.  Typeclasses are just mappings from types to functions

Except not quite... the "Monad m =>" in the signature really means "hey, compiler, pass me the appropriate implementation of Monad so I can figure out what I'm doing with this type m".  It's not a built in table, it's a hidden parameter.

Aside from Object Orientation, it is probably a good idea to learn some C for a bit too.  C is a good language to play in and try and implement more advanced language features.  Once you reallize that objects are just lookup tables of functions bound with a data-structure, you can implement your own in C, or you can make closures as functions bundled with (some) of their arguments, or you can implement interesting datastructures, or so many other fun things.  A good understanding of tagged unions has helped me in many a convo with an OO head.

A perhaps strange suggestion in this vein:  dig up the source code for Xt, the old X11 Toolkit, and the Xaw widget library that is built atop it.  (It's part of the X11 source tree, since most of the basic X11 utilities and xterm are based on it.)  It implements a primitive object system in C.  Gtk+ does the same, but hides much of the implementation behind macros and relies on tricky casting etc. behind the scenes for performance; in Xt, the basic machinery is more easily visible for inspection and much easier to understand even if you're not all that familiar with C.  If you go this way, once you've figured out what Xt is doing you might go on to see the more advanced concepts in how Gtk+ does it.

And once you've done this, you'll have a good idea of what Objective-C and C++ (minus templates) are doing under the covers.  (Mostly C++, since ObjC is more or less Smalltalk's OO on top of X, whereas the core concepts of C++ are not so very different from what Xt does.)  If you really want to dig in further, you might want to try to find the source to cfront, the original C++ implementation which was a preprocessor for the C compiler.  It'll be missing a lot of modern C++ features, but the core is there.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Thomas | 4 Jan 13:27 2013
Picon

Re: Object Oriented programming for Functional Programmers

On Sun, Dec 30, 2012 at 1:27 PM, Brandon Allbery <allbery.b <at> gmail.com> wrote:

[T]he "Monad m =>" in the signature really means "hey, compiler, pass me the appropriate implementation of Monad so I can figure out what I'm doing with this type m".  It's not a built in table, it's a hidden parameter.


Well, "hidden" - it *is* right there in the type signature still, it just doesn't *look* like an argument.

It also might be optimized away in static cases (certainly, it *could* happen, whether does or is even worthwhile is another question).
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Kim-Ee Yeoh | 4 Jan 13:51 2013

Re: Object Oriented programming for Functional Programmers

On Fri, Jan 4, 2013 at 7:27 PM, David Thomas <davidleothomas <at> gmail.com> wrote:
Well, "hidden" - it *is* right there in the type signature still, it just doesn't *look* like an argument.

If you squint hard enough, (=>) looks like (->). Or maybe the other way round. Whatever. :)
 
It also might be optimized away in static cases (certainly, it *could* happen, whether does or is even worthwhile is another question).

The optimization at stake is specialization. Given (Num a => a), specialize it to Int or Double  or X so that it's memoizably first-class, which is where functions still fall down [1]. All functions are values but data values still play nicer than others.

Isn't fixing this the real cure for the monomorphism restriction?


-- Kim-Ee

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Rustom Mody | 31 Dec 03:00 2012
Picon

Re: Object Oriented programming for Functional Programmers



On Mon, Dec 31, 2012 at 1:28 AM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:
Hello, Haskell Cafe folks.

My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though.

But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.

But, why I am writing this to you, haskellers?

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?


Ive been collecting material regarding (confusions around) OO.  Its far from complete but the references may be useful, eg
 - the Rees list on the different things that OO means to different people
 - the fundamental philosophical differences between commitment to declarativeness and imperativeness -- in philosophical language rationalism and empiricism
 
As I said, its still in the early stage of bits and pieces being collected...
http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-2.html

* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".


In the C++ world Stepanov is almost on par with Stroupstrup.  His STL has transformed C++ practices more than anything else
Good to read his views on OOP
http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP



--
http://www.the-magus.in
http://blog.languager.org

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Rustom Mody | 31 Dec 03:11 2012
Picon

Re: Object Oriented programming for Functional Programmers



On Mon, Dec 31, 2012 at 7:30 AM, Rustom Mody <rustompmody <at> gmail.com> wrote:


Ive been collecting material regarding (confusions around) OO.  Its far from complete but the references may be useful, eg
 - the Rees list on the different things that OO means to different people
 - the fundamental philosophical differences between commitment to declarativeness and imperativeness -- in philosophical language rationalism and empiricism
 
As I said, its still in the early stage of bits and pieces being collected...
http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-2.html

* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".


In the C++ world Stepanov is almost on par with Stroupstrup.  His STL has transformed C++ practices more than anything else
Good to read his views on OOP
http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP


Just realized that the resultant anti-OOP direction of my earlier mail is stronger than is good for a young computer scientist.
In a field like ours its as important to be able to wear a technical/mathematical hat as a social or political one.
And when the latter, its good to be able to participate in a discussion in which inheritance, UML etc etc figures.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Kim-Ee Yeoh | 31 Dec 05:23 2012

Re: Object Oriented programming for Functional Programmers

There's OOHaskell, which you can google for. The name's such a nice example of an aptronym: it's the Overlooked Object-oriented Haskell.


-- Kim-Ee


On Mon, Dec 31, 2012 at 2:58 AM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:
Hello, Haskell Cafe folks.

My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though.

But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.

But, why I am writing this to you, haskellers?

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

* Will I learn new programming strategies that I can use back in the Haskell world?

Thanks in advance for your kind responses,
Daniel Díaz.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Heinrich Apfelmus | 31 Dec 11:11 2012
Picon

Re: Object Oriented programming for Functional Programmers

Daniel Díaz Casanueva wrote:
> Hello, Haskell Cafe folks.
> 
> My programming life (which has started about 3-4 years ago) has always been
> in the functional paradigm. Eventually, I had to program in Pascal and
> Prolog for my University (where I learned Haskell). I also did some PHP,
> SQL and HTML while building some web sites, languages that I taught to
> myself. I have never had any contact with JavaScript though.
> 
> But all these languages were in my life as secondary languages, being
> Haskell my predominant preference. Haskell was the first programming
> language I learned, and subsequent languages never seemed so natural and
> worthwhile to me. In fact, every time I had to use another language, I
> created a combinator library in Haskell to write it (this was the reason
> that brought me to start with the HaTeX library). Of course, this practice
> wasn't always the best approach.
> 
> But, why I am writing this to you, haskellers?
> 
> Well, my curiosity is bringing me to learn a new general purpose
> programming language. Haskellers are frequently comparing Object-Oriented
> languages with Haskell itself, but I have never programmed in any
> OO-language! (perhaps this is an uncommon case) I thought it could be good
> to me (as a programmer) to learn C/C++. Many interesting courses (most of
> them) use these languages and I feel like limited for being a Haskell
> programmer. It looks like I have to learn imperative programming (with side
> effects all over around) in some point of my programming life.
> 
> So my questions for you all are:
> 
> * Is it really worthwhile for me to learn OO-programming?
> 
> * If so, where should I start? There are plenty of "functional programming
> for OO programmers" but I have never seen "OO programming for functional
> programmers".
> 
> * Is it true that learning other programming languages leads to a better
> use of your favorite programming language?
> 
> * Will I learn new programming strategies that I can use back in the
> Haskell world?

Personally, I don't think that learning an imperative OO language will 
"expand your mind" in a way that Haskell does. I have started with 
Pascal and later C, but once I learned about Haskell, I switched to it 
immediately for virtually all my programming tasks and never looked back.

The only thing that OO languages are good for are "legacy" systems, 
where no Haskell compiler is readily available. If you have a concrete 
project in mind, like an Android or iPhone app, or a client-heavy web 
application, it is certainly worthwhile to learn the relevant language 
(Java, Objective-C, JavaScript) in order to make your ideas a reality. 
But other than that, you already know Pascal and programming in these 
languages is not very different.

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Strake | 31 Dec 14:46 2012
Picon

Re: Object Oriented programming for Functional Programmers

Disclaimer: My own experience with OO is limited.

On 30/12/2012, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:
> My programming life (which has started about 3-4 years ago) has always been
> in the functional paradigm. Eventually, I had to program in Pascal and
> Prolog for my University (where I learned Haskell). I also did some PHP,
> SQL and HTML while building some web sites, languages that I taught to
> myself. I have never had any contact with JavaScript though.
>
> ...
>
> I thought it could be good to me (as a programmer) to learn C/C++.
> It looks like I have to learn imperative programming (with side effects all over around) in some point of my
programming life.

Have to, no. Ought to, yes. As Turing-equivalent computers are
essentially imperative, imperative code is nearest to the actions of
the machine. Ergo asm may seem the best choice, but not so: C is the
wiser choice, as it is machine-agnostic, widely used, and often clear
and effective.

I never used pascal, and after I read this:
http://www.lysator.liu.se/c/bwk-on-pascal.html
I care not to do.

> So my questions for you all are:
>
> * Is it really worthwhile for me to learn OO-programming?

Likely. Some code is most readily written in objective style.

> * If so, where should I start? There are plenty of "functional programming
> for OO programmers" but I have never seen "OO programming for functional
> programmers".

Smalltalk.

> * Is it true that learning other programming languages leads to a better
> use of your favorite programming language?

Yes. Either one gains an awareness of certain biases and assumptions
made while using prior languages, or else the new language becomes
one's favorite (^_~)

> * Will I learn new programming strategies that I can use back in the
> Haskell world?

Maybe. I honestly can't say a priori, but it's a win to know the
alternatives. I have done some OO, and a few times while writing in
Haskell, the objective model came to mind first, tho in many cases it
is cumbersome in Haskell.

Cheers,
Strake

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mike Meyer | 31 Dec 15:33 2012

Re: Object Oriented programming for Functional Programmers

On Mon, Dec 31, 2012 at 7:46 AM, Strake <strake888 <at> gmail.com> wrote:
> Disclaimer: My own experience with OO is limited.

Mine isn't quite so much...

> On 30/12/2012, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:
>> My programming life (which has started about 3-4 years ago) has always been
>> in the functional paradigm. Eventually, I had to program in Pascal and
>> Prolog for my University (where I learned Haskell). I also did some PHP,
>> SQL and HTML while building some web sites, languages that I taught to
>> myself. I have never had any contact with JavaScript though.
>>
>> ...
>>
>> I thought it could be good to me (as a programmer) to learn C/C++.
>> It looks like I have to learn imperative programming (with side effects all over around) in some point of
my programming life.
>> So my questions for you all are:
>>
>> * Is it really worthwhile for me to learn OO-programming?
> Likely. Some code is most readily written in objective style.

Learning a new paradigm is almost always a good idea. It gives you a
new set of tools for approaching programming problems. Of course, the
single worst thing you can do is try and force a paradigm onto a
language that isn't meant for it.

>> * If so, where should I start? There are plenty of "functional programming
>> for OO programmers" but I have never seen "OO programming for functional
>> programmers".
> Smalltalk.

That's a good functional start. Personally, I'd go with Eiffel,
because it means you can use Meyer's (no relation) Object Oriented
Software Construction as a text. Unfortunately, you'll have to buy a
dead trees copy of that text. It not only covers OO programming, but
explains why things are the way they are, why the way C++ is is wrong,
and provides an introduction to design-by-contract as well.

    <mike
Bob Hutchison | 31 Dec 18:13 2012
Picon

Re: Object Oriented programming for Functional Programmers

On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.

As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages.

I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.

C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-)

Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes.


* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

That's been my experience. And it'll be harder to name your favourite language too.


* Will I learn new programming strategies that I can use back in the Haskell world?

Probably.

Cheers,
Bob


Thanks in advance for your kind responses,
Daniel Díaz.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Rico Moorman | 31 Dec 22:26 2012
Picon

Re: Object Oriented programming for Functional Programmers

Hello Bob and Mike,


Reading a little within the suggested book I came across the following statement.

We should first examine the merits and limitations of the traditional approach: using
functions as a basis for the architecture of software systems. This will not only lead us to
appreciate why we need something else — object technology — but also help us avoid,
when we do move into the object world, certain methodological pitfalls such as premature
operation ordering, which have been known to fool even experienced O-O developers.

Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author?

Thank you very much in advance.

Best regards,

Rico Moorman

On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison <hutch-lists <at> recursive.ca> wrote:
On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.

As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages.

I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.

C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-)

Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes.



* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

That's been my experience. And it'll be harder to name your favourite language too.



* Will I learn new programming strategies that I can use back in the Haskell world?

Probably.

Cheers,
Bob


Thanks in advance for your kind responses,
Daniel Díaz.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Brandon Allbery | 31 Dec 22:46 2012
Picon

Re: Object Oriented programming for Functional Programmers

On Mon, Dec 31, 2012 at 4:26 PM, Rico Moorman <rico.moorman <at> gmail.com> wrote:
We should first examine the merits and limitations of the traditional approach: using
functions as a basis for the architecture of software systems. This will not only lead us to
 
Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author?

"Procedures".  They're coming at it from the standpoint of C / Algol / Pascal, where "functions" are more or less your only real way to organize code; not talking about functional programming.
 
--
brandon s allbery kf8nh                               sine nomine associates
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bob Hutchison | 1 Jan 17:53 2013
Picon

Re: Object Oriented programming for Functional Programmers


On 2012-12-31, at 4:26 PM, Rico Moorman <rico.moorman <at> gmail.com> wrote:

Hello Bob and Mike,

Reading a little within the suggested book I came across the following statement.

We should first examine the merits and limitations of the traditional approach: using
functions as a basis for the architecture of software systems. This will not only lead us to
appreciate why we need something else — object technology — but also help us avoid,
when we do move into the object world, certain methodological pitfalls such as premature
operation ordering, which have been known to fool even experienced O-O developers.

Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author?

He is talking about functions/procedures as in C, Pascal, Algol… structured programming basically. The first edition was written in 1988, the second about 10 years later. However, today, I *think* he might include functions as found in modern functional languages in this, and as you read on in the book you'll see why I say this. I've been considering re-reading OOSC2 for a while now (it is, believe it or not, a fun book… well, maybe that's just me) and keep Haskell and ML in mind while reading it. Meyer is trying to thoroughly explain the reasoning behind OO in this book, it isn't really a critique of anything especially (except indirectly other OO languages). Meyer can be scathing but you'll have to look elsewhere for the best/worst/most fun of that. Haskell, as it matures, is going to have to have an answer for everything in this book (answers may include 'pass' as Meyer does with Eiffel on a few issues–there's no shame in admitting Haskell, or anything else, doesn't have all the answers)… he's talking about issues that are independent of programming language.

Cheers,
Bob


Thank you very much in advance.

Best regards,

Rico Moorman

On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison <hutch-lists <at> recursive.ca> wrote:
On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.

As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages.

I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.

C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-)

Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes.



* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

That's been my experience. And it'll be harder to name your favourite language too.



* Will I learn new programming strategies that I can use back in the Haskell world?

Probably.

Cheers,
Bob


Thanks in advance for your kind responses,
Daniel Díaz.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Никитин Лев | 1 Jan 19:23 2013
Picon

Re: Object Oriented programming for Functional Programmers

Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP.
 
01.01.2013, 23:56, "Bob Hutchison" <hutch-lists <at> recursive.ca>:

On 2012-12-31, at 4:26 PM, Rico Moorman <rico.moorman <at> gmail.com> wrote:

Hello Bob and Mike,
 
Reading a little within the suggested book I came across the following statement.
 
We should first examine the merits and limitations of the traditional approach: using
functions as a basis for the architecture of software systems. This will not only lead us to
appreciate why we need something else — object technology — but also help us avoid,
when we do move into the object world, certain methodological pitfalls such as premature
operation ordering, which have been known to fool even experienced O-O developers.
 
Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author?
 
He is talking about functions/procedures as in C, Pascal, Algol… structured programming basically. The first edition was written in 1988, the second about 10 years later. However, today, I *think* he might include functions as found in modern functional languages in this, and as you read on in the book you'll see why I say this. I've been considering re-reading OOSC2 for a while now (it is, believe it or not, a fun book… well, maybe that's just me) and keep Haskell and ML in mind while reading it. Meyer is trying to thoroughly explain the reasoning behind OO in this book, it isn't really a critique of anything especially (except indirectly other OO languages). Meyer can be scathing but you'll have to look elsewhere for the best/worst/most fun of that. Haskell, as it matures, is going to have to have an answer for everything in this book (answers may include 'pass' as Meyer does with Eiffel on a few issues–there's no shame in admitting Haskell, or anything else, doesn't have all the answers)… he's talking about issues that are independent of programming language.
 
Cheers,
Bob

 
Thank you very much in advance.
 
Best regards,
 
Rico Moorman

On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison <hutch-lists <at> recursive.ca> wrote:
On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?
Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.

As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages.

I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.

C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-)

Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes.



* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?
That's been my experience. And it'll be harder to name your favourite language too.



* Will I learn new programming strategies that I can use back in the Haskell world?
Probably.

Cheers,
Bob


Thanks in advance for your kind responses,
Daniel Díaz.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

,

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 1 Jan 19:49 2013
Picon

Re: Object Oriented programming for Functional Programmers


On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru> wrote:

> Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP.

Really? Because when I studied it I had a very different impression: that behind this language there was no
theory at all. And it's only feature I remember that is not present in mainstream languages is it's
pre/postconditions system, which looked like an ugly hack for me.

Of course, my memory could fail me, but I doubt my tutorial did; I remember it being written by Meyer himself.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mike Meyer | 1 Jan 20:41 2013

Re: Object Oriented programming for Functional Programmers


MigMit <miguelimo38 <at> yandex.ru> wrote:
>On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru>
>wrote:
>> Eiffel, for my opinion, is a best OOP language. Meyer use a
>theoretical approach as it is possible in OOP.
>Really? Because when I studied it I had a very different impression:
>that behind this language there was no theory at all. And it's only
>feature I remember that is not present in mainstream languages is it's
>pre/postconditions system, which looked like an ugly hack for me.

I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to
"mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to
something like Scheme, Haskell or even Clojure, maybe not so much.

On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is
"Design by Contract". The contracts are as important as the type signature, and show up in the
auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not
sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as
in the code.

--

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 1 Jan 21:47 2013
Picon

Re: Object Oriented programming for Functional Programmers

Well, probably one of the reasons is that I've learned Eiffel later than Haskell.

But really, "Design by Contract" — a theory? It certainly is a useful approach, but it doesn't seem to be a
theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in
this direction.

And by "hack" I meant not the presence of pre/postconditions, but the fact that they don't affect anything
else. Strip all of them away, and you'll have the program which is, essentially, the same (and, in fact,
pre/postconditions are supposed to be removed in the final version of the program). Compare this to
Haskell types, for example: an untyped version of Haskell won't be able to choose between two class
instances, so, that would be an entirely different language.

On Jan 1, 2013, at 11:41 PM, Mike Meyer <mwm <at> mired.org> wrote:

> 
> 
> MigMit <miguelimo38 <at> yandex.ru> wrote:
>> On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru>
>> wrote:
>>> Eiffel, for my opinion, is a best OOP language. Meyer use a
>> theoretical approach as it is possible in OOP.
>> Really? Because when I studied it I had a very different impression:
>> that behind this language there was no theory at all. And it's only
>> feature I remember that is not present in mainstream languages is it's
>> pre/postconditions system, which looked like an ugly hack for me.
> 
> I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to
"mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to
something like Scheme, Haskell or even Clojure, maybe not so much.
> 
> On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions
is "Design by Contract". The contracts are as important as the type signature, and show up in the
auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not
sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as
in the code.
> 
> 
> -- 
> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bob Hutchison | 1 Jan 23:26 2013
Picon

Re: Object Oriented programming for Functional Programmers


On 2013-01-01, at 3:47 PM, MigMit <miguelimo38 <at> yandex.ru> wrote:

> Well, probably one of the reasons is that I've learned Eiffel later than Haskell.
> 
> But really, "Design by Contract" — a theory? It certainly is a useful approach, but it doesn't seem to be a
theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in
this direction.

Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not
the same thing.

And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory.

> 
> And by "hack" I meant not the presence of pre/postconditions, but the fact that they don't affect anything
else. Strip all of them away, and you'll have the program which is, essentially, the same (and, in fact,
pre/postconditions are supposed to be removed in the final version of the program).

> Compare this to Haskell types, for example: an untyped version of Haskell won't be able to choose between
two class instances, so, that would be an entirely different language.

So, I think, you're saying take away the contracts and the outcome of compilation won't be any different.
Whereas take away the types and Haskell is stopped cold. And that difference makes contracts a 'hack' but
types not a 'hack'?

Seems to me you're ignoring everything that happens between an empty directory and a working program.
Contracts help in that process (I say but can't prove). Call that a 'hack' if you want, but I'll take as many
of those kinds of hacks as I can get if they're anywhere near as good as contracts.

Pre and post conditions with class invariants are neither types nor unit test, something in between. With
the wonderful properties of 'useful' and 'executable'.

Sometimes you just have to settle for the hacks.

Cheers,
Bob

> 
> On Jan 1, 2013, at 11:41 PM, Mike Meyer <mwm <at> mired.org> wrote:
> 
>> 
>> 
>> MigMit <miguelimo38 <at> yandex.ru> wrote:
>>> On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru>
>>> wrote:
>>>> Eiffel, for my opinion, is a best OOP language. Meyer use a
>>> theoretical approach as it is possible in OOP.
>>> Really? Because when I studied it I had a very different impression:
>>> that behind this language there was no theory at all. And it's only
>>> feature I remember that is not present in mainstream languages is it's
>>> pre/postconditions system, which looked like an ugly hack for me.
>> 
>> I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to
"mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to
something like Scheme, Haskell or even Clojure, maybe not so much.
>> 
>> On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions
is "Design by Contract". The contracts are as important as the type signature, and show up in the
auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not
sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as
in the code.
>> 
>> 
>> -- 
>> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 2 Jan 10:41 2013
Picon

Re: Object Oriented programming for Functional Programmers


On Jan 2, 2013, at 2:26 AM, Bob Hutchison <hutch-lists <at> recursive.ca> wrote:

> 
> On 2013-01-01, at 3:47 PM, MigMit <miguelimo38 <at> yandex.ru> wrote:
> 
>> Well, probably one of the reasons is that I've learned Eiffel later than Haskell.
>> 
>> But really, "Design by Contract" — a theory? It certainly is a useful approach, but it doesn't seem to be
a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in
this direction.
> 
> Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not
the same thing.

Well, we were talking about Eiffel. OOSC2 deserves a few unkind words as well, but I won't go there.

> 
> And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory.

I don't know about DbC in general, but it's implementation in Eiffel seems to be nothing more than a few
ASSERT macros, for some weird reason embedded into the language.

> So, I think, you're saying take away the contracts and the outcome of compilation won't be any different.
Whereas take away the types and Haskell is stopped cold. And that difference makes contracts a 'hack' but
types not a 'hack'?

I wasn't clear enough, sorry. I'm sure it's due to sleep deprivation. Or coffee deprivation.

See, there are two parts of Eiffel, as I see it. First one is the "contracts" part. Second is… well,
everything else. Second part seems to be doing all the "real" job, while the first one is doing something
invisible, something that leaves no trace in the final result. Which doesn't mean it's unimportant, of
course. The contracts part is designed to help the other part do it's job, but not to do the job by itself.
Now, there are two problems with that:

1) The "real job" part needs helping. And a lot of it, actually, one doesn't need to look very closely to see
that Eiffel type system is extremely unsafe (for the statically type language).

2) The "contracts" part does a very poor job. Instead of really improving the inherent unsafety, it resorts
to testing. And...

2') ...not even the real, thorough testing — contracts system would be quite happy if the program works on
the developer's machine. Which is the "works for me" approach certain languages gets rightfully blamed for.

> Seems to me you're ignoring everything that happens between an empty directory and a working program.
Contracts help in that process (I say but can't prove).

I agree. They do help — but there are lots of things that help in this transition. Versioning systems.
Collaboration tools. Bug tracking software. Text editors. Even debuggers.

> Pre and post conditions with class invariants are neither types nor unit test, something in between. With
the wonderful properties of 'useful' and 'executable'.
> 
> Sometimes you just have to settle for the hacks.
> 
> Cheers,
> Bob
> 
>> 
>> On Jan 1, 2013, at 11:41 PM, Mike Meyer <mwm <at> mired.org> wrote:
>> 
>>> 
>>> 
>>> MigMit <miguelimo38 <at> yandex.ru> wrote:
>>>> On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru>
>>>> wrote:
>>>>> Eiffel, for my opinion, is a best OOP language. Meyer use a
>>>> theoretical approach as it is possible in OOP.
>>>> Really? Because when I studied it I had a very different impression:
>>>> that behind this language there was no theory at all. And it's only
>>>> feature I remember that is not present in mainstream languages is it's
>>>> pre/postconditions system, which looked like an ugly hack for me.
>>> 
>>> I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to
"mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to
something like Scheme, Haskell or even Clojure, maybe not so much.
>>> 
>>> On the other hand, one persons theory is another persons hack. The theory behind the pre/post
conditions is "Design by Contract". The contracts are as important as the type signature, and show up in
the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm
not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post
conditions as in the code.
>>> 
>>> 
>>> -- 
>>> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bob Hutchison | 2 Jan 13:56 2013
Picon

Re: Object Oriented programming for Functional Programmers


On 2013-01-02, at 4:41 AM, MigMit <miguelimo38 <at> yandex.ru> wrote:

> 
> On Jan 2, 2013, at 2:26 AM, Bob Hutchison <hutch-lists <at> recursive.ca> wrote:
> 
>> 
>> On 2013-01-01, at 3:47 PM, MigMit <miguelimo38 <at> yandex.ru> wrote:
>> 
>>> Well, probably one of the reasons is that I've learned Eiffel later than Haskell.
>>> 
>>> But really, "Design by Contract" — a theory? It certainly is a useful approach, but it doesn't seem to
be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything
in this direction.
>> 
>> Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not
the same thing.
> 
> Well, we were talking about Eiffel. OOSC2 deserves a few unkind words as well, but I won't go there.
> 
>> 
>> And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory.
> 
> I don't know about DbC in general, but it's implementation in Eiffel seems to be nothing more than a few
ASSERT macros, for some weird reason embedded into the language.

Hmm. I must disagree with you here. I've used three Eiffel systems, ISE, Small/SmartEiffel, and Tower.
They all implemented DbC pretty thoroughly. In my opinion, every other implementation of DbC pale in
comparison, to the point where they're hardly DbC at all. Are we talking about the same thing?

There are three major components (in my opinion) to DbC: pre and post conditions, and class invariants. Pre
and post conditions and invariants cannot be implemented simply as asserts. I'll have to refer you to
OOSC2 for the (many) details, but a few of the more interesting aspects of these constructs are:

1) error reporting. If a precondition is violated the caller is flagged as the source of the error and error
messages, stack traces, etc all reflect the caller. If a post condition is violated it's the callee who is
responsible. And the error reports generated are rather good.

2) pre&post conditions and class invariants have defined behaviour in cases of inheritance,
even/especially multiple inheritance. They are combined non-trivially in subclasses. Without this I
don't think you have DbC.

3) invariants are not checked for calls within a class (self.method does not have them checked,
other.method does)

4) You have access to all the parameters for pre&post conditions, and results for post conditions. Access
to the initial state of the object is supposed to be there but I don't think all implementations support that.

That's only a brief summary, it goes further than that, again I refer you to OOSC2 (and any of the Eiffel
implementations I mentioned, and I don't know of any other implementations). This is nothing like a few
assert macros.

> 
>> So, I think, you're saying take away the contracts and the outcome of compilation won't be any different.
Whereas take away the types and Haskell is stopped cold. And that difference makes contracts a 'hack' but
types not a 'hack'?
> 
> I wasn't clear enough, sorry. I'm sure it's due to sleep deprivation. Or coffee deprivation.
> 
> See, there are two parts of Eiffel, as I see it. First one is the "contracts" part. Second is… well,
everything else. Second part seems to be doing all the "real" job, while the first one is doing something
invisible, something that leaves no trace in the final result. Which doesn't mean it's unimportant, of
course. The contracts part is designed to help the other part do it's job, but not to do the job by itself.
Now, there are two problems with that:
> 
> 1) The "real job" part needs helping. And a lot of it, actually, one doesn't need to look very closely to see
that Eiffel type system is extremely unsafe (for the statically type language).

Feel free to enlighten me about these obvious and extremely unsafe aspects of Eiffel's type system.
Personally, I can't say I ever noticed.

> 
> 2) The "contracts" part does a very poor job. Instead of really improving the inherent unsafety, it
resorts to testing. And…

What constitutes a 'good' job? 'Resorts' to testing. I have to admit to resorting to testing on occasion
myself. Frequent occasion. Routinely even. :-)

> 
> 2') ...not even the real, thorough testing — contracts system would be quite happy if the program works
on the developer's machine. Which is the "works for me" approach certain languages gets rightfully
blamed for.

Really? You believe that automated testing and contracts are why software bugs *are not* found?

> 
>> Seems to me you're ignoring everything that happens between an empty directory and a working program.
Contracts help in that process (I say but can't prove).
> 
> I agree. They do help — but there are lots of things that help in this transition. Versioning systems.
Collaboration tools. Bug tracking software. Text editors. Even debuggers.

You should read OOSC2. You'll find that this is completely consistent with it. Don't forget that the 'C' in
OOSC2 is 'contraction'.

Cheers,
Bob

> 
>> Pre and post conditions with class invariants are neither types nor unit test, something in between.
With the wonderful properties of 'useful' and 'executable'.
>> 
>> Sometimes you just have to settle for the hacks.
>> 
>> Cheers,
>> Bob
>> 
>>> 
>>> On Jan 1, 2013, at 11:41 PM, Mike Meyer <mwm <at> mired.org> wrote:
>>> 
>>>> 
>>>> 
>>>> MigMit <miguelimo38 <at> yandex.ru> wrote:
>>>>> On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru>
>>>>> wrote:
>>>>>> Eiffel, for my opinion, is a best OOP language. Meyer use a
>>>>> theoretical approach as it is possible in OOP.
>>>>> Really? Because when I studied it I had a very different impression:
>>>>> that behind this language there was no theory at all. And it's only
>>>>> feature I remember that is not present in mainstream languages is it's
>>>>> pre/postconditions system, which looked like an ugly hack for me.
>>>> 
>>>> I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to
"mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to
something like Scheme, Haskell or even Clojure, maybe not so much.
>>>> 
>>>> On the other hand, one persons theory is another persons hack. The theory behind the pre/post
conditions is "Design by Contract". The contracts are as important as the type signature, and show up in
the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm
not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post
conditions as in the code.
>>>> 
>>>> 
>>>> -- 
>>>> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
>>> 
>>> 
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> 
> 

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bob Hutchison | 2 Jan 15:01 2013
Picon

Re: Object Oriented programming for Functional Programmers


On 2013-01-02, at 7:56 AM, Bob Hutchison <hutch-lists <at> recursive.ca> wrote:

> 
> You should read OOSC2. You'll find that this is completely consistent with it. Don't forget that the 'C' in
OOSC2 is 'contraction'.

'Construction' of course… the automated spell checker is not my friend :-(
MigMit | 2 Jan 22:38 2013
Picon

Re: Object Oriented programming for Functional Programmers

> 2) pre&post conditions and class invariants have defined behaviour in cases of inheritance,
even/especially multiple inheritance. They are combined non-trivially in subclasses. Without this I
don't think you have DbC.

Yes, I forgot about that. Thanks.

> Feel free to enlighten me about these obvious and extremely unsafe aspects of Eiffel's type system.
Personally, I can't say I ever noticed.

Correct me if I'm wrong, but isn't it true that methods can be removed in subclasses? If that's not extreme, I
don't know what is.

>> 2) The "contracts" part does a very poor job. Instead of really improving the inherent unsafety, it
resorts to testing. And…
> 
> What constitutes a 'good' job?

Well, a sound type system would certainly help.

> 'Resorts' to testing. I have to admit to resorting to testing on occasion myself. Frequent occasion.
Routinely even. :-)

You routinely try to overcome language weakness with tests?

>> 2') ...not even the real, thorough testing — contracts system would be quite happy if the program works
on the developer's machine. Which is the "works for me" approach certain languages gets rightfully
blamed for.
> 
> Really? You believe that automated testing and contracts are why software bugs *are not* found?

Is that what I said?

I believe that testing means a lot more than just making sure the program works on the developer's computer.
I believe that system that encourages the "works for me" approach is one of the reasons software bugs are
not found.

>>> Seems to me you're ignoring everything that happens between an empty directory and a working program.
Contracts help in that process (I say but can't prove).
>> 
>> I agree. They do help — but there are lots of things that help in this transition. Versioning systems.
Collaboration tools. Bug tracking software. Text editors. Even debuggers.
> 
> You should read OOSC2. You'll find that this is completely consistent with it.

I've never said it's not. But all of these tools are external to the language, which means that they can be
easily replaced if a better alternative surfaces.
Mike Meyer | 2 Jan 07:52 2013

Re: Object Oriented programming for Functional Programmers


[Context destroyed by top posting.]
MigMit <miguelimo38 <at> yandex.ru> wrote:
>But really, "Design by Contract" — a theory? It certainly is a useful
>approach, but it doesn't seem to be a theory, not until we can actually
>prove something about it, and Eiffel doesn't seem to offer anything in
>this direction.

You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note
that it's a theory about *programming*, not the resulting program.

>And by "hack" I meant not the presence of pre/postconditions, but the
>fact that they don't affect anything else. Strip all of them away, and
>you'll have the program which is, essentially, the same (and, in fact,
>pre/postconditions are supposed to be removed in the final version of
>the program). Compare this to Haskell types, for example: an untyped
>version of Haskell won't be able to choose between two class instances,
>so, that would be an entirely different language.

Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type signatures
a hack to get around deficiencies in the type inferencing engine? After all, you can strip all of them away
and have essentially the same program.

Personally, I think the answer is "no", and for the same reason. We add type signatures to top level
functions because it helps document the function, and to help isolate type errors during compilation.
They makes *programming* easier, even if they don't change the program at all. Pre and Post conditions
(and class invariants - they're also part of DbC!) serve pretty much the same function. They help document
the classes and methods, and tools that generate class/method documentation from source always include
them. They're as important as the type signature. They also help isolate bugs, in that you get told
explicitly that routine foo passed in an invalid parameter to bar rather than an exception somewhere deep
in the guts of bar that you have to work back from to find foo.

As I said before, I'm not sure I agree that the latter is worth the cost of using them for anything complex. The
bugs they uncover are as likely to be in the pre/post conditions as in the code proper.  The documentation
benefit is unquestionable, though. And if some condition is worth documenting, then having it as
executable documentation means it gets tested with the rest of the code, so you know the documentation is
correct. Which means that just adding conditions to a language misses most of the benefit of DbC. You need
to fix the documentation system as well.

This is the kind of theory that you'll find in OOSC: why the features that are there help make programming
easier. Not theories about how they make the resulting program better. Those two have a lot in common,
though. Anything that makes witing correct code easier generally results in a better program.
--

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 2 Jan 10:48 2013
Picon

Re: Object Oriented programming for Functional Programmers


On Jan 2, 2013, at 10:52 AM, Mike Meyer <mwm <at> mired.org> wrote:

> 
> 
> [Context destroyed by top posting.]
> MigMit <miguelimo38 <at> yandex.ru> wrote:
>> But really, "Design by Contract" — a theory? It certainly is a useful
>> approach, but it doesn't seem to be a theory, not until we can actually
>> prove something about it, and Eiffel doesn't seem to offer anything in
>> this direction.
> 
> You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing.
Note that it's a theory about *programming*, not the resulting program.

Well, you can call that a theory, for sure. But I think it's usually called an "observation". I always
thought the theory is something that allows us to develop some new knowledge. Just stating that
"comfortable chairs make programmers more productive" doesn't constitute a theory.

> Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type
signatures a hack to get around deficiencies in the type inferencing engine? After all, you can strip all
of them away and have essentially the same program.

I've tried to clarify my position in my response to Bob Hutchison.
Mike Meyer | 2 Jan 12:28 2013
Face

Re: Object Oriented programming for Functional Programmers

On Wed, 2 Jan 2013 13:48:07 +0400
MigMit <miguelimo38 <at> yandex.ru> wrote:
> On Jan 2, 2013, at 10:52 AM, Mike Meyer <mwm <at> mired.org> wrote:
> > MigMit <miguelimo38 <at> yandex.ru> wrote:
> >> But really, "Design by Contract" — a theory? It certainly is a useful
> >> approach, but it doesn't seem to be a theory, not until we can actually
> >> prove something about it, and Eiffel doesn't seem to offer anything in
> >> this direction.
> > You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing.
Note that it's a theory about *programming*, not the resulting program.
> Well, you can call that a theory, for sure. But I think it's usually called an "observation".

An "observation" is what you make to decide if a theory is true or
not. In order to make the observation (at least for theories about
helping programmers) you need an implementation so you can observe
people using it.

> I always thought the theory is something that allows us to develop
> some new knowledge.

Yup. Deciding whether or not the theory is true *is* a development of
new knowledge. I can say for a certainty that the documentation aspect
of DbC makes me more productive. The testing aspect of it needs more
testing (sorry).

> Just stating that "comfortable chairs make programmers more
> productive" doesn't constitute a theory.

Well, it's not very rigorous, and I can think of some
counterexamples. On the other hand, if you reparaphrased (sic) it as
"Chairs that encourage good posture make programmers more productive",
then you have a honest-to-goodness theory. Better yet, it's one that's
been thoroughly tested in ergonomics labs around the world.

At this point, we're arguing about the semantics of the word
"theory".

On Wed, 2 Jan 2013 13:41:54 +0400
MigMit <miguelimo38 <at> yandex.ru> wrote:
> I don't know about DbC in general, but it's implementation in Eiffel
> seems to be nothing more than a few ASSERT macros, for some weird
> reason embedded into the language.

Either you used a particularly poor implementation of Eiffel, or you
didn't look at the implementation beyond writing them out. Every
Eiffel system I've used included tools that computed the contracts on
a method or class (remember, class invariants apply to subclasses,
etc.) and displayed them. Those are just as much part of DbC as the
"assert macros".

If you ignore that usage, you've correctly described things. At least
as well as saying that a function call implementation is a goto that
records a return address, for some weird reason embedded into the
language. Or <higher level construct> is just <implementation method>,
for some weird reason embedded into the language.

The "weird reason" is pretty much always the same: the construct in
question carries more semantic meaning than the implementation
method. Functions capture the notion of a distinct, reusable chunk of
code, that can have properties all it's own. This is a major step up
from just having a goto variant with an otog that undoes it.

Likewise, pre and post (and invariant) conditions capture the notion
of a contract. They express the terms of the contract implemented by
some specific bit of code. The contract is part of the interface to
that code. If you're actually doing DbC, it's no less important than
the rest of the interface. Like, for instance, the type signature.

Personally, I don't believe in turning off the conditions, for much
the same reason I don't believe in turning off array bounds
checking. I think it's better to get the right answer later than to
get the wrong answer now.

   <mike
--

-- 
Mike Meyer <mwm <at> mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Никитин Лев | 2 Jan 13:24 2013
Picon

Re: Object Oriented programming for Functional Programmers

 
Well, we can say "concepts" in place of "theory".  And I'm comparing Eiffel with other OOP lang, not with some langs based on a solid math theory (lambda calcules for FP langs, for example). ok?
 
DbC is not the same as "assert macros". First, it has a lang semantic. There is an interesting graduated mechanism to turn off or turn on conditions' checking.
 
Dbc is not only initeresting "concept" of lang. Meyer is considering class as a type in his type system. By the way, preconditions and postconditions of class and its subclass have to be consistient. I don't remeber all details now, as I remeber preconditions of subclass are automaticly logically 'and'ed to preconditions of superclass. This supports "concept" of "class is type" and "subclass is a same type as superclass".
 
Other "concept" - classes are only modules.
 
Other "concept" - "command/query separation" = dividing functions on functions that change state of object and on functions that query some info from function (sic. pure functions!).
 
Other "concept" - polymorphic types (general types) - parametrisied types, including constrained parametrisied types (MAP [V, K -> HASHABLE]).
 
Other "concept" - solving multiple inherient problem - "name clashing"
 
And so on.
 
BTW. Why you think that Eiffel type system is unsafe? I don't what is a situation with java type now (not using java for several yeas), but I thought that java type system is more unsafe that eiffel type system. (They said that there were generic types in java). 
And BTW, smalltalk is a lang with dynamic type system.
 
PS. In structuring programming, to prove correctness of loop construction, you have to write down precondition of loop, loop invariant, loop postcondition. You have to (mathamaticly) prove: if precondition holds than invariant holds (and in result we get solved postcondition).
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Никитин Лев | 2 Jan 13:37 2013
Picon

Re: Object Oriented programming for Functional Programmers

Opps... I forgot about Eiffel agents!
 
PS. After participationing in this discussion I'm  tempting to reread Meyer's book after 10 years interval, to have a detailed look at the eiffel from the FP position. When I read this book first I know nothing about FP.
 
 
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 2 Jan 22:29 2013
Picon

Re: Object Oriented programming for Functional Programmers


On Jan 2, 2013, at 4:24 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru> wrote:

>  
> Well, we can say "concepts" in place of "theory".  And I'm comparing Eiffel with other OOP lang, not with
some langs based on a solid math theory (lambda calcules for FP langs, for example). ok?

I agree that there are certain concepts, or ideas, that Eiffel is built on. If that is what you meant, sure, I
have no problem with that.

Of course, there are plenty of languages based on some specific ideas. For example, take the following
concepts: 1) it's better to do something instead of failing, even if it doesn't make any sense; 2) global is
better then local; 3) for every feature that can be implemented in two ways there should be a switch that the
user can set as xe wishes. Implement these as fully as possible — and you'll get PHP.

So, somehow I doubt that being based on some set of ideas is a very strong selling point.

> BTW. Why you think that Eiffel type system is unsafe?

Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you can't
be certain that this object actually has this method. Could be that this object belongs to some subclass
which removes this method.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Gershom Bazerman | 2 Jan 23:09 2013
Picon

Re: Object Oriented programming for Functional Programmers

On 1/2/13 4:29 PM, MigMit wrote:
>
>> BTW. Why you think that Eiffel type system is unsafe?
> Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you
can't be certain that this object actually has this method. Could be that this object belongs to some
subclass which removes this method.
>

Eiffel doesn't handle the relationship of co- and contra-variance of 
arguments with subtyping in a principled way. This is apparently known 
as the "catcall" problem. See, e.g., this article: 
http://www.eiffelroom.org/node/517

--Gershom
MigMit | 2 Jan 23:19 2013
Picon

Re: Object Oriented programming for Functional Programmers


On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gershomb <at> gmail.com> wrote:

> On 1/2/13 4:29 PM, MigMit wrote:
>> 
>>> BTW. Why you think that Eiffel type system is unsafe?
>> Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you
can't be certain that this object actually has this method. Could be that this object belongs to some
subclass which removes this method.
>> 
> 
> Eiffel doesn't handle the relationship of co- and contra-variance of arguments with subtyping in a
principled way. This is apparently known as the "catcall" problem. See, e.g., this article: http://www.eiffelroom.org/node/517

Yes, variance is another big source of unsafety, that's for sure. And another reason I think there is no real
"theory" behind Eiffel, just a bunch of features (or "concepts") boiled together.
Alberto G. Corona | 3 Jan 10:56 2013
Picon

Re: Object Oriented programming for Functional Programmers

Anyway, Type checking is essentially an application of set theory : (I did no search in te literature for this, It is just my perception). When I say   (+) :: Num a => a -> a -> a . I mean that (+) takes two elements of the set of Num typeclass and return another. This is in principle a weak restriction, because many functions do it as well, for example (*).  

A propery check or a contract would be much more restrictive and thus would detect much more program errors. But it seems that no other language but haskell took this set theoretical analysis so exhaustively, and without it, a property check is like detecting microscopic cracks in nuclear waste vessel without first making sure that the cover has been sealed.


2013/1/2 MigMit <miguelimo38 <at> yandex.ru>

On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gershomb <at> gmail.com> wrote:

> On 1/2/13 4:29 PM, MigMit wrote:
>>
>>> BTW. Why you think that Eiffel type system is unsafe?
>> Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you can't be certain that this object actually has this method. Could be that this object belongs to some subclass which removes this method.
>>
>
> Eiffel doesn't handle the relationship of co- and contra-variance of arguments with subtyping in a principled way. This is apparently known as the "catcall" problem. See, e.g., this article: http://www.eiffelroom.org/node/517

Yes, variance is another big source of unsafety, that's for sure. And another reason I think there is no real "theory" behind Eiffel, just a bunch of features (or "concepts") boiled together.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alberto.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Timon Gehr | 3 Jan 23:02 2013
Picon
Picon

Re: Object Oriented programming for Functional Programmers

On 01/03/2013 10:56 AM, Alberto G. Corona wrote:
> Anyway, Type checking is essentially an application of set theory : (I
> did no search in te literature for this, It is just my perception).

Not exactly. Type theory is not an application of set theory, it is an 
alternative to set theory.

> When
> I say   (+) :: Num a => a -> a -> a . I mean that (+) takes two elements
> of the set of Num typeclass and return another.

If I get this right, you consider Num to be a set, and then its 
inhabitants would need to be be types, thus this describes a type-level 
mapping.
This is a more accurate description, (but there might be a better one):

(+) : (a : Type)->(i : (Num a : Prop))->(x : a)->(y : a)->(z : a)

(+) is a mapping from types 'a' to mappings from proofs 'i' of the 
proposition that 'a' is an instance of the 'Num' type class to a curried 
function that takes two arguments of type 'a' and produces a result of 
type 'a'.

> This is in principle a
> weak restriction, because many functions do it as well, for example (*).
>
> A propery check or a contract would be much more restrictive and thus
> would detect much more program errors. But it seems that no other
> language but haskell took this set theoretical analysis so exhaustively,

There are quite a few that take it further than Haskell.

http://wiki.portal.chalmers.se/agda/pmwiki.php

> and without it, a property check is like detecting microscopic cracks in
> nuclear waste vessel without first making sure that the cover has been
> sealed.
>
Timon Gehr | 3 Jan 23:07 2013
Picon
Picon

Re: Object Oriented programming for Functional Programmers

On 01/02/2013 11:19 PM, MigMit wrote:
>
> On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gershomb <at> gmail.com> wrote:
>
>> On 1/2/13 4:29 PM, MigMit wrote:
>>>
>>>> BTW. Why you think that Eiffel type system is unsafe?
>>> Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you
can't be certain that this object actually has this method. Could be that this object belongs to some
subclass which removes this method.
>>>
>>
>> Eiffel doesn't handle the relationship of co- and contra-variance of arguments with subtyping in a
principled way. This is apparently known as the "catcall" problem. See, e.g., this article: http://www.eiffelroom.org/node/517
>
> Yes, variance is another big source of unsafety, that's for sure. And another reason I think there is no
real "theory" behind Eiffel, just a bunch of features (or "concepts") boiled together.
>

There seem to be efforts to fix this:
http://tecomp.sourceforge.net/index.php?file=doc/papers/proof/

The resulting language appears to be type safe:
http://tecomp.sourceforge.net/index.php?file=doc/papers/lang/modern_eiffel.txt#chapter_20
Colin Adams | 5 Jan 01:14 2013
Picon

Re: Object Oriented programming for Functional Programmers

There have been lots of proposals to fix the CATCALL problems in recent years. None have been implemented (at least in ISE/GEC compilers. And tecomp has been abandonded by its author - he is now writing a series of blogs about a vapourware product called "Modern Eiffel").


I don't find the CATCALL problem a great problem in practice (one gets used to avoiding the problem). But it is a nasty whole in the theory of the type system.

On 3 January 2013 22:07, Timon Gehr <timon.gehr <at> gmx.ch> wrote:
On 01/02/2013 11:19 PM, MigMit wrote:

On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gershomb <at> gmail.com> wrote:

On 1/2/13 4:29 PM, MigMit wrote:

BTW. Why you think that Eiffel type system is unsafe?
Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you can't be certain that this object actually has this method. Could be that this object belongs to some subclass which removes this method.


Eiffel doesn't handle the relationship of co- and contra-variance of arguments with subtyping in a principled way. This is apparently known as the "catcall" problem. See, e.g., this article: http://www.eiffelroom.org/node/517

Yes, variance is another big source of unsafety, that's for sure. And another reason I think there is no real "theory" behind Eiffel, just a bunch of features (or "concepts") boiled together.


There seem to be efforts to fix this:
http://tecomp.sourceforge.net/index.php?file=doc/papers/proof/

The resulting language appears to be type safe:
http://tecomp.sourceforge.net/index.php?file=doc/papers/lang/modern_eiffel.txt#chapter_20





_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bob Hutchison | 2 Jan 16:01 2013
Picon

Re: Object Oriented programming for Functional Programmers


On 2013-01-02, at 1:52 AM, Mike Meyer <mwm <at> mired.org> wrote:

> 
> 
> [Context destroyed by top posting.]
> MigMit <miguelimo38 <at> yandex.ru> wrote:
>> But really, "Design by Contract" — a theory? It certainly is a useful
>> approach, but it doesn't seem to be a theory, not until we can actually
>> prove something about it, and Eiffel doesn't seem to offer anything in
>> this direction.
> 
> You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing.
Note that it's a theory about *programming*, not the resulting program.
> 
>> And by "hack" I meant not the presence of pre/postconditions, but the
>> fact that they don't affect anything else. Strip all of them away, and
>> you'll have the program which is, essentially, the same (and, in fact,
>> pre/postconditions are supposed to be removed in the final version of
>> the program). Compare this to Haskell types, for example: an untyped
>> version of Haskell won't be able to choose between two class instances,
>> so, that would be an entirely different language.
> 
> Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type
signatures a hack to get around deficiencies in the type inferencing engine? After all, you can strip all
of them away and have essentially the same program.

Eiffel programmers certainly consider the pre&post conditions and invariants to be part of the signature.

DbC is closely related to the management of state, and so to the object as a whole not just the parameters to a
method. Now, I'm no expert in Haskell so treat the next part of this paragraph accordingly... putting
invariants and conditions on monads, in particular to the entry and exit from do notation might be
interesting. No particular ideas as to how you'd do that, or even if it'd be useful, but it seems to me to be a
bit closer to the level of abstraction where DbC is at in Eiffel.

> 
> Personally, I think the answer is "no", and for the same reason. We add type signatures to top level
functions because it helps document the function, and to help isolate type errors during compilation.
They makes *programming* easier, even if they don't change the program at all. Pre and Post conditions
(and class invariants - they're also part of DbC!) serve pretty much the same function. They help document
the classes and methods, and tools that generate class/method documentation from source always include
them. They're as important as the type signature. They also help isolate bugs, in that you get told
explicitly that routine foo passed in an invalid parameter to bar rather than an exception somewhere deep
in the guts of bar that you have to work back from to find foo.
> 
> As I said before, I'm not sure I agree that the latter is worth the cost of using them for anything complex.
The bugs they uncover are as likely to be in the pre/post conditions as in the code proper.  The
documentation benefit is unquestionable, though. And if some condition is worth documenting, then
having it as executable documentation means it gets tested with the rest of the code, so you know the
documentation is correct. Which means that just adding conditions to a language misses most of the
benefit of DbC. You need to fix the documentation system as well.

I can only speak from personal experience here. I used Eiffel as my primary programming language in the
1990's for about 10 years. I wrote a lot of code in Eiffel, and I used pre&post conditions and class
invariants extensively (and loop invariants surprisingly often). Some of that code would certainly be
described as 'complex'. Yes, documentation is a huge part of what DbC gives you, but a peculiarly
aggressive kind of documentation that tells you when you're doing it wrong. The biggest problem I had with
writing pre&post conditions and class invariants was missing part of what should be specified and so
letting things pass that shouldn't have. The next biggest problem was being overly specific (I sometimes
do the same thing with type signatures in Haskell I'm afraid). Bugs in the code of the conditions and
invariants was not much of a problem I found (I can't recall any). It does take a while to learn how to write
the conditions and how to accommodate DbC concepts when you write a class or class hierarchy. And,
occasionally, the balancing act between DbC and unit tests is tricky.

> 
> This is the kind of theory that you'll find in OOSC: why the features that are there help make programming
easier. Not theories about how they make the resulting program better. Those two have a lot in common,
though. Anything that makes witing correct code easier generally results in a better program.
> -- 
> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Никитин Лев | 2 Jan 05:44 2013
Picon

Re: Object Oriented programming for Functional Programmers

I said "theoratical", but not "mathematical" or "a scientific" theory.    Meyer have built a quite coherent construction in comparison with other OOP langs.
 
BTW, when I started study haskell i had similar question: is it possible to add DbC to haskell? Does haskell need DbC?
For example, class invariants may be expressed in DbC construction (fmap id = id for Functior, for example).
 
02.01.2013, 02:41, "Mike Meyer" <mwm <at> mired.org>:

MigMit <miguelimo38 <at> yandex.ru> wrote:

On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru>
wrote:
 Eiffel, for my opinion, is a best OOP language. Meyer use a
theoretical approach as it is possible in OOP.
Really? Because when I studied it I had a very different impression:
that behind this language there was no theory at all. And it's only
feature I remember that is not present in mainstream languages is it's
pre/postconditions system, which looked like an ugly hack for me.

I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to "mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to something like Scheme, Haskell or even Clojure, maybe not so much.

On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is "Design by Contract". The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code.


--
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit | 2 Jan 10:43 2013
Picon

Re: Object Oriented programming for Functional Programmers


On Jan 2, 2013, at 8:44 AM, Никитин Лев <leon.v.nikitin <at> pravmail.ru> wrote:

> I said "theoratical", but not "mathematical" or "a scientific" theory.

Than what kind of theory did you mean?

> <image1.gif>  Meyer have built a quite coherent construction in comparison with other OOP langs.

More than Smalltalk, for example?

> BTW, when I started study haskell i had similar question: is it possible to add DbC to haskell? Does haskell
need DbC?
> For example, class invariants may be expressed in DbC construction (fmap id = id for Functior, for example).
>  
> 02.01.2013, 02:41, "Mike Meyer" <mwm <at> mired.org>:
> MigMit <miguelimo38 <at> yandex.ru> wrote:
> 
> On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin <at> pravmail.ru>
> wrote:
>  Eiffel, for my opinion, is a best OOP language. Meyer use a
> theoretical approach as it is possible in OOP.
> Really? Because when I studied it I had a very different impression:
> that behind this language there was no theory at all. And it's only
> feature I remember that is not present in mainstream languages is it's
> pre/postconditions system, which looked like an ugly hack for me.
> I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to
"mainstream" OO languages like C++, Java or Python, it's on a much solider theoretical basis.  Compared to
something like Scheme, Haskell or even Clojure, maybe not so much.
> 
> On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions
is "Design by Contract". The contracts are as important as the type signature, and show up in the
auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not
sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as
in the code.
> 
> 
> -- 
> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
wren ng thornton | 2 Jan 05:39 2013

Re: Object Oriented programming for Functional Programmers

On 12/31/12 4:26 PM, Rico Moorman wrote:
> Hello Bob and Mike,
>
> Reading a little within the suggested book I came across the following
> statement.
>
>> We should first examine the merits and limitations of the traditional
>> approach: using
>> functions as a basis for the architecture of software systems. This will
>> not only lead us to
>> appreciate why we need something else — object technology — but also help
>> us avoid,
>> when we do move into the object world, certain methodological pitfalls
>> such as premature
>> operation ordering, which have been known to fool even experienced O-O
>> developers.
>
> Because you both have more experience with this piece of literature, how
> would you interpret it? With a grain of salt or would function really mean
> procedure from the viewpoint of the author?

I'm not Bob nor Mike, and haven't read the text in question, but when 
you encounter "function" in most any imperative or OO setting, it almost 
certainly means a first-order procedure. No mathematical functions. No 
higher-order thingamabobs that you can pass to or return from other 
thingamabobs. Just an address in code with an expected stack frame 
configuration associated with it.

As for learning object orientation, I'd second the suggestion of 
Smalltalk. I'll leave the religious wars aside, but "OOP" means very 
different things to very different people. Most people use the term 
whilst referring to C++ and Java, but most people recognize that the 
ideological framework is best attained by Smalltalk (and related 
languages like Ruby). So, if you're interested in learning the ideology, 
then Smalltalk is a great place to get it.

Also, Smalltalk has the "become" method, which is amazing magic.

--

-- 
Live well,
~wren
Alexander Solla | 31 Dec 21:51 2012
Picon

Re: Object Oriented programming for Functional Programmers

Since you have done a significant amount of work with Haskell, I must presume you have a solid understanding of monads.  If so, I can suggest reading 


It is "for the OO programmer", but it does a good job of clarifying some issues.

In particular, a "class hierarchy" is analogous to a stack of monads (made with monad transformers).  That is to say, a class attaches 'methods' to an 'object' (i.e., a context, which might include data).  Different languages use different monads to attach methods to objects -- for example, JavaScript uses "prototype-based" object orientation, which is very much analogous to the Haskell pattern:

data SomeData = ...

defaultData :: SomeData
defaultData = ...

setName :: Name -> SomeData -> SomeData
setName = ...

namedData :: SomeData
namedData = setName (Name "Pete") defaultData

Typically, an object oriented language provides an enriched IO monad which provides method dispatch based on context, state "for free" by setting variables (i.e., the dreaded side-effect), and so on.  From a functional perspective, this is all syntactic sugar for a complicated monad transformer stack:

type OO a = ClassT a (StateT a IO) a

Typical object oriented languages are procedural in nature, and use explicit looping to handle iterating over data structures.  Typically, all work is done in the same monad and it is "impossible" to define your own monads using "best practices" for that OO language.



On Sun, Dec 30, 2012 at 11:58 AM, Daniel Díaz Casanueva <dhelta.diaz <at> gmail.com> wrote:
Hello, Haskell Cafe folks.

My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though.

But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.

But, why I am writing this to you, haskellers?

Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.

So my questions for you all are:

* Is it really worthwhile for me to learn OO-programming?

* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".

* Is it true that learning other programming languages leads to a better use of your favorite programming language?

* Will I learn new programming strategies that I can use back in the Haskell world?

Thanks in advance for your kind responses,
Daniel Díaz.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Emanuel Koczwara | 2 Jan 15:12 2013
Picon

Re: Object Oriented programming for Functional Programmers

Hi,

  First, I see (posts on this mailing list) that OO ideas are well known
in functional community :)

> 
> So my questions for you all are:
> 
> 
> * Is it really worthwhile for me to learn OO-programming?
> 
> 

  Learn or not to learn? I would say: yes! There is whole new universe
to discover: UML, design patterns, classes and objects, data structures
based on 'pointers' (and you can modify them, surprise!) and of course
many algorithms that work on this structures (please note, that many
books about algorithms and data structures take imperative approach), OO
databases, many many many libraries for almost any thing! and finally,
you will be able to try stable, well known and widely used tools (think
about GUIs, game engines, embedded systems, mobile devices and all this
fascinating stuff you can do with them).

> * If so, where should I start? There are plenty of "functional
> programming for OO programmers" but I have never seen "OO programming
> for functional programmers".
> 

  Get a book (big and heavy!), forget all about programming and read it
with fresh mind. Do _all_ exercises from that book.

> 
> * Is it true that learning other programming languages leads to a
> better use of your favorite programming language?
> 
> 

  I would say, any know knowledge has impact on your life. Programming
skills also.

> * Will I learn new programming strategies that I can use back in the
> Haskell world?
> 

  Here I can't say much, I'm just starting with Haskell, but if you
would go with C++, then you will also learn some C by the way, FFI is
waiting..

> 
> Thanks in advance for your kind responses,
> 

  I hope it was helpful.

Emanuel

Gmane