239 reputation
212
bio website plus.google.com/u/0/…
location London, United Kingdom
age
visits member for 2 years, 1 month
seen Sep 7 at 20:13

I'm an applied mathematician & engineer, living & working just outside the London metro area.

Over the years and on both sides of the Atlantic, I've led a variety of quantitative & operational challenges across intelligent systems & software engineering, sonar, defense, environmental technology, robotics, and most recently the complex world of multi-channel retail.

The common thread that links passion, profession, and play is applying technology, good design, and quantitative modelling and simulation, to build better products, enable better decisions, and optimise performance.

I'm always experimenting and tinkering, so feel free to get in touch with ideas.

My Google+ profile, Google+ posts (active), and blog (older)


Nov
1
comment Should comments say WHY the program is doing what it is doing? (opinion on a dictum by the inventor of Forth)
Thanks for the response. So in your opinion then, should comments include justifications for design choices, e.g. the reasons why a particular design was chosen over reasonable alternatives?
Oct
31
awarded  Student
Oct
31
asked Should comments say WHY the program is doing what it is doing? (opinion on a dictum by the inventor of Forth)
Sep
16
comment Mercurial release management. Rejecting changes that fail testing
To the OP: you're clearly on this site reasonably regularly. Is there any reason why you seem to ask questions but accept no answers? It's usually good practice on these sites to reward good answers with feedback in recognition for the time they've invested in your question. You've got a few very good answers below... (nudge nudge)
Sep
16
awarded  Supporter
Sep
16
comment Mercurial release management. Rejecting changes that fail testing
(+1) very clear description -- and very helpful. Thanks for this! (It's a pity the OP hasn't returned to officially review the responses.)
Sep
10
comment Learning OO for a C Programmer
You may find this easier than you expect. Obj-C will reduce the language gap since it is quite similar to C -- the differences will naturally emphasise the key concepts you'll need to master. My suggestion is more around choosing some fruitful toy problems / exercises. I expect you'll already have a strong intuition for OO design because anyone coding solutions for as long as you will intrinsically appreciate the cleanliness and elegance of wrapping functions and data structures within their own package (class). [PS I went from C to OO first via Obj-C, then Ruby, now Python -- Good luck!]