usefulness of OOP

FFT,

i share your sentiments. One real abstraction technique that i believe has some legs and remotely resembles OO techniques is the Haskell typeclass. i think this really gets at some of what OO is groping towards; but, i think there is a genuine overhead for Scala that is about the rational reconstruction of OO semantics. It's an overhead the main function of which is to ease the transition of the OO community to a more scalable set of abstractions.

Best wishes,

--greg

On Mon, Apr 27, 2009 at 6:03 PM, FFT <fft1976 [at] gmail [dot] com> wrote:

I was watching a Google Tech talk by Martin Odersky, in which he says
that functional programmers do not understand the usefulness of OOP,
specifically, the ability to extend classes by overriding methods.
However, as far as I can tell, he does not support this claim later in
the talk. As a counter-argument, I know that in OCaml, OOP is
available (the "O" part), but is widely viewed as a failed experiment
(not "failed" in a pejorative sense, but even its creator does not use
the objective extensions). What can overriding methods do that
higher-order functions can not do as well or better?

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

I would almost have to imagine you misheard. Overriding a non-trivial
concrete method with another concrete method is very rare in modern
mainstream OO practice, to the point where I would almost consider it an
anti-pattern. I would imagine it makes a bit more sense with mix-in
inheritance, but haven't needed it enough to say, and in any case that use
seems more aspect-oriented than object-oriented.

FFT-2 wrote:
>
> What can overriding methods do that
> higher-order functions can not do as well or better?
>
>

2009/4/28 Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com>

... to ease the transition of the OO community to a more scalable set of abstractions.

Are you saying that Scala is therapy for Java programmers? :)

On Mon, Apr 27, 2009 at 9:33 PM, Dave Griffith
wrote:

> I would almost have to imagine you misheard.

Bad wording on my part (I'm not an OO person, so I don't always use
the correct nomenclature) I think what Martin said was that it's
useful to implement some methods in a class, while leaving some
unimplemented (to be implemented by the user of the class).

He mentioned how functional programmers don't understand the
usefulness of this. I still don't see what useful things this gives
you that higher-order functions don't.

It doesn't give anything that higher order functions don't.  The two techniques are equivalent and can be implemented in terms of one another.  However, in each language, one technique will tend to be more readable than the other.

2009/4/28 FFT <fft1976 [at] gmail [dot] com>

On Mon, Apr 27, 2009 at 9:33 PM, Dave  Griffith
<dave [dot] l [dot] griffith [at] gmail [dot] com> wrote:

> I would almost have to imagine you misheard.

Bad wording on my part (I'm not an OO person, so I don't always use
the correct nomenclature) I think what Martin said was that it's
useful to implement some methods in a class, while leaving some
unimplemented (to be implemented by the user of the class).

 He mentioned how functional programmers don't understand the
usefulness of this. I still don't see what useful things this gives
you that higher-order functions don't.

Meredith Gregory wrote:
> FFT,
>
> i share your sentiments. One real abstraction technique that i believe
> has some legs and remotely resembles OO techniques is the Haskell
> typeclass. i think this really gets at some of what OO is groping
> towards; but, i think there is a genuine overhead for Scala that is
> about the rational reconstruction of OO semantics. It's an overhead the
> main function of which is to ease the transition of the OO community to
> a more scalable set of abstractions.

To be really powerful a language needs to support both static and
dynamic polymorphism. In Haskell type classes can be used for both types
(see http://haskell.org/haskellwiki/OOP_vs_type_classes for some
examples). In Scala dynamic polymorphism is achieved through sub typing,
static polymorphism mostly through implicits.

Now with type classes you can extend existing types with new dynamically
resolved functionality to outside of their definition site. This can not
be achieved with inheritance/implementation as the type hierarchy is
static. Something like scoped interface injection could be a solution.
It would be resolved similarly to implicits, but could introduce new
sub/super type relationships locally. I would really be interested if
someone knows a language which supports such a feature, it's somewhat
akin to dynamic multi methods but instead work on interface basis.

/Jesper Nordenberg

On Tue, Apr 28, 2009 at 3:03 AM, FFT wrote:
> I was watching a Google Tech talk by Martin Odersky, in which he says
> that functional programmers do not understand the usefulness of OOP,
> specifically, the ability to extend classes by overriding methods.
> However, as far as I can tell, he does not support this claim later in
> the talk. As a counter-argument, I know that in OCaml, OOP is
> available (the "O" part), but is widely viewed as a failed experiment
> (not "failed" in a pejorative sense, but even its creator does not use
> the objective extensions). What can overriding methods do that
> higher-order functions can not do as well or better?
>
The crucial thing is to be able to implement methods (and, in the case
of Scala, types)
in subclasses. That way, the unknown part of an abstraction can be
left open in a class to be filled in later in subclasses. Functional
programmers indeed usually don't get this, and think higher-order
methods or ML functors are a sufficient replacement. But the crucial
difference is this:

An implementation of an abstract {def, val, type} can refer to other
members of its superclass. But an argument to a higher order method or
functor cannot refer to
the result of the application. So open recursion with abstraction is
supported in OOP but it requires elaborate and rather tedious
boilerplate in FP (such as the encodings of classes in TAPL (*).

To get a demonstration what difference this can make, I invite you to
try to do this little task, which was originally proposed by Corky
Cartwright at a WG 2.8 meeting (**):

The task is to write an interpreter for a little functional language -
lambda calculus with n-argument functions and integer arithmetic.
There are several means to represent
variables and environments in such an interpreter. For instance,
variables could be strings and environments association lists, or
variables could be DeBruijn numbers, and environments simple stacks.
The question is this -- how much of your interpreter can you re-use if
you change your decision how to represent variables and environments?

Corky put this up as a challenge in the meeting because he noted that
this was rather easy in Scheme, but almost impossible in GJ (or Java
today). So are static types hindering re-use? People at the meeting
came up with three different solutions, one in SML, one in Haskell,
and one in Scala. The Scala solution used a simple abstract class for
the interpreter where environment type, variable type and environment
access were kept abstract. Abstract members were then implemented in
different ways for DeBruijn and association list interpreters. The
Haskell solution used a big type class (with six functional
dependencies, if I remember correctly). The ML solution used functors
with sharing constraints. It was about 1 1/2 times the length of the
other two solutions. Also, everyone but the most experienced ML
programmers found it significantly harder to understand than the other
two solutions. But it's really better if you try this out for
yourself...

Cheers

On Tue, Apr 28, 2009 at 3:03 AM, FFT wrote:
> I was watching a Google Tech talk by Martin Odersky, in which he says
> that functional programmers do not understand the usefulness of OOP,
> specifically, the ability to extend classes by overriding methods.
> However, as far as I can tell, he does not support this claim later in
> the talk. As a counter-argument, I know that in OCaml, OOP is
> available (the "O" part), but is widely viewed as a failed experiment
> (not "failed" in a pejorative sense, but even its creator does not use
> the objective extensions). What can overriding methods do that
> higher-order functions can not do as well or better?

Part of the usefulness of OOP shows even when comparing Java to C#:
Java supports closures with anonymous inner classes, whereas in C#
only delegates (=functions) may close over the surrounding scope.
Being used to programming with closures, I felt that very limiting in
C# and ended up passing several delegates to the constructor of a
generic helper class (instead of creating named subclasses for each
case which probably would have been more natural).

To get a demonstration what difference this can make, I invite you to
try to do this little task, which was originally proposed by Corky
Cartwright at a WG 2.8 meeting (**):

The task is to write an interpreter for a little functional language -
 lambda calculus with n-argument functions and integer arithmetic.

  This sounds very interesting, Martin! Are the solutions people came up with documented anywhere that we could look at?
On Tue, Apr 28, 2009 at 5:23 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Tue, Apr 28, 2009 at 3:03 AM, FFT <fft1976 [at] gmail [dot] com> wrote:
> I was watching a Google Tech talk by Martin Odersky, in which he says
> that functional programmers do not understand the usefulness of OOP,
> specifically, the ability to extend classes by overriding methods.
> However, as far as I can tell, he does not support this claim later in
> the talk. As a counter-argument, I know that in OCaml, OOP is
> available (the "O" part), but is widely viewed as a failed experiment
> (not "failed" in a pejorative sense, but even its creator does not use
> the objective extensions). What can overriding methods do that
> higher-order functions can not do as well or better?
>
The crucial thing is to be able to implement methods (and, in the case
of Scala, types)
in subclasses. That way, the unknown part of an abstraction can be
left open in a class to be filled in later in subclasses. Functional
programmers indeed usually don't get this, and think higher-order
methods or ML functors are a sufficient replacement. But the crucial
difference is this:

An implementation of an abstract {def, val, type} can refer to other
members of its superclass. But an argument to a higher order method or
functor cannot refer to
the result of the application. So open recursion with abstraction is
supported in OOP but it requires elaborate and rather tedious
boilerplate in FP (such as the encodings of classes in TAPL (*).

To get a demonstration what difference this can make, I invite you to
try to do this little task, which was originally proposed by Corky
Cartwright at a WG 2.8 meeting (**):

The task is to write an interpreter for a little functional language -
 lambda calculus with n-argument functions and integer arithmetic.
There are several means to represent
variables and environments in such an interpreter. For instance,
variables could be strings and environments association lists, or
variables could be DeBruijn numbers, and environments simple stacks.
The question is this -- how much of your interpreter can you re-use if
you change your decision how to represent variables and environments?

Corky put this up as a challenge in the meeting because he noted that
this was rather easy in Scheme, but almost impossible in GJ (or Java
today). So are static types hindering re-use? People at the meeting
came up with three different solutions, one in SML, one in Haskell,
and one in Scala. The Scala solution used a simple abstract class for
the interpreter where environment type, variable type and environment
access were kept abstract. Abstract members were then implemented in
different ways for DeBruijn and association list interpreters. The
Haskell solution used a big type class (with six functional
dependencies, if I remember correctly). The ML solution used functors
with sharing constraints. It was about 1 1/2 times the length of the
other two solutions. Also, everyone but the most experienced ML
programmers found it significantly harder to understand than the other
two solutions. But it's really better if you try this out for
yourself...

Cheers

 -- Martin

(*) Benjamin Pierce: Types And Programming Languages
(**) IFIP Working Group for Functional Programming

Hi Paul.

I don't have the source anymore. It's been 2003 when we did this. But
it's not hard to do this yourself, really.

Cheers

On Tue, Apr 28, 2009 at 2:23 AM, martin odersky wrote:
> The ML solution used functors
> with sharing constraints. It was about 1 1/2 times the length of the
> other two solutions.

If we are going to compare the lengths of code with such accuracy, a
more precise problem definition could be helpful or, better yet, the
original implementation to convert from (Scheme or Scala?)

What's the syntax and semantics of the language being interpreted? Is
the idea to have two implementations sharing code, while minimizing
the total code size?

On Tue, Apr 28, 2009 at 8:31 PM, FFT wrote:
> On Tue, Apr 28, 2009 at 2:23 AM, martin odersky wrote:
>> The ML solution used functors
>> with sharing constraints. It was about 1 1/2 times the length of the
>> other two solutions.
>
> If we are going to compare the lengths of code with such accuracy, a
> more precise problem definition could be helpful or, better yet, the
> original implementation to convert from (Scheme or Scala?)
>
> What's the syntax and semantics of the language being interpreted? Is
> the idea to have two implementations sharing code, while minimizing
> the total code size?
>
Here's the language to to interpret (where postfix * means tupling):

Variables: x
Integer literals: i
Terms:

t = Lambda x*. t
| Apply t t*
| Var(x)
| Num(i)

We assume usual operational semantics of lambda calculus (i.e. static scoping).

The task is to write two interpreters, one with variables x being
DeBruijn indices and one with them being names.
You should go for maximal sharing, i.e. factor out commonalities into
a common class/typeclass/functor/whatever, so that there remains no
duplication of code in the two solutions.

Cheers

Martin,
Do you have a simpler such problem?  I'd like to see what you mean for myself, but there's too much in there that I would need to learn beforehand.
Ricky.

2009/4/28 martin odersky <martin [dot] odersky [at] epfl [dot] ch>

On Tue, Apr 28, 2009 at 8:31 PM, FFT <fft1976 [at] gmail [dot] com> wrote:
> On Tue, Apr 28, 2009 at 2:23 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
>> The ML solution used functors
>> with sharing constraints. It was about 1 1/2 times the length of the
>> other two solutions.
>
> If we are going to compare the lengths of code with such accuracy, a
> more precise problem definition could be helpful or, better yet, the
> original implementation to convert from (Scheme or Scala?)
>
> What's the syntax and semantics of the language being interpreted? Is
> the idea to have two implementations sharing code, while minimizing
> the total code size?
>
Here's the language to to interpret (where postfix * means tupling):

Variables: x
Integer literals: i
Terms:

t = Lambda x*. t
 |  Apply t t*
 |  Var(x)
 |  Num(i)

We assume usual operational semantics of lambda calculus (i.e. static scoping).

The task is to write two interpreters, one with variables x being
DeBruijn indices and one with them being names.
You should go for maximal sharing, i.e. factor out commonalities into
a common class/typeclass/functor/whatever, so that there remains no
duplication of code in the two solutions.

Cheers

On Tue, Apr 28, 2009 at 8:50 PM, Ricky Clarkson
wrote:
> Martin,
> Do you have a simpler such problem?  I'd like to see what you mean for
> myself, but there's too much in there that I would need to learn beforehand.
> Ricky.
>
Not really. The problem is that any such discussion requires problems
of a certain size. You can't justify the usefulness of OOP on a
whiteboard (in any case, I can't). You need problems approaching real
size scenarios.

But in any case the solutions to the problem Corky gave are quite
manageable -- they were all under 60 lines AFAIRC.

Cheers

I am not sure I follow.  So what is wrong with this:
 

Abstract members were then implemented in
different ways for DeBruijn and association list interpreters. The
Haskell solution used a big type class (with six functional
dependencies, if I remember correctly).

Daryoush


On Tue, Apr 28, 2009 at 2:23 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Tue, Apr 28, 2009 at 3:03 AM, FFT <fft1976 [at] gmail [dot] com> wrote:
> I was watching a Google Tech talk by Martin Odersky, in which he says
> that functional programmers do not understand the usefulness of OOP,
> specifically, the ability to extend classes by overriding methods.
> However, as far as I can tell, he does not support this claim later in
> the talk. As a counter-argument, I know that in OCaml, OOP is
> available (the "O" part), but is widely viewed as a failed experiment
> (not "failed" in a pejorative sense, but even its creator does not use
> the objective extensions). What can overriding methods do that
> higher-order functions can not do as well or better?
>
The crucial thing is to be able to implement methods (and, in the case
of Scala, types)
in subclasses. That way, the unknown part of an abstraction can be
left open in a class to be filled in later in subclasses. Functional
programmers indeed usually don't get this, and think higher-order
methods or ML functors are a sufficient replacement. But the crucial
difference is this:

An implementation of an abstract {def, val, type} can refer to other
members of its superclass. But an argument to a higher order method or
functor cannot refer to
the result of the application. So open recursion with abstraction is
supported in OOP but it requires elaborate and rather tedious
boilerplate in FP (such as the encodings of classes in TAPL (*).

To get a demonstration what difference this can make, I invite you to
try to do this little task, which was originally proposed by Corky
Cartwright at a WG 2.8 meeting (**):

The task is to write an interpreter for a little functional language -
 lambda calculus with n-argument functions and integer arithmetic.
There are several means to represent
variables and environments in such an interpreter. For instance,
variables could be strings and environments association lists, or
variables could be DeBruijn numbers, and environments simple stacks.
The question is this -- how much of your interpreter can you re-use if
you change your decision how to represent variables and environments?

Corky put this up as a challenge in the meeting because he noted that
this was rather easy in Scheme, but almost impossible in GJ (or Java
today). So are static types hindering re-use? People at the meeting
came up with three different solutions, one in SML, one in Haskell,
and one in Scala. The Scala solution used a simple abstract class for
the interpreter where environment type, variable type and environment
access were kept abstract. Abstract members were then implemented in
different ways for DeBruijn and association list interpreters. The
Haskell solution used a big type class (with six functional
dependencies, if I remember correctly). The ML solution used functors
with sharing constraints. It was about 1 1/2 times the length of the
other two solutions. Also, everyone but the most experienced ML
programmers found it significantly harder to understand than the other
two solutions. But it's really better if you try this out for
yourself...

Cheers

I'm not objecting to the size of solutions; I'll happily rattle out a couple of thousand lines of code to demonstrate a point to myself, but I wonder if the same result could be obtained with a more approachable problem.  Something of Programming in Scala's academic level.

2009/4/28 martin odersky <martin [dot] odersky [at] epfl [dot] ch>

On Tue, Apr 28, 2009 at 8:50 PM, Ricky Clarkson
<ricky [dot] clarkson [at] gmail [dot] com> wrote:
> Martin,
> Do you have a simpler such problem?  I'd like to see what you mean for
> myself, but there's too much in there that I would need to learn beforehand.
> Ricky.
>
Not really. The problem is that any such discussion requires problems
of a certain size. You can't justify the usefulness of OOP on a
whiteboard (in any case, I can't).  You need problems approaching real
size scenarios.

But in any case the solutions to the problem Corky gave are quite
manageable -- they were all under 60 lines AFAIRC.

Cheers

On Tue, Apr 28, 2009 at 10:51 PM, Daryoush Mehrtash wrote:
> I am not sure I follow.  So what is wrong with this:
>
>>
>> Abstract members were then implemented in
>> different ways for DeBruijn and association list interpreters. The
>> Haskell solution used a big type class (with six functional
>> dependencies, if I remember correctly).
>
>
Nothing. Did I imply that something was wrong with it?

On Tuesday 28 April 2009 21:51:03 Daryoush Mehrtash wrote:
> On Tue, Apr 28, 2009 at 2:23 AM, martin odersky
wrote:
> > To get a demonstration what difference this can make, I invite you to
> > try to do this little task, which was originally proposed by Corky
> > Cartwright at a WG 2.8 meeting (**):
> >
> > The task is to write an interpreter for a little functional language -
> > lambda calculus with n-argument functions and integer arithmetic.
> > There are several means to represent
> > variables and environments in such an interpreter. For instance,
> > variables could be strings and environments association lists, or
> > variables could be DeBruijn numbers, and environments simple stacks.
> > The question is this -- how much of your interpreter can you re-use if
> > you change your decision how to represent variables and environments?
> >
> > Corky put this up as a challenge in the meeting because he noted that
> > this was rather easy in Scheme, but almost impossible in GJ (or Java
> > today). So are static types hindering re-use? People at the meeting
> > came up with three different solutions, one in SML, one in Haskell,
> > and one in Scala. The Scala solution used a simple abstract class for
> > the interpreter where environment type, variable type and environment
> > access were kept abstract. Abstract members were then implemented in
> > different ways for DeBruijn and association list interpreters. The
> > Haskell solution used a big type class (with six functional
> > dependencies, if I remember correctly). The ML solution used functors
> > with sharing constraints. It was about 1 1/2 times the length of the
> > other two solutions. Also, everyone but the most experienced ML
> > programmers found it significantly harder to understand than the other
> > two solutions. But it's really better if you try this out for
> > yourself...

Apologies for joining this late (in case I missed what I'm looking for
already) but are the solutions available anywhere and has anyone added an
OCaml solution?

Martin,

Cool! i'll give this a whirl.

Best wishes,

--greg

On Tue, Apr 28, 2009 at 11:41 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Tue, Apr 28, 2009 at 8:31 PM, FFT <fft1976 [at] gmail [dot] com> wrote:
> On Tue, Apr 28, 2009 at 2:23 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
>> The ML solution used functors
>> with sharing constraints. It was about 1 1/2 times the length of the
>> other two solutions.
>
> If we are going to compare the lengths of code with such accuracy, a
> more precise problem definition could be helpful or, better yet, the
> original implementation to convert from (Scheme or Scala?)
>
> What's the syntax and semantics of the language being interpreted? Is
> the idea to have two implementations sharing code, while minimizing
> the total code size?
>
Here's the language to to interpret (where postfix * means tupling):

Variables: x
Integer literals: i
Terms:

t = Lambda x*. t
 |  Apply t t*
 |  Var(x)
 |  Num(i)

We assume usual operational semantics of lambda calculus (i.e. static scoping).

The task is to write two interpreters, one with variables x being
DeBruijn indices and one with them being names.
You should go for maximal sharing, i.e. factor out commonalities into
a common class/typeclass/functor/whatever, so that there remains no
duplication of code in the two solutions.

Cheers

May be I read too much between the lines.  Here is what I was thinking...

The  challenge problem required extension points to deal with future changes in the types, if  I understand you correctly,  in Haskell this was done by function abstraction in the type class (seems straight forward and consistent with the problem you were trying to solve).    In Scala you had to use the Abstract class with hidden members.  With the Haskell type you also get the side effect free guarantees that you would need if you are really concern about re usability. That aside, it seems to me that unless there is something wrong with the Haskell implementation, or the OO  implementation is somehow orders of magnitude better than the Haskell one, your argument is actually against the OO model.   Because the notions that you had to introduce to solve a problem later on gives you lot of grief (aka good interview question) when you try to do generic programing (Last I check Java Generics faq was 500+ pages).    So I assumed that you found the Haskell implementation as complicated enough to justify the OO model. 

daryoush

On Tue, Apr 28, 2009 at 1:57 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Tue, Apr 28, 2009 at 10:51 PM, Daryoush Mehrtash <dmehrtash [at] gmail [dot] com> wrote:
> I am not sure I follow.  So what is wrong with this:
>
>>
>> Abstract members were then implemented in
>> different ways for DeBruijn and association list interpreters. The
>> Haskell solution used a big type class (with six functional
>> dependencies, if I remember correctly).
>
>
Nothing. Did I imply that something was wrong with it?

On Wednesday 29 April 2009 00:04:30 Meredith Gregory wrote:
> On Tue, Apr 28, 2009 at 11:41 AM, martin odersky
wrote:
> > Here's the language to to interpret (where postfix * means tupling):
> >
> > Variables: x
> > Integer literals: i
> > Terms:
> >
> > t = Lambda x*. t
> >
> > | Apply t t*
> > | Var(x)
> > | Num(i)
> >
> > We assume usual operational semantics of lambda calculus (i.e. static
> > scoping).
> >
> > The task is to write two interpreters, one with variables x being
> > DeBruijn indices and one with them being names.
> > You should go for maximal sharing, i.e. factor out commonalities into
> > a common class/typeclass/functor/whatever, so that there remains no
> > duplication of code in the two solutions.

Here is my first stab at an OCaml implementation:

open List

let unClosure = function `Closure c -> c | _ -> invalid_arg "closure"

let add state x v = (x, v)::state

let rec eval state = function
| `Lambda(params, body) -> `Closure(state, params, body)
| `Apply(f, args) ->
let args = map (eval state) args in
let state, params, body = unClosure(eval state f) in
eval (fold_left2 add state params args) body
| `Var x -> assoc x state
| `Num i -> `Int i

The representation of variables is (parametrically) polymorphic and is only
required to support structural equality. So you just use values of whatever
type you like. For example, with strings:

eval [] (`Apply(`Lambda(["x"], `Var "x"), [`Num 3]))

And with de Bruijn indices:

eval [] (`Apply(`Lambda([1], `Var 1), [`Num 3]))

On Wednesday 29 April 2009 00:52:07 Daryoush Mehrtash wrote:
> With the Haskell type you also get the side effect free guarantees that you
> would need if you are really concern about re usability.

Out of curiosity, what does the Haskell look like if you change it to
represent variable bindings using an imperative hash table?

On Tue, Apr 28, 2009 at 5:02 PM, Jon Harrop wrote:

>  let add state x v = (x, v)::state

I like your implementation, but I think "add" and "assoc" are also
supposed to be parameters to "eval". For strings, it will be the "add"
and "assoc" you used, and for De Bruijn numbers (I still don't grok
them), something else.

However, as far as I can tell, this is all easily doable, with "state"
as a polymorphic type.

By the way, I think it's just as easy without polymorphic variants
(backquoted tags), although your approach is probably 1 line terser.

Martin, perhaps the usefulness of OOP is somewhere else? :-) Such as
when mutable state is required, GUIs, etc. ?

On Wed, Apr 29, 2009 at 3:14 AM, FFT wrote:
> On Tue, Apr 28, 2009 at 5:02 PM, Jon Harrop wrote:
>
>>  let add state x v = (x, v)::state
>
> I like your implementation, but I think "add" and "assoc" are also
> supposed to be parameters to "eval". For strings, it will be the "add"
> and "assoc" you used, and for De Bruijn numbers (I still don't grok
> them), something else.
>
Right. The point is to use the best datastructure in each case. For
the DeBruijn interpreter
this should be a stack of lists of values (one list per lambda). For
the named var case, this could be a map from names to values. The
problem is that values include closures, which in turn refer to terms.
So here's the open recursion you have to deal with.

Cheers

On Wednesday 29 April 2009 08:14:36 martin odersky wrote:
> On Wed, Apr 29, 2009 at 3:14 AM, FFT wrote:
> > On Tue, Apr 28, 2009 at 5:02 PM, Jon Harrop wrote:
> >>  let add state x v = (x, v)::state
> >
> > I like your implementation, but I think "add" and "assoc" are also
> > supposed to be parameters to "eval". For strings, it will be the "add"
> > and "assoc" you used, and for De Bruijn numbers (I still don't grok
> > them), something else.
>
> Right. The point is to use the best datastructure in each case. For
> the DeBruijn interpreter
> this should be a stack of lists of values (one list per lambda). For
> the named var case, this could be a map from names to values. The
> problem is that values include closures, which in turn refer to terms.
> So here's the open recursion you have to deal with.

I see. Here is my attempt at factoring out that commonality:

open List

let rec eval env = function
| `Num i -> `Int i
| `Lambda body -> `Closure(env#apply body)
| `Var v -> env#var v
| `Apply(f, args) ->
match eval env f, map (eval env) args with
| `Closure f, args -> f args
| _ -> invalid_arg "Apply of non-function";;

I believe this "eval" function is suitably generic. Here is a concrete
implementation of "env" using de Bruijn indices:

let de_bruijn = object
val env = []
method apply body args = eval {< env=args::env >} body
method var (i, j) = nth (nth env i) j
end

Here is one using variables named with strings and an association list:

let named = object (self)
val env = []
method apply (params, body) args =
eval {< env=fold_left2 (fun s x v -> (x, v)::s) env params args >} body
method var s = assoc s env
end;;

Just to prove that this is generic, here is an extra implementation using a
map (balanced binary tree) from strings to values:

module StringMap = Map.Make(String)

let named = object (self)
val env = StringMap.empty
method apply (params, body) args =
eval {< env=fold_right2 StringMap.add params args env >} body
method var s = StringMap.find s env
end;;

That is 20 lines of code. How does that compare with the other
implementations?

On Wed, Apr 29, 2009 at 5:19 PM, Jon Harrop wrote:

>  let de_bruijn = object

I think (at least part of) the challenge here is to do this without
objects, this being a discussion about the usefulness of OOP.

On Wed, Apr 29, 2009 at 5:19 PM, Jon Harrop wrote:

>
> That is 20 lines of code. How does that compare with the other
> implementations?
>

I suspect your solution is wrong. When I add

let y = eval named (`Apply(`Lambda(["x"], `Var "x"), [`Num 3]));;

to it, "ocamlc -i" likes it, but "ocamlc" gives me an error for that line:

The type of this expression,
_[> `Closure of 'a list -> 'a | `Int of int ] as 'a,
contains type variables that cannot be generalized

I have 3.10.0 here, by the way.

On Thursday 30 April 2009 08:13:37 FFT wrote:
> On Wed, Apr 29, 2009 at 5:19 PM, Jon Harrop wrote:
> > That is 20 lines of code. How does that compare with the other
> > implementations?
>
> I suspect your solution is wrong. When I add
>
> let y = eval named (`Apply(`Lambda(["x"], `Var "x"), [`Num 3]));;

Run it in the top level:

# eval named (`Apply(`Lambda(["x"], `Var "x"), [`Num 3]));;
- : _[> `Closure of 'a list -> 'a | `Int of int ] as 'a = `Int 3

> to it, "ocamlc -i" likes it, but "ocamlc" gives me an error for that line:
>
> The type of this expression,
> _[> `Closure of 'a list -> 'a | `Int of int ] as 'a,
> contains type variables that cannot be generalized
>
> I have 3.10.0 here, by the way.

You're just hitting the value restriction because you're exporting a value of
a monomorphic type from a compilation unit.

On Thursday 30 April 2009 01:47:50 FFT wrote:
> On Wed, Apr 29, 2009 at 5:19 PM, Jon Harrop wrote:
> >  let de_bruijn = object
>
> I think (at least part of) the challenge here is to do this without
> objects, this being a discussion about the usefulness of OOP.

I'll try to write a non-OOP version but I think objects are the natural
solution here.

2009/4/30 Jon Harrop :
> On Thursday 30 April 2009 01:47:50 FFT wrote:
>> On Wed, Apr 29, 2009 at 5:19 PM, Jon Harrop wrote:
>> >  let de_bruijn = object
>>
>> I think (at least part of) the challenge here is to do this without
>> objects, this being a discussion about the usefulness of OOP.
>
> I'll try to write a non-OOP version but I think objects are the natural
> solution here.

Then what exactly are you arguing about? The example wasn't cited as
"Scala is the bestest language ever!!", but "OOP is useful. Here's an
example of why"

On Thursday 30 April 2009 11:07:42 Jon Harrop wrote:
> On Thursday 30 April 2009 01:47:50 FFT wrote:
> > On Wed, Apr 29, 2009 at 5:19 PM, Jon Harrop wrote:
> > >  let de_bruijn = object
> >
> > I think (at least part of) the challenge here is to do this without
> > objects, this being a discussion about the usefulness of OOP.
>
> I'll try to write a non-OOP version but I think objects are the natural
> solution here.

Here is a simple non-OOP solution that just uses a pair of functions instead
of an object:

open List

let rec eval (apply, var as env) = function
| `Num i -> `Int i
| `Lambda body -> `Closure(apply body)
| `Var v -> var v
| `Apply(f, args) ->
match eval env f, map (eval env) args with
| `Closure f, args -> f args
| _ -> invalid_arg "Apply of non-function";;

let rec de_bruijn env =
(fun body args -> eval (de_bruijn (args::env)) body),
(fun (i, j) -> nth (nth env i) j)

module StringMap = Map.Make(String)

let rec named env =
(fun (xs, body) vs ->
eval (named(fold_right2 StringMap.add xs vs env)) body),
(fun s -> StringMap.find s env)

As you can see, it is at least as simple as the OOP solution I gave and just
as generic.

If more "methods" were required then you could just use a record of functions
to name them. OOP seems to be unnecessary because neither inheritance nor
OOP-style polymorphism are beneficial in this case.

However, I do not understand why a Haskell solution would use type classes at
all when (I'd have thought) it could represent an equivalent of my OCaml
directly. I would very much like to see this 33% shorter Scala solution as
well.

On Thu, Apr 30, 2009 at 2:24 PM, Jon Harrop wrote:
> If more "methods" were required then you could just use a record of functions
> to name them.

At which point you're on your way to an encoding of objects ... which
is presumably why you earlier said that objects were the natural
solution.

Cheers,

Miles

Jon Harrop writes:

[...]

> If more "methods" were required then you could just use a record of functions
> to name them. OOP seems to be unnecessary because neither inheritance nor
> OOP-style polymorphism are beneficial in this case.

I've seen the phrase "object based programming" for this kind of usage.

Much of the time "OOP" is mostly (or entirely) about building objects,
not about inheritance.

[...]

On Thursday 30 April 2009 12:45:53 David MacIver wrote:
> 2009/4/30 Jon Harrop :
> > I'll try to write a non-OOP version but I think objects are the natural
> > solution here.
>
> Then what exactly are you arguing about? The example wasn't cited as
> "Scala is the bestest language ever!!", but "OOP is useful. Here's an
> example of why"

In response to FFT's question about OCaml, Martin Odersky made a variety of
statements about "ML" in his post at the beginning of this thread. I disagree
with Martin's response because he neglected OCaml which is not only the gold
standard among MLs and an advanced functional+OOP language but was the
specific subject of FFT's original question. This is not the first time
Martin has glossed over his major competitor when comparing languages.

Martin asserted that "Functional programmers indeed usually don't get this,
and think higher-order methods or ML functors are a sufficient replacement"
but the popularity of OOP-based OCaml libraries like LablGTK and PXP appear
to be compelling counter examples.

Then he stated:

"The ML solution used functors with sharing constraints. It was about 1 1/2
times the length of the other two solutions. Also, everyone but the most
experienced ML programmers found it significantly harder to understand than
the other two solutions."

I seriously doubt anyone can write Scala or Haskell that is either clearer or
shorter than my OCaml, not least because Scala and Haskell cannot even infer
sum types.

Perhaps someone can provide an idiomatic Scala implementation so that we can
draw a fair and objective comparison in order to draw some genuinely
informative conclusions?

On Thursday 30 April 2009 01:19:52 Jon Harrop wrote:
> let de_bruijn = object
> val env = []
> method apply body args = eval {< env=args::env >} body
> method var (i, j) = nth (nth env i) j
> end
> ...
> let named = object (self)
> val env = []
> method apply (params, body) args =
> eval {< env=fold_left2 (fun s x v -> (x, v)::s) env params args >}
> body method var s = assoc s env
> end;;

Incidentally, some people may be interested to see that my OOP-based solution
uses purely functional objects where mutation is replaced with "functional
object update" using OCaml's {< ... >} notation. The objects encapsulate
state but it is immutable.

On Thursday 30 April 2009 14:28:20 Miles Sabin wrote:
> On Thu, Apr 30, 2009 at 2:24 PM, Jon Harrop wrote:
> > If more "methods" were required then you could just use a record of
> > functions to name them.
>
> At which point you're on your way to an encoding of objects ... which
> is presumably why you earlier said that objects were the natural
> solution.

Exactly, yes.

Although I believe that OOP is largely useless, I do use it on occasion in
OCaml. For example, my HLVM project uses an object to represent the state and
capabilities of the LLVM IR code emitter.

Hi Jon,
I could easily argue about the useless nature of ranting, but I could not argue about OO being useless.

Although I believe that OOP is largely useless, I do use it on occasion in
OCaml. For example, my HLVM project uses an object to represent the state and
capabilities of the LLVM IR code emitter.

I believe you would need some solid arguments to back this opinion. I am almost 100% an OO designer/developer (at least just before the advent of Scala and its wonderful object-functional nature) but I do not see a war anywhere. I like to synthesize than blame and tear apart. We are not soldiers of OOP, FP or whatever. At least we shouldn't be.
*Anything* that has achieved even a small fraction of results cannot be blamed as useless.
BRChristos.


--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

Christos,

Launch Firefox, if you're not already using it, and type Jon Harrop in your Google search field.  If you wait for a moment, you should see the word 'troll' appear in the autosuggestions.  He does have some very good points, and is hard to discount completely, but it's not worth worrying too much about what he says.

I tried to give him the benefit of the doubt, until I found myself attacked by him in comments on his blog.  He refuted my points on the grounds that I was irrelevant because I was in academia.  When I informed him that I work outside of academia he deleted mine and his comments.

Oops, I seem to have clicked Reply to all.

2009/4/30 Christos KK Loverdos <loverdos [at] gmail [dot] com>

Hi Jon,
I could easily argue about the useless nature of ranting, but I could not argue about OO being useless.

Although I believe that OOP is largely useless, I do use it on occasion in
OCaml. For example, my HLVM project uses an object to represent the state and
capabilities of the LLVM IR code emitter.

I believe you would need some solid arguments to back this opinion. I am almost 100% an OO designer/developer (at least just before the advent of Scala and its wonderful object-functional nature) but I do not see a war anywhere. I like to synthesize than blame and tear apart. We are not soldiers of OOP, FP or whatever. At least we shouldn't be.
*Anything* that has achieved even a small fraction of results cannot be blamed as useless.
BRChristos.


--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

Hi Jon,

It seems that you are arguing a point that you want to argue, instead
of the one that was originally presented:

On Apr 30, 2009, at 10:32 AM, Jon Harrop wrote:

> In response to FFT's question about OCaml, Martin Odersky made a
> variety of
> statements about "ML" in his post at the beginning of this thread. I
> disagree
> with Martin's response because he neglected OCaml which is not only
> the gold
> standard among MLs and an advanced functional+OOP language but was the
> specific subject of FFT's original question. This is not the first
> time
> Martin has glossed over his major competitor when comparing languages.

I don't think that FFT's original question was about OCaml per se, but
s/he rather used OCaml as an example since it is, in fact, a well
known respected OO/FP hybrid language, and s/he further claimed that
those who use OCaml "see OOP as a largely failed experiment":

On Apr 27, 2009, at 9:03 PM, FFT wrote:

> As a counter-argument, I know that in OCaml, OOP is
> available (the "O" part), but is widely viewed as a failed experiment
> (not "failed" in a pejorative sense, but even its creator does not use
> the objective extensions).

The implication here being that while OOP is available in OCaml,
people who use OCaml seem to stick to its FP aspects (I have no idea
whether this is true or not). Paraphrasing FFT even further:
apparently even the person who put the "O" in OCaml tends to just
stick to the "Caml", if you catch my meaning.

So it seems FFT is looking for some reason to use the OO part of an OO/
FP language.

Martin presented a situation where using OOP was a natural fit, and
you apparently agreed:

2009/4/30 Jon Harrop :

> I'll try to write a non-OOP version but I think objects are the
> natural
> solution here.

No one ever made the assertion that an equally elegant result could
not be achieved in OCaml. I do think the insinuation was made that
when you are restricted to a pure FP language, the sol'ns are perhaps
less natural.

So the example presented was one that directly addressed FFT's
original question which was why anyone would use OOP instead of pure
FP: indeed it's the very subject of this thread.

FFT never asked why scala was better than ocaml, which seems to be the
topic you'd like to argue.

-steve

I'm a fairly experienced OO programmer. And I've been trying on and off for a couple of years get my head around FP. So I have sort of the oposite question of the rest of this thread because I've had a lot of trouble understanding how large systems are architected in FP; especially data centric systems.

So I'm curious if people could point me to any resources that discuss FP systems design? Something like "Design Patterns" for FP maybe?

I'm not trying to say at all that FP cannot do it. I just don't really understand it so I want to find out where I can educate my self.

Also examples would be interesting. Are there any exemplary large open source pure FP systems out there that I should look at?

Thanks.
-Arthur


On Thu, Apr 30, 2009 at 11:33 AM, Steve Lianoglou <mailinglist [dot] honeypot [at] gmail [dot] com> wrote:

Hi Jon,

It seems that you are arguing a point that you want to argue, instead of the one that was originally presented:

On Apr 30, 2009, at 10:32 AM, Jon Harrop wrote:

In response to FFT's question about OCaml, Martin Odersky made a variety of
statements about "ML" in his post at the beginning of this thread. I disagree
with Martin's response because he neglected OCaml which is not only the gold
standard among MLs and an advanced functional+OOP language but was the
specific subject of FFT's original question. This is not the first time
Martin has glossed over his major competitor when comparing languages.

I don't think that FFT's original question was about OCaml per se, but s/he rather used OCaml as an example since it is, in fact, a well known respected OO/FP hybrid language, and s/he further claimed that those who use OCaml "see OOP as a largely failed experiment":

On Apr 27, 2009, at 9:03 PM, FFT wrote:

As a counter-argument, I know that in OCaml, OOP is
available (the "O" part), but is widely viewed as a failed experiment
(not "failed" in a pejorative sense, but even its creator does not use
the objective extensions).

The implication here being that while OOP is available in OCaml, people who use OCaml seem to stick to its FP aspects (I have no idea whether this is true or not). Paraphrasing FFT even further: apparently even the person who put the "O" in OCaml tends to just stick to the "Caml", if you catch my meaning.

So it seems FFT is looking for some reason to use the OO part of an OO/FP language.

Martin presented a situation where using OOP was a natural fit, and you apparently agreed:

2009/4/30 Jon Harrop <jon [at] ffconsultancy [dot] com>:

I'll try to write a non-OOP version but I think objects are the natural
solution here.

No one ever made the assertion that an equally elegant result could not be achieved in OCaml. I do think the insinuation was made that when you are restricted to a pure FP language, the sol'ns are perhaps less natural.

So the example presented was one that directly addressed FFT's original question which was why anyone would use OOP instead of pure FP: indeed it's the very subject of this thread.

FFT never asked why scala was better than ocaml, which seems to be the topic you'd like to argue.

-steve

In the same boat here.    I've found that Real World Haskell http://book.realworldhaskell.org/read/ has helped my Scala.
From: Arthur Peters [mailto:arthur [dot] peters [at] gmail [dot] com]
Sent: Thursday, April 30, 2009 11:53 AM
To: Steve Lianoglou
Cc: scala [at] listes [dot] epfl [dot] ch
Subject: Re: [scala] usefulness of OOP

I'm a fairly experienced OO programmer. And I've been trying on and off for a couple of years get my head around FP. So I have sort of the oposite question of the rest of this thread because I've had a lot of trouble understanding how large systems are architected in FP; especially data centric systems.

So I'm curious if people could point me to any resources that discuss FP systems design? Something like "Design Patterns" for FP maybe?

I'm not trying to say at all that FP cannot do it. I just don't really understand it so I want to find out where I can educate my self.

Also examples would be interesting. Are there any exemplary large open source pure FP systems out there that I should look at?

Thanks.
-Arthur


On Thu, Apr 30, 2009 at 11:33 AM, Steve Lianoglou <mailinglist [dot] honeypot [at] gmail [dot] com> wrote:

Hi Jon,

It seems that you are arguing a point that you want to argue, instead of the one that was originally presented:

On Apr 30, 2009, at 10:32 AM, Jon Harrop wrote:

In response to FFT's question about OCaml, Martin Odersky made a variety of
statements about "ML" in his post at the beginning of this thread. I disagree
with Martin's response because he neglected OCaml which is not only the gold
standard among MLs and an advanced functional+OOP language but was the
specific subject of FFT's original question. This is not the first time
Martin has glossed over his major competitor when comparing languages.

I don't think that FFT's original question was about OCaml per se, but s/he rather used OCaml as an example since it is, in fact, a well known respected OO/FP hybrid language, and s/he further claimed that those who use OCaml "see OOP as a largely failed experiment":

On Apr 27, 2009, at 9:03 PM, FFT wrote:

As a counter-argument, I know that in OCaml, OOP is
available (the "O" part), but is widely viewed as a failed experiment
(not "failed" in a pejorative sense, but even its creator does not use
the objective extensions).

The implication here being that while OOP is available in OCaml, people who use OCaml seem to stick to its FP aspects (I have no idea whether this is true or not). Paraphrasing FFT even further: apparently even the person who put the "O" in OCaml tends to just stick to the "Caml", if you catch my meaning.

So it seems FFT is looking for some reason to use the OO part of an OO/FP language.

Martin presented a situation where using OOP was a natural fit, and you apparently agreed:

2009/4/30 Jon Harrop <jon [at] ffconsultancy [dot] com>:

I'll try to write a non-OOP version but I think objects are the natural
solution here.

No one ever made the assertion that an equally elegant result could not be achieved in OCaml. I do think the insinuation was made that when you are restricted to a pure FP language, the sol'ns are perhaps less natural.

So the example presented was one that directly addressed FFT's original question which was why anyone would use OOP instead of pure FP: indeed it's the very subject of this thread.

FFT never asked why scala was better than ocaml, which seems to be the topic you'd like to argue.

-steve

PLEASE READ: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please delete it and all copies from your system, destroy any hard copies and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Nomura Holding America Inc., Nomura Securities International, Inc, and their respective subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state the views of such entity. Unless otherwise stated, any pricing information in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.

On Thu, Apr 30, 2009 at 8:04 AM, Christos KK Loverdos <loverdos [at] gmail [dot] com> wrote:

Hi Jon,
I could easily argue about the useless nature of ranting, but I could not argue about OO being useless.

Although I believe that OOP is largely useless, I do use it on occasion in
OCaml. For example, my HLVM project uses an object to represent the state and
capabilities of the LLVM IR code emitter.

I believe you would need some solid arguments to back this opinion. I am almost 100% an OO designer/developer (at least just before the advent of Scala and its wonderful object-functional nature) but I do not see a war anywhere. I like to synthesize than blame and tear apart. We are not soldiers of OOP, FP or whatever. At least we shouldn't be.

Dude... I am so looking forward to your book!  I totally agree with you and I am looking forward to your perspective on Scala... and I fully expect to learn a lot of new things by basking in your perspective on the language and the OO/FP blend.  

*Anything* that has achieved even a small fraction of results cannot be blamed as useless.
BRChristos.


--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Thursday April 30 2009, Frohnhofer, James wrote:
> In the same boat here.
>
> I've found that Real World Haskell
> http://book.realworldhaskell.org/read/ has helped my Scala.

I see this is licensed under Creative Commons, so I'm wondering if
anyone has produced a PDF version of these HTML pages. I searched a bit
and could not find any.

If anyone is aware of such a thing, I'd love to get a pointer.

Randall Schulz

Are there any exemplary large open source pure OO systems out there that I should look at?

I don't think there are many exemplary large systems, at least of those that you'd normally think of as a single system.  Open source FP projects tend not to be large (other than compilers), not least because functional programmers tend to write smaller units.  E.g., xmonad is an order of magnitude smaller than some other window managers with similar functionality.

You might get some truck out of looking at HappStack or darcs.

You are more likely to find large mixed-paradigm projects containing varying levels of functional code, I think.

2009/4/30 Arthur Peters <arthur [dot] peters [at] gmail [dot] com>

I'm a fairly experienced OO programmer. And I've been trying on and off for a couple of years get my head around FP. So I have sort of the oposite question of the rest of this thread because I've had a lot of trouble understanding how large systems are architected in FP; especially data centric systems.

So I'm curious if people could point me to any resources that discuss FP systems design? Something like "Design Patterns" for FP maybe?

I'm not trying to say at all that FP cannot do it. I just don't really understand it so I want to find out where I can educate my self.

Also examples would be interesting. Are there any exemplary large open source pure FP systems out there that I should look at?

Thanks.
-Arthur


On Thu, Apr 30, 2009 at 11:33 AM, Steve Lianoglou <mailinglist [dot] honeypot [at] gmail [dot] com> wrote:

Hi Jon,

It seems that you are arguing a point that you want to argue, instead of the one that was originally presented:

On Apr 30, 2009, at 10:32 AM, Jon Harrop wrote:

In response to FFT's question about OCaml, Martin Odersky made a variety of
statements about "ML" in his post at the beginning of this thread. I disagree
with Martin's response because he neglected OCaml which is not only the gold
standard among MLs and an advanced functional+OOP language but was the
specific subject of FFT's original question. This is not the first time
Martin has glossed over his major competitor when comparing languages.

I don't think that FFT's original question was about OCaml per se, but s/he rather used OCaml as an example since it is, in fact, a well known respected OO/FP hybrid language, and s/he further claimed that those who use OCaml "see OOP as a largely failed experiment":

On Apr 27, 2009, at 9:03 PM, FFT wrote:

As a counter-argument, I know that in OCaml, OOP is
available (the "O" part), but is widely viewed as a failed experiment
(not "failed" in a pejorative sense, but even its creator does not use
the objective extensions).

The implication here being that while OOP is available in OCaml, people who use OCaml seem to stick to its FP aspects (I have no idea whether this is true or not). Paraphrasing FFT even further: apparently even the person who put the "O" in OCaml tends to just stick to the "Caml", if you catch my meaning.

So it seems FFT is looking for some reason to use the OO part of an OO/FP language.

Martin presented a situation where using OOP was a natural fit, and you apparently agreed:

2009/4/30 Jon Harrop <jon [at] ffconsultancy [dot] com>:

I'll try to write a non-OOP version but I think objects are the natural
solution here.

No one ever made the assertion that an equally elegant result could not be achieved in OCaml. I do think the insinuation was made that when you are restricted to a pure FP language, the sol'ns are perhaps less natural.

So the example presented was one that directly addressed FFT's original question which was why anyone would use OOP instead of pure FP: indeed it's the very subject of this thread.

FFT never asked why scala was better than ocaml, which seems to be the topic you'd like to argue.

-steve

>> If more "methods" were required then you could just use a record of
>> functions
>> to name them. OOP seems to be unnecessary because neither inheritance nor
>> OOP-style polymorphism are beneficial in this case.
> I've seen the phrase "object based programming" for this kind of usage.
> Much of the time "OOP" is mostly (or entirely) about building objects,
> not about inheritance.

Apologies if this comes across as beating a dead horse, I don't mean
it that way.

I think there is an interesting question of nuance here: when does
record-style become object-style? My personal off-the-cuff answer is
that if there is no mutable state then it is more just a record, and
less an object.

sincerely.

On Thu, Apr 30, 2009 at 6:24 AM, Jon Harrop wrote:
>  open List
>
>  let rec eval (apply, var as env) = function
>    | `Num i -> `Int i
>    | `Lambda body -> `Closure(apply body)
>    | `Var v -> var v
>    | `Apply(f, args) ->
>        match eval env f, map (eval env) args with
>        | `Closure f, args -> f args
>        | _ -> invalid_arg "Apply of non-function";;
>
>  let rec de_bruijn env =
>    (fun body args -> eval (de_bruijn (args::env)) body),
>    (fun (i, j) -> nth (nth env i) j)
>
>  module StringMap = Map.Make(String)
>
>  let rec named env =
>    (fun (xs, body) vs ->
>       eval (named(fold_right2 StringMap.add xs vs env)) body),
>    (fun s -> StringMap.find s env)

These definitions compile, but when I try to use them:

let get_int = function `Int x -> x | _ -> failwith "not int"

let x = get_int (eval de_bruijn (`Apply(`Lambda(`Var (0, 0)), [`Num 3])))
let y = get_int (eval named (`Apply(`Lambda(["x"], `Var "x"), [`Num 3])))

I get type errors. Am I using your code wrong, or is it basically
untypeable, which is what Martin seemed to say?

By the way, I'm very curious if polymorphic variants could be removed
as well here, or would you get a type error?

On Thu, Apr 30, 2009 at 11:31 AM, Raoul Duke <raould [at] gmail [dot] com> wrote:

I think there is an interesting question of nuance here: when does
record-style become object-style? My personal off-the-cuff answer is
that if there is no mutable state then it is more just a record, and
less an object.

When it implements one or more OO features, of which the textbook answer would be: encapsulation, inheritance, and polymorphism.

On Thu, Apr 30, 2009 at 11:15 AM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:

On Thursday April 30 2009, Frohnhofer, James wrote:
> In the same boat here.
>
> I've found that Real World Haskell
> http://book.realworldhaskell.org/read/ has helped my Scala.

I see this is licensed under Creative Commons, so I'm wondering if
anyone has produced a PDF version of these HTML pages. I searched a bit
and could not find any.

If anyone is aware of such a thing, I'd love to get a pointer.

http://www.google.com/search?as_epq=Real+World+Haskell&as_filetype=pdf

On Thursday April 30 2009, Nils Kilden-Pedersen wrote:
> On Thu, Apr 30, 2009 at 11:15 AM, Randall R Schulz
wrote:
> > On Thursday April 30 2009, Frohnhofer, James wrote:
> > > In the same boat here.
> > >
> > > I've found that Real World Haskell
> > > http://book.realworldhaskell.org/read/ has helped my Scala.
> >
> > I see this is licensed under Creative Commons, so I'm wondering if
> > anyone has produced a PDF version of these HTML pages. I searched a
> > bit and could not find any.
> >
> > If anyone is aware of such a thing, I'd love to get a pointer.
>
> http://www.google.com/search?as_epq=Real+World+Haskell&as_filetype=pdf

Outstanding! Thank you.

(It should have occurred to me to search with a file-type restriction.)

The first hit, [1], looks a lot like what I had started creating by
printing individual chapter's HTML page to PDF using Firefox 3's
built-in print-to-PDF file and then concatenating the PDFs. (I think I
like my font assignments better, though...)

[1] 

Randall Schulz

Brilliant.  I'd looked for that for a C# guy who was interested in Haskell, but failed.  Asking on #haskell didn't help either.  It'd be nicer without the comments, and with better formatting, but it's fine as is.

2009/4/30 Randall R Schulz <rschulz [at] sonic [dot] net>

On Thursday April 30 2009, Nils Kilden-Pedersen wrote:
> On Thu, Apr 30, 2009 at 11:15 AM, Randall R Schulz
<rschulz [at] sonic [dot] net>wrote:
> > On Thursday April 30 2009, Frohnhofer, James wrote:
> > > In the same boat here.
> > >
> > > I've found that Real World Haskell
> > > http://book.realworldhaskell.org/read/ has helped my Scala.
> >
> > I see this is licensed under Creative Commons, so I'm wondering if
> > anyone has produced a PDF version of these HTML pages. I searched a
> > bit and could not find any.
> >
> > If anyone is aware of such a thing, I'd love to get a pointer.
>
> http://www.google.com/search?as_epq=Real+World+Haskell&as_filetype=pdf

Outstanding! Thank you.

(It should have occurred to me to search with a file-type restriction.)

The first hit, [1], looks a lot like what I had started creating by
printing individual chapter's HTML page to PDF using Firefox 3's
built-in print-to-PDF file and then concatenating the PDFs. (I think I
like my font assignments better, though...)


[1] <http://fldit-www.cs.uni-dortmund.de/~peter/RealWorldHaskell.pdf>


Randall Schulz