After I have released Karmencita I received questions about it’s “relationship” with Linq so i thought to write a post about this.

“Am i trying to copy Linq ? “

Heck no. Like i have also mentioned in FAQ the both Karmencita and Linq are OQL implementation. Despite what most people think there is nothing ground breaking in either Linq or Karmencita. It has been done before.

“Linq is static typed but Karmencita isn’t !“

   I would mention that , personally, i think the best thing about Linq is the VS.NET intelissense.  As a guy who dabbs with dynamic languages i prefer Karmencita’s terse and fast to write syntax over’s Linq’s syntax. But it’s just a matter of taste. If you want “static typing” just to avoid stupid typing mistakes then i suggest to take a look at unit testing. By writing unit tests you can catch both typing and logical errors. Also as a side note…..is pretty much impossible now to make a internal DSL static typed since i can’t write compiler plugins for C#/VB.NET  to do the type checking myself. I was taking a few days ago with C# member team from Microsoft and unfortunately they don’t have plans to allows us that.

“Karmencita’s advantages over Linq ?“

Since it’s implemented as a library you can use Karmencita with any .NET language . I’m dabbing with a slighty modified version of it from Boo.

“Plans ?”

Lots of plans…only time is missing . I would like to “bake” a JavaScriptuesque “eval” in there. Also joins . Multithread interpretor  (with option for CPU bounding on multicore machines) to speed up filtering huge data sources.

If you have other questions contact me.

Now playing: Dream Theater - Endless Sacrifice

  Read this . It’s about LISP, lists, tree processing and DSLs. It’s about what makes LISP a great language. Invariably any programmer ends up having to write a DSL for a specific problem. This is one of the greatest strengths of a programming language and LISP really shines here.

  So how is that related to C#? Is way harder to do this in C#. Like in any static typed language you end up fighting the type system instead of solving the problem at hand.  Think about reflection, for instance. It’s a lot of code to type there ….C# 3.0 might help a little bit but, unfortunately, it will not make a big difference. We need a “dynamic C#”, we need “eval”, we need metaprogramming capabilities, we need a way to get (temporary) out of the shackles of strong typing.  Also we need a tree implementation in the BCL collections.

Case at point…..Karmencita. An embedded SQL language used to query in memory data. It’s a DSL build upon a dynamic model. It’s fast, terse and easy to use. When i started working at Karmencita i build at first a static typed model (after implementing the DataBlock OQL language). Didn’t liked too much….it was A LOT of code to type and for what ? Just to “satisfy” a parser to whom you can’t even specify the DSL rules ? Hence the dynamic model.

The Practical Common Lisp book is freely available online if you’re interested.

Now playing: George Enescu - Romanian rhapsody

      While working at Karmencita i had a “static typing vs. dynamic” discussion with a friend of mine.  Of course, the guy insisted that the dynamic DSL is useless unless there was a way to “type check” it . I disagreed , of course, but nonetheless i was interested in doing this in C#. Unfortunately, there isn’t any way to do it. I was thinking at something like a C# compiler plugin…..so that at compile time i would have access to the AST and type check the DSL.

    Unfortunately is not possible to do this in C# now. Maybe someday…..

Now playing: Elvenking - Hobs And Feathers

Is coming. LGPL. Soon.

  Big viewstate size is bad. In ASP.NET 2.0 there is a way to keep a page viewstate on the server and send
only a slim page output to the client. The way to accomplish this is by overriding the Load/SavePageStateToPersistenceMedium
methods. Here is a short sample which keeps the page viewstate into the server session :

- override the SavePageStateToPersistenceMedium method adding a VIESTATE_KEY.

    protected override void SavePageStateToPersistenceMedium(object state)
    {
        HtmlInputHidden vsk = (HtmlInputHidden) this.FindControl("__VIEWSTATE_KEY");

        if (vsk == null)
        {
            vsk = new HtmlInputHidden();
            vsk.ID = "__VIEWSTATE_KEY";
            vsk.Value = Guid.NewGuid().ToString();
            this.Page.FindControl("Form1").Controls.AddAt(0, vsk);
        }
        else
        {
            vask.Value = Guid.NewGuid().ToString();
         }

       this.Session.Add(vsk.Value, state);  

  }

- override the LoadPageStateToPersistenceMedium
 
     protected override object LoadPageStateFromPersistenceMedium()
    {
        string viewstatekey = Request.Params["__VIEWSTATE_KEY"].ToString();
        object r = this.Session[viewstatekey];

       //remove it from the cache
       this.Session.Remove(viewstatekey);

        return r;
    } 

Of course the viewstate can be compressed (LosFormatter) before adding it to the session. So, if you really need the
ViewState feature, here is a very simple solution that allows us to both have view state and send a slim output to the
client.
 

Now playing: Savage Circus - Tomorrowland