premature optimization

Building Web Applications With Flask
by Italo Maia
Published 25 Jun 2015

The message here is: do not make your product more robust or complex than you know it needs to be and do not waste time planning for what may, most likely, never happen. Tip Always plan for reasonable levels of safety, complexity, and performance. Premature optimization Is your software fast enough? Don't know? Then why are you optimizing that code, my friend? When you spend time optimizing software that you're not sure needs optimization, if no one complained about it being slow or you do not notice it to be slow in daily use, you're probably wasting time with premature optimization. And so, on to Flask. Blueprints 101 So far, our applications have all been flat: beautiful, single-file Web applications (templates and static resources not considered).

…

Beyond GET Flask-Restless Summary 7. If Ain't Tested, It Ain't Game, Bro! What kinds of test are there? Unit testing Behavior testing Flask-testing LiveServer Extra assertions JSON handle Fixtures Extra – integration testing Summary 8. Tips and Tricks or Flask Wizardry 101 Overengineering Premature optimization Blueprints 101 Oh God, please tell me you have the logs… Debugging, DebugToolbar, and happiness Flask-DebugToolbar Sessions or storing user data between requests Exercise Summary 9. Extensions, How I Love Thee How to configure extensions Flask-Principal and Flask-Login (aka Batman and Robin) Admin like a boss Custom pages Summary 10.

…

You may purchase a nice Integrated Development Environment (IDE) such as PyCharm or WingIDE to improve your productivity or hire third-party services to help you test your code or control your development schedule, but these can do just so much. Good architecture and task automation will be your best friend in most projects. Before discussing suggestions on how to organize you code and which modules will help you save some typing here and there, let's discuss premature optimization and overengineering, two terrible symptoms of an anxious developer/analyst/nosy manager. Overengineering Making software is like making a condo, in a few ways. You'll plan ahead what you want to create before starting so that waste is kept to a minimum. Contrary to a condo, where it's advisable to plan the whole project before you start, you do not have to plan out your software because it will most likely change during development, and a lot of the planning may just go to waste.

The Art of UNIX Programming
by Eric S. Raymond
Published 22 Sep 2003

The really valuable effect is that not optimizing that 90% holds down global complexity and reduces bugs. You may recall that we quoted Donald Knuth observing “Premature optimization is the root of all evil” in Chapter 1, and that Rob Pike and Ken Thompson had a few pungent observations on the topic as well. These were the voices of experience. Do good design. Think about what's right first. Tune for efficiency later. Profilers help you do this. If you get in the good habit of using them, you can get rid of the bad habit of premature optimization. Profilers don't just change the way you work; they change how you think. Profilers for compiled languages rely on instrumenting object code, so they are even more platform-dependent than compilers.

…

The most basic argument for prototyping first is Kernighan & Plauger's; “90% of the functionality delivered now is better than 100% of it delivered never”. Prototyping first may help keep you from investing far too much time for marginal gains. For slightly different reasons, Donald Knuth (author of The Art Of Computer Programming, one of the field's few true classics) popularized the observation that “Premature optimization is the root of all evil”.[11] And he was right. Rushing to optimize before the bottlenecks are known may be the only error to have ruined more designs than feature creep. From tortured code to incomprehensible data layouts, the results of obsessing about speed or memory or disk usage at the expense of transparency and simplicity are everywhere.

…

They spawn innumerable bugs and cost millions of man-hours — often, just to get marginal gains in the use of some resource much less expensive than debugging time. Disturbingly often, premature local optimization actually hinders global optimization (and hence reduces overall performance). A prematurely optimized portion of a design frequently interferes with changes that would have much higher payoffs across the whole design, so you end up with both inferior performance and excessively complex code. In the Unix world there is a long-established and very explicit tradition (exemplified by Rob Pike's comments above and Ken Thompson's maxim about brute force) that says: Prototype, then polish.

Forge Your Future with Open Source
by VM (Vicky) Brasseur

Keep It Simple, Silly We in the software world love to get mired down in the details. We’ll spend hours thinking and arguing about the minutiae, whether we need to or not. Add to that a tendency toward perfectionism and you have a recipe for what’s called premature optimization, or trying to optimize a program or process before you’ve had the chance to see whether that optimization is even needed. When premature optimization occurs while trying to prepare a project to release as FOSS, there’s a very good chance that the release will be delayed indefinitely as everything is over-considered, over-architected, but undoubtedly under-documented.

…

If you’ve never released a FOSS project before, you naturally want to do everything possible to make sure it goes smoothly. You want every single bug to be fixed. You want all of the code to be pristine. While that’s admirable, it does open the door to that premature optimization. Instead of focusing only on the code, work to keep the entire process and all policies you establish for the project very simple and as clear as possible. Use the time you would have spent on premature optimization to make sure that the project and its policies are well documented. The combination of a simpler, easier to follow process and clear documentation about it not only encourages people to use and contribute to your project, but it also saves you time from having to answer relatively simple questions.

…

For instance, for a web-based Javascript application, the user’s browser, browser version, and operating system may be the only relevant components, whereas for compiled software, chip architecture and operating system may be the most relevant components of the platform. premature optimization Spending a lot of time and effort to “improve” something before you know whether or what type of improvements are needed. Premature optimizations can devour a lot of valuable time and are considered a worst practice in software development. Principle of Least Astonishment A convention in software and system design which says that if a design has the chance to surprise people with an unexpected interface or result, then that design should be thrown out in favor of one that will not surprise anyone.

The Alignment Problem: Machine Learning and Human Values
by Brian Christian
Published 5 Oct 2020

When Hoare himself was asked about the quote in 2004, he said he had “no recollection” of where it came from, suggesting perhaps it was the kind of thing that Edsger Dijkstra might have said, and adding, “I think it would be fair for you assume it is common culture or folklore” (Hans Gerwitz, “Premature Optimization Is the Root of All Evil,” https://hans.gerwitz.com/2004/08/12/premature-optimization-is-the-root-of-all-evil.html). Knuth, in 2012, conceded, “I did say things like ‘Premature optimization is the root of all evil in programming’” (Mark Harrison, “A note from Donald Knuth about TAOCP,” http://codehaus.blogspot.com/2012/03/note-from-donald-knuth-about-taocp.html). In all likelihood, the phrase was indeed his own. 3.

…

Everything is vague to a degree you do not realize till you have tried to make it precise, and everything precise is so remote from everything that we normally think, that you cannot for a moment suppose that is what we really mean when we say what we think. When you pass from the vague to the precise . . . you always run a certain risk of error. —BERTRAND RUSSELL1 Premature optimization is the root of all evil. —DONALD KNUTH2 It’s Christmas Eve, and my wife and I are staying at my father and stepmother’s house, when I wake up in the middle of the night, drenched in sweat. I figure I must have worn way too much clothing to bed; I throw off the covers, peel off my shirt.

Super Thinking: The Big Book of Mental Models
by Gabriel Weinberg and Lauren McCann
Published 17 Jun 2019

Here, de-risking is as easy as doing a few minutes of online research, reading reviews, and sending an email to your relatives. Unfortunately, people often make the mistake of doing way too much work before testing assumptions in the real world. In computer science this trap is called premature optimization, where you tweak or perfect code or algorithms (optimize) too early (prematurely). If your assumptions turn out to be wrong, you’re going to have to throw out all that work, rendering it ultimately a waste of time. It’s as if you booked an entire vacation assuming your family could join you, only to finally ask them and they say they can’t come.

…

Realize that your intuitive interpretations of the world can often be wrong due to availability bias, fundamental attribution error, optimistic probability bias, and other related mental models that explain common errors in thinking. Use Ockham’s razor and Hanlon’s razor to begin investigating the simplest objective explanations. Then test your theories by de-risking your assumptions, avoiding premature optimization. Attempt to think gray in an effort to consistently avoid confirmation bias. Actively seek out other perspectives by including the Devil’s advocate position and bypassing the filter bubble. Consider the adage “You are what you eat.” You need to take in a variety of foods to be a healthy person.

…

Department of, 97 just world hypothesis, 22 Kahneman, Daniel, 9, 30, 90 karoshi, 82 Kauffman Foundation, 122 keeping up with the Joneses, 210–11 key person insurance, 305 King, Martin Luther, Jr., 129, 225 KISS (Keep It Simple, Stupid), 10 knowledge, institutional, 257 knowns: known, 197 unknown, 198, 203 known unknowns, 197–98 Knox, Robert E., 91 Kodak, 302–3, 308–10, 312 Koenigswald, Gustav Heinrich Ralph von, 50 Kohl’s, 15 Kopelman, Josh, 301 Korea, 229, 231, 235, 238 Kristof, Nicholas, 254 Krokodil, 49 Kruger, Justin, 269 Kuhn, Thomas, 24 Kutcher, Ashton, 121 labor market, 283–84 laggards, 116–17 landlords, 178, 179, 182, 188 Laplace, Pierre-Simon, 132 large numbers, law of, 143–44 Latané, Bibb, 259 late majority, 116–17 lateral thinking, 201 law of diminishing returns, 81–83 law of diminishing utility, 81–82 law of inertia, 102–3, 105–8, 110, 112, 113, 119, 120, 129, 290, 296 law of large numbers, 143–44 law of small numbers, 143, 144 Lawson, Jerry, 289 lawsuits, 231 leadership, 248, 255, 260, 265, 271, 275, 276, 278–80 learned helplessness, 22–23 learning, 262, 269, 295 from past events, 271–72 learning curve, 269 Le Chatelier, Henri-Louis, 193 Le Chatelier’s principle, 193–94 left to their own devices, 275 Leibniz, Gottfried, 291 lemons into lemonade, 121 Lernaean Hydra, 51 Levav, Jonathan, 63 lever, 78 leverage, 78–80, 83, 115 high-leverage activities, 79–81, 83, 107, 113 leveraged buyout, 79 leveraging up, 78–79 Levitt, Steven, 44–45 Levitt, Theodore, 296 Lewis, Michael, 289 Lichtenstein, Sarah, 17 lightning, 145 liking, 216–17, 220 Lincoln, Abraham, 97 Lindy effect, 105, 106, 112 line in the sand, 238 LinkedIn, 7 littering, 41, 42 Lloyd, William, 37 loans, 180, 182–83 lobbyists, 216, 306 local optimum, 195–96 lock-in, 305 lock in your gains, 90 long-term negative scenarios, 60 loose versus tight, in organizational culture, 274 Lorenz, Edward, 121 loss, 91 loss aversion, 90–91 loss leader strategy, 236–37 lost at sea, 68 lottery, 85–86, 126, 145 low-context communication, 273–74 low-hanging fruit, 81 loyalists versus mercenaries, 276–77 luck, 128 making your own, 122 luck surface area, 122, 124, 128 Luft, Joseph, 196 LuLaRoe, 217 lung cancer, 133–34, 173 Lyautey, Hubert, 276 Lyft, ix, 288 Madoff, Bernie, 232 magnetic resonance imaging (MRI), 291 magnets, 194 maker’s schedule versus manager’s schedule, 277–78 Making of Economic Society, The (Heilbroner), 49 mammograms, 160–61 management debt, 56 manager’s schedule versus maker’s schedule, 277–78 managing to the person, 255 Manhattan Project, 195 Man in the High Castle, The (Dick), 201 manipulative insincerity, 264 man-month, 279 Mansfield, Peter, 291 manufacturer’s suggested retail price (MSRP), 15 margin of error, 154 markets, 42–43, 46–47, 106 failure in, 47–49 labor, 283–84 market norms versus social norms, 222–24 market power, 283–85, 312 product/market fit, 292–96, 302 secondary, 281–82 winner-take-most, 308 marriage: divorce, 231, 305 same-sex, 117, 118 Maslow, Abraham, 177, 270–71 Maslow’s hammer, xi, 177, 255, 297, 317 Maslow’s hierarchy of needs, 270–71 mathematics, ix–x, 3, 4, 132, 178 Singapore math, 23–24 matrices, 2 × 2, 125–26 consensus-contrarian, 285–86, 290 consequence-conviction, 265–66 Eisenhower Decision Matrix, 72–74, 89, 124, 125 of knowns and unknowns, 197–98 payoff, 212–15, 238 radical candor, 263–64 scatter plot on top of, 126 McCain, John, 241 mean, 146, 149, 151 regression to, 146, 286 standard deviation from, 149, 150–51, 154 variance from, 149 measles, 39, 40 measurable target, 49–50 median, 147 Medicare, 54–55 meetings, 113 weekly one-on-one, 262–63 Megginson, Leon, 101 mental models, vii–xii, 2, 3, 31, 35, 65, 131, 289, 315–17 mentorship, 23, 260, 262, 264, 265 mercenaries versus loyalists, 276–77 Merck, 283 merry-go-round, 108 meta-analysis, 172–73 Metcalfe, Robert, 118 Metcalfe’s law, 118 #MeToo movement, 113 metrics, 137 proxy, 139 Michaels, 15 Microsoft, 241 mid-mortems, 92 Miklaszewski, Jim, 196 Milgram, Stanley, 219, 220 military, 141, 229, 279, 294, 300 milkshakes, 297 Miller, Reggie, 246 Mills, Alan, 58 Mindset: The New Psychology of Success (Dweck), 266 mindset, fixed, 266–67, 272 mindset, growth, 266–67 minimum viable product (MVP), 7–8, 81, 294 mirroring, 217 mission, 276 mission statement, 68 MIT, 53, 85 moats, 302–5, 307–8, 310, 312 mode, 147 Moltke, Helmuth von, 7 momentum, 107–10, 119, 129 Monday morning quarterbacking, 271 Moneyball (Lewis), 289 monopolies, 283, 285 Monte Carlo fallacy, 144 Monte Carlo simulation, 195 Moore, Geoffrey, 311 moral hazard, 43–45, 47 most respectful interpretation (MRI), 19–20 moths, 99–101 Mountain Dew, 35 moving target, 136 multiple discovery, 291–92 multiplication, ix, xi multitasking, 70–72, 74, 76, 110 Munger, Charlie, viii, x–xi, 30, 286, 318 Murphy, Edward, 65 Murphy’s law, 64–65, 132 Musk, Elon, 5, 302 mutually assured destruction (MAD), 231 MVP (minimum viable product), 7–8, 81, 294 Mylan, 283 mythical man-month, 279 name-calling, 226 NASA, 4, 32, 33 Nash, John, 213 Nash equilibrium, 213–14, 226, 235 National Football League (NFL), 225–26 National Institutes of Health, 36 National Security Agency, 52 natural selection, 99–100, 102, 291, 295 nature versus nurture, 249–50 negative compounding, 85 negative externalities, 41–43, 47 negative returns, 82–83, 93 negotiations, 127–28 net benefit, 181–82, 184 Netflix, 69, 95, 203 net present value (NPV), 86, 181 network effects, 117–20, 308 neuroticism, 250 New Orleans, La., 41 Newport, Cal, 72 news headlines, 12–13, 221 newspapers, 106 Newsweek, 290 Newton, Isaac, 102, 291 New York Times, 27, 220, 254 Nielsen Holdings, 217 ninety-ninety rule, 89 Nintendo, 296 Nobel Prize, 32, 42, 220, 291, 306 nocebo effect, 137 nodes, 118, 119 No Fly List, 53–54 noise and signal, 311 nonresponse bias, 140, 142, 143 normal distribution (bell curve), 150–52, 153, 163–66, 191 North Korea, 229, 231, 238 north star, 68–70, 275 nothing in excess, 60 not ready for prime time, 242 “now what” questions, 291 NPR, 239 nuclear chain reaction, viii, 114, 120 nuclear industry, 305–6 nuclear option, 238 Nuclear Regulatory Commission (NRC), 305–6 nuclear weapons, 114, 118, 195, 209, 230–31, 233, 238 nudging, 13–14 null hypothesis, 163, 164 numbers, 130, 146 large, law of, 143–44 small, law of, 143, 144 see also data; statistics nurses, 284 Oakland Athletics, 289 Obama, Barack, 64, 241 objective versus subjective, in organizational culture, 274 obnoxious aggression, 264 observe, orient, decide, act (OODA), 294–95 observer effect, 52, 54 observer-expectancy bias, 136, 139 Ockham’s razor, 8–10 Odum, William E., 38 oil, 105–6 Olympics, 209, 246–48, 285 O’Neal, Shaquille, 246 one-hundred-year floods, 192 Onion, 211–12 On the Origin of Species by Means of Natural Selection (Darwin), 100 OODA loop, 294–95 openness to experience, 250 Operation Ceasefire, 232 opinion, diversity of, 205, 206 opioids, 36 opportunity cost, 76–77, 80, 83, 179, 182, 188, 305 of capital, 77, 179, 182 optimistic probability bias, 33 optimization, premature, 7 optimums, local and global, 195–96 optionality, preserving, 58–59 Oracle, 231, 291, 299 order, 124 balance between chaos and, 128 organizations: culture in, 107–8, 113, 273–80, 293 size and growth of, 278–79 teams in, see teams ostrich with its head in the sand, 55 out-group bias, 127 outliers, 148 Outliers (Gladwell), 261 overfitting, 10–11 overwork, 82 Paine, Thomas, 221–22 pain relievers, 36, 137 Pampered Chef, 217 Pangea, 24–25 paradigm shift, 24, 289 paradox of choice, 62–63 parallel processing, 96 paranoia, 308, 309, 311 Pareto, Vilfredo, 80 Pareto principle, 80–81 Pariser, Eli, 17 Parkinson, Cyril, 74–75, 89 Parkinson’s law, 89 Parkinson’s Law (Parkinson), 74–75 Parkinson’s law of triviality, 74, 89 passwords, 94, 97 past, 201, 271–72, 309–10 Pasteur, Louis, 26 path dependence, 57–59, 194 path of least resistance, 88 Patton, Bruce, 19 Pauling, Linus, 220 payoff matrix, 212–15, 238 PayPal, 72, 291, 296 peak, 105, 106, 112 peak oil, 105 Penny, Jonathon, 52 pent-up energy, 112 perfect, 89–90 as enemy of the good, 61, 89–90 personality traits, 249–50 person-month, 279 perspective, 11 persuasion, see influence models perverse incentives, 50–51, 54 Peter, Laurence, 256 Peter principle, 256, 257 Peterson, Tom, 108–9 Petrified Forest National Park, 217–18 Pew Research, 53 p-hacking, 169, 172 phishing, 97 phones, 116–17, 290 photography, 302–3, 308–10 physics, x, 114, 194, 293 quantum, 200–201 pick your battles, 238 Pinker, Steven, 144 Pirahã, x Pitbull, 36 pivoting, 295–96, 298–301, 308, 311, 312 placebo, 137 placebo effect, 137 Planck, Max, 24 Playskool, 111 Podesta, John, 97 point of no return, 244 Polaris, 67–68 polarity, 125–26 police, in organizations and projects, 253–54 politics, 70, 104 ads and statements in, 225–26 elections, 206, 218, 233, 241, 271, 293, 299 failure and, 47 influence in, 216 predictions in, 206 polls and surveys, 142–43, 152–54, 160 approval ratings, 152–54, 158 employee engagement, 140, 142 postmortems, 32, 92 Potemkin village, 228–29 potential energy, 112 power, 162 power drills, 296 power law distribution, 80–81 power vacuum, 259–60 practice, deliberate, 260–62, 264, 266 precautionary principle, 59–60 Predictably Irrational (Ariely), 14, 222–23 predictions and forecasts, 132, 173 market for, 205–7 superforecasters and, 206–7 PredictIt, 206 premature optimization, 7 premises, see principles pre-mortems, 92 present bias, 85, 87, 93, 113 preserving optionality, 58–59 pressure point, 112 prices, 188, 231, 299 arbitrage and, 282–83 bait and switch and, 228, 229 inflation in, 179–80, 182–83 loss leader strategy and, 236–37 manufacturer’s suggested retail, 15 monopolies and, 283 principal, 44–45 principal-agent problem, 44–45 principles (premises), 207 first, 4–7, 31, 207 prior, 159 prioritizing, 68 prisoners, 63, 232 prisoner’s dilemma, 212–14, 226, 234–35, 244 privacy, 55 probability, 132, 173, 194 bias, optimistic, 33 conditional, 156 probability distributions, 150, 151 bell curve (normal), 150–52, 153, 163–66, 191 Bernoulli, 152 central limit theorem and, 152–53, 163 fat-tailed, 191 power law, 80–81 sample, 152–53 pro-con lists, 175–78, 185, 189 procrastination, 83–85, 87, 89 product development, 294 product/market fit, 292–96, 302 promotions, 256, 275 proximate cause, 31, 117 proxy endpoint, 137 proxy metric, 139 psychology, 168 Psychology of Science, The (Maslow), 177 Ptolemy, Claudius, 8 publication bias, 170, 173 public goods, 39 punching above your weight, 242 p-values, 164, 165, 167–69, 172 Pygmalion effect, 267–68 Pyrrhus, King, 239 Qualcomm, 231 quantum physics, 200–201 quarantine, 234 questions: now what, 291 what if, 122, 201 why, 32, 33 why now, 291 quick and dirty, 234 quid pro quo, 215 Rabois, Keith, 72, 265 Rachleff, Andy, 285–86, 292–93 radical candor, 263–64 Radical Candor (Scott), 263 radiology, 291 randomized controlled experiment, 136 randomness, 201 rats, 51 Rawls, John, 21 Regan, Ronald, 183 real estate agents, 44–45 recessions, 121–22 reciprocity, 215–16, 220, 222, 229, 289 recommendations, 217 red line, 238 referrals, 217 reframe the problem, 96–97 refugee asylum cases, 144 regression to the mean, 146, 286 regret, 87 regulations, 183–84, 231–32 regulatory capture, 305–7 reinventing the wheel, 92 relationships, 53, 55, 63, 91, 111, 124, 159, 271, 296, 298 being locked into, 305 dating, 8–10, 95 replication crisis, 168–72 Republican Party, 104 reputation, 215 research: meta-analysis of, 172–73 publication bias and, 170, 173 systematic reviews of, 172, 173 see also experiments resonance, 293–94 response bias, 142, 143 responsibility, diffusion of, 259 restaurants, 297 menus at, 14, 62 RetailMeNot, 281 retaliation, 238 returns: diminishing, 81–83 negative, 82–83, 93 reversible decisions, 61–62 revolving door, 306 rewards, 275 Riccio, Jim, 306 rise to the occasion, 268 risk, 43, 46, 90, 288 cost-benefit analysis and, 180 de-risking, 6–7, 10, 294 moral hazard and, 43–45, 47 Road Ahead, The (Gates), 69 Roberts, Jason, 122 Roberts, John, 27 Rogers, Everett, 116 Rogers, William, 31 Rogers Commission Report, 31–33 roles, 256–58, 260, 271, 293 roly-poly toy, 111–12 root cause, 31–33, 234 roulette, 144 Rubicon River, 244 ruinous empathy, 264 Rumsfeld, Donald, 196–97, 247 Rumsfeld’s Rule, 247 Russia, 218, 241 Germany and, 70, 238–39 see also Soviet Union Sacred Heart University (SHU), 217, 218 sacrifice play, 239 Sagan, Carl, 220 sales, 81, 216–17 Salesforce, 299 same-sex marriage, 117, 118 Sample, Steven, 28 sample distribution, 152–53 sample size, 143, 160, 162, 163, 165–68, 172 Sánchez, Ricardo, 234 sanctions and fines, 232 Sanders, Bernie, 70, 182, 293 Sayre, Wallace, 74 Sayre’s law, 74 scarcity, 219, 220 scatter plot, 126 scenario analysis (scenario planning), 198–99, 201–3, 207 schools, see education and schools Schrödinger, Erwin, 200 Schrödinger’s cat, 200 Schultz, Howard, 296 Schwartz, Barry, 62–63 science, 133, 220 cargo cult, 315–16 Scientific Autobiography and other Papers (Planck), 24 scientific evidence, 139 scientific experiments, see experiments scientific method, 101–2, 294 scorched-earth tactics, 243 Scott, Kim, 263 S curves, 117, 120 secondary markets, 281–82 second law of thermodynamics, 124 secrets, 288–90, 292 Securities and Exchange Commission, U.S., 228 security, false sense of, 44 security services, 229 selection, adverse, 46–47 selection bias, 139–40, 143, 170 self-control, 87 self-fulfilling prophecies, 267 self-serving bias, 21, 272 Seligman, Martin, 22 Semmelweis, Ignaz, 25–26 Semmelweis reflex, 26 Seneca, Marcus, 60 sensitivity analysis, 181–82, 185, 188 dynamic, 195 Sequoia Capital, 291 Sessions, Roger, 8 sexual predators, 113 Shakespeare, William, 105 Sheets Energy Strips, 36 Shermer, Michael, 133 Shirky, Clay, 104 Shirky principle, 104, 112 Short History of Nearly Everything, A (Bryson), 50 short-termism, 55–56, 58, 60, 68, 85 side effects, 137 signal and noise, 311 significance, 167 statistical, 164–67, 170 Silicon Valley, 288, 289 simulations, 193–95 simultaneous invention, 291–92 Singapore math, 23–24 Sir David Attenborough, RSS, 35 Skeptics Society, 133 sleep meditation app, 162–68 slippery slope argument, 235 slow (high-concentration) thinking, 30, 33, 70–71 small numbers, law of, 143, 144 smartphones, 117, 290, 309, 310 smoking, 41, 42, 133–34, 139, 173 Snap, 299 Snowden, Edward, 52, 53 social engineering, 97 social equality, 117 social media, 81, 94, 113, 217–19, 241 Facebook, 18, 36, 94, 119, 219, 233, 247, 305, 308 Instagram, 220, 247, 291, 310 YouTube, 220, 291 social networks, 117 Dunbar’s number and, 278 social norms versus market norms, 222–24 social proof, 217–20, 229 societal change, 100–101 software, 56, 57 simulations, 192–94 solitaire, 195 solution space, 97 Somalia, 243 sophomore slump, 145–46 South Korea, 229, 231, 238 Soviet Union: Germany and, 70, 238–39 Gosplan in, 49 in Cold War, 209, 235 space exploration, 209 spacing effect, 262 Spain, 243–44 spam, 37, 161, 192–93, 234 specialists, 252–53 species, 120 spending, 38, 74–75 federal, 75–76 spillover effects, 41, 43 sports, 82–83 baseball, 83, 145–46, 289 football, 226, 243 Olympics, 209, 246–48, 285 Spotify, 299 spreadsheets, 179, 180, 182, 299 Srinivasan, Balaji, 301 standard deviation, 149, 150–51, 154 standard error, 154 standards, 93 Stanford Law School, x Starbucks, 296 startup business idea, 6–7 statistics, 130–32, 146, 173, 289, 297 base rate in, 157, 159, 160 base rate fallacy in, 157, 158, 170 Bayesian, 157–60 confidence intervals in, 154–56, 159 confidence level in, 154, 155, 161 frequentist, 158–60 p-hacking in, 169, 172 p-values in, 164, 165, 167–69, 172 standard deviation in, 149, 150–51, 154 standard error in, 154 statistical significance, 164–67, 170 summary, 146, 147 see also data; experiments; probability distributions Staubach, Roger, 243 Sternberg, Robert, 290 stock and flow diagrams, 192 Stone, Douglas, 19 stop the bleeding, 234 strategy, 107–8 exit, 242–43 loss leader, 236–37 pivoting and, 295–96, 298–301, 308, 311, 312 tactics versus, 256–57 strategy tax, 103–4, 112 Stiglitz, Joseph, 306 straw man, 225–26 Streisand, Barbra, 51 Streisand effect, 51, 52 Stroll, Cliff, 290 Structure of Scientific Revolutions, The (Kuhn), 24 subjective versus objective, in organizational culture, 274 suicide, 218 summary statistics, 146, 147 sunk-cost fallacy, 91 superforecasters, 206–7 Superforecasting (Tetlock), 206–7 super models, viii–xii super thinking, viii–ix, 3, 316, 318 surface area, 122 luck, 122, 124, 128 surgery, 136–37 Surowiecki, James, 203–5 surrogate endpoint, 137 surveys, see polls and surveys survivorship bias, 140–43, 170, 272 sustainable competitive advantage, 283, 285 switching costs, 305 systematic review, 172, 173 systems thinking, 192, 195, 198 tactics, 256–57 Tajfel, Henri, 127 take a step back, 298 Taleb, Nassim Nicholas, 2, 105 talk past each other, 225 Target, 236, 252 target, measurable, 49–50 taxes, 39, 40, 56, 104, 193–94 T cells, 194 teams, 246–48, 275 roles in, 256–58, 260 size of, 278 10x, 248, 249, 255, 260, 273, 280, 294 Tech, 83 technical debt, 56, 57 technologies, 289–90, 295 adoption curves of, 115 adoption life cycles of, 116–17, 129, 289, 290, 311–12 disruptive, 308, 310–11 telephone, 118–19 temperature: body, 146–50 thermostats and, 194 tennis, 2 10,000-Hour Rule, 261 10x individuals, 247–48 10x teams, 248, 249, 255, 260, 273, 280, 294 terrorism, 52, 234 Tesla, Inc., 300–301 testing culture, 50 Tetlock, Philip E., 206–7 Texas sharpshooter fallacy, 136 textbooks, 262 Thaler, Richard, 87 Theranos, 228 thermodynamics, 124 thermostats, 194 Thiel, Peter, 72, 288, 289 thinking: black-and-white, 126–28, 168, 272 convergent, 203 counterfactual, 201, 272, 309–10 critical, 201 divergent, 203 fast (low-concentration), 30, 70–71 gray, 28 inverse, 1–2, 291 lateral, 201 outside the box, 201 slow (high-concentration), 30, 33, 70–71 super, viii–ix, 3, 316, 318 systems, 192, 195, 198 writing and, 316 Thinking, Fast and Slow (Kahneman), 30 third story, 19, 92 thought experiment, 199–201 throwing good money after bad, 91 throwing more money at the problem, 94 tight versus loose, in organizational culture, 274 timeboxing, 75 time: management of, 38 as money, 77 work and, 89 tipping point, 115, 117, 119, 120 tit-for-tat, 214–15 Tōgō Heihachirō, 241 tolerance, 117 tools, 95 too much of a good thing, 60 top idea in your mind, 71, 72 toxic culture, 275 Toys “R” Us, 281 trade-offs, 77–78 traditions, 275 tragedy of the commons, 37–40, 43, 47, 49 transparency, 307 tribalism, 28 Trojan horse, 228 Truman Show, The, 229 Trump, Donald, 15, 206, 293 Trump: The Art of the Deal (Trump and Schwartz), 15 trust, 20, 124, 215, 217 trying too hard, 82 Tsushima, Battle of, 241 Tupperware, 217 TurboTax, 104 Turner, John, 127 turn lemons into lemonade, 121 Tversky, Amos, 9, 90 Twain, Mark, 106 Twitter, 233, 234, 296 two-front wars, 70 type I error, 161 type II error, 161 tyranny of small decisions, 38, 55 Tyson, Mike, 7 Uber, 231, 275, 288, 290 Ulam, Stanislaw, 195 ultimatum game, 224, 244 uncertainty, 2, 132, 173, 180, 182, 185 unforced error, 2, 10, 33 unicorn candidate, 257–58 unintended consequences, 35–36, 53–55, 57, 64–65, 192, 232 Union of Concerned Scientists (UCS), 306 unique value proposition, 211 University of Chicago, 144 unknown knowns, 198, 203 unknowns: known, 197–98 unknown, 196–98, 203 urgency, false, 74 used car market, 46–47 U.S.

Code Complete (Developer Best Practices)
by Steve McConnell
Published 8 Jun 2004

Testing merely tells you the specific ways in which your software is defective. Testing won't make your program more usable, faster, smaller, more readable, or more extensible. Premature optimization is another kind of process error. In an effective process, you make coarse adjustments at the beginning and fine adjustments at the end. If you were a sculptor, you'd rough out the general shape before you started polishing individual features. Premature optimization wastes time because you spend time polishing sections of code that don't need to be polished. You might polish sections that are small enough and fast enough as they are, you might polish code that you later throw away, and you might fail to throw away bad code because you've already spent time polishing it.

…

When you tune code, you're implicitly signing up to reprofile each optimization every time you change your compiler brand, compiler version, library version, and so on. If you don't reprofile, an optimization that improves performance under one version of a compiler or library might well degrade performance when you change the build environment. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. — Donald Knuth You should optimize as you go—false! One theory is that if you strive to write the fastest and smallest possible code as you write each routine, your program will be fast and small. This approach creates a forest-for-the-trees situation in which programmers ignore significant global optimizations because they're too busy with micro-optimizations.

…

Concerns such as correctness, information hiding, and readability become secondary goals, even though performance is easier to improve later than these other concerns are. Post hoc performance work typically affects less than five percent of a program's code. Would you rather go back and do performance work on five percent of the code or readability work on 100 percent? In short, premature optimization's primary drawback is its lack of perspective. Its victims include final code speed, performance attributes that are more important than code speed, program quality, and ultimately the software's users. If the development time saved by implementing the simplest program is devoted to optimizing the running program, the result will always be a program that runs faster than one developed with indiscriminate optimization efforts (Stevens 1981).

Write Great Code, Volume 2
by Randall Hyde
Published 6 Aug 2012

Although the quote is often attributed to Donald Knuth, who popularized it, it was Tony Hoare who originally said, “Premature optimization is the root of all evil.” This statement has long been the rallying cry of software engineers who avoid any thought of application performance until the very end of the software-development cycle—at which point the optimization phase is typically ignored for economic or time-to-market reasons. However, Hoare did not say, “Concern about application performance during the early stages of an application’s development is the root of all evil.” He specifically said premature optimization, which, back then, meant counting cycles and instructions in assembly language code—not the type of coding you want to do during initial program design, when the code base is rather fluid.

…

The following excerpt from a short essay by Charles Cook (www.cookcomputing.com/blog/archives/000084.html) describes the problem with reading too much into this statement: I’ve always thought this quote has all too often led software designers into serious mistakes because it has been applied to a different problem domain to what was intended. The full version of the quote is “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” and I agree with this. It’s usually not worth spending a lot of time micro-optimizing code before it’s obvious where the performance bottlenecks are. But, conversely, when designing software at a system level, performance issues should always be considered from the beginning.

…

The remainder of the book, Chapter 7 through Chapter 15, describes how compilers generate machine code for different HLL statements and data types. Armed with this knowledge, you will be able to choose the most appropriate data types, constants, variables, and control structures to produce efficient applications. While you read, keep Dr. Hoare’s quote in mind: “Premature optimization is the root of all evil.” It is certainly possible to misapply the information in this book and produce code that is difficult to read and maintain. This would be especially disastrous during the early stages of your project’s design and implementation, when the code is fluid and subject to change.

Code Simplicity
by Max Kanat-Alexander
Published 23 Mar 2012

Sometimes a user will report that there’s a bug, when actually it’s the program behaving exactly as you intended it to. In this case, it’s a matter of majority rules. If a significant number of users think that the behavior is a bug, it’s a bug. If only a tiny minority (like one or two) think it’s a bug, it’s not a bug. The most famous error in this area is what we call “premature optimization.” That is, some developers seem to like to make things go fast, but they spend time optimizing their code before they know that it’s slow! This is like a charity sending food to rich people and saying, “We just wanted to help people!” Illogical, isn’t it? They’re solving a problem that doesn’t exist.

Getting Real
by Jason Fried , David Heinemeier Hansson , Matthew Linderman and 37 Signals
Published 1 Jan 2006

In the flocking birds example, as with a well-designed system, it's the interactions and relationships that create the interesting behavior. The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it's locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence. Keep it small. Keep it simple. Let it happen. —Andrew Hunt, The Pragmatic Programmers Table of contents | Essay list for this chapter | Next essay The Three Musketeers Use a team of three for version 1.0 For the first version of your app, start with only three people.

System Error: Where Big Tech Went Wrong and How We Can Reboot
by Rob Reich , Mehran Sahami and Jeremy M. Weinstein
Published 6 Sep 2021

In our experience, the job interview questions for software engineers typically involve scalable solutions to abstract coding problems. This encourages young candidates to focus on scale and algorithmic efficiency. It does not encourage them to think critically about the company or its societal impacts when looking for a job. The pioneering computer scientist Donald Knuth famously said that “premature optimization is the root of all evil.” We could interpret this quote any number of ways, and indeed it has been widely misunderstood. Knuth uses optimization and efficiency synonymously: to optimize code is to make it more efficient. Knuth himself was not anti-efficiency; rather, he was arguing that there is a time and a place for efficiency.

…

For Knuth, the time and place to be efficient is when you have figured out what is worth making efficient by analyzing the effects of efficiency at a higher level. But suppose that a technologist focuses on those bits of code that will make the code faster and writes the program in a way that doesn’t sacrifice code readability. Overall, the program becomes more efficient. Has the technologist avoided premature optimization? Not necessarily. Suppose the program is used for an undesirable end: suppose it is used successfully by a malicious hacker or to guide an economy into a state of massive inequality. Perhaps then we could interpret Knuth’s quote even more broadly than he intended: even if technologists know how to make a program run efficiently, if they have not considered its possible uses and impacts, optimization may yet be premature.

Relevant Search: With Examples Using Elasticsearch and Solr
by Doug Turnbull and John Berryman
Published 30 Apr 2016

Well, by indexing TMDB directly, you violated some advice we gave earlier. You directly placed the source data model into Elasticsearch. Shouldn’t you have done some signal modeling? If you use this data directly to create a search index, won’t you end up with relevance problems? Well, yes, but that’s for a good reason. Search is a place ripe for premature optimization. You’re likely to reach the heat death of the universe before achieving a perfect search solution in every direction. You know there will be relevance problems, but you don’t quite know what those are until you experiment with user searches. There are few areas that emphasize “fail fast” as much as search relevance.

…

combining high-value tiers scored with simple Solr multiplying variables MUST clause, 2nd MUST_NOT clause, 2nd my_doublemetaphone filter N n-gram token filter n-gramming analyzer name field named attributes negative boosting nested documents no_match_size parameter nongreedy clauses nonwinning fields normalize acronyms NOT operator number_of_fragments numerical attributes numerical boosts numerical data num_of_fragments parameter O OLAP (online analytical processing) optimizing signals OR operator order parameter ordering documents origin variable original_id field, 2nd overview field, 2nd P PageRank algorithm, 2nd, 3rd pair tuning, 2nd paired relevance tuning parent-child documents parentheses parsons analyzer Parsons code path_hierarchy analyzer path_hierarchy tokenizer paths, modeling specificity with pattern_capture filter payloads, 2nd people.name field, 2nd persona personalizing search based on user behavior collaborative filtering tying behavior information back to search index based on user profiles gathering profile information tying profile information back to search index concept search and phone_number field phone_num_parts filter phonetic analyzer phonetic plugin phonetic tokenization, 2nd, 3rd phrase query, 2nd, 3rd phrase-matching clause phrases, concept search and pogo-sticking popularity field position entry positional and phrase matching postings highlighter, 2nd postings list, 2nd post_tags parameter precision analysis for by example combining field-centric and term-centric search multiple search terms and multiple fields phonetic tokenization scoring strength of feature in single field premature optimization pre_tags parameter price field prioritizing documents product codes product owner profile-based personalization profiles promoted field prose text pseudo-content Python example search application Q quadrants query behavior, explaining Query DSL, 2nd, 3rd query function query matching, debugging analysis to solve matching issues comparing query to inverted index fixing by changing analyzers query parsing underlying strategy query normalization query parameter query parsers, 2nd, 3rd query validation endpoint, 2nd query-time analysis, 2nd, 3rd query-time boosting query-time personalization queryNorm queryWeight, 2nd quotes R ranking adding high-value tiers adding new tier for medium-confidence boosts tiered relevance layers debugging computing weight explain feature scoring matches to measure relevance search term importance similarity vector-space model learning to rank term-centric real-estate search recall analysis for by example combining field-centric and term-centric search improving multiple search terms and multiple fields phonetic tokenization scoring strength of feature in single field recency achieving users’ recency goals overview reducing boost weight reindex function, 2nd, 3rd, 4th reindexing with English analyzer related_items field relevance engineers duties of gaining skills of overview relevance.

ANSI Common LISP
by Paul Graham
Published 12 Nov 1995

If not, you are reduced to guessing where the bottlenecks are, and you might be surprised how often such guesses turn out to be wrong. A corollary of the bottleneck rule is that one should not put too much effort into optimization early in a program's life. Knuth puts the point even more strongly: "Premature optimization is the root of all evil (or at least most of it) in programming."0 It's hard to see where the real bottlenecks will be when you've just started writing a program, so there's more chance you'll be wasting your time. Optimizations also tend to make a program harder to change, so trying to write a program and optimize it at the same time can be like trying to paint a picture with paint that dries too fast.

…

162 n i n t e r s e c t i o n function 357, 222 n i n t h function 357,40 no-applicable-method generic function 334 no-next-method generic function 334 Norvig, Peter 410,412 not function 321, 13 not any function 321 not every function 321 not i n l i n e declaration 315, 313 nreconc function 359 nreverse function 369, 222 n s e t - d i f f erence function 359, 222 n s e t - e x c l u s i v e - o r function 359 n s t r i n g - c a p i t a l i z e function 365 nstring-downcase function 365 n s t r i n g - u p c a s e function 365 n s u b l i s function 359 nsubst function 360, 222 n s u b s t - i f function 360, 222 n s u b s t - i f - n o t function 360 n s u b s t i t u t e function 369 nsubst i t u t e - i f function 369 n s u b s t i t u t e - i f - n o t function 370 n t h function 358,39 n t h - v a l u e macro 321 n t h c d r function 358,39 ntimes 167 n u l l function 358, 13 numbers comparison of 146 complex 143 conversion to reals 144 extracting components of 146 floating-point 143 contagion 143 limits of 150,407 overflow 150 printing 124 types of 150 integer 11 no limit on size of 150 parsing 68 see also: bignums, fixnums random 146 ratio 143 conversion to integers 144 extracting components of 146 types of 143 converting between 144 numberp function 351, 20 numerator function 351, 146 nunion function 360, 222 object-oriented programming 176 analogy to hardware 176 benefits of 178 broad application of term 285 implementing 269 for reusable software 104 as a way to get run-time typing 410 and spaghetti code 408 transcended by Lisp 2, 285 two models of 192 see also: classes, CLOS, encapsulation, inheritance, instances, messagepassing, methods, multimethods, slots oddp function 352, 44, 147 oil paint 5,402 open function 376, 120 open-stream-p generic function 377 operator 8 optimization destructive operations 222 efficient algorithms 214 fast operators 228 426 focus of 213 premature 214, 229 tail recursion—see recursion, tail see also: consing, avoiding optimize declaration 315, 313 feoptional—see parameters, optional or macro 321, 14 OS/360 4 otherwise symbol 316 output 18, 123 output-stream-p generic function 377 overflow—see numbers, floating-point packages based on names 239 default 136,236 defining 137 exporting from 137, 238 grossness of 411 importing into 238 nicknames of 137 purpose of 136,237 setting 137 used 137,239 •package* variable 394, 236 package-error-package generic function 345 package-name function 345, 236 package-nicknames function 345 package-shadowing-symbols function 345 p a c k a g e - u s e - l i s t function 346 p a c k a g e - u s e d - b y - l i s t function 346 packagep function 345 painting 5, 214, 402 p a i r l i s function 358 palindromes 46, 63 parentheses 8, 17 parameters 14 compilation—see compilation parameters congruent 186 efficiency of 228 keyword 103 optional 102 required 102 rest 102 specialized—see specialization p a r s e - i n t e g e r function 352, 68 parse-namestring function 372 pathname function 372 pathnames 120 pathname-device function 373 INDEX pathname-directory function 373 pathname-host function 372 pathname-mat ch-p function 373 pathname-name function 373 pathname-type function 373 pathname-vers ion function 373 pathnamep function 373 patterns for destructuring 85, 103 matching 249 peek-char function 377, 123 phase function 352 Perdue, Crispin 401 PGM 152 p i constant 394, 149 Pitman, Kent M. 401 planning 5,229 plists—see property lists plusp function 352, 147 poetry 407 pointers avoiding 219 conses as pairs of 32 implicit 34 see also: lists pop macro 359, 47 p o s i t i o n function 367, 64 p o s i t i o n - i f function 367, 65 p o s i t i o n - i f - n o t function 368 p p r i n t function 384, 168 p p r i n t - d i s p a t c h function 384 pprint-exit-if-list-exhausted macro 384 p p r i n t - f i l l function 384 p p r i n t - i n d e n t function 384 p p r i n t - l i n e a r function 384 p p r i n t - l o g i c a l - b l o c k macro 384 p p r i n t - n e w l i n e function 385 p p r i n t - p o p macro 385 p p r i n t - t a b function 385 p p r i n t - t a b u l a r function 385 precedence 182 implementing 274 purpose of 183 prefix notation 8 premature optimization 214 primary methods 187 p r i n l function 386, 123 p r i n l - t o - s t r i n g function 386 p r i n c function 385,123 p r i n c - t o - s t r i n g function 385 p r i n t function 385, 160 • p r i n t - a r r a y * variable 394, 59, 280 • p r i n t - b a s e * variable 394, 113 INDEX • p r i n t - c a s e * variable 394 • p r i n t - c i r c l e * variable 394, 208 • p r i n t - e s c a p e * variable 394 •print-gensym* variable 395 • p r i n t - l e n g t h * variable 395 • p r i n t - l e v e l * variable 395 • p r i n t - l i n e s * variable 395 • p r i n t - m i s e r - w i d t h * variable 395 p r i n t - n o t - r e a d a b l e - o b j ect generic function 385 p r i n t - o b j e c t generic function 385 *print-pprint-dispatch* variable 395 • p r i n t - p r e t t y * variable 395 • p r i n t - r a d i x * variable 395 • p r i n t - r e a d a b l y * variable 395 * p r i n t - r i g h t - m a r g i n * variable 395 p r i n t - u n r e a d a b l e - o b j e c t macro 386, 70 p r o b e - f i l e function 374 proclaim function 315, 215 profilers 214 prog macro 321 prog* macro 321 progl macro 321, 127, 274 prog2 macro 321 progn special operator 321, 24 progv special operator 321 prompt 7, 19 property lists 134 provide function 388 psetf macro 322 psetq macro 322 push macro 359,47 pushnew macro 359, 49 qualifiers 188 •query-io* variable 395 queues using lists as—see lists, as queues using vectors as 126 Quicksort 164 quote special operator 315, 10, 161 random function 352, 146 random-choice 170 •random-state* variable 395 random-state-p function 352 random text 138 rapid prototyping 3, 23, 401 rassoc function 359 r a s s o c - i f function 359 r a s s o c - i f - n o t function 359 427 ratios—see numbers, ratio r a t i o n a l function 352 r a t i o n a l i z e function 352 r a t ionalp function 352 ray-tracing 151 r c u r r y 110 read function 387, 18, 122 • r e a d - b a s e * variable 395 r e a d - b y t e function 377, 234 r e a d - c h a r function 377, 123 r e ad-char-no-hang function 377 •read-default-float-format* variable 396 r e a d - d e l i m i t e d - l i s t function 387, 236 *read-eval* variable 396, 406 r e a d - f r o m - s t r i n g function 387, 123 r e a d - l i n e function 377, 121 read-macros defining 235 dispatching 131, 235 predefined 399, 130 read-preserving-whitespace function 387 read-sequence function 377 *read-suppress* variable 396 • r e a d t a b l e * variable 396 r e a d t a b l e - c a s e function 387 r e a d t a b l e p function 387 r e a l p function 352 r e a l p a r t function 352, 146 Rees, Jonathan A. 405, 411 recursion 16 efficiency of 116 and functional programming 114 can't be inlined 217 local 101 proper metaphor for 16 tail 116,215,289,409 using 114 verifying 42 reduce function 368, 66 extends two-argument functions 66 : key argument to 406 more efficient than apply 228 r e i n i t i a l i z e - i n s t a n c e generic function 334 rem function 352, 145 remf macro 359 remhash function 371 remove function 368, 22, 55, 66 remove-duplicates function 368, 66 remove-if function 368, 66 remove-if-not function 368 428 remove-method generic function 335 remprop function 343 rename-f i l e function 374 rename-package function 346 rendering 151 r e p l a c e function 369 Replicator 414 r e q u i r e function 388 ftrest—see parameters, rest r e s t function 359 r e s t a r t - b i n d macro 340 r e s t a r t - c a s e macro 341 r e s t a r t - n a m e function 341 r e t u r n macro 322, 82 return-from special operator 322, 81 reusable software 3, 104 revappend function 359 r e v e r s e function 369, 46 rewriting 262,402 rhyming dictionaries 224 ring buffers 126 risk 5, 6 room function 390 r o t a t e f macro 322, 165 round function 352, 145 rounding to even digit 145 unpredictable, by format 125 row-major-aref function 363 row-major order 221 r p l a c a function 359 r p l a c d function 359 rules 247 run-length encoding 36 run-time typing 2,6,218,410 Russell, Stuart 412 s a f e t y compilation parameter 214 s b i t function 363 s c a l e - f l o a t function 352 schar function 364 Scheme 109,405,411 scope 112,405 search function 369 search binary 60 breadth-first 51 second function 357, 40 Sedgewick, Robert 402, 406 self-modifying programs 210 sequences 45, 63 access to elements of 63 copying segments of 46 INDEX finding the lengths of 45 finding elements of 64 removing duplicates from 66 replacing elements of 41 reversing 46 sorting 46, 164 see also: arrays, lists, vectors sequence functions 63 s e t function 343 sets hash tables as 77 lists as 43 s e t - d i f f e r e n c e function 359, 45 set-dispatch-macro-character function 387,235 s e t - e x c l u s i v e - o r function 359 set-macro-character function 387, 235 s e t - p p r i n t - d i s p a t c h function 386 set-syntax-from-char function 387 s e t f macro 322, 21 defining expansions of 100, 404 macros that expand into 168 macro call as first argument to 168 s e t q special operator 322 seventh function 357, 40 shadow function 346 shadowing-import function 346 Shalit, Andrew 405 s h a r e d - i n i t i a l i z e generic function 335 sharp-quote 25, 131 s h i f t f macro 322 s h o r t - f l o a t - e p s i l o n constant 392 s h o r t - f l o a t - n e g a t i v e - e p s i l o n constant 392 s h o r t - s i t e - n a m e function 390 shortest path 51 side-effects 19,22,201 s i g n a l function 341 signum function 353,146 s i m p l e - b i t - v e c t o r - p function 363 simple-condition-formatarguments generic function 341 simple-condition-format-control generic function 341 s i m p l e - s t r i n g - p function 364 simple-vector-p function 364 s i n function 353, 149 s i n g l e ?

Designing Web APIs: Building APIs That Developers Love
by Brenda Jin , Saurabh Sahni and Amir Shevat
Published 28 Aug 2018

You can also use an open source task queue like Celery. Scaling Throughput Best Practices Here are some best practices that will help your applications to scale to high load: • Measure and find your bottlenecks first before starting to make changes for scaling. The database is the most common bottle‐ neck in modern applications. • Avoid premature optimizations. Scaling optimizations often come at a cost, and some of them can increase the development time of your application. Unless you have scaling problems, you probably don’t want to add that complexity. • Prefer horizontal scalability over vertical scalability. • Understand that database indexes are among the best ways to address slow database queries. • Determine which data you use frequently, and cache it. • If you add caching, do not forget to add cache invalidation. • Consider performing expensive operations asynchronously.

Hands-On Functional Programming in RUST
by Andrew Johnson
Published 29 May 2018

In this chapter, we will learn the following: Recognizing and applying good performant code practices Diagnosing and improving performance bottlenecks Recognizing and applying good defensive coding practices Diagnosing and resolving software bugs Recognizing and applying metaprogramming techniques Technical requirements A recent version of Rust is necessary to run the examples provided: https://www.rust-lang.org/en-US/install.html This chapter's code is available on GitHub: https://github.com/PacktPublishing/Hands-On-Functional-Programming-in-RUST Specific installation and build instructions are also included in each chapter's README.md file. Writing faster code Premature optimization is the root of all evil – Donald Knuth A good software design tends to create faster programs, while a bad software design tends to create slower programs. If you find yourself asking, "Why is my program slow?, then first ask yourself, Is my program disorderly?" In this section, we describe some performance tips.

The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2
by Thomas A. Limoncelli , Strata R. Chalup and Christina J. Hogan
Published 27 Aug 2014

While every effort is made to foresee potential scaling issues, not all of them can receive engineering attention. The additional design and coding effort that will help deal with future potential scaling issues is lower priority than writing code to fix the immediate issues of the day. Spending too much time preventing scaling problems that may or may not happen is called premature optimization and should be avoided. 5.1.1 Identify Bottlenecks A bottleneck is a point in the system where congestion occurs. It is a point that is resource starved in a way that limits performance. Every system has a bottleneck. If a system is underperforming, the bottleneck can be fixed to permit the system to perform better.

…

See Service platform selection Plauger, P., 11 Playbooks oncall, 297–298 process, 153 Pods, 137 Points of presence (POPs), 83–85 Pollers, 352 Post-crash recovery, 35 Postmortems, 152 communication, 302 DevOps, 184 oncall, 291, 300–302 purpose, 300–301 reports, 301–302 templates, 484–485 Power failures, 34, 133 Power of 2 mapping process, 110–111 Practical Approach to Large-Scale Agile Development: How HP Transformed HP LaserJet FutureSmart Firmware, 188 Practice of System and Network Administration, 132, 204 Pre-checks, 141 Pre-shift oncall responsibilities, 294 Pre-submit checks in build phase, 202–203 Pre-submit tests, 267 Pre-web era (1985-1994), 452–455 Prefork processing module, 114 Premature optimization, 96 Prescriptive failure domains, 127 Primary resources capacity planning, 372 defined, 366 Prioritizing automation, 257–258 feature requests, 46 for stability, 150 Privacy in platform selection, 63 Private cloud factor in platform selection, 62 Private sandbox environments, 197 Proactive scaling solutions, 97–98 Problems to solve in DevOps, 187 Process watchers, 128 Processes automation benefits, 253 containers, 60 instead of threads, 114 Proctors for Game Day, 318 Product Management (PM) monitoring, 336 Production candidates, 216 Production health in continuous deployment, 237 Project-focused days, 162–163 Project planning frequencies, 410 Project work, 161–162 Promotion step in deployment phase, 212 Propellerheads, 451 Proportional shedding, 230 Protocols collections, 351 network, 489 Prototyping, 258 Provider comparisons in service platform selection, 53 Provisional end-of-shift reports, 299 Provisioning in capacity planning, 384–385 in DevOps, 185–186 Proxies monitoring, 352 reverse proxy service, 80 Public cloud factor in platform selection, 62 Public Information Officers in Incident Command System, 325–326 Public key infrastructure (PKI), 40 Public safety arena in Incident Command System, 325 Publishers in message bus architectures, 85 Publishing postmortems, 302 PubSub2 system, 86 Pull monitoring, 350–351 Puppet systems configuration management, 261 deployment phase, 213 multitenant, 271 Push conflicts in continuous deployment, 238 Push monitoring, 350–351 “Pushing Millions of Lines of Code Five Days a Week” presentation, 233 PV (paravirtualization), 58–59 Python language libraries, 55 overview, 259–261 QPS (queries per second) defined, 10 limiting, 40–41 Quadratic scaling, 476 Quality Assurance monitoring, 335 Quality assurance (QA) engineers, 199 Quality measurements, 402 Queries in HTTP, 69 Queries of death, 130–131 Queries per second (QPS) defined, 10 limiting, 40–41 Queues, 113 benefits, 113 draining, 35–36 issue tracking systems, 263 messages, 86 variations, 113–114 Quick fixes vs. long-term, 295–296 RabbitMQ service, 86 Rachitsky, L., 302 Rack diversity, 136 Racks failures, 136 locality, 137 RAID systems, 132 RAM for caching, 104–106 failures, 123, 131–132 Random testing for disaster preparedness, 314–315 Rapid development, 231–232 Rate limits in design for operations, 40–41 Rate monitoring, 348 Rationale, documenting, 276 Re-assimilate tool, 255 Read-only replica support, 37 Real-time analysis, 353 Real user monitoring (RUM), 333 Reboots, 34 Recommendations in postmortem reports, 301 Recommended reading, 487–489 Recovery-Oriented Computing (ROC), 461 Recovery tool, 255 Redis storage system, 24, 106 Reduced risk factor in service delivery, 200 Reducing risk, 309–311 Reducing toil, automation for, 257 Redundancy design for operations, 37 file chunks, 20 for resiliency, 124–125 servers, 17 Reengineering components, 97 Refactoring, 97 Regional collectors, 352–353 Registering packages, 204, 206 Regression analysis, 375–376 Regression lines, 376 Regression tests for performance, 156, 215 Regular meetings in DevOps, 187 Regular oncall responsibilities, 294–295 Regular software crashes, 128 Regular Tasks (RT) assessments, 423–425 operational responsibility, 403 Regulating system integration, 250 Relationships in DevOps, 182 Release atomicity, 240–241 Release candidates, 197 Release engineering practice in DevOps, 186 Release vehicle packaging in DevOps, 185 Releases defined, 196 DevOps, 185 Reliability automation for, 253 message bus architectures, 87 Reliability zones in service platform selection, 53–54 Remote hands, 163 Remote monitoring stations, 352 Remote Procedure Call (RPC) protocol, 41 Repair life cycle, 254–255 Repeatability automation for, 253 continuous delivery, 190 Repeatable level in CMM, 405 Replacement algorithms for caches, 107 Replicas, 124 in design for operations, 37–38 load balancers with, 12–13 three-tier web service, 76 updating, 18 Reports for postmortems, 301–302 Repositories in build phase, 197 Reproducibility in continuous deployment, 237 Requests in updating state, 18 “Resilience Engineering: Learning to Embrace Failure” article, 320 Resiliency, 119–120 capacity planning, 370–371 DevOps, 178 exercises, 143 failure domains, 126–128 human error, 141–142 malfunctions, 121–123 overload failures, 138–141 physical failures.

Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs
by Ken Kocienda
Published 3 Sep 2018

Here’s what he has to say about optimization: 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.2 (Emphasis added.) Optimization is the process where programmers try to make code execute faster. Isn’t that what the PLT was all about? So, isn’t optimization a good thing? Not always, and if the Knuthian numerical estimate is to be given the credence it deserves, and he is an extraordinarily deliberative man, then optimization is bad about 97 percent of the time.

The Pragmatic Programmer
by Andrew Hunt and Dave Thomas
Published 19 Oct 1999

Given a small input set, a straightforward insertion sort will perform just as well as a quicksort, and will take you less time to write and debug. You also need to be careful if the algorithm you choose has a high setup cost. For small input sets, this setup may dwarf the running time and make the algorithm inappropriate. Also be wary of premature optimization. It's always a good idea to make sure an algorithm really is a bottleneck before investing your precious time trying to improve it. Related sections include: Estimating, page 64 Challenges Every developer should have a feel for how algorithms are designed and analyzed. Robert Sedgewick has written a series of accessible books on the subject ([Sed83, SF96, Sed92] and others).

The Big Ratchet: How Humanity Thrives in the Face of Natural Crisis
by Ruth Defries
Published 8 Sep 2014

Beyond that, natural selection is likely to render the compound ineffective. Companies in the pesticide market need to continually synthesize new compounds to combat resistance. Many, many hundreds of different synthesized pesticides exist for this reason. It’s a costly endeavor with no endpoint. Resistance put a big dent in the premature optimism that DDT would once and for all make humanity the victor in the battle against pests. Pest resistance wrought by natural selection wasn’t the only problem with the DDT bonanza. The pesticide, when sprayed across fields and forests and inside homes, attacked all living organisms with which it came into contact.

Everything for Everyone: The Radical Tradition That Is Shaping the Next Economy
by Nathan Schneider
Published 10 Sep 2018

Less glamorously, the professional organizations for doctors, lawyers, real estate agents, and hairdressers have clung to the guild model, complete with monopoly powers recognized by governments and peers. As we talked on the rooftop, Prime Produce’s founders freely mixed medieval idiom with that of Silicon Alley. Taeyoung cited the computer programming guru Donald Knuth’s dictum, “Premature optimization is the root of all evil.” That is, if they decided too much ahead of time and in too much detail, they wouldn’t be as flexible or as iterative. Hsu described what Prime Produce was doing as “crafted social innovation,” a form of “slow entrepreneurship.” The guild’s appeal wasn’t just nostalgic to them but was a means of navigating an often lonely, attention-deficient economy, by cultivating habits of excellence and communizing resources like office space, companionship, and broadband.

Coders at Work
by Peter Seibel
Published 22 Jun 2009

. …” Mathematical things: similarly I'll get people who miss it. So then I'll say, you know, I actually said it correctly, but I know I still have to change it and make it better. Seibel: When you publish a literate program, it's the final form of the program, typically. And you are often credited with saying, “Premature optimization is the root of all evil.” But by the time you get to the final form it's not premature—you may have optimized some parts to be very clever. But doesn't that make it hard to read? Knuth: No. A good literate program will show its history. A good literate program will say, “Here's the obvious way to do it and then why we don't follow that road?”

…

I write a whole variety of different kinds of programs. Sometimes I'll write a program where I couldn't care less about efficiency—I just want to get the answer. I'll use brute force, something that I'm guaranteed I won't have to think—there'll be no subtlety at all so I won't be outsmarting myself. There I'm not doing any premature optimization. Then I can change that into something else and see if I get something that agrees with my brute-force way. Then I can scale up the program and go to larger cases. Most programs stop at that stage because you're not going to execute the code a trillion times. When I'm doing an illustration for The Art of Computer Programming I may change that illustration several times and the people who translate my book might have to redo the program, but it doesn't matter that I drew the illustration by a very slow method because I've only got to generate that file once and then it goes off to the publisher and gets printed in a book.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
by Martin Kleppmann
Published 17 Apr 2017

Sometimes, when discussing scalable data systems, people make comments along the lines of, “You’re not Google or Amazon. Stop worrying about scale and just use a relational database.” There is truth in that statement: building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. However, it’s also important to choose the right tool for the job, and different technologies each have their own strengths and weaknesses. As we shall see, relational databases are important but not the final word on dealing with data. Scope of This Book This book does not attempt to give detailed instructions on how to install or use spe‐ cific software packages or APIs, since there is already plenty of documentation for those things.

…

A single integra‐ ted software product may also be able to achieve better and more predictable perfor‐ mance on the kinds of workloads for which it is designed, compared to a system consisting of several tools that you have composed with application code [23]. As I said in the Preface, building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. The goal of unbundling is not to compete with individual databases on performance for particular workloads; the goal is to allow you to combine several different data‐ bases in order to achieve good performance for a much wider range of workloads than is possible with a single piece of software.

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
by Martin Kleppmann
Published 16 Mar 2017

Sometimes, when discussing scalable data systems, people make comments along the lines of, “You’re not Google or Amazon. Stop worrying about scale and just use a relational database.” There is truth in that statement: building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. However, it’s also important to choose the right tool for the job, and different technologies each have their own strengths and weaknesses. As we shall see, relational databases are important but not the final word on dealing with data. Scope of This Book This book does not attempt to give detailed instructions on how to install or use specific software packages or APIs, since there is already plenty of documentation for those things.

…

A single integrated software product may also be able to achieve better and more predictable performance on the kinds of workloads for which it is designed, compared to a system consisting of several tools that you have composed with application code [23]. As I said in the Preface, building for scale that you don’t need is wasted effort and may lock you into an inflexible design. In effect, it is a form of premature optimization. The goal of unbundling is not to compete with individual databases on performance for particular workloads; the goal is to allow you to combine several different databases in order to achieve good performance for a much wider range of workloads than is possible with a single piece of software.

Ruby by example: concepts and code
by Kevin C. Baird
Published 1 Jun 2007

In some cases, these features result in a very dramatic improvement, but in other cases, they either fail to improve the code or sometimes even make it worse. The places where these attempts fail to improve speed are often as interesting as where they succeed. There’s an old adage among programmers: Premature optimization is the root of all evil.2 Keep that in mind while reading these examples. The Code For this chapter, we’ll be looking at some short scripts in pairs. Here’s factorial1.rb: #!/usr/bin/env ruby # factorial1.rb class Integer def fact() return 1 if (self.zero?) or (self == 1) return self * (self-1).fact end end And here’s fibonacci1.rb: #!

Building Microservices
by Sam Newman
Published 25 Dec 2014

One of the downsides is that this navigation of controls can be quite chatty, as the client needs to follow links to find the operation it wants to perform. Ultimately, this is a trade-off. I would suggest you start with having your clients navigate these controls first, then optimize later if necessary. Remember that we have a large amount of help out of the box by using HTTP, which we discussed earlier. The evils of premature optimization have been well documented before, so I don’t need to expand upon them here. Also note that a lot of these approaches were developed to create distributed hypertext systems, and not all of them fit! Sometimes you’ll find yourself just wanting good old-fashioned RPC. Personally, I am a fan of using links to allow consumers to navigate API endpoints.

Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business
by Arvid Kahl
Published 24 Jun 2020

Usually, it will be yet another attempt at making a big difference and failing. This is a great opportunity to dust yourself off and try again. Just make sure you remove the feature that has proven not to work. Don't keep it hanging around. There are a number of other reasons that can cause you to build things you shouldn't have: "Premature Optimization"-like integrations. You thought you could use this eventually, and you'd better already have it in the product before you need it. Maybe you intend to eventually partner with a service, so you build an integration ahead of time. And then the partnership falls through, and you never need it.

Range: Why Generalists Triumph in a Specialized World
by David Epstein
Published 1 Mar 2019

And yet every May, speakers all over the country fire up the Standard Graduation Speech, the theme of which is: don’t give up on your dreams. I know what they mean, but this is a bad way to put it, because it implies you’re supposed to be bound by some plan you made early on. The computer world has a name for this: premature optimization. . . . . . . Instead of working back from a goal, work forward from promising situations. This is what most successful people actually do anyway. In the graduation-speech approach, you decide where you want to be in twenty years, and then ask: what should I do now to get there?

Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14
by Scott Meyers
Published 15 Mar 2014

Item 29: Assume that move operations are not present, not cheap, and not used. Move semantics is arguably the premier feature of C++11. “Moving containers is now as cheap as copying pointers!” you’re likely to hear, and “Copying temporary objects is now so efficient, coding to avoid it is tantamount to premature optimization!” Such sentiments are easy to understand. Move semantics is truly an important feature. It doesn’t just allow compilers to replace expensive copy operations with comparatively cheap moves, it actually requires that they do so (when the proper conditions are fulfilled). Take your C++98 code base, recompile with a C++11-conformant compiler and Standard Library, and—shazam!

Careless People: A Cautionary Tale of Power, Greed, and Lost Idealism
by Sarah Wynn-Williams
Published 11 Mar 2025

We [Facebook] make the weather.… Lately, however, we have been thinking more deeply about how the content we show not only responds to existing affinities but also reinforces or shapes future affinities, potentially by clustering people and cutting off some points from other points prematurely.… We have been prematurely optimizing and we are driving towards a local maxima and … what we have to do is relax the optimization a bit. Take a hit on time spent and engagement and let things flow with greater exploration. Boz showed that Facebook’s senior management knew exactly what Facebook was doing. Then he argued that Facebook should step back from all this “optimizing and driving,” instead letting people have greater input and more control over the content they see.

Text Analytics With Python: A Practical Real-World Approach to Gaining Actionable Insights From Your Data
by Dipanjan Sarkar
Published 1 Dec 2016

There are several advanced features in Python, including iterators, generators, list comprehensions, lambda expressions, and several modules like itertools and functools, which provide the ability to write code following the functional programming paradigm. Python was designed keeping in mind the fact that simple and beautiful code is more elegant and easy to use rather than doing premature optimization and writing hard-to-interpret code. Python’s standard libraries are power-packed with a wide variety of capabilities and features ranging from low-level hardware interfacing to handling files and working with text data. Easy extensibility and integration was considered when developing Python such that it can be easily integrated with existing applications—rich application programming interfaces (APIs) can even be created to provide interfaces to other applications and tools.

Software Design for Flexibility
by Chris Hanson and Gerald Sussman
Published 17 Feb 2021

Use of time and space matters, but our intuition about where those costs come from is poor. Every engineer knows that evaluating the real performance of a system involves extensive and careful measurements that often show that the cost is in surprising places. As complexity increases, this will only get harder. But we persist in doing premature optimization at all levels of our programs without knowing its real value. Suppose we separate the parts of a system that have to be fast from the parts that have to be smart. Under this policy, the cost of generality and evolvability can be confined to the parts that have to be smart. This is an unusual perspective in computing systems, yet it is ubiquitous in our life experience.

The Missing Billionaires: A Guide to Better Financial Decisions
by Victor Haghani and James White
Published 27 Aug 2023

It certainly seems plausible that holding future oil should offer investors a risk premium, and that owning gold, art, or cryptocurrencies will generate a return that tracks per capita income growth of some segment of the population, or even more. But unfortunately, it is not possible to actually observe and quantify the cash flows associated with this expected return. Building Your Multi‐asset Portfolio Premature optimization is the root of all evil. —Donald Knuth, computer scientist, winner of the Turing Award, and the father of the analysis of algorithms All our discussion so far has been framed within the context of a two‐asset world, with the main decision being how much of your savings to allocate to the risky asset—usually the broad equity market—with the residual invested in the safe asset, usually T‐bills or TIPS.

Concepts, Techniques, and Models of Computer Programming
by Peter Van-Roy and Seif Haridi
Published 15 Feb 2004

Rewriting a program to improve some characteristic is called optimizing it, although it is never “optimal” in any mathematical sense. Usually, the program can easily be improved up to a point, after which diminishing returns set in and the program rapidly becomes more complex for ever smaller improvements. Optimization should therefore not be done unless necessary. Premature optimization is the bane of computing. Optimization has a good side and a bad side. The good side is that the overall execution time of most applications is largely determined by a very small part of the program text. Therefore performance optimization, if necessary, can almost always be done by rewriting just this small part (sometimes a few lines suffice).

…

Paul, 257 Mozart Consortium, xxiv, xxvi, 106 Mozart Programming System, 254 Base modules, 229, 729 Browser tool, 1, 88 displaying cyclic structures, 102 displaying strings, 716 WaitQuiet operation, 798 cheap concurrency, 252 command line interface, 817 Compiler Panel tool, 815 Distribution Panel tool, 815 Explorer tool, 757, 815 garbage collection, 78 GlobalStore, 743 interactive interface, 1, 87, 815 kernel languages, 844 library modules, 229 limited role of the compiler, 504 memory consumption, 174 Open Source license, xxiv overview, xxiv Panel tool, 815 performance, 201, 379 Prototyper tool, 689 separate compilation, 457 Standard Library, 214, 225, 230, 685, 690 System modules, 229, 729 thread scheduler, 253 uncaught exception, 93, 801 multi-agent systems (MAS), xxiii, 345, 362, 576 multimedia, 176 multiprocessor cluster, 711 shared-memory, 710 multiset, 240 mutable store (for cells), 794 Myriorama, 273 n-queens problem, 629 name, 203, 714, 791, 824, 847 defining scope, 508 distributed computing, 711 fresh, 203 generation, 206 impure, 715 pure, 715 name server, 403, 711 natural design, 461, 569 natural language, xiii, 31, 38, 641 natural selection, 451, 462 Naur, Peter, 32 Index 885 needed variable, 283, 796 negation as failure, 662, 674 nesting marker, 53, 83, 355, 365 Netherlands, 819 network awareness, 387, 723 network transparency, 255, 387, 708 neutral element, 187 New operation, 495, 549 NewActive operation, 558 NewActiveExc operation, 562, 728 NewArray operation, 436 NewCell operation, 416 NewDictionary operation, 437 NewLock operation, 22, 583 NewName operation, 203, 792, 824 NewPort operation, 349 NewSpace operation, 764 NewStat operation, 725 resilient, 742 Newton’s method for square roots, 119 Newton, Isaac, 278 nil, 828 node (in Erlang), 387 noise (electronic), 473 nonblocking operation, 333 receive (in Erlang), 394 delete (in queue), 598 read (in tuple space), 586 receive, 333 send, 333 stack, 578 noncompositional design, 461 nondeterminism choice statement, 621, 623, 772 declarative concurrent model, 575 don’t know, 324, 621 introduction, 20 limitation of declarative model, 319 logic programming, 638 observable, 20, 234, 319, 570, 573, 575, 576 bounded buffer, 595 Filter operation, 386 lack of in Flavius Josephus problem, 561 relation to exceptions, 327 relation to coroutines, 275 thread scheduler, 253 nonstrict evaluation, 331 Haskell, 310 nonvar operation (in Prolog), 660, 662 normal distribution, 476 normal order reduction, 330 Haskell, 309 notify operation (in monitor), 592 notifyAll operation (in monitor), 593 NP-complete problems, 176 NUL character, 841 number, 52, 819 O’Keefe, Richard, 111, 407, 668 object, 413, 420, 542, 546 declarative, 423, 483, 568 introduction, 17 Java, 551, 807 passive, 556, 575, 576 strong, 542 object code, 221 object graph, 553 object, active, 350, 556–567 comparison with passive object, 556 defining behavior with a class, 558 polymorphism, 429 object, port, 346, 350, 413 approaches to concurrency, 573 Erlang, 563 further reading, 582 many-to-one communication, 351 polymorphism, 429 reactive, 351 reasoning, 352 886 Index sharing one thread, 378 when to use, 576 object, stream, 256, 265–266, 411, 413, 574 comparison with port object, 351 Flavius Josephus problem, 561 higher-order iteration, 258 polymorphism, 429 producer/consumer, 257 transducer, 259 Ockham, William of, 29 octal integer, 819 Okasaki, Chris, 175, 330 OLE (Object Linking and Embedding), 462 OMG (Object Management Group), 462 open distribution, 709, 711, 714 open program, 202 Open Source software, xxiv operating system, 208 Linux, xxvi, 201, 471, 499 Mac OS X, xxiv, xxvi, 254 Solaris, xxvi, xxix Unix, xxiv, 254, 305, 459, 553, 642 VM (Virtual Machine), 41 Windows, xxiv, 254 operation (in data abstraction), 420 operational semantics, 38, 60, 635, 779–811 operator associativity, 34, 837 binary, 34, 836 infix, 52, 83, 185, 793, 826, 828, 830, 836 mixfix, 826, 837 postfix, 837 precedence, 34, 836 prefix, 836 ternary, 838 unary, 836 OPI (Oz programming interface), 815 optimistic scheduling, 603 optimization, 177 avoid during development, 452 combinatoric, 661 compiler, 162 eager execution, 302 early error detection, 504 first-argument indexing, 659 memoization, 694 monitor performance, 597 object system, 545 relational programming, 622 short-circuit protocol, 559 standard computer, 314 thread priorities, 265 order-independence, 49 unification, 110, 232 orelse operator, 83 otherwise method, 500 OTP (Ericsson Open Telecom Platform), 386 overloading, 313, 429 overriding relation, 502 Oz, Wizard of, 1 ozc command, 228, 817 pairwise distinct, 756, 774, 782 palindrome, 628 palindrome product problem, 628, 757 Panangaden, Prakash, 338 Panel tool, see Mozart Programming System Papert, Seymour, xiii, 233 paradigm, xiii, xvi, see computation model declarative, 29 school of thought, xvi paragraph (in OPI), 815 parallelism, 237, 322 difference with concurrency, 322 importance of nonstrictness, 331 importance of worst-case complexity, 174 parameter passing, 430–434 Index 887 call by name, 432 exercise, 484 call by need, 433 exercise, 485 lazy evaluation, 433 call by reference, 57, 430 Java, 555 call by value, 431 Java, 555 call by value-result, 431 call by variable, 430 parity, 14 Parnas, David Lorge, xxii, 462 parser, 32, 161–166 generic, 650 gump tool, 39 natural language, 641 partial failure, 326 partial list, 440, 829 partial order, 238 partial termination, 243, 338, 804 partial value, 46 Pascal’s triangle, 4 Pascal, Blaise, 5 pass by . . . , see parameter passing pattern matching case statement, 6, 67 function (in Erlang), 388 Haskell, 309 receive expression (in Erlang), 391 reduction rule semantics, 784 PDA (procedural data abstraction), 420 pencil, xviii Pentium III processor, 201, 471 performance cluster computing, 711 competitive concurrency, 254 constraint programming, 758 Cray-1 supercomputer, 175 declarative programming, 313 dictionary, 201 distributed stream, 724 lazy language, 289, 342 measuring, 167 memoization, 25, 315 mobile object, 724 monitor, 597 Mozart Programming System, 201, 379 personal computer, 175 price of concurrency, 339 record field access, 438 role of optimization, 177, 265, 302 role of parallelism, 237, 322 transitive closure, 471 word-of-mouth simulation, 486 permanent failure, 739 permutations, 2 persistence data structure, 149, 297 database, 654 Erlang, 387 transaction, 600 personal computer, 3, 252, 254, 289, 304 low-cost, 74, 175 pessimistic scheduling, 603 Phidani Software, 642 π calculus, xvii, 41, 54, 805 pipeline, 259 pixel, 556 placeholder dataflow variable, 86 future (in Multilisp), 336 GUI design, 686, 703 planning flight, 671 WARPLAN, 621 Plotkin, Gordon, 779 point resting, 338 synchronization, 333 two-dimensional space, 554 pointer, 76 content edge, 733 888 Index dependency, 459 dynamic typing, 106 garbage collection, 76 memory block, 480 resource, 480 state, 733 POLA (Principle of Least Authority), 209 polymorphism, 18, 106, 425, 462, 493 active objects, 429 ad-hoc, 429 apportioning responsibility, 425 example, 530 Haskell, 312 object-oriented programming, 490 port objects, 429 stream objects, 429 universal, 429 Ponsard, Christophe, 545 port (explicit state), 349, 719, 848 communication from inside encapsulated search, 673 distributed semantics, 383 Port.sendRecv operation, 673 portal, 476 postcondition, 441, 521 potential function, 175 precondition, 441, 521 predicate calculus, 633 preemption, 252 preprocessor, 318 DCG (in Prolog), 649 design patterns, 536 extended DCG (in Prolog), 140 fallacy of, 318 presentation model (in GUI), 695 principle abstraction, 410 avoid changing interfaces, 458 avoid premature optimization, 177, 452 balance planning and refactoring, 452 centralized first, distributed later, 745 class is final by default, 492 compartmentalize responsibility, 425, 451 concentrate explicit state, 412 creative extension, xiv, 844 decisions at right level, 460 declarative concurrency, 242, 281 document component interfaces, 451 documented violations, 460 eager default, lazy declared, 330 encapsulate design decisions, 458 enriching control (in logic programming), 640 error confinement, 90 “everything should be an object”, 542 exploit data abstraction uniformity, 543 form mirrors content, 544 freely exchange knowledge, 451 function structure follows type structure, 135 functional abstraction, 4 last call optimization, 72 layered language design, 850 least authority (POLA), 209 least expressiveness, 323 least privilege, 209 minimize dependencies, 387, 459 minimize indirections, 459 model independence, 457 more is not better or worse, just different, xx Mozart design rules, xxvi natural selection, 451, 462 need to know, 209 objects over ADTs, 490 pay only on use, 620 predictable dependencies, 460 run time is all there is, 504, 690 separation of concerns, 567 stateful component with declara- Index 889 tive behavior, 417 substitution property, 518, 521, 523 syntax stability, 643 system decomposition, 210 type first, 137 use data abstraction everywhere, 489, 543 working software keeps working, 59, 459, 722 private scope, 507, 508 C++ and Java sense, 508 Smalltalk and Oz sense, 507 probability exponential distribution, 475 Gaussian distribution, 476 normal distribution, 476 uniform distribution, 474 unique name generation, 207 problem cryptarithmetic, 755, 776 digital logic satisfiability, 176 Flavius Josephus, 558–561 flight planning, 671 grocery puzzle, 774 halting, 209, 681 Hamming, 293, 342 intractable, 176 library scheduler, 672 making change, 775 n-queens, 629 NP-complete, 176 palindrome product, 628, 757 Send-More-Money, 755, 776 undecidable, 209 zebra puzzle, 774 proc statement, 65, 792 procedure as component, 412 basic operations, 55 external reference, 65 importance, 54 order, 177 tail-recursive, 72 procedure value (closure), 65, 178, 792 anonymous, 53 common limitation, 179, 552 distributed lexical scoping, 722 encoding as an object, 540 higher-order programming, 177 relation to inner class, 552 process concurrent calculus, 54 concurrent program design, 364 CSP, 619 distributed system, 707 Erlang, 350, 386, 389 large program design, 450 operating system, 255 producer and consumer, 724 run-time error, 96 small program design, 218 processor, 237 cluster computing, 711 dataflow machine, 337, 469 parallel functional programming, 331 shared-memory multiprocessor, 710 producer, 257 profiling, 177, 452 program design, see software development program point, 444, 606 programming, xv, 1 accumulator, 139 component-based, 412 concurrent, 573 constraint, 44, 274, 577, 663 data-centered, 576 declarative, 29, 406 descriptive, 115 need for algorithms, 116 programmable, 115 Erlang, 388 flow-based, 257 functional, 406 890 Index future developments, 461 good style, xxi Haskell, 309 higher-order, 113, 123, 177–194 introduction, 13 relation to object-oriented, 538 imperative, 29, 406 Java, 552, 615 kernel language approach, xvi logic, 44, 101, 142, 406, 632 multi-agent, 412, 576 multiparadigm, xiv, xxvi event manager, 566 nonalgorithmic, 622 object-based, 19, 538 object-oriented (OOP), 19, 413, 489 open, 105, 202 paradigm, xiii, xvi, 29, see computation model Prolog, 663 real-time, 304 relational, 621 stateful, 29 stateless, 29 synchronous, 266 programming model, xiii, 29 Prolog, 660–671 Aquarius, 140, 661 Parma, 661 SICStus, 190, 663 state threads package, 190 proof engineering, 117 proof rule, 444 propagate-and-search, 629, 750 propagator, 752, 760 property liveness, 602 object, 497 safety, 602 propositional logic, 632 protected scope, 508 C++ sense, 509 Java sense, 567 protection boundary, 202 protector, 325 protocol, 353 by-need, 282 communication, 715 consistency, 712 DHCP (Dynamic Host Connection Protocol), 207 distributed binding, 733 distributed unification, 733 eager copy, 734 eager immediate copy, 734 interaction (in GUI), 682 invalidation, 733 IP (Internet Protocol), 206 lazy copy, 733 meta-object, 516 mobile state, 733 negotiation, 376 short-circuit, 559 stationary state, 733 TCP (Transmission Control Protocol), 712, 740 timer, 368 Prototyper tool, 689 pseudorandom numbers, 473 Psion Series 3 palmtop computer, 378 public scope, 507 pure object-oriented language, 543 QTk, 213, 680, 729 interactive use, 214, 684 Prototyper, 689 use in application, 225 quadratic equation, 179 quantifier, 441, 445, 633, 645 existential (in Prolog), 671 quantum (in thread scheduling), 252 query database, 655 logic programming, 634 queue, 145 amortized ephemeral, 147 amortized persistent, 298 Index 891 breadth-first traversal, 156 concurrent, 379, 583 nonblocking delete, 598 priority, 605, 614 worst-case ephemeral, 147 worst-case persistent, 299 race condition, 20, 234 raise statement, 93, 801 random number generation, 472 rational tree, 760 Raymond, Eric, 462 reachable memory, 74 ReadOnly operation, 799 real-time computing garbage collection, 76 hard, 174, 253, 254, 304 soft, 304 reasoning algebraic, 111, 116, 323 atomic action, 581 causal, 353, 575 lift control system, 375 logical, xix, 111, 632 message-passing concurrent model, 352 shared-shate concurrent model, 324 stateful model, 324, 440 receive asynchronous, 332 nonblocking, 333 synchronous, 332 receive expression (in Erlang), 391 recomputation, 761, 776 record, 19, 52, 825 adjoin, 827 basic operations, 54, 826 dynamic creation, 165, 549, 695 importance, 53 type, 438 usage trade-offs, 438 recurrence equation, 167 recursion, 3, 113, 124 direct, 113 indirect, 113 mutual, 110 polymorphic, 309 programming with, 127 Prototyper tool, 690 tail recursion optimization, 72 red cut (in Prolog), 670 Red Hat Corporation, xxvi, 201, 471 reduction order, 330–332 applicative, 330 normal, 330 reduction rule, 784 reengineering, 522 refactoring, 452 reference, 714 referential transparency, 113 reflection, 515 region (in OPI), 815 register abstract machine, 56 forwarding, 621 memory management, 74 registration action procedures (in GUI), 683 display refresh (FlexClock), 700 distributed binding, 737 finalization, 481 relation, 655 relative error, 120 reliability, 711 rendezvous, 619 replicator, 326 research project, xxiv resolution deadlock, 605 logic programming, 635, 640, 662 SLDNF, 662 video display, 321 resource distributed component, 746 distributed system, 729 external, 77, 480 file descriptor, 293 892 Index localized, 709 producer/consumer pipeline, 261 use of laziness, 289 responsibility atomicity and consistency (in transaction), 600 compartmentalize (in a team), 451 coroutine (avoiding starvation), 275 design by contract, 521 distributed memory management, 738 dynamic typing, 493 failure confinement, 245 memory management, 76 role of polymorphism, 425 type inference, 137 resting point, 338 restriction (environment), 62 retract/1 operation (in Prolog), 662 return (in for loop), 190 Reuter, Andreas, 582, 600 Reynolds, John C., 419 right, see name Rinard, Martin C., 338 RISC (Reduced Instruction Set Computer) microprocessor, 621 RMI (remote method invocation), 354, 709, 724, 725 root variable, 763 Round operation, 822 RPC (remote procedure call), 354, 709 rubber band, 251 runic inscription, 779 Runnable interface (in Java), 616 s-expression, 650 Sacks, Oliver, 405 safety, 602 Saint-Exupéry, Antoine de, 111 Santayana, George, 694 Saraswat, Vijay A., 338, 662, 808 scalability compilation, 458 multiprocessor, 710 program development, 105 weighted reference counting, 737 scalar product (constraint), 775 scheduler Delay operation, 304 deterministic, 253 lift control system, 366 nondeterministic, 253 randomness, 473 resource allocation, 672 round-robin, 252, 256 thread, 239, 252 transaction, 603 Schulte, Christian, xxvi science, xv, xviii scientific method, xvii scope, 56, 507 attribute, 510 dynamic, 59 lexical, 57, 59, 64, 508, 539 absence in Prolog, 661 distributed, 722 hiding, 221, 411, 423, 442, 483, 495, 549 substitution, 803 private, 507, 508 protected, 508 public, 507 static, see lexical user-defined, 508 search aggregate, 670 all-solutions, 626 binary, 151 branch-and-bound, 772 breadth-first, 644 communication from inside encapsulated search, 673 constraint programming, 274 contribution of AKL, 809 danger, 639 Index 893 database query, 657 depth-first, 622, 644 deterministic, 621 encapsulated, 625 generate-and-test, 629, 758 iterative deepening, 644 linear, 197 logic programming, 661 n-queens problem, 629 one-solution, 626 overuse, xxi propagate-and-search, 629, 750 pruning, 662 relational computation model, 623 relational programming, 621 saturation, 772 search space, 622 search strategy, 761 search tree, 624 security abstract data type, 201–210 application, 744 atom vs. name, 508 capability, 208 data abstraction, 419–435 distributed resources, 731 distributed system, 743 engineering, 744 hardware, 744 human society, 208 implementation, 744 kernel language concepts, 847 language, 208, 744 linguistic abstraction, 39 mechanism, 208 open distribution, 711 policy, 208 right, 791, 847 static typing, 106 threat model, 744 self clone, 517 delegation, 511 dynamic binding, 505 forwarding, 511 Java, 553 this notation, 551 self (in Erlang), 390 semantic stack, 62 runnable, 62 suspended, 62 terminated, 62 semantics, 31 abstract machine, 56–78, 92–94, 239–241, 282–283, 348–349, 416–417 axiomatic, 38, 440–450, 632 by-need trigger, 282 cell, 416 common abstractions, 808 denotational, 38 exceptions, 92 interleaving, 780 kernel language, see abstract machine kernel language approach, 38 logical, 38, 631–641 monitor (in Java), 592 operational, 38, 60, 635, 779–811 port, 348, 383 secure types, 203 semantic statement, 61 SOS (structural operational semantics), 779 thread, 239 Send operation, 349 slot-reserving semantics, 384 send asynchronous, 332 latency, 263 nonblocking, 333 synchronous, 332 Send-More-Money problem, 755, 776 separation of concerns, 567 sequential logic, 269 serializability, 600 serialization, 709 894 Index serializer, 325 set comprehension, 301 setof/3 operation (in Prolog), 626, 666, 670 Shakespeare, William, 815 shared-state concurrency, see atomic action, see lock, see monitor, see transaction sharing, 418 Browser tool, 102, 829 distributed state, 720 distributed value, 716 thread, 378 short-circuit concurrent composition, 277 Flavius Josephus problem, 559 transitive closure, 464 Show operation, 340 side effect, 411 declarative, 288 signal operation (in monitor), 592 signature (of procedure), 129 simulation components, 412 digital logic, 266–272 inadequacy of declarative model, 173 Internet, 412 multi-agent, 412 slow network, 578 small world, 486 word-of-mouth, 476 Simurgh, 707 single-assignment store, 42–49, 60, 781 importance, 43 singularity, 176 sink (consumer), 259 64-bit address, 78 64-bit word, 74, 175, 820 skip statement, 62, 785 SLDNF resolution, 662 small world graph, 461 simulation, 486 Smolka, Gert, xxvi snapshot (of state), 437, 718 software design, see design methodology, see language design software development, 218, 450 bottom-up, 451 compositional, 453 concurrent components, 362 distributed programming, 745 evolutionary, 451 extreme programming, 452 framework, 492 IID (Iterative and Incremental), 451 importance of names, 508 in the large, 450 in the small, 218 incremental, 451 interactive interface, 87 iterative, 451 middle-out, 451 stepwise refinement, 465, 604 test-driven, 452 top-down, 8, 451 software engineering, 450 component as unit of deployment, 221 concurrency, 233 distributed lexical scoping, 722 further reading, 462 informatics curriculum, xxii lexical scoping, 59 software rot, 459 Solaris operating system, xxvi, xxix Solve operation, 626, 773 SolveAll operation, 626 SolveOne operation, 626 Sort operation, 670, 829 SOS (structural operational semantics), 779 source (producer), 259 source code, 221 interactive, 815 Index 895 million line, xvi, 36, 387, 457, 458 nonexistent, 492 preprocessor input, 318 reengineering, 522 set of functors, 285 textual scope, 64 variable name, 44 space, see computation space, see memory space leak, see memory leak specification, 410 component, 461 specification language, 116 speculative execution (in nonstrict language), 331 stack declarative object, 423 depth-first traversal, 156 memory management, 74 open declarative, 195, 421 proving it correct, 442 secure declarative bundled, 423 secure declarative unbundled, 205, 422 secure stateful bundled, 424 secure stateful unbundled, 424 semantic, 61 stateful concurrent, 578 standalone application, 222 declare not allowed, 87 Java, 555 uncaught exception, 93 starvation, 275 wait set implementation, 597 state cell (mutable variable), 414 declarative, 408 explicit, 16, 409 implicit, 408 interaction with call by name, 485 lazy execution, 481 lazy language, 331 memory management, 77 modularity property, 315 nonstrict language, 331 port (communication channel), 347 reasoning with, 38, 440 revocable capability, 434 threading, 139 transformation, 133 state transition diagram, 353, 368 component design, 364 floor component, 369 lift component, 371 lift controller component, 369 transaction, 607 stateless (declarative programming), 111 statement case, 67, 790 catch (clause in try), 94 choice, 623, 772 conc, 278 declare, 2, 87 fail, 623 finally (clause in try), 94 for, 188 fun, 84 functor, 223 gate, 272 if, 66, 790 local, 56, 63, 786 lock, 22, 583 proc, 65, 792 raise, 93, 801 skip, 62, 785 thread, 241, 785 try, 92, 799 break, 486 compound, 117 compound (in Java), 552 declarative kernel language, 49 interactive, 87 procedure application, 66 sequential composition, 63, 785 suspendable, 65 896 Index value creation, 63 variable-variable binding, 63 static binding, 506 linking, 222 scope, see scope, lexical typing, 51, 104–106 stdin (standard input), 229, 553 stdout (standard output), 553 Steiner, Jennifer G., 334 Stirling’s formula for factorial, 618 storage manager, 325 store, 781 equivalence, 785 mutable (for cells), 416 mutable (for ports), 348 need, 780, 795 predicate, 781 read-only, 206, 798 single-assignment, 42–49, 60, 99, 235, 781 trigger, 282, 795 value, 43 stream, 795 deterministic, 257 Java, 553 merger, 395 producer/consumer, 257 usage trade-offs, 439 strict . . . , see eager . . . strict two-phase locking, 604 strictness analysis, 289, 310, 342 string, 53, 830 virtual, 211, 831 StringToAtom operation, 824 structure compiler, 162 compositional, 461 difference, 141 distribution, 255 effect of concurrency, 252 grammar, 32 hierarchical, 453 interpreter, 653 noncompositional, 461 program, 219, 220 structure equality, 103, 418, 723 substitution, 126, 803 substitution property, 518, 521, 523 subtype basic types, 52 class hierarchy, 518 Sun Microsystems, xxvi, 462 superclass, 503, 513, 556 supercomputer, 175 supply-driven execution, see eager execution suspension Delay operation, 305 due to program error, 48, 89 thread, 239, 276 Sussman, Gerald Jay, 42 Sussman, Julie, 42 Symbian Ltd., 378 symbolic link, 459 synchronization, 333–337 clock, 308 dataflow, 790 synchronized keyword, 593, 616 synchronous communication, 332 active object variant, 562 component interaction, 456 CSP, 619 dependency, 387 error reporting, 360 failure detection, 400, 739 fault confinement, 745 receive, 332 send, 332 synchronous programming, 266 syntactic sugar, 40, 79–84 dynamic record creation, 165 local statement, 40 state transition diagram, 369 syntax, 31 convention for examples, xxix language, 31 nestable constructs (in Oz), 833 Index 897 nestable declarations (in Oz), 833 Oz language, 833 Oz lexical, 839 Prolog, 663 term (in Oz), 833 synthesized argument, 161 system exception, 96 Szyperski, Clemens, 462 tail call optimization, 72 Tanenbaum, Andrew S., 334 task (in concurrency), 780 tautology, 632 TCP (Transmission Control Protocol), 712, 740 technology, xv dangers of concurrency, 21 history of computing, 176 magic, 314 molecular computing, 176 Prolog implementation, 661 reengineering, 522 singularity, 176 software component, 462 synchronous digital, 267 transition to 64-bit, 78 Tel, Gerard, 353 tell operation, 782, 787 temporal logic, 603 temporary failure, 739 term Erlang, 391 Oz, 833 Prolog, 664 termination detection, 276, 382 ping-pong example, 305 failure in declarative program, 245 partial, 243, 338, 804 proof, 449 total, 804 test-driven development, 452 testing declarative programs, 111, 407 dynamic typing, 105 programming in the small, 219 stateful programs, 407 text file, 210 Thalys high-speed train, 382 theorem binomial, 4 Church-Rosser, 331 Gödel’s completeness, 634 Gödel’s incompleteness, 634 halting problem, 681 theorem prover, 117, 634, 662 Therac-25 scandal, 21 thinking machine, 621 third-party independence, 335 32-bit address, 78 32-bit word, 74, 174 this, see self Thompson, D’Arcy Wentworth, 405 thread, 846 declarative model, 233 hanging, 399 interactive interface, 89 introduction, 15 Java, 615 monotonicity property, 239, 781, 782 priority, 253 ready, 239 runnable, 239 suspended, 239 synchronization, 333 thread statement, 241, 785 Thread class (in Java), 616 throughput, 263 thunk, 432 ticket, 480, 714 Connection module, 715 ticking, 307 time complexity, 11 time slice, 252–254 duration, 254 898 Index time-lease mechanism, 480, 734, 738 time-out, 740 Erlang, 391–394 system design, 460 timer protocol, 368 timestamp, 207, 602 timing measurement active object, 379 memory consumption, 173 palindrome product (constraint version), 758 palindrome product (naive version), 629 transitive closure, 471 word frequency, 201 token equality, 418, 714, 723 token passing, 579, 588, 591, 721 token syntax (of Oz), 833 tokenizer, 32, 162 top-down software development, 8, 451 total termination, 804 trade-off asynchronous communication vs. fault confinement, 745 compilation time vs. execution efficiency, 457 compositional vs. noncompositional design, 461 dynamic vs. static scoping, 58 dynamic vs. static typing, 104 explicit state vs. implicit state, 315, 409 expressiveness vs. execution efficiency, 116 expressiveness vs. manipulability, 681 functional decomposition vs. type decomposition, 542 helper procedure placement, 120 indexed collections, 435 inheritance vs. component composition, 462, 492 kernel language design, 844 language design, 811 lazy vs. eager execution, 329 memory use vs. execution speed, 177 names vs. atoms, 510 nonstrictness vs. explicit state, 331, 344 objects vs.

The Personal MBA: A World-Class Business Education in a Single Volume
by Josh Kaufman
Published 2 Feb 2011

The purpose of understanding and analyzing systems is to improve them, which is often tricky—changing systems can often create unintended consequences. In this chapter, you’ll learn the secrets of Optimization, how to remove unnecessary Friction from critical processes, and how to build Systems that can handle Uncertainty and Change. SHARE THIS CONCEPT: http://book.personalmba.com/improving-systems/ Optimization Premature optimization is the root of all evil. —DONALD KNUTH, COMPUTER SCIENTIST AND FORMER PROFESSOR AT STANFORD UNIVERSITY Optimization is the process of maximizing the output of a System or minimizing a specific input the system requires to operate. Optimization typically revolves around the systems and processes behind your Key Performance Indicators , which measure the critical elements of the system as a whole.

Eloquent JavaScript: A Modern Introduction to Programming
by Marijn Haverbeke
Published 15 Nov 2018

: operator, 18, 20, 209 [] (array), 60 [] (subscript), 60, 61 || operator, 17, 20, 51, 95, 328, 408 2d (canvas context), 289 200 (HTTP status code), 312, 360, 364 204 (HTTP status code), 366, 367 304 (HTTP status code), 374, 380, 386 400 (HTTP status code), 425 403 (HTTP status code), 364 404 (HTTP status code), 312, 365, 377–379 405 (HTTP status code), 316, 364 406 (HTTP status code), 422 500 (HTTP status code), 364 A a (HTML tag), 222, 235, 237, 320, 344 Abelson, Hal, 202 absolute positioning, 240, 244, 253, 257, 262 absolute value, 76, 424 abstract data type, 96 abstract syntax tree, see syntax tree abstraction, 5, 41, 84, 86, 203, 316, 349 in Egg, 230 of the network, 221 acceleration, 281–282 Accept header, 329, 422 access control, 98, 141–142, 375 Access-Control-Allow-Origin header, 316 actions, 334, 336, 337 activeElement property, 319 actor, 269, 274, 280 add method, 113 addEntry function, 66 addEventListener method, 248, 282, 362 addition, 13, 113 address, 77, 311 address bar, 221, 311, 313 adoption, of tools and techniques, 145 ages example, 104 alert function, 223–224 algorithmic optimization, 397, 406 alpha, 346 alphanumeric character, 147 alt attribute, 233 ALT key, 252 altKey property, 252 ambiguity, 215 American English, 148 ampersand character, 223, 314 analysis, 129, 133 ancestor element, 275 Android, 252 angle, 242, 293, 294, 421 angle brackets, 222 animation, 256, 262, 271, 306, 419 bouncing ball, 308, 421 performance, 266 platform game 277, 283, 296, 297, 303, 305 spinning cat, 240, 241, 244 anyStorage function, 198–199, 200 appendChild method, 232, 417 Apple, 225 application (of functions), see function application applications, 1, 333, 372 arc, 293, 294 arc method, 293, 421 argument, 27, 47, 51, 74, 155, 204 arguments object, 409 argv property, 355 arithmetic, 13, 19, 210 array, 61, 64, 79, 95 counting, 93 creation, 91, 60, 336, 409, 413 in Egg, 214 filtering, 88 indexing, 60, 68, 72, 409, 418 iteration, 69, 85, 87 length of, 61 as matrix, 107–108, 268 methods, 71, 79, 87–89, 92, 94, 95 notation, 77 random element, 122 as regular expression match, 149 representation, 77 of rest arguments, 74 searching, 68, 71 as table, 67 Array constructor, 336 Array prototype, 100, 103 Array.from function, 195, 231, 356 array-like object, 230–232, 255, 320, 325, 358 arrays in Egg (exercise), 214, 416 arrow function, 45, 99, 199 arrow keys, 262 artificial intelligence, 117, 213 assert function, 140 assertion, 140 assignment, 25, 34, 160, 162, 215, 417 assumption, 139, 140 asterisk, 13, 148 async function, 195–196, 199, 200, 386 asynchronous programming, 181, 200 animation, 284 in Node.js, 354, 359, 361, 365, 368 reading files, 325 attribute, 222, 230, 235, 320, 337, 422 autofocus attribute, 320 automatic semicolon insertion, 24 automation, 125, 132 automaton, 117 avatar, 266 average function, 91 await keyword, 195–196, 197, 199 axis, 281, 289, 298, 424 B Babbage, Charles, 58 background, 266, 273, 278 background (CSS), 262, 266, 274 backslash character as path separator, 365 in regular expressions, 146, 147, 157, 158, 414 in strings, 14, 223 backtick, 14–15 backtracking, 153–154, 156–157 ball, 308, 421 balloon (exercise), 262, 418 banking example, 137 Banks, Iain, 264 baseControls constant, 348 baseTools constant, 348 bean counting (exercise), 56, 409 beforeunload event, 258 behavior, 164, 213 benchmark, 236, 391, 397 Berners-Lee, Tim, 218 best practices, 3 bezierCurveTo method, 292 big ball of mud, 167, 168 binary data, 3, 11, 358 binary numbers, 11, 12, 68, 133, 153, 324 binary operator, 13, 16, 23 binding assignment, 25, 44 compilation of, 215, 403 definition, 24, 41, 215, 417 destructuring, 76 in Egg, 210, 212 exported, 173 global, 43, 130, 285, 354, 355 local, 43 model of, 25, 63, 65 naming, 26, 35, 52, 75, 131 from parameter, 42, 49 scope of, 43 as state, 31, 33, 65, 160, 326 undefined, 138 visibility, 43 bitfield, 255 bitmap graphics, 295, 308 bits, 3, 11, 12, 16, 68 block, 29, 32, 42, 43, 46, 63, 136, 137, 204 block comment, 36, 156 block element, 235, 237–238 blocking, 182, 241, 260, 359 blur event, 257–258 blur method, 319 body (HTML tag), 222–223, 228 body (HTTP), 313–315, 360, 366, 367, 378 body property, 228, 229, 231, 316 bold, 237 Book of Programming, The, 10, 352 Boolean, 16, 28, 31, 65, 146, 209, 210 conversion to, 19, 28, 31 Boolean function, 28 border (CSS), 235, 237 border-radius (CSS), 253 bouncing, 267, 270, 278, 280, 308 boundary, 151, 153, 157, 161, 164, 302, 413 bounds, of ranges, 88 box, 142, 227, 266, 308, 421 box shadow (CSS), 275 br (HTML tag), 340, 422 braces block, 4, 29, 42 class, 102 function body, 46, 63, 408 object, 66, 76, 85 in regular expression, 148 branching, 152, 153 branching recursion, 50, 300 break keyword, 33, 35 breakpoint, 134 British English, 148 broadcastConnections function, 193 browser, 2, 5, 174, 183, 219–225, 266, 267, 308, 313, 316, 321, 344, 348, 372 environment, 7, 26, 27, 311 security, 317, 392 storage, 326–328 window, 248 browser wars, 225 bubbling, see event propagation Buffer class, 358, 359, 361, 362 bug, 83, 129, 133, 157, 159, 164, 168, 225 building Promise.all (exercise), 200, 416 bundlers, 174 button, 247, 313, 320, 330 button (HTML tag), 224, 248, 252, 262, 321, 327, 330, 337 button property, 249, 255, 338 buttons property, 255, 338 C C (programming language), 391 cache, 172, 184 call method, 99, 104 call protocol, 400 call stack, 46–47, 51, 62, 135, 136, 138, 197, 400 callback functions, 184–190, 247, 283, 337, 358–359, 361, 380, 385 calling (of functions), see function application camel case, 35, 238 cancelAnimationFrame function, 260 canvas, 266, 287, 289–292, 295–301, 305–307, 395, 421 context, 289 path, 290 size, 288, 290 canvas (HTML tag), 288, 334, 337, 344, 345, 349, 423 CanvasDisplay class, 301, 302, 304 capitalization, 35, 101, 149, 238, 243, 362 capture group, 149–151, 155, 376 career, 265 caret character, 147, 151, 161, 358 carriage return, 161 cascading, 238 Cascading Style Sheets, see CSS case conversion, 62 case keyword, 35 case sensitivity, 149, 414 casual computing, 2 cat’s hat (exercise), 244 catch keyword, 135–136, 138–139, 141, 197, 413 catch method, 188 CD, 11 cell, 330 Celsius, 110 centering image on screen, 241 player in viewport, 276 certificate, 317 change event, 319, 322, 340, 422, 425 character, 14–15, 92–93, 322 character category, 163 character encoding, 358–359 characterCount function, 90 characterScript function, 94, 95, 411 charCodeAt method, 92 checkbox, 318, 323, 330, 422 checked attribute, 318, 323 chessboard (exercise), 38, 408 chicks function, 198–199 child node, 229, 230, 232 childNodes property, 230, 231, 233, 419 children property, 231 Chinese characters, 92, 94 choice, 152 Chrome, 225, 398, 400, 402, 404 circle, 241, 293 circle (SVG tag), 288 circles (exercise), 350, 423 circular dependency, 178, 415 circus, 71 class, 101, 102, 113, 119, 267, 335 class attribute, 232, 235, 239, 273, 275 class declaration, 102 class hierarchy, 112 className property, 235 cleaning up, after exceptions, 136 clearing, the canvas, 288, 296, 301, 302, 421 clearInterval function, 260 clearRect method, 296, 421 clearTimeout function, 259, 260 click event, 248, 250, 253, 255, 337, 422 client, 220, 316, 361, 372, 381, 382 clientHeight property, 235 clientWidth property, 235 clientX property, 253, 255, 339 clientY property, 253, 255, 339 clipboard, 225 clipping, 302 closePath method, 291 closing tag, 222, 224 closure, 49, 214, 417–419 closure in Egg (exercise), 214, 417 code, 6, 156, 265 structure of, 23, 32, 41, 167, 175 code golf, 164 code unit, 92 codePointAt method, 93 coin, 266, 267, 280, 305 Coin class, 271, 280 collaboration, 219 collection, 5, 60, 62, 64, 79 collision detection, 277, 278, 280–282, 420, 421 colon character, 18, 34, 63, 237 color, 288, 290, 302, 334, 346 color (CSS), 237, 238 color codes, 336 color field, 334, 336, 341 color picker, 334, 341, 344 color property, 335 ColorSelect class, 341 comma character, 204 COMMAND key, 252, 349 command line, 169, 353–355, 368 comment, 35, 77, 156, 160, 214, 229, 372, 374, 379, 384, 417 comment field reset (exercise), 388, 426 COMMENT_NODE code, 229 comments in Egg (exercise), 214, 417 CommonJS modules, 171–173, 355–356 exercise, 177–178, 415 communication, 220, 316 community, 354 compareRobots function, 125 comparison, 16, 19, 31, 35, 80 deep, 210, 409 of NaN, 17 of numbers, 16, 27 of objects, 66 of strings, 16 of undefined values, 19 compatibility, 5, 219, 225, 350, 357 compilation, 174, 212, 213, 391, 392, 398, 400, 403, 417 complexity, 3, 83, 112, 154, 239, 272, 349 component, 334, 335, 340, 346 composability, 5, 91, 175 computed property, 61, 328 computers, 1, 2 concat method, 72, 95, 413, 418, 426 concatenation, 15, 72, 418 conditional execution, 18, 28, 34, 37, 209 conditional operator, 18, 20, 209 conditional request, 374 configuration, 160 connected graph, 125 connection, 220, 311, 317, 372, 373 connections binding, 192 consistency, 35, 219, 230 console.log function, 5, 8, 16, 27, 46, 48, 55, 133, 354, 362–363, 398 const keyword, 25–26, 43, 65, 75, 76 constants, 26, 75, 282 constructor, 35, 101, 102, 112, 126, 130, 136, 150, 157, 411, 413 content negotiation (exercise), 329, 422 Content-Length header, 313 Content-Type header, 313, 360, 365, 369 context, 289 context menu, 251 continuation, 184 continue keyword, 33 control, 339, 341, 344, 347 control flow asynchronous, 182, 196 conditional, 28–30 exceptions, 135, 136 function, 46, 86 loop, 30–31, 32–33 control point, 292, 293 convention, 35 convergent evolution, 184 Conway’s Game of Life, 330 coordinates, 113, 241–242, 253, 273, 276, 278, 279, 289, 293, 298 copy-paste programming, 53, 168 copyright, 169 correlation, 66, 67, 69, 70 corvid, 183 cosine, 75, 241 countBy function, 93, 95 counter variable, 30, 32, 242, 408, 409, 416, 418 CPU, 182 crash, 138, 140, 378, 387 createElement method, 234, 336, 417 createReadStream function, 362, 365 createServer function, 360, 362, 375, 376 createTextNode method, 233, 422 createWriteStream function, 361, 367 cross-domain request, 316 crow, 183, 184, 188, 194 crow-tech module, 185 crying, 149 cryptography, 317 CSS, 237–239, 273–277, 287, 290, 336, 382 CTRL key, 252, 349 ctrlKey property, 252, 349 curl program, 367 curly braces, see braces cursor, 322 curve, 292–293 cutting point, 272 cwd function, 364–365 cycle, 229 D Dark Blue (game), 265 data, 2, 11, 59 data attribute, 235, 262 data event, 362 data flow, 334, 349 data format, 77, 230 data loss, 387 data set, 68, 87 data structure, 59, 175, 177, 306, 330 collection, 60 immutable, 120 list, 79 map, 104 stack, 62 tree, 204, 227, 229 data URL, 344–345 date, 147, 148, 150 Date class, 150, 151, 169, 171 date-names package, 171 Date.now function, 151, 346, 405 dblclick event, 253 De Morgan’s laws, 411 debouncing, 260 debugger statement, 134 debugging, 6, 129–131, 133, 136, 139, 140, 164 decentralization, 219 decimal number, 11, 133, 153 declaration, 237 decodeURIComponent function, 314, 364, 376 deep comparison, 66, 80 deep comparison (exercise), 80, 410 default behavior, 237, 251 default export, 173 default keyword, 35 default value, 20, 48, 290, 328, 348 defineProperty function, 411 defineRequestType function, 185, 190 degree, 293, 298 delete method, 113 DELETE method, 312–313, 315, 363, 366, 378 delete operator, 63 deoptimization, 401, 403, 404 dependence, 66 dependency, 168, 170, 173, 178, 224, 357 deserialization, 77 design, 168 destructuring, 151 destructuring assignment, 424 destructuring binding, 76, 171, 348, 415 developer tools, 7, 27, 134, 138 dialect, 174 dialog box, 26 diamond, 307, 420 digit, 11, 12, 133, 147–149, 336 Dijkstra, Edsger, 116, 176 Dijkstra’s algorithm, 176 dijkstrajs package, 176, 414 dimensions, 113, 235, 265, 267, 278, 289, 401, 408 dinosaur, 213 direct child node, 239 direction (writing), 95 directory, 355, 358–359, 363, 365–366, 368, 425 directory creation (exercise), 368, 425 disabled attribute, 320 discretization, 266, 278, 283 dispatch, 34, 334–336, 340, 347, 375, 423 display, 272, 273, 283, 284, 301, 305, 306 display (CSS), 237, 262 distance, 396, 423 distribution, 392 division, 13, 14, 396 division by zero, 14 do loop, 31, 122 doctype, 222–223 document, 221, 227, 258, 287 document format, 317, 329 Document Object Model, see DOM documentation, 353 documentElement property, 228, 229 dollar sign, 26, 151, 155, 161 DOM, 228, 229 attributes, 235 components, 334 construction, 230, 232, 234, 336 events, 248, 252 fields, 318, 322 graphics, 266, 267, 273–276, 287, 288, 305 interface, 229–230 modification, 232–233 querying, 231–232, 239 tree, 229 dom property, 335 domain, 221, 313, 316, 327 domain-specific language, 84, 132, 145, 214, 239 DOMDisplay class, 273, 301 dominant direction (exercise), 95, 411 done property, 346 doneAt property, 346 dot character, see period character double-click, 253 double-quote character, 14, 165, 204, 223 download, 7, 169, 344, 356, 367, 371, 387 download attribute, 344 draggable bar example, 254 dragging, 254, 334, 342, 350 draw function, 342, 350 drawGraph function, 395 drawImage method, 295–296, 298, 301, 303, 421 drawing, 227, 235, 236, 241, 272, 273, 288, 289, 292, 299, 303, 305, 333, 334, 422 drawing program example, 253, 333 drawPicture function, 338, 344, 350, 423 drop-down menu, 319, 324 duplication, 168 dynamic typing, 403 E ECMAScript, 5, 6, 173 ECMAScript 6, 6, 426 economic factors, 349 ecstatic package, 376 Edge, 398, 400, 402 editor, 32 efficiency, 50, 79, 91, 192, 212, 236, 266, 275, 289, 338, 349 efficient drawing (exercise), 349, 423 Egg language, 203, 215, 229 electronic life, 266 elegance, 50, 205 element, 222, 229, 231, 234 ELEMENT_NODE code, 229, 418 elements property, 320 ellipse, 240, 242 else keyword, 29 elt function, 234, 336, 349, 384 email, 317 emoji, 15, 92, 162, 262 empty set, 156 encapsulation, 97, 98, 105, 112, 248, 272 encodeURIComponent function, 314, 373–374, 383 encoding, 220 encryption, 317 end event, 362 end method, 360, 361, 364 enemies example, 160 engine, 391, 398, 400, 402 engineering, 225 ENOENT (status code), 365 ENTER key, 321 entity, 223 enum (reserved word), 26 environment, 26, 208 equality, 17 error, 92, 129, 130, 133–135, 138, 139, 187, 188, 194 error event, 326, 367 error handling, 129, 135, 138, 359, 364, 365, 383, 386 error message, 207, 330 error recovery, 134 error response, 312, 364, 366 error tolerance, 223 Error type, 136, 138, 139, 365 ES modules, 173, 224 ESC key, 285 escaping in HTML, 222, 224 in regular expressions, 146, 147, 158 in strings, 14, 204 in URLs, 314, 364, 373–374, 376 Escher, M.C., 286 ETag header, 374, 380, 386 eval operator, 170 evaluate function, 207–208, 210 evaluation, 170, 207, 213 even numbers, 30, 56 event handling, 247–262, 266, 282, 284, 285, 295–296, 305, 321, 322, 337, 362, 419, 422 event loop, 197 event object, 249, 253, 255 event propagation, 249, 250, 257, 258 event type, 249 every method, 95 everything (exercise), 95, 411 everywhere function, 192 evolution, 145, 349, 357 exception handling, 135, 136, 138–142, 187, 188, 196, 197, 200, 416, 422 exception safety, 138 exec method, 149–150, 158, 160 execution order, 28, 45, 46 exercises, 2, 7, 37, 133 exit method, 354 expectation, 251 experiment, 3, 7, 164 exploit, 225 exponent, 13, 165, 414 exponentiation, 31, 33 export keyword, 173 exports object, 171–173, 356, 415 expression, 23, 24, 27, 31, 33, 44, 203, 204, 208 expressivity, 214 extension, 355 extraction, 150 F factorial function, 8 Fahrenheit, 110 fallthrough, 35 false, 16 farm example, 52, 54, 152 fetch function, 315, 329, 361, 383, 385, 425 field, 252, 313, 318, 320, 323, 326, 330, 334, 388 Fielding, Roy, 310 file, 168, 325, 426 access, 172, 174, 345, 358, 359 image, 333, 344 resource, 312, 313, 363, 365, 366 stream, 361 file extension, 365 file field, 318, 325 file format, 160 file reading, 325 file server, 381 file server example, 363, 365–369, 425 file size, 174 file system, 325, 358, 359, 363, 364, 425 File type, 325 FileReader class, 325, 326, 345 files property, 325 fill function, 343 fill method, 291, 336 fillColor property, 336 filling, 289–291, 295, 306 fillRect method, 289, 296 fillStyle property, 290, 295 fillText method, 295, 420 filter method, 88, 91, 94, 120, 191, 411, 413 finally keyword, 137, 142, 413 findIndex method, 94 findInStorage function, 194, 195 findRoute function, 124, 193 finish event, 367 Firefox, 225, 398, 400, 402, 404 firewall, 372 firstChild property, 230 fixed positioning, 257 fixing scope (exercise), 215, 417 FizzBuzz (exercise), 37, 407 flattening (exercise), 95 flexibility, 6 flipHorizontally function, 304, 420 flipHorizontally method, 298 flipping, 297–298 floating-point number, 12–13 flood fill, 340, 343 flooding, 192 flow diagram, 152, 153 focus, 252, 257, 319, 320, 322, 323, 349, 388 focus event, 257–258 focus method, 319 fold, see reduce method font, 295 font-family (CSS), 238 font-size (CSS), 262 font-weight (CSS), 238 for attribute, 323 for loop, 32, 33, 69, 85, 95, 139, 397, 409, 410 for/of loop, 69, 93, 106, 107, 109, 398, 412 force, 393–398 force-directed graph layout, 393 forceDirected_noRepeat function, 397 forceDirected_noVector function, 401 forceDirected_simple function, 396 forceDirected_skip function, 398 forEach method, 87 form, 313, 314, 320, 321, 369 form (HTML tag), 318, 320, 385, 425 form property, 320 formatDate module, 171, 173 fractal example, 300 fractional numbers, 13, 165, 266 fragmentation, 402 frame, 296, 297, 303, 421 framework, 54, 334 frequency table, 67 fs package, 358, 359 Fuller, Margaret, 370 function, 5, 26, 41, 45, 130, 203, 204, 211 application, 26, 27, 42, 46, 47, 50, 74, 88, 138, 203, 208 body, 42, 46 callback, see callback function declaration, 45 definition, 41, 45, 52 higher-order, 45, 85, 86, 88, 89, 91, 155, 283 inlining, 400 model of, 49 naming, 52–54 as property, 62 purity, 55 scope, 44, 169, 214 as value, 42, 44, 48, 85, 86, 88, 249, 283, 419 Function constructor, 170, 172, 210, 213, 330, 422 function keyword, 42, 45 Function prototype, 100, 103 future, of JavaScript, 6, 26, 45, 308 G game, 265–267, 282, 284, 285, 301 with canvas, 305 screenshot, 277, 305 game of life (exercise), 330, 422 GAME_LEVELS data set, 284 garbage collection, 12, 400–403 garble example, 355 gardening, 371 gaudy home pages, 262 generation, 330, 422 generational garbage collection, 403 generator, 196 get method, 105 GET method, 312, 313, 315, 321, 361, 363, 365, 373, 377–378 getAttribute method, 235 getBoundingClientRect method, 236, 339 getContext method, 289 getDate method, 151 getElementById method, 232, 417 getElementsByClassName method, 232 getElementsByTagName method, 232, 233, 243, 418 getFullYear method, 151 getHours method, 151 getImageData method, 345, 346 getItem method, 326, 328 getMinutes method, 151 getMonth method, 151 getPrototypeOf function, 100, 101, 215, 417 getSeconds method, 151 getter, 109, 113, 270 getTime method, 150 getYear method, 151 GitHub, 312 global object, 130 global scope, 43, 170, 210, 259, 354, 355, 417 goalOrientedRobot function, 125 Google, 225 gossip property, 192 grammar, 23, 129, 160 graph, 118, 124, 176, 193, 306, 392, 394, 405 graph layout, 393, 394, 397, 398, 400 graphics, 266, 272, 275, 287–289, 295, 305, 306 GraphNode class, 394, 400 grave accent, see backtick gravity, 282 greater than, 16 greed, 156–157 grep, 368 grid, 266, 273, 278–279, 330, 422 Group class, 113, 114, 126, 197, 411, 412 groupBy function, 95 grouping, 13, 29, 149, 155, 413 groups (exercise), 113, 114, 411, 412 H h1 (HTML tag), 222, 235 hack, 173 handleAction function, 382 hard disk, 175, 181, 184 hard drive, 12, 325, 327, 353, 387 hard-coding, 231, 307 has method, 105, 113 hash mark character, 214, 336 hasOwnProperty method, 105, 215, 417 head (HTML tag), 222, 223, 228 head property, 228 header, 313, 316, 360, 373 headers property, 315, 316, 329 height property, 350, 423 help text example, 257 hexadecimal numbers, 153, 314, 336, 346 Hières-sur-Amby, 183 hidden element, 238, 262 higher-order functions, see function, higher-order history, 5, 349 historyUpdateState function, 346 Hoare, C.A.R., 82 Hooke’s law, 395 hooligan, 375 Host header, 313 hot code, 392 href attribute, 222, 232, 235 HTML, 221, 312, 326, 369 notation 221 structure 227 html (HTML tag), 223, 228 HTTP, 219–221, 311–317, 366, 367, 369, 373, client, 361, 367, 372 server, 360, 363, 375, 381 http package, 360–361 HTTPS, 221, 317, 361 https package, 361 human language, 23 Hypertext Markup Language, see HTML Hypertext Transfer Protocol, see HTTP hyphen character, 13, 147, 238 I id attribute, 232, 239, 323 idempotence, 189, 366, 425 identifier, 204 identity, 65 if keyword, 28, 162 chaining, 29, 34, 408 If-None-Match header, 374, 380, 385 image, 233, 258, 287, 313 imagination, 265 IME (input method editor), 252 img (HTML tag), 222, 233, 237, 258, 287, 295, 296, 345 immutable, 65, 120, 270, 335, 336, 342, 346, 423 implements (reserved word), 26 import keyword, 173 in operator, 64, 105 includes method, 68, 69, 399, 411 indentation, 32 index, 61 index property, 149 index.html file, 381 index.js file, 355 indexOf method, 71, 73, 94, 113, 146, 158, 411 infinite loop, 33, 47, 139, 409 infinity, 14 infrastructure, 169 inheritance, 100, 111–112, 139, 365 INI file, 160 ini package, 169, 173, 175, 356 initialization, 258 inline caching, 403, 404 inline element, 235, 237 inlining, 400 inner function, 44, 418 inner loop, 154 innerHeight property, 257 innerWidth property, 257 input, 134, 247, 266, 319, 353, 378 input (HTML tag), 257, 318, 322, 323, 325, 341, 345 input event, 322 insertBefore method, 232, 233 installation, 169 instance, 101 instanceof operator, 112, 139 instructions, 3, 391 integers, 13 integration, 145, 230 interface, 98 canvas, 287, 289 design, 54, 145, 150, 155, 158, 229, 230, 272, 290 HTTP, 316, 373 module, 168–172, 175, 315, 356 object, 105, 106, 109, 114, 126, 189, 269, 301, 322, 335 interface (reserved word), 26 internationalization, 162 internet, 160, 220, 221, 224 Internet Explorer, 225 interpolation, 15 interpretation, 7, 170, 207–208, 212, 391 interview question, 37 inversion, 147 invoking (of functions), see function application IP address, 221, 311, 313 isDirectory method, 366, 425 isEven (exercise), 56, 408 isolation, 97, 167, 170, 224 iterable interface, 107, 412 iterator, 196 iterator interface, 106, 107, 114, 398 J Jacques, the weresquirrel, 60 Java, 5 JavaScript, 5 availability of, 2 flexibility of, 6 history of, 5, 219 in HTML, 223 syntax, 23 uses of, 6 versions of, 6 weaknesses of, 6 JavaScript console, 7, 16, 27, 134, 138, 330, 354 JavaScript Object Notation, see JSON join method, 94, 104, 356 journal, 60, 62, 64, 66, 69 JOURNAL data set, 68 journalEvents function, 69 JSON, 77, 175, 184, 193, 315, 328, 373, 386, 425 json method, 315 JSON.parse function, 77, 426 JSON.stringify function, 77 JSX, 384 jump, 4 jump-and-run game, 265 jumping, 266, 282 just-in-time compilation, 392 K Kernighan, Brian, 128 key code, 282 key property, 252, 418, 423 keyboard, 26, 247, 251, 266, 281, 282, 285, 319, 320, 322, 349 keyboard bindings (exercise), 349, 423 keyboard focus, see focus keydown event, 251, 260, 282, 349, 418, 423 keyup event, 251, 282 keyword, 24, 26, 235 Khasekhemwy, 322 kill process, 360 Knuth, Donald, 40 L label, 295, 307 label (HTML tag), 323, 341 labeling, 323 landscape example, 44 Laozi, 180 lastChild property, 230 lastIndex property, 158–160 lastIndexOf method, 71 Last-Modified header, 313 latency, 174 lava, 266, 267, 275, 278, 280, 305 Lava class, 270, 280 layering, 194, 220 layout, 235–237 laziness, 236 Le Guin, Ursula K., 2 leaf node, 229 leak, 225, 285 learning, 2, 6, 371 left (CSS), 240–242, 244 LEGO, 168 length property for arrays, 61, 336 for strings, 53, 56, 61, 74, 409 less than, 16 let keyword, 24, 25, 43, 65, 75, 76, 130 level, 266, 267, 273, 275, 284 Level class, 267 lexical scoping, 44 library, 230, 334, 356, 357 license, 169 line, 24, 32, 161, 287, 289–294, 307, 420 line break, 14, 161 line comment, 35, 156 line drawing, 350, 424 line width, 290, 297 lines of code, 211 lineTo method, 290–291 lineWidth property, 290 link (HTML tag), 277 linked list, 79, 410, 426 links, 222, 230–231, 251, 252, 344 linter, 173 Liskov, Barbara, 96 list (exercise), 79, 410 listen method, 360 listening (TCP), 220, 360 literal expression, 23, 146, 206, 208 live data structure, 227, 233, 240, 419 live view, 372, 373, 387, 426 lives (exercise), 285 load event, 258, 295–296, 303, 326, 421 LoadButton class, 344 local binding, 48, 215, 409 local scope, 43, 212 localhost, 360 localStorage object, 326–327, 383 locked box (exercise), 141, 413 logging, 133 logical operators, 17 long polling, 372–374, 378, 380, 385 loop, 4, 30, 32, 37, 38, 50, 69, 85, 90, 91, 160, 189, 408, 409, 420 termination of, 33 loop body, 31, 85 lycanthropy, 60, 66 M machine code, 3, 213, 391 macro-optimization, 406 magic, 99, 203 mailRoute array, 123 maintenance, 169 malicious script, 224 man-in-the-middle, 317 map, 272, 321 map (data structure), 104 Map class, 105, 109, 195 map method, 88, 91, 94, 99, 104, 120, 191, 268, 340 Marcus Aurelius, 246 match method, 149, 159 matching, 146, 151, 152, 158, 164 algorithm, 152–154 Math object, 56, 61, 75 Math.abs function, 76, 424 Math.acos function, 75 Math.asin function, 75 Math.atan function, 75 Math.ceil function, 76, 278, 302–303 Math.cos function, 75, 241, 242, 421 mathematics, 50, 86 Math.floor, 76, 122, 278, 302–303 Math.max function, 27, 61, 74, 75, 302 Math.min function, 27, 56, 75, 302 Math.PI constant, 75, 293 Math.random function, 75, 122, 271, 330, 404 Math.round function, 76 Math.sin function, 75, 241, 242, 271, 281 Math.sqrt function, 68, 75, 411 Math.tan function, 75 Matrix class, 107–108, 335 matrix example, 107–108, 111 MatrixIterator class, 108 max-height (CSS), 275–276 maximum, 27, 75, 90 max-width (CSS), 275–276 McConnell, Steve, 390 Meadowfield, 117 measurement, 397 measuring, 399 measuring a robot (exercise), 125, 412 media type, 317, 329, 365 meetups, JavaScript, 371 memory, 3, 11 call stack, 24 organization, 12, 47, 60, 65, 77 persistence, 387 speed, 181, 213, 400, 402, 406 structure sharing, 79 mesh, 221 message event, 259 meta key, 252 metaKey property, 252, 349 method, 62, 100, 101 array, 71 HTTP, 312, 317, 360, 367, 373, 375 interface, 98 method attribute, 313 method call, 98 method property, 315 methods object, 363 micro-optimization, 397, 399, 406 Microsoft, 225 Middle East, graph of, 393 mime package, 365 MIME type, 329, 365 mini application, 326 minifiers, 175 minimalism, 265 minimum, 27, 56, 75 minimum (exercise), 56, 408 minus, 13, 165 Miró, Joan, 332 mirror, 298, 308, 421 mirroring, 297–298 MKCOL method, 368–369, 425 mkdir function, 368–369, 425 modification date, 366 modifier key, 252 modular robot (exercise), 177, 414 modularity, 97, 334 module, 168, 169, 177, 272, 355, 356, 375 design, 175 module loader, 355 module object, 172 module system, 169 modulo (remainder) operator, 14, 33, 297, 407, 408, 418, 420 Mongolian vowel separator, 162 monster (exercise), 285, 419 Mosaic, 225 motion, 266 mouse, 26 button, 249, 250, 253 cursor, 253 mouse trail (exercise), 262, 418 mousedown event, 250, 253, 255, 337, 338, 422 mousemove event, 254, 260–262, 338, 350, 418 mouseup event, 253–255 moveTo method, 290, 293 Mozilla, 225 multiple attribute, 324, 325 multiple-choice, 318–319, 323, 324 multiplication, 13, 269–270, 280 multiplier function, 49 music, 265 mutability, 63, 65, 120 N name attribute, 320, 324 namespace, 75 naming, 4, 5, 25–26 NaN (not a number), 14, 17, 18, 130 negation, 16, 17 neighbor, 330, 422 neighbors property, 190 nerd, 158 nesting of arrays, 67 of expressions, 23, 205 of functions, 44 of loops, 38, 408 of objects, 228, 231 in regular expressions, 154 of scope, 44 Netscape, 5, 225 network, 182, 219, 372 abstraction, 194, 316 protocol, 220 reliability, 188 security, 317 speed, 174, 181, 353 network function, 194 new operator, 101 newline character, 14, 38, 147, 156, 161, 268, 422 next method, 107, 197, 412 nextSibling property, 230 Nietzsche, Friedrich, 226 node, 228, 229 node program, 354 node-fetch package, 361 Node.js, 6, 7, 27, 171, 183, 353–369, 372, 373, 375, 387, 398 NodeList type, 230, 239 node_modules directory, 355, 356 nodeName property, 243 nodeType property, 229, 418, 419 nodeValue property, 231 nonbreaking space, 162 normalizing, 396 not a number (NaN), 14, 17, 18, 129 notation, 173 note-taking example, 327 notification, 372 NPM, 169, 171, 173, 174, 176, 177, 355–358, 365, 375, 376, 387, 415 npm program, 356, 357, 365 null, 18, 19, 51, 61, 77, 80, 134 number, 12, 65, 146, 165, 414 conversion to, 19, 28 notation, 12–13 precision of, 13 representation, 12 special values, 14 Number function, 28, 35 number puzzle example, 50–52 Number.isNaN function, 29 O object, 59, 63–65, 97, 112 creation, 77, 101, 328, 401, 403 identity, 65 as map, 272 as module, 169 mutability, 65 property, 27, 61, 75, 76, 99 representation, 77 Object prototype, 99, 100 object shape, 404 Object.assign function, 328, 336 Object.create function, 100, 104, 211 Object.keys function, 64, 80, 195, 410, 417 object-oriented programming, 97, 101, 105, 106, 111, 119, 175 Object.prototype, 104 observation, 399 obstacle, 277, 278 offsetHeight property, 235, 236 offsetWidth property, 235 on method, 362 onclick attribute, 224, 248 onclick property, 337 OpenGL, 289 opening tag, 222 operator, 13, 16, 19, 204, 210, 404 application, 13 optimization, 50, 55, 236, 260, 266, 275, 306, 308, 359, 392, 398–400, 403, 406, 426 option (HTML tag), 319, 324, 425 optional, in pattern, 148 optional arguments, 48, 78 options property, 324 ordering, 220 ordinal package, 171–172 organic growth, 167 organization, 167 outline, 289 output, 16, 26, 27, 133, 134, 211, 353, 422 overflow (CSS), 275–276 overflow, with numbers, 12 overlap, 278 overlay, 238 overriding, 103, 105, 111, 415 overwriting, 367, 369, 378 P p (HTML tag), 222, 235 package, 168, 171, 355, 357 package (reserved word), 26 package manager, 169 package.json file, 357 padding (CSS), 274 page reload, 258, 321, 326 pageX property, 253, 255 pageXOffset property, 236 pageY property, 253, 255 pageYOffset property, 236, 257 Palef, Thomas, 265 panning, 339 paragraph, 222 parallelism, 182, 313 parameter, 27, 42, 43, 46–48, 74, 76, 99, 131, 172 parent node, 249 parentheses arguments, 23, 41, 46, 85, 204 expression, 13 in regular expressions, 149, 151, 152, 162, 413 statement, 27, 29, 31, 33 parentNode property, 230 parse function, 207 parseApply function, 206 parseExpression function, 205 parseINI function, 161, 168 parsing, 77, 129, 161, 203–206, 208, 211, 223, 227, 364, 380 password, 317 password field, 318 path canvas, 290–293, 420 closing, 291 file system, 355, 363 URL, 312, 315, 363, 364, 373, 375 path package, 365 pathfinding, 123, 176, 193, 343 pathfinding (exercise), 405, 406, 426 patience, 350 pattern, 145–147, 157 pausing (exercise), 285, 419 pea soup, recipe analogy, 84 peanuts, in weresquirrel example, 70–71 percent sign, 314 percentage, 94, 257 performance, 154, 174, 212, 236, 266, 306, 359, 391, 393, 397, 399 period character, 27, 61, 74, 147, 156, 165, 336 persistence, 326, 372, 387, 425 persistent data structure, 119, 120, 126, 132, 335, 342, 346, 419 persistent group (exercise), 126 persistent map (exercise), 413 PGroup class, 126, 413 phase, 271, 281 phi coefficient, 66–68 phi function, 68, 76 phone, 252 physics, 277, 281, 393, 418 physics engine, 278 pi, 13, 75, 241, 271, 293 PI constant, 75, 242 pick function, 343 picture, 287, 288, 296, 306, 334, 346 Picture class, 335, 345 picture property, 335 PictureCanvas class, 337, 349 pictureFromImage function, 345 pie chart example, 294, 295, 307, 420 ping request, 190 pink, 336 pipe analogy, 220 pipe character, 152, 414 pipe method, 364, 367 pipeline, 175 pixel, 235, 242, 253, 267, 273, 288, 289, 295, 296, 302, 306, 308, 333, 335, 339, 342, 343, 345, 350, 423 pixel art, 296 PixelEditor class, 340, 347, 349 pizza, in weresquirrel example, 67 platform game, 265, 285 Plauger, P.J., 128 player, 265–267, 275, 278, 281, 284, 296, 303, 305 Player class, 270, 281 plus character, 13, 148, 165 pointer, 230 pointer events, 253–256, 337 pointerPosition function, 338 polling, 247 pollTalks function, 385 polymorphism, 105–106 pop method, 62, 71 Popper, Karl, 234 port, 220, 311, 360 pose, 296 position, of elements on screen, 236 position (CSS), 240, 244, 257, 266, 275 POST method, 313, 314, 321, 374 postMessage method, 259 power example, 42, 48, 50 precedence, 13, 17, 239 predicate function, 88, 92, 95 Prefer header, 374, 380, 385 premature optimization, 50 preventDefault method, 251, 256–258, 282, 321, 339, 423 previousSibling property, 230 primitiveMultiply (exercise), 141, 413 privacy, 225 private (reserved word), 26 private properties, 98, 141–142 process object, 354–355, 364–365 processor, 181, 400 profiling, 50, 399 program, 2, 23, 28 program size, 83, 84, 164, 272 programming, 1 difficulty of, 2 history of, 3 joy of, 1, 2 Programming Is Terrible, 166 programming language, 1–2 creating, 203, 213 DOM, 229 history of, 3 machine language and, 391 Node.js and, 354 power of, 5 programming style, 3, 24, 32, 35, 272 progress bar, 256 project chapter, 117, 203, 265, 333, 371 promise, 200, 416 Promise class, 186, 187, 189, 195, 197, 198, 200, 315, 326, 359, 361, 363, 386, 416 Promise.all function, 190, 199, 200, 416 Promise.reject function, 187 Promise.resolve function, 186, 190 promises package, 359 promptDirection function, 139 promptInteger function, 134 propagation, of events, 249, 250, 257, 258 proper lines (exercise), 350, 424 property access, 27, 61, 129, 348, 403 assignment, 63 definition, 63, 66, 109 deletion, 63, 98 inheritance, 99, 101, 103 model of, 63 naming, 105–107 testing for, 64 protected (reserved word), 26 protocol, 220, 221, 311–312 prototype, 99–104, 111, 211, 215, 417, 426 diagram, 103 prototype property, 101 pseudorandom numbers, 75 public (reserved word), 26 public properties, 98 public space (exercise), 369, 425 publishing (packages), 358 punch card, 3 pure function, 55, 79, 88, 175, 330, 422 push method, 62, 69, 71, 411, 426 pushing data, 372 PUT method, 312–313, 363, 367, 373, 378, 425 Pythagorean theorem, 411, 423 Python, 391 Q quadratic curve, 292 quadraticCurveTo method, 292, 420 query string, 314, 374, 380 querySelector method, 240, 417 querySelectorAll method, 239, 324 question mark, 18, 148, 157, 314 queue, 198 quotation mark, 14, 165 quoting in JSON, 77 of object properties, 63 quoting style (exercise), 165, 413 R rabbit example, 98, 100–102 radians, 242, 293, 298 radio buttons, 318, 323 radius, 350, 423 radix, 11 raising (exceptions), 135 random numbers, 75, 271 random-item package, 414 randomPick function, 122 randomRobot function, 122 range, 88, 147, 148 range function, 5, 78, 409 Range header, 316 ray tracer, 306 readability, 4, 5, 35, 50, 54, 135, 167, 208, 276, 307 readable stream, 361, 362, 364, 378 readAsDataURL method, 345 readAsText method, 326 readdir function, 359, 366, 425 readdirSync function, 425 read-eval-print loop, 354 readFile function, 172, 358, 425 readFileSync function, 359, 424 reading code, 6, 117 readStorage function, 184 readStream function, 378, 379 real-time events, 247 reasoning, 17 recipe analogy, 84 record, 62 rect (SVG tag), 288 rectangle, 266, 278, 289, 307, 342 rectangle function, 342, 423 recursion, 47, 50, 56, 80, 189, 195, 205, 206, 208, 231, 243, 300, 394, 408, 410, 413, 416, 418 reduce method, 89, 91, 94, 95, 340, 411 redundancy, 397 ReferenceError type, 215 RegExp class, 146, 157, 424 regexp golf (exercise), 164 regular expressions, 145–165, 206, 368, 375, 376, 417, 424 alternatives, 152 backtracking, 153 boundary, 151 creation, 146, 157 escaping, 146, 158, 414 flags, 149, 155, 157, 414 global, 155, 158, 159 grouping, 149, 155 internationalization, 162 matching, 152, 158 methods, 146, 150, 158 repetition, 148 rejecting (a promise), 187, 189, 198 relative path, 172, 224, 355, 363, 425 relative positioning, 240, 241 relative URL, 315 remainder (modulo) operator, 14, 33, 297, 407, 408, 418, 420 remote access, 363 remote procedure call, 316 removeChild method, 232 removeEventListener method, 248, 419 removeItem method, 326 rename function, 359 rendering, 289 renderTalk function, 384 renderTalkForm function, 385 renderUserField function, 383 repeat method, 73, 257 repeating key, 251 repetition, 52, 148, 154, 157, 260 replace method, 155, 165, 413 replaceChild method, 233, 418 replaceSelection function, 322 reportError function, 383 repulsion, 393, 395 request, 185, 189, 220, 312, 313, 321, 360, 361, 367, 372 request function, 189, 361, 362 request type, 185 requestAnimationFrame function, 241, 258, 260, 283, 308, 418 requestType function, 190 require function, 171, 172, 178, 355, 356, 365, 375 reserved words, 26 resolution, 172, 355 resolve function, 364 resolving (a promise), 186, 187, 189, 198 resource, 220, 221, 312, 313, 317, 363, 377 response, 185, 189, 312, 313, 316, 360, 364, 366 Response class, 315 responsiveness, 247, 353, rest parameters, 74 restore method, 299, 300 result property, 326 retry, 189 return keyword, 42, 47, 101, 196, 408, 411 return value, 27, 42, 134, 185, 410 reuse, 54, 112, 167–169, 356 reverse method, 79 reversing (exercise), 79, 409 rgb (CSS), 274 right-aligning, 243 rmdir function, 366, 368 roadGraph object, 118 roads array, 117 roads module (exercise), 177, 415 robot, 117, 119, 121, 123, 125, 177 robot efficiency (exercise), 125, 412 robustness, 373 root, 229 rotate method, 298, 300 rotation, 307, 420 rounding, 76, 134, 278, 279, 302, 424 router, 372, 375 Router class, 375, 376 routeRequest function, 194 routeRobot function, 123 routing, 192 rows, in tables, 243 Ruby, 391 rules (CSS), 238, 239 run function, 211 runAnimation function, 283, 285 runGame function, 284, 285 runLayout function, 396 runLevel function, 283, 285 running code, 7 runRobot function, 121, 412 run-time error, 132–134, 140, 417 Rust (programming language), 391 S Safari, 225 sandbox, 7, 59, 224, 227, 316 save method, 299, 300 SaveButton class, 344 scalar replacement of aggregates, 400, 402 scale constant, 337–339 scale method, 297, 299 scaling, 273, 296, 297, 303, 421 scalpel (exercise), 200, 416 scheduling, 197, 354 scientific notation, 13, 165 scope, 43, 44, 48, 168, 170–173, 208, 210, 214, 215, 417 script (HTML tag), 223, 224, 258 SCRIPTS data set, 87, 89, 92, 93, 95 scroll event, 256, 260 scrolling, 251, 256–257, 275–276, 282, 301 search method, 158 search problem, 124, 152, 154, 232, 368, 405 search tool (exercise), 368, 424 section, 161 Secure HTTP, 221, 317, 361 security, 224, 225, 316, 317, 325, 327, 364, 375 select (HTML tag), 319, 324, 327, 334, 340, 425 selected attribute, 324 selection, 322 selectionEnd property, 322 selectionStart property, 322 selector, 239 self-closing tag, 222 semantic versioning, 357 semicolon, 23, 24, 33, 237 send method, 185, 188 sendGossip function, 191 sep binding, 364–365 sequence, 148 serialization, 77 server, 220, 221, 311–313, 315, 316, 353, 360, 362, 363, 372, 375 session, 328 sessionStorage object, 328 set, 146, 147, 229 Set (data structure), 113, 126 Set class, 113, 126, 413 set method, 105 setAttribute method, 235, 337 setInterval function, 260, 296 setItem method, 326 setter, 110 setTimeout function, 184, 197, 259, 260, 380, 386 shape, 287, 290, 291, 293, 295, 307 shapes (exercise), 307, 420 shared property, 100, 103 SHIFT key, 252, 423 shift method, 71 shiftKey property, 252 short-circuit evaluation, 20, 51, 209, 411 SICP, 202 side effect, 24, 27, 34, 42, 54, 65, 79, 88, 159, 175, 199, 230, 232, 233, 236, 290, 299, 314, 334, 335 sign, 12, 165, 414 sign bit, 12 signal, 11 simplicity, 213 simulation, 119, 121, 265, 270, 330, 393, 418 sine, 75, 241, 271, 281 single-quote character, 14, 165, 224 singleton, 126 skill, 333 SkillShareApp class, 386 skill-sharing project, 371–373, 375, 381 skipSpace function, 206, 214 slash character, 13, 35–36, 146, 156, 315, 364, 425 slice method, 72, 73, 88, 233, 409, 416 slope, 424 sloppy programming, 261 smooth animation, 241 SMTP, 220 social factors, 349 socket, 372–373 some method, 92, 95, 191, 376, 426 sorting, 229 source property, 158 special form, 203, 208 special return value, 134, 135 specialForms object, 208 specificity, 239 speed, 1, 2, 308, 421 SpiderMonkey, 400 spiral, 307, 420 split method, 118, 268 spread, 74, 336 spread operator, 274 spring, 393, 395 sprite, 296, 303–304 spy, 256 square, 28 square brackets, 60, 61, 74, 76, 107, 147, 324, 328, 409 square example, 41–42, 45, 46 square root, 68, 75, 411 src attribute, 222, 224 stack, see call stack stack overflow, 47, 50, 56, 408 stack trace, 136 staged compilation, 392 standard, 5, 26, 35, 88, 136, 162, 349, 354, 355 standard environment, 26 standard output, 354, 362–363 standards, 219, 225 star, 307, 420 Star Trek insignia, 292 startPixelEditor function, 347 startState constant, 347 startsWith method, 364 stat function, 359, 365, 366, 425 state of application, 275, 334, 342, 346, 347, 388 in binding, 24, 31, 32, 34, 400 of canvas, 289, 299 in iterator, 197 in objects, 119, 268, 301 transitions, 198, 336, 337 statement, 23, 24, 28, 31, 32, 42, 63 static (reserved word), 26 static file, 373, 376 static method, 110, 113, 268, 413 static typing, 403 Stats type, 366 statSync function, 425 status code, 312, 354–355 status property, 315, 383 stdout property, 362–363 stopPropagation method, 250 storage function, 187 stream, 220, 361–363, 364, 367, 378 strict mode, 130 string, 14, 60, 62, 65, 92 indexing, 56, 72, 74, 92, 149 length, 37, 92 methods, 73, 149 notation, 14 properties, 72 representation, 15 searching, 73 String function, 28, 105 stroke method, 290–292 strokeRect method, 289, 421 strokeStyle property, 290 strokeText method, 295 stroking, 289, 290, 295, 306 strong (HTML tag), 235, 237 structure, 168, 222, 227, 334 Structure and Interpretation of Computer Programs, 202 structure sharing, 79 style, 237 style (HTML tag), 238, 239 style attribute, 237–239, 273 style sheet, see CSS subclass, 111 submit, 318, 320, 321 submit event, 321, 384, 425 substitution, 54 subtraction, 13, 113 sum function, 5, 78 summing (exercise), 78, 409 summing example, 4, 83, 89, 211 superclass, 111 survey, 294 Sussman, Gerald, 202 SVG, 287–289, 305, 306 swapping bindings, 424 swipe, 342 switch keyword, 34 symbiotic relationship, 183 symbol, 106 Symbol function, 106 Symbol.iterator symbol, 107 SymmetricMatrix class, 111 synchronization, 387, 426 synchronous programming, 182, 195, 359, 368 syncState method, 335, 338, 340, 341, 349, 426 syntax of Egg, 203, 204 error, 26, 129, 130 expression, 23 function, 42, 45 identifier, 26 number, 12, 165 object, 63 operator, 13 statement, 24, 26, 28–34, 135 string, 14 syntax tree, 204–205, 207, 228–229 SyntaxError type, 206 T tab character, 14, 32 TAB key, 320 tabbed interface (exercise), 262, 419 tabindex attribute, 252, 320, 349 table (HTML tag), 243, 266, 274, 422 table example, 417 tableFor function, 68 tables, 67, 68, 274 tags, 221–222, 227, 239, see also names of specific tags talk, 371, 372, 377–379 talkResponse method, 380 talksAbout function, 231 talkURL function, 383 Tamil, 87 tampering, 317 tangent, 75 target property, 250 task management example, 71 TCP, 220, 221, 311, 373 td (HTML tag), 243, 274 Tef, 166 temperature example, 110 template, 171, 388, 426 template literals, 15 tentacle (analogy), 25, 63, 65 terminal, 354 termite, 183 ternary operator, 18, 20, 209 test method, 146 test runners, 132 test suites, 132 testing, 125, 132 text, 14, 221, 222, 227, 229, 295, 305–307, 322, 324, 358, 422 text field, 257, 318, 319, 322 text method, 315 text node, 229, 231, 233, 419 text wrapping, 305 text-align (CSS), 243 textAlign property, 295, 420 textarea (HTML tag), 260, 318, 322, 327, 330, 425 textBaseline property, 295, 420 textContent property, 418, 422 TEXT_NODE code, 229, 419 textScripts function, 94, 411 th (HTML tag), 243 then method, 186–188, 191, 416 theory, 133 this binding, 62, 98–99, 101, 130 thread, 182, 183, 198, 259 throw keyword, 135, 136, 139, 141, 413 tile, 303 time, 147, 148, 150, 184, 241, 261, 277, 278, 280, 283, 303, 346 time zone, 150 timeline, 182, 197, 223, 241, 247, 258 timeout, 188, 259, 373, 374, 380 Timeout class, 189 times method, 269 timing, 396 title, 382 title (HTML tag), 222, 223 toDataURL method, 344 toLowerCase method, 62, 243 tool, 145, 164, 175, 334, 339, 340, 342–344, 347, 350, 357 tool property, 335 ToolSelect class, 340 top (CSS), 240–242, 244 top-level scope, see global scope toString method, 99, 100, 103–105, 346, 362 touch, 255, 334 touchend event, 255 touches method, 278 touches property, 255, 339 touchmove event, 255, 339, 350 touchstart event, 255, 337, 339 toUpperCase method, 62, 132, 243, 362 tr (HTML tag), 243, 274 trackKeys function, 282, 285 transform (CSS), 287 transformation, 297–299, 308, 420 translate method, 298, 299 Transmission Control Protocol, 220, 221, 311, 373 transparency, 289, 296, 346 transpilation, 213 trapezoid, 307, 420 traversal, 152 tree, 100, 204, 229 treeGraph function, 394 trial and error, 133, 282, 293 triangle (exercise), 37, 407 trigonometry, 75, 241 trim method, 73, 268 true, 16 trust, 224 try keyword, 136, 137, 190, 413, 422 type, 12, 16, 112 type attribute, 318, 321 type checking, 131, 174 type coercion, 18, 19, 28 type observation, 392, 401, 403 type property, 204, 249 type variable, 131 typeof operator, 16, 80, 410 TypeScript, 131–132 typing, 260 typo, 129 U Ullman, Ellen, xx unary operator, 16, 23 uncaught exception, 138, 188 undefined, 18, 19, 25, 42, 47, 61, 63, 77, 129, 130, 134 underline, 237 underscore character, 26, 35, 98, 151, 157 undo history, 346, 347 UndoButton class, 347 Unicode, 15, 17, 87, 92, 147, 162, 163 unicycling, 371 Uniform Resource Locator, see URL uniformity, 204 uniqueness, 239 unit (CSS), 242, 257 Unix, 366–368 Unix time, 150 unlink function, 359, 366 unshift method, 71 unwinding the stack, 135 upcasing server example, 362 updated method, 378, 381, 425 updateState function, 336 upgrading, 169 upload, 325 URL, 221, 224, 288, 313, 315, 317, 360, 373, 383 URL encoding, 314 url package, 364, 380 urlToPath function, 364 usability, 251 use strict, 130 user experience, 247, 320, 372, 383 user interface, 138, 334 users’ group, 371 UTF-8, 358, 359 UTF-16, 15, 92 V V8, 398 validation, 134, 140, 203, 277, 321, 378, 379 value, 12, 186 value attribute, 318, 322, 324 var keyword, 25, 43, 76 variables, see also binding Vec class, 113, 268, 269, 280, 394, 396, 421 vector, 394, 400 vector (exercise), 113, 411 vector graphics, 295 verbosity, 46, 182 version, 169, 222, 312, 357, 398 viewport, 275–277, 301, 302, 305 VillageState class, 119 virtual keyboard, 252 virtual world, 117, 119, 121 virus, 224 vocabulary, 41, 84 void operator, 26 volatile data storage, 12 W waitForChanges method, 380 waiting, 184 walking, 303 warning, 357 wave, 271, 280, 281 web, see World Wide Web web application, 5, 326, 333 web browser, see browser web page, 174 web worker, 259 WebDAV, 369 webgl (canvas context), 289 website, 224, 225, 313, 353, 369, 371 WebSockets, 373 weekDay module, 169–170 weekend project, 369 weresquirrel example, 60, 62, 64, 66, 69, 71 while loop, 4, 30, 32, 53, 160 whitespace in HTML, 231, 340, 419 indentation, 32 matching, 147, 162 syntax, 204, 206, 214, 417 trimming, 73, 268 in URLs, 373–374 Why’s (Poignant) Guide to Ruby, 22 width property, 350, 423 window, 250, 255, 258 window object, 248 with statement, 131 word boundary, 151 word character, 147, 151, 162 work list, 124, 343 workbench (exercise), 330, 422 world, of a game, 265 World Wide Web, 5, 77, 219, 221, 224, 225, 311 writable stream, 360–363, 364 write method, 360, 361 writeFile function, 359, 361, 425 writeHead method, 360 writing code, 6, 117 writing system, 87 WWW, see World Wide Web X XML, 230, 288 XML namespace, 288 xmlns attribute, 288 Y yield (reserved word), 26 yield keyword, 197 your own loop (example), 95 Yuan-Ma, 10, 352 Z Zawinski, Jamie, 144 zero-based counting, 56, 61, 150 zeroPad function, 54 zigzag shape, 420 zooming, 305 Eloquent JavaScript, 3rd Edition is set in New Baskerville, Futura, Dogma, and TheSansMono Condensed.

ZeroMQ
by Pieter Hintjens
Published 12 Mar 2013

The goal of MOPED is to define a process by which we can take a rough use case for a new distributed application, and go from “Hello World” to fully working prototype in any language in under a week. Using MOPED, you grow, more than build, a working ØMQ architecture from the ground up with minimal risk of failure. By focusing on the contracts rather than the implementations, you avoid the risk of premature optimization. By driving the design process through ultra-short test-based cycles, you can be more certain that what you have works before you add more. We can turn this into five real steps: Internalize the ØMQ semantics. Draw a rough architecture. Decide on the contracts. Make a minimal end-to-end solution.

The C++ Programming Language
by Bjarne Stroustrup
Published 2 Jan 1986

All rights reserved. 107 ________________________________________ ________________________________________________________________________________________________________________________________________________________________ 6 ________________________________________ ________________________________________________________________________________________________________________________________________________________________ Expressions and Statements Premature optimization is the root of all evil. – D. Knuth On the other hand, we cannot ignore efficiency. – Jon Bentley Desk calculator example — input — command line arguments — expression summary — logical and relational operators — increment and decrement — free store — explicit type conversion — statement summary — declarations — selection statements — declarations in conditions — iteration statements — the infamous ggoottoo — comments and indentation — advice — exercises. 6.1 A Desk Calculator [expr.calculator] Statements and expressions are introduced by presenting a desk calculator program that provides the four standard arithmetic operations as infix operators on floating-point numbers.

…

If a ‘‘maintenance crew’’ is left guessing about the architecture of the system or must deduce the purpose of system components from their implementation, the structure of a system can deteriorate rapidly under the impact of local patches. Documentation is typically much better at conveying details than in helping new people to understand key ideas and principles. 23.4.7 Efficiency [design.efficiency] Donald Knuth observed that ‘‘premature optimization is the root of all evil.’’ Some people have learned that lesson all too well and consider all concern for efficiency evil. On the contrary, efficiency must be kept in mind throughout the design and implementation effort. However, that does not mean the designer should be concerned with micro-efficiencies, but that first-order efficiency issues must be considered.

Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design
by Diomidis Spinellis and Georgios Gousios
Published 30 Dec 2008

An interpreter for a smaller set will be smaller in code and footprint, and therefore will execute each of its operations much faster, but conversely it has a larger set to execute. So we are looking for a reasonable balance of set size against code length in order to get a near-optimal performance out of the interpreter. In finding the optimal point for both of these trade-offs, it is important to keep Hoare’s Dictum[47] in the back of your mind: Premature optimization is the root of all evil. —C. A. R. Hoare The precise sweet spot for lots of these optimizations will be system-dependent. In a Java environment, the system includes not only the physical hardware but also the JVM. With the added factor that the Java component of the environment is invariably just-in-time compiled, small scoped performance benchmarks are notoriously unreliable.

Pro AngularJS
by Adam Freeman
Published 25 Mar 2014

Finally, I would have used the $animate service, which I describe in Chapter 23, to display short, focused animations to ease the transition from one view to another when the URL path changes. 186 Chapter 8 ■ SportsStore: Orders and Administration AVOIDING OPTIMIZATION PITFALLS You will notice that I say that I could consider reusing the category and pagination data, not that I would definitely do so. That’s because any kind of optimization should be carefully assessed to ensure it is sensible and that it avoids two main pitfalls that dog optimization efforts. The first pitfall is premature optimization, which is where a developer sees an opportunity to optimize an operation or task before the current implementation causes any problems or breaks a contract in the nonfunctional specification. This kind of optimization tends to make code more specific in its nature that it would otherwise be, and that can kill the easy movement of functionality from one component to another that is typical of AngularJS (and is one of the most enjoyable aspects of AngularJS development).

The Architecture of Open Source Applications
by Amy Brown and Greg Wilson
Published 24 May 2011

I have run into many bottlenecks along the way but each time I look for improvements in design rather than speed-ups in performance. I have been asked many times why I wrote Graphite in Python rather than Java or C++, and my response is always that I have yet to come across a true need for the performance that another language could offer. In [Knu74], Donald Knuth famously said that premature optimization is the root of all evil. As long as we assume that our code will continue to evolve in non-trivial ways then all optimization6 is in some sense premature. One of Graphite's greatest strengths and greatest weaknesses is the fact that very little of it was actually "designed" in the traditional sense.

Clojure Programming
by Chas Emerick , Brian Carper and Christophe Grand
Published 15 Aug 2011

That’s an optimization and should only be taken on when absolutely necessary, especially given the costs associated with it: efficient field access ties code that uses it to a particular type, which often complicates the implementation of generic functionality and limits composability.[432] * * * [431] The canonical and up-to-date version of this flowchart is maintained at https://github.com/cemerick/clojure-type-selection-flowchart along with a number of translations, including Dutch, German, Japanese, Portuguese, and Spanish so far. [432] Recall that “premature optimization is the root of all evil.” Thank you, Professor Knuth. Chapter 19. Introducing Clojure into Your Workplace (or, Sneaking Clojure Past the Boss[433]) It is a sad fact that many programmers, if not the majority, use languages and tools every day that they begrudge. Either through historical accident, organizational inertia, or hard facts of the business, we often find ourselves stuck wishing we were using something, anything else to get our jobs done.

Solr in Action
by Trey Grainger and Timothy Potter
Published 14 Sep 2014

Technically an index-time boost is distributed (multiplied) into each term’s relevancy, which is somewhat different than using a function query against a popularity field, which is added to the overall score. Although it’s possible to construct your function queries in such a way as to mimic the index-time boost, in practice the additive boost will likely accomplish your desired outcome, so too much focus on this detail is likely a premature optimization until you discover a problem with this approach. Both the index-time document boost and the boosting of a document by a function on a popularity field are focused upon globally boosting a document’s relevancy versus all other documents. This might make sense for an e-commerce application in which certain products tend to sell better overall or for a news website where certain popular articles are trending.

Tools of Titans: The Tactics, Routines, and Habits of Billionaires, Icons, and World-Class Performers
by Timothy Ferriss
Published 6 Dec 2016

“Many, many people are working very hard, trying to save their money to retire so they can travel. Well, I decided to flip it around and travel when I was really young, when I had zero money. And I had experiences that, basically, even a billion dollars couldn’t have bought.” “You Don’t Want ‘Premature Optimization’” “I really recommend slack. ‘Productive’ is for your middle ages. When you’re young, you want to be prolific and make and do things, but you don’t want to measure them in terms of productivity. You want to measure them in terms of extreme performance, you want to measure them in extreme satisfaction.”

The Singularity Is Near: When Humans Transcend Biology
by Ray Kurzweil
Published 14 Jul 2005

We saw this in the railroad frenzy of the nineteenth century, which was followed by widespread bankruptcies. (I have some of these early unpaid railroad bonds in my collection of historical documents.) And we are still feeling the effects of the e-commerce and telecommunications busts of several years ago, which helped fuel a recession from which we are now recovering. AI experienced a similar premature optimism in the wake of programs such as the 1957 General Problem Solver created by Allen Newell, J. C. Shaw, and Herbert Simon, which was able to find proofs for theorems that had stumped mathematicians such as Bertrand Russell, and early programs from the MIT Artificial Intelligence Laboratory, which could answer SAT questions (such as analogies and story problems) at the level of college students.163 A rash of AI companies occurred in the 1970s, but when profits did not materialize there was an AI "bust" in the 1980s, which has become known as the "AI winter."

EuroTragedy: A Drama in Nine Acts
by Ashoka Mody
Published 7 May 2018

And the gains from mean reversion were blunted, in part, by hysteresis effects, the legacy of diminished skills and low investment due to extended underperformance during the long crisis.12 The recovery, therefore, was disappointing by historical standards. But it had been so long in coming and growth expectations had been set so low that it was easy for officials and commentators to hail the recovery as a significant step forward. The dangers of premature optimism were once again great, as was made clear with the unhelpful reaction of financial markets to comments by ECB President Mario Draghi. In June 2017, at the ECB’s annual conclave of central bankers in Sintra on the Portuguese Riviera, Draghi said, “All the signs now point to a strengthening and broadening recovery in the euro area.”