[racket] Documenting a financial model in Racket?

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Fri Sep 9 12:19:24 EDT 2011

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.


Posted on the users mailing list.