<\/div>Just about every job has some sort of support tasks associated with it. You need to clean the kitchen and wash dishes in order to cook foodI guess you could hire someone else to do it, but it still needs to be done.<\/span>, but doing dishes is not cooking. Dishwashing might be part of your job as a cook, but it’s not the point<\/i> of the job. You don’t cook food because you want to wash dishes, you wash dishes because you want to cook food.<\/p>\n Cleaning your brushes is not painting. Stringing and tuning your guitar is not playing music. Checking spelling and formatting text is not writing a novel. Updating WordPress and sorting out CSS problems is not writing a blog. Putting gas in your car is not delivering pizzas. Those ancillary tasks need to be done and a few people might even enjoy doing them, but they don’t pay the bills. They just enable you to do the thing that does<\/b> pay the bills. If you can reduce how much of your time is spent on these ancillary tasks, it will be a net win.\u00a0<\/p>\n I’ll admit that sometimes the line can get really blurry. An artist working on commission might have the following workflow: I’m sure lots of people will have different ideas about which parts of this workflow fall within “creating art” and which parts are ancillary tasks. I’m willing to bet that lots of artists will wish they could do more of stuff somewhere in the 4-8 range and less of the other stuff, even if they don’t all agree on where they’d like to draw the line between “drawing” and “not drawing”.<\/p>\n We’re 5 entries and about 10,000 words into this series, so I guess it’s finally time to get to the main topic…<\/p>\n Programming is no different. There are a lot of parts of this job that need to be done, even if they don’t strictly qualify as “programming”. Here are a handful of vexations that aren’t really programming:<\/p>\n I think Blow’s idea to increase the overall joy of programming involves reducing how much time programmers spend on these sorts of tasks. Some of these things are unavoidable, but we should always be on the lookout for opportunities to mitigate them. For the rest of this series, I’m going to run through this list of time-sucking, morale-draining tasks and talk about what they involve, why they’re annoying, and how a new language might help.<\/p>\n This first vexation is a little bit lame and trivial. That’s fine. We’ll get to the big stuff later in the series. The first vexation is…<\/p>\n As problems go, this one is pretty trivial. The task of formatting code isn’t nearly as annoying as the arguments<\/b> over how we should be formatting code.\u00a0<\/p>\n Most languages ignore whitespace. Whitespace is any non-printing character: Spaces, tabs, line breaks, etc. To a compiler this sentence…<\/p>\n This sentence is false.<\/p>\n …is functionally equivalent to this sentence:<\/p>\n This\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 sentence\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/p>\n is \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 false.<\/p>\n Code is very complex. Your code needs to convey a lot of concrete and precise information to the compiler. At the same time, the code must also convey a lot of abstract information to other humans. A person reading the code wants to know what<\/b> it’s supposed to do, while the compiler wants to know exactly how<\/b> to do it. Having the compiler ignore whitespace enables you to format the code in a way that will (hopefully) make it clearer to the human without confusing the compiler.\u00a0<\/p>\n In movies, they always show programmers frantically typing<\/a>Often into some sort of stark terminal window with scrolling text in a terrible font with colors likely to cause eyestrain, because that looks more interesting for the audience.<\/span>\u00a0 lots and lots of code. In the real world, those moments of intense productivity are few and far between. Projects might start out in a rush of typing, but as soon as the program matures beyond trivial complexity you’ll find more and more of your time is being spent on reading<\/b> code rather than writing code.\u00a0<\/p>\n Code can easily become so complex that it will act like a flytrap for other programmers. Anyone unfortunate enough to wind up in your region of the codebase will need to stop and spend a couple of minutes reading your giant messy block of code before they realize it isn’t the thing they’re looking for. If there are a lot of flytraps in the code, then those five-minute chunks of time can add up quickly, dragging down everyone’s productivity. To help mitigate this, teams devise rules and conventions about how code should be formatted. For an example of this, check out my analysis of the formatting rules used by id Software<\/a>.<\/p>\n I know I keep bringing this up, but often code formatting arguments happen between programmers working in different disciplines. Different kinds of programming result in very different looking code, and it’s completely reasonable to adopt a coding style that suits the kind of code you’re trying to write. The problem is that once you get used to a particular style, other coding styles will look wrong<\/b>. So then some ninny decides that there is ONE, AND ONLY ONE correct way to format code, and they venture out into the internet to try and convert the heretics.\u00a0<\/p>\n Let’s say you’re processing keyboard input for a shooter. You might have a block of code that looks something like this:<\/p>\n Pretty standard stuff. This is a very easy bit of code to read, and it packs a lot of easy-to-follow logic into a relatively small space. But then you wind up with some code orthodoxy like:<\/p>\n And suddenly that code looks like this:<\/p>\n Some people will like this better because it follows the rules set by the rest of the code and their eye twitches when they encounter code that breaks the rules. But note how this takes up more than twice as many lines to accomplish the exact same trivial task. The information density is much lower and it’s harder to find what you’re looking for.<\/p>\n This article would be a chore to read if it was one giant paragraph.<\/p>\n It would also be annoying to read if everything was on its own line.<\/p>\n This would waste a lot of space.<\/p>\n It would make it hard to tell the end of one thought <\/p>\n from the beginning of another.<\/p>\n It would also force you to do a lot of scrolling.<\/p>\n At the other extreme, that sparse bracket style would be really handy in code with complicated nested conditional logic. If the flowchart of the code branches outward like a March Madness<\/a> tournament bracket<\/a> and all those branches contain complex algorithms, then you’ll want to adopt a spacious bracket style to put some gaps between the big blocks of math.\u00a0<\/p>\n Another argument is over the placement of opening brackets. This code:<\/p>\n Is functionally identical to this:<\/p>\n Should the opening bracket go on its own line like this? You can make a reasonable case for either one. If this is a trivial bit of code like the one above, then you might want to put the bracket at the end of the if() to save vertical space and keep the information density high. On the other hand, if you've got 25 lines of code inside the brackets then maybe it would be wise to give the opening bracket its own line so that it's easy to make sure the indenting lines up properly.\u00a0\u00a0<\/p>\n This argument over bracket style is just one of many. How do we name functions and variables? Do we create indentations using spaces or tabs? Should comments go in a big block at the top of a function or be scattered around the code? <\/p>\n Like I said earlier, code formatting rules are there to facilitate communication with other programmersIncluding your future self.<\/span>. It's easy to lose sight of this and take a orthodoxical approach where nothing is allowed to deviate from the mandated style. But mindlessly formatting code according to THE RULES is like going around pronouncing English words phonetically rather than using the accepted pronunciation. It might give you a warm feeling to keep everything neat and tidy, but you're pursuing order at the expense of clarity. My formatting rules tend to favor the types of code I usually write, but if I've got a random block of one-off code I'm more than happy to break the rules. The is especially true in the case of large blocks of short repetitive lines. (Like the keyboard handling code above.)\u00a0<\/p>\n It all depends on what you're trying to do. Too much whitespace is annoying because the information density is really low. Too little whitespace makes it harder to follow the logic and visualize the flow. If you switch between styles based on code density, then the code can feel like anarchy.\u00a0<\/p>\n Again, the code format rules should probably be specific to the kinds of programming problems that your team \/ company is dealing with. The worst thing is to be dogmatic and obsessive about it rather than tailoring the style to fit the domain.<\/p>\n In any case, code formatting is a really minor item in the list of things that vex programmers. It's also the one thing that I don't think a new language can help with. You could certainly make things worse<\/strong>, but I can't think of any way to make things better. No matter what language you use, you're still going to have to deal with the trade-off between clarity and information density. I often have a lot of gripes about how code is formattedI HATE when an ultra-spacious style is used on already simple stuff, to the point where a screen full of text will contain less than a dozen lines of actual code that does something. Hates it forever.<\/span>, but all of those gripes are personal, cultural, or domain-based. Say what you want about C++, but it doesn't presume to dictate how your code should be formatted.<\/p>\n Next week we're going to talk about something that matters a lot more.<\/p>\n","protected":false},"excerpt":{"rendered":" One of Jon Blow’s original goals for Jai was to embrace (or perhaps restore) the “joy of programming”. I thought that while we’re waiting for Jai to come out, we could look at this idea and see what it might suggest about future languages. “Joy of programming” is a pretty nebulous concept, but I interpret […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[],"class_list":["post-48185","post","type-post","status-publish","format-standard","hentry","category-programming"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/48185","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=48185"}],"version-history":[{"count":14,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/48185\/revisions"}],"predecessor-version":[{"id":48204,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/48185\/revisions\/48204"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=48185"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=48185"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=48185"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n<\/p>\n\n
The Vexations of Modern Programming<\/h3>\n
<\/div>\n
Vexation #1: Formatting Code is Not Programming<\/h3>\n
<\/div>\r\n\r\nif (key == KEYBOARD_W)\r\n\r\n\u00a0\u00a0player.MoveForward ();\r\n\r\nif (key == KEYBOARD_S)\r\n\r\n\u00a0\u00a0player.Backpedal ();\r\n\r\nif (key == KEYBOARD_A)\r\n\r\n\u00a0\u00a0player.MoveLeft ();\r\n\r\nif (key == KEYBOARD_D)\r\n\r\n\u00a0\u00a0player.MoveRight ();\r\n\r\nif (key == KEYBOARD_SPACE)\r\n\r\n\u00a0\u00a0player.Jump ();\r\n\r\nif (key == KEYBOARD_LCTRL)\r\n\r\n\u00a0\u00a0player.ToggleCrouch ();\r\n\r\nif (key == KEYBOARD_LSHIFT)\r\n\r\n\u00a0\u00a0player.ToggleSprint ();\r\n\r\nif (key == KEYBOARD_R)\r\n\r\n\u00a0\u00a0player.Reload ();\r\n\r\nif (key == KEYBOARD_Q)\r\n\r\n\u00a0\u00a0player.Melee ();\r\n\r\nif (key == KEYBOARD_G)\r\n\r\n\u00a0\u00a0player.ThrowGrenade ();\r\n\r\nif (key == KEYBOARD_E)\r\n\r\n\u00a0\u00a0player.Activate ();\r\n\r\nif (key == KEYBOARD_F)\r\n\r\n\u00a0\u00a0player.SpecialAbility ();\r\n<\/pre>\n
\n
\r\nif (key == KEYBOARD_W)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.MoveForward ();\r\n\r\n}\r\n\r\n\r\n\r\nif (key == KEYBOARD_S)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.Backpedal ();\r\n\r\n}\r\n\r\n\r\n\r\nif (key == KEYBOARD_A)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.MoveLeft ();\r\n\r\n}\r\n\r\n\r\n\r\nif (key == KEYBOARD_D)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.MoveRight ();\r\n\r\n}\r\n\r\n\r\n\r\nif (key == KEYBOARD_SPACE)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.Jump ();\r\n\r\n}\r\n\r\n\r\nif (key == KEYBOARD_LCTRL)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.ToggleCrouch ();\r\n\r\n}\r\n\r\n\r\nif (key == KEYBOARD_LSHIFT)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.ToggleSprint ();\r\n\r\n}\r\n\r\n\r\nif (key == KEYBOARD_R)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.Reload ();\r\n\r\n}\r\n\r\n\r\nif (key == KEYBOARD_Q)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.Melee ();\r\n\r\n}\r\n\r\n\r\nif (key == KEYBOARD_G)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.ThrowGrenade ();\r\n\r\n}\r\n\r\n\r\nif (key == KEYBOARD_E)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.Activate ();\r\n\r\n}\r\n\r\n\r\nif (key == KEYBOARD_F)\r\n\r\n{\r\n\r\n\u00a0\u00a0player.SpecialAbility ();\r\n\r\n}\r\n\r\n<\/pre>\nif (player.hitpoints < 1)\u00a0 {\r\n\r\n\u00a0\u00a0player.Die ();\r\n\r\n\u00a0\u00a0game.End ();\r\n\r\n}<\/pre>\nif (player.hitpoints < 1)\u00a0\u00a0\r\n\r\n{\r\n\r\n\u00a0\u00a0player.Die ();\r\n\r\n\u00a0\u00a0game.End ();\r\n\r\n}\u00a0<\/pre>\n