Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Suffering-oriented programming

nathanmarz.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Suffering-oriented programming

#41

Post by mhartl »

knieveltech wrote: post #8
ctdonath wrote: post #7

"First make it possible. Then make it beautiful. Then make it fast." Alas, the guy writing the checks all too often doesn't see past step 1.

This. I've yet to see a client development project that made it past step 1 on anything other than the most trivial features. Sucks, but I got paid. What can you do?

I think the advice is intended for products you build for users, not products you build for clients. The right strategy depends on who your customer is. When you find a ripe market, you'll discover that your customers—i.e., the users—just want a solution, even if it isn't pretty. When your customer is the client, then you're selling to him, not to his users, which means you rationally should care less about the product. This can be painful, which is one reason why many startup founders prefer to avoid client work.

Re: Suffering-oriented programming

#42

Post by pejapeja »

So in agile terms, besides splitting down the work by user stories it can also be split down by function (make it work), design (make it beautiful) and last performance (make it fast). Quite a natural approach to prioritize that order depending on what stage the project is, early, mid or late. It requires a continuous refactoring but in the business man's point of view it's rework. But the end result will probably look more like a second generation product rather than a first gen with mediocre function, design and performance.

Re: Suffering-oriented programming

#43

Post by redfloatplane »

astine wrote: post #4
csl_ wrote: post #2

The biggest problem I have with this approach (and believe me, I love this approach), is that it makes it hard to finish things. For example, over Christmas, I built a small pretend-natural-language CLI controller for iTunes. I made a working version in something like four hours, spent a few days adding in crazy half-thought-out features like speech recognition and a web interface - and then I basically stopped devel…

"The problem, then, is that once the "suffering" is gone, or sufficiently lessened, there is no real reason to keep building." Then how is the project incomplete? If it's not a product that you're planning to sell, put your code on Github or the like and others will add any features that you're missing.

The code is on github, here: http://github.com/CarlQLange/fit

Re: Suffering-oriented programming

#44

Post by pejapeja »

jt2190 wrote: post #35

Suffering-oriented programming rejects that you can effectively anticipate needs you don't currently have. I do anticipate, however, I never do it in code. Rather, I find that just thinking through some scenarios helps me to see where the code might start evolving, and to make sure that that part of the code is isolated enough to change without having to change everything else, if the time ever comes. (Perhaps Nathan…

I agree, as some agile guru said, a plan is useless but planning is essential. An important thing along with avoiding making useless features is also to avoid building a design that is hostile against features we do need to add. Building a good design without having any anticipation of what will come is in my point of view impossible. The tricky part is to keep the anticipations and assumptions to a reasonable level.

Re: Suffering-oriented programming

#45

Post by AlexBucataru »

jt2190 wrote: post #35

Suffering-oriented programming rejects that you can effectively anticipate needs you don't currently have. I do anticipate, however, I never do it in code. Rather, I find that just thinking through some scenarios helps me to see where the code might start evolving, and to make sure that that part of the code is isolated enough to change without having to change everything else, if the time ever comes. (Perhaps Nathan…

Good point. Breaking down the code into "isolated enough" units as you write it shouldn't add much complexity or effort. It actually makes testing / debugging and refactoring easier. You cannot anticipate what will need to be added, expanded or improved, but you can be sure something will.

Re: Suffering-oriented programming

#47

Post by jemfinch »

nathanmarz wrote: post #33
ced wrote: post #30

Earlier quoted context omitted.

Isn't it problematic that 11, 01 and 10 XOR together to get 00? And why not use a simple counter?

Random 64 bit ids are used in the process. So the probability of accidentally completing a tuple is very, very small (1 / 2^64 for every ack). Counters don't work because of the asynchronous nature of Storm. For example, consider a topology that looks like this: A -> B -> C \-> D Let's say A emits 2 tuples (+2 differential), B processed those and emits 2 to C and 3 to D (+3 differential), C processes 2 tuples (-2 dif…

"So the probability of accidentally completing a tuple is very, very small (1 / 2^64 for every ack)."

Which means, due to the birthday paradox, that you should expect your first collision around 2^32 tuples. Process a few million tuples a day (that's only about 25 per second) and you should expect your first error within your first year.

EDIT: I'm wrong, see the explanations below.

Re: Suffering-oriented programming

#48

Post by techdmn »

jacques_chester wrote: post #29

"First make it possible. Then make it beautiful. Then make it fast." This mantra closely resembles the rule attributed to Kent Beck that one should "Make it work. Make it right. Make it fast".

Agree, was disappointed to see the paraphrase go unattributed.

Re: Suffering-oriented programming

#49

Post by nathanmarz »

jemfinch wrote: post #47
nathanmarz wrote: post #33

Earlier quoted context omitted.

Random 64 bit ids are used in the process. So the probability of accidentally completing a tuple is very, very small (1 / 2^64 for every ack). Counters don't work because of the asynchronous nature of Storm. For example, consider a topology that looks like this: A -> B -> C \-> D Let's say A emits 2 tuples (+2 differential), B processed those and emits 2 to C and 3 to D (+3 differential), C processes 2 tuples (-2 dif…

"So the probability of accidentally completing a tuple is very, very small (1 / 2^64 for every ack)." Which means, due to the birthday paradox, that you should expect your first collision around 2^32 tuples. Process a few million tuples a day (that's only about 25 per second) and you should expect your first error within your first year. EDIT: I'm wrong, see the explanations below.

The birthday paradox doesn't apply. All that matters it the value at the time the ack is applied, so it's always 1/2^64 (because the xor of any number of random numbers is still random).

Re: Suffering-oriented programming

#50

Post by jemfinch »

nathanmarz wrote: post #49
jemfinch wrote: post #47

Earlier quoted context omitted.

"So the probability of accidentally completing a tuple is very, very small (1 / 2^64 for every ack)." Which means, due to the birthday paradox, that you should expect your first collision around 2^32 tuples. Process a few million tuples a day (that's only about 25 per second) and you should expect your first error within your first year. EDIT: I'm wrong, see the explanations below.

The birthday paradox doesn't apply. All that matters it the value at the time the ack is applied, so it's always 1/2^64 (because the xor of any number of random numbers is still random).

No, the birthday paradox very much applies. The chance of success for your first ack is (2^64-1)/2^64. The chance of success for your first and second ack is the chance of success for your first ack times the chance of success for your second ack, ((2^64-1)/2^64)^2. And so on for your third ack, and your ack.

By the time you reach your 2^32 ack, your chance of having all successes is ((2^64-1)/(2^64))^2^32, which is EDIT: My test program seems to indicate that I'm wrong, but I can't see the flaw either in it or in my reasoning. Can you explain why the birthday paradox doesn't apply here?

EDIT': In the birthday paradox, it would be ((2^64-1)/2^64)) * ((2^64-2)/2^64) * ((2^64-3)/2^64), etc.

Post reply on HN