(Mostly) Functional Design?

(Mostly) Functional Design?

[Kyle Consalus]

There are a wealth of resources related to object oriented design techniques
(which can certainly be applied to OCaml), but I've been pretty much unable
to find any good resources on large scale design of functional programs.
I realize that this is the sort of thing that develops over time with
experience.
Just the same, there is (most likely) a lot to learn and consider, and a 
resource would be helpful. My recent uses of OCaml for fairly small projects
have been effective, but a lot of things were cumbersome in the design
and I suspect that I may be thinking about it wrong.
So, could anyone suggest a good resource or perhaps weigh
in on their thoughts on the topic?

Thanks,

Kyle

Re: [Caml-list] (Mostly) Functional Design?

[Robert Morelli]

I've been lurking on this list for several years.  This seems as good a
time as any to delurk and jump on a soap box.

I think you've put your finger on one of the main reasons functional
languages have failed to attract significant use beyond a few niche
areas.

I contend:
   1.  The FP community tends to emphasize low level issues rather than 
the larger scale issues that concern most programmers.  It is also
inept at practical documentation and advocacy.
   2.  There isn't much of a theory of large scale functional design.
At least,  there is no consensus.
   3.  Point 2. is not the consequence of point 1.;  it's not simply a
matter of communication,  but an instrinsic void in the FP paradigm.
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.


Kyle Consalus wrote:
> There are a wealth of resources related to object oriented design techniques
> (which can certainly be applied to OCaml), but I've been pretty much unable
> to find any good resources on large scale design of functional programs.
> I realize that this is the sort of thing that develops over time with
> experience.
> Just the same, there is (most likely) a lot to learn and consider, and a 
> resource would be helpful. My recent uses of OCaml for fairly small projects
> have been effective, but a lot of things were cumbersome in the design
> and I suspect that I may be thinking about it wrong.
> So, could anyone suggest a good resource or perhaps weigh
> in on their thoughts on the topic?
> 
> Thanks,
> 
> Kyle

Re: [Caml-list] (Mostly) Functional Design?

[Alex Baretta]

Robert Morelli wrote:

> I contend:
>   1.  The FP community tends to emphasize low level issues rather than
> the larger scale issues that concern most programmers.  It is also
> inept at practical documentation and advocacy.
>   2.  There isn't much of a theory of large scale functional design.
> At least,  there is no consensus.
>   3.  Point 2. is not the consequence of point 1.;  it's not simply a
> matter of communication,  but an instrinsic void in the FP paradigm.
> 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.

Your points are very simply wrong. Functional design addresses the same
large-scale design problems that OO tries to address, and, in fact,
given cognitive compatibility with the mind of the developere, it offers
a productivity at least an order of magnitude greater on very large
scale projects (over 100klocs) where the dominant cost factor is code
maintenance. Ocaml's functional paradigm greatly stresses a priori
correctness via static type-checking, which we take advantage of to
achieve static verification of the Embedded SQL queries in our FreerP
suite of business applications. It is only thanks to the rich type
system in Ocaml that we are able to maintain coherence between a
database schema counting hundreds of relations and hundreds of Xcaml
server pages containing at least as many embedded SQL queries. Java
simply would not scale.

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] (Mostly) Functional Design?

[Alex Baretta]

Andrej Bauer wrote:
> Dear Alex,
> 
> I was silly enough to write to you _before_ looking at the xcaml web
> page. I think I can find my answers there.

I am painfully slow at putting up some code for the community to look
at. The trouble is that, although we are a free software company, we
tend to (find the time to) release our code only when we are paid to do so.

***

The Xcaml paradigm only partly solves your issues. It is aimed at
guarateeing coherence in a very large scale ERP application, which
implies that we have worked a lot on guarateeing static type safety in
queries. We have still not finished implementing the Xcaml2 API, which
will include proper static verification of HTML forms.

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] (Mostly) Functional Design?

[Robert Morelli]

Alex Baretta wrote:
 > Your points are very simply wrong. Functional design addresses the same
 > large-scale design problems that OO tries to address, and, in fact,
 > given cognitive compatibility with the mind of the developere, it offers
 > a productivity at least an order of magnitude greater on very large
 > scale projects (over 100klocs) where the dominant cost factor is code
 > maintenance. Ocaml's functional paradigm greatly stresses a priori

With all due respect,  claims of order of magnitude productivity
gains,  that OCaml is a far better language than Java,  etc.  are
exactly the kind of advocacy that I think is counterproductive.
Most programmers would regard such dramatic statements as implausible,
if not preposterous.

 > correctness via static type-checking, which we take advantage of to
 > achieve static verification of the Embedded SQL queries in our FreerP
 > suite of business applications. It is only thanks to the rich type
 > system in Ocaml that we are able to maintain coherence between a
 > database schema counting hundreds of relations and hundreds of Xcaml
 > server pages containing at least as many embedded SQL queries. Java
 > simply would not scale.

The use of type checking is a point where the FP community
has not reached consensus,  as there are widely divergent views from
the Scheme community and the ML and Haskell communities.  Even between
ML and Haskell,  there are significant differences in the treatment of
imperative features,  type inference,  objects and type classes,  etc.
These differences,  it seems to me,  are more fundamental than anything
you find in the OO world,  even the difference between,  say,  Java
and Smalltalk.

Moreover,  ML's traditional emphasis on type inference,  among other
things,  puts demands and limitations on the type system.  Is type
inference worth it?  Is there a consensus?  In fact,  most of the
features that lie above the level of lambda calculus and syntactic
sugar,  including the type system,  of FP langaugaes like OCaml seem
more or less arbitrary to me.  Personally,  I see the OCaml type
system as relatively weak.  I'm intrigued by very powerful features
like dependent types,  and I think they are dismissed too quickly by the
mainstream of the FP community.  But that's just my view.  There's
no consensus.

In general,  I believe that OCaml and its approach to static typing
are best suited to simple domains,  like language tools and formal
methods.  These are characterized by dealing with objects which can
be completely characterized by simple universal properties.  This
fits well with the category theoretic foundation of the language.
But there are relatively few areas where you have such luxury,
and even when it's possible,  finding the perfect characterization
often requires rare intellectual gifts.

I am not familiar with your FreerP technology and its use of Xcaml,
but I will not dispute your claim of great success.  It just seems
likely to me that you've taken advantage of uncommon insight to
cast your problems into a new sort of niche application.  Relational
algebra is after all not so far from category theory.  Perhaps you've
found an approach that could be used in many more applications to
business.  If so,  I wish you success.

Re: [Caml-list] (Mostly) Functional Design?

[Alex Baretta]

Robert Morelli wrote:
> Alex Baretta wrote:
>> Your points are very simply wrong. Functional design addresses the same
>> large-scale design problems that OO tries to address, and, in fact,
>> given cognitive compatibility with the mind of the developere, it offers
>> a productivity at least an order of magnitude greater on very large
>> scale projects (over 100klocs) where the dominant cost factor is code
>> maintenance. Ocaml's functional paradigm greatly stresses a priori
> 
> With all due respect,  claims of order of magnitude productivity
> gains,  that OCaml is a far better language than Java,  etc.  are
> exactly the kind of advocacy that I think is counterproductive.
> Most programmers would regard such dramatic statements as implausible,
> if not preposterous.

As of today, I am unable to compute any software metric over my repo,
including the banal and meaningless klocs. This is due to the need to
develop faster than the tree maintainer--that is, I--can verify
changesets and commit them to a repo. Currently, my collegues are
working each on his own tree and producing tarballs as backups, which
pile up waiting for me to merge them.

Since I cannot give you numbers, let me give you ideas about what we
did: we have written a compiler for a functional web oriented
language--the Xcaml--which is to Ocaml what JSP is to Java; we have
written a virtual machine for this language implementing the execution
model for an Xcaml application; since Xcaml needs a very strong level of
intgration with relational DBs, we developed the Xcaml DataBase
Specification language and toolchain, which compiles OO-ER models down
to logical, physical and virtual DB schemas--thus supporting design
refinement at the intermediate level--and compiles the whole thing to
SQL-DDL and to Ocaml database access libraries; the Embedded SQL is a
syntax extension to Ocaml which compiles SQL queries to calls to the
data access libraries generated by the XDBS, thus delegating static
typechecking of SQL queries to the Ocaml type system. Collaterally we
have developed Machiavelli: a event-driven asynchronous servlet
framework, working behind the scenes of the Xcaml application to perform
long running computations that would lock the HTTP user agent for too
long. On top of all this we are developing FreerP--a full fledged ERP
application. We are almost there: FreerP currently manages sales, stock
inventory, logistics, accounting. Besides all this we have developed
Schopenhauer, a realtime soft PLC/CNC based on Ocaml, which we use to
control industrial equipment such as glass cutting machines or metal
sheet cutting machines. Schopenhauer has a seemless integration with the
Xcaml system, so that user interfaces can be based on the web, and can
easily take advantage of the powerful database API. Schopenhauer is
actually our most successful technology commercially, at least this year.

Now, how many man years have gone into this: about 5. I can guarantee
that with Java this would not be feasible.

>> correctness via static type-checking, which we take advantage of to
>> achieve static verification of the Embedded SQL queries in our FreerP
>> suite of business applications. It is only thanks to the rich type
>> system in Ocaml that we are able to maintain coherence between a
>> database schema counting hundreds of relations and hundreds of Xcaml
>> server pages containing at least as many embedded SQL queries. Java
>> simply would not scale.
> 
> The use of type checking is a point where the FP community
> has not reached consensus,  as there are widely divergent views from
> the Scheme community and the ML and Haskell communities.  Even between

I am not advocating FP languages. I am advocating type-checking over
everything else and Ocaml as the most productive language I have ever seen.

> I am not familiar with your FreerP technology and its use of Xcaml,
> but I will not dispute your claim of great success.  It just seems
> likely to me that you've taken advantage of uncommon insight to
> cast your problems into a new sort of niche application.  Relational
> algebra is after all not so far from category theory.  Perhaps you've
> found an approach that could be used in many more applications to
> business.  If so,  I wish you success.

Thank you. I wish ourselves as much. I might have had some clever ideas,
but mainly I have taken advantage of what the type system gives me:
deferred binding of recursive calls, extensional polymorphism and
recursive types, a tiny bit of OO (I miss Javascripts delegation so
much!), a couple of recursive modules, iterators, high level
datastructures such as sets, maps and real-time deques. We have also
used an old-time Obj.magic hack to achieve polymorphic recursion in one
function which simply could not be done without it. But I have a
correctness proof ;)

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] (Mostly) Functional Design?

[padiolea]

> Alex Baretta wrote:
>  > Your points are very simply wrong. Functional design addresses the same
>  > large-scale design problems that OO tries to address, and, in fact,
>  > given cognitive compatibility with the mind of the developere, it
> offers
>  > a productivity at least an order of magnitude greater on very large
>  > scale projects (over 100klocs) where the dominant cost factor is code
>  > maintenance. Ocaml's functional paradigm greatly stresses a priori
>
> With all due respect,  claims of order of magnitude productivity
> gains,  that OCaml is a far better language than Java,  etc.  are
> exactly the kind of advocacy that I think is counterproductive.

I agree. I think there is no silver bullet, and since the
ICFP programming contests I now realise that what matters are not
programming langages, but programmers. Good programmers even
in langage such as C by using advanced features such as function pointers,
macros can emulate higher order code, objects, ...

Nevertheless, I think that on the avergage, average programmers
can be better by using langage such as ocaml. It is just
that what you do by careful programming/experience/design-patterns
in some langages, is directly supported in other langage and so
easier for the average programmer to use.

There is some study comparing lisp, tcl, java, ... done on students
to solve a simple example and the numbers speaks for themselves.
Again, have a look at peter norvig webpage.
Recently richard jones have made a webpage where he presents
side by side the code of a raytracer done in caml and one done in c++.
This page is very interesting because there is no long boring
advocacy (such as what I am doing now) but a practical example.

> Most programmers would regard such dramatic statements as implausible,
> if not preposterous.

Yes I know, truth is sometimes hard to hear :)

You also have to realise that many features of java come from
the fp community: garbage collection,  generics,
and if I remember listeners for implementing callbacks
are examples of anonymous and higher order functions. In fact
Java was invented in part by golsing and steele who extensively
worked on scheme.
And in the same way some features of oo community have come in
the fp community (there is objects in ocaml),
or have influenced the fp commununity (there is type class in haskell)
It is not a black&white world.


>
>  > correctness via static type-checking, which we take advantage of to
>  > achieve static verification of the Embedded SQL queries in our FreerP
>  > suite of business applications. It is only thanks to the rich type
>  > system in Ocaml that we are able to maintain coherence between a
>  > database schema counting hundreds of relations and hundreds of Xcaml
>  > server pages containing at least as many embedded SQL queries. Java
>  > simply would not scale.
>
> The use of type checking is a point where the FP community
> has not reached consensus,

The same can be said in the OO community. Smalltalk, Clos, Self, Dylan
are weakly typed.
Java was also in some way weakly typed but since 1.5 with generics,
it is now better.

> as there are widely divergent views from
> the Scheme community and the ML and Haskell communities.  Even between
> ML and Haskell,  there are significant differences in the treatment of
> imperative features,  type inference,  objects and type classes,  etc.
> These differences,  it seems to me,  are more fundamental than anything
> you find in the OO world,

There are many differences in the oo world too, regarding covariance,
multiple inheritance, typing, ...

>  even the difference between,  say,  Java
> and Smalltalk.
>
> Moreover,  ML's traditional emphasis on type inference,  among other
> things,  puts demands and limitations on the type system.  Is type
> inference worth it?

yes :)

> Is there a consensus?

There is rarely consensus when it comes to programming langage, or
even programming tools.

> In fact,  most of the
> features that lie above the level of lambda calculus and syntactic
> sugar,  including the type system,  of FP langaugaes like OCaml seem
> more or less arbitrary to me.  Personally,  I see the OCaml type
> system as relatively weak.

So you think the same for java I guess.

> I'm intrigued by very powerful features
> like dependent types,  and I think they are dismissed too quickly by the
> mainstream of the FP community.  But that's just my view.  There's
> no consensus.
>
> In general,  I believe that OCaml and its approach to static typing
> are best suited to simple domains,

please stop qualifying  langage tools and formal methods as simple domains.

>  like language tools and formal
> methods.  These are characterized by dealing with objects which can
> be completely characterized by simple universal properties.  This
> fits well with the category theoretic foundation of the language.

I dont really understant what you mean here.

> But there are relatively few areas where you have such luxury,
> and even when it's possible,  finding the perfect characterization
> often requires rare intellectual gifts.
>
>

Re: [Caml-list] (Mostly) Functional Design?

[Jon Harrop]

On Monday 18 July 2005 19:56, padiolea@irisa.fr wrote:
> Recently richard jones have made a webpage where he presents
> side by side the code of a raytracer done in caml and one done in c++.
> This page is very interesting because there is no long boring
> advocacy (such as what I am doing now) but a practical example.

Do you mean my pages?

  http://www.ffconsultancy.com/free/ray_tracer/comparison.html
  http://www.ffconsultancy.com/free/ray_tracer/languages.html

I'd like to make more practical comparisons of such languages but I think this 
simple ray tracer is especially good because it packs so many different 
problems into a single program. As you say, the results speak for themselves.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Technical Presentation Software
http://www.ffconsultancy.com/products/presenta

Re: [Caml-list] (Mostly) Functional Design?

[Jon Harrop]

On Monday 18 July 2005 19:15, Robert Morelli wrote:
> With all due respect,  claims of order of magnitude productivity
> gains,  that OCaml is a far better language than Java,  etc.  are
> exactly the kind of advocacy that I think is counterproductive.
> Most programmers would regard such dramatic statements as implausible,
> if not preposterous.

Although "preposterous", I agree that OCaml is an order of magnitude more 
productive than C++. I also agree that code maintainance is the main reason 
for this.

> The use of type checking is a point where the FP community
> has not reached consensus,  as there are widely divergent views from
> the Scheme community and the ML and Haskell communities.

I have seen huge improvements in productivity only from statically typed 
languages. More importantly, I can do many things in OCaml which I could not 
have done in C++ because they were practically impossible.

> In general,  I believe that OCaml and its approach to static typing
> are best suited to simple domains,  like language tools and formal
> methods.

Firstly, those domains are not simple (quite the opposite, in fact!). 
Secondly, OCaml has already been applied with great success to many, wildly 
different problem domains. For example, we have found OCaml to be very 
beneficial in the areas of scientific computing and graphics. The fact that 
people like Alex and I are able to run our companies this is a testament to 
this fact.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Technical Presentation Software
http://www.ffconsultancy.com/products/presenta

Re: [Caml-list] (Mostly) Functional Design?

[skaller]

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

On Mon, 2005-07-18 at 12:15 -0600, Robert Morelli wrote:

> With all due respect,  claims of order of magnitude productivity
> gains,  that OCaml is a far better language than Java,  etc.  are
> exactly the kind of advocacy that I think is counterproductive.
> Most programmers would regard such dramatic statements as implausible,
> if not preposterous.

Yes they would .. until they tried it.

-- 
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] (Mostly) Functional Design?

[Alwyn Goodloe]

We have to be cautious here. For about three years I was involved in
evaluating technology for a large organization. Like most organizations,
about 1/3 of the development was your standard GUI entry/SQL querries.
Like most shops we wanted to pick something modern that was good for
apps as well as had a great GUI/SQL interface. Java worked well for us.
If someone came to me with and showed me a language that made 2/3 of
my developers more productive, I would be quite happy. But here is the
killer -- I have to ask about the other 1/3. We were trying to get away
from supporting multiple languages. Its a nightmare from a support
perspective. So my next question is about your GUI development
environment. Is it  as good as the others on the market? There are a lot
of  considerations that go into picking a language. With the execption of
scripting languages, tools play a big part in this decision as do other
factors.

On Tue, 19 Jul 2005, skaller wrote:

> On Mon, 2005-07-18 at 12:15 -0600, Robert Morelli wrote:
>
> > With all due respect,  claims of order of magnitude productivity
> > gains,  that OCaml is a far better language than Java,  etc.  are
> > exactly the kind of advocacy that I think is counterproductive.
> > Most programmers would regard such dramatic statements as implausible,
> > if not preposterous.
>
> Yes they would .. until they tried it.
>
> --
> John Skaller <skaller at users dot sourceforge dot net>
>
>

Re: [Caml-list] (Mostly) Functional Design?

[Paul Snively]

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


On Jul 18, 2005, at 2:27 PM, skaller wrote:

> On Mon, 2005-07-18 at 12:15 -0600, Robert Morelli wrote:
>
>
>> With all due respect,  claims of order of magnitude productivity
>> gains,  that OCaml is a far better language than Java,  etc.  are
>> exactly the kind of advocacy that I think is counterproductive.
>> Most programmers would regard such dramatic statements as  
>> implausible,
>> if not preposterous.
>>
>
> Yes they would .. until they tried it.
>
I'm going to allow myself to be guilty of exactly what I deplored  
about the original e-mail, namely offering personal opinions and  
anecdotes without citations or sources of any kind. :-)

Although I had the great good fortune to learn Scheme as my third  
language after BASIC and Z-80 assembly language and to attend Indiana  
University and hobknob with the likes of Dan Friedman and Douglas  
Hofstadter, by far the majority of my for-pay programming work has  
been in 680x0 assembly language, C, C++, and Java. I've been doing  
this for about 25 years now. I supported Macintosh developers in the  
transition from Object Pascal to C++ in the MacApp 3.0 timeframe,  
roughly 1989-1991, provided background research for a presentation  
that Larry Tesler gave about Apple's approach to supporting dynamic  
linking of C++, and unofficially supported Macintosh Common Lisp,  
which at the time was owned by Apple. More recently, I spent  
essentially the entirety of the dot-com years working with Java,  
doing everything from what, as far as I know, was the first applet  
used in a movie promotional site (for one of Peter Jackson's earlier  
films, "The Frighteners") to replacing the back-end infrastructure  
for a large multimedia/social site (iFilm.com). I currently develop C+ 
+ for a combined Linux server/set-top box conditional access system  
for the cable/satellite industry.

I found Objective Caml in a rather roundabout way: I first started  
paying attention to distributed programming and data replication  
issues while at Apple, as part of an effort to reduce the tendency  
that any large organization has to construct numerous "data silos,"  
the left hand not knowing what the right hand is doing. As this was  
about 1990, my investigations led me to Ken Birman's work on the  
Horus project at Cornell. While we never did anything with Horus, I  
continued to pay some attention to it, off and on, over the years.  
Fast forward about a decade, and I was thinking about distributed  
programming again, in the context of the game industry (I've had a  
couple of game programming jobs before). By this time, Birman's group  
had moved on to create the Ensemble system, which was written in  
Objective Caml.

I'd never really cottoned to the ML family before, finding the syntax  
to be too unlike Pascal or C and not being able to really see the  
benefit over, say, Common Lisp or Scheme. O'Caml seemed a bit  
different: it was object-oriented as well as functional, was  
apparently reasonably fast, and the Ensemble team seemed to put great  
stock in being able to prove certain tricky bits of their system  
correct by virtue of having access to a formal semantics for the  
parts of O'Caml that they used. This made for an intriguing  
combination, with Ensemble as a compelling proof-by-demonstration.  
Fast forward again, because I'm still doing this on my own free time,  
but I have enough experience now to suggest that John is correct: the  
ML family in general, but O'Caml in particular, provides extreme  
productivity benefits over the currently popular languages. I find it  
to be on a par with Common Lisp in expressive power, and in fact I  
find the factors in Common Lisp and O'Caml's productivity enhancement  
to be roughly similar:

* Both are functional, in the sense of supporting the use of higher- 
order functions
* Both are imperative. Sometimes the judicious use of state is the  
most efficient, along a number of dimensions, approach to solving  
your problem
* Both are object-oriented. Sometimes the judicious use of inclusion  
polymorphism, etc.
* Both are geared towards programming-in-the-large: package/module  
systems, documentation-construction tools, sophisticated steppers/ 
debuggers/inspectors, etc. make structuring systems easier
* Both recognize that a software development ecosystem needs more  
than just a core language: reasonably comprehensive libraries are  
also important

and here's what I think of as the kicker, the above being necessary,  
but not sufficient, properties of a productive development environment:

* Both are interactive, encouraging a playful, exploratory, discovery- 
oriented programming style.

I can't emphasize enough how crucial O'Caml's provision of a  
toplevel, bytecode compiler, and native compiler are. There is no  
substitute for being able to type in some code and see what happens  
without a whole edit/compile/link/test/crash/debug cycle. Of course,  
it's also important to be able to commit to an implementation and  
have it perform acceptably. Modern Lisps and O'Caml have these bases  
covered. You can get close-ish with a good Standard ML, but there's  
no one system that ties it all together like O'Caml does (you have  
to, e.g. mix and match something like Moscow ML with something like  
MLton to get both the interactivity and the final performance out of  
Standard ML). This is the key. The Lisps and O'Caml let me have a  
thought and be playing with that thought instantly; they don't yank  
me out of the thought while I'm waiting for my compiler/linker,  
either the first time, or whenever I make a mistake. I don't know how  
to put this any better: as a programmer, I get into a rather fluid  
state of analysis/synthesis with respect to my problem domain. Lisp  
and O'Caml sustain that fluid state; virtually all other language  
environments shatter it. And yes, the difference, in my experience,  
is roughly an order of magnitude in productivity. But because this  
productivity comes from sustaining this fluid analytical/synthetic  
process, it can't be described in any meaningful way; it can only be  
experienced, and this is a real burden to impose upon those who are  
quite rightly skeptical about such claims, which is why, apart from  
this e-mail, I don't generally bother trying; I limit my advocacy to  
saying "Why not take O'Caml for a spin some weekend? What have you  
got to lose?"

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

Best regards,
Paul Snively

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

iEYEARECAAYFAkLcKl4ACgkQO3fYpochAqLIywCfcvn6l/UrazIK3d7Wxm9RTt0T
qmwAoNADqJErYWaC3m3oxUx0ZxOlWciX
=rkZl
-----END PGP SIGNATURE-----

Re: [Caml-list] (Mostly) Functional Design?

[Jonathan Bryant]

:D

On Mon, 2005-07-18 at 15:16 -0700, Paul Snively wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Jul 18, 2005, at 2:27 PM, skaller wrote:
> 
> > On Mon, 2005-07-18 at 12:15 -0600, Robert Morelli wrote:
> >
> >
> >> With all due respect,  claims of order of magnitude productivity
> >> gains,  that OCaml is a far better language than Java,  etc.  are
> >> exactly the kind of advocacy that I think is counterproductive.
> >> Most programmers would regard such dramatic statements as  
> >> implausible,
> >> if not preposterous.
> >>
> >
> > Yes they would .. until they tried it.
> >
> I'm going to allow myself to be guilty of exactly what I deplored  
> about the original e-mail, namely offering personal opinions and  
> anecdotes without citations or sources of any kind. :-)
> 
> Although I had the great good fortune to learn Scheme as my third  
> language after BASIC and Z-80 assembly language and to attend Indiana  
> University and hobknob with the likes of Dan Friedman and Douglas  
> Hofstadter, by far the majority of my for-pay programming work has  
> been in 680x0 assembly language, C, C++, and Java. I've been doing  
> this for about 25 years now. I supported Macintosh developers in the  
> transition from Object Pascal to C++ in the MacApp 3.0 timeframe,  
> roughly 1989-1991, provided background research for a presentation  
> that Larry Tesler gave about Apple's approach to supporting dynamic  
> linking of C++, and unofficially supported Macintosh Common Lisp,  
> which at the time was owned by Apple. More recently, I spent  
> essentially the entirety of the dot-com years working with Java,  
> doing everything from what, as far as I know, was the first applet  
> used in a movie promotional site (for one of Peter Jackson's earlier  
> films, "The Frighteners") to replacing the back-end infrastructure  
> for a large multimedia/social site (iFilm.com). I currently develop C+ 
> + for a combined Linux server/set-top box conditional access system  
> for the cable/satellite industry.
> 
> I found Objective Caml in a rather roundabout way: I first started  
> paying attention to distributed programming and data replication  
> issues while at Apple, as part of an effort to reduce the tendency  
> that any large organization has to construct numerous "data silos,"  
> the left hand not knowing what the right hand is doing. As this was  
> about 1990, my investigations led me to Ken Birman's work on the  
> Horus project at Cornell. While we never did anything with Horus, I  
> continued to pay some attention to it, off and on, over the years.  
> Fast forward about a decade, and I was thinking about distributed  
> programming again, in the context of the game industry (I've had a  
> couple of game programming jobs before). By this time, Birman's group  
> had moved on to create the Ensemble system, which was written in  
> Objective Caml.
> 
> I'd never really cottoned to the ML family before, finding the syntax  
> to be too unlike Pascal or C and not being able to really see the  
> benefit over, say, Common Lisp or Scheme. O'Caml seemed a bit  
> different: it was object-oriented as well as functional, was  
> apparently reasonably fast, and the Ensemble team seemed to put great  
> stock in being able to prove certain tricky bits of their system  
> correct by virtue of having access to a formal semantics for the  
> parts of O'Caml that they used. This made for an intriguing  
> combination, with Ensemble as a compelling proof-by-demonstration.  
> Fast forward again, because I'm still doing this on my own free time,  
> but I have enough experience now to suggest that John is correct: the  
> ML family in general, but O'Caml in particular, provides extreme  
> productivity benefits over the currently popular languages. I find it  
> to be on a par with Common Lisp in expressive power, and in fact I  
> find the factors in Common Lisp and O'Caml's productivity enhancement  
> to be roughly similar:
> 
> * Both are functional, in the sense of supporting the use of higher- 
> order functions
> * Both are imperative. Sometimes the judicious use of state is the  
> most efficient, along a number of dimensions, approach to solving  
> your problem
> * Both are object-oriented. Sometimes the judicious use of inclusion  
> polymorphism, etc.
> * Both are geared towards programming-in-the-large: package/module  
> systems, documentation-construction tools, sophisticated steppers/ 
> debuggers/inspectors, etc. make structuring systems easier
> * Both recognize that a software development ecosystem needs more  
> than just a core language: reasonably comprehensive libraries are  
> also important
> 
> and here's what I think of as the kicker, the above being necessary,  
> but not sufficient, properties of a productive development environment:
> 
> * Both are interactive, encouraging a playful, exploratory, discovery- 
> oriented programming style.
> 
> I can't emphasize enough how crucial O'Caml's provision of a  
> toplevel, bytecode compiler, and native compiler are. There is no  
> substitute for being able to type in some code and see what happens  
> without a whole edit/compile/link/test/crash/debug cycle. Of course,  
> it's also important to be able to commit to an implementation and  
> have it perform acceptably. Modern Lisps and O'Caml have these bases  
> covered. You can get close-ish with a good Standard ML, but there's  
> no one system that ties it all together like O'Caml does (you have  
> to, e.g. mix and match something like Moscow ML with something like  
> MLton to get both the interactivity and the final performance out of  
> Standard ML). This is the key. The Lisps and O'Caml let me have a  
> thought and be playing with that thought instantly; they don't yank  
> me out of the thought while I'm waiting for my compiler/linker,  
> either the first time, or whenever I make a mistake. I don't know how  
> to put this any better: as a programmer, I get into a rather fluid  
> state of analysis/synthesis with respect to my problem domain. Lisp  
> and O'Caml sustain that fluid state; virtually all other language  
> environments shatter it. And yes, the difference, in my experience,  
> is roughly an order of magnitude in productivity. But because this  
> productivity comes from sustaining this fluid analytical/synthetic  
> process, it can't be described in any meaningful way; it can only be  
> experienced, and this is a real burden to impose upon those who are  
> quite rightly skeptical about such claims, which is why, apart from  
> this e-mail, I don't generally bother trying; I limit my advocacy to  
> saying "Why not take O'Caml for a spin some weekend? What have you  
> got to lose?"
> 
> > -- 
> > John Skaller <skaller at users dot sourceforge dot net>
> >
> >
> 
> Best regards,
> Paul Snively
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> 
> iEYEARECAAYFAkLcKl4ACgkQO3fYpochAqLIywCfcvn6l/UrazIK3d7Wxm9RTt0T
> qmwAoNADqJErYWaC3m3oxUx0ZxOlWciX
> =rkZl
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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
-- 
*=========================*
|Jonathan Bryant          |
|Valdosta State University|
|Information Technology   |
|System Operations        |
|-------------------------|
|jtbryant@valdosta.edu    |
|x6358                    |
*=========================*

Re: [Caml-list] (Mostly) Functional Design?

[skaller]

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

On Mon, 2005-07-18 at 12:15 -0600, Robert Morelli wrote:

> 
> The use of type checking is a point where the FP community
> has not reached consensus,  

It isn't an issue of consensus .. the problem is a lack
of enough good theorems.

-- 
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] (Mostly) Functional Design?

[Kenneth Oksanen]

On Mon, 2005-07-18 at 11:22 +0200, Alex Baretta wrote:
> [..] given cognitive compatibility with the mind of the developere, [FP] offers
> a productivity at least an order of magnitude greater on very large
> scale projects (over 100klocs) where the dominant cost factor is code
> maintenance. [..]

While I tend to agree with FP ideas and benefits in general, I hope such
strong statements would be backed by other than anecdotal evidence.
Controlled, randomized studies, for example.  Something similar to
Prechelt's work (IEEE Computer 33(10):23-29, October 2000), but on
larger projects.

-- 
; Kenneth Oksanen, mailto:cessu@iki.fi, http://iki.fi/cessu
((lambda(a) (a a((lambda(a)(lambda()(set! a(+ a 1))a))1)))(lambda(a c)
((lambda(b) (newline)(write b)(a a((lambda(c)(lambda()(c c)))(lambda(a)
((lambda(c) (if(=(modulo c b)0)(a a)c))(c))))))(c)))) ; Scheme me!

Re: [Caml-list] (Mostly) Functional Design?

[Mark Meyers]

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

This sounds like something I heard someone say about ten years ago standing 
on a soapbox... Only he was shouting about object oriented programming at 
the time. 

On 7/18/05, Robert Morelli <morelli@cs.utah.edu> wrote: 
> 
> I've been lurking on this list for several years. This seems as good a
> time as any to delurk and jump on a soap box.
> 
> I think you've put your finger on one of the main reasons functional
> languages have failed to attract significant use beyond a few niche
> areas.
> 
> I contend:
> 1. The FP community tends to emphasize low level issues rather than
> the larger scale issues that concern most programmers. It is also
> inept at practical documentation and advocacy.
> 2. There isn't much of a theory of large scale functional design.
> At least, there is no consensus.
> 3. Point 2. is not the consequence of point 1.; it's not simply a
> matter of communication, but an instrinsic void in the FP paradigm.
> 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.
> 
> 
> Kyle Consalus wrote:
> > There are a wealth of resources related to object oriented design 
> techniques
> > (which can certainly be applied to OCaml), but I've been pretty much 
> unable
> > to find any good resources on large scale design of functional programs.
> > I realize that this is the sort of thing that develops over time with
> > experience.
> > Just the same, there is (most likely) a lot to learn and consider, and a
> > resource would be helpful. My recent uses of OCaml for fairly small 
> projects
> > have been effective, but a lot of things were cumbersome in the design
> > and I suspect that I may be thinking about it wrong.
> > So, could anyone suggest a good resource or perhaps weigh
> > in on their thoughts on the topic?
> >
> > Thanks,
> >
> > Kyle
> 
> _______________________________________________
> 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
>

[-- Attachment #2: Type: text/html, Size: 3299 bytes --]

Large scale and FP (was: Re: [Caml-list] (Mostly) Functional Design?)

[David MENTRE]

Hello Robert,

2005/7/18, Robert Morelli <morelli@cs.utah.edu>:
>    1.  The FP community tends to emphasize low level issues rather than
> the larger scale issues that concern most programmers.  It is also
> inept at practical documentation and advocacy.

What do you call practical documentation?

>    2.  There isn't much of a theory of large scale functional design.
> At least,  there is no consensus.

What do you call large scale? Could you give some metrics (number of
lines of code, number of objects, ..), even if such metrics are a bit
meaningless?

Yours,
d.

Re: Large scale and FP

[Robert Morelli]

David MENTRE wrote:
> Hello Robert,
> 
> 2005/7/18, Robert Morelli <morelli@cs.utah.edu>:
> 
>>   1.  The FP community tends to emphasize low level issues rather than
>>the larger scale issues that concern most programmers.  It is also
>>inept at practical documentation and advocacy.
> 
> 
> What do you call practical documentation?

Let me give you an example which I think is quite typical.

When I first started learning functional languages,  I chose Haskell
to start with.  I simultaneously read several books.  Of these,  I'll
mention Hudak's The Haskell School of Expression,  because it was the
most admirable of the lot in terms of addressing ordinary programming
issues.  However,  not only did Hudak's book fail to address any higher
level programming principles,  it didn't even properly address the
basics of getting even a small real program running.  To my recollection
(going back some time),  it ignored or gave very short shrift to basic
issues like commenting conventions,  file extension conventions,
directory layout,  documentation tools,  etc.,  much less anything like
debugging techniques.  It didn't even explain the module system to the
point where the reader would be able to write a working program.  Every
example in the book was an exerpt that could not run by itself.  The
code accompanying the book was written with a literate programming
technology that was not discussed in the book.  Etc.

Mind you,  there are excellent beginner's books on Haskell,  like
Davie's "An Introduction to FP Systems using Haskell,"  which introduces
basics of the language along with the basics of its theory and
implementation.  However,  it's not a practical programming book,
and is totally focused on low level issues.  Peyton-Jones' expository
articles are models of clarity,  but aren't complete accounts of the
language.

The situation with Scheme is even worse.  Abelman and Sussman is
a classic,  but hardly practical.  I find it unfortunate that
Dybvig's book is the only attempt at a general introduction to the
language.  As an aside,  I find the documentation for SCSH,  or lack
thereof,  a tragic missed opportunity.

OCaml,  with its O'Reilly book,  probably has the best practical
documentation of any functional language around.  But it's just
not even a far cry from what languages like Java enjoy.

Re: [Caml-list] (Mostly) Functional Design?

[james woodyatt]

On 18 Jul 2005, at 00:59, Robert Morelli wrote:
>
> The FP paradigm is intrinsically poorly adapted to the kind of large 
> scale design concepts that concern most programmers.

The other points may or may not be salient, but this one seems most 
likely to stir controversy.  I don't think it's necessarily true.

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

It's true that the object-oriented programming community has a great 
deal to say about programming complicated large-scale systems.  There's 
a lot of people in that community, and many of them are drawn by 
non-technical concerns to the development of complicated large-scale 
systems.  It should come as no surprise to anyone that so much has been 
said by them on the subject.  It remains to be seen, however, whether 
very much of what the object-orient programming community has said 
about programming complicated large-scale systems has been correct and 
useful.

The giants in the software tool business got that way not because they 
all chose the object-oriented architecture.  They got to be giants 
because they had the best tools to serve a very large community of 
programmers that arose around non-functional programming languages 
rather than functional ones-- for historical reasons that have little 
bearing on the present state of the art in functional programming.  
Extending non-functional languages with object-oriented features was 
the only sensible and rational way to restore some semblance of sanity 
to the development of complicated large-scale systems.

However, the functional programming community, while it is smaller and 
therefore has much less to say about this subject, much of it what it 
*does* have to say has turned out from my perspective to be more useful 
in the long run.  It's true that functional programming languages are 
today still only used in certain niches, whereas object-oriented 
programming languages have spread to nearly every last specialization 
of software practice.  It's not clear, however, that this is because of 
a lack of some intrinsic technological benefit that functional 
programming should bring to the practitioner.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

Re: [Caml-list] (Mostly) Functional Design?

[Alwyn Goodloe]

I think some of the problem in this discussion is due to a
gulf between what programmers in industry expect and the
more academic FP community. Lets think back to circa 1988.

OO community was really really small. It had a brand of religiously
committed Smalltalk programmers. Most C programmers found Smalltalk about
as easy to get as they do Haskell. Smalltalk programmers found that the
language and environment made them more productive, but to the average C
programmer it was just too strange to fathom. Then C++ came on the scene.
Virtually no C++ programmer I met in industry during the 1990s actually
used the OO features effectively. Why because all they were given was a
new compiler. The few that did get the new paradigm were taught OO
analysis and design BEFORE they were given a new language.

 About 1991 or so a set of books were published. Grady Booch, Martin
Fowler, and others wrote books about OO analysis and design. These books
didn't speak about code they were mostly about how to do OO analysis.
Examples were taken from application domains such as insurance, banking,
etc. The analysis and design techniques that these authors advocated
eventually evolved into UML/Rational methodology.  Meyer's Object Oriented
Software Construction was a great companion to these less technical books.
It is the analysis and design techniques that make OO useful when paired
with a reasonable OO language like Eiffel or Java. My argument is that the
FP community really doesn't seem to understand that the books and seminars
that Booch and company did in the early 90s (however flawed they were) did
more to move OO from the realm of Smalltalk hackers than maybe even C++.
I hope that there is someone out there that can fill that gap and write
about FP analysis and design.  It seems to me that the FP paradigm is a
better fit with old fashioned Structured Analysis/Design from the 1980s
(Yourdon) than it is with OO analysis/design. Remember dataflow
diagrams....  As someone who likes the paradigm and hopes to see it
spread, I hope some expert in the field addresses this need.


Alwyn E. Goodloe

agoodloe@gradient.cis.upenn.edu

Ph.D. Candidate
Department of Computer and Information Science
The University of Pennsylvania

Re: [Caml-list] (Mostly) Functional Design?

[alphablock]

May be there are many less FP solutions than OOP solutions just because
there are many less FP problems than OOP problems.

Or may be i am plain naive, who knows...

- damien


----- Original Message -----
From: "Robert Morelli" <morelli@cs.utah.edu>
To: "Kyle Consalus" <consalus@gmail.com>
Cc: <caml-list@yquem.inria.fr>
Sent: Monday, July 18, 2005 9:59 AM
Subject: Re: [Caml-list] (Mostly) Functional Design?


> I've been lurking on this list for several years.  This seems as good a
> time as any to delurk and jump on a soap box.
>
> I think you've put your finger on one of the main reasons functional
> languages have failed to attract significant use beyond a few niche
> areas.
>
> I contend:
>    1.  The FP community tends to emphasize low level issues rather than
> the larger scale issues that concern most programmers.  It is also
> inept at practical documentation and advocacy.
>    2.  There isn't much of a theory of large scale functional design.
> At least,  there is no consensus.
>    3.  Point 2. is not the consequence of point 1.;  it's not simply a
> matter of communication,  but an instrinsic void in the FP paradigm.
> 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.
>
>
> Kyle Consalus wrote:
> > There are a wealth of resources related to object oriented design
techniques
> > (which can certainly be applied to OCaml), but I've been pretty much
unable
> > to find any good resources on large scale design of functional programs.
> > I realize that this is the sort of thing that develops over time with
> > experience.
> > Just the same, there is (most likely) a lot to learn and consider, and a
> > resource would be helpful. My recent uses of OCaml for fairly small
projects
> > have been effective, but a lot of things were cumbersome in the design
> > and I suspect that I may be thinking about it wrong.
> > So, could anyone suggest a good resource or perhaps weigh
> > in on their thoughts on the topic?
> >
> > Thanks,
> >
> > Kyle
>
> _______________________________________________
> 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] (Mostly) Functional Design?

[Alex Baretta]

alphablock wrote:
> May be there are many less FP solutions than OOP solutions just because
> there are many less FP problems than OOP problems.
> 
> Or may be i am plain naive, who knows...
> 
> - damien

I would not say so. It is just the problems tend to admit a fairly
simple--although generally not trivial solution. This does not justify a
large scale attempt to catalog all FP "design patterns" in a single
book. Let me try to list a few I can readily think of.

* Indefinite recursion through tail call optimization
* Systematic elimination of explicit or implicit (recursive) cycles
whenever an iterator is available. If an iterator is not available for a
given data structure, it is often advisable to define one.
* Order preservation of sequential data structures such as lists through
 the use of an even number of order reversing tail-recursive algorithms.
* Late-binding of recursive calls
* Multi-stage programming through partial evaluation
...

These ideas are more general coding strategies requiring a specific
design from the programmer, rather than parametrized design patterns
abstracting from the (absence of) cognitive abilities of the programmer.

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] (Mostly) Functional Design?

[alphablock]

i love the internet and wise people giving me wise answers :)

- damien

----- Original Message ----- 
From: "Alex Baretta" <alex@barettadeit.com>
To: "alphablock" <alphablock@wanadoo.fr>; "Ocaml" <caml-list@inria.fr>
Sent: Monday, July 18, 2005 5:26 PM
Subject: Re: [Caml-list] (Mostly) Functional Design?


> alphablock wrote:
> > May be there are many less FP solutions than OOP solutions just because
> > there are many less FP problems than OOP problems.
> > 
> > Or may be i am plain naive, who knows...
> > 
> > - damien
> 
> I would not say so. It is just the problems tend to admit a fairly
> simple--although generally not trivial solution. This does not justify a
> large scale attempt to catalog all FP "design patterns" in a single
> book. Let me try to list a few I can readily think of.
> 
> * Indefinite recursion through tail call optimization
> * Systematic elimination of explicit or implicit (recursive) cycles
> whenever an iterator is available. If an iterator is not available for a
> given data structure, it is often advisable to define one.
> * Order preservation of sequential data structures such as lists through
>  the use of an even number of order reversing tail-recursive algorithms.
> * Late-binding of recursive calls
> * Multi-stage programming through partial evaluation
> ...
> 
> These ideas are more general coding strategies requiring a specific
> design from the programmer, rather than parametrized design patterns
> abstracting from the (absence of) cognitive abilities of the programmer.
> 
> 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/>
> 
> _______________________________________________
> 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] (Mostly) Functional Design?

[Doug Kirk]

First, since this thread was started by somebody asking for ideas on  
learning FP, I can site a couple of printed resources that have  
helped me, but none are written using Ocaml:


"Haskell School of Expression", Hudak, ISBN 0-52164-4089
"Algorithms: A Functional Programming Approach", Rabhi, Lapalme, ISBN  
0-20159-6040
"Structure & Interpretation of Computer Programs", Sussman, Abelson,  
Sussman, ISBN 0-26269-2201

With regard to the mailing lists, I've found that the Haskell list  
has a higher percentage of general FP information than the Ocaml  
list. It's almost as if the Haskellers are the theoretic bunch, and  
the Ocamlers are the applied-technology bunch. (see disclaimer at  
bottom)


On Jul 18, 2005, at 10:26 AM, Alex Baretta wrote:

> This does not justify a
> large scale attempt to catalog all FP "design patterns" in a single
> book.

Large scale? Was not "Design Patterns" originally a Ph.D. thesis? I  
wouldn't call that "large scale". It just so happens that the work  
was very helpful in a practical application for the programming  
community at large to describe things that were already being done  
(see below). So much so that it remains a bestseller in the  
programming world.

<rant>
Unfortunately, what I see today is that too much emphasis is placed  
on the GoF patterns; many coming out of college and into the "real  
world" now see those as the entire toolbox, instead of simply a  
collection of tools that may or may not apply.
</rant>

> These ideas are more general coding strategies requiring a specific
> design from the programmer, rather than parametrized design patterns
> abstracting from the (absence of) cognitive abilities of the  
> programmer.

Yet before "Design Patterns" was released, I used those patterns in  
my day-to-day design activities. It's just that nobody had catalogued  
(formalized) them. I even used them while coding in C, as any good  
programmer wanting to maximize maintainability of code would soon  
learn to do.

So for me at least, the DP book was a formal description of what I  
had already been doing, which I would call "general coding  
strategies". However, having the book formalize the commonly-used  
paradigms raised the level of thinking in the entire (OO) programming  
community, even for programmers that hadn't had the opportunity to  
informally discover the techniques themselves.

In the OO world, it is common now to speak of a design as an  
application of one or more of the patterns; if somebody listening  
doesn't understand a mentioned pattern, he can simply be directed to  
"look it up" so that progress on the design may continue. The point  
here being that speaking in patterns is a communication short-cut  
describing widely understood and accepted concepts. For instance,  
when you say "Indefinite recursion through tail call optimization",  
what does that mean? What is required to accomplish it? What resource  
is available that describes this and the others that you listed and  
the requirements for achieving each of them? If your answer is  
graduate school, then FP is doomed to the sidelines of the mainstream.

Having a resource such as that *is* a valuable tool that enables  
novices to raise their level of thinking, and even more so,  
understanding, of the environment in which they are operating. (The  
danger of having the resource without experience is pointed out in  
the rant above...it may be easy for novices to see it as the entire  
toolbox.)

For myself, I've been lurking on this list for awhile, and trying to  
learn FP practices using Ocaml. Since I have 3 mouths to feed, I must  
spend most of my time doing work that clients are willing to pay  
for...the last 9 years that means Java. So the lack of resources to  
learn FP/Ocaml seriously affects my ability to start using it for  
anything "real".

I am not so much interested in Ocaml as I am FP (I chose to look more  
closely at Ocaml over Haskell because of the results of the ICFP  
challenges, and because of some comments on the Haskell list).  
Generally, I am dissatisfied with OO (as I was with structured  
programming before it) as a methodology for solving mid- to large- 
scale problems (essentially they are the same methodology; OO just  
localizes the structures). I am looking to find a way to advance the  
state of the art of problem-solving software systems ("languages").


<disclaimer>
All of the preceding is simply my opinion based upon my own  
observations and experience. It is not intended to incite controversy.
</disclaimer>


Cheers,
--doug
  

Re: [Caml-list] (Mostly) Functional Design?

[Alex Baretta]

Doug Kirk wrote:

Le me quote your message starting with the disclaimer:
> <disclaimer>
> All of the preceding is simply my opinion based upon my own
> observations and experience. It is not intended to incite controversy.
> </disclaimer>

I don't think your message incites controversy. It is a thoughtful
apology of the metapattern of devising, documenting and teaching
canonical solutions to canonical problems. I recognize that this is
actually one of the fundamental ideas in Engineering as a whole.

> 
> In the OO world, it is common now to speak of a design as an 
> application of one or more of the patterns; ...

This I would not like. Design is an eminently "artistic" activity: it
takes creativity. Applying patterns is a parrot's work. One my main
reasons for liking Ocaml is that the "general coding strategies" that
apply are do not produce the vast majority of my locs, but are usually
localizeable in a small bunch of lines in a module. This means that me
job is that of the artist, not that of the parrot. This makes me feel a
little less miserable for being a hacker ;)

> Having a resource such as that *is* a valuable tool that enables 
> novices to raise their level of thinking, and even more so, 
> understanding, of the environment in which they are operating. (The 
> danger of having the resource without experience is pointed out in  the
> rant above...it may be easy for novices to see it as the entire  toolbox.)

It usually takes me a few minutes to explain a single "design strategy"
to a collegue. It takes a few more minutes to show an example. It might
take anywhere between a few minutes to the rest of his/her lifetime to
digest the idea. I wonder if this situation would improve, given
adequate literature and documentation.

> For myself, I've been lurking on this list for awhile, and trying to 
> learn FP practices using Ocaml. Since I have 3 mouths to feed ...

Me too! ;)

> I must 
> spend most of my time doing work that clients are willing to pay 
> for...the last 9 years that means Java.

The problem is not so much the lack of documentation, but the lack of
customers. The year of our lord 2005 is a very sad year for the IT
business, at least in Italy.

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] (Mostly) Functional Design?

[james woodyatt]

On 18 Jul 2005, at 10:17, Doug Kirk wrote:
>
> First, since this thread was started by somebody asking for ideas on 
> learning FP, I can site a couple of printed resources that have helped 
> me, but none are written using Ocaml:
>
> "Haskell School of Expression", Hudak, ISBN 0-52164-4089
> "Algorithms: A Functional Programming Approach", Rabhi, Lapalme, ISBN 
> 0-20159-6040
> "Structure & Interpretation of Computer Programs", Sussman, Abelson, 
> Sussman, ISBN 0-26269-2201

I would add that a good tutorial on monads is a resource that every 
functional programmer should read for comprehension.  I haven't found 
one that I can recommend without hesitation, but here's a candidate:

	<http://www.nomaware.com/monads/html/>


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

Re: [Caml-list] (Mostly) Functional Design?

[Robert Morelli]

james woodyatt wrote:
> On 18 Jul 2005, at 10:17, Doug Kirk wrote:
> 
>>
>> First, since this thread was started by somebody asking for ideas on 
>> learning FP, I can site a couple of printed resources that have helped 
>> me, but none are written using Ocaml:
>>
>> "Haskell School of Expression", Hudak, ISBN 0-52164-4089
>> "Algorithms: A Functional Programming Approach", Rabhi, Lapalme, ISBN 
>> 0-20159-6040
>> "Structure & Interpretation of Computer Programs", Sussman, Abelson, 
>> Sussman, ISBN 0-26269-2201
> 
> 
> I would add that a good tutorial on monads is a resource that every 
> functional programmer should read for comprehension.  I haven't found 
> one that I can recommend without hesitation, but here's a candidate:
> 
>     <http://www.nomaware.com/monads/html/>

You know,  I once started writing an expository paper called "Monads for
Mortals."  My background is in mathematics and I knew what monads were
in category theory more than a decade before I learned what a functional
programming language was.  However,  my purpose was to explain monads in
a way that I think is completely intuitive,  simple,  and sensible from
an ordinary programmer's point of view.  I abandoned the paper several
years ago,  but perhaps it's worth completing it.

By the way,  not only did I know about monads before FP,   I'm probably
one of the few people on earth who knew what what denotational semantics
was before I even knew what the phrase "functional language" meant.  I
read an entire book on the subject about a year before I learned
Haskell.



Another book that might be mentioned here is
Felleisen, Findler,  Flatt, Krishnamurthi,  How to Design Programs.

Re: [Caml-list] (Mostly) Functional Design?

[james woodyatt]

On 19 Jul 2005, at 02:35, Robert Morelli wrote:
>   However,  my purpose was to explain monads in
> a way that I think is completely intuitive,  simple,  and sensible from
> an ordinary programmer's point of view.  I abandoned the paper several
> years ago,  but perhaps it's worth completing it.

Yes, well... I would count that as a point in favor of your argument 
that the community "is also inept at practical documentation and 
advocacy."  I think a really good introduction to monads for the 
practitioner, as distinct from the mathematician, would be a sign of 
growing aptitude for practical documentation and advocacy.

They're kinda hard to use in Ocaml, which my preferred functional 
language, so I don't think it would be a good idea for me to try to 
write such a thing.  It would be nice if somebody did.


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

Re: [Caml-list] (Mostly) Functional Design?

[Paul Snively]

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

Hi James!

On Jul 19, 2005, at 9:53 AM, james woodyatt wrote:

> They're kinda hard to use in Ocaml, which my preferred functional  
> language, so I don't think it would be a good idea for me to try to  
> write such a thing.  It would be nice if somebody did.
>
I dunno; from what I can see of the available O'Caml libraries,  
you've done quite a lot more work with monadic programming in O'Caml  
than anyone else. If you couldn't write a newbie introduction to the  
subject, I despair of anyone else doing it.

Since O'Caml is also my preferred functional language, I find it  
frustrating to see grab-and-use implementations of things like  
monadic foo or the Zipper structure or Functional Reactive  
Programming... in Haskell, and not be able to find them for O'Caml.  
When some of the constructs are awkward, for heaven's sake, go ahead  
and use camlp4 to make some nice syntactic sugar, cf. the Haskell- 
like "do" notation that was released not too long ago. When there's  
more than one credible implementation of a subconcept that a module  
depends on, please implement the module as a functor. Obviously, this  
is basic stuff, and since I haven't yet released any O'Caml code of  
my own, I desperately need to take my own advice. :-)

I guess I should mention that I am in the process of attempting to  
build an F-Rep-based geometric modeling kernel in O'Caml, with  
eventual visualization integration with lablGL. I think O'Caml is  
incredibly well-suited to this task, but as I'm still very much in  
the process of mastering O'Caml at the same time I'm trying to  
understand F-Rep systems, collaboration would be welcome. Ultimately  
the goal is to develop a 3D modeling system competitive and  
collaborative with the UnrealEd etc. tools included with the Unreal  
technology based games, but there are many subprojects that have to  
happen first, and a good F-Rep kernel seems like an excellent  
starting point.

>
> -- 
> j h woodyatt <jhw@wetware.com>
> markets are only free to the people who own them.
>
> _______________________________________________
> 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
>

Best regards,
Paul Snively

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

iEYEARECAAYFAkLdNNYACgkQO3fYpochAqIqBQCgnpMXu3UWM60yGETKNkLMDkB9
WTMAoNfezxjWGtlrmCKg/aw2CqTRdDcX
=TXib
-----END PGP SIGNATURE-----

Re: [Caml-list] (Mostly) Functional Design?

[Jon Harrop]

On Tuesday 19 July 2005 18:13, Paul Snively wrote:
> I guess I should mention that I am in the process of attempting to
> build an F-Rep-based geometric modeling kernel in O'Caml,

You mean like this?

  http://cis.k.hosei.ac.jp/~F-rep/

> with eventual visualization integration with lablGL.

LablGL is excellent, BTW. You may find some of my work useful if you're 
learning it:

  http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation/
  http://www.ffconsultancy.com/free/maze/
  http://www.ffconsultancy.com/free/ray_tracer/
  http://www.ffconsultancy.com/free/ray_tracer/comparison.html

> I think O'Caml is 
> incredibly well-suited to this task, but as I'm still very much in
> the process of mastering O'Caml at the same time I'm trying to
> understand F-Rep systems, collaboration would be welcome.

I think you will find OCaml to be dangerously well suited to this task. I've 
used OCaml for several somewhat-similar projects and find OCaml to be 
enormously more productive than C++ (my previous "favourite language").

I am working full-time on our presentation software so I can't afford any time 
to work on new stuff. However, there is probably some overlap and I am 
willing to open source some interesting and useful parts of our code.

> Ultimately 
> the goal is to develop a 3D modeling system competitive and
> collaborative with the UnrealEd etc. tools included with the Unreal
> technology based games, but there are many subprojects that have to
> happen first, and a good F-Rep kernel seems like an excellent
> starting point.

That sounds like a great project. Best of luck with that. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Technical Presentation Software
http://www.ffconsultancy.com/products/presenta

Re: [Caml-list] (Mostly) Functional Design?

[Paul Snively]

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

Hello Jon!

On Jul 19, 2005, at 4:58 PM, Jon Harrop wrote:

> On Tuesday 19 July 2005 18:13, Paul Snively wrote:
>
>> I guess I should mention that I am in the process of attempting to
>> build an F-Rep-based geometric modeling kernel in O'Caml,
>>
>
> You mean like this?
>
>   http://cis.k.hosei.ac.jp/~F-rep/
>
Precisely. Specifically, I'm attempting to essentially go straight  
from the admittedly incomplete VDM spec found in "Pasko A., Savchenko  
V., Adzhiev V. and Sourin A. "Multidimensional geometric modeling and  
visualization based on the function representation of objects",  
Technical Report 93-1-008, The University of Aizu, Japan, 1993," near  
the bottom of the "Publications" page, to working O'Caml code. Some  
aspects of VDM seem to translate essentially directly (e.g. they  
actually use "let ... = ... in ..."). Others seem to require just a  
little bit of thought, e.g. whether a "value" defined as a "Float*"  
actually needs to be a "float option" or whether it's just that VDM  
doesn't have a better way to express variants, and their tree  
structure can be described as a variant without using "option"  
anywhere. At the moment, I strongly suspect the latter.

> LablGL is excellent, BTW. You may find some of my work useful if  
> you're
> learning it:
>
>   http://www.ffconsultancy.com/products/ocaml_for_scientists/ 
> visualisation/
>   http://www.ffconsultancy.com/free/maze/
>   http://www.ffconsultancy.com/free/ray_tracer/
>   http://www.ffconsultancy.com/free/ray_tracer/comparison.html
>
Yes, I've seen bits of your work and greatly appreciate them! That  
reminds me that I need to buy your book. :-)

> I think you will find OCaml to be dangerously well suited to this  
> task. I've
> used OCaml for several somewhat-similar projects and find OCaml to be
> enormously more productive than C++ (my previous "favourite  
> language").
>
Yes, I'd actually begun the project as a C++ project, for no other  
reason than the hope of gaining more collaborators. That hasn't  
happened, and so I've bitten the bullet and started over, partially  
to become as fluent as possible in O'Caml, and partially because I  
already had had the sense that it was the right tool for the job,  
even if ultimately I take longer with it on this project (cf. "become  
as fluent as possible...")

> I am working full-time on our presentation software so I can't  
> afford any time
> to work on new stuff. However, there is probably some overlap and I am
> willing to open source some interesting and useful parts of our code.
>
That's a very kind and generous offer, especially when I consider  
what you've already made available and published. Thanks! By the way,  
how should an American best purchase your book?

>
>> Ultimately
>> the goal is to develop a 3D modeling system competitive and
>> collaborative with the UnrealEd etc. tools included with the Unreal
>> technology based games, but there are many subprojects that have to
>> happen first, and a good F-Rep kernel seems like an excellent
>> starting point.
>>
>
> That sounds like a great project. Best of luck with that. :-)
>
I meant "compatible" rather than "collaborative" above, although I  
must say that Tim Sweeney at Epic Games has already been both  
incredibly supportive, e.g. sending along the source code to the  
UnrealScript compiler to use as a reference point, and incredibly  
forthright, e.g. pointing out that the published Unreal Tournament  
headers weren't likely to result in a working editor, as they leave  
out far too much, and the CSG code was never built into the Mac  
codebase anyway (I'm typing this on my fantastic new PowerBook 15").

All the more reason, I think, to use this as an opportunity to learn  
O'Caml better: even if I never get a working modeler out of it, I  
will have achieved another goal. But I think my chances of at least  
getting a very nice F-Rep-based modeler going, even if it never reads/ 
writes Unreal archives, are vastly better in O'Caml than away from it.

> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> Technical Presentation Software
> http://www.ffconsultancy.com/products/presenta
>
> _______________________________________________
> 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

Many thanks and best regards,
Paul Snively


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

iEYEARECAAYFAkLdmw4ACgkQO3fYpochAqLfKQCfSEWaRAxnfV3W880ZD7i191YY
GXsAnA7rezWEZMtV1d3w8B9rXBSKruHD
=jgtU
-----END PGP SIGNATURE-----

Re: [Caml-list] (Mostly) Functional Design?

[padiolea]

> I contend:
>    1.  The FP community tends to emphasize low level issues rather than
> the larger scale issues that concern most programmers.  It is also

what are large scale issues ?

> inept at practical documentation and advocacy.
>    2.  There isn't much of a theory of large scale functional design.

Because there is a theory of large scale design in OO world ?
I mean can we call drawing rectangles and lines a theory ?


> At least,  there is no consensus.
>    3.  Point 2. is not the consequence of point 1.;  it's not simply a
> matter of communication,  but an instrinsic void in the FP paradigm.
> The FP paradigm is intrinsically poorly adapted to the kind of large
> scale design concepts that concern most programmers.

Can you be more specific ?

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

So what are those intrinsical technical reasons ?


> Functional programming is a niche
> technology ideally suited to simple domains like language tools and
> formal methods.

Do you really think that langage tools and formal methods are
"simple domains" ?


> It does not have much to say about complicated
> systems.

You mean overcomplicated system I guess.


I like some of the ideas that the oo community brings to the world.
I like objects, I think inheritance/subtyping are cool,
I like late binding. I just think they are overrated.
IMHO higher order functions, parametric polymorphism, pattern matching,
garbage collection, ... are equally important features.

In fact, in the OO world, many "design patterns" have direct
translation in fp construct, and in fact just imitates what
functionnal programmers have done for years.
For instance the strategy pattern is just an example of use of
higher order functions. Peter norvig have a talk on his webpage
where he says that 21 of the design patterns have
a direct translation in dylan.
Nevertheless, again, I like the fact that the oo community
brings to the world the idea of design patterns, of a catalogue.
In fact, there is now some design functionnal patterns (have
a look at the haskell wiki).

That said, I have read analysis books, I had a look at UML,
and I never saw anything useful in those books. Those books
are verbose, very long, and boring.



>
>
> Kyle Consalus wrote:
>> There are a wealth of resources related to object oriented design
>> techniques
>> (which can certainly be applied to OCaml), but I've been pretty much
>> unable
>> to find any good resources on large scale design of functional programs.
>> I realize that this is the sort of thing that develops over time with
>> experience.
>> Just the same, there is (most likely) a lot to learn and consider, and a
>> resource would be helpful. My recent uses of OCaml for fairly small
>> projects
>> have been effective, but a lot of things were cumbersome in the design
>> and I suspect that I may be thinking about it wrong.
>> So, could anyone suggest a good resource or perhaps weigh
>> in on their thoughts on the topic?
>>
>> Thanks,
>>
>> Kyle
>
> _______________________________________________
> 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] (Mostly) Functional Design?

[Gerd Stolpmann]

Am Montag, den 18.07.2005, 01:59 -0600 schrieb Robert Morelli:
> I've been lurking on this list for several years.  This seems as good a
> time as any to delurk and jump on a soap box.
> 
> I think you've put your finger on one of the main reasons functional
> languages have failed to attract significant use beyond a few niche
> areas.

Well, I don't believe that. There aren't any technical reasons why
people don't think FP languages are attractive. There are social
reasons. Adult programmers and decision-makers must sit down again on
the school bank. It has to do with the difficulty to get into existing
and working relationships. IMHO, a marketing expert can say much more
about this than a techie.

> I contend:
>    1.  The FP community tends to emphasize low level issues rather than 
> the larger scale issues that concern most programmers.  It is also
> inept at practical documentation and advocacy.

This is entirely nonsense. Although current FP languages have certain
typical "low level" mechanisms like functional composition, they also
have lots of other higher level mechanisms (e.g. a module calculus). 
A current FP language may also be an imperative language or an OO
language at the same time. At least O'Caml is a true multi-paradigm
language.

Another remark: Designers of FP languages often try to avoid the inner
contradictions of the widespread practical languages, and to only
include "sound" language concepts. Sound concepts work for small-scale
and for large-scale programs. For example, if you compose two functions
f and g to a new function, it does not matter how large f and g are. If
f and g are stateless, you don't run into the typical problems of
large-scale imperative programming, i.e. managing the state in a
reasonable way. Well, of course, the term "sound" should be seen
relative to the intentions of the language designer.

>    2.  There isn't much of a theory of large scale functional design.
> At least,  there is no consensus.

Your thesis also includes that other languages have some theory of
large-scale programming. I doubt that. Design patterns, for example, are
medium-scale at best. They help organising the relationships of only a
few classes. Even worse, if you translate design patterns to FP
languages, you often get small-scale counterparts. And is there anything
beyond design patterns?

I also miss that "large-scale" is a multi-dimensional term. It is very
different to design reusable data structures or to design a single large
program. Current FP languages are quite good at supporting reusability. 

>    3.  Point 2. is not the consequence of point 1.;  it's not simply a
> matter of communication,  but an instrinsic void in the FP paradigm.
> 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.  

My view is very different. OO languages like Java or Eiffel are extreme
languages in the sense that they only allow OO to structure the program
and nothing else. (And in the past many OO programmers were really
extremists because they thought the OO paradigm reflected how the world
was structured.) At least O'Caml isn't designed with extremism in mind,
and you _can_ program in it as it were an OO language. This easily
proves that there aren't such technical reasons: O'Caml is a superset of
OO languages.

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

This only has to do with marketing. It is much simpler to be successful
in a niche where other technologies have clear disadvantages than to be
successful in a universal sense.

I hope the programmers of the world will learn, and will see that much
of the complexity OO pretends to solve has been created by the extreme
view of OO before. For example, compare how GUIs are customised in an
extreme OO language and a multi-paradigm language like O'Caml. In the
extreme language you often must use quite heavy constructs like
subclassing to get a new behaviour where you can simply pass a closure
in O'Caml.

One clear disadvantage in the large scale _application_ of FP languages
is that the programmers must learn much more primitive concepts, and it
takes longer until they can combine them in a reasonable way to large
programs.

Gerd

> Kyle Consalus wrote:
> > There are a wealth of resources related to object oriented design techniques
> > (which can certainly be applied to OCaml), but I've been pretty much unable
> > to find any good resources on large scale design of functional programs.
> > I realize that this is the sort of thing that develops over time with
> > experience.
> > Just the same, there is (most likely) a lot to learn and consider, and a 
> > resource would be helpful. My recent uses of OCaml for fairly small projects
> > have been effective, but a lot of things were cumbersome in the design
> > and I suspect that I may be thinking about it wrong.
> > So, could anyone suggest a good resource or perhaps weigh
> > in on their thoughts on the topic?
> > 
> > Thanks,
> > 
> > Kyle
> 
> _______________________________________________
> 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] (Mostly) Functional Design?

[skaller]

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

On Mon, 2005-07-18 at 21:45 +0200, Gerd Stolpmann wrote:

> Well, I don't believe that. There aren't any technical reasons why
> people don't think FP languages are attractive. There are social
> reasons.

There are technical reasons why existing FP *tools* aren't 
attractive.. though it is hard to divorce 'technical' from
'social': programming is a human activity, and so 
intrinsically social.

The most important problem with FP languages is quite
simple -- it is expensive to interface them to existing
code. And the 'social' analogue: existing programmers.

Most projects (a) reuse existing code and (b) reuse
existing programmers. It isn't a matter of going back
to school. C++ was successful precisely because it allowed
reuse of both C code and C programmers. Ocaml can be
successful where starting from scratch is OK: a new
project or a new business venture.

Secondly, the tools have some real problems, like
all tools. Ocaml, for example, just cannot generate
dynamically loadable binary libraries easily (if at all),
and whilst it can use source code libraries .. there
are no namespaces or packages to organise large code bases.

The former isn't a problem with the Ocaml language though..
but it is enough of a problem with the tools that I've spent
5 years developing an FP language (in Ocaml of course)
that can generate dynamically loadable libraries.

If only 'XYZ' functional language could simply replace
C generating C libraries, it would be an instant winner!
But even C++ can't do that .. you can use C libs in C++
but not the other way around, at least not easily
(because of exception handling ..)

-- 
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] (Mostly) Functional Design?

[Chris Campbell]

On 18/07/05, Robert Morelli <morelli@cs.utah.edu> wrote:
> I've been lurking on this list for several years.  This seems as good a
> time as any to delurk and jump on a soap box.
> 
> I think you've put your finger on one of the main reasons functional
> languages have failed to attract significant use beyond a few niche
> areas.
> 
> I contend:
>    1.  The FP community tends to emphasize low level issues rather than
> the larger scale issues that concern most programmers.  It is also
> inept at practical documentation and advocacy.

Problems with documentation plague software as a whole whether they're
written in "OO" languages or "FP" languages.  Tools like Javadoc did
change things slightly.  They made it easier to put some documentation
in at low cost.  It still only works if programmers can be bothered
and don't necessarily do anything for the quality of documentation
(people will always write crap comments in code, now they just get
javadoc'd).

As for advocacy I agree that sometimes it is counter productive but
sometimes people make the mistake of assuming the purpose of the
language is to become popular and widely used in the mainstream. i.e.
it's the next Java/C# or is the silver bullet to end all software
ills.  It's not.  The reality is more complex.

Many "functional" languages are research vehicles.  They're not about
converting the masses, they're about exploring ideas.  Sometimes the
goal is not to create a language for widespread use, it is to create a
language which explores a problem or satisfies curiosity.  Some are
intended to change the world and some of those do fail.

Also note that on the whole, any language other than C, C++, Java, C#
face advocacy problems in someway.  The comment about gains in
productivity is correct, but is so not because it may not be true for
a particular language but because everyone claims it without proof. 
That's the problem with language advocacy, it's subjective not
objective.

It's probably worth noting that languages that succeed in some way do
so in a niche or fill a particular need and spread out into the wider
world, being used for problems they solve well and those they do not. 
Sometimes that helps people develop better languages, sometimes it has
a negative affect.

>    2.  There isn't much of a theory of large scale functional design.
> At least,  there is no consensus.

There is no consensus in mainstream industry either.  We have
guidelines in the form of patterns, and good rules of thumb for aiding
maintainance (low coupling, high cohesion, ...) and newer (or old ones
becoming popular) ideas that look like they make good tools to use
when appropriate ("test first", "let it fail").  None are appropriate
for all situations and their is no consensus as to what those
situations are.

>    3.  Point 2. is not the consequence of point 1.;  it's not simply a
> matter of communication,  but an instrinsic void in the FP paradigm.
> The FP paradigm is intrinsically poorly adapted to the kind of large
> scale design concepts that concern most programmers.  

Which are what?  I don't think there's any consensus on that.

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

First you have to define what a functional language is to talk about
that.  Let's say for the sake of argument it's charaterised mainly by
declarative variables, with emphasis on higher order functions and
structuring code through repeated function application with state
present in some way but not the default.  This isn't everyones
definition, but it's what I tend to think of FP being about.  Note
that takes in a lot of systems, doesn't say anything about
"typed-ness" and can be applied to many languages outside the FP
mainstream.  That's intentional.  I don't think there is one set of
baskets to classify all systems, and it's pointless doing so.  It's
better to realise there is a scale involved and some languages are
high up in some parts and low in others.

There are complex systems where those lend a hand in major ways.  The
absense of a stateful default is a major boost in developing
distributed systems.  It allows you to isolate state to where it is
really necessary and to not worry about consistency all the time. 
State becomes a major pain fast in such systems when it's the default.
 The rules become much more complex.

HOFs enable reuse.

> The use of type checking is a point where the FP community
> has not reached consensus,  as there are widely divergent views from
> the Scheme community and the ML and Haskell communities.  

The static vs dynamic debate is a really annoying pointless way to
increase enthropy, so I won't go there.  I will say however that
statically typed systems like ML prevent me from doing some things I
can do easily in dynamically typed systems unless they're sufficiently
rich (like say specifying functions which operate on a family of
records containing a given set of fields is trivial in dynamically
typed languages but requires something more in statically typed
systems) but come with other benefits.  I use both.

Besides, I'm pretty sure there are "dynamically typed" OO languages. 
So there are differences in the OO camp too.

> Even between
> ML and Haskell,  there are significant differences in the treatment of
> imperative features,  type inference,  objects and type classes,  etc.

This is bad?  Each shows a different choice and the consequences of
making that choice.  Each opens up different avenues of research which
leads to a greater understanding of languages and their concepts as a
whole.  Each has different trade offs.

You can limit your search to one path, but if you do that you may
never realise your on the wrong one or understand the consequences of
the choices you made.

> These differences,  it seems to me,  are more fundamental than anything
> you find in the OO world,  even the difference between,  say,  Java
> and Smalltalk.

Even if this is true, why is it a bad thing?  Sometimes there can be
more than one solution with different trade offs.  Choice isn't a bad
thing.


Chris

Some Clarifications

[Robert Morelli]

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.

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.

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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] (Mostly) Functional Design?

[Marius Nita]

Robert Morelli wrote:
> I've been lurking on this list for several years.  This seems as good a
> time as any to delurk and jump on a soap box.
> 
> I think you've put your finger on one of the main reasons functional
> languages have failed to attract significant use beyond a few niche
> areas.
> 
> I contend:
>   1.  The FP community tends to emphasize low level issues rather than 
> the larger scale issues that concern most programmers.  It is also
> inept at practical documentation and advocacy.
>   2.  There isn't much of a theory of large scale functional design.
> At least,  there is no consensus.
>   3.  Point 2. is not the consequence of point 1.;  it's not simply a
> matter of communication,  but an instrinsic void in the FP paradigm.
> 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 think those who blindly blame FP are as guilty as those who blindly 
praise it. Asserting "FP is strictly better than imperative programming" 
is wholly unscientific, irrational, and rooted in dogma.

Blindly asserting "FP is strictly worse than IP" is naturally just as 
bad. Talking about issues of "large scale design" and hinting that 
certain things are inherently better than others, without providing any 
actual definitions or proof, is obviously not productive because it's 
vacuously irrefutable.

We need tools that enable us to measure and talk about usability and 
scalability before we can claim that such things are richer in some 
paradigms than in others.

Until we have that, all we can do is play the social game; expose people 
to technologies, observe their response, use it as feedback, etc., and 
work toward a way to make improve this situation. So I'll listen to 
point #1 (and I tend to agree) but I have no direct way to respond to 
your other two points, other than resorting to dogma.

-marius

> 
> Kyle Consalus wrote:
> 
>> There are a wealth of resources related to object oriented design 
>> techniques
>> (which can certainly be applied to OCaml), but I've been pretty much 
>> unable
>> to find any good resources on large scale design of functional programs.
>> I realize that this is the sort of thing that develops over time with
>> experience.
>> Just the same, there is (most likely) a lot to learn and consider, and 
>> a resource would be helpful. My recent uses of OCaml for fairly small 
>> projects
>> have been effective, but a lot of things were cumbersome in the design
>> and I suspect that I may be thinking about it wrong.
>> So, could anyone suggest a good resource or perhaps weigh
>> in on their thoughts on the topic?
>>
>> Thanks,
>>
>> Kyle
> 
> 
> _______________________________________________
> 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

[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

[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

[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

[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

[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

[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

[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