giving that haskell doesn't have the notion objects(even it has the keyword class) How does Haskell developer design their code? how do they represent interaction/entities? does they have alternative to uml? or class equivalent?(or do they even care?)
-
3I think the question can be flipped on its head - I am just as bewildered as to how Java programmers manage to shoehorn everything into classes :). In general, one spends much more time in Haskell thinking about functions and transitions from things of one type to things of another. That aside, this question seems a bit broad and un-answerable right now by SO standards. Maybe you could add a specific example of something you can't imagine being done in Haskell?Alec– Alec2017-01-31 20:30:25 +00:00Commented Jan 31, 2017 at 20:30
-
@Alec I am not arguing about using object or not, I am just wondering how design is expressed, I don't have anything against Functional programmingchedy najjar– chedy najjar2017-01-31 20:32:17 +00:00Commented Jan 31, 2017 at 20:32
-
1You must've misunderstood my comment - I wasn't making a point for or against functional programming, only on the difficulty of conveying how different the paradigms are. I still think the question isn't really answerable without an example...Alec– Alec2017-01-31 20:34:36 +00:00Commented Jan 31, 2017 at 20:34
-
2I'd be glad to add a "translation" of a given uml/class architecture to my answerepsilonhalbe– epsilonhalbe2017-01-31 20:41:11 +00:00Commented Jan 31, 2017 at 20:41
-
1This is an interesting question. Perhaps there's no widespread standard design process for Haskell development. It surely "helps" that most Haskellers usually talk about the connections with math and formal semantics, which is more objective than, say, code style, which are the best language idioms/patterns, and so on. Some Haskellers (including me, to be honest) feel a bit uncomfortable with UML for its informal nature. Also, architecture documents are for large dev groups -- I'm not sure how large Haskell dev groups (on the same project) are around the globe.chi– chi2017-01-31 21:28:34 +00:00Commented Jan 31, 2017 at 21:28
|
Show 3 more comments
1 Answer
I don't know of any formal(ized) notion of drawing or describing architecture.
Nevertheless you can structure your application
The most basic way is using the expressiveness of the type system:
- wrapping simple types in
newtypes - or usingtypesynonyms to - distinguish between say anIntand anAgevalue, e.g.newtype Age = Age Int. - composing more complex types as products of existing e.g.
data Person = Person { name :: String, age :: Age} - or by using sum types
data Employee = Chef Person | Waiter Person
All these data types - which can be made much more elaborate - can be accessed/modified* via record syntax or lenses. I tend to think of the data types as my skeleton of the application I write - and use the compiler to stay true to the ideas I had when starting and never subvert the types by using unsafeXX functions.
Lack of OO/Encapsulation
I have never had - having functions attached to objects is not necessary (utterly wrong in my opinion, but that is not up for discussion here).
A basic form of encapsulation can be done via newtype and modules with their exports.
Polymorphism
A lot can already be done with typeclasses, which if you have not yet worked with them, are somewhat like interfaces, (but with less typing) - but there is a lot more you can accomplish with advanced things like type families.
Conclusion
So if I would like to draw a structure/architecture of my program, I would start with my data-types as boxes and use arrows as functions between them. And maybe use "special" boxes for container types.
*: technically one usually doesn't modify stuff, but create new values from old values as (almost) everything is immutable.
answered Jan 31, 2017 at 20:30
