What language do you think is a good combination between OOP and FP
Friedrich Dominicus
personal preferred PL is Eiffel, I now try to find out where OOP and
FP good be best combined. The following candidated don't look bad:
- OCAML
- CECIL
Do you have know any other language like this?
Do you think it's a good idea to combine FP and OOP Elements in one
language?
Or do you think that a language should purely be functional and/or
oo-oriented?
Here's what I like about Eiffel (the idea of Design by Contract), so I
expect that functional elements in assertions could help a lot.
The full power of FP-language seemed to be the direct support for
abstract datatypes. So I like the way for example how Stacks are
implemented in FP-languages.
Any comments or hints ?
Best regards
Friedrich
Rainer Joswig
<Friedrich...@inka.de> wrote:
> I'm relatively new to FP and used to program in an OO-fashion. My
> personal preferred PL is Eiffel, I now try to find out where OOP and
> FP good be best combined. The following candidated don't look bad:
>
> - OCAML
> - CECIL
>
> Do you have know any other language like this?
Dylan
Common Lisp
> Or do you think that a language should purely be functional and/or
> oo-oriented?
>
> Here's what I like about Eiffel (the idea of Design by Contract), so I
> expect that functional elements in assertions could help a lot.
Common Lisp has a better exception system. Assertions can
easily be added via method combination.
Dwight VandenBerghe
<Friedrich...@inka.de> wrote:
>Do you think it's a good idea to combine FP and OOP Elements in one
>language?
I'm an Ocaml user, and while I love the language, I don't use the
OOP features much. It's not that I'm completely adverse: in Python,
for instance, I use OOP all the time, and I've been writing OOP-
style C++ for many years. (But I hate it, and that's a different
story for another time.)
>Or do you think that a language should purely be functional and/or
>oo-oriented?
I think, door # 2: OOP or functional. With ML (or Ocaml not using
the OOP features) there is so much elegant support for programming-
in-the-large, with the extraordinary module system, functors, and
the like, that you really don't need OOP as an alternative problem-
segmentation methodology. ADT's give you almost everything that
OOP gives you - OOP adds the ability to indirect off a reference
to any subclass of the reference's base class, and get the appropriate
function for the derived class, which you can't get with just
references to ADT's - although you can get the same effect if the
ADT instantiation is not through a reference. And that is not
such a big deal, at least to me, in my applications (large,
commercial programs like compilers, as well as embedded systems).
It's a different way of thinking. Python (or Modula-3, or
Eiffel, or SmallTalk, or Objective-C) has a world view that revolves
around classes and inheritance and method overrides and so forth.
It's a way of dividing up a problem to manage the complexity.
It's not terribly bad, but it sure isn't as good as its evangelists
claim. (It IS terribly bad as implemented in C++, but there I
go again.) At root OOP is not a different or more powerful way
of programming; you can do the same thing with function pointers
and nested structures. It's just a way of bundling things with
some syntactic molasses that makes it a little easier, supposedly,
to reuse common parts and extend existing mechanisms. Supposedly.
FP, on the other hand, is a different and more powerful way of
programming. It puts the full power of functions at your disposal,
and it makes some things easy that you think would be very hard
(like returning functions from functions, and storing functions
in variables, and partially evaluating functions and then
executing them later in their original environment, and so on
and on) while making some other things hard that you think would
be easy (like assigning a value to a member of a list). So you
are forced to think differently, with different pathways, rather
than just obliquely, as you do when learning OOP. And with
the incredible module systems and libraries of Ocaml and SML,
you can build ADT's that are more than ADT's - that are sort
of polymorphic ADT's combined with templates. You get reuse
and power and problem subdivision already with ML, so you
don't need OOP. It's not that OOP is a bad thing; it's that
you don't seem to need it in ML, because ML's existing
problem-subdivision mechanisms are more than up to the task.
I've been following the CAML list regarding OOP, and as far
as I can tell, most of the people who are making heavy use
of Ocaml's OOP features are those who are coming to Ocaml
with a heavy predisposition toward the OOP style of programming.
OOP provides something familiar to them, something they can
feel comfortable with. This is a good thing ... it took me
many months to learn the language because there was so little
in it that was familiar to me.
A well-written ML/Ocaml program is a thing of beauty. FP
lets you write poetry rather than prose. In my humble
opinion, OOP doesn't help FP, it clutters it. Ocaml is
nice because you are free to use the OOP features or not
as you choose. But if I were designing a new FP language,
I would skip the OOP features and concentrate on making
the FP core fast and clean and portable and elegant.
It's not that easy to design an FP language these days.
Scheme and ML are rather elegant and well-thought-out,
and you'd have to do a whole lot better than them to
gain any audience. Haskell was designed explicitly to
unite the wandering nomadic tribes of the lazy-evaluation
steppes. Ocaml is very successful because it has one of
the finest implementations of any programming languages,
ever. I suppose you could do a stunningly fast Haskell
... There does seem to be room for improving the usual
imperative languages by adding FP features, though.
The difficulty and the wonder of FP both spring from the
same source, I think. Scheme, ML, Ocaml and Haskell are the
products of some of the best thinkers in the field.
They are our top-drawer talents, our blue-chippers.
Elegance and clarity and beauty and power really matter
to these guys, and they are open to peer review and
external criticism. They publish their specs as well
as their implementations freely. So it's no surprise
that Milner got the award for ML, or that Scheme has
taken over much of the academic community, or that
these languages are rigorously defined and meticulously
implemented.
But ... then again, it's no surprise that these languages
are hard to learn, either. Instead of sitting down and
learning to print "hello, world" on the display, you are
handed a treatise on the lambda calculus and are expected
to understand combinators in a few hours. Instead of
filling out a dialog box (as in Visual Basic) that specifies
the colors and fonts of your application's main window,
you are introduced to currying and first-order functions
and tail recursion elimination. Jeez, where did all the
audience go? Out the exits, that's where, out to something
familiar and understandable without a math degree.
You want to help the FP community? Build us a language
that we can teach to the Visual Basic crowd. Build us
a language like Pizza, the Java veneer with the essential
FP features, but fast and usable. Find a way for us to
take these amazingly beautiful concepts that Milner, Steele,
et al, have brought down from the gods to us, and distribute
them to the masses.
No, with apologies to Xavier Leroy, for whom I have the
highest respect -- we don't really need OOP features in FP.
What we need is a way to give to the rest of the world what
we have already found for ourselves. FP, not OOP, is the
real revolution, the real break-through, the real hope for
the programmers of the next generation.
Dwight "ML until I die" VandenBerghe
Jeff Meunier
> I'm relatively new to FP and used to program in an OO-fashion. My
> personal preferred PL is Eiffel, I now try to find out where OOP and
> FP good be best combined. The following candidated don't look bad:
>
> - OCAML
> - CECIL
I don't know CECIL, but I recommend OCAML highly. Get the documentation
and browse through it to get an idea of all the neat things it can do.
> Do you think it's a good idea to combine FP and OOP Elements in one
> language?
I think it's a great idea to combine the practicality of OOP with the
beauty of FP. OOP is a very useful paradigm that just about anyone can
grasp. FP, on the other hand, usually takes a while to fully understand,
and as a result FP is abandoned prematurely. Sinve FP is not taught at
many univesities (like mine), people are left to pick it up on their own
(like I was), and are often left with a bad taste for FP. I don't *want*
to learn about monads and category theory, I just want to write
programs. It's good to have a language that you can pick up easily, and
which has familiar aspects.
> Or do you think that a language should purely be functional and/or
> oo-oriented?
Pure OOP gives you Smalltalk (among others), which is a very nice
language. Pure FP gives you Haskell, which is also very nice. The
problem with Haskell is that it's difficult to do simple imperative
things, like printing out the value of a variable at the beginning of a
function (without using monads, which I still don't understand too
well). Although impure, a small amount of imperative-ness is handy. It
doesn't matter if a programming language is perfect in some respect
(e.g., Haskell). It still needs to be used by programmers. Look at C
and C++: they are terrible languages, but tremendously successful, and
rather easy to learn.
Granted, if FP were taught from the start, things would be different. I
can imagine an alternate universe in which students stay up all night
studying because they can't quite grasp iteration and variable mutation,
but where types and recursion are covered to completion on day 1.
> Here's what I like about Eiffel (the idea of Design by Contract), so I
> expect that functional elements in assertions could help a lot.
OCAML has assertions as a standard feature.
> The full power of FP-language seemed to be the direct support for
> abstract datatypes. So I like the way for example how Stacks are
> implemented in FP-languages.
OCAML has quite a few useful standard modules: stacks, hashtables, sets,
streams. Even lexers and parsers are standard.
OCAML also supports compiliation to bytecode or native code, it has a
debugger and profiler, supports sockets and cryptography, and takes up
only 8MB of disk space.
--
Jeffrey A. Meunier
Booth Research Center
University of Connecticut
http://www.engr.uconn.edu/~jeffm
Graham Matthews
: Friedrich Dominicus wrote:
: Pure OOP gives you Smalltalk (among others), which is a very nice
: language. Pure FP gives you Haskell, which is also very nice. The
: problem with Haskell is that it's difficult to do simple imperative
: things, like printing out the value of a variable at the beginning of a
: function (without using monads, which I still don't understand too
: well). Although impure, a small amount of imperative-ness is handy.
I think a distinction needs to be made here. If you are just printing
out the value of a variable for debugging purposes then that should be
easy and should not involve monads (cf: 'trace' in Gofer). Often such
debug printing is not easy but that's the fault of the implementation
(more money needs to be directed to programming environments -- I know
researchers don't get funded for that ...). If you are printing out
the value of a variable for purposes other than debugging then that
should involve monads or uniqueness types or whatever the I/O mechanism
is.
graham
--
He'll be riding that fast train to Memphis
On that sweet R & B
Till the green grass way down home
Grows up over me
John Velman
and some eloquent, as well. I'm a newcommer to FP, and, as it happens,
I spent a while today trying to download "fp+oop=Haskell" by Emery Berger.
Without success.
Is the Emery Berger article completely off base, or ...?
If anyone can point me to a place I can download the Berger article, I'd
appreciate it. I tried Emery's site, and the link to the ..ps.gz version
seemed to go nowhere. I found an HTML version somewhere, but I'd really
like something I can put on old fashioned paper. I tried the
.dvi.Z, ..ps.Z at haskell.org/papers. The files downloaded, but
my gunzip says they are corrupted (yes, I retried the download). Other sites
I found had apparently broken links to the paper.
Best regards,
--
John Velman
jrve...@mail.hac.com
Patrick Logan
: I've read a number of the responses to this, and found them all
: interesting and some eloquent, as well. I'm a newcommer to FP, and,
: as it happens, I spent a while today trying to download
: "fp+oop=Haskell" by Emery Berger. Without success.
: Is the Emery Berger article completely off base, or ...?
I have not read it. However, Simon Peyton-Jones has some information
on his "work in progress" pages about existential types that are going
to be in GHC (and Haskell 2, eventually, I guess).
Existential types enable the kind of polymorphism usually associated
with the phrase "object-oriented programming". For example a list can
contain all kinds of objects as long as they have some set of
functions defined (i.e. the "methods" of the objects).
This is useful for implementing things like graphics editors where a
"canvas" has all kinds of various objects in its list of shapes. The
shapes can be any kind of type as longs as they support some set of
"methods" like "draw" (for display on the canvas) or "drop" (for
drag-and-drop user interfaces).
--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com
Lennart Augustsson
Patrick Logan <plo...@user2.teleport.com> writes:
> I have not read it. However, Simon Peyton-Jones has some information
> on his "work in progress" pages about existential types that are going
> to be in GHC (and Haskell 2, eventually, I guess).
They have been in HBC for about four years now. There are universal
types too, but you have express them differently than the current GHC
syntax.
--
-- Lennart Augustsson
[This non-signature is unintentionally not left unblank.]
Klaus.S...@home.ivm.de
> Re: What language do you think is a good combination between OOP and FP
> References:
> <35A5D6AA...@inka.de>
>
>> I'm relatively new to FP and used to program in an OO-fashion. My
>> personal preferred PL is Eiffel, I now try to find out where OOP and
>> FP good be best combined. The following candidated don't look bad:
>>
>> - OCAML
>> - CECIL
>>
>
>Dylan
>Common Lisp
How does Scheme with TinyClos, STklos, BOS or Yasos compare, FP-OOP-compromise
-wise?
Klaus Schilling
Rainer Joswig
(Dwight VandenBerghe) wrote:
> It's a different way of thinking. Python (or Modula-3, or
> Eiffel, or SmallTalk, or Objective-C) has a world view that revolves
> around classes and inheritance and method overrides and so forth.
> It's a way of dividing up a problem to manage the complexity.
> It's not terribly bad, but it sure isn't as good as its evangelists
> claim. (It IS terribly bad as implemented in C++, but there I
> go again.) At root OOP is not a different or more powerful way
> of programming;
I don't agree. OOP (in its many incarnations with different
views on the topic) is an important paradigm.
> FP, on the other hand, is a different and more powerful way of
> programming.
"more powerful"? For what?
> opinion, OOP doesn't help FP, it clutters it.
There are a lot of different ideas/dimensions what "object-oriented" is
about.
Prototype-oriented view: Objects can delegate.
Logics: Use logic to describe the relations, concepts and individuals.
Message Passing: Communicating objects.
Generic Functions: Choose implementation based on argument classes.
...
> It's not that easy to design an FP language these days.
> Scheme and ML are rather elegant and well-thought-out,
Common Lisp is another language with a very clean idea
about OOP. Classes with multiple inheritance
will give you the data structures. Generic Functions
capture the functionality. A machinery with
very dynamic features (method combination) determines
the runtime behaviour. The language is extensible
in terms of itself, so that you have an object-oriented
reflective language that has an Meta Object Protocol.
So Common Lisp combines OOP-features (Classes, Inheritance, ...)
with FP (Generic Functions). Lisp programmers have
been long using object-oriented ways of thinking
in their software. Actually the operating system
of the Lisp machines is implemented using the techniques.
Dylan is an attempt to simplify these ideas, add things
like type inference and sell it to the average programmer.
Harlequin has recently released a free version for Windows.
See at http://www.harlequin.com/ .
Rainer Joswig
They all try to bring various ideas of Common Lisp (CLOS) into
Scheme.
Dylan also is like a Scheme with CLOS (minus Meta Object Protocol,
minus method combinations, minus ...).
Bob Manjoney
What are GHC and HBC, and where might I find more information on them?
Thanks,
Bob Manjoney
McHugh Software International
Lennart Augustsson wrote in message ...
Patrick Logan
: What are GHC and HBC, and where might I find more information on them?
They're Haskell compilers, http://www.haskell.org
Fergus Henderson
>Existential types enable the kind of polymorphism usually associated
>with the phrase "object-oriented programming". For example a list can
>contain all kinds of objects as long as they have some set of
>functions defined (i.e. the "methods" of the objects).
Yep. Existential types are The Way To Go [TM].
But in OOP, objects generally have three important properties:
identity
state (normally mutable)
methods
Existential types help with the methods, but they don't help
with object identity or mutable state.
Now there's ways to handle those in Haskell too, but I suspect that if
you're really doing lots of object oriented programming then a language
with more direct support for OOP may be more elegant.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Jacques Garrigue
> I'm an Ocaml user, and while I love the language, I don't use the
> OOP features much. It's not that I'm completely adverse: in Python,
> for instance, I use OOP all the time, and I've been writing OOP-
> style C++ for many years. (But I hate it, and that's a different
> story for another time.)
[...cut a lot of interesting remarks...]
> No, with apologies to Xavier Leroy, for whom I have the
> highest respect -- we don't really need OOP features in FP.
As another Ocaml user, I must say that I mostly agree with you:
in most cases, FP is more than enough to solve the problem, and there
is no real need for OOP. Unneeded use of OOP may clutter your program.
I believe OOP is an interesting paradigm, but when it comes to make
concise and error-free programs, and even efficient ones, FP is a
better choice.
Still, I wouldn't say as you that we don't need OOP features in FP. I
happen to be using them quite often. Strangely, not for what OOP
supporters would sell them: it is too difficult to make a really safe
library using OOP. While a functional library can be almost completely
characterized by its interface, with OOP protocols need to be
explained informally. I believe there is work in the OOP community to
formalize that, but for now FP wins. The reusability claims of OOP
come very short when you compare them with the FP possibility of
reusing any bit of code.
However, I see at least two reasons to use OOP in a functional context:
* Objects are a useful concept, particularly for prototyping. They may
help you structure your program. While I would not use them in
libraries (or only in very restricted cases), I see no problem in
using them at the user level, when code reuse is not so much a
problem. Consider also the problems related with the use of
references in ML. I prefer to use an object with a mutable instance
variable, and know the scope of my variable.
Why not use an ADT? With objects and inheritance it is easier to
provide several variations on the same basic interface. Once an
ADT is closed, there is no easy way to extend it. However if I'm
going to turn this into a library, I might start thinking harder,
and build an ADT covering the needed variations.
* There are cases where you need objects for typing. Parametric
polymorphism is wonderful, but it does not cover everything.
Heterogeneous containers are not available for instance. Object
subtyping is a way to refine typing, and be able to express more in
a type-safe system.
I shall add that I do not believe that OOP is the only useful
extension one may add to FP. There are many other directions to
explore. There is of course a tradeoff between expressivity and
complexity of the language, but remember that currently the public for
FP is a knowledgeable one, and ready to learn.
> What we need is a way to give to the rest of the world what
> we have already found for ourselves. FP, not OOP, is the
> real revolution, the real break-through, the real hope for
> the programmers of the next generation.
The question is maybe: Are we ready?
Certainly, we have found ways to solve our problems using FP, but can
we solve all problems using FP? If this is not the case, can we provide
a unified model for integrating with systems that solve the problems
we cannot solve?
FP is a wonderful paradigm for writing compilers and theorem provers.
We have known this for long. It can also be used for many other tasks,
but there proving its superiority will not be that easy.
I read a lot about Erlang on this newsgroup. I sincerely believe this
is a wonderful language, and a step in the good direction. But can it
pretend to be as universal as C/C++ ? If no, what are users expected
to do for areas not covered by the language?
I would really like to know what is the real strength of FP now, not
only in terms of what one can do with it, but also in terms of how
easily the peripheral problems, and particularly the relation with the
non-FP world can be handled, both conceptually (what is an object seen
from the FP side) and practically.
Regards,
Jacques
---------------------------------------------------------------------------
Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
thomas...@erix.ericsson.se
Jacques Garrigue <s...@my.signature> writes:
> I read a lot about Erlang on this newsgroup. I sincerely believe this
> is a wonderful language, and a step in the good direction. But can it
> pretend to be as universal as C/C++ ? If no, what are users expected
> to do for areas not covered by the language?
I'm not sure Erlang should go for being a universal replacement for
C or C++. I think it's probably more rewarding to focus on its strengths
instead, and provide graceful interfacing with the rest of the world.
(Though I'm willing to be convinced otherwise.)
Anyway, to answer your second question, there's support in Erlang/OTP
for interfacing with C, C++, Java, CORBA and heaven knows what else :-)
Thomas
--
Thomas Lindgren thomas...@erix.ericsson.se
Software Architecture Research Centre avoid +junk to mail me
Ericsson Telecom AB
Patrick Logan
: Yep. Existential types are The Way To Go [TM].
: But in OOP, objects generally have three important properties:
: identity
: state (normally mutable)
: methods
: Existential types help with the methods, but they don't help
: with object identity or mutable state.
: Now there's ways to handle those in Haskell too, but I suspect that if
: you're really doing lots of object oriented programming then a language
: with more direct support for OOP may be more elegant.
I have been writing with OOP languages for 15 years: Lisp (Flavors),
Smalltalk, C++, and now Java. For the last year I have been learning
Haskell and some of the non-standard features. (I am just tackling
existential types right now.)
The issues Fergus lists above are the crux of the matter to
me. Particularly state. I am debating with myself the true benefit of
a static type system having the responsibility of ensuring side
effects (i.e. state) are safe.
On the one hand, I think, yes, it is a great idea. The more work the
compiler can do for me statically the better.
On the other hand, the current type systems that I have used for
Haskell can be frustrating to this novice. The fact that I have to
carry a type system's signature for state from main down through the
various functions that will manipulate some of the state is a burden.
My current leaning is that a simple dynamic language like Smalltalk
combined with good design habits for encapsulating state is the most
pleasant way to program a large system. But what I am faced with is
the challenge to spend enough time with Haskell to give it a fair
chance before giving up. I think the combination of good technology
and good wisdom for using that technology is not ready yet. Maybe in
five years the language implementors and the trail blazing application
developers will have provided the evidence.
Comments?
Bob Hutchison
>Friedrich Dominicus wrote:
>> Here's what I like about Eiffel (the idea of Design by Contract), so I
>> expect that functional elements in assertions could help a lot.
>
>OCAML has assertions as a standard feature.
>
>
What kind of assertions? Are they like Eiffel's (pre and post
conditions, class invariants, loop variants and invariants)?
Cheers,
Bob
---
Bob Hutchison, hu...@RedRock.com, (416) 878-3454
RedRock, Toronto, Canada
doy...@my-dejanews.com
>
> > Here's what I like about Eiffel (the idea of Design by Contract), so I
> > expect that functional elements in assertions could help a lot.
>
> easily be added via method combination.
It depends on your definition of "better". If you mean "more flexible"
you're probably right because Eiffel's exception mechanism is specifically
designed not to be flexible. They're known as "disciplined exceptions" and
their contribution to large-scale software reliability are discussed in
Bertrand Meyer's Object-Oriented Software Construction (2nd edition).
-PD
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Nick Kallen
>we have already found for ourselves. FP, not OOP, is the
>real revolution, the real break-through, the real hope for
>the programmers of the next generation.
Programmers of the world unite!
I've been programming in Haskell and Clean for about two years now.
Admittedly a brief period compared to some of the posters in this thread.
But I just have to say, some of the silly and naive remarks made in this and
its root thread are striking.
FP is awesome. It's radically different than the more conventional
languages; tons of features from closures to laziness to recursive data
types to you name it make programming in the small (henceforth called
microprogramming) in functional languages superior to anything that exists.
Unfortunately, FP as it stands now is not the be all end all for
programming in the large (henceforth called macroprogramming). Yeah,
countless papers from "Why Functional Programming Matters" to <insert
something more modern here> explain how wonderful higher order functions can
make code reuse a snap. Well, snap shmap, it's not that wonderful when
you're dealing with large programs. Large applications need better
abstraction mechanisms than simply functions and modules. This is a fact.
Subtyping, is an essential one, and can only be expressed extremely crudely
using type classes. Inheritance, which cannot be expressed using type
classes, is also extremely valuable. It can't simply be accomplished with
higher order functions and the like without extremely verbose, inelegant,
and hard to write code.
Object Orientation which doesn't provide subtyping but does provide
inheritance, is far from perfect, but has *proven* to be a great abstraction
mechanism for macroprogramming. The fact of the matter is, when you're
dealing with huge programs, ADTs don't cut it. You need subtyping and/or
inheritance, you need to group data with their operations in objects. Not to
mention that Objects and Message passing is a much more convenient
"real-world" macroprogramming model of how a program works. Message passing
is a far better abstraction mechanism for programming in the large. FP can
simulate message passing only in extremely crude ways.
Lastly is state. I love referential transparency more than God, but one
has to admit that IO done in Haskell and Clean is simply unsatisfactory.
Monads are extremely limiting, hard to learn, and confusing. Not to mention
there's a whole host of problems with them related to concurrency and the
like. These problems are why the Clean people still stick with the
continuation passing style using uniqueness types. I bet anyone here who has
tried to write IO in Clean will agree with me when I say that explicitly
passing around the state to every damn little function is an extreme burden.
Not only do you have to be constantly sign the types of every damn function
with complicated state manipulation signatures, but every damn function has
to return it's data and the new state in a tuple, you have to constantly
worry referencing the state uniquely. It just clogs up the program.
Now, I don't know what the solution is to this dilemma. But it can't
just be ignored. FP as it stands does not provide sufficient state and IO
capabilities.
FP as it stands does not provide sufficient mechanisms for
macroprogramming. It needs subtyping. Higher order polymorphism. Higher
order modules, parameterized modules, etc. etc. As it stands it can't
compete with OO in this regard.
This posting is intentionally polemical and provoking. Hopefully this will
motivate some discussion beyond bashing academics and whining that the mob
can't appreciate beauty.
Jason Stokes
In article <6odqcd$44g$1...@birch.prod.itd.earthlink.net>, Nick Kallen
<pha...@earthlink.net> wrote:
> Object Orientation which doesn't provide subtyping but does provide
>inheritance, is far from perfect, but has *proven* to be a great abstraction
>mechanism for macroprogramming.
Which reminds me -- Haskell's type class system seems to me to need
some serious improvement. The four major deficiencies of it are:
1) Poor support for encapsulation and data hiding; you can't control
which features of an instance are exported to the world, and which are
private to the instance, except through the clumsy module mechanism.
2) Unnecessary distinction between types and type classes, Types like
Int should also be classes, able to be used in context declarations,
inherit, and export features to subclasses. I *really* don't
understand why this strategy was chosen; it seems to me to be simply a
symptom of not imposing a class-oriented paradigm from the ground up.
3) The module mechanism again. In Eiffel the basic unit of modularity
is the class itself, which works very well.
4) Multiple inheritance needs to allow multiple names in a given module
and have renaming or selection of features added in the case of a name
clash. In Eiffel this is accomplished with the rename or undefine
keywords.
- --
Jason Stokes: js...@valis.apana.org.au
See my homepage: http://bluedog.apana.org.au/~jstok/index.html
for my PGP key.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQCVAwUBNaqXmjXsitsNFJm1AQEjtAP/cDsA2Ac9qPWxxD8IF8pbSb7Y+UWrPM+b
JaBetSD4bHoA68ie53SKJxwpHMx5jzMJ5i6KY4uyGjrHI/2rzLg6vlvSl16qdp9l
fJXooeMao6RTyi16ac31DCvgynMSZgm4BYFU4cfKgtTdojBC8mZFJoEjY5ne7rZl
FMmzQuysmfk=
=CJ3n
-----END PGP SIGNATURE-----
Elan
Friedrich Dominicus wrote:
> I'm relatively new to FP and used to program in an OO-fashion. My
> personal preferred PL is Eiffel, I now try to find out where OOP and
> FP good be best combined.
I wonder what y'all think of Beta?
TIA
Elan
Daniel C. Wang
Patrick Logan <plo...@user2.teleport.com> writes:
> My current leaning is that a simple dynamic language like Smalltalk
> combined with good design habits for encapsulating state is the most
> pleasant way to program a large system. But what I am faced with is
> the challenge to spend enough time with Haskell to give it a fair
> chance before giving up. I think the combination of good technology
> and good wisdom for using that technology is not ready yet. Maybe in
> five years the language implementors and the trail blazing application
> developers will have provided the evidence.
>
> Comments?
>
Don't forget to take a look at ML. It's very much like Haskell without the
laziness or pain of making side effects explicit in the type system.
Mike Williams
"Nick Kallen" <pha...@earthlink.net> writes:
.
|> FP as it stands does not provide sufficient mechanisms for
|> macroprogramming. It needs subtyping. Higher order polymorphism. Higher
|> order modules, parameterized modules, etc. etc. As it stands it can't
|> compete with OO in this regard.
We have made several very large systems using Erlang. Does 300K to
500K lines of code count as "macroprogramming"? (equivalent to
somewhere around 1.5M Lines of C++). I wonder how we managed to make
these systems without "higher order polymorphism, higher order
modules, parameterized modules, etc. etc.". Must have been a pure
fluke..........
/Mike
--
mi...@erix.ericsson.se ++46 8 7197855
Ericsson Telecom AB, Dept ÄT2/ETX/DN/S, S 126 25 Stockholm, Sweden
Mike Williams
solutions and complex tools. This is quite wrong. The larger a project
becomes, the more important it is to strive to maintain simplicity.
Also the larger a project becomes, the harder it is to keep things
simple. The danger of design by committee becomes overwhelming.
At an academic level combining OO and FP may seem a good idea. At a
practical level, it is an idea which would accelerate the rate at
which my hair is turning grey. Large software development are done by
"average" programmers. The hardest task they have is to understand
*what* it is they are designing, i.e. the application. This is usually
never properly specified and subject to alteration during the course
of the project. In order to be able to focus on "what" it is essential
to keep "how" as simple as possible. This is why complex languages
such as C++, Ada aren't a good idea. This is also why taming the
operating system which a layer of "middle-ware" is a good idea to
prevent time effort and energy being wasted on understanding the often
bizarre features of operating systems.
/Mike
PS. Here at Ericsson, we have more experience of very large projects
using FP than anywhere else in the world. My comments are based on
personal experience.
In article <6odqcd$44g$1...@birch.prod.itd.earthlink.net>,
"Nick Kallen" <pha...@earthlink.net> writes:
|> Programmers of the world unite!
|>
|> I've been programming in Haskell and Clean for about two years now.
|> Admittedly a brief period compared to some of the posters in this thread.
|> But I just have to say, some of the silly and naive remarks made in this and
|> its root thread are striking.
|> FP is awesome. It's radically different than the more conventional
|> languages; tons of features from closures to laziness to recursive data
|> types to you name it make programming in the small (henceforth called
|> microprogramming) in functional languages superior to anything that exists.
etc etc
Brian Rogoff
> ... snip ...
>
> On the other hand, the current type systems that I have used for
> Haskell can be frustrating to this novice. The fact that I have to
> carry a type system's signature for state from main down through the
> various functions that will manipulate some of the state is a burden.
Maybe you should consider a statically typed functional language with
OO and imperative features, like OCaml? OCaml really is a pleasure to
use; maybe one day it will replace Perl (*).
> My current leaning is that a simple dynamic language like Smalltalk
> combined with good design habits for encapsulating state is the most
> pleasant way to program a large system.
I disagree, but thats just my leaning. I prefer static typing, and a
powerful module system. Smalltalk has neither. I think I'd prefer
Common Lisp to Smalltalk if were going to forsake static typing, since
at least it has a standard package system.
-- Brian
(*) I think there is too much focus on displacing C and Fortran with FP
languages. Lots of jobs done in Perl today could be done better IMO
with a language like OCaml.
Patrick Logan
: On Mon, 13 Jul 1998, Patrick Logan wrote:
: > ... snip ...
: >
: > On the other hand, the current type systems that I have used for
: > Haskell can be frustrating to this novice. The fact that I have to
: > carry a type system's signature for state from main down through the
: > various functions that will manipulate some of the state is a burden.
: Maybe you should consider a statically typed functional language with
: OO and imperative features, like OCaml? OCaml really is a pleasure to
: use; maybe one day it will replace Perl (*).
I have been thinking about this, yes. I have not tried any of the ML
variants.
Jacques Garrigue
> Jacques Garrigue <s...@my.signature> writes:
> > I read a lot about Erlang on this newsgroup. I sincerely believe this
> > is a wonderful language, and a step in the good direction. But can it
> > pretend to be as universal as C/C++ ? If no, what are users expected
> > to do for areas not covered by the language?
> I'm not sure Erlang should go for being a universal replacement for
> C or C++. I think it's probably more rewarding to focus on its strengths
> instead, and provide graceful interfacing with the rest of the world.
> (Though I'm willing to be convinced otherwise.)
Well, I certainly think as you that this is the good approach. Do
what you can do best, and do not ignore the rest of the world. Still,
even with "graceful interfacing", I believe that multi-language
programming has some rough edges. One is that programmers should know
both languages. Another (but not so much for Erlang, since it is
untyped) is that you loose information at the interface. I see also
problems with debugging. Finally, while splitting the code between two
languages may be reasonable for large projects, isn't it a burden
during the prototyping phase?
I shall add, maybe this is really the right approach for Erlang:
define precisely the area of application of the language, and make it
simple and efficient. But I see the future of FP as being more
ambitious, extending to many more areas of programming. This does not
seem unreasonable, when you think that ML can compare in efficiency
with C, modulo an acceptable factor. Then problems get more complex.
> Anyway, to answer your second question, there's support in Erlang/OTP
> for interfacing with C, C++, Java, CORBA and heaven knows what else :-)
Wonderful. I should have expected that from a production quality
language. For the first 3 languages, I understand that you can
interface with foreign code. Can you also use libraries easily?
According to Erlang's approach, you would probably rather program in
the original language if you are to use a library, so you don't need
to interface with libraries themselves, but what happens when you want
to use simultaneously an Erlang and a C++ library ?
thomas...@erix.ericsson.se
Jacques Garrigue <s...@my.signature> writes:
> > Anyway, to answer your second question, there's support in Erlang/OTP
> > for interfacing with C, C++, Java, CORBA and heaven knows what else :-)
>
> Wonderful. I should have expected that from a production quality
> language. For the first 3 languages, I understand that you can
> interface with foreign code. Can you also use libraries easily?
The standard mechanism is the port, which is fairly heavyweight
but appropriate for device drivers and similar stuff.
I haven't kept up with how things have evolved beyond that or
precisely what mechanisms are used today, so I'll have to
refer you to the OTP guys for authoritative answers to your
questions.
I tend to go for straight Erlang, no chaser, myself :-)
Andrew Bromage
js...@bogus-address.apana.org.au (Jason Stokes) writes:
>Which reminds me -- Haskell's type class system seems to me to need
>some serious improvement. The four major deficiencies of it are:
>1) Poor support for encapsulation and data hiding; you can't control
>which features of an instance are exported to the world, and which are
>private to the instance, except through the clumsy module mechanism.
Haskell's module system definitely seems like an afterthought, and IMO
it's the most annoying "feature" of the language. Give me ML or Modula-2
any day.
But we can't blame type classes for that.
>2) Unnecessary distinction between types and type classes, Types like
>Int should also be classes, able to be used in context declarations,
>inherit, and export features to subclasses. I *really* don't
>understand why this strategy was chosen; it seems to me to be simply a
>symptom of not imposing a class-oriented paradigm from the ground up.
It was chosen because it fits neatly onto the Hindley-Milner type
system, basically.
I do have some problems with your suggestion. When you blur the
distinction between type classes and types, you also blur the
distinction between type classes and data objects. (Which is what
you want. You want a class system rather than a type class system.)
I suspect that it would have bad implications for type inference, but
I'm not sure. I didn't think too hard about it.
The reason that I prefer type classes to classes in many situations
is that you don't have to specify all of the methods of a type where
you declare the type. For example, suppose you want some new dictionary
ADT which requires some strange information (like a hash code only
weirder) in order to do its job. In a language like Eiffel or Java,
you'd have to change the declaration for each type that you want to
store in this ADT. Not so with type classes. You can just retro-fit
the appropriate methods onto the type, and you don't get the overhead
of those new methods when they're not used.
Type classes also solve many multiple inheritance problems, which is
important because Haskell's type system is heavily dependent on multiple
inheritance. If you only inherit interfaces, the problems are solved.
BTW, what are you planning to subclass Int as?
>3) The module mechanism again. In Eiffel the basic unit of modularity
>is the class itself, which works very well.
It works well for some applications, especially widget libraries. I'm
not so convinced that it's a good idea in general, though.
>4) Multiple inheritance needs to allow multiple names in a given module
That's not a type class problem either. That's a name overloading
problem. I can't see a good way out for Haskell here because of
currying --- a name has a type of its own, independent of the number
of arguments which you supply. Ironically, good Haskell compilers
try to jump through hoops to try to get rid of the currying, which
makes me wonder if it was a good idea to rely on it so much in the
first place. I should point out that Clean doesn't have this problem,
since it is a graph rewrite system rather than a lambda calculus system.
I suspect that a good sub-module system would alleviate this somewhat,
though. Overload names by module-qualifying where appropriate.
>and have renaming or selection of features added in the case of a name
>clash. In Eiffel this is accomplished with the rename or undefine
>keywords.
I always thought those were a bit of a hack. Attempts to overcome a
problem which should never have happened.
Cheers,
Andrew Bromage
Buday Gergely
> capabilities.
> FP as it stands does not provide sufficient mechanisms for
> macroprogramming. It needs subtyping. Higher order polymorphism. Higher
> order modules, parameterized modules, etc. etc. As it stands it can't
> compete with OO in this regard.
Subtyping is needed, you're right.
I think SML has the power, just the appropriate design methods are missing,
or not well formulated. Cf. Booch, SSADM, etc.
- Gergely
Brian Rogoff
> On Mon, 13 Jul 1998, Nick Kallen wrote:
> > FP as it stands does not provide sufficient mechanisms for
> > macroprogramming. It needs subtyping. Higher order polymorphism. Higher
> > order modules, parameterized modules, etc. etc. As it stands it can't
> > compete with OO in this regard.
>
> SML has parameterized modules, SML/NJ even has higher order functors as well.
> Subtyping is needed, you're right.
Well, its useful anyways. I think for largish projects that a powerful
module system which supports separate compilation is much more important.
OCaml has this, as well as an object system.
> I think SML has the power, just the appropriate design methods are missing,
> or not well formulated. Cf. Booch, SSADM, etc.
Since the Ada 95 module system lifted many ideas from SML's (*), it might
be fruitful to start from an Ada based methodology like HOOD. You can find
info at www.hood.be. The HOOD method encourages conservatism towards OO
polymorphism, I suspect that SML would be a good target language.
-- Brian
(*) Ada 95 added generic signature packages and generic formal package
parameters to Ada 83. Unfortunately, exceptions are not typed and
thus don't appear in the signature.
Matthias Blume
On Mon, 13 Jul 1998, Nick Kallen wrote:
> capabilities.
> FP as it stands does not provide sufficient mechanisms for
> macroprogramming. It needs subtyping. Higher order polymorphism. Higher
> order modules, parameterized modules, etc. etc. As it stands it can't
> compete with OO in this regard.
SML has parameterized modules, SML/NJ even has higher order functors as well.
In my experience, SML is *excellent* for programming "in the large".
Personally, I have not missed subtyping. As Buday Gergely points out,
none of the other features mentioned are "missing". Moreover, I don't
think that things like polymorphism, higher-order modules, etc. are in
any way part of the definition of OOP.
Subtyping is needed, you're right.
It may be needed by some of us, but not necessarily by everyone. Most
of the time what people need are mechanisms for abstraction and
modularization. And those _are_ supported by FPLs (perhaps even
better than by OOPLs).
I think SML has the power, just the appropriate design methods are missing,
or not well formulated. Cf. Booch, SSADM, etc.
First of all, that's certainly not the fault of FP itself. Design
methods are not part of any language definition or such. But then,
one should also ask why these things ("patterns", etc.) emerged in the
OO world. Isn't it because programming was such a mess, and the (OO)
languages themselves did not provide enought support to organize it?
I am not claiming that there is _no_ need for design methods in the FP
world, but their current nonexistence can also be seen as an
indication that such auxiliary structuring principles aren't so
essential. People familiar and experienced in functional programming
will tell you again and again that programming is about _types_. The
type systems found in non-OO FPLs are typically simpler and more
rigorous. "Getting the types right" is definitely a good recipe for
writing robust software in a functional way. (Of course, I am
excluding untyped FPLs such as (the functional subsets of) Lisp and
Scheme here.)
Of course, as in any non-trivial formalism, there are a lot of clever
tricks in the way how one can utilize the type system of a language
like ML. Perhaps one day someone will sit down and write a book about
them, and then we can call that our "patterns" or "design methods"...
--
-Matthias
Friedrich Dominicus
some time to read all the messages and to understand what this opinions
mean. But I missed s.th. completly. What has a longer stay, Functions or
Objects. And I do think that Objects Data-Structures stay longer than
any Functions. And another point is the really not easy to understand
art of input/output managing in FP languages. So what do you think about
the following.
Using objects to structure the programs, input/output and all other
stuff done in FP languages, such that all the control-flow structures
are written entirely in an functional way. As I understand you can
easyly replace all the ifs, whiles, loops etc with functional elements
And as I do understand the Functional Languages just provide this
elements because they are sometimes easier to read, but they are not
necessary.
Another thing I think of are that whether you like states or not most FP
languages provide them in one way or another. So I do think states are
very useful even for FP languages, so why not combine the strength of
OOP and FP in a way that each part do the work for which it seems to
suite best?
Best regards
Friedrich
Ulf Wiger
Jacques> [...] I believe that multi-language programming has
Jacques> some rough edges. One is that programmers should know both
Jacques> languages. Another (but not so much for Erlang, since it
Jacques> is untyped) is that you loose information at the
Jacques> interface. I see also problems with debugging. Finally,
Jacques> while splitting the code between two languages may be
Jacques> reasonable for large projects, isn't it a burden during the
Jacques> prototyping phase?
Actually, for Erlang programmers, it is very simple during the
prototyping phase, assuming that you build your product around Erlang.
You can easily build a stub in Erlang which emulates the external
program. By the same token you can migrate components back and forth
between Erlang and e.g. C, without affecting other parts of the system.
Obviously, there's no magic to this - it's merely a question of good
encapsulation, and the combination of processes and a functional
language provides excellent encapsulation.
For C programmers (assume the 2nd language is C), it is a tad bit
more painful, since they must learn some Erlang in order to be
productive. Those of our C programmers who have been forced to do this
complain in the beginning, but in time often become Erlang fanatics
like the rest of us. ;-)
>> Anyway, to answer your second question, there's support in
>> Erlang/OTP for interfacing with C, C++, Java, CORBA and heaven
>> knows what else :-)
Jacques> Wonderful. I should have expected that from a production
Jacques> quality language. For the first 3 languages, I understand
Jacques> that you can interface with foreign code. Can you also use
Jacques> libraries easily?
You can dynamically link in a C routine to the VM, and call library
functions this way. We do this, for example, to change the time zone
of the VM (!). The routine that is used to set the TZ env variable
in Solaris contains 45 lines of C, and is loaded as a shared object.
The overhead of calling such a routine is very small, but debugging
is hard, and the linked-in routing can of course bring down the
entire VM with a rouge pointer. Furthermore, calling a shared object
is a blocking operation, so must behave rather like an interrupt
routine.
Normally, you don't risk this, but use named pipes or sockets. This
is of course slower, but has the advantage of being robust. A foreign
program cannot easily bring down the Erlang VM, but is rather
supervised by an Erlang agent and can be restarted if necessary.
The well-structured way to interface Erlang with other languages
via ports or sockets is to use the Erlang IDL compiler.
/Uffe
--
Ulf Wiger, Chief Designer AXD 301 <ulf....@etxb.ericsson.se>
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuvägen 9, Älvsjö mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden fax: +46 8 719 43 44
Brian Rogoff
> In article Buday Gergely <ger...@math.bme.hu> writes:
> I think SML has the power, just the appropriate design methods are missing,
> or not well formulated. Cf. Booch, SSADM, etc.
>
> First of all, that's certainly not the fault of FP itself. Design
> methods are not part of any language definition or such. But then,
> one should also ask why these things ("patterns", etc.) emerged in the
> OO world. Isn't it because programming was such a mess, and the (OO)
> languages themselves did not provide enought support to organize it?
No, I think you are confusing design methods (Booch, Fusion, HOOD, etc)
with design patterns. Design methods tend to be very general
management techniques for organizing the process of going from
requirements, analysis, design, to implementation. Design patterns, at
least those from the GoF book, are clever little implementation tricks
that arise frequently enough that you give them a name. I think a
common FP pattern that I see in the books is "Parser Builder", for
example. An example of an OO pattern is Observer-Observable, where the
OO-ness comes about because the set of Observers is heterogeneous.
> I am not claiming that there is _no_ need for design methods in the FP
> world, but their current nonexistence can also be seen as an
> indication that such auxiliary structuring principles aren't so
> essential.
It can also be seen as an indication that FP languages aren't widely used
enough in large systems programming to warrant the development of such
techniques.
It's also the case that at least some of the existing design methods could
be used with very little modification with {OCA,S}ML, since the MLs are
"modular, statically typed" languages, not just FP languages.
> People familiar and experienced in functional programming
> will tell you again and again that programming is about _types_. The
> type systems found in non-OO FPLs are typically simpler and more
> rigorous. "Getting the types right" is definitely a good recipe for
This is isn't really specific to FP, but to "typeful" programming in general.
Ada, Modula, and Eiffel programming is about types too. A good design
method should help you get the types right, amongst other things. I would
also expect a good design method to be useable with multiple languages.
-- Brian
Perdita Stevens
> (*) I think there is too much focus on displacing C and Fortran with FP
> languages. Lots of jobs done in Perl today could be done better IMO
> with a language like OCaml.
Intriguing -- please expand...
Perdita
Brian Rogoff
I currently work in the EDA (electronic design automation) industry, but
I've programmed in other fields, so I think this "rant" is fairly widely
applicable.
Perl is very widely used in EDA, for many tasks, file generation and
analysis, test pattern generation, simulation (! yes, its true), you
name it. While Perl has many advantages over C for some of these
tasks, since it has some builtin regexp pattern matching, easier memory
management, etc., it doesn't scale well when I want to do more complex
things with it, like build sophisticated recursive data structures,
netlist equivalence checkers, and other program analysis tools. ML evolved
from the language of a theorem proving system; it is a fairly natural fit
to many kinds of symbolic computing in EDA. If it can do the fairly grungy
stuff that Perl does well, and has an easily portable and available
implementation, then its other advantages give it a significant edge over
Perl in many EDA applications. OCaml works fine for me, though I'm sure I
could get used to SML too.
OTOH, most of the attempts I've seen to do numerical linear algebra, or
low level systems programming, in functional languages, don't seem
compelling. Imperative languages with high level features (parametric
polymorphism, overloading, downward funargs) seem to be sufficient for
these tasks, and the biggest advantage of FP languages IMO, high
readability/length ratio, is not that great here, while one of the biggest
problems with FP languages, poor performance, is really damning here. That
doesn't mean that I don't think functional languages won't eventually do
these tasks well, just that it seems to me that there are greater wins to
be had in going after jobs that can be done much better with FP languages.
There are more than enough of these.
-- Brian
Mike Williams
Brian Rogoff <b...@shell5.ba.best.com> writes:
|> It can also be seen as an indication that FP languages aren't widely used
|> enough in large systems programming to warrant the development of such
|> techniques.
In Erlang we have developed a set of standard design pattern and
libraries to support them. For example we have design patterns for
- finite state machines
- even handlers
- generic servers (i.e. a generic client server model)
All patterns and supporting libraries work in a distributed envinonment and
the also have hooks for debugging and changing code in running systems.
/Mike
Buday Gergely
> On 16 Jul 1998, Matthias Blume wrote:
> > In article Buday Gergely <ger...@math.bme.hu> writes:
> > I think SML has the power, just the appropriate design methods are missing,
> > or not well formulated. Cf. Booch, SSADM, etc.
> >
> > First of all, that's certainly not the fault of FP itself. Design
> > methods are not part of any language definition or such. But then,
> > one should also ask why these things ("patterns", etc.) emerged in the
> > OO world. Isn't it because programming was such a mess, and the (OO)
> > languages themselves did not provide enought support to organize it?
>
> No, I think you are confusing design methods (Booch, Fusion, HOOD, etc)
> with design patterns. Design methods tend to be very general
> management techniques for organizing the process of going from
> requirements, analysis, design, to implementation. Design patterns, at
> least those from the GoF book, are clever little implementation tricks
>
> enough in large systems programming to warrant the development of such
> techniques.
>
> be used with very little modification with {OCA,S}ML, since the MLs are
> "modular, statically typed" languages, not just FP languages.
>
> > People familiar and experienced in functional programming
> > will tell you again and again that programming is about _types_. The
> > type systems found in non-OO FPLs are typically simpler and more
> > rigorous. "Getting the types right" is definitely a good recipe for
>
> This is isn't really specific to FP, but to "typeful" programming in general.
> Ada, Modula, and Eiffel programming is about types too. A good design
> method should help you get the types right, amongst other things. I would
> also expect a good design method to be useable with multiple languages.
>
> -- Brian
>
type-controlled programming is the New Jersey socket library for SML/NJ.
A lot of bugs can be prevented because of the type system.
(I wish they written even docs for it! ;-)
So, the problem
is: given a "real-life" problem, formulate a static type system that reveal
as much errors statically as it's possible.
- Gergely
Dimitrios Souflis
> In article <Pine.BSF.3.96.980718...@shell5.ba.best.com>,
> Brian Rogoff <b...@shell5.ba.best.com> writes:
>
> |> It can also be seen as an indication that FP languages aren't widely used
> |> enough in large systems programming to warrant the development of such
> |> techniques.
>
> In Erlang we have developed a set of standard design pattern and
> libraries to support them. For example we have design patterns for
>
> - finite state machines
> - even handlers
> - generic servers (i.e. a generic client server model)
>
> All patterns and supporting libraries work in a distributed envinonment and
> the also have hooks for debugging and changing code in running systems.
>
> /Mike
To all:
How about publishing recurring solutions in a FP setting in this
newsgroup? Maybe the FP community can assemble its own "GoF" book.
Obviously, the precise form of GoF patterns, with its emphasis
on class and object hierarchies is unsuitable. We should design
a new way of writing down a recurring solution to a recurring
problem (a.k.a. a design pattern). I believe that teaching
real-world FP would benefit from such a corpus of wisdom. Not to
mention the ability to convince others that FP is useful and
practical.
Would someone with more experience than me write in a semi-formal
way "Parser-Builder"? Or any other functional "pattern"?
--
Dimitrios Souflis dsou...@altera.gr
Altera Ltd. http://www.altera.gr/dsouflis
*** If Hungarian is so great, dwhy vdo aits nproponents
*** dnot vuse nit ain atheir nemail?
Claes Wikstrom
Jacques Garrigue <s...@my.signature> writes:
> I read a lot about Erlang on this newsgroup. I sincerely believe this
> is a wonderful language, and a step in the good direction. But can it
> pretend to be as universal as C/C++ ?
No,
> If no, what are users expected
> to do for areas not covered by the language?
Use the language which is appropriate for the task at hand !
Systems programming today is such a horribly complex task
so a whole lot of languages are necessary in order to
complete the task. This is no big deal, we just use the
language which is best for each particular task. As an example,
the erlang Virtual Machine is hardly written in Erlang, it's
written in C, whereas a whole lot of the installation, compilation
and administration scripts dealing with the Erlang source are written
in bourne shell or perl5.
On the other hand, if I was assigned the task to write
i.e the software for a worldwide stock broker firm, or a
control system for a large industrial plant, I'd use Erlang.
Cheers
/klacke
+--------------------------------------------------+
| Claes Wikstrom , tel: +46 8 719 81 08 |
| email: kla...@erix.ericsson.se |
| WWW: http://www.ericsson.se/cslab/~klacke |
| -" Object orientation is a bit like communism. |
| It's a nice idea in theory". |
+--------------------------------------------------+
Shawn Driscoll
>On the other hand, if I was assigned the task to write
>i.e the software for a worldwide stock broker firm, or a
>control system for a large industrial plant, I'd use Erlang.
Have you tried using OS-9 at all in your control systems?
Shawn Driscoll
http://www.microware.com
Claes Wikstrom
>
> Claes Wikstrom wrote in message ...
> >On the other hand, if I was assigned the task to write
> >i.e the software for a worldwide stock broker firm, or a
> >control system for a large industrial plant, I'd use Erlang.
>
> Have you tried using OS-9 at all in your control systems?
Not to my knowledge. The Operating systems that are used
together with erlang (as middleware) within ericsson
are, Unix(es), VxWorks, WinNT.
Dr Richard A. O'Keefe
> > I read a lot about Erlang on this newsgroup. I sincerely believe this
> > is a wonderful language, and a step in the good direction. But can it
> > pretend to be as universal as C/C++ ?
The underlying assumption here seems to be that it's a GOOD thing
for a language to be 'universal'. But there are two very important
things a language can do for you:
- it can make it EASY to say what you WANT to say
- it can make it HARD to say what you DON'T want to say.
This is a point that designers of scripting languages often miss;
it's not just what you PUT IN that makes a special purpose language
useful, it's what you LEAVE OUT.
Here are some of the things I can say in C++ that I don't WANT to say:
- storage leaks
- unchecked arithmetic errors
- uninitialised variables
- wild accesses to memory
- unsynchronised access to variables in multithread programs
(assuming e.g. POSIX threads)
When you are trying to write reliable software (as Ericsson do)
it is a great saving in development and maintenance time if you
don't have to check for these errors, because they can't possibly
exist.
Doesn't having `unsafe' operations around let you build efficient
and reliable components, using the unsafe operations for efficiency
and encapsulation for reliability? Well, it MAY do so, but there
is no guarantee that it WILL. (Burroughs, now Unisys, developed a
systems programming language in the 70s called NEWP. NEWP modules
that use unsafe operations have to be explicitly flagged, and each
subcomponent has to explictly flag unsafe use. Modula-3 has the
same idea.) I've just been looking at some benchmark results at
http://www.stic.org/, and was pleased but not surprising to see
Smalltalk outperforming C++ for quite a few of the benchmarks.
Another way to look at it is that languages like Smalltalk and
Erlang _have_ encapsulated the unsafe operations: they're in
the runtime system.
There's a book
Taming the Tiger
Leon S. Levy
Springer 1987
ISBN 0-397-96468-7
that goes into the economics of developing special minilanguages
that let you say just what you mean and very little more.
As for what I think is a good combination between FP and OOP,
the answer has to be Clean. Existential types are lovely.
Jacques Garrigue
> > Jacques Garrigue <s...@my.signature> writes:
> > > I read a lot about Erlang on this newsgroup. I sincerely believe this
> > > is a wonderful language, and a step in the good direction. But can it
> > > pretend to be as universal as C/C++ ?
>
> The underlying assumption here seems to be that it's a GOOD thing
> for a language to be 'universal'. But there are two very important
> things a language can do for you:
>
> - it can make it EASY to say what you WANT to say
> - it can make it HARD to say what you DON'T want to say.
>
> This is a point that designers of scripting languages often miss;
> it's not just what you PUT IN that makes a special purpose language
> useful, it's what you LEAVE OUT.
>
> Here are some of the things I can say in C++ that I don't WANT to say:
>
> - storage leaks
> - unchecked arithmetic errors
> - uninitialised variables
> - wild accesses to memory
> - unsynchronised access to variables in multithread programs
> (assuming e.g. POSIX threads)
>
> When you are trying to write reliable software (as Ericsson do)
> it is a great saving in development and maintenance time if you
> don't have to check for these errors, because they can't possibly
> exist.
Maybe you didn't read fully my message, since this quote seems to be
already taken from an answer. Anyway it was never my intention to
disqualify FP as not universal. And I don't think you need all the
above for a language to be universal. I don't think storage leaks or
unsynchronized access are a positive feature of C/C++.
As you write it later in your post, FP or pure OO languages can
compete in efficiency with C. So why shouldn't they try to compete in
all areas ? You seem to assume that leaving erroneous behaviours out
would require to restrict the application area of the language. That
is not clear to me.
Keeping a language small seems to me more a question of manageability
than theoretical possibility. Making a general purpose language is not
easy, but not impossible either. So why should we dismiss it as
useless?
Dr Richard A. O'Keefe
> already taken from an answer.
I read fully _what arrived here_.
> Anyway it was never my intention to
> disqualify FP as not universal.
The phrasing I quoted clearly implied that it isn't.
> And I don't think you need all the
> above for a language to be universal.
You are confusing cause with effect.
The thing is that the expressibility of things you DIDN'T
mean to say is a CONSEQUENCE of universality.
> I don't think storage leaks or
> unsynchronized access are a positive feature of C/C++.
Neither do I, BUT THEY ARE A NECESSARY CONSEQUENCE OF THE
WAY THOSE LANGUAGE DESIGNERS APPROACHED UNIVERSALITY.
If a language *can* do anything,
then it can do *anything*,
including things you don't _want_ to do.
The particular bad things I mentioned are by no means an
exhaustive list. They aren't even the elements of the beginning
of a microscopic fragment of a list of things you _can_ do in C
or C++ but don't want to, that are permitted because _everything_
is permitted.
> As you write it later in your post, FP or pure OO languages can
> compete in efficiency with C.
And the very *reason* that they can do so is precisely that
they are *not* universal. The current Clean compiler, for
example (1.3), can do some compile-time garbage collection,
precisely *because* Clean takes control of memory management
away from the programmer. The fact that SML can omit run-time
type checks (as C and C++ do) without losing type-safety (as
C and C++ do) is precisely *because* the language restricts
your freedom.
> So why shouldn't they try to compete in
> all areas ? You seem to assume that leaving erroneous behaviours out
> would require to restrict the application area of the language. That
> is not clear to me.
I think you have misunderstood. I am actually saying that for
many applications, existing functional languages are already
*TOO* powerful.
I am not at all saying that there is no room in the world for
"universal" languages, whatever they might be. What I *am*
saying is that there is *also* room, far more room than most
programmers can be brought to understand, for languages that
are _just_ powerful enough for the task at hand, so that they
are easier for _people_ to understand, easier for _compilers_
to understand, and harder for either to get wrong.
I think you have also grossly underestimated the mind-boggling
vastness of the set of things we _might_ say but not mean.
For example, how about a language in which it is provable that
every program MUST terminate? Yes, there do exist such languages.
No, that doesn't contradict the Halting Theorem, because the point
is precisely that such languages cannot express _every_ algorithm,
only ones that halt (and not all of them). Such a language is not
suitable for writing an operating system, because you don't _want_
an operating system to stop. But it is perfect for writing
packet filters, and hard real-time programmers ought to be very
interested in such things. For one specific example, the Mercury
compiler is supposed to be able to verify the termination of about
3/4 of the predicates it is given. Some of the remainder are just
beyond its powers, while some of them don't terminate. If one were
using Mercury for real-time programming (and why not?) then making
the "bad behaviours" (i.e. non-termination of the response to an
event) *impossible* would reduce development and maintenance costs,
EVEN THOUGH THE RESTRICTED LANGUAGE WOULD BE LESS SUITABLE FOR
OTHER THINGS.
I just spent two hours today talking about class library design in
a class. One of the things I explained was that if you try to be as
general as possible, you *WILL* be inefficient for some applications.
One example I gave was trees: if you put parent links into your
nodes, that will make some applications run O(N) times faster, but
it will make other applications run O(N) times slower.
There's an old saying "Jack of all trades and master of none."
It applies to libraries and languages as well.
> Keeping a language small seems to me more a question of manageability
> than theoretical possibility.
And what good is an unmanageable language?
Dijkstra pointed out years ago that we have very small heads
and can't manage a lot of detail at once.
> Making a general purpose language is not
> easy, but not impossible either. So why should we dismiss it as
> useless?
It is trivially easy to make a general purpose language.
Just dream up some fancy interrupt-driven Turing machine,
and you're there.
The hard thing is to make a language we can AFFORD TO USE.
Please, if anyone else wants to argue this point, would you
PLEASE read Levy's book "Taming the Tiger"? As I said in my
previous message, that book explains the economics of small
languages.
I am not saying that general purpose or universal languages
are impossible or useless, only that they are EXPENSIVE, and
a good way to spoil a cost-effective language is to add more
features to it.
To connect with another thread, there is one feature of Erlang
which is immensely dangerous. Using that feature can destroy
every guarantee that the language wants to give you.
Dom Sabalos had a swamp ig, and this IG can rapidly put you
in the swamp. "Interface Generator" is of course the means
Erlang uses to let you call C from Erlang...