A British ComputerProgrammer?
working in the ComputerGamesIndustry
. Self-taught programmer, learned some mathematics at CambridgeUniversity
in between evenings at the bar.
Threads I am involved with:
Current email address: mailto:firstname.lastname@example.org
Can also be reached at: mailto:email@example.com
As you can see, having HowiLearnedToLoveObjects
as a separate page attracts attention, and encourages people to add their own stories.
Hope you enjoy Wiki, as many of the rest of us have!
As you say My Grok* pages are not patterns (yet), I will at some time, if no-one else does it first, fix them. In various places you indicate how bad it is to implement something other than the specification. First up the specification usually does not define everything (eg precision of computation). Secondly I expect that Xp encourages and endorses changing the spec frequently, that is why you have a user on site. The spec evolves as everyone learns what is really required. If we followed the rule OptimizeLater
then we are currently trying to implement the spec
Go FASTER. Tell me what it cost later
The specification for anything certainly does specify the precision, IF the precision matters. In fact, if the word "precision" is even meaningful in a given context, it probably matters. You obviously can't optimize a quantum physics simulation by making it so inaccurate the results are meaningless. In games, you can't reduce the precision of the colour calculations so far that the game becomes black and white! There is a precision specified, at least implicitly, and if we are to be professional about this we must make such specifications explicit. This need not mean "write a huge design document" - if you want to reduce precision for speed reasons, and your "user" is on site, you can run it by him first (and write a slower but less precise version to simulate). But you can't just unilaterally decide - as a programmer - that the application needs less precision than it already has.
Of course, if you UnitTest
well enough, dropping the precision will instantly break the tests. If you do it extremely well, you may even find that dropping the precision didn't break the tests so it is acceptable after all. But even there, the specification of the required precision exists - implicitly, in the tests. I hate implicit definitions!
When we have a better idea of what OptimizationPattern
s are - and what they are not - we can see if precision changes are acceptable. But this is interesting nonetheless. DesignPatterns
are not customer-visible, and some OptimizationPattern
s may be - you must ask the customer before you implement them. So OptimizationPattern
s of this nature belong at a logically higher level than DesignPatterns
. They might even be a part
, rather than just a tool.
You suggested that we refactor the optimization stuff, and we will, when I get back from skiing change jobs and get connected from home....
(in September, not at the start of it)
If you find you can't wait start without me. I can always unit test the pages later...
Seriously though, I think there is a way to express the grok stuff as a pattern
of the form
Problem: I wrote the code and the optimizer did XYZ when I wanted it to ABC
Explanation: The compiler did this because .... (usually aliasing in C)
Work around: write the code like this JKL then the optimizer will produce ABC.
Still needs more work to be in the form of a pattern.
There then would be another page that specified a methodology to go through when trying to make code go faster.
A bigger challenge would be to identify the patterns and the method that are generic and address the question how do we make algorithms faster?
PS. You are right when we finally understand one another, and trust one another
we will agree. At the moment you are scared that I don't grok usability. Sacred that I will change things without verifying it with the user. This is because for the last 5 years I have been writing code and frequently was one of the users, the maintainer, the architect, and the tea lady.
I am not sure what it is that I am afraid that you don't grok, but I can tell that I am.
Eddie, I'm glad you're back at Wiki! I'd thought maybe you'd left it a while back. -- JamesCrook
Sometimes instead of striving for pattern-form, it's useful to just describe the conflicting forces which the pattern would resolve. This would mean understanding what the compiler is able to do, how it is constrained by aliasing etc. This is what I thought the GrokAliasing
etc pages were about. It doesn't necessarily matter
if it is not in pattern form. -- DaveHarris
Are you accepting patches against EddiesWiki
1.1 Beta?? -- TimLesher
Eddie Edwards? '...get back from skiing'? You're not the great Eddie 'The Eagle' Edwards are you? -- PaulRuane