Raoul Duke | 1 May 01:14 2009
Picon

Re: Re: usefulness of OOP

+1, imhumbleo.

On 4/30/09, Jon Harrop <jon <at> 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.
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
>

Raoul Duke | 1 May 01:16 2009
Picon

Re: usefulness of OOP

On 4/30/09, Josh Suereth <joshua.suereth <at> 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.

Jon Harrop | 1 May 01:48 2009

Re: usefulness of OOP

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

(Continue reading)

Josh Suereth | 1 May 01:41 2009
Picon

Re: usefulness of OOP

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 <at> gmail.com> wrote:
On 4/30/09, Josh Suereth <joshua.suereth <at> 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.

Jon Harrop | 1 May 02:34 2009

Re: usefulness of OOP

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

--

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

FFT | 1 May 04:03 2009
Picon

Re: usefulness of OOP

On Thu, Apr 30, 2009 at 4:48 PM, Jon Harrop <jon <at> ffconsultancy.com> 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?

Jon Harrop | 1 May 04:39 2009

Re: usefulness of OOP

On Friday 01 May 2009 03:03:42 FFT wrote:
> On Thu, Apr 30, 2009 at 4:48 PM, Jon Harrop <jon <at> ffconsultancy.com> 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.

--

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

Nils Kilden-Pedersen | 1 May 04:50 2009
Picon

Re: Re: usefulness of OOP

On Thu, Apr 30, 2009 at 4:36 PM, Jon Harrop <jon <at> 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.
Christos KK Loverdos | 1 May 11:13 2009
Picon

Re: usefulness of OOP

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 <at> gmail.com> wrote:


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

BR
Christos.


--
 __~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
martin odersky | 1 May 11:16 2009
Picon
Picon

Re: usefulness of OOP

On Fri, May 1, 2009 at 12:18 AM, FFT <fft1976 <at> gmail.com> wrote:
> On Thu, Apr 30, 2009 at 2:12 PM, Jon Harrop <jon <at> ffconsultancy.com> 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

 -- Martin


Gmane