[racket] Documenting a financial model in Racket?
Grant Rettke wrote at 09/09/2011 11:23 AM:
> At work I've inherited a financial application whose model that is too
> complicated to be documented.
>
[...]
> What approaches, techniques, or features of Racket do you think might
> be interesting?
>
If you want to use Racket, and not the systems analysis and design
methodologies of the '80s and '90s, then my suggestion for an initial
plan: Start with the legacy Java code that is not understood,
painstakingly comment every few lines with what it is doing mechanically
and why you think the intent might be, and at some point turn the Java
syntax into sexp syntax (better to do the comments on the original code,
before this point), and then iteratively refine that, til you get to
something that you can execute in Racket with macros/language (ideally,
but don't kill yourself on this if it's too hard, and proceed to next
step), and then you should know the mechanics well enough that you
understand what most of the code is doing and can make DSLs for it.
Make DSLs that fit the code, and your uses of those become documentation
for complicated or simply estoteric bits of your model. You can
iteratively refine your system at DSL levels of abstraction, then.
Reverse-engineer equations from code into somewhat higher-level DSLs,
too. Finally, put the DSL uses into Honu or a Python-ish pseudocode for
showing to those averse to parentheses, add Executive Summary, and get
printed and bound handsomely.
Due to your DSLs, you might also now have the bits working in Racket,
and you'll probably find qualitative ways in which that's better than
your legacy implementation. It might even be faster and have fewer
defects, since if it's "too complicated to be documented", that could
mean it was crafted by a genius monk, but more likely the code has
inefficiencies and bugs that are easier to identify (or that simply fall
out incidentally) in the course of DSL implementation.
--
http://www.neilvandyke.org/