Hacker News Reader

Comment by chukye | Hacker News Reader

I think this was already quoted in somewhere, but, its the best advice;

"The key to making programs fast is to make them do practically nothing."

That's what separates good and bad teams (or individual developers): the wisdom of how to make a program that does the bare minimum while actually solving the problem.

"Make things as simple as possible, but not simpler."

He is saying make the program spend less time computing. Thats what he means by not looking at every byte. The way he does that is by using more complicated algorithms. It's not simple.

Quote is often credited to Einstein; being "simple" does not mean something is not complex, it means that there's no unnecessary complexity; being "too simple" means necessary complexity was remove.

Basically means only do exactly what's required, nothing more, nothing less.

Also useful: "If you want to make a fast program, use a slow computer."

Not really necessary in most cases. There's enough profiling tools available that can give response times in fractions of a second and in many cases you can add repetition to inflate the few processes that are still too small to measure. These will give you far more meaningful figures about the performance of your code than anecdotal evidence using a slow PC as a benchmark.

I agree with both of you. Once I optimized a major Python project to avoid some bad disk access patterns. Nobody noticed them because everyone was using SSDs and those patterns didn't hurt (too much) performance on those, but I was running on an HDD and I had run times of hours (vs a couple of minutes for everyone else).

But my optimizations were guided by the profiler and a (more or less) correct analysis of the results.

Developers care more about performance if it's slow on their computers too.

Haha, this is true. Yet i still need to have as fast build and feedback as possible when I'm doing work.

Which is one of a hundred reasons why the machine you write the code on, the machine you build it on, and the machine you test it on, should be three different machines (actually probably more than that because your test environment should be more varied than a single OS/environment).

If we really want to adhere to best working practices, then it should be a separate team performing the tests based on the same specifications that the developers used to write the code (ie the testing team wouldn't perform tests based on the developers specifications but rather the project owners specs to mitigate the risk of the developers misunderstanding the specs).

However that requires a level of process that is either too costly, or too rigid for many IT companies to follow.

I used to work at a place that had an intentionally slow dsl line, and a ~5 year old, beat up pc to test their code on. If it worked there, it would work for their customers.

I wish more places would try this. Sure, your app works in downtown SF, but if your customer is in Nowheresville, AL, you should probably spend more time optimizing.

I wish more web developers would test their sites on 3G connections with Australian latency :-)

The difference between 3G & 4G both in speed and latency is profound, and nobody seems to design with 3G in mind, so I find from a data standpoint 3G is practically worse than nothing these days.

All of your apps will say "I have data access!" and send a million requests for tens of megabytes, which will never finish, melting your battery as it waits on timeouts and completely choking the access you do have preventing you from doing anything useful.

Why encourage technology lag and bad ISP behavior?

Because that's the lazy answer

Because programmers are lazy.

Why making program faster when it works fine on their top of the line desktop machines?

Yes and we underestimate how often this kind of rule can apply.

To have fast network, reduces network utilisation (for example using cache). To have fast database, reduce number of queries (for example using more complex queries). To have fast memory allocation, avoid dynamic memory or preallocate...

This also works if you are aiming for stable software - I can't find the quote or who to attribute it to:

> The only bug-free line of code is the line of code that is never written.

This is why I find myself writing fewer bugs when I'm writing Python. I write less and have less to mess up.

This is actually why I find myself writing fewer bugs when I'm writing Java than Python. Thanks to static typing, I don't need to endlessly repeat myself writing and updating boilerplate unit tests and boilerplate documentation (and inevitably messing up)

I've heard about PEP484 and hope it catches on, but unfortunately it's for python3 and a lot of people are still stuck on python2 for many reasons.

cough That's kind of why I feel like Haskell is a superior language to most others.

Too true. I read an account of some product being ported to F# (from C#) a few years back. The line count was substantially decreased (at least one order of magnitude if I'm remembering correctly) with a correlated decrease in defects. I can't find the original post, but there are plenty of supporting testimonials[1].

[1]: http://fsharp.org/testimonials/

Yeah, as someone who gets to use F# fairly regularly, actually, it's a substantial improvement in the LOC department compared to Java or C#. I don't find it quite as reliable as something like Haskell (do to the fact that you don't have to be explicit about side-effects), but it's definitely better than most languages.

Somehow this reminds me of this quote from Antoine de Saint-Exupéry: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Reply on news.ycombinator.com