[Haskell-cafe] Haskell for Physicists

[Alexey Khudyakov]

2009/12/4 Roman Salmin <roman.salmin at gmail.com>:
> On Fri, Dec 04, 2009 at 01:43:42PM +0000, Matthias Görgens wrote:
>> >  _So my strong opinion that solution is only DSL not EDSL_
>>
>> Why do you think they will learn your DSL, if they don't learn any
>> other language?
>  I didn't said that they didn't learn any language. They learn languages,
> but
>  only part that is necessary to do particular task.
>   f.e. ROOT CINT(C++ interpreter) didn't distinguish object from pointer to
> object, i.e.
>   statement h.ls(); works as well as h->ls(); independently of either h has
> type TH1F or TH1F*,
>   so beginning ROOT user didn't need know what is pointer, memory management
> helps him.
>  But early or latter one need to write more complicated code,
>  then one need to spend months to reading big C++ books, and struggling with
> compilers errors, segfaults etc..^(1) (instead of doing assigned task!) or,
> what is more usually, trying Ad hoc methods for writing software.
>  So people will learn DSL because:
>   1. DSL is simpler than general purpose language
>   2. DSL describe already known domain for user, (one probably don't need
> monads, continuations, virtual methods, template instantiation etc...etc...)
>         so learning is easy, and didn't consume much time.
>
>>  And if your DSL includes general purpose stuff, like
>> functions, control structures, data structures, you'll re-invent the
>> wheel.  Probably porly.
>  You didn't need to reinvent the wheel, because you DSL compiler can
> produce Haskell code:
>    DSL -> General Purpose Language -> Executable
>  And ever if you do, it saves allot of time of experts.
>
>  Roman.
>
> (1) In Haskell this probably will sound like: reading allot of small
> tutorials and articles, grokking monads,
>    struggling with type-check errors, infinite loops, laziness, etc...
>
There is other side. As Matthias Görgens mentioned earlier

1. One have to reinvent control structures. Multiple times. Lets assume that
compiler would translate DSL to haskell code. But DSL's expressions which
convert into haskell control structures are DSL's control structures.

2. There would be more than one DSL. If they are all EDSL there is no real
problems with combining them in one program if necessity arises. Probably
there would be ways to combine them if they are DSL but they will require
expertise and most likely dirty hacks.

2.1 And all of them will have different conrol structures, abstraction
mechanisms.

3. Turing tarpit. Users will constantly require more power and features in
DSL. Most likely DSL designers wouldn't be great language designers so
DSL will turn into utter mess.

4. One have all power (and libraries of host languages). Of course if he is
able to utilize it.

This is tradeoff between power and simplicity. If one have too much simplicity
he is not able to solve difficult problems. If one have too much power at
expense of simplicity he has to struggle with tool to have thing done.
And it's possible to sacrifice simplicity and don't gain any power.