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

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

Author

Message

thomasl+j..#16 / 55

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

: 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

Bob Hutchis#18 / 55

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

Nick Kalle#19 / 55

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

Jason Stok#20 / 55

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.

> 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

Daniel C. Wan#22 / 55

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

Mike Willia#23 / 55

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

Mike Willia#24 / 55

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

Brian Rogof#25 / 55

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.