FP/OOP (was: Re: What language...) 
Author Message
 FP/OOP (was: Re: What language...)



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



Fri, 05 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)
Quote:



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

> 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

Yeah, "typeful" sw. design method is what I'm missing. A nice example of
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



Fri, 05 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:



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

--

Altera Ltd.                      http://www.altera.gr/dsouflis

*** If Hungarian is so great, dwhy vdo aits nproponents
*** dnot vuse nit ain atheir nemail?



Sun, 07 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:

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

Quote:
> 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            |

| WWW:   http://www.ericsson.se/cslab/~klacke      |
| -" Object orientation is a bit like communism.   |
|    It's a nice idea in theory".                  |
+--------------------------------------------------+



Thu, 11 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:

>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



Thu, 11 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:


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

/klacke

+--------------------------------------------------+
| Claes Wikstrom , tel: +46 8 719 81 08            |

| WWW:   http://www.ericsson.se/cslab/~klacke      |
| -" Object orientation is a bit like communism.   |
|    It's a nice idea in theory".                  |
+--------------------------------------------------+



Thu, 11 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:

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



Sat, 13 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:

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

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>



Sun, 14 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:
> Maybe you didn't read fully my message, since this quote seems to be
> already taken from an answer.

I read fully _what arrived here_.

Quote:
> Anyway it was never my intention to
> disqualify FP as not universal.

The phrasing I quoted clearly implied that it isn't.

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

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

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

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

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

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



Mon, 15 Jan 2001 03:00:00 GMT  
 
 [ 55 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software