Reputation
9,595
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
9 42 95
Impact
~508k people reached

Jul
28
comment Is there a Haskell idiom for trying several functions and stop as soon as one succeeds?
@JimmyHoffa: Thanks a lot for your answer (+1). I will review monoids during the coming days and then take a close look at your examples.
Jul
27
comment Is there a Haskell idiom for trying several functions and stop as soon as one succeeds?
I do not understand why <|> treats the identity of a monoid in a special way. Couldn't one pick an arbitrary element of an arbitrary set to play that special role? Why does the set have to be a monoid and the special element wrt <|> its identity?
Jul
27
asked Is there a Haskell idiom for trying several functions and stop as soon as one succeeds?
Jul
25
awarded  Popular Question
Jul
19
comment Is this data model a list or tree?
"Are you considering each element of any list pointed by tree as node ?": tree points to one list only. This list is a node but not a leaf node. It contains three subnodes, the first two are internal nodes, the third is a leaf-node. And so on. The leaf-nodes of the tree are therefore the one marked by 1, 2, 3, 4, 5, 6, 7, and the empty list.
Jul
19
comment Is this data model a list or tree?
@overexchange: Yes, the node containing a 7 is a leaf. Leaf nodes are nodes that do not have any children.
Jul
17
comment Is this data model a list or tree?
The type restriction means that one expects all leaves to have the same type. But in a language like Python you can also have leaves of any type.
Jul
17
comment Is this data model a list or tree?
@overexchange: Lists are trees. [1, 2, 3] is isomorphic to 1 : 2 : 3 : [], or :(1, :(2, :(3, [])))`, which is a tree.
Jul
17
comment Is this data model a list or tree?
@overexchange: How do you define sequential? Partially ordered? Then DAGs (and trees and lists as well, since they are special cases of DAGS) are sequential.
Jul
17
comment Is this data model a list or tree?
As observed, [1, 2, 3, 4] can be seen as a tree with one root node and 4 leaves. In this case you speak of an unranked tree: each node can have an arbitrary number of children. Such an unranked tree is isomorphic to a binary tree (ranked tree in which each node has exactly two, possibly empty, child-trees) if you think about the Lisp representation: nodes are either atoms or cons-cells. Bottom line (as pointed out by others): the data in the examples can be considered as trees according to different definitions of tree.
Jul
15
awarded  Necromancer
Jul
15
comment Is it fine to have broken intermediate commits, as long as the final commit in any push works?
Why can't you commit both changes in one step? Aren't you supposed to commit meaningful chunks of work?
Jul
13
comment What categories of software modeling problems is object orientation highly unsuitable for?
@JörgWMittag: Thanks a lot!
Jul
13
comment What categories of software modeling problems is object orientation highly unsuitable for?
@JörgWMittag: interesting, I did not know about the Scala solution. Is there some online material about it?
Jul
13
comment What categories of software modeling problems is object orientation highly unsuitable for?
@Gabriels.: Yes. OOP shines in the dual situaton: a stable interface with a growing number of classes implementing it, e.g. widgets in a GUI library.
Jul
13
comment What categories of software modeling problems is object orientation highly unsuitable for?
Any problem in which you have a fixed set of types and a growing number of operations that process them: using an object-oriented approach you would have to add a method to each class each time you define a new operation.
Jul
13
awarded  Nice Answer
Jul
8
awarded  Nice Answer
Jul
7
comment When should you avoid iterative and incremental development?
@jwenting: Your story is yet another confirmation that reality is a continuum between the two ideal extremes of waterfall and perfect incremental development.
Jul
5
comment When should you avoid iterative and incremental development?
@lxrec: I agree with you that there is always a tension between upfront design, and incremental development, and that decisions depend on the context: cost of late changes on one hand, and likelihood of those changes on the other. In some domains changes of requirements are more frequent than in others.