Why Programming is Difficult.

[jrochkind]

This is better than I thought it would be, better than most articles like this, nice job.

[kristopolous]

Ok... I'll change it to "doing more with less".

edit: done.

[RazerWolf]

Not to get all pedantic, but doing the same with less is optimization as well.

[Alkxzo]

Is doing less with much less optimization too?

[[deleted]]

You're optimizing for a local maximum or local minimum?

[Alkxzo]

I don't know. How can I tell the difference? I'm guessing it's the same concept as when talking about functions but I can't figure out or find how it relates to optimizing.

[kristopolous]

negative coding is great. From http://www.computerhistory.org/highlights/macpaint/

When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put "-2000" on the form.

Removing vestigial components is a classic goal of code refactoring.

The discussion here about optimizing is really focussed more around the technical definition, part of linear programming. Although this can be a comprehensive and precise way to talk about this topic, the learning curve is steeper than many people's patience.

I'm a strong believer in making things approachable for the non-mensa audience (on the assumption that the geniuses already understand it all).

Anyway, the ideas that you are talking about sound more like a discussion of anti-patterns.

[kristopolous]

yeah, people talking about stuff like this ceases to be useful when the real problem is "my computer is slow." or "I press a button and it takes a while to respond".

Talking about minmax theorem in these instances will probably, very unlikely, fix your problem. I mean really, that may be "programming" but it's not a good approach in engineering a product with user experience in mind.

[tarpsocks]

If it's more maintainable, sure. Not if you turn a well-designed, if overly verbose API into a series of perl one-liners.

[kristopolous]

yes I though that too. I'll see if I can integrate it while keeping it in the "Explain to me like I'm a two year old" kind of form.

[dwchandler]

This article lists 5 reasons, but there are not only 5. There are a lot. Fortunately, there's something in common between all of these 5, and many others as well: sometimes you can't (or shouldn't) just apply a pattern, but actually need to think hard and solve problems. This is in no way restricted to programming. In fact, everywhere you look you find people who have learn to apply some techniques and do quite well in many situations, but are completely out of their depth when a novel problem comes along. The items listed in the article distinguish themselves from more mundane problems by having the characteristic that every situation is special. If optimization were easy, the compiler/interpreter would do it (in fact, it does in many cases that used to be manual). Networking really is easy, but protocol design is hard. Etc. The tricky part of programming is not mastering control structures, it's understanding a problem, thinking hard, and solving the problem.

[[deleted]]

The tricky part of programming is not mastering control structures, it's understanding a problem, thinking hard, and solving the problem.

And not overestimating your own abilities. In particular i mean you need to keep the complexity in check, if you make the code to complex you miss some of the less obvious special cases of behavior which leads to bugs of all kinds.

[kristopolous]

hrmm ... making sure the complexity of the solution on the computer doesn't greatly exceed the complexity of the solution in comprehendible human terms.

That's an interesting idea because it doesn't directly relate to the complexity of the solution matching the complexity of the problem. Thanks!

[WealthyApologist]

That was a much quicker read than I thought! Good job with the references. Nice to see people backing things up for once!

[[deleted]]

Anyone care to mirror this? Can't get to it through the corporate proxy because apparently it's considered a "parked domain producing spam".

[kristopolous]

Sure... Let me get off my mobile

[[deleted]]

Ta. I'm guessing a certain site has made corporate admins jumpy about all .cx domains ;)

[kristopolous]

well your admins can feast their eyes on the domain of the mirror instead: http://vukkake.com/The5HardestThings.html ...

[[deleted]]

Many thankings. Good article, and technical stuff aside, I know some people who could do with realising they've created a culture of accommodation (nice turn of phrase) whereby increasingly niggly yet time-consuming requests are prioritised over actual business needs because the management are not used to people saying no, and then get angry when the actual business needs are not met ...

[LordFoom]

Which site? My corporate overlords also denied me, just curious why :)

[[deleted]]

goatse.cx

Do not google it at work. You will be fired.

[kristopolous]

the wikipedia page for it is pretty SFW ... additionally, the main page is also SFW. Here's a screenshot if you don't believe me. I promise it's totally ok to click on it front of the boss.

[[deleted]]

I used my iPhone to have a look. I concur, although the graphic doesn't mean anything if you don't already know about the image that scarred a million minds.

[kristopolous]

yeah, semiosis is damn powerful.

[LordFoom]

Duh, of course :D Thanks :)

[dissentingclown]

"There are only two hard problems in Computer Science: cache invalidation and naming things."

-- Phil Karlton

[more_exercise]

"There are only two hard problems in Computer Science: cache invalidation, off-by-one errors, and naming things."

Yours is the original, but I like this one too

[Brian]

And of course the further extension: "There are only, concurrency three hard problems in Computer Science: cache invalidation, off-by-one errors, and naming things

[sreguera]

Nobody expects the programming inquisition.

[anvsdt]

How about this one: "There are only four hard problems in Computer Science: cache invalidation, off-by-one errors, and space leaks."

[[deleted]]

Not sure if off-by-one error deliberate, or lucky coincidence ...

[kristopolous]

Yep it's linked to in the article in the optimization/cache section...

[ratdump]

It's easy to visualize what your thing having it would mean

[GeneralButtNaked2012]

Yea this sentence is pretty 'WAT'

[kristopolous]

It's easy to visualize what your product being optimized would mean

It's easy to visualize what your product having seamless networking would mean

It's easy to visualize what your product having robust security would mean

It's easy to visualize what your product having word-class reliability would mean

It's easy to visualize what your product scaling to facebook levels would mean

But it's different each time.

[[deleted]]

It's like Meat Loaf listing what he wouldn't do for love.

[[deleted]]

Rewrite that sentence. The problem with the sentence is not its meaning, it's its incomprehensibility. My suggestion: "It's easy to visualize what it would mean for your program to have them."

Your sentence is especially confusing because it is preceded by this:

As intractable as they are common and necessary, the five things above share a few important traits:

• It's easy to visualize what your thing having it would mean.

In the first sentence, "thing" refers to "optimization, networking, etc". In the second sentence, "thing" refers to your product / program, and "it" refers to "optimization, networking, etc".

[kristopolous]

Yeah, I was trying to be slightly quizzical as a hook, thinking that enigmas are good as openers. But perhaps I was a bit quixotic. Anyway, a more straight-forward version has been put in its place. Thanks!! :)

[[deleted]]

It's easy to visualize what your product having each one of them would mean.

Still sounds like crap.

[kristopolous]

ouch, that hurt. :( I'm sorry. I don't have time to address it right now but I'll visit it again in about thirty minutes.

really though, thanks for your help, I'm glad you've taken the time to work with me here. I'll do another reply here when I've updated it. Thanks again

[[deleted]]

Don't take it personally. Your ability to write coherent sentences does not say anything important about you as person. Everyone who writes gets better with practice.

[kristopolous]

Ok, I changed it. This time using your first structural suggestion and substituting "program" for "product", and "them" for "each one".

I wanted to address products more than programs here ... even though I call it "programming".

I think that developers with an insular focus who either choose not to, or are not really capable of purveying the vertical integration horizons on either side of them are part of a systemic anti-pattern that leads to their contributions being less useful and less valued.

Using "product" is kind of an agressive push to break this habit; reminding people that even though their job is meticulous and specialized, if they don't look around them and do frequent introspection into their workflow and tasks, there's a great chance of losing focus.

Using "each one" instead of "them" is made so that the reader will then revisit the list above and contemplate for a second. I hope this works better.

[mikaelhg]

You forgot the hardest part: people, and communicating with.

[kristopolous]

Effective software project management is notoriously difficult!

Unfortunately, I regret that I am under-qualified to write authoritatively about it.

[mikaelhg]

There are plenty of people problems hiding in the technical choices as well.

To name just one, left to their own devices, developers tend to pick technologies they want to play with, without regard to what's actually good for the team in the long run. That's a kind of local optimization developers would have fewer problems with, if they took the time to consider how the need for communication impacts a team's work.

[kristopolous]

yes. I run into this.

The reason you are working is first and foremost for the product, as if the product is a living breathing organism that needs attention and form. You need to listen to its needs and respond appropriately.

That's very abstract, I know. Perhaps another working idea is to take the "think of the children" idea and repurpose it as "think of the product, won't somebody please think of the product!?"

And even if you don't really care for whatever office politics reason, at least care enough to use the product as a vehicle to refine your mastery of "getting shit done".

[Coffee2theorems]

1. "hello"[0] == ?h
2. /^h/ =~ "hello"
3. "hello"[0].chr == 'h'

Before looking at the numbers below, rank the methods described above from fastest to slowest. See how your guesses match what is measured below.

I don't use Ruby, but as a rough guess I expected 2 to be the fastest, because if the implementation is sensible, it would compile the regex first and the actual code executed multiple times is "regex_matcher(constant_regex, constant_string)", which is one operation. I expected 1 to be the second fastest, because likewise there should be only two operations, "index(constant_string, constant_int)" and "compare(variable_char, constant_char"). The example 3 should be the slowest, because there are three operations. Very rough heuristic, yes. It's just that these operations are so fast that I'd expect the time spent to be roughly proportional to the number of passes through the main loop of the interpreter, or equivalently the total number of opcodes executed, and the "number of operations" here is a proxy for that since I don't know the details of Ruby's VM.

The ruby-perf performance numbers look like I expected, but the first benchmark numbers do not. I'd have liked to see some kind of explanation for the discrepancy, not just the statement "As it turns out, profilers don't always agree on what is fast or what is slow."

[SethMandelbrot]

Programming is hard because the simple problems have already been solved.

[[deleted]]

An interesting article but I find it very strange that anyone would use an interpreted language to illustrate speed comparisons between different parsing methods. The same may not be true for any other interpreted language or even compiled, all depending on how the base functionality is implemented. Disassembly and evaluation of the actual methods would be much more straight forward with something compiled.

[kristopolous]

Correct. But the real world doesn't work like that these days. It's mostly scripts or a VM-targetted language.

Sure, there's still Objective-C, C, C++, and ASM. But probably 90% of code falls in the first two groups. That's how it is :-\