RE: [Caml-list] Some Clarifications

RE: [Caml-list] Some Clarifications

[Don Syme]

Hi Robert,

For what it's worth, I found your posts genuinely interesting.

Best wishes,
Don


-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Robert Morelli
Sent: 19 July 2005 21:15
To: Robert Morelli
Cc: Kyle Consalus; caml-list@yquem.inria.fr
Subject: [Caml-list] Some Clarifications

In the interests of saving time,  and keeping my post to a palatable
length,  I stated my contentions as unsupported assertions.  I intended
to elaborate only those points that aroused debate.  Unfortunately,
people have already misconstrued or protested every single statement
I've made,  so this thread has grown beyond the point I want to deal
with in detail.

Let me just try to explain what I think the essential distinction
between OO and FP programming is.  In FP you ideally capture the essence
of your data in your data structures.  In other words,  they are ideally
wholly characterized by their data type.  This is the reason conciseness
is considered a virtue in FP,  because verbosity is likely evidence of a
conceptual error.  That's not so in OO (with its associated problem
space),  where you model things whose existence you know,  but whose
essence you may not be able to capture in the language,  its type and
class systems,  or even in your head.

FP languages can handle such things to a greater of lesser extent,
but FP languages have many technical and practical disadvantages,
so it often doesn't make sense to use them in such a way.  And
the further you deviate from the ideal,  the less a rigid type
system helps keep your software sound,  and the more it gets in your
way.

One of the areas where I do much of my programming is in mathematical
software.  I view this as one of the most difficult areas,  at the
opposite extreme from simple domains like formal methods and language
tools.  The problems with characterizing mathematical objects come
up peripherally here with representations of numbers.  This always leads
to endless,  inconclusive discussions of issues like operator
overloading,  inheritance and multiple inheritance,  multiple dispatch,
multiple views of a data structure,  constraints, etc., etc.  And that's
just the tip of the iceberg.  I find that the facilities of a language
like OCaml are so inadequate to represent this domain,  that using
OCaml can be a distinct impediment.  Sometimes Java is a better fit.
Not always,  but sometimes.

The fundamental point is that OO puts interaction at the
center of the paradigm,  not abstract characterization.  That has
huge consequences and it's what makes the whole idea of a "theory"
of large scale design meaningful.  OO commits to a certain way of
organizing interaction,  state changes,  behavior changes, ....  that's
attractive in practice (but requires deeper theory than FP).

Consider the following historical example.  Milner,  the creator of ML,
began trying to grapple with the concept of interaction and concurrency
in the early 1970's.  His first attempt was to use a functional approach
with higher order functions.  That was a failure.  Ultimately,  he ended
up creating the process algebra CCS (and later went on to the
pi-calculus).  Milner's CCS,  and his account of it,  have a striking
resemblance to the OO interactive paradigm,  and completely abandon FP
concepts.  This despite the fact that he created ML in the very same
period,  and had no involvement with the OO projects of the time.  In
the past decade,  concurrent object calculi have been proposed as
foundations of the OO paradigm.  They look very much akin to things like
the pi-calculus.  Haskell's concurrency also has a pi-calculus like
semantics.

Some other historical perspectives ... 1.  At the same time,  Smalltalk
and Xerox PARC was underway,  and within a few years,  the Mac hit the
scene with its OO influenced interactive GUI -- arguably the most
important development in the history of software development.
2.  Simula,  the first OO language,  and one of the most influential
languages of all time,  was developed about a decade earlier.
Simula's objects had a built-in notion of concurrency,  intended to
model interactive queuing networks.
3.  Within a decade or so,  OO based RAD visual development tools like
Visual Basic hit the scene and quickly gained enormous influence.
Is there even an FP analog of building software that way?
4. Over the decades,  both hardware and software technologies have
inexorably evolved toward networked,  decentralized,  componentized
systems.  Even CPU's are now trending toward multicore designs.  This
makes the sequential computational model that FP is based on seem less
and less central.

Part of what I think accounts for the popularity of OO in the real
world is that it allows you to program in a very sloppy way in the early

stages of development without blowing your ability to muck with the way
things interact,  and alter their behavior later in the development
process.  Ideally,  it allows you to build big,  sloppy,  poorly planned

systems that are nevertheless manageable to maintain.  In the real
world,  almost all programmers are hackers,  with limited capacity for
forethought,  so this is an attractive feature.

It's sometimes claimed that OCaml's type system gives you a similar
advantage,  allowing you to quickly pinpoint all of the consequences
of a design change.  But that's a rather different technique.

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Some Clarifications

[Jon Harrop]

On Wednesday 27 July 2005 10:38, Don Syme wrote:
> For what it's worth, I found your posts genuinely interesting.

I think there is something of interest worth discussing but most of it would 
be more appropriate on c.l.functional than here. I'd be happy to discuss this 
there.

Just replying to the OPs OCaml-related comments: I don't think that most 
programmers use OO because it is the right tool for the job. I think they use 
it either because it is forced upon them (Java) or because the language fails 
to provide alternatives (C++).

OCaml is a useful case study here because it provides many alternatives. 
You're not going to implement a closure via an object (as you would in C++) 
or a 3D vector via an object (as you would in Java), for example. So it is 
instructive to look at uses of OO in OCaml code.

Of the OCaml code which I have studied, the OCaml compilers make scarce use of 
objects, the stdlib makes no use (IIRC), the third party data structures and 
algorithms that I use also make no use of OO but lablgtk uses OO and I have 
one friend who has tried using OO in his own OCaml work.

In my code, I have used an object once, in order to circumvent a typing 
problem. I have never successfully used OO in OCaml.

From my point of view, it is interesting to compare graphics and GUI code 
which I have written in a classical FP style to a friend's who chose the OO 
approach because GUI code is a pedagogical example of OO design. Although it 
is early days, I see no evidence that OO is any better than the classical FP 
approach at this task.

> Part of what I think accounts for the popularity of OO in the real world is
> that it allows you to program in a very sloppy way in the early stages of
> development without blowing your ability to muck with the way things
> interact,  and alter their behavior later in the development process.
> Ideally,  it allows you to build big,  sloppy,  poorly planned systems that
> are nevertheless manageable to maintain. 

My experience is exactly the opposite. I worked on a project for several years 
which was written in C++ and which used OO extensively. Ultimately, we 
ditched both C++ and OO in favour of OCaml and FP precisely because we wanted 
to make a few fundamental changes and those changes were simply too difficult 
for us to make successfully. In contrast, we have made many similarly 
complicated fundamental changes to the OCaml code with no problems.

So, despite reasonable understanding and planning beforehand, OO completely 
failed to allow us to maintain and develop the program.

> I find that the facilities of a language like OCaml are so inadequate to
> represent this domain,  that using OCaml can be a distinct impediment.

If you would like to discuss OCaml-related stuff then I'd like to hear more: 
specifically what it is you're working on, what you have tried and failed to 
do in OCaml and why you think OCaml is "so inadequate"?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Some Clarifications

[Robert Roessler]

Jon Harrop wrote:

> ...
> Of the OCaml code which I have studied, the OCaml compilers make scarce use of 
> objects, the stdlib makes no use (IIRC), the third party data structures and 
> algorithms that I use also make no use of OO but lablgtk uses OO and I have 
> one friend who has tried using OO in his own OCaml work.

The body of the OCaml implementation itself may not represent the best 
sample set for making this type of observation: in historical context, 
the "O" of OCaml came along relatively late in the project's life, and 
I do not believe that the compilers and standard library code were 
redesigned and reimplemented from the ground up once the "O" was present.

> In my code, I have used an object once, in order to circumvent a typing 
> problem. I have never successfully used OO in OCaml.

An object certainly seems a natural and concise way to represent a 
"state-holder-with-structured-access" - and I have done just that in a 
small OCaml project... but that could be the Smalltalk and C++ in my 
background talking. :)

Robert Roessler
roessler@rftp.com
http://www.rftp.com

Re: [Caml-list] Some Clarifications

[David Thomas]

I notice that there are two things that people have
been commonly confusing with the notion of Object
Oriented programming.  The first of these is the
notion of modularity.  While this is generally
provided by OO design, it can (and should!) certainly
be applied in virtually any methodology.

The second is the notion of OO design, and the
language features provided to make it easier.  Any
time you write a program that focuses on the
components as "data and operations on that data," you
have written an OO program.  This can be done in any
language.  It doesn't matter what the components are
called, they can be classes, structures, records,
modules, or libraries. It also does not require the
use of polymorphism or inheritence,  although these
quite often make implementing and extending such
designs significantly easier.  I've seen many designs
in OCaml (most of the core libraries, to start with)
that have this focus, and much (though not all) of
what I've written does as well, regardless of whether
we've used those language features set aside as
designed to facilitate OO implementations.  I would
guess that you have, too.

** digression **
The Java practice of forcing you to represent the
entire program as a class does nothing to encourage OO
design.  The focus is not on the data, it is still on
the operation to be performed.  This limitation on a
"pure OO" language is admittedly imposed from outside.
 I've yet to see an OS that provides support for truly
OO design.  The GUI notion of associating a default
action with a file type comes close, but I've not seen
this used in a shell, which would be rather
interesting, though I've no clue how usefull.

--- Jon Harrop <jon@ffconsultancy.com> wrote:

> On Wednesday 27 July 2005 10:38, Don Syme wrote:
> > For what it's worth, I found your posts genuinely
> interesting.
> 
> I think there is something of interest worth
> discussing but most of it would 
> be more appropriate on c.l.functional than here. I'd
> be happy to discuss this 
> there.
> 
> Just replying to the OPs OCaml-related comments: I
> don't think that most 
> programmers use OO because it is the right tool for
> the job. I think they use 
> it either because it is forced upon them (Java) or
> because the language fails 
> to provide alternatives (C++).
> 
> OCaml is a useful case study here because it
> provides many alternatives. 
> You're not going to implement a closure via an
> object (as you would in C++) 
> or a 3D vector via an object (as you would in Java),
> for example. So it is 
> instructive to look at uses of OO in OCaml code.
> 
> Of the OCaml code which I have studied, the OCaml
> compilers make scarce use of 
> objects, the stdlib makes no use (IIRC), the third
> party data structures and 
> algorithms that I use also make no use of OO but
> lablgtk uses OO and I have 
> one friend who has tried using OO in his own OCaml
> work.
> 
> In my code, I have used an object once, in order to
> circumvent a typing 
> problem. I have never successfully used OO in OCaml.
> 
> From my point of view, it is interesting to compare
> graphics and GUI code 
> which I have written in a classical FP style to a
> friend's who chose the OO 
> approach because GUI code is a pedagogical example
> of OO design. Although it 
> is early days, I see no evidence that OO is any
> better than the classical FP 
> approach at this task.
> 
> > Part of what I think accounts for the popularity
> of OO in the real world is
> > that it allows you to program in a very sloppy way
> in the early stages of
> > development without blowing your ability to muck
> with the way things
> > interact,  and alter their behavior later in the
> development process.
> > Ideally,  it allows you to build big,  sloppy, 
> poorly planned systems that
> > are nevertheless manageable to maintain. 
> 
> My experience is exactly the opposite. I worked on a
> project for several years 
> which was written in C++ and which used OO
> extensively. Ultimately, we 
> ditched both C++ and OO in favour of OCaml and FP
> precisely because we wanted 
> to make a few fundamental changes and those changes
> were simply too difficult 
> for us to make successfully. In contrast, we have
> made many similarly 
> complicated fundamental changes to the OCaml code
> with no problems.
> 
> So, despite reasonable understanding and planning
> beforehand, OO completely 
> failed to allow us to maintain and develop the
> program.
> 
> > I find that the facilities of a language like
> OCaml are so inadequate to
> > represent this domain,  that using OCaml can be a
> distinct impediment.
> 
> If you would like to discuss OCaml-related stuff
> then I'd like to hear more: 
> specifically what it is you're working on, what you
> have tried and failed to 
> do in OCaml and why you think OCaml is "so
> inadequate"?
> 
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> Objective CAML for Scientists
>
http://www.ffconsultancy.com/products/ocaml_for_scientists
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
>
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [Caml-list] Some Clarifications

[Ville-Pertti Keinonen]

David Thomas wrote:

> language features provided to make it easier.  Any
> time you write a program that focuses on the
> components as "data and operations on that data," you
> have written an OO program.  This can be done in any

Not according to traditional terminology.  What you've done is used 
Abstract Data Types, which is one of the most basic forms of abstraction 
that anyone should learn in any programming language.

Of course I've seen quite a few programmers who don't have enough 
discipline to use consistent abstractions unless they're forced to 
encapsulate things in classes.

Re: [Caml-list] Some Clarifications

[Richard Jones]

On Wed, Jul 27, 2005 at 04:55:32AM -0700, Robert Roessler wrote:
> An object certainly seems a natural and concise way to represent a 
> "state-holder-with-structured-access" - and I have done just that in a 
> small OCaml project... but that could be the Smalltalk and C++ in my 
> background talking. :)

Modules actually work better for this.

The exception is for GUIs, where inheritance allows you to do a few
minor but useful things - in particular having containers and layouts
which can contain widgets of any widget type.  It's interesting that
the one example of OO design in the GoF book (or in my ancient edition
of it at least) is GUI widgets.  I'm keen to know if there are any
other areas where inheritance is actually useful over straightforward
polymorphism and higher-order functions..

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Some Clarifications

[james woodyatt]

On 27 Jul 2005, at 03:58, Jon Harrop wrote:
>
> Of the OCaml code which I have studied, the OCaml compilers make  
> scarce use of
> objects, the stdlib makes no use (IIRC), the third party data  
> structures and
> algorithms that I use also make no use of OO but lablgtk uses OO  
> and I have
> one friend who has tried using OO in his own OCaml work.

In the first pass through at my functioanl reactive I/O [Iom] library  
in OCaml NAE, I managed to get a lot done without using any objects.   
In general, this produced tighter code, but it was less adaptable  
than I wanted it to be, and I found it hard to reuse parts of  
reactors.  Sure, reactors themselves were highly reuseable, but I  
found myself wanting to make a framework of very similar reactors all  
built out of some common functions.  A reactor was typically written  
as a huge bundle of mutually recursive monad functions, and it was a  
major pain to separate the reusable functions from the rest of the  
bundle.

In my recently announced refactoring of the [Iom] library, I found I  
could get more adaptability by using the object system.  In the new  
code, reactors can be written as classes (even pure functional  
classes) and the monad functions implemented as methods.  It makes  
the challenge of designing a general purpose reactive I/O framework a  
lot easier.  The problem of separating the reusable functions from  
the rest of the bundle is resolved by implementing a class with  
virtual methods.

I doubt this hybrid approach, combining both FP and OO, could be used  
in any other language I know about.  From my perspective, FP and OO  
are orthogonal and not mutually exclusive techniques.  Once you  
decide to use OO for what it really does, and which FP doesn't, I  
think you find that what it has to say about large-scale software  
development is a lot less than what most practitioners think.  This  
is because you're right: most programmers don't use OO because it's  
the right tool for the job; most use it because it's inappropriately  
forced on them by a language that doesn't provide reasonable  
alternatives for things that don't need OO to enable.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

Re: [Caml-list] Some Clarifications

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Wed, 2005-07-27 at 04:55 -0700, Robert Roessler wrote:
> Jon Harrop wrote:

> > In my code, I have used an object once, in order to circumvent a typing 
> > problem. I have never successfully used OO in OCaml.

I have, and they worked quite well -- I was implementing
Python in Ocaml .. the utility of Ocaml objects to represent
Python objects is obvious :)

> An object certainly seems a natural and concise way to represent a 
> "state-holder-with-structured-access" - and I have done just that in a 
> small OCaml project... but that could be the Smalltalk and C++ in my 
> background talking. :)

Generally (whatever that means) one will prefer functional
techniques in Ocaml: not because they're better supported
than Objects, but because transparency and persistence
just make programming easier. However many applications
have to implement protocols that require state to
represent context, and others have to interface with
foreign Object Oriented code (eg Gtk).

In fact the big pain here is that Ocaml is strict about
typing, and if you're modelling a system that isn't,
it can be hard, simply because what you are required
to implement is already flawed.

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Some Clarifications

[Robert Roessler]

Richard Jones wrote:

> On Wed, Jul 27, 2005 at 04:55:32AM -0700, Robert Roessler wrote:
> 
>>An object certainly seems a natural and concise way to represent a 
>>"state-holder-with-structured-access" - and I have done just that in a 
>>small OCaml project... but that could be the Smalltalk and C++ in my 
>>background talking. :)
> 
> 
> Modules actually work better for this.

In a non-trolling and non-flaming way (of course), I would be 
interested in examples illustrating your assertion - simple or 
complex, real or synthetic - I am usually ready to learn. :)

Robert Roessler
roessler@rftp.com
http://www.rftp.com

Re: [Caml-list] Some Clarifications

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 27, 2005, at 1:33 PM, skaller wrote:

> On Wed, 2005-07-27 at 09:37 -0600, Robert Morelli wrote:
>
>
>> My contention is simply that the program is incomplete;  there's
>> more to be discovered by implementing more of mathematics.  The
>> attitude that OCaml is some kind of pinnacle of language development,
>> already capable of dealing with all problems (and anyone who fails to
>> agree must simply be ignorant),  is quite depressing to me.
>>
>
> Good heavens, no one here believes that!

Yes, that's quite a straw man. I'd also point out that examples like  
Axiom and its Aldor language don't support the assertion that OO is  
somehow better suited to the domain than FP is; on the contrary, they  
point out that even today, the best research into the automation of  
mathematics takes place in even richer functional languages with  
richer type systems than O'Caml's. I think most of us on the list are  
aware that, e.g. even plain ol' Haskell 98, with its typeclasses, has  
some advantages over O'Caml, nevermind GHC 6.4 with its GADTs, and  
nevermind Aldor or Cayenne or Epigram or DML or any of the other  
languages with one kind or another of dependent types.

But as John said, many of us appreciate that O'Caml runs on several  
platforms, generates plenty good-enough native code for many of those  
targets most of the time, pays some attention to representation  
issues in arrays and records, doesn't slavishly abstract from the  
underlying hardware but is nevertheless memory safe, has a nice time- 
travel debugger, a profiler for native code, syntactic extensibility  
that rivals Lisp's, a rapidly growing set of impressive libraries,  
good foreign-function interfaces, and a top-notch community. O'Caml  
is the language that I think of as "the obvious alternative to C++,"  
and I wouldn't hesitate to use it commercially on real-world  
projects, if only it had bindings to Carbon or Cocoa on Mac OS X. :-)

Also, as others here have pointed out, O'Caml programmers aren't  
necessarily averse to using objects when they actually buy us  
something, but O'Caml doesn't use objects as an organizational  
dumping ground the way C++ or Java do, since O'Caml has an actual  
module system, parametric polymorphism, and higher-order functions  
(yes, I know you know all of this). So perhaps your (Robert) argument  
is better levied against Haskell programmers, or Concurrent Clean  
programmers, or Standard ML programmers, than O'Caml programmers? In  
any case, to the extent that your point is that O'Caml isn't the end  
of the language design road, I think we're in vehement agreement.  
However, if your argument is also that object-oriented languages  
taken apart from features such as higher-order functions, module  
systems, parametric polymorphism (or, these days, even with  
parametric polymorphism bolted on), somehow have a clearer  
evolutionary path than functional languages, I'll have to disagree  
wholeheartedly. However, it's not clear to me, actually, what your  
argument is at this point, so I'll stop here.

Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iEYEARECAAYFAkLoHTwACgkQO3fYpochAqJLKwCfSruR2rr1CxUGa2D4659yyzk1
4WEAoLh0FDRvr36r3Uaaw7DsveHN4nWo
=ufoe
-----END PGP SIGNATURE-----

Re: [Caml-list] Some Clarifications

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]

On Wed, 2005-07-27 at 09:37 -0600, Robert Morelli wrote:

> My contention is simply that the program is incomplete;  there's
> more to be discovered by implementing more of mathematics.  The
> attitude that OCaml is some kind of pinnacle of language development,
> already capable of dealing with all problems (and anyone who fails to
> agree must simply be ignorant),  is quite depressing to me.  

Good heavens, no one here believes that!

> If it
> were true,  I don't think good researchers would be developing it.

Precisely.

Its just that it is way WAY ahead of Java and C++ in most domains,
and unlike many advanced academic languages, it has a reasonable
number of users, has been developed conservatively, and is
beginning to be used in RL (Xavier proofing required) industrial
applications.

For once many people would probably agree with me,
that here is a high performance advanced general purpose
proven industrial strength programming language -- 
there are few others that rate all those adjectives.

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Some Clarifications

[Robert Morelli]

David MENTRE wrote:
> Hello Robert,
> 
> [As a side note, you did not answered my question on which software
> you consider of large scale. ]
> 
> Just two remarks on your post:
> 
> 2005/7/19, Robert Morelli <morelli@cs.utah.edu>:
> 
>>One of the areas where I do much of my programming is in mathematical
>>software.  I view this as one of the most difficult areas,  at the
>>opposite extreme from simple domains like formal methods and language
>>tools.  The problems with characterizing mathematical objects come
>>up peripherally here with representations of numbers.  This always leads
>>to endless,  inconclusive discussions of issues like operator
>>overloading,  inheritance and multiple inheritance,  multiple dispatch,
>>multiple views of a data structure,  constraints, etc., etc.
> 
> 
> You should take a look at Axiom:
> http://page.axiom-developer.org/zope/mathaction/FrontPage
> 
> This is an old Computer Algebra System, developed for 30 years at IBM
> and now free software (BSD-like license). It has a complete typing of
> mathematical expressions. The type system is very different from ML
> systems however: no type inference. It is closer to a dynamic OO
> language, but the types are not computer types but mathematical ones,
> based on mathematical properties of objects (you know more about the
> subject than me).

I took a look at it at one time.  What particularly interested me was
the special language Aldor that was created for AXIOM's library
compiler.  Aldor has first class dependent types,  so its type system
is more expressive and consistent than OCaml's.  Because it's so
powerful,  it does indeed have some of the feel of a dynamic OO
language,  but it is not OO and it is statically typed,  using its
typing information for performance and safety.  (A paper coauthored by
Stephen Watts,  the principle designer of the language,  described an
encoding of the C++ object model in Aldor.)

There was some research formalizing a subset of Aldor's type system,
and proposing some minor changes to make it more theoretically
tractable.  There was even a project underway to implement something
using the Curry-Howard correspondence to encode significant assertions
in the type system of a modified Aldor.  (I haven't looked at
this for years,  so anyone interested should look this up to check
current status and details.  Simon Thompson was involved.)

> To come back to OCaml, Axiom interactive type system poses interesting
> questions regarding type inference and interactive systems.
> Mathematical notation is based on operator overloading: use the same
> "+" as an operation on matrices or on integers, but the two "+" are
> not the same operations, even if they have the same mathematical
> properties. ML type systems are very bad when you need to manipulate
> objects of different types (in OCaml, you would need +, +., +/, +b,
> etc.). Maybe there is some interesting research to be done in that
> area. Pierre Weis (of OCaml fame) discussed ones with Tim Daly (Axiom
> lead developer) but did not catched the issue (at least this is how I
> interpreted the discussion).

It's a small world.  I lost my job at about the same time that AXIOM
was open sourced.  One of the things I considered was seeking funding
to do a research project.  One of the projects in computer science that
would most engage me intellectually,  would be to seek new programming
language paradigms to address the needs of mathematical software.
I briefly contacted Tim Daly during this period to explore whether I
could do something with AXIOM.   Unfortunately,  it was not to be:  no
credentials in computer science,  no proposalware,  not enough time to
cook up enough pseudo-goals and hype,  so I never submitted it.

At the time,  Tim Daly struck me as more of a software developer than
a programming language guy,  so he and Weis may have been talking
different languages,  so to speak.

I believe that mathematical software is one of the most fruitful avenues
for programming language research.  It seems to me that essentially
everything of lasting value in programming languages has come out of
attempting to implement mathematics.

My contention is simply that the program is incomplete;  there's
more to be discovered by implementing more of mathematics.  The
attitude that OCaml is some kind of pinnacle of language development,
already capable of dealing with all problems (and anyone who fails to
agree must simply be ignorant),  is quite depressing to me.  If it
were true,  I don't think good researchers would be developing it.

In fact,  if I may make a personal digression,  what got me interested
in computer science in the first place was doing these mathematical
calculations.  At some point,  I became almost transfixed with the
question of what would be needed to really do them properly.  I
began trying to design my own programming language.  What is amazing
to me in retrospect is that at the time,  I did not know what the terms
"functional programming language,"  "concurrency,"  or "programming
language semantics" meant,  nor did I know that there were researchers
who studied any such things seriously,  yet my design goals shared
a good deal with Haskell,  and my way of handling interaction involved
total concurrency,  like a process algebra.  I also tried to endow my
language with a category theoretic semantics (I believed at the
time this was an original idea).  It seems particularly strange that I
became fascinated with concurrency,  even though I was dealing with a
seemingly static world of mathematical objects,  and I had never done
any form of programming with threads or networking.  At the same time,
I placed the highest priority on stateless programming (which at the
time,  I thought was my own innovation).  I agonized for a long time
about how to reconcile these two diametric tendencies,  and finally came
up with a mechanism (not monads -- I never thought of that).

This experience has convinced me that studying mathematical computations
is very fruitful,  since I was lead to many correct ideas and instincts,
without any background in computer science,  or even much experience
programming.  At the same time,  I have encountered many programmers
with a great deal of experience who seem to have limited judgement
about programming languages.  The distinguishing factor seems to
be a certain kind of aesthetic and feeling for structure that I think
is best developed through mathematics.

>>The fundamental point is that OO puts interaction at the
>>center of the paradigm,  not abstract characterization.  That has
>>huge consequences and it's what makes the whole idea of a "theory"
>>of large scale design meaningful.  OO commits to a certain way of
>>organizing interaction,  state changes,  behavior changes, ....  that's
>>attractive in practice (but requires deeper theory than FP).
> 
> 
> I disagree on most of your arguments when comparing OO et FP (for the
> same reasons as others have developed on the previous thread).
> However, I agree on issues regarding  interactivity and ML typing, and
> more generally on the rigid aspects of ML typing in *certain*
> contexts.
> 
> As a programmer, ML typing is very rigid and this is a good point: I'm
> sure that in all over my program, the datastructure is *never* misued
> and that certain invariants are ensured. ML typing and moreover type
> inference is a must have for library programmers.

To me,  this seems to have a pattern.  If the ML type system
can express the intrinsic structure of the objects you're dealing with,
it will constrain you in just the right way.  To the extent that it
can't,  it will get in your way and may necessitate convoluted
work-arounds.  The mental effort that goes into the former case is
valuable,  since it clarifies your problem itself which is an ideal
match to its expression in software.  The effort that goes into the
latter is wasted mental energy,  since it only creates artifice,  rather
than helping you understand your problem.

My assertion has been that the former case arises in the area of
formal methods,  for which the ML language was originally designed,
and in a few other similar niche areas which I have described as
"simple."  I see no shame in this,  but others here apparently believe
they must advocate that functional programming is an ideal fit for every
programming task.

> However, as an interactive user (cf. my above comment on Axiom) or as
> a system architect, I sometimes misses the flexibility of dynamic OO
> system. Ok, they allow the system to be incoherent, but this is
> sometimes *useful*, for example when you refactor a big system and you
> want to test a subset of your modifications. The other point, as I
> said, is the use of overloading. It is natural in dynamic OO systems,
> it is very unpleasant in OCaml (although I haven't dug into GCaml, I
> had a bad experience with OCaml objects).
> 
> I sometimes dream of a system that would allow me to have *both*
> static typing and type inference like ML and dynamic typing like Lisp
> or OO languages. The best of both worlds! :) In my opinion, the
> interesting part is how to mix the two paradigms smoothly, e.g. how to
> have meaningful error messages, how to define types for certain
> objects but let the type inference system do the job for most of my
> code, etc.
> 
> Yours,
> d.
> 
> PS: formal methods or language tools are *not* simple domains! :-)

A number of people have made this same point.  I think we must be
misunderstanding each other.  Let me just point out,  in case there
is a language barrier,  that the primary use of the word "simple"
in English has a positive connotation.  (The words "simplistic"
and "simple-minded" have negative connotations.)  Simple is good.
The best researchers,  scientists,  and artists,  are driven to
find the simplest possible expressions,  and instinctively reject
complicated ones.  The highest praise I can ever give someone,  is that
they have created something simple,  but expressive.

Re: [Caml-list] Some Clarifications

[David Thomas]

ADT's have traditionally been written in OO style. 
The thing that makes "OO programming" different from
traditional programming is that the same methodology
is extended to every component of the program. 
While yes, a stack with "push" and "pop" methods is an
ADT, surely a text widget is not, even if coded in
very much the same style.


--- Ville-Pertti Keinonen <will@exomi.com> wrote:

> David Thomas wrote:
> 
> > Any time you write a program that focuses on the
> > components as "data and operations on that data,"
> > you have written an OO program.  
> 
> Not according to traditional terminology.  What
> you've done is used Abstract Data Types, which is
one 
> of the most basic forms of abstraction that anyone
> should learn in any programming language.
>
> Of course I've seen quite a few programmers who
> don't have enough discipline to use consistent 
> abstractions unless they're forced to encapsulate
> things in classes.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Caml-list] Some Clarifications

[Richard Jones]

On Mon, Jul 25, 2005 at 02:21:27PM +0200, Damien Doligez wrote:
> Then I am still wondering what you are working on, that is so
> high-level that you can only code it in OO, and makes compilation
> and formal methods look simple and low-level.

It's a very advanced AI-based system for trolling newsgroups.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Some Clarifications

[Damien Doligez]

On Jul 24, 2005, at 16:51, Robert Morelli wrote:


> Computer algebra is not all of what mathematical software is about,
>

Then I am still wondering what you are working on, that is so
high-level that you can only code it in OO, and makes compilation
and formal methods look simple and low-level.


-- Damien

Re: [Caml-list] Some Clarifications

[Ville-Pertti Keinonen]

Robert Morelli wrote:

> To be entirely frank,  I am put off by the style of your comments.

My annoyance with regard to your (largely unsubstantiated) points was 
probably apparent in my style.

> If you disagree with my answer to the subject of this discussion,
> you should point the original poster to what you think is a
> discussion of large scale functional design,  or present your own
> explanation for why it doesn't exist.  I would be genuinely interested

What is large-scale OO design, then?

Most of the methodologies (abstraction, layering, tools such as UML) I'm 
aware of translate more-or-less directly to (stateful) FP in general, 
and OCaml in particular as it provides OO abstraction as well as functional.

> in what you have to say.  But instead,  you have chosen to veer off into
> rhetoric,  advocacy,  and ad hominem distractions.  I am puzzled by your

First of all, I apologize if my points appeared to be ad hominem 
attacks, they were not intended as such.  I'm still curious as to your 
amounts of relative experience in different languages and paradigms - 
that was a question, not an attack - and I may have veered too far into 
speculation about common reasons why people may draw the kinds of 
conclusions you seemed to be implying in your posts.  It was 
speculation, not assertion.

> citing points about Erlang and concurrent variants of ML that sound
> superficially to be relevant,  but which have no real bearing on
> anything I said.  I disagree with the frequent use of this mailing list

You were citing increased need for parallelism as a reason for FP to 
become less relevant in the future; I think that specific examples of 
combining concurrency and functional approaches are valid counterexamples.

Please be specific as to why they aren't relevant.

> to irrationally promote OCaml as a superior language to Java.  It is not

What criterion are used to evaluate superiority are of course extremely 
subjective.  Personally I consider expressiveness to be very important. 
  Do you disagree that OCaml is more expressive (i.e. there are more 
things that can be concisely expressed in OCaml but not in Java than 
vice versa)?

If there are things that you find are simple to do in Java (preferably 
as a language rather than through its library collection) but not in 
OCaml, I'd very much like specific examples.

It's entirely valid to disagree on the importance of expressiveness, or 
whether providing a variety of tools for abstraction vs. concentrating 
on a single paradigm is better.

Re: [Caml-list] Some Clarifications

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 24, 2005, at 1:08 AM, Robert Morelli wrote:

> What you've quoted here is a direct and emphatic statement that what I
> wanted to discuss is something I believe is a technical issue,  not a
> conspiracy of large corporations, not an attack on a poster's
> credibility,  not a claim that some broadly useful language is
> horrendously bad,  not rhetorical deceptions,  not advocacy,  not ad
> hominem diversions.  You didn't include it in your quote,  but I also
> pointed out that functional programmers are prone to a  
> counterproductive
> form of advocacy and focus on low level issues and that they have
> generally been unsuccessful at providing practical documentation.   
> I do
> lament that,  and it is directly relevant to the original poster's
> question,  but I primarily raised that point to underline that I  
> believe
> the lack of a "theory" of large scale design issues is not a result of
> it.
>
> You may disagree with me,  and you may find my statements  
> provocative or
> unsettling,  but you cannot claim that I attempted to use a game of
> rhetorical deception,  advocacy,  or ad hominem diversions.

Hmmm. Given your lack of supporting citations or even anecdotes from  
personal experience behind your assertions, I have to take issue with  
your claim of lack of "advocay or ad hominem diversions," if you  
accept the notion of "ad hominem" arguments against a technology.  
Still, let's accept your claim of sincerity. What can those of us who  
do functional programming, particularly because we find it pleasant  
and have come from an extensive object-oriented background, say to that?

The first observation that I would make is that, in my experience,  
object-orientation as we find it in popular programming languages  
either doesn't support large-scale software engineering without  
employing idioms that present issues of their own, such as C++ with  
its lack of a module system and the Pimpl Idiom, lack of virtual  
constructors, bizarre multiple inheritance resolution semantics,  
abstract base classes via the declaration "= 0" trick, etc.) or Java  
with its distinction between primitive types and object types,  
package system  that doesn't enforce a distinction between interface  
and implementation (but at least Java has Interface and Class; it's  
just that using them well is a matter of self-imposed discipline),  
all objects inheriting from One True Object, arrays being a subclass  
of Object but null not being, all parameter passing effectively being  
by reference (i.e. no value semantics), no polymorphic constructors,  
no enumerations, and so on. Couple this with a general lack of  
understanding of the issues in ensuring that object-oriented  
programming respects the contracts expressed in the total context at  
hand: as Peter Norvig has observed, object-oriented programming is a  
discipline that requires you to understand not only what you do  
write, but what you don't. This observation led to Betrand Meyer's  
Eiffel language and "Object-Oriented Software Construction, 2nd ed."  
It's also led to the Liskov Substitutability Principle, the  
definition of which is a question I use in interviews, and it never  
ceases to amaze me how many programmers don't know it, and even if  
they do know its definition, violate it in their code. By the way,  
OOSC is one of the handful of volumes in the OO world that lends  
credence to your claim that OO has theory behind it. Abadi and  
Cardelli's "A Calculus of Objects" is one of the few others. But the  
issues in object-orientation are very real, even if you are  
extraordinarily careful to separate interface from implementation and  
adhere to the Liskov Substitutability Principle; see <http:// 
okmij.org/ftp/Computation/Subtyping/> for details. Basically, a  
common problem in object-oriented programming is the confusion of  
subtyping and subclassing, as Oleg's explanations help clarify.

An unfortunate upshot of the poor modularization support of C++ and  
Java is that C++ and Java programmers tend to turn classes into  
structural dumping grounds. I've been guilty of this myself on rare  
occasions, and even more often have been guilty of not correcting it  
when I've been maintaining someone else's code, just because I've  
judged that schedule pressures don't allow for such refactoring  
efforts. One reason that it may seem that there's more "theory of  
large-scale design" in object-orientation is precisely because the  
industry has had to identify idioms--that is, extra-lingual localized  
coding patterns--and patterns--slightly-larger-scale combinations of  
idioms that reflect a concept that lacks direct expression in the  
language family in question--to work around the problems with object- 
orientation as we find it in these popular languages. For example,  
<http://norvig.com/design-patterns/> helps explain that "16 of 23  
patterns have qualitatively simpler implementation in Lisp or Dylan  
than in C++ for at least some uses of each pattern." It's also worth  
noting that functional programming is making its way into C++, most  
apparently thanks to the Standard Template Library and its  
"functional" header and standard algorithms, but also by way of more  
featureful libraries such as Boost Lambda, the Phoenix library hiding  
inside Boost Spirit, or <http://www.cc.gatech.edu/~yannis/fc++/>. At  
the latter site, we also find a very interesting paper, "FC++:  
Functional Tools for OO Tasks."

So what are the aspects of functional languages in general, and  
O'Caml in particular, that I find to support good large-scale  
software engineering?

1) higher-order functions
2) structural, vs. nominal, typing
3) an excellent module system, with functors
4) an excellent object system leveraging all of the above, with C++- 
level power, but much more safety
5) good libraries leveraging all of the above
6) an excellent community leveraging all of the above

Witness, e.g. the thread regarding "The right way to do this in  
O'Caml?" it deals with some subtle issues and comes up with some very  
helpful answers, while also helping to identify some outstanding  
questions.

Having said all of this, I can't help but suspect that there are some  
things that we'll just have to agree to disagree about, e.g. that  
"language tools" and "formal methods" are simple domains. I also see  
some unique benefits in functional programming for mathematics,  
whether symbolic or concrete, but there are others here who either  
have chimed in on those subjects, or can do so much more ably than I  
can. All I wanted to do what to provide some pointers to some  
explanations of what some of the issues in OO are, some of the pluses  
of functional programming are, and leave you to examine them at your  
leisure. Given your particular focus on programming-in-the-large, let  
me particularly recommend the literature on module systems. The  
papers on O'Caml's module system can serve as an excellent starting  
point.

Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iEYEARECAAYFAkLj4zMACgkQO3fYpochAqLPGgCgv+pXvI9Sd1DuWrJXe3hV4tF2
yy8An3nBP8fhTU3Cm28YGpttZpjOXhUz
=ZDOi
-----END PGP SIGNATURE-----

Re: [Caml-list] Some Clarifications

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Sun, 2005-07-24 at 02:08 -0600, Robert Morelli wrote:
> but I primarily raised that point to underline that I believe
> the lack of a "theory" of large scale design issues is not a result of
> it.

Well, in my opinion, there is no 'theory' of large scale design
for Object Orientation, whilst there IS a theory for
functional programming. 

Attempts have been made to develop OO theory, but the result
primarily discredits OO, rather than supporting it:
the so-called 'covariance problem' basically destroys
class based (statically typed) object orientation as
a paradigm.

On the other hand, functional people DO have a well
founded, elegant, long standing theoretical framework.
Perhaps I might agree that Lambda Calculus is a low
level theory .. but I am referring instead to a theory
of abstraction at all levels: namely, Category Theory.
CT subsumes lambda calculus, it has provided the inspiration
for the ML language family module system, and the fundamental
data types: tuples/records, variants, and of course
function closures.

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Some Clarifications

[David MENTRE]

Robert Morelli <morelli@cs.utah.edu> writes:

> Several years ago I read a paper about a computer algebra system
> written in OCaml called FOC.  The title of the paper was something
> like "Functors,  blah,  blah,  ... Is it Too Much?"  I think the
> conclusion of the paper was that FOC naturally drew upon all of OCaml's
> language facilities,  both functional and object oriented.  This paper
> might speak to the demands of the domain for anyone who is curious
> enough to look it up.  Of course,  we can equally well ask,  "Is it
> Enough?"

http://www.lip6.fr/fr/production/publications-rapport-fiche.php?RECORD_KEY%28rapports%29=id&id(rapports)=139

Yours,
d.
-- 
pub  1024D/A3AD7A2A 2004-10-03 David MENTRE <dmentre@linux-france.org>
 5996 CC46 4612 9CA4 3562  D7AC 6C67 9E96 A3AD 7A2A

Re: [Caml-list] Some Clarifications

[Robert Morelli]

Damien Doligez wrote:
> On Jul 19, 2005, at 22:14, Robert Morelli wrote:
> 
> 
>> One of the areas where I do much of my programming is in mathematical
>> software.  I view this as one of the most difficult areas,  at the
>> opposite extreme from simple domains like formal methods and language
>> tools.
>>
> 
> Since computer algebra is clearly a subset of formal methods, and a
> pretty good match for OCaml's feature set, I'm rather curious to know
> exactly what kind of mathematical software you are writing, that can
> be so much more complex.

Computer algebra is not all of what mathematical software is about,  and
computer algebra is not,  in practice,  a subset of formal methods.  The
communities of researchers who work in the two fields are traditionally
quite distinct,  with distinct immediate goals,  and the research is
funded and evaluated differently.  For instance,  the NSF in the US
funds several different kinds of computational mathematics research
through several different programs,  and funds formal methods research
through several different programs.

In principle,  the two fields should be merged -- at least in part --
and that is very clearly the vision of some people (though not all).
In practice,  there have been initiatives to bring the two fields
together,  but up until now that has been considered a challenging
interdisciplinary endeavor.

Several years ago I read a paper about a computer algebra system
written in OCaml called FOC.  The title of the paper was something
like "Functors,  blah,  blah,  ... Is it Too Much?"  I think the
conclusion of the paper was that FOC naturally drew upon all of OCaml's
language facilities,  both functional and object oriented.  This paper
might speak to the demands of the domain for anyone who is curious
enough to look it up.  Of course,  we can equally well ask,  "Is it
Enough?"

Re: [Caml-list] Some Clarifications

[Gerd Stolpmann]

Am Samstag, den 23.07.2005, 18:04 -0600 schrieb Robert Morelli:
> To be entirely frank,  I am put off by the style of your comments.
> If you disagree with my answer to the subject of this discussion,
> you should point the original poster to what you think is a
> discussion of large scale functional design,  or present your own
> explanation for why it doesn't exist.  I would be genuinely interested
> in what you have to say.  But instead,  you have chosen to veer off into
> rhetoric,  advocacy,  and ad hominem distractions.  I am puzzled by your
> citing points about Erlang and concurrent variants of ML that sound
> superficially to be relevant,  but which have no real bearing on
> anything I said.  I disagree with the frequent use of this mailing list
> to irrationally promote OCaml as a superior language to Java.  It is not
> an advocacy forum,  and I will not be drawn into criticizing OCaml's
> object system in this context.  When I crave irrational discussions,  I
> visit slashdot.  I am disappointed that you have resorted to ad
> hominem distractions,  projecting knowledge or "feelings" on me of
> issues outside of,  and irrelevant to,  what I stated,  and which do not
> represent my own feelings or anything I wish to discuss here.

I really doubt you know what you are speaking about (or, in other words,
we have a very different perception). First, I don't see that there is
very much advocacy on this list. Sometimes there are threads where
language features are compared, and it is very clear that a language
with many features like OCaml wins over a language with intentionally
few features like Java. There is almost always a more concise expression
for the same in OCaml. But this isn't advocacy, it is just an
observation. It doesn't mean that OCaml is the better language in
general.

Second, about "large-scale". I really wonder what your point is. OCaml
has a number of features that are a good basis for large programs.
Obviously, this list ignores all these features in its advocacy. Just to
bring them to your knowledge:

- OCaml has a quite strong definition, in the sense every expression
  has a clear meaning. This is very important for large programs,
  because it reduces unwanted effects.

- OCaml is statically typed, and its type system is much richer than
  the systems of pure OO languages. It is common practise to model the
  base lines of large programs by first designing the types one wants
  to use.

- Types may be polymorphic, to support reuse of code.

- OCaml has a module system. It is easy to implement a "separations
  of concerns" strategy by modularising the program.

- OCaml allows opaque types. This supports the "information hiding"
  which is also a large-scale strategy. There are also design techniques
  like abstract data types.

- The modules have a signature. It is possible to design the module
  system in advance (i.e. before implementation) by specifying the
  signature.

- OCaml allows separate compilation.

Note that all these large-scale features aren't special to functional
programming (but are compatible with it). In this sense, your original
thesis is correct. It is just the case that the conventional strategies
of large-scale design can also be applied to functional programs. Maybe
this is the reason why you don't find a thread about it.

As you mention Java: Of course, there are lot of books about large-scale
programming, because it is unclear from the language definition how to
do it. There is only a quite overloaded class system (which is also a
module system and also a type system), and it is the question how to use
the class system to get the effects of strategies like "separations of
concerns". (Note that the "design patterns" have little to do with this,
they are "low-level".)

I hope this message answers at least the question of the original poster
and gives some hints where to look.

Gerd

> In case you,  or anyone else,  is genuinely confused by what I said,
> I will make a further clarification in a separate post.
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Telefon: 06151/153855                  Telefax: 06151/997714
------------------------------------------------------------

Re: [Caml-list] Some Clarifications

[David Teller]

Could you please take this part of the thread off-list ?

The discussion on FP was interesting for everyone. The inter-person
fight is not.

Cheers,
 David

Le dimanche 24 juillet 2005 à 02:08 -0600, Robert Morelli a écrit :
> What you've quoted here is a direct and emphatic statement that what I
> wanted to discuss is something I believe is a technical issue,  
[...]

-- 
Read, Write, and Publish Standard eBooks
  Free, Open Software, Open Standards and multi-platform
    The OpenBerg project http://www.openberg.org

Re: [Caml-list] Some Clarifications

[Robert Morelli]

What you've quoted here is a direct and emphatic statement that what I
wanted to discuss is something I believe is a technical issue,  not a
conspiracy of large corporations, not an attack on a poster's
credibility,  not a claim that some broadly useful language is
horrendously bad,  not rhetorical deceptions,  not advocacy,  not ad
hominem diversions.  You didn't include it in your quote,  but I also
pointed out that functional programmers are prone to a counterproductive
form of advocacy and focus on low level issues and that they have
generally been unsuccessful at providing practical documentation.  I do
lament that,  and it is directly relevant to the original poster's
question,  but I primarily raised that point to underline that I believe
the lack of a "theory" of large scale design issues is not a result of
it.

You may disagree with me,  and you may find my statements provocative or
unsettling,  but you cannot claim that I attempted to use a game of
rhetorical deception,  advocacy,  or ad hominem diversions.

One point which might help clarify my attitude,  is that my hostility is
to advocacy on this mailing list,  not to any particular language or
paradigm.  Advocates of OCaml might misinterpret my hostility to
advocacy as a hostility to OCaml.  That would be quite off the mark,
but I do not see a good justification for further elaborating my
personal attitudes here.


Paul Snively wrote:
> On Jul 23, 2005, at 5:04 PM, Robert Morelli wrote:
> 
>> To be entirely frank,  I am put off by the style of your comments.
> 
> 
> Considering that you're the one who joined the thread by saying:
> 
> "This seems as good a time as any to delurk and jump on a soap box"  and 
> "The FP paradigm is intrinsically poorly adapted to the kind of  large 
> scale design concepts that concern most programmers.  Object  oriented 
> programming is a much better match,  not because of a  conspiracy of 
> commercial giants in the software tool business,  but  because of 
> intrinsic technical reasons.  Functional programming is a  niche 
> technology ideally suited to simple domains like language tools  and 
> formal methods.  It does not have much to say about complicated  
> systems," I have to say that complaining about the style of others'  
> comments here takes considerably bigger brass balls than I possess.  
> Congratulations.
> 
> Best regards,
> Paul Snively

Re: [Caml-list] Some Clarifications

[Alex Baretta]

Paul Snively wrote:
> 
> On Jul 23, 2005, at 5:04 PM, Robert Morelli wrote:
> 
>>> To be entirely frank,  I am put off by the style of your comments.
>
> Considering that you're the one who joined the thread by saying:
> 
> I have to say that complaining about the style of others' 
> comments here takes considerably bigger brass balls than I possess. 
> Congratulations.


Our friend is just a troll. We (I) should take the habit of ignoring the
ignorant.

Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

Re: [Caml-list] Some Clarifications

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 23, 2005, at 5:04 PM, Robert Morelli wrote:

> To be entirely frank,  I am put off by the style of your comments.

Considering that you're the one who joined the thread by saying:

"This seems as good a time as any to delurk and jump on a soap box"  
and "The FP paradigm is intrinsically poorly adapted to the kind of  
large scale design concepts that concern most programmers.  Object  
oriented programming is a much better match,  not because of a  
conspiracy of commercial giants in the software tool business,  but  
because of intrinsic technical reasons.  Functional programming is a  
niche technology ideally suited to simple domains like language tools  
and formal methods.  It does not have much to say about complicated  
systems," I have to say that complaining about the style of others'  
comments here takes considerably bigger brass balls than I possess.  
Congratulations.

Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iEYEARECAAYFAkLi/W0ACgkQO3fYpochAqLl1gCffYj4LbbCOlQqRijBrME7v38/
jJkAnR2d6aCqCfBFS3yB/19Jn+xcdfPj
=4L0x
-----END PGP SIGNATURE-----

Re: [Caml-list] Some Clarifications

[Robert Morelli]

To be entirely frank,  I am put off by the style of your comments.
If you disagree with my answer to the subject of this discussion,
you should point the original poster to what you think is a
discussion of large scale functional design,  or present your own
explanation for why it doesn't exist.  I would be genuinely interested
in what you have to say.  But instead,  you have chosen to veer off into
rhetoric,  advocacy,  and ad hominem distractions.  I am puzzled by your
citing points about Erlang and concurrent variants of ML that sound
superficially to be relevant,  but which have no real bearing on
anything I said.  I disagree with the frequent use of this mailing list
to irrationally promote OCaml as a superior language to Java.  It is not
an advocacy forum,  and I will not be drawn into criticizing OCaml's
object system in this context.  When I crave irrational discussions,  I
visit slashdot.  I am disappointed that you have resorted to ad
hominem distractions,  projecting knowledge or "feelings" on me of
issues outside of,  and irrelevant to,  what I stated,  and which do not
represent my own feelings or anything I wish to discuss here.

In case you,  or anyone else,  is genuinely confused by what I said,
I will make a further clarification in a separate post.

Re: [Caml-list] Some Clarifications

[Damien Doligez]

On Jul 19, 2005, at 22:14, Robert Morelli wrote:


> One of the areas where I do much of my programming is in mathematical
> software.  I view this as one of the most difficult areas,  at the
> opposite extreme from simple domains like formal methods and language
> tools.
>

Since computer algebra is clearly a subset of formal methods, and a
pretty good match for OCaml's feature set, I'm rather curious to know
exactly what kind of mathematical software you are writing, that can
be so much more complex.

-- Damien

Re: [Caml-list] Some Clarifications

[David MENTRE]

Hello Robert,

[As a side note, you did not answered my question on which software
you consider of large scale. ]

Just two remarks on your post:

2005/7/19, Robert Morelli <morelli@cs.utah.edu>:
> One of the areas where I do much of my programming is in mathematical
> software.  I view this as one of the most difficult areas,  at the
> opposite extreme from simple domains like formal methods and language
> tools.  The problems with characterizing mathematical objects come
> up peripherally here with representations of numbers.  This always leads
> to endless,  inconclusive discussions of issues like operator
> overloading,  inheritance and multiple inheritance,  multiple dispatch,
> multiple views of a data structure,  constraints, etc., etc.

You should take a look at Axiom:
http://page.axiom-developer.org/zope/mathaction/FrontPage

This is an old Computer Algebra System, developed for 30 years at IBM
and now free software (BSD-like license). It has a complete typing of
mathematical expressions. The type system is very different from ML
systems however: no type inference. It is closer to a dynamic OO
language, but the types are not computer types but mathematical ones,
based on mathematical properties of objects (you know more about the
subject than me).

To come back to OCaml, Axiom interactive type system poses interesting
questions regarding type inference and interactive systems.
Mathematical notation is based on operator overloading: use the same
"+" as an operation on matrices or on integers, but the two "+" are
not the same operations, even if they have the same mathematical
properties. ML type systems are very bad when you need to manipulate
objects of different types (in OCaml, you would need +, +., +/, +b,
etc.). Maybe there is some interesting research to be done in that
area. Pierre Weis (of OCaml fame) discussed ones with Tim Daly (Axiom
lead developer) but did not catched the issue (at least this is how I
interpreted the discussion).


> The fundamental point is that OO puts interaction at the
> center of the paradigm,  not abstract characterization.  That has
> huge consequences and it's what makes the whole idea of a "theory"
> of large scale design meaningful.  OO commits to a certain way of
> organizing interaction,  state changes,  behavior changes, ....  that's
> attractive in practice (but requires deeper theory than FP).

I disagree on most of your arguments when comparing OO et FP (for the
same reasons as others have developed on the previous thread).
However, I agree on issues regarding  interactivity and ML typing, and
more generally on the rigid aspects of ML typing in *certain*
contexts.

As a programmer, ML typing is very rigid and this is a good point: I'm
sure that in all over my program, the datastructure is *never* misued
and that certain invariants are ensured. ML typing and moreover type
inference is a must have for library programmers.

However, as an interactive user (cf. my above comment on Axiom) or as
a system architect, I sometimes misses the flexibility of dynamic OO
system. Ok, they allow the system to be incoherent, but this is
sometimes *useful*, for example when you refactor a big system and you
want to test a subset of your modifications. The other point, as I
said, is the use of overloading. It is natural in dynamic OO systems,
it is very unpleasant in OCaml (although I haven't dug into GCaml, I
had a bad experience with OCaml objects).

I sometimes dream of a system that would allow me to have *both*
static typing and type inference like ML and dynamic typing like Lisp
or OO languages. The best of both worlds! :) In my opinion, the
interesting part is how to mix the two paradigms smoothly, e.g. how to
have meaningful error messages, how to define types for certain
objects but let the type inference system do the job for most of my
code, etc.

Yours,
d.

PS: formal methods or language tools are *not* simple domains! :-)

Re: [Caml-list] Some Clarifications

[Ville-Pertti Keinonen]

Robert Morelli wrote:

> In the interests of saving time,  and keeping my post to a palatable

I'll only comment on a couple of points for the same reason...

> just the tip of the iceberg.  I find that the facilities of a language
> like OCaml are so inadequate to represent this domain,  that using
> OCaml can be a distinct impediment.  Sometimes Java is a better fit.

Which do you have more experience in, OCaml or Java?  Or FP vs. OO 
languages in general?

Unless you are highly experienced in both, your view of OCaml as an 
impediment might merely be an indication that you don't know the 
language and the associated styles of abstraction sufficiently well. 
Remember, OCaml is a multi-paradigm language, and the paradigms include OO.

The reason I'm pointing this out is that there are very few things that 
Java, as a language, is capable of that don't translate easily to OCaml 
(type-narrowing casts, explicit - extremely clunky - introspection, 
neither of which are usually considered good OO practice).  OCaml 
provides a huge amount of things that don't easily translate to Java, 
even in the OO area (separation of subtyping and inheritance, multiple 
inheritance, binary methods etc.), and learning to make use of them 
effectively requires experience.

Even for an OO language, Java is horribly clunky and limited.  The 
reasons for its popularity are almost certainly familiarity, library 
functionality and commercial backing, it can't possibly be the merits of 
the language itself.

> 4. Over the decades,  both hardware and software technologies have
> inexorably evolved toward networked,  decentralized,  componentized
> systems.  Even CPU's are now trending toward multicore designs.  This
> makes the sequential computational model that FP is based on seem less
> and less central.

Really?  Avoiding mutable state is a good way of making concurrent 
programming convenient and reliable.

See e.g. Erlang for a very much real-world example.

Also consider a couple of multi-paradigm (with good FP features) 
languages with very good support for concurrent and distributed 
programming - Oz, Alice ML.

All of these are capable of running several orders of magnitude more 
threads than Java efficiently.  As is CML, which is the lightest-weight 
of them all, but also the least practical.

Unlike multithreading in mainstream languages, where it's just a 
bolted-on feature, resulting in extremely heavyweight threads and a 
default concurrency model of shared-state concurrency (which is the most 
error-prone) these systems treat concurrency as a programming paradigm.


Most of your arguments seem to be centered around either your personal 
"feeling" of what OO is and what it's capable of (which is why I'm 
interested in how much experience you have in different kinds of 
languages) or rationalizations based on a belief in correlation between 
popularity and merit (obviously popularity will go hand in hand with the 
availability of literature and tools, but none of those are defining 
factors in terms of the technical or scientific merit of a paradigm, 
technology, language or anything else).

Note that I'm not arguing against OO, I consider it a very useful 
programming paradigm, but it is not sufficient and it is vastly over- 
and misused by the mainstream because they don't know anything else.  I 
consider multi-paradigm languages such as OCaml the most powerful and 
practical programming tools.