What language do you think is a good combination between OOP and FP 
Author Message
 What language do you think is a good combination between OOP and FP

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

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

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



Fri, 29 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP

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

--


                 http://www.gemstone.com



Fri, 29 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP

Quote:


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

RedRock, Toronto, Canada



Fri, 29 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP

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

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.



Fri, 29 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP
-----BEGIN PGP SIGNED MESSAGE-----


Quote:

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

- --

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



Fri, 29 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP

Quote:

> 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



Fri, 29 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP

Quote:

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


Fri, 29 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP


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

--

Ericsson Telecom AB, Dept ?T2/ETX/DN/S, S 126 25 Stockholm, Sweden



Sat, 30 Dec 2000 03:00:00 GMT  
 What language do you think is a good combination between OOP and FP
There is a misconception that large programming projects need complicated
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.



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



Sat, 30 Dec 2000 03:00:00 GMT  
 FP/OOP (was: Re: What language...)

Quote:

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

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



Sat, 30 Dec 2000 03:00:00 GMT  
 
 [ 55 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software