Back to Profile: sokhaty


  • Andrew Kennedy: F# Units of Measure

    Measurements in F# is an exciting feature. No doubt about it. I was really impressed when I learned about it being added to the language.

    It surely addresses a lot of potential issues with measurement mismatch. 


    Yet, run time support for measurements still makes a lot of sense.

    If you are reading data from external sources at run-time (files, sensors, or web services), you'd still have to implemet all the measurement tracking and conversion yourself. If this can be married to contract somehow, then application would just have to tell the framework that it expects mass to be in kilos, and if input feed turns out to be pounds then conversion would happen under the scene.


    Another presumably useful feature would be to declare measures off of classes/types. If for example, I'm counting my chicken, I don't want to be able to inadvertently add this to the count of eggs, unless I explicitly coersed chicken and eggs to be "things".


    Anyhow, compile time support is a very good start.

  • Donald Farmer and Julie Strauss: Inside Project Gemini

    Great, you have it all covered. I'm sold Smiley


    Now, this in-memory columnar database, is it going to be shipped along with Gemini only, or it eventually make it into some edition of SQL Server engine?

    Sure, database query language doesn't have to be SQL (or arguably even shouldn't be SQL), but querying language aside, such a compelling feature as in-memory columnar storage  looks very appealing as a generic service.

  • Donald Farmer and Julie Strauss: Inside Project Gemini

    Columnar in-memory database storage, wow, that's some serious stuff!

    A question though, when a dozen of users load their BI-mini apps onto the server and try to run them all, will there be 10 copies of in-memory database on the server (which might quite easily kill the server on the spot)? Or the server version of columnar database in not in-memory?


  • Christian Kleinerman: Introduction to SQL Server Project Madison

    Good introductiory video. Not too many technical details though. 

    Are compute node SQL Server instances running the same code as the coordinator? Doesn't sound like they need to.

    Is data auto partitioning going to be supported?

    How Madison compares to now Oracle's Exadata?

    What kind of storage (row oriented, column oriented) is used for compute nodes?

    Coordinator still seems like a potential bottleneck, if 150 compute nodes start streaming back to the corrdinator, on a poorly scoped query there is still a good chance to food it with data. Are there any provisions for scaling out the coordinator, or it's vertical scaling for now?


    Really looking forward to more videos on Madison (with a bt more details on internals Smiley ) .


  • David LeBlanc: Inside SafeInt

    Ale, thanks a ton for the pointers! Now I have to read them Smiley

  • David LeBlanc: Inside SafeInt

    Ah, wonders of computing. Ideas are simple, yet 90+% of all the implementation work is about discovering and handling all the border cases Smiley

    Btw, what were those (two?) good books mentioned in passing on the subject of partial template specialization (a.k.a. template meta programming)?

  • Louis Lafreniere: Next Generation Buffer Overrun Protection with /GS++

    Outstanding, it doesn't even look all that scary Smiley A lot of thanks, Louis!

  • Louis Lafreniere: Next Generation Buffer Overrun Protection with /GS++

    Thank you for the pointers, Louis.

    Is there anything that can be used in cases when binaries are coming not from the internal or a major vendor, like Microsoft, and there is no .pdbs immediately available? Is it possible to blindly search for a sequence of machine code instructions (naive signature matching)? Or in this case /gs injected code "optimized out beyond recognition"?



  • Louis Lafreniere: Next Generation Buffer Overrun Protection with /GS++

    Good video. It's been quite a while I had to write anything in C/C++, so excuse my ignorance.

    But, is there a utility to quickly check if an executable or a DLL contains modules that were compiled with /gs or /gs++ flag? In another words to do some sort of a static analysis of program binaries to have at least some level of confidence that it was hardened against buffer overflows?



  • Maoni Stephens and Andrew Pardoe: CLR 4 Garbage Collector - Inside Background GC

    Great video indeed!

    Charles, close to the end Andrew mentioned that SQL team is working on putting more CLR into SQL Server.

    Is there a chance to interview anyone on the SQL team on that? Are we to expect T-SQL being (finally) executing on the top of the CLR (after all, what's the point of having two VMs on a database server doing essentially the same type of work)? Are we (finally) to see a decent programming language that can be used to do rich data processing inside the database server (code near) instead of (frankly utterly outdated and feature deprived) T-SQL? Something like F# with LINQ directly to relational engine (bypassing SQL all together) would be a blessing (after all a relational engine does not have to be SQL).



  • The Future of SQL Data Services with Nigel Ellis

    10GB of "pure" data may sound like a reasonable starting point, but if the data are moderately indexed, the space would run out much-much faster.

    Are you planning to charge for the total consumed space (data and indexes), or table pages only?

    Are you planning to offer space compression by any chance?

  • Expert to Expert: Erik Meijer and Anders Hejlsberg - The Future of C#

    Immutability should be a VM-level feature.

    Regarding lazy evaluated methods,  I guess what you are really asking for is an object pipeline at VM or even OS level that would be thread safe and allowed multiple contributors and consumers to plug into it. It would presumably address quite a few scenarios of massive and/or parallel data processing. And yes, it would be nice if all the interfaces that can potentially return lots and lots of data were "pipeline"-aware.