3 ms·

Having spent a great deal of time - most of my career, really, doing performance optimization, some of this rings true, but much of it doesn't. Rule 2 only app

Having spent a great deal of time - most of my career, really, doing performance optimization, some of this rings true, but much of it doesn't. Rule 2 only applies if you can just decide that your current level of performance is "pretty great" and then parachute away to another project. Otherwise if you find that, instead of 1 hot spot taking 80% of your time, you have 5 warm spots taking 16% of your time, you have 5x as much thinking to do to fix your problems and get that potential 4x speedup (assuming you could get cut that 80% down by a factor of 16). Rule 4 is an argument from bad implementation. It's harder to get fancy algorithms right, but what does it mean to say an algorithm is buggier than some other algorithm. Are we seriously meant to think that there are some bugs buried in Strassen's matrix multiply? Rule 3 is dubious. It seems to imply that the performance cost of fancy algorithms on low N matters, which assumes that we are actually executing the algorithm quite a bit. Perhaps we've picked the wrong fancy algorithm? Maybe if you have a godzillion tiny matrix multiplies you shouldn't be using Strassen's but you might still get a performance win from doing something 'fancy' that's tuned for large numbers of small matrix multiplies... As for Rule 5, this is probably the best of the lot. That's why I like to use languages that allow me to describe my data structures in detail... even going so far as to say that the contents of my user-built containers have types. Ahem.

vvanders 9y ago
So much this, there's nothing I dread so much as a "flat profile". These rules are great if you actually have a smoking gun, however if you're getting killed by random memory access patterns they rarely present that way.
hasenj 9y ago
Rule 5 is where dynamic languages usually utterly fail.
- vvanders 9y ago
  C# is one of the few ones to have value types, but yeah in general they really suck for controlling memory access patterns and layout.
- gavinpc 9y ago
  In twenty-five years as a working programmer, I have fallen in love with a piece of technology four times: Emacs (on my third attempt), Tup (the build system by Mike Shal), React... and now TypeScript. I've been using it full-time for a few weeks now, and I can't imagine going back. If you like rule 5... you'll heart TypeScript. Edit: I also spent ~12 years writing C# which is good. But TypeScript is actually more powerful in a way, because of the impossibility of typing everything. This means it's likely to get things like variadic generics or higher-kinded types long before C#, since (1) in C# everything has to be typed down to the smallest particle (so it's much harder to add features), and (2) changes to the CLR would be needed.
  - millstone 9y ago
    When you say "going back" - going back to what? I mean, is a language where all array keys are strings really the best platform for higher-kinded types?
    - gavinpc 9y ago
      Going back to untyped JS of course. It's not about having "the best" platform for types—that's just the point. TypeScript's system is incomplete, but it's plenty good enough to dramatically improve the experience. The tooling is now much more powerful. The type contracts also provide a whole new channel of formal communication between team members, not to mention unknown users if you're developing libraries. And it's just way more fun. It's a rewarding challenge to write the most expressive types that you can for the problem you're solving. But you don't have to. If you want to start by writing data types and then fulfilling them, you can. If you want to start by writing code and then typing it, you can. It's brilliantly designed to fit with all kinds of idiomatic JavaScript. The language server provides fast incremental compilation and integrates easily with all major editors. Structural typing means you can define types in-place and conform to interfaces that haven't been written yet. The type system's features are impressive and growing, including generics (with constraints and defaults), tagged unions, mapped types, guard conditions and flow control analysis. It's not "the best" of both worlds, but it is both worlds. What other language is as "gelatinous" as JavaScript [0] but still gives you state-of-the-art type inference when you want it? Hack? [1] I don't know, but it's the same value proposition. [0] https://news.ycombinator.com/item?id=13942674 https://news.ycombinator.com/item?id=13942674 [1] http://hacklang.org/ http://hacklang.org/
freyir 9y ago
In this context, a "buggier" algorithm is one that is more prone to bugs.
- glangdale 9y ago
  I can grasp the underlying point here (more code and more complex code both increase the chance you'll have a bug). Again, this seems a bit like the assumption behind Rule 2 - that the time spent in figuring out the complex algorithm and ensuring it is bug free is not worth spending (just like saying "oh, it's not worth smashing a hot spot if it's only 20%). This will frequently be true, but not always. I suspect that most people would be happier to use OS schedulers, TCP implementations and compilers (to name a few things) written by people who don't get to "parachute out" when the easy solutions are exhausted.

vvanders 9y ago

So much this, there's nothing I dread so much as a "flat profile". These rules are great if you actually have a smoking gun, however if you're getting killed by random memory access patterns they rarely present that way.

hasenj 9y ago

Rule 5 is where dynamic languages usually utterly fail.

vvanders 9y ago
C# is one of the few ones to have value types, but yeah in general they really suck for controlling memory access patterns and layout.
gavinpc 9y ago
In twenty-five years as a working programmer, I have fallen in love with a piece of technology four times: Emacs (on my third attempt), Tup (the build system by Mike Shal), React... and now TypeScript. I've been using it full-time for a few weeks now, and I can't imagine going back. If you like rule 5... you'll heart TypeScript. Edit: I also spent ~12 years writing C# which is good. But TypeScript is actually more powerful in a way, because of the impossibility of typing everything. This means it's likely to get things like variadic generics or higher-kinded types long before C#, since (1) in C# everything has to be typed down to the smallest particle (so it's much harder to add features), and (2) changes to the CLR would be needed.
- millstone 9y ago
  When you say "going back" - going back to what? I mean, is a language where all array keys are strings really the best platform for higher-kinded types?
  - gavinpc 9y ago
    Going back to untyped JS of course. It's not about having "the best" platform for types—that's just the point. TypeScript's system is incomplete, but it's plenty good enough to dramatically improve the experience. The tooling is now much more powerful. The type contracts also provide a whole new channel of formal communication between team members, not to mention unknown users if you're developing libraries. And it's just way more fun. It's a rewarding challenge to write the most expressive types that you can for the problem you're solving. But you don't have to. If you want to start by writing data types and then fulfilling them, you can. If you want to start by writing code and then typing it, you can. It's brilliantly designed to fit with all kinds of idiomatic JavaScript. The language server provides fast incremental compilation and integrates easily with all major editors. Structural typing means you can define types in-place and conform to interfaces that haven't been written yet. The type system's features are impressive and growing, including generics (with constraints and defaults), tagged unions, mapped types, guard conditions and flow control analysis. It's not "the best" of both worlds, but it is both worlds. What other language is as "gelatinous" as JavaScript [0] but still gives you state-of-the-art type inference when you want it? Hack? [1] I don't know, but it's the same value proposition. [0] https://news.ycombinator.com/item?id=13942674 https://news.ycombinator.com/item?id=13942674 [1] http://hacklang.org/ http://hacklang.org/

freyir 9y ago

In this context, a "buggier" algorithm is one that is more prone to bugs.

glangdale 9y ago
I can grasp the underlying point here (more code and more complex code both increase the chance you'll have a bug). Again, this seems a bit like the assumption behind Rule 2 - that the time spent in figuring out the complex algorithm and ensuring it is bug free is not worth spending (just like saying "oh, it's not worth smashing a hot spot if it's only 20%). This will frequently be true, but not always. I suspect that most people would be happier to use OS schedulers, TCP implementations and compilers (to name a few things) written by people who don't get to "parachute out" when the easy solutions are exhausted.