usefulness of OOP

On Thursday 30 April 2009 16:04:25 Christos KK Loverdos wrote:
> I believe you would need some solid arguments to back this opinion.

When you offer programmers the choice of OOP or other paradigms they rarely
choose OOP. OCaml has demonstrated this.

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

I think it is confusing to bring FP into this. The alternatives to OOP
provided by languages like OCaml have nothing to do with FP.

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

Sure. When I said "largely useless" I meant that in the majority of cases
where I could use OOP I choose alternatives in practice. For example, I could
have used a class hierarchy to represent the type of an expression in this
interpreter.

Jon, I don't understand the logic of your arguments, or where you get your data.

On Thu, Apr 30, 2009 at 3:39 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Thursday 30 April 2009 16:04:25 Christos KK Loverdos wrote:
> I believe you would need some solid arguments to back this opinion.

When you offer programmers the choice of OOP or other paradigms they rarely
choose OOP. OCaml has demonstrated this.

WHO?  What other paradigms?  Please give us some data.
 

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

I think it is confusing to bring FP into this. The alternatives to OOP
provided by languages like OCaml have nothing to do with FP.

Wasn't FP vs. OOP the whole point of this discussion?  And does OCaml have nothing to do with FP?  What is your definition of OOP and FP?
 

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

Sure. When I said "largely useless" I meant that in the majority of cases
where I could use OOP I choose alternatives in practice. For example, I could
have used a class hierarchy to represent the type of an expression in this
interpreter.

The question here is, do most people choose alternatives in practice?

On Thursday 30 April 2009 16:52:32 Arthur Peters wrote:
> 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?

FP only affects code at small scales so your grail is a red herring.

You really want to study the language features that are used for large scale
structuring of programs instead of OOP. That means primarily module systems
and arguably also type classes. Note that module systems does not just mean
functors. There are many other features that I miss when using OOP-only
languages like F#, such as hierarchical encapsulation using nested module
signatures.

I've had a lot of trouble
> understanding how large systems are architected in FP; especially data
> centric systems.

Object Oriented is generally explain in terms of GUI programs (draw application with various shapes etc).   To see the contrast between FP and OO  you should see the FP solution to the graphical programming.   For that I highly recommend Paul Hudak's book  http://books.google.com/books?id=lQbth9j5j9oC&dq=paul+hudak+haskell+of+expression&printsec=frontcover&source=bn&hl=en&ei=nwv6SZj6IqPqsgPg5ujRAQ&sa=X&oi=book_result&ct=result&resnum=4
It talks about Haskell, but the "patterns" is applicable to Scala too. 

As an example, try to think about the code that is required to implement a Pong Application.  Shown here: http://haskell.org/soe/images/foo0035.avi

In Hudaks book this application is developed using functional approach in less than 20 lines of code.  

Daryoush




On Thu, Apr 30, 2009 at 8:52 AM, Arthur Peters <arthur.peters@gmail.com> wrote:

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.honeypot@gmail.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@ffconsultancy.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

On Thursday 30 April 2009 21:03:10 Josh Suereth wrote:
> On Thu, Apr 30, 2009 at 3:39 PM, Jon Harrop wrote:
> > On Thursday 30 April 2009 16:04:25 Christos KK Loverdos wrote:
> > > I believe you would need some solid arguments to back this opinion.
> >
> > When you offer programmers the choice of OOP or other paradigms they
> > rarely choose OOP. OCaml has demonstrated this.
>
> WHO? What other paradigms? Please give us some data.

OCaml provides other language features that overlap with OOP:

. Variant types can be used to replace sealed flat class hierarchies where
adding methods is more valuable than adding classes.

. Pattern matching replaces dispatch in OOP but handles a much more general
case (capable of dispatching over multiple non-object types and branches of
data structures at the same time and, in such cases, is asyptotically faster
than OO dispatch as well) and also provides exhaustiveness and redundancy
checking.

. Module systems allow code to be encapsulated gradually using nested module
signatures and functors allow modules to be parameterized over other modules,
which is great for rich data structures (see Okasaki).

. Polymorphic variants provide inferred open sum types.

> > I think it is confusing to bring FP into this. The alternatives to OOP
> > provided by languages like OCaml have nothing to do with FP.
>
> Wasn't FP vs. OOP the whole point of this discussion?

I don't believe so, no. Indeed, I do not even believe FP vs OOP makes sense
because they solve different problems.

> And does OCaml have nothing to do with FP?

OCaml is a functional language.

> What is your definition of OOP and FP?

For FP I use: has first-class lexical closures and preferably hard TCO.

For OOP: has objects with subtype polymorphism, inheritance and method
dispatch.

> > Sure. When I said "largely useless" I meant that in the majority of cases
> > where I could use OOP I choose alternatives in practice. For example, I
> > could
> > have used a class hierarchy to represent the type of an expression in
> > this interpreter.
>
> The question here is, do most people choose alternatives in practice?

Certainly in OCaml I think the answer is yes: the programmer can choose OOP
from a variety of solutions and, in practice, they rarely choose OOP. OCaml
is unusual in this respect and, consequently, a valuable source of
information in this context.

On Thursday 30 April 2009 18:06:39 FFT wrote:
> 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...

I changed the API a bit. Now you do:

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

and:

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

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

Yes, here is an implementation that uses only ordinary variants:

open List

type ('lambda, 'var) expr =
| Num of int
| Lambda of 'lambda
| Var of 'var
| Apply of ('lambda, 'var) expr * ('lambda, 'var) expr list

type value =
| Closure of (value list -> value)
| Int of int

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

type de_bruijn = DeBruijn of (de_bruijn, int * int) expr

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

type named = Named of string list * (named, string) expr

let rec named env =
(fun (Named(xs, body)) vs ->
eval (named(fold_left2 (fun s x v -> (x, v)::s) env xs vs)) body),
(fun s -> assoc s env)

The really elucidates the power of polymorphic variants if you compare with my
other code!

I still don't see what you mean by a "module system".  Aren't you just creating a very low-level object system and reclassifying it?

On Thursday 30 April 2009 21:46:06 Daryoush Mehrtash wrote:
> Object Oriented is generally explain in terms of GUI programs (draw
> application with various shapes etc). To see the contrast between FP and
> OO you should see the FP solution to the graphical programming. For that
> I highly recommend Paul Hudak's book
> http://books.google.com/books?id=lQbth9j5j9oC&dq=paul+hudak+haskell+of+expr
>ession&printsec=frontcover&source=bn&hl=en&ei=nwv6SZj6IqPqsgPg5ujRAQ&sa=X&oi
>=book_result&ct=result&resnum=4 It talks about Haskell, but the "patterns"
> is applicable to Scala too.
>
> As an example, try to think about the code that is required to implement a
> Pong Application. Shown here: http://haskell.org/soe/images/foo0035.avi
>
> In Hudaks book this application is developed using functional approach in
> less than 20 lines of code.

Are languages like Python not comparably terse when using OOP?

On Thursday 30 April 2009 22:07:24 Josh Suereth wrote:
> I still don't see what you mean by a "module system". Aren't you just
> creating a very low-level object system and reclassifying it?

The main discrepancy is that objects exist only at run-time whereas modules
can exist only at compile time. You might regard module systems as class
systems without objects but module systems can also support higher-order
modules.

For some excellent examples of modules in action, I recommend Chris Okasaki's
book "Purely functional data structures".

On Thursday 30 April 2009 18:56:40 Nils Kilden-Pedersen wrote:
> On Thu, Apr 30, 2009 at 11:31 AM, Raoul Duke 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.

You need a new textbook. ;-)

Encapsulation is provided by many different language features such as modules.

Polymorphism comes in at least four varieties and OOP is associated with only
one: subtype polymorphism. Parametric polymorphism (aka generics) are another
common form of polymorphism that is certainly not indicative of an object
system.

I'm not aware of inheritance being provide by other language features but, as
others have said, it is (probably not uncoincidentally!) a bad idea.

It is not so much about  tears-ness of the language.    The difference, IMHO, is in what the code is expressing.   In imperative programs your code implements the steps require to execute the program (in which OO would be a good way to organize your code).  In FP you are expressing the "what".  In this case the "what" of the game is few lines of code where as the "how" is much more involved.    Things like algebraic data type, and function types, etc.  make it easy/possible to express the "what". 

daryoush

On Thu, Apr 30, 2009 at 2:13 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Thursday 30 April 2009 21:46:06 Daryoush Mehrtash wrote:
> Object Oriented is generally explain in terms of GUI programs (draw
> application with various shapes etc).   To see the contrast between FP and
> OO  you should see the FP solution to the graphical programming.   For that
> I highly recommend Paul Hudak's book
> http://books.google.com/books?id=lQbth9j5j9oC&dq=paul+hudak+haskell+of+expr
>ession&printsec=frontcover&source=bn&hl=en&ei=nwv6SZj6IqPqsgPg5ujRAQ&sa=X&oi
>=book_result&ct=result&resnum=4 It talks about Haskell, but the "patterns"
> is applicable to Scala too.
>
> As an example, try to think about the code that is required to implement a
> Pong Application.  Shown here: http://haskell.org/soe/images/foo0035.avi
>
> In Hudaks book this application is developed using functional approach in
> less than 20 lines of code.

Are languages like Python not comparably terse when using OOP?

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

On Thu, Apr 30, 2009 at 2:12 PM, Jon Harrop wrote:

>  open List
>
>  type ('lambda, 'var) expr =
>    | Num of int
>    | Lambda of 'lambda
>    | Var of 'var
>    | Apply of ('lambda, 'var) expr * ('lambda, 'var) expr list
>
>  type value =
>    | Closure of (value list -> value)
>    | Int of int
>
>  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";;
>
>  type de_bruijn = DeBruijn of (de_bruijn, int * int) expr
>
>  let rec de_bruijn env =
>    (fun (DeBruijn body) args -> eval (de_bruijn (args::env)) body),
>    (fun (i, j) -> nth (nth env i) j)
>
>  type named = Named of string list * (named, string) expr
>
>  let rec named env =
>    (fun (Named(xs, body)) vs ->
>      eval (named(fold_left2 (fun s x v -> (x, v)::s) env xs vs)) body),
>    (fun s -> assoc s env)
>
> The really elucidates the power of polymorphic variants if you compare with my
> other code!
>

Thanks, this was great!

Personally, I like the second version more. The only real differences
are that you declare your types up-front, and I think it's good for
readability and correctness. Conciseness is important, but it's not
everything (and none of those compilation unit restrictions nonsense
now!)

In my humble opinion, this answers Martin's challenge nicely: straight
up ML, no "exotic" features like OO, polymorphic variants, functors,
type coercions, etc. Would be interesting to see a Scala version now,
to compare :-)

I suspect the ML programmers Martin talked about were too eager to use
modules, which can be excessively boilerplate-y and verbose.

I decided to rewrite your eval code in LOLCode to show you the beauty that is the best language ever invented:

O HAI LOLCode 1.3

   HOW IZ I evaluating YR expr AN YR env?
      expr, WTF?
      OMG expr IZ LIEK Num
            FOUND YR expr'Z value
      OMG expr IZ LIEK Lambda
           expr AS Closure IZ evaluating MKAY
           FOUND YR IT
      OMG expr IZ LIEK Var
           expr IZ lookupValue MKAY
           FOUND YR IT
      OMG expr IZ LIEK Apply
           HOW IZ I evaluatingLocal YR expr
                 I IZ evaluating YR expr AN YR env
                 FOUND YR IT
           IF U SAY SO
           expr'z args IZ morphinWif YR evaluatingLocal
           I IZ expr'z f YR IT
           FOUND YR IT
      OIC
           
   IF U SAY SO

KTHXBAI

I don't think it gets any better.  Any modern internet-saavy teenager should be able to intuitively understand what the code is performing, without question.  Long Live 1337-P


-Josh


On Thu, Apr 30, 2009 at 5:12 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Thursday 30 April 2009 18:06:39 FFT wrote:
> On Thu, Apr 30, 2009 at 6:24 AM, Jon Harrop <jon@ffconsultancy.com> 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...

I changed the API a bit. Now you do:

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

and:

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

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

Yes, here is an implementation that uses only ordinary variants:

 open List

 type ('lambda, 'var) expr =
   | Num of int
   | Lambda of 'lambda
   | Var of 'var
   | Apply of ('lambda, 'var) expr * ('lambda, 'var) expr list

 type value =
   | Closure of (value list -> value)
   | Int of int

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

 type de_bruijn = DeBruijn of (de_bruijn, int * int) expr

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

 type named = Named of string list * (named, string) expr

 let rec named env =
   (fun (Named(xs, body)) vs ->
     eval (named(fold_left2 (fun s x v -> (x, v)::s) env xs vs)) body),
   (fun s -> assoc s env)

The really elucidates the power of polymorphic variants if you compare with my
other code!

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

+1, imhumbleo.

On 4/30/09, Jon Harrop wrote:
> You need a new textbook. ;-)
>
> Encapsulation is provided by many different language features such as
> modules.
>
> Polymorphism comes in at least four varieties and OOP is associated with
> only
> one: subtype polymorphism. Parametric polymorphism (aka generics) are
> another
> common form of polymorphism that is certainly not indicative of an object
> system.
>
> I'm not aware of inheritance being provide by other language features but,
> as
> others have said, it is (probably not uncoincidentally!) a bad idea.
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
>

On 4/30/09, Josh Suereth wrote:
> I decided to rewrite your eval code in LOLCode to show you the beauty that
> is the best language ever invented:
> I don't think it gets any better. Any modern internet-saavy teenager should
> be able to intuitively understand what the code is performing, without
> question. Long Live 1337-P

Josh, I can't tell if you are just joking around, or if you are
actually being pissy about ML syntax. If it is the latter, than that
really seems narrow-minded. I hope that isn't the case.

sincerely.

On Thursday 30 April 2009 23:18:37 FFT wrote:
> Thanks, this was great!
>
> Personally, I like the second version more. The only real differences
> are that you declare your types up-front, and I think it's good for
> readability and correctness.

I disagree. Situations where the type declaration is half of the code, like
this, are ideal for polymorphic variants not only because they eliminate the
type declarations (making the code clearer) but also because they result in
more type inference which makes maintenence easier. This is exactly the same
advantage that HM type inference offers over explicit languages like Java
except polymorphic variants also allow the inference of sum types. I really
miss them in other FPLs.

There is essentially no effect on correctness: everything is still statically
typed. There is less to read but the type information is still fully
available in the IDE, thrown back from the compiler.

The main disadvantage of polymorphic variants, particularly for recursive sum
types such as these, is the obfuscation of error messages. However, I
actually found it harder to write the code with ordinary variants because I
had to work out which types required what type arguments and then found that
I had to add two new types for the sole purpose of working around
deficiencies in HM:

type de_bruijn = DeBruijn of (de_bruijn, int * int) expr
...
type named = Named of string list * (named, string) expr

Note that these are required for SML-like MLs but not in OCaml provided you
enable -rectypes. Polymorphic variants hiding that incidental complexity is
another of their advantages.

> Conciseness is important, but it's not everything (and none of those
> compilation unit restrictions nonsense now!)

The type problem you had originally occurs with many different types and was
not due to my use of these unique features of OCaml. The value restriction is
essentially the disadvantage of combining the imperative and purely
functional paradigms. However, in many years of OCaml coding it has been
irritating only once, in the context of parser combinators which were an
academic exercise anyway.

> In my humble opinion, this answers Martin's challenge nicely: straight
> up ML, no "exotic" features like OO, polymorphic variants, functors,
> type coercions, etc. Would be interesting to see a Scala version now,
> to compare :-)

While I would have agreed if that had been the comparison, I see no merit in
comparing Scala with MLs that are two decades out of date. OCaml is now 13
years old but, IMHO, still well worth the comparison.

> I suspect the ML programmers Martin talked about were too eager to use
> modules, which can be excessively boilerplate-y and verbose.

Functors have their uses but, like objects and type classes, they solve only
very specific kinds of problems well. That's why I think it is so important
to be multiparadigm. Unfortunately, not only do no languages combine all of
these features yet, I do not believe anyone is even working on one.

Anytime I mention LOLCode, it's in jest.  I actually like OCaml the language, along with Scala. 

From what I understand of modules, they appear to be primitive objects that get compiled away.  A rose by any other name...

Similarly, I can take a Prototype-OO language that happens to support first-class functions and such, and generate similar code to OCaml.  You can make a langauge more suitable to a particular design goal, but sometimes that requires you to bend the language, or add strange features to it.  Scala, AFAICT, sits right between the two ideas.  It is trying to take the best of both worlds, and merge ideas that are compatable.  OCaml, starting from FP, is just taking on useful features of OO that are lacking in "pure" FP.  These are of course different design decisions made.   Each makes sense given the history of the language.  The original argument was about pure FP vs. pure OO, however I beleive Mr. Harrop is blurring this distinction.

I believe he's limiting his definition of OO to things which include *all* of objects with subtype polymorphism, method dispatch and inheritance.  Perhaps this is true of mainstream OO languages.  However I'm a big fan of Prototype Object Orientated languages (e.g. javascript), and these seem to me to still be OO, but don't quite have the same 3 features.   He's also including features in FP (or Caml) that have a more object-oriented feel.  I don't care if it's completely in the compiler, it's still an OO style methodology.  I remember using compile-time polymorphism in C++ using templates(generics).

I agree with some of the earlier points made in this thread.  FP is very useful (and very much missed [or painful] when coding in Java).  OO is useful (and in-fact succint) in various situations.

LOLCode, being a prototype OO language seemed like a good, completely off-topic, idea to throw into the discussion.  Esepcially since it brings in a completely (almost) class-less OO, with enough of the "in-between FP and OO" features to demonstrate usefullness on a problem. 

For future reference, if I mention kittens or LOLCode, I'm usually being facetious or sarcastic.

-Josh


On Thu, Apr 30, 2009 at 7:16 PM, Raoul Duke <raould@gmail.com> wrote:

On 4/30/09, Josh Suereth <joshua.suereth@gmail.com> wrote:
> I decided to rewrite your eval code in LOLCode to show you the beauty that
> is the best language ever invented:
> I don't think it gets any better.  Any modern internet-saavy teenager should
> be able to intuitively understand what the code is performing, without
> question.  Long Live 1337-P

Josh, I can't tell if you are just joking around, or if you are
actually being pissy about ML syntax. If it is the latter, than that
really seems narrow-minded. I hope that isn't the case.

sincerely.

On Friday 01 May 2009 00:41:50 Josh Suereth wrote:
> Similarly, I can take a Prototype-OO language that happens to support
> first-class functions and such, and generate similar code to OCaml...

My point was that you need more features than that to generate code similar to
my OCaml and, in particular, that the extra features you need (like
polymorphic variants) have nothing to do with FP. Hence I do not think it
makes sense to discuss FP vs OOP in this context.

To put that another way: the differences between the FP solutions is greater
than the difference between FP and OOP here.

> I believe he's limiting his definition of OO to things which include *all*
> of objects with subtype polymorphism, method dispatch and inheritance.
> Perhaps this is true of mainstream OO languages. However I'm a big fan of
> Prototype Object Orientated languages (e.g. javascript), and these seem to
> me to still be OO, but don't quite have the same 3 features.

Can you elaborate on this? I thought they had exactly those features.

> He's also including features in FP (or Caml) that have a more
> object-oriented feel. I don't care if it's completely in the compiler, it's
> still an OO style methodology.

Well, if you include everything in your definition of OOP then there is
no "vs" to discuss. :-)

On Thu, Apr 30, 2009 at 4:48 PM, Jon Harrop wrote:

> Functors have their uses but, like objects and type classes, they solve only
> very specific kinds of problems well. That's why I think it is so important
> to be multiparadigm.

I think there should be a limited number of powerful paradigms that
play well together. Hypothetically speaking, if OOP is not a useful
paradigm, when you already have higher-order functions and algebraic
data types, it should not be stuffed into a language (This discussion
is failing to demonstrate the usefulness of OOP, but that doesn't mean
it's not useful, perhaps with mutable state, including GUIs?)

> Unfortunately, not only do no languages combine all of
> these features yet, I do not believe anyone is even working on one.

FWIW, Scala is meant to integrate functions, objects, type classes and
modules into one powerful paradigm. (My Scala knowledge comes almost
entirely from the Google Tech Talk video, so take it with a grain of
salt)

Speaking of the video (this was asked in one of the questions), I'm a
little uneasy about Scala keeping the original constructor arguments
around indefinitely for pattern matching. Doesn't this double the
memory consumption in many cases?

On Friday 01 May 2009 03:03:42 FFT wrote:
> On Thu, Apr 30, 2009 at 4:48 PM, Jon Harrop wrote:
> > Functors have their uses but, like objects and type classes, they solve
> > only very specific kinds of problems well. That's why I think it is so
> > important to be multiparadigm.
>
> I think there should be a limited number of powerful paradigms that
> play well together.

In what sense do these features conflict? In fact, are they not working
together quite harmoniously in the example programs I gave?

> Hypothetically speaking, if OOP is not a useful
> paradigm, when you already have higher-order functions and algebraic
> data types, it should not be stuffed into a language (This discussion
> is failing to demonstrate the usefulness of OOP,

Impossible to say given the lack of code in any other languages. :-)

> but that doesn't mean
> it's not useful, perhaps with mutable state, including GUIs?)

I don't think mutable state will make a difference but there is always the
possibility of more compelling examples. However, even WPF in .NET 3.5 is now
moving toward functional alternatives so I'm not even sure GUIs are a
compelling example for OOP any more.

> > Unfortunately, not only do no languages combine all of
> > these features yet, I do not believe anyone is even working on one.
>
> FWIW, Scala is meant to integrate functions, objects, type classes and
> modules into one powerful paradigm. (My Scala knowledge comes almost
> entirely from the Google Tech Talk video, so take it with a grain of
> salt)

Scala is much closer to OOP than to FP and really sits next to C#, e.g. in
terms of tail calls and type inference. There are lots of radical features in
Scala, of course, but they are all on the OOP side.

On Thu, Apr 30, 2009 at 4:36 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

You need a new textbook. ;-)

Encapsulation is provided by many different language features such as modules.

Polymorphism comes in at least four varieties and OOP is associated with only
one: subtype polymorphism. Parametric polymorphism (aka generics) are another
common form of polymorphism that is certainly not indicative of an object
system.

I'm not aware of inheritance being provide by other language features but, as
others have said, it is (probably not uncoincidentally!) a bad idea.

You are inverting what I wrote. I didn't state that OO languages exclusively have those features, nor that other languages couldn't have similar features. I merely stated that the textbook answer for when a language is considered OO is when it incorporates at least those 3 features.

>> You need a new textbook. ;-)

> You are inverting what I wrote. I didn't state that OO languages exclusively
> have those features, nor that other languages couldn't have similar
> features. I merely stated that the textbook answer for when a language is
> considered OO is when it incorporates at least those 3 features.

not trying to be obnoxious, but i believe you wrote "one of" not "at
least those 3" originally, which is i think a significant difference.

sincerely.

On Thu, Apr 30, 2009 at 10:53 PM, Raoul Duke <raould@gmail.com> wrote:

not trying to be obnoxious, but i believe you wrote "one of" not "at
least those 3" originally, which is i think a significant difference.

That was in response to your question/statement:

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

Unless I misunderstood, your question was not on what defines an OO language. My answer was when using one or more of the OO features, it becomes more object-style than record-style. It was an off-the-cuff question to which both you and I provided an off-the-cuff answer.

hi,

> Unless I misunderstood, your question was not on what defines an OO
> language. My answer was when using one or more of the OO features, it
> becomes more object-style than record-style. It was an off-the-cuff question
> to which both you and I provided an off-the-cuff answer.

sorry to be slow --

i think it has been confusing because i think both your notes were
related to my original question, and your original answer now sounds
like it conflated your own opinion (which is that something is OO if
it uses at least one of) vs. what you expect textbooks say (where OO
has to use all of).

so i think i now understand that your personal opinion differs from
what you'd expect a textbook to say.

and that OO features can't exist elsewhere.

thanks :-)
sincerely.

When I landed at University, in 1993, the Web had just began. What great moments. (I leave aside the note that for the first couple of semesters we did not even have a free email account from our Department of Informatics)
We are probably witnessing an important evolutionary step in PL right now. It is most interesting to be part of it. More steps will follow, that's for sure. I think what is important for anyone is try to do the best given one's knowledge, experience, wishes, everyday-life constraints.
I recently watched some StarTrek movies (again). In their world, humanity's goal is continuous improvement. That's the spirit.
Christos

On Thu, Apr 30, 2009 at 18:59, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Thu, Apr 30, 2009 at 8:04 AM, Christos KK Loverdos <loverdos@gmail.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

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

On Fri, May 1, 2009 at 12:18 AM, FFT wrote:
> On Thu, Apr 30, 2009 at 2:12 PM, Jon Harrop wrote:
>
>>  open List
>>
>>  type ('lambda, 'var) expr =
>>    | Num of int
>>    | Lambda of 'lambda
>>    | Var of 'var
>>    | Apply of ('lambda, 'var) expr * ('lambda, 'var) expr list
>>
>>  type value =
>>    | Closure of (value list -> value)
>>    | Int of int
>>
>>  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";;
>>
>>  type de_bruijn = DeBruijn of (de_bruijn, int * int) expr
>>
>>  let rec de_bruijn env =
>>    (fun (DeBruijn body) args -> eval (de_bruijn (args::env)) body),
>>    (fun (i, j) -> nth (nth env i) j)
>>
>>  type named = Named of string list * (named, string) expr
>>
>>  let rec named env =
>>    (fun (Named(xs, body)) vs ->
>>      eval (named(fold_left2 (fun s x v -> (x, v)::s) env xs vs)) body),
>>    (fun s -> assoc s env)
>>
>> The really elucidates the power of polymorphic variants if you compare with my
>> other code!
>>
>
> Thanks, this was great!
>
> Personally, I like the second version more. The only real differences
> are that you declare your types up-front, and I think it's good for
> readability and correctness. Conciseness is important, but it's not
> everything (and none of those compilation unit restrictions nonsense
> now!)
>
> In my humble opinion, this answers Martin's challenge nicely: straight
> up ML, no "exotic" features like OO, polymorphic variants, functors,
> type coercions, etc. Would be interesting to see a Scala version now,
> to compare :-)
>
> I suspect the ML programmers Martin talked about were too eager to use
> modules, which can be excessively boilerplate-y and verbose.
>
I do not claim to be an expert in ML things, but I guess there was a
reason for using modules. The point is to have a reusable interpreter
component. That implies that the abstract interpreter framework and
its instantiations have to live in different source units. And I think
it would also imply that you have to make the types explicit at the
interface. How else would you document the contract between a the
framework and its instances?

Cheers

On Thu, Apr 30, 2009 at 9:03 PM, FFT <fft1976@gmail.com> wrote:

Speaking of the video (this was asked in one of the questions), I'm a
little uneasy about Scala keeping the original constructor arguments
around indefinitely for pattern matching. Doesn't this double the
memory consumption in many cases?

Scala uses case classes for pattern matching, which by default are immutable, so the "original" constructor arguments should never change.
I'm not sure how case classes behave if the constructor args are made variable, but I don't see how "memory consumption" would double, since we're dealing with references to objects, not clones of them.

On Thu, Apr 30, 2009 at 07:03:42PM -0700, FFT wrote:

>Speaking of the video (this was asked in one of the questions), I'm a
>little uneasy about Scala keeping the original constructor arguments
>around indefinitely for pattern matching. Doesn't this double the
>memory consumption in many cases?

It doesn't if nobody can reference them. Making a case class makes
them visible, so they have to be kept around, but if they are private,
and not used otherwise outside of the construction of the object, they
don't take up fields.

David

On Friday May 1 2009, David Brown wrote:
> On Thu, Apr 30, 2009 at 07:03:42PM -0700, FFT wrote:
> >Speaking of the video (this was asked in one of the questions), I'm
> > a little uneasy about Scala keeping the original constructor
> > arguments around indefinitely for pattern matching. Doesn't this
> > double the memory consumption in many cases?
>
> It doesn't if nobody can reference them. Making a case class makes
> them visible, so they have to be kept around, but if they are
> private, and not used otherwise outside of the construction of the
> object, they don't take up fields.

Except when they do.

Check out this thread for all the gory details:

> David

Randall Schulz

On Friday 01 May 2009 10:16:28 martin odersky wrote:
> I do not claim to be an expert in ML things, but I guess there was a
> reason for using modules. The point is to have a reusable interpreter
> component. That implies that the abstract interpreter framework and
> its instantiations have to live in different source units. And I think
> it would also imply that you have to make the types explicit at the
> interface. How else would you document the contract between a the
> framework and its instances?

In the last implementation I gave, the abstract interpreter framework is given
by this part of the code:

open List

type ('lambda, 'var) expr =
| Num of int
| Lambda of 'lambda
| Var of 'var
| Apply of ('lambda, 'var) expr * ('lambda, 'var) expr list

type value =
| Closure of (value list -> value)
| Int of int

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"

Moreover, that uses only mundane features found in all of OCaml, F#, SML,
Haskell and Scala so it should be trivial to port. The contract is the
signature.

Consequently, I do not understand why anyone pulled in features like functors
and type classes.

On Fri, May 1, 2009 at 2:16 AM, martin odersky wrote:
> I do not claim to be an expert in ML things,

Don't worry, this has already been "pointed out" on caml-list.

[If I were planning to write a Scala book, I'd sure as hell wouldn't
try to insult hte father of the language, but that's just me. Jon's
charm is that he tells you like it is, that's why I love his prose]

> but I guess there was a
> reason for using modules. The point is to have a reusable interpreter
> component. That implies that the abstract interpreter framework and
> its instantiations have to live in different source units.

No problemo, at least with the last version (without backquotes)

> And I think
> it would also imply that you have to make the types explicit at the
> interface. How else would you document the contract between a the
> framework and its instances?

camlc -i yoursource.ml

this generates the "interface", if you are too lazy to write one your
self, but for some reason want it (if you are really lazy, just don't
write it and don't generate it)

I'd really like for the OOP die-hards to come up with some situations
where OOP (in Scala especially) is much better than plain FP, but I'm
slowly getting disappointed.

In other words, if I don't need JVM and know OCaml already, is there
any reason to want to learn Scala?

[kthx]

P.S. The superiority of LOLCode to all other languages is well known,
but I'm too old to use it, damn it!

I am still not satisfied.

open List

type ('lambda, 'var) expr =
| Num of int
| Lambda of 'lambda
| Var of 'var
| Apply of ('lambda, 'var) expr * ('lambda, 'var) expr list

type value =
| Closure of (value list -> value)
| Int of int

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

What is the signature of apply and of env? In a sense you have used
Hindley/Milner type inference to get open recursion. It's a clever
trick, but I have my doubts it will scale. At some points you will
have to introduce component structures and to me it looks like in
Ocaml these are either classes or functors.

> In other words, if I don't need JVM and know OCaml already, is there
> any reason to want to learn Scala?
>
That depends wholly on you and your taste. I would not want to argue
with you. OCaml is a fine language; we do not need to try to convince
fellow functional programmers to switch their tools. The pool of
imperative Java/C/C# programmers is large enough to fish in for
everybody :-)

Cheers

On Saturday 02 May 2009 08:32:29 martin odersky wrote:
> I am still not satisfied.
>
> open List
>
> type ('lambda, 'var) expr =
>
> | Num of int
> | Lambda of 'lambda
> | Var of 'var
> | Apply of ('lambda, 'var) expr * ('lambda, 'var) expr list
>
> type value =
>
> | Closure of (value list -> value)
> | Int of int
>
> 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-functio
>
> What is the signature of apply and of env?

You can run the program through "ocamlc -i" to autogenerate a module
signature:

type ('a, 'b) expr =
Num of int
| Lambda of 'a
| Var of 'b
| Apply of ('a, 'b) expr * ('a, 'b) expr list

type value = Closure of (value list -> value) | Int of int

val eval :
('a -> value list -> value) * ('b -> value) -> ('a, 'b) expr -> value

The first argument to "eval" is "env" so the signatures of "apply" and "var"
are the components of the type of "env" which are:

val apply : 'a -> value list -> value
val var : 'b -> value

where the same 'a and 'b appear in the ('a, 'b) expr type.

> In a sense you have used
> Hindley/Milner type inference to get open recursion. It's a clever
> trick, but I have my doubts it will scale.

This trick, known as "untying the recursive knot", is widely used in OCaml.
The most common practical application is breaking apart recursive definitions
by parameterizing them over each other in order to place them in separate
compilation units or assemblies. This technique is described in F# for
Scientists (page 50) and, in more detail, in the following OCaml Journal
article:

http://ocamlnews.blogspot.com/2008/06/tricks-with-recursion-knots-module...

Note that untying the recursive knot typically breaks apart both type and
function recursions simultaneously. The latter will be problematic in Scala
because it turns tail calls to statically known functions (e.g.
self-recursion) into tail calls to statically unknown functions and,
consequently, will introduce stack space leaks in the absence of TCO (aka
proper tail recursion).

> At some points you will
> have to introduce component structures and to me it looks like in
> Ocaml these are either classes or functors.

Or records of functions.

In practice, I would probably choose classes. However, that is *not* because
OOP is useful in this context but because OCaml's implementation of objects
enables more inference. Using objects in OCaml allows me to avoid writing and
maintaining any types explicitly by hand.

In other words, I mainly use OCaml's objects as a replacement for records that
allows the record type to be inferred. Your example has arguably turned out
to be a better example of why more inference can be useful: writing the types
manually SML-style is seriously tedious and error prone, not least because
you need to add two extra types just to make HM happy.

I would still very much like to see the Scala equivalents of these programs!

On Sat, May 2, 2009 at 12:32 AM, martin odersky wrote:
> I am still not satisfied.

The example given here may be too small to really teach us anything
(even though a Scala version of it hasn't been posted yet). How do the
ML and OOP/fp approaches scale to programs of realistic size?

Here, I think another interesting thing to compare is the
implementations Scala and OCaml compilers (excluding runtimes).

Scala compiles only to JVM, and OCaml compiles to either its bytecode
or native code on various platforms. Aside from that, the work that
needs to be done is somewhat similar, and yet I believe OCaml source
code is many times smaller.

On Sunday 03 May 2009 23:24:30 FFT wrote:
> On Sat, May 2, 2009 at 12:32 AM, martin odersky
wrote:
> > I am still not satisfied.
>
> The example given here may be too small to really teach us anything
> (even though a Scala version of it hasn't been posted yet). How do the
> ML and OOP/fp approaches scale to programs of realistic size?

You would want to add more "members" to the environment object. That is
trivial in OOP. The vanilla ML would be converted to use a record instead of
a tuple. However, that would scale just as well.

> Here, I think another interesting thing to compare is the
> implementations Scala and OCaml compilers (excluding runtimes).
>
> Scala compiles only to JVM, and OCaml compiles to either its bytecode
> or native code on various platforms. Aside from that, the work that
> needs to be done is somewhat similar, and yet I believe OCaml source
> code is many times smaller.

I'm not sure you can draw any interesting conclusions from that because,
although the sizes of the code bases differs, the functionality in the
compilers in wildly different because the languages themselves are so
different.

I think it only makes sense to solve the same problem in different languages
and compare the solutions. However, I do not know of any capabilities from
OOP that are not trivial to reproduce in SML except for inheritance which is
considered bad style. OOP in OCaml offers more type inference but I think
that is unique to OCaml and, for example, is not provided by Scala.

Any ideas?

Jon, et al,

i've finally put together a 1st draft response. i've still got a lot of debugging to do, but the solution is end-to-end.

• there is a parser and evaluator hosted inside a lift-based web-container
• the parser is built using BNFC and can target Java/C#/OCaml/Haskell/F#/...
• the parser comes with visitor pattern support
• the evaluator is built in a two-level type style and demonstrates that the only OO you need is just enough to make Scala happy -- the abstractions are all FP-based
  

As i said, this is very much a draft and the code falls over most of the time. But, at this point, it's really a pedagogical device and framework for hosting and evaluating different solutions.

Again, one the main reasons i see for using Scala is it's seamless interop with Java. The OCaml solution is intriguing (though ther are some strangenesses in it that i've yet to grok, like why the lambda terms seem to have no body), but i would like to see that solution hosted in this manner.

As of two years ago when i was evaluating various Language+Platform options, OCaml had no stable web framework that could compare to Lift -- which is still very nascent. If that has changed, i'd love to hear about it. A similar situation holds for Haskell, although i'm still keeping my eye on HAppS. Beyond this, there is the huge and ever-growing Java open source base. To get something of even this toy quality on any other platform is hugely time-consuming, in my experience.

Again, as an example, if i wanted to add a DB backend to this app, it is trivial to

• auto-generate an XML schema from the bnf
• wire-in BDBXML
• store and retrieve code-model expressions from an XML database

or

• auto-generate an SQL schema (from the XML schema generated from the BNF)
• wire in JPA
• store and retrieve code-model expressions from a relational database
  

Literally, this app could have this capability in about 2 hours. In my experience it has taken me 2 orders of magnitude to do the same for other Language+Platform configurations.

Best wishes,

--greg


On Sun, May 3, 2009 at 3:55 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Sunday 03 May 2009 23:24:30 FFT wrote:
> On Sat, May 2, 2009 at 12:32 AM, martin odersky <martin.odersky@epfl.ch>
wrote:
> > I am still not satisfied.
>
> The example given here may be too small to really teach us anything
> (even though a Scala version of it hasn't been posted yet). How do the
> ML and OOP/fp approaches scale to programs of realistic size?

You would want to add more "members" to the environment object. That is
trivial in OOP. The vanilla ML would be converted to use a record instead of
a tuple. However, that would scale just as well.

> Here, I think another interesting thing to compare is the
> implementations Scala and OCaml compilers (excluding runtimes).
>
> Scala compiles only to JVM, and OCaml compiles to either its bytecode
> or native code on various platforms. Aside from that, the work that
> needs to be done is somewhat similar, and yet I believe OCaml source
> code is many times smaller.

I'm not sure you can draw any interesting conclusions from that because,
although the sizes of the code bases differs, the functionality in the
compilers in wildly different because the languages themselves are so
different.

I think it only makes sense to solve the same problem in different languages
and compare the solutions. However, I do not know of any capabilities from
OOP that are not trivial to reproduce in SML except for inheritance which is
considered bad style. OOP in OCaml offers more type inference but I think
that is unique to OCaml and, for example, is not provided by Scala.

Any ideas?

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

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

+1 206.650.3740

http://biosimilarity.blogspot.com

All,

i should have mentioned:

• the abstract syntax used for evaluation is here
• the evaluation strategy pattern and instantiations over different env/var types is here
• the concrete syntax is here
• a brain-dead compilation strategy taking concrete syntax to abstract syntax + evaluation strategy is here
  

Some of my take-aways from this exercise include the following.

• the aim of the design activity almost entirely determines the meaning of "scalable" in scalable abstractions
• If my aim is to build a standalone solution to a programming puzzle, then certain kinds of notions of compositions are clear winners. The two-level type analysis of the problem essentially employs a category-theoretic framework that has known good compositional properties.
• If my aim is to build an application that interops with other applications and increases its value and the value of other applications by virtue of its interaction in an ecosystem of software solutions, then scalable notions of composition are almost completely dominated by the incumbent means of composition -- even if those are relatively suboptimal. 
• This is a source of massive tension in many design activities.
  
• the social context has a big influence on the meaning of scalable in scalable abstractions
• The category-theoretic analysis underlying the solution space i explored has many "gimme's" and "theorems for free". For example, suppose that i wanted a Hennessy-Milner logic to go with my little language, to do model-checking for properties on my terms. The category-theoretic framework makes this a snap. i can auto-generate this logic for this language, provided a "notion of collection" is supplied, as well as a generic algorithm for a model-checker. However, and this is a big 'however', this solution will not be absorbed by the dominant community that is currently engaged in software engineering solitions -- despite the fact that they are rushing headlong towards the cliff of concurrency where these and related techniques will be necessitated. There be "scalable" abstractions in the category-theoretic informed design approach that clearly generate interesting features for very little effort, but the feature space is simply not understood by the potential user-base. (We all know this problem: users don't actually know their requirements. ;-)
  
• The software engineering practices of the day will make it understandable that you might want to store code models on the backend. (Even Microsoft has come around to this idea, but you only have to look at VS6 to see what a long journey that was.) Once you start storing code models, you might think about wanting to search through them. Once you think about this, you might wonder what sort of query language would enable this. This sort of pondering can eventually lead to an understanding of the needs for the abstractions in the above bullet point: model-checking can be turned into a kind of query. It's a much longer route, in terms of conceptual burden. However, because of the social context, it's one of the few collections of abstractions that scales, in the sense of laying a foundation for big wins in feature and function relative to design and build effort.
  

Best wishes,

--greg

On Tue, May 5, 2009 at 8:10 AM, Meredith Gregory <lgreg.meredith@gmail.com> wrote:

Jon, et al,

i've finally put together a 1st draft response. i've still got a lot of debugging to do, but the solution is end-to-end.

• there is a parser and evaluator hosted inside a lift-based web-container
• the parser is built using BNFC and can target Java/C#/OCaml/Haskell/F#/...
• the parser comes with visitor pattern support
• the evaluator is built in a two-level type style and demonstrates that the only OO you need is just enough to make Scala happy -- the abstractions are all FP-based
  

As i said, this is very much a draft and the code falls over most of the time. But, at this point, it's really a pedagogical device and framework for hosting and evaluating different solutions.

Again, one the main reasons i see for using Scala is it's seamless interop with Java. The OCaml solution is intriguing (though ther are some strangenesses in it that i've yet to grok, like why the lambda terms seem to have no body), but i would like to see that solution hosted in this manner.

As of two years ago when i was evaluating various Language+Platform options, OCaml had no stable web framework that could compare to Lift -- which is still very nascent. If that has changed, i'd love to hear about it. A similar situation holds for Haskell, although i'm still keeping my eye on HAppS. Beyond this, there is the huge and ever-growing Java open source base. To get something of even this toy quality on any other platform is hugely time-consuming, in my experience.

Again, as an example, if i wanted to add a DB backend to this app, it is trivial to

• auto-generate an XML schema from the bnf
• wire-in BDBXML
• store and retrieve code-model expressions from an XML database

or

• auto-generate an SQL schema (from the XML schema generated from the BNF)
• wire in JPA
• store and retrieve code-model expressions from a relational database
  

Literally, this app could have this capability in about 2 hours. In my experience it has taken me 2 orders of magnitude to do the same for other Language+Platform configurations.

Best wishes,

--greg


On Sun, May 3, 2009 at 3:55 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Sunday 03 May 2009 23:24:30 FFT wrote:
> On Sat, May 2, 2009 at 12:32 AM, martin odersky <martin.odersky@epfl.ch>
wrote:
> > I am still not satisfied.
>
> The example given here may be too small to really teach us anything
> (even though a Scala version of it hasn't been posted yet). How do the
> ML and OOP/fp approaches scale to programs of realistic size?

You would want to add more "members" to the environment object. That is
trivial in OOP. The vanilla ML would be converted to use a record instead of
a tuple. However, that would scale just as well.

> Here, I think another interesting thing to compare is the
> implementations Scala and OCaml compilers (excluding runtimes).
>
> Scala compiles only to JVM, and OCaml compiles to either its bytecode
> or native code on various platforms. Aside from that, the work that
> needs to be done is somewhat similar, and yet I believe OCaml source
> code is many times smaller.

I'm not sure you can draw any interesting conclusions from that because,
although the sizes of the code bases differs, the functionality in the
compilers in wildly different because the languages themselves are so
different.

I think it only makes sense to solve the same problem in different languages
and compare the solutions. However, I do not know of any capabilities from
OOP that are not trivial to reproduce in SML except for inheritance which is
considered bad style. OOP in OCaml offers more type inference but I think
that is unique to OCaml and, for example, is not provided by Scala.

Any ideas?

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

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

+1 206.650.3740

http://biosimilarity.blogspot.com

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

+1 206.650.3740

http://biosimilarity.blogspot.com

Where are the UML diagrams?

On Tue, May 5, 2009 at 9:45 AM, Meredith Gregory
wrote:
> All,
>
> i should have mentioned:
>
> the abstract syntax used for evaluation is here
> the evaluation strategy pattern and instantiations over different env/var
> types is here
> the concrete syntax is here
> a brain-dead compilation strategy taking concrete syntax to abstract syntax
> + evaluation strategy is here
>

FFT,

Left as an exercise to the reader. ;-)

Best wishes,

--greg

On Tue, May 5, 2009 at 10:00 AM, FFT <fft1976@gmail.com> wrote:

Where are the UML diagrams?

On Tue, May 5, 2009 at 9:45 AM, Meredith Gregory
<lgreg.meredith@gmail.com> wrote:
> All,
>
> i should have mentioned:
>
> the abstract syntax used for evaluation is here
> the evaluation strategy pattern and instantiations over different env/var
> types is here
> the concrete syntax is here
> a brain-dead compilation strategy taking concrete syntax to abstract syntax
> + evaluation strategy is here
>

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

+1 206.650.3740

http://biosimilarity.blogspot.com

On Tue, May 5, 2009 at 7:00 PM, FFT <fft1976@gmail.com> wrote:

Where are the UML diagrams?

Ur funny :-)
 

On Tue, May 5, 2009 at 9:45 AM, Meredith Gregory
<lgreg.meredith@gmail.com> wrote:
> All,
>
> i should have mentioned:
>
> the abstract syntax used for evaluation is here
> the evaluation strategy pattern and instantiations over different env/var
> types is here
> the concrete syntax is here
> a brain-dead compilation strategy taking concrete syntax to abstract syntax
> + evaluation strategy is here
>

--
Viktor Klang
Senior Systems Analyst

On Tuesday 05 May 2009 17:45:03 Meredith Gregory wrote:
> ...

I barely understood a word of that. :-)

My interpretation is that you've solved the challenge in Scala and put your
solution into a web framework so that it can be used as an interactive
service over the web. Is that correct?

> The OCaml solution is intriguing (though ther are some strangenesses in it
> that i've yet to grok, like why the lambda terms seem to have no body), but
> i would like to see that solution hosted in this manner.

I do not understand what you mean by "hosted in this manner". Does the user
point their browser at a page on your server and get a REPL? Is a running
demo up anywhere?

> OCaml had no stable web framework that could compare to Lift -- which is
> still very nascent. If that has changed, i'd love to hear about it.

I have no relevant experience myself but I have heard good things about the
Ocsigen web framework for OCaml:

http://www.ocsigen.org

There are also some OCaml success stories in the web programming space, such
as Wink:

http://wink.com

I think they handle ~30 requests per second.

Jon,

Thanks for your queries. My responses are in-lined below.

Best wishes,

--greg

On Tue, May 5, 2009 at 8:31 PM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Tuesday 05 May 2009 17:45:03 Meredith Gregory wrote:
> ...

I barely understood a word of that. :-)

My interpretation is that you've solved the challenge in Scala and put your
solution into a web framework so that it can be used as an interactive
service over the web. Is that correct?

That's certainly true, but it's not quite everything that could be gotten from what i wrote.

> The OCaml solution is intriguing (though ther are some strangenesses in it
> that i've yet to grok, like why the lambda terms seem to have no body), but
> i would like to see that solution hosted in this manner.

I do not understand what you mean by "hosted in this manner". Does the user
point their browser at a page on your server and get a REPL? Is a running
demo up anywhere?

To run the code, assuming you have svn and mvn installed on your box, you do the following.

• Get a version of the project
• svn checkout http://rlambda.googlecode.com/svn/trunk/ rlambda
• Compile and run the code
• cd rlambda; mvn compile jetty:run
  
• Point your browser at http://localhost:8080
   

> OCaml had no stable web framework that could compare to Lift -- which is
> still very nascent. If that has changed, i'd love to hear about it.

I have no relevant experience myself but I have heard good things about the
Ocsigen web framework for OCaml:

 http://www.ocsigen.org

i played with Ocsigen. Two years ago it had none of the maturity of Lift. It may be better, now.
 

There are also some OCaml success stories in the web programming space, such
as Wink:

 http://wink.com

I think they handle ~30 requests per second.

Thanks for the link. i'll look into that.
 

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

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

+1 206.650.3740

http://biosimilarity.blogspot.com

On Wednesday 06 May 2009 07:45:20 Meredith Gregory wrote:
> > I barely understood a word of that. :-)
> >
> > My interpretation is that you've solved the challenge in Scala and put
> > your solution into a web framework so that it can be used as an
> > interactive service over the web. Is that correct?
>
> That's certainly true, but it's not quite everything that could be gotten
> from what i wrote.

:-)

> > > The OCaml solution is intriguing (though ther are some strangenesses in
> >
> > it
> >
> > > that i've yet to grok, like why the lambda terms seem to have no body),
> >
> > but
> >
> > > i would like to see that solution hosted in this manner.
> >
> > I do not understand what you mean by "hosted in this manner". Does the
> > user point their browser at a page on your server and get a REPL? Is a
> > running demo up anywhere?
>
> To run the code, assuming you have svn and mvn installed on your box, you
> do the following.
>
> - Get a version of the project
> - svn checkout *http*://rlambda.googlecode.com/svn/trunk/ rlambda
> - Compile and run the code
> - cd rlambda; mvn compile jetty:run
> - Point your browser at http://localhost:8080

I get BUILD ERROR:

The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or
no valid version could be found

> > > OCaml had no stable web framework that could compare to Lift -- which
> > > is still very nascent. If that has changed, i'd love to hear about it.
> >
> > I have no relevant experience myself but I have heard good things about
> > the Ocsigen web framework for OCaml:
> >
> > http://www.ocsigen.org
>
> i played with Ocsigen. Two years ago it had none of the maturity of Lift.
> It may be better, now.

Ok.

> > There are also some OCaml success stories in the web programming space,
> > such
> > as Wink:
> >
> > http://wink.com
> >
> > I think they handle ~30 requests per second.
>
> Thanks for the link. i'll look into that.

I think they use their own stuff written entirely from scratch in OCaml and
not any existing frameworks.

I just setup rlambda as described and it worked as expected.
I use Maven 2.0.10

On Wed, May 6, 2009 at 9:15 AM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Wednesday 06 May 2009 07:45:20 Meredith Gregory wrote:
> > I barely understood a word of that. :-)
> >
> > My interpretation is that you've solved the challenge in Scala and put
> > your solution into a web framework so that it can be used as an
> > interactive service over the web. Is that correct?
>
> That's certainly true, but it's not quite everything that could be gotten
> from what i wrote.

:-)

> > > The OCaml solution is intriguing (though ther are some strangenesses in
> >
> > it
> >
> > > that i've yet to grok, like why the lambda terms seem to have no body),
> >
> > but
> >
> > > i would like to see that solution hosted in this manner.
> >
> > I do not understand what you mean by "hosted in this manner". Does the
> > user point their browser at a page on your server and get a REPL? Is a
> > running demo up anywhere?
>
> To run the code, assuming you have svn and mvn installed on your box, you
> do the following.
>
>    - Get a version of the project
>       - svn checkout *http*://rlambda.googlecode.com/svn/trunk/ rlambda
>    - Compile and run the code
>       - cd rlambda; mvn compile jetty:run
>       - Point your browser at http://localhost:8080

I get BUILD ERROR:

 The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or
no valid version could be found

> > > OCaml had no stable web framework that could compare to Lift -- which
> > > is still very nascent. If that has changed, i'd love to hear about it.
> >
> > I have no relevant experience myself but I have heard good things about
> > the Ocsigen web framework for OCaml:
> >
> >  http://www.ocsigen.org
>
> i played with Ocsigen. Two years ago it had none of the maturity of Lift.
> It may be better, now.

Ok.

> > There are also some OCaml success stories in the web programming space,
> > such
> > as Wink:
> >
> >  http://wink.com
> >
> > I think they handle ~30 requests per second.
>
> Thanks for the link. i'll look into that.

I think they use their own stuff written entirely from scratch in OCaml and
not any existing frameworks.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

On Wednesday 06 May 2009 08:12:26 Daniel Kröni wrote:
> I just setup rlambda as described and it worked as expected.

Can you describe what you see? :-)

Jon,

Thanks for letting me know about the build error. Is the version of mvn >= 2.0.9?

Best wishes,

--greg

On Wed, May 6, 2009 at 12:15 AM, Jon Harrop <jon@ffconsultancy.com> wrote:

On Wednesday 06 May 2009 07:45:20 Meredith Gregory wrote:
> > I barely understood a word of that. :-)
> >
> > My interpretation is that you've solved the challenge in Scala and put
> > your solution into a web framework so that it can be used as an
> > interactive service over the web. Is that correct?
>
> That's certainly true, but it's not quite everything that could be gotten
> from what i wrote.

:-)

> > > The OCaml solution is intriguing (though ther are some strangenesses in
> >
> > it
> >
> > > that i've yet to grok, like why the lambda terms seem to have no body),
> >
> > but
> >
> > > i would like to see that solution hosted in this manner.
> >
> > I do not understand what you mean by "hosted in this manner". Does the
> > user point their browser at a page on your server and get a REPL? Is a
> > running demo up anywhere?
>
> To run the code, assuming you have svn and mvn installed on your box, you
> do the following.
>
>    - Get a version of the project
>       - svn checkout *http*://rlambda.googlecode.com/svn/trunk/ rlambda
>    - Compile and run the code
>       - cd rlambda; mvn compile jetty:run
>       - Point your browser at http://localhost:8080

I get BUILD ERROR:

 The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or
no valid version could be found

> > > OCaml had no stable web framework that could compare to Lift -- which
> > > is still very nascent. If that has changed, i'd love to hear about it.
> >
> > I have no relevant experience myself but I have heard good things about
> > the Ocsigen web framework for OCaml:
> >
> >  http://www.ocsigen.org
>
> i played with Ocsigen. Two years ago it had none of the maturity of Lift.
> It may be better, now.

Ok.

> > There are also some OCaml success stories in the web programming space,
> > such
> > as Wink:
> >
> >  http://wink.com
> >
> > I think they handle ~30 requests per second.
>
> Thanks for the link. i'll look into that.

I think they use their own stuff written entirely from scratch in OCaml and
not any existing frameworks.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

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

+1 206.650.3740

http://biosimilarity.blogspot.com

On Wednesday 06 May 2009 15:29:19 Meredith Gregory wrote:
> Jon,
>
> Thanks for letting me know about the build error. Is the version of mvn >=
> 2.0.9?

Yes, Maven 2.0.9 from the Debian package maven2. I just had to do:

mvn -up install

whereupon it downloaded half of the internet but now it works. Very
impressive. I have no idea how to do that. :-)