8,954 reputation
63681
bio website
location
age
visits member for 3 years, 5 months
seen 15 mins ago

0x2B | ~0x2B


9h
comment Correct name for expression tree merging
The labels in the tree correspond to the variables in the formula, therefore the most natural interpretation would be to let A, B, C, D and E be leaves.
9h
comment Correct name for expression tree merging
Also, if I had to represent your expression: A and (B and (C or D)) or (B and (C or E)) as a tree, I would have and as the root of the tree, not A.
9h
comment Correct name for expression tree merging
Hm, then you are reducing the tree based on its semantics, not only on the syntax. What is the use of this?
9h
comment Correct name for expression tree merging
I would call it collapsing but I think your example is wrong because you can only collapse equal subtrees and the trees under B differ on their right child. You can only collapse the two C leaves. Of course, by doing this you'd get a DAG which is no longer a tree.
11h
comment What advantage is there in pairing when programming that there isn't when pairing in other jobs?
Can you give examples? I can think about lots of counterexamples: Mathematicians normally work alone and only meet to discuss stuff from time to time.
11h
comment How can you achieve and maintain flow while pair programming?
@Lev: Having a code review before committing is much more efficient: the review takes from a few minutes to half and hour, instead of an entire workday.
11h
answered What's the etiquette on looking at the other person's email when pair programming?
11h
comment Should I accept a job if pair programming is required?
@Wizard: I find with pair programming you discuss too many insignificant details: there is a lot of noise that slows down your train of thoughts and makes you less efficient. Other people find it stimulating and like the unstructured but continuous feedback they get. Some people say I am an individualist, I object that you can work as a team and still be structured, in the same way as a soccer team occupy the whole playground instead of going all where the ball is. Anyway, I think it is a matter of how each programmer works and not all programmers work in the same way.
11h
comment Should I accept a job if pair programming is required?
@Wizard: Some people like pair programming, I don't. I prefer to discuss the structure of the code in advance, then do the coding, then do a code review. This puts a filter between myself and my colleagues so that we only exchange relevant information.
11h
comment Should I accept a job if pair programming is required?
@Sergio Acosta: Two heads together does not imply you do all the coding together. You can also discuss the architecture together, divide the code into submodules, define interfaces, and then do the coding on your own while respecting the interfaces. I did this many times and it can be much more efficient than sitting together for hours on the same code.
11h
comment Should I accept a job if pair programming is required?
"After a week of this we deployed it.. and everything just worked. Not a single bug. Not one.": I haven't experienced a significant difference in number of bugs between using pair-programming and not using it. Discussing the essential points with your colleagues and then coding on your own can be as effective. Pair-programming is no silver bullet.
11h
comment What's the etiquette on looking at the other person's email when pair programming?
There is no general rule: you have to discuss it with your pair.
2d
comment Does agile contradict to Open/Closed principle?
My understanding of O/C is that if you need new behaviour you add new classes or new methods to existing classes. Existing methods in existing classes should not change their behaviour. Once a class has become mature and stable enough and a lot of code depends on it, I do not see why this should be a problem.
Dec
15
comment Coerce bad input or always crash early
@Doval: I totally agree with you. I think you misunderstood what I wanted to say. I would not try to repair the data: return None (if this clearly signals a problem to the caller) or throw an exception as soon as you find an error. The only thing I want to avoid is to implement "only the happy path", assuming that the code will crash anyway when it receives invalid data, and that this is enough.
Dec
15
comment Coerce bad input or always crash early
@Doval: I would not like to go back to my back-end code in six months and change all the places that might receive invalid data to send back a proper "sorry, I can't do anything with that data" response. So, I think that programming each component as if it were external is more robust and requires less maintenance.
Dec
15
comment Coerce bad input or always crash early
@Doval: So, yes, your distinction between internal and external components is a good one, as long as you are 100% sure that a component is really internal. E.g., in my current project we are developing an HTTP back-end that responds to requests generated by our JavaScript client. So the back end is now an internal component. But in six months from now we might decide to expose the back-end and let an external tool send it requests.
Dec
15
comment Coerce bad input or always crash early
@Doval: I agree with you. My point is how you handle this data: you throw an exception as soon as you detect the invalid input? Or you ignore it and let it crash in an uncontrolled way as soon as that data is accessed? Also, in some cases it makes sense to ignore the data without crashing. Consider e.g. a mail client that downloads a badly formatted message: in this case, the client should handle the bad data and not just crash.
Dec
15
comment Coerce bad input or always crash early
"If a negative value comes in, you should be asking yourself: why? If it's from direct user input, why did your front-end allow the minus sign in the first place?": Shouldn't each component be self-contained and not depend on the specification of other components? I.e. the back-end should have a clear specification like "crash on invalid data" or "skip invalid data" or "coerce invalid data", no matter where that data comes from.
Dec
15
comment Coerce bad input or always crash early
"In the long run, programing like this makes your code unreadable, long, ugly and unmaintainable.": Why? Can you elaborate on this? Letting the code crash or handle an error is a matter of requirements (how should the software behave), not of coding style.
Dec
14
awarded  Famous Question