RE: [Haskell-cafe] State of OOP in Haskell
Lennart wrote: OOHaskell is ingenious, but it's a terrible way to use Haskell. It's very unidiomatic Haskell, and it makes you do things in the same old OO way. It's probably obvious but let me say that ... OOHaskell is more of a proof of concept and a sandbox for OO language design. It is not a serious proposal for actual OO application development. Alexy wrote: And OOHaskell didn't compile for me on GHC 6.6... tells you about currency of use. I know a few people trying to use it. :-) Oleg and I were distracted but will update OOHaskell for 6.6 soon. Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
Steve Downey wrote: The primary goal of writing source code isn't to communicate to a computer, but to communicate to a human being. That implies that the communication should be at a high enough level of abstraction to be easily understood by people, while not losing the precision necessary for a computer. OO, at least when done well, maps well to how people think. Things that can be directed to perform actions. There is also a well developed practice of OO analysis and design. It's not clear (at least to me) that there is an equivalent set of practices for functional programming. Some of Haskell constructs come from the area of formal methods. Notably, algebraic types come from Z-notation (as I am told). Formal methods in general and Z notation in particular precede OO as defined, for example, in Smalltalk-80. Formal methods do not require substantial training and/or costly tools (although both exists). It can be trained in several weeks and start bringing benefits. Here are two surveys (somewhat outdated) on the use of formal methods in industry: http://citeseer.ifi.unizh.ch/39426.html http://citeseer.ifi.unizh.ch/craigen93international.html So, you can safely borrow methodics from formal methods and even think about Hindley-Milner type system as a theorem prover. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
The primary goal of writing source code isn't to communicate to a computer, but to communicate to a human being. That implies that the communication should be at a high enough level of abstraction to be easily understood by people, while not losing the precision necessary for a computer. OO, at least when done well, maps well to how people think. Things that can be directed to perform actions. There is also a well developed practice of OO analysis and design. It's not clear (at least to me) that there is an equivalent set of practices for functional programming. It did take more than a decade for the industry to move from structured analysis and design to OO, even when it was obvious to most practioners that there was a horrible mismatch, and the models coming out of analysis didn't apply. The consensus answer to 'how do I implement my OO model in Haskell' seems to be 'you're asking the wrong question'. But what is the right question? On 1/28/07, Frederick Ross [EMAIL PROTECTED] wrote: I'm going to be offensive, bigoted, and myopic for a minute here: programming straight onto the Turing machine (and not too dissimilarly, the von Neumann machine) is the act of making your thoughts comprehensible to a little gizmo that exists to zip back and forth on an infinite ticker tape. We should therefore abstract. However, I am only marginally happier about making my thoughts comprehensible to a tinkertoy set (which is how I regard object oriented programming). Why not just stay as close to mathematics as possible? Why the deep desire to communicate your loftiest intentions to a tinkertoy set? There was the Lambada project to map between Java's object hierarchies and Haskell, however, and there was a lot of effort put into making Haskell talk properly through COM. Both of those necessitate a model of object oriented programming embedded in Haskell which would provide you with prior art. On 1/27/07, Alexy Khrabrov [EMAIL PROTECTED] wrote: ...In the tradition of the letters of an ignorant newbie... What's the consensus on the OOP in Haskell *now*? There're some libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified type system with inheritance. If I have GHC, which way to do anything OOP-like is considered right today? -- Frederick Ross Graduate Fellow, (|Siggia + |McKinney)/sqrt(2) Lab The Rockefeller University Je ne suis pas Fred Cross! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
Steve Downey wrote: | OO, at least when done well, maps well to how people think. Things | that can be directed to perform actions. There is also a well | developed practice of OO analysis and design. It's not clear (at least | to me) that there is an equivalent set of practices for functional | programming. | [...] | The consensus answer to 'how do I implement my OO model in Haskell' | seems to be 'you're asking the wrong question'. But what is the right | question? That's a good question. In fact, it may even be the right question. (sorry, I'm having a bad week) The OO viewpoint of objects with associated actions is not entirely alien to Haskell/fp. Data types (abstract or concrete) are classes of objects; the associated actions are the functions that process and produce values of the given data type. The nature of functions allows an action to be associated with more than one object, relieving the programmer from a sometimes arbitrary choice: data Car = ... data Garage = ... repair :: Garage - Car - Car Should the repair action be associated with the garage or with the car? Well, with both, actually. (If this example does not convince you, you can probably think of better ones yourself.) Greetings, Arie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
Steve Downey wrote: OO, at least when done well, maps well to how people think. Um, better duck. I am afraid you are about to draw some flames on that one. I hope people will try to be gentle. OO does NOT always map well to how most people think. OO maps well to how people trained in OO think. OO does provide abstraction, as you mentioned. It was the first such abstraction model that became popular. And abstraction was dearly needed at the time, so OO provided that need. But that doesn't mean OO is a good way of providing that abstraction. You'll find that Haskell provides the needed abstraction in a much cleaner, clearer, and consistent manner. I propose that the right question is: list exactly what kinds of abstraction OO provides, and why each is useful. Then, for each one, investigate how it is provided in Haskell. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
OOHaskell is ingenious, but it's a terrible way to use Haskell. It's very unidiomatic Haskell, and it makes you do things in the same old OO way. Presumably people are using Haskell to do things differently? But as I said, I consider OOHaskell itself a work of genius. :) -- Lennart On Jan 27, 2007, at 22:24 , Alexy Khrabrov wrote: What about this OOHaskell: http://homepages.cwi.nl/~ralf/OOHaskell/ -- how is it received in the café? :) Cheers, Alexy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
And OOHaskell didn't compile for me on GHC 6.6... tells you about currency of use. On 1/28/07, Lennart Augustsson [EMAIL PROTECTED] wrote: OOHaskell is ingenious, but it's a terrible way to use Haskell. It's very unidiomatic Haskell, and it makes you do things in the same old OO way. Presumably people are using Haskell to do things differently? But as I said, I consider OOHaskell itself a work of genius. :) -- Lennart On Jan 27, 2007, at 22:24 , Alexy Khrabrov wrote: What about this OOHaskell: http://homepages.cwi.nl/~ralf/OOHaskell/ -- how is it received in the café? :) Cheers, Alexy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
I'm going to be offensive, bigoted, and myopic for a minute here: programming straight onto the Turing machine (and not too dissimilarly, the von Neumann machine) is the act of making your thoughts comprehensible to a little gizmo that exists to zip back and forth on an infinite ticker tape. We should therefore abstract. However, I am only marginally happier about making my thoughts comprehensible to a tinkertoy set (which is how I regard object oriented programming). Why not just stay as close to mathematics as possible? Why the deep desire to communicate your loftiest intentions to a tinkertoy set? There was the Lambada project to map between Java's object hierarchies and Haskell, however, and there was a lot of effort put into making Haskell talk properly through COM. Both of those necessitate a model of object oriented programming embedded in Haskell which would provide you with prior art. On 1/27/07, Alexy Khrabrov [EMAIL PROTECTED] wrote: ...In the tradition of the letters of an ignorant newbie... What's the consensus on the OOP in Haskell *now*? There're some libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified type system with inheritance. If I have GHC, which way to do anything OOP-like is considered right today? -- Frederick Ross Graduate Fellow, (|Siggia + |McKinney)/sqrt(2) Lab The Rockefeller University Je ne suis pas Fred Cross! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
Well, I'm thinking in terms of OOD/OOA/OOP -- Design, Architecture, Programming. That's about the only way to model a bog system. Say I have a stock market model -- I'll have a database of tickers, a simulator to backtest things, a trading strategy, etc. Do Haskell modules provide enough encapsulation to design a system in terms of them? What are the design/architecture units in Haskell if not OO-based? Cheers, Alexy On 1/27/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote: deliverable: ...In the tradition of the letters of an ignorant newbie... What's the consensus on the OOP in Haskell *now*? There're some libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified type system with inheritance. If I have GHC, which way to do anything OOP-like is considered right today? Using existentials and typeclasses to do some OO things wouldn't be considered unidiomatic (particularly, using existentials to package up interfaces to values). In general though, using a functional approach will produce better (simpler) Haskell code, and make it more likely others will understand it. Personally, I run in fear from OO Haskell ;) Concrete examples of when you think you need an OO feature might be useful, so people can discuss the more FP solutions to the same problem. Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] State of OOP in Haskell
...In the tradition of the letters of an ignorant newbie... What's the consensus on the OOP in Haskell *now*? There're some libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified type system with inheritance. If I have GHC, which way to do anything OOP-like is considered right today? Cheers, Alexy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
deliverable: ...In the tradition of the letters of an ignorant newbie... What's the consensus on the OOP in Haskell *now*? There're some libraries such as OOHaskell, O'Haskell, and Haskell~98's own qualified type system with inheritance. If I have GHC, which way to do anything OOP-like is considered right today? Using existentials and typeclasses to do some OO things wouldn't be considered unidiomatic (particularly, using existentials to package up interfaces to values). In general though, using a functional approach will produce better (simpler) Haskell code, and make it more likely others will understand it. Personally, I run in fear from OO Haskell ;) Concrete examples of when you think you need an OO feature might be useful, so people can discuss the more FP solutions to the same problem. Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
deliverable: Well, I'm thinking in terms of OOD/OOA/OOP -- Design, Architecture, Programming. That's about the only way to model a bog system. Say I have a stock market model -- I'll have a database of tickers, a simulator to backtest things, a trading strategy, etc. Do Haskell modules provide enough encapsulation to design a system in terms of them? What are the design/architecture units in Haskell if not OO-based? Haskell's pretty big on encapsulation (we like our strong statically checked guarantees after all) Some of the encapsulation mechanisms used in large (5k loc up to 100k + Haskell programs I've hacked on): modules qualified modules type classes to specify generic interfaces existential types to hide implementations completely (and statically) existentials using typeclasses to package the interface monads for state/effect encapsulation abstract data types data types with smart constructors first class modules via existentials purity laziness So the same kind of encapsulation as OO stuff provides (existentials are essentially OO objects), and a few more besides. Monads in particular are perfect for encapsulating interesting effects, and having that encapsulation statically enforced. Probably some of the OO refugees can think of other mechanisms. Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State of OOP in Haskell
What about this OOHaskell: http://homepages.cwi.nl/~ralf/OOHaskell/ -- how is it received in the café? :) Cheers, Alexy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
