Combinator library gets software prize

[C.Reinke]

> > This article is very good, and having read the conference paper earlier
> > in the year I finished it with only one question:  What's a 'quant' ...
> > and is it good or bad to be one?
> > 
> >         "Ten years ago, Jean-Marc Eber, then a quant at Société
> > Générale, ..."
> 
> The OED has:
..
> So perhaps he was tall, thin and fond of wearing a cap?
> 
>  :-)

You might want to try 

  http://www.dictionary.com/cgi-bin/dict.pl?term=quant

  An expert in the use of mathematics and related subjects,
  particularly in investment management and stock trading.
  ...

  http://www.investorwords.com/q1.htm#quant

  One who performs quantitative analyses. Or more generally, a
  securities analyst.


Am I the only one who finds the exclusive emphasis on combinator
languages slightly disappointing (in fact, the article seems to equate
functional language with domain-specific combinator languages, which is
more than a bit mistleading)?

This is a Haskell forum, not one on Backus' FP, so readers are well
aware of the advantages of functional abstraction. Domain-specific
languages, if embedded in Haskell, tend to inherit these advantages,
even if the language in question was designed as a pure combinator
language.

The consequence (and the intention, as far as one can gather from the
paper) of the limitation to combinators is that this language can and
will be used mainly in non-functional languages, not inheriting all
that much from a functional style of programming. The same will
probably hold for any communication standards based on it.

This appplication is undoubtely a success and a good step forward,
but there is more to functional languages.

The paper somewhat downplays the role of embedding the combinator-based
DSL in a full functional language while also mentioning that some
features gained for free in the Haskell prototype considerably
complicate implementations in other languages. I would be interested
to hear more about these aspects:

  - Is the strictly combinator-based approach a pragmatic necessity
    ("one step at a time") or is there no need for more advanced
    features (especially abstraction) in the application area?

  - Has there been a comparison of the way the combinators of the 
    DSL are used in Haskell and in other implementations? 

    I would think that the use of abstraction to define more complex
    instruments in terms of the basic combinators should play a rather
    dominant role. On the other hand, I can imagine that users would
    want to have each complex instrument explicitly named and studied,
    instead of trusting large amounts of money to anonymous
    abstractions created on-the-fly.

  - What about interactive exploration of new instruments, e.g., in a
    Hugs or OCaml session (as opposed to changing a C++ implementation,
    or a stand-alone executable generated by an OCaml compiler, for
    every experiment)?

Claus