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


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

--


                  http://www.*-*-*.com/



Sat, 30 Dec 2000 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++ ?  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.

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

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, 31 Dec 2000 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:

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

                        Thomas
--

Software Architecture Research Centre           avoid +junk to mail me
Ericsson Telecom AB



Sun, 31 Dec 2000 03:00:00 GMT  
 FP/OOP (was: Re: What language...)
G'day all.

Quote:

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

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

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

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

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



Sun, 31 Dec 2000 03:00:00 GMT  
 FP/OOP (was: Re: What language...)
Quote:

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



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

Quote:


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

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



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


   > 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



Mon, 01 Jan 2001 03:00:00 GMT  
 FP/OOP (was: Re: What language...)
Sorry for the late answers to all the interesting comments. I needed
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



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

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

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



Tue, 02 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
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.

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

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



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

Quote:

> (*) 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



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

Quote:


> > (*) 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...

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



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

 Relevant Pages 
 

 
Powered by phpBB® Forum Software