For anyone wondering what K is, I&#x27;ll repost this old email exchange between an ML person and a K person (it&#x27;s already online, so no privacy violation):<p><pre><code>    On Wed, 12 Oct 2005, Fermin Reig wrote:

    &gt; Dear Rico,
    &gt; 
    &gt; I have read Mark Joshi&#x27;s book on C++ design patterns (as well as your
    &gt; review) and I&#x27;d like to share my opinion of the book with you. (By the
    &gt; way, I find the information in your website very useful.)
    &gt; 
    &gt; My interest in the book was to try to learn how theory is put into
    &gt; practise. The best way to do that is by actually implementing things, so
    &gt; I did: I reimplemented his C++ code in OCaml, a functional, OO language
    &gt; that I like using. However, instead of a direct translation of C++
    &gt; classes to OCaml classes, I chose a non-OO design. The result is quite
    &gt; interesting from the point of view of code complexity and programming
    &gt; productivity (and hence cost). Here&#x27;s a summary:
    &gt; 
    &gt; Monte Carlo (datatypes only)
    &gt; C++: 264 lines of code (LOC), (7 classes, 20 methods), 12 files
    &gt; ML : 33 LOC, (3 datatypes, 1 function), 2 files
    &gt; LOC ML&#x2F;C++: 33&#x2F;264 = 13%
    &gt; Binomial trees (datatypes only)
    &gt; C++: 264 + 138 = 402 LOC, (10 classes, 30 methods), 18 files
    &gt; ML : 33 + 12 = 45 LOC, (3 datatypes, 3 functions), 2 files
    &gt; LOC ML&#x2F;C++: 45&#x2F;402 = 11%
    &gt; Binomial trees (datatypes + main algorithm)
    &gt; LOC ML&#x2F;C++: 165&#x2F;522 = 32%
    &gt; 
    &gt; I&#x27;m not claiming that Mark&#x27;s C++ code is bad (actually, it&#x27;s quite
    &gt; good). However, using a better tool results in obtaining a better final
    &gt; product. (Performance of Ocaml&#x27;s code is competitive with C++ as well.)
    &gt; 
    &gt; I have written slides with more details about this, which I have shown
    &gt; to a few friends. If you would like to see them, I can email them to
    &gt; you. (I have also told Mark Joshi about my evaluation.)
    &gt; 
    &gt; Regards,
    &gt; Fermin

    Hi Fermin,

    Not bad. But my K implementation only uses 2 lines of code though...

    EuroOpt:{[S;K;r;v;T;n;po] &#x2F; spot, strike, rate, vol, expir, steps, payoff

    &#x2F; initialize constants
    p:(%2*m)*(1%D)-d:a-m:_sqrt -1+a*a:.5*(_exp dt*r+v*v)+D:_exp -r*dt:T%n;

    &#x2F; apply n binomial steps
    :*n{-1_ D*(p*1!x)+x*1-p}&#x2F;K po&#x27; S*(1%d)^(2*!n+1)-n
    }

    ...and here are some test cases...

    po:{0|x-y}; &#x2F; arbitrary payoff function: max(0, K-S) for put

    &#x2F; compare results for n = 16, 32, 64, 128, and 256
    \t EuroOpt[5;10;.06;.3;.5;;po]&#x27; _16*2^!5

    &#x2F; pass in payoff functions for put, call, and digital \t 
    EuroOpt[8;10;.06;.3;.5;500;]&#x27; {0|x-y},{0|y-x},{y&gt;x}

    &#x2F; investigating convergence for a digital option with 1-300 steps...
    EuroOpt[8;10;.06;.3;.5;;{y&gt;x}]&#x27; 1+!300

    So yes, I agree with you. Functional languages are cool and C++ is
    verbose &amp; restrictive. Unfortunately, in the real world people don&#x27;t care
    about any of this... :-)

    Cheers,
    - Rico
</code></pre>
And that was the previous version of K, before Q&#x2F;kdb+. Things are probably even more concise now, but I&#x27;ve stopped following this about 10 years ago. Good times.