Fast software is a discipline, not a purpose • Hacker News Board

Re: Fast software is a discipline, not a purpose

#41

Post by hasenj » Thu, Nov 16, 2017, 9:39 AM UTC

delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

This quote is so misunderstood and so abused all the time.

The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how.

It's not a rallying call to forgo all concerns about application performance and efficiency.

The mis-application of this quote is the root of all evil in modern software IMO.

It's why a chat program takes 500MB of RAM and why many programs take 10 seconds to load even though there's no technical reason they cannot startup instantly.

You should make it right and fast from the very start. You should not make something that "works" but is full of bugs and slow as hell. Like, that makes no sense at all. If it's full of bugs then it doesn't work. If it's slow as hell then it doesn't work.

1. Make it work correctly and efficiently (to a reasonable degree)

2. Make it even faster

3. Make it better

Re: Fast software is a discipline, not a purpose

#42

Post by cjsuk » Thu, Nov 16, 2017, 9:40 AM UTC

delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

1. Make it work

2. Make it ... err actually fuck it, let's build a hairball on top of it.

That's how it really rolls.

You have to think it fast, think it right, then make it work because if you do it the other way round, it never happens.

Re: Fast software is a discipline, not a purpose

#43

Post by majikandy » Thu, Nov 16, 2017, 9:41 AM UTC

dullgiulio wrote: post #39

majikandy wrote: post #32

Earlier quoted context omitted.

Do you have any evidence to back that statement up?

I think the proof should be on those who say that readable code cannot be performant.

I've never heard anyone say that.

Re: Fast software is a discipline, not a purpose

#44

Post by jlg23 » Thu, Nov 16, 2017, 9:42 AM UTC

lmm wrote: post #35

jlg23 wrote: post #29

Earlier quoted context omitted.

The advice you quoted is the most valuable of all, in my opinion. You give "map/filter/reduce" as an example and claim that theses approaches "typically result in passing over the data multiple times". No, since reduce can behave like map and filter , with a proper reduction function you only have to pass over the data once. > Most collections/array I process have trivial number of elements ( That is true for all oth…

> No, since reduce can behave like map and filter, with a proper reduction function you only have to pass over the data once. You can indeed - which is why reduce is relatively opaque and unmaintainable, and should be a last resort. Any given map/filter pipeline could be rewritten to reduce, and it quite possibly would perform better - but at the cost of not being able to test individual pipeline stages, nor inspect…

I disagree. I does not have to be unmaintainable. The difference between chaining map/filter and a single reduce is mostly a syntax transformation plus a little bit of thinking upfront:

   ;; N.B.: Code was written here in a comment and never tested. 
   ;; It might need some of those: ')))))'
   (flet ((filter-element (element bucket)
            ;; all (filter...)s of your chain here
           )
          (mutate-element (element bucket)
            ;; apply all your (map...)s here
           ))
     (defun distill-magic (essence element)
        (if (not (filter-element element essence))
            essence
            (cons (mutate-element element essence) 
                   essence))))

The hard part is sometimes to reformulate the chain in a way that you only filter on either pre- or post-mutation data. If you can't, your most probably using the wrong algorithm. But fixing that, if it requires serious thinking, is something I defer to the moment it actually matters. I now can, because it is neatly encapsulated in a single, local function definition.

And yes, of course I can inspect intermediate results in a debugger: Just trace distill-magic or set a break point.

Re: Fast software is a discipline, not a purpose

#45

Post by ssijak » Thu, Nov 16, 2017, 9:45 AM UTC

"When people train, they usually don’t try to actually run faster or lift heavier weights. As a relatively healthy computer science professor, how fast I run or how much I can lift is of no practical relevance. "

This is really strange. If you don`t try to lift heavier weights you will not have progress. It is called progressive loading. I don`t wan`t to go into the details of the training, but if you do not track and improve your training (with whatever goal you have in mind, there are different kinds of progressions) you are the same as the programmer who write bad code, and knows it is bad, but does not care.

Re: Fast software is a discipline, not a purpose

#46

Post by ssijak » Thu, Nov 16, 2017, 9:47 AM UTC

jackjeff wrote: post #2

“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…

Ever heard of streams/iterators? Where data from the collection pass as a stream through all transformations only once. Code is readable and functional, and it only passes once through your collection.

Re: Fast software is a discipline, not a purpose

#47

Post by zimpenfish » Thu, Nov 16, 2017, 9:54 AM UTC

ssijak wrote: post #45

"When people train, they usually don’t try to actually run faster or lift heavier weights. As a relatively healthy computer science professor, how fast I run or how much I can lift is of no practical relevance. " This is really strange. If you don`t try to lift heavier weights you will not have progress. It is called progressive loading. I don`t wan`t to go into the details of the training, but if you do not track an…

> If you don`t try to lift heavier weights you will not have progress.

That depends on what you're aiming for - if you're aiming for tone rather than bulk, you'd go for more reps of the same weight rather than stepping up the weight with the same reps, wouldn't you?

(Although I guess, technically, that does count as "heavier" since you're still moving more weight in your sets.)

Re: Fast software is a discipline, not a purpose

#48

Post by zimpenfish » Thu, Nov 16, 2017, 9:58 AM UTC

hasenj wrote: post #41

delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

This quote is so misunderstood and so abused all the time. The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how. It's not a rallying call to forgo all concerns about application performance and efficiency. The mis-application of this quote is the root of all evil in modern software IMO. It's why a chat program…

> 1. Make it work correctly and efficiently (to a reasonable degree)

Unfortunately, this took your team 6 months and the people that launched their app 4 months ago (having opted for "make it work") now have 90% of your market and you've all just been made redundant because the customers do not care whether your app is "more correct" and "more efficient" because they just plain damn couldn't use it.

There's a reason "worse is better" applies to software.

Re: Fast software is a discipline, not a purpose

#49

Post by zimpenfish » Thu, Nov 16, 2017, 9:59 AM UTC

Cthulhu_ wrote: post #40

delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

The challenge there is that a lot of developers are pushed by their managers to go to the next feature after #1, postponing 2 and 3 for when there's time. Time to market is considered the most important thing. Of course, it accumulates after a year.

> pushed by their managers to go to the next feature

Understandable, though, since features are what get customers to pay - 99% of customers will not care about efficient code as long as they can achieve what they're after without screaming.

Re: Fast software is a discipline, not a purpose

#50

Post by s_m_t » Thu, Nov 16, 2017, 10:01 AM UTC

ssijak wrote: post #45

"When people train, they usually don’t try to actually run faster or lift heavier weights. As a relatively healthy computer science professor, how fast I run or how much I can lift is of no practical relevance. " This is really strange. If you don`t try to lift heavier weights you will not have progress. It is called progressive loading. I don`t wan`t to go into the details of the training, but if you do not track an…

I interpreted that as "When people train, their goal in of itself is not usually to run faster or lift heavier weights". (the following might diverge from the actual content of the article, the author's english doesn't seem to be that great and I don't think we'll gain anything by taking the article literally)The goal might be overall health, attractiveness, etc. However, that doesn't mean they won't take the training seriously if they think it will help their larger goal. If you saw someone at the gym dilly dallying and doing a seriously half-assed rotation you might think they don't really care about their end goal.

In the same vein if you saw a programmer coding something extremely slow just because they couldn't be bothered to put in the tiny bit of extra effort to get to a baseline of performance you might think they don't take their job or future skillset very seriously. Always thinking about the performance of your implementation is a form of training just like lifting weights is. Even if you don't care about making this particular section of code fast, or you don't care whether this particular dumbbell is lifted up and down 10 times in a row, you do those things in service of a greater goal.