

What type of DSL do you prefer? - jorgeleo

I am working on an OLAP database for .net (pure managed code). Write once, slice and dice data many times.<p>For the record, I do know of many products that do the same thing, but they are inadequate for different reasons. Pure managed code is one thing, price is a huge problem with a lot of them, lack of easy managed programmability, or just plain slow. A b-tree index cannot compete with bitmap index when we talk about intersection and aggregations on millions of records. And yes, I do know about SQL Server Analysis Services, PowerPivot, SPSS, and all the big ones.<p>But the MDX is not very intuitive, and SQL does not gives me the fine granularity to intermediate results that I need (I mean, yes it can be done, but a price is paid in performance). So I am into creating a more granular DSL.<p>From .net I am looking into 2 options: 
* A .net API. probably some type of fluent interface
* A text DSL that the developer executes against the engine. Maybe a graphic front end on top of it.<p>If you had to write an application that queries this kind of engine, what would you prefer? To interact with classes and objects, or to write strings that the engine will execute (ala SQL)?<p>:^)
======
Detrus
Strings?

Not familiar with your specific needs, but generally prefer DSLs fine tuned to
the task. Strings sound like they'll allow more flexibility for you, less
hassle for developers to type and read. Objects and classes sounds like
boilerplate galore.

Hard to say though, depends on API or string DSL design. Do you have example
code?

~~~
jorgeleo
Engine.Create("dbfile", CSV, "sourcefile", new Config[] { Field1, Field2 });

vs

Engine.Exec("Create dbfile CSV 'sourcefile' using Field1, Field2");

or...

Engine.Context("contextname", "var1>10").Save()

vs

Engine.Exec("Save (var1>10) as contextname");

~~~
Detrus
Well the string DSL is easier to read. Doesn't seem like there would be a lot
of useful autocompletion with objects/classes either.

