From mboxrd@z Thu Jan 1 00:00:00 1970 From: michael@kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 6 May 2017 13:44:55 +0000 Subject: [TUHS] Discuss of style and design of computer programs from a user stand point In-Reply-To: References: <201705060202.v4622L1J013430@coolidge.cs.Dartmouth.EDU> <5a2d6cc957c2efcd968f35aa5557c7a0e309dd27@webmail.yaccman.com> <20170506091857.GE12539@yeono.kjorling.se> Message-ID: <20170506134455.GG12539@yeono.kjorling.se> On 6 May 2017 09:09 -0400, from cym224 at gmail.com (Nemo): >> I would actually take that one step further: When you are writing >> code, you are _first and foremost_ communicating with whatever human >> will need to read or modify the code later. > > ..., there are > times when the code is transformed by optimization into something very > difficult to read. (We used noweb to document the transformation.) True, optimized code can be difficult to read. But very little code really _needs_ to be optimized to that level, and when you come across it, you will generally know -- at least after running the application through a profiler. (I have to admit we do have it easy these days.) I've been working on optimizing some SQL code recently -- I know, that's not exactly operating system kernel C or assembler -- and it's amazing at times how the code can end up being both easier to understand _as well as_ faster to execute, if you just put some thought into what the code really needs to do. And not just minor speedups either, but wallclock runtime reductions on the order of _two to four nines_. I think there's been only one time in the last several years when I have really _needed_ to optimize code to the point that its workings were not obvious. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)