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

51–60 of 64 posts

Re: Suffering-oriented programming

#51

Post by snewman »

jemfinch wrote: post #50
nathanmarz wrote: post #49

Earlier quoted context omitted.

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…

The birthday paradox kicks in when you have a set of objects, and a collision between any pair is interesting. Here, only a collision with 0 is interesting.

Suppose that the sequence of values you have after each ack is A, B, C, D, E (five acks total). So long as A, B, C, and D are all nonzero, we're OK. With the birthday paradox, we'd be looking at A=B, A=C, A=D, A=E, B=C, B=D, etc. -- many more combinations.

Re: Suffering-oriented programming

#52

Post by nathanmarz »

jemfinch wrote: post #50
nathanmarz wrote: post #49

Earlier quoted context omitted.

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…

The birthday paradox concerns the chance of 2 random elements in an entire set being the same. There's no set here, so there's no birthday paradox. http://en.wikipedia.org/wiki/Birthday_problem

Hilariously, you got your equation right (which isn't the birthday paradox equation btw) but got your result wrong. http://www.wolframalpha.com/input/?i=%28%282%5E64-1%29%2F%28...

So the chance of success after 2^32 acks is >0.999999999, not It takes about 2^60 acks before there's a significant chance of a mistake. That's a lot of acks, so it will take an insanely long time for a mistake to be made.

Re: Suffering-oriented programming

#53

Post by chipsy »

reinhardt wrote: post #36

Well written, I especially loved the definition: Suffering-oriented programming can be summarized like so: don't build technology unless you feel the pain of not having it. Having said that, it would be cool to hear from a "devil's advocate". I am particularly thinking of cases where "making it possible" gives an 80% solution but a fundamental flaw or limitation makes the remaining 20% prohibitive, basically requirin…

If your spec is good, it's rare, because you're most likely to see a showstopper appear 10% or 20% of the way into making the 80% solution - and that's early enough that you can rearchitect and continue.

The cases where it becomes almost impossible tend to come from the "reuse something written to a different spec" projects where you're forcing things through the wrong architecture. The warning against over-focus on genericity at the end of the article is directed at exactly this - when you aim for generic you can often find yourself building to a spec without concrete goals, thus the actual problems are poorly dealt with.

Re: Suffering-oriented programming

#54

Post by ars »

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?

If you're good, you can trick the client a bit, deliberately don't completely finish part of 1 till you have most of 2 working.

Don't do this just for your own gratification, but only when it will genuinely help the client.

It helps when you get a sense of how long they expect the project to take - if you do it fast, but deliver a poor solution you are not doing your job.

If they want it fast, and they know it will be poor then fine. But a lot of the time they are not expecting fast, but then you deliver fast and they think "cool", not realizing you didn't really finish things properly.

Re: Suffering-oriented programming

#55

Post by follower »

Deestan wrote: post #10
astine wrote: post #4

Earlier quoted context omitted.

"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.

> put your code on Github or the like and others will add any features that you're missing. No they won't, because he hadn't even started on the "make it beautiful". When I want to solve a new-ish problem, I can't imagine grabbing some barely working cowdung from some guy's github repo. If he hasn't even tried to make it clean or readable, it'll take me more time to make sense of the mess than just rebuild it myself.

> No they won't, because he hadn't even started on the "make it beautiful".

At the risk of sparking a language war--the iTunes control project is written in Python so it has a certain level of consistency to start with.

> When I want to solve a new-ish problem, I can't imagine grabbing some barely working cowdung from some guy's github repo.

One developer's cowdung is another developer's works-for-me code. :)

For me part of the standard development process is the "literature review" which consists of finding all the prior art (polished or not) and evaluating it. I'd much rather someone uploaded their code in any state than not at all. YMMV. :)

Re: Suffering-oriented programming

#56

Post by kristianp »

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".

I found this insightful on the make it fast stage: "you might worry about things like asymptotic complexity in the "make it beautiful" phase and focus on the constant-time factors in the "make it fast" phase."

Re: Suffering-oriented programming

#58

Post by bwarp »

revorad wrote: post #13
bwarp wrote: post #9

The art of thinking about a problem appears to be lost. What happened to getting it fast, beautiful and possible first time by thinking about it? I come from an engineering background and "right" is the only way to do it.

I'd love to hear some examples where you got it fast, beautiful and possible the first time.

One example where "engineering" versus "agile" paid off:

In 04/05, I single-handedly wrote a large Windows Mobile (.Net CF) and SOA platform for managing proof of delivery across 5000 devices which used server-push messaging over semi-persistent GPRS links. This required about 6 months of work after 3 months of R&D. It was delivered on time, with zero defects, worked perfectly on low bandwidth connections and required no training for the user (less than 5% of the userbase had problems using it with no training).

It was fast, even over low bandwidth connections. Virtually real time when a link was up.

It was beautiful because it was easy to use and abstracted the messaging system and connection availability entirely.

It was possible because it worked first time with no regressions or defects in the field reported in over 6 years. It had to work first time as there was no upgrade channel for the users.

Re: Suffering-oriented programming

#59

Post by revorad »

bwarp wrote: post #58
revorad wrote: post #13

Earlier quoted context omitted.

I'd love to hear some examples where you got it fast, beautiful and possible the first time.

One example where "engineering" versus "agile" paid off: In 04/05, I single-handedly wrote a large Windows Mobile (.Net CF) and SOA platform for managing proof of delivery across 5000 devices which used server-push messaging over semi-persistent GPRS links. This required about 6 months of work after 3 months of R&D. It was delivered on time, with zero defects, worked perfectly on low bandwidth connections and require…

That's a great example. A post detailing your process for building that and comparing it to "agile" would be very interesting. Thanks!

Re: Suffering-oriented programming

#60

Post by bwarp »

revorad wrote: post #59
bwarp wrote: post #58

Earlier quoted context omitted.

One example where "engineering" versus "agile" paid off: In 04/05, I single-handedly wrote a large Windows Mobile (.Net CF) and SOA platform for managing proof of delivery across 5000 devices which used server-push messaging over semi-persistent GPRS links. This required about 6 months of work after 3 months of R&D. It was delivered on time, with zero defects, worked perfectly on low bandwidth connections and require…

That's a great example. A post detailing your process for building that and comparing it to "agile" would be very interesting. Thanks!

I will do that some time in the next few weeks! I haven't had time to set up a blog (yet) unfortunately.
Post reply on HN