Wednesday, August 17, 2011
Firefox 6 came out during the last week. I then see a few tools that highlight using JavaScript to process what you would expect from something in native code via a plugin.
An MP3 decoder written within JavaScript
http://jsmad.org/

A PDF viewer written in Javascript - with footnotes, color, diagrams.

http://andreasgal.github.com/pdf.js/web/viewer.html#7

This ties back to the Hanselman interview with Erik Meijer -where he refers to JavaScript as the Assembly language of the web. The low level code that other tools are beginning to compile to -example Script# and other tools - that Hanselman followed up with in additional episodes.

All this makes me wonder what is coming in Windows 8. (maybe this is why the Build Conference sold out months ahead of the event?)

However - the MP3 player link above works in Firefox and not in IE9. So there is more work to be done in the browser area, but the efforts in this area of late are really noticeable. (IE8, IE9, beta of IE10 - Firefox 4, 5 and 6 were not that far apart .. maybe too close together for some). The rapid changes to the Google Chrome browser. This increasing pace and direction of standards in the browsers is interesting, and when tied to mobile phones, and tablets as the new devices, becomes more interesting and intriguing as to where computing in general is moving. Virtualization of computing resources, cloud integration, with those hardware changes,makes for a very dynamic landscape for the 2nd decade of the 21st century.

That dynamic element, for the computing world - in this decade, assumes the world economies can stay afloat...the force that will determine acceleration, or collapse at this point.


Wednesday, August 17, 2011 9:48:55 PM (Eastern Standard Time, UTC-05:00)
 Tuesday, January 25, 2011
In 2008, I attended the Microsoft Professionals meeting (Atlanta) where Shawn Wildermuth gave a presentation on Domain specific languages or DSL's. The concepts were an introduction into a Microsoft product development that used the code names   "OSLO",  "M", and "Quadrant" that was previewed in part at the PDC2008 (Professional Developer Conference) which has mostly morphed into something else by PDC2009. Shawn produced three articles for MSDN on the topics of "OSLO" and "M". In the 2008 presentation I attended, Shawn introduced the premise that we use DSL's already today; SQL, XAML, Make, Ant/Nant, MSBuild, regular-expressions, even musical notation are all examples of DSL's. From that talk, the idea of software development DSL's  was planted - even though the technologies that had prompted his discussion have been morphed into new forms within Microsoft - the conclusion  from this argument is that a set of text statements ( or specific symbols like music or regular expressions) can be declared and used to achieve a desired result - and within programming - results in how executing code processes those results. A concise grammar and syntax, that declares what you want to do but not how you do accomplish that - regular expression syntax is a great example. Software development using a DSL, is an idea that continues to cross my path. I thought I would try to capture some of the variations I have seen in how various developers and architects approach the concept of creating and using DSLs.

Martin Fowler wrote the book on Domain Specific Languages where he describes the 3 types of DSLs.
There are some early Oslo software preview videos out on the Microsoft site that show the language M being used to generate a DSL grammar within the tool called Quadrant. This is what Martin Fowler referred to as a "DSL workbench"- where the tool builds the DSL. Martin Fowler identified two other main categories of DSL; the External DSL, and the Internal, or Embedded DSL. External DSL's are often quite complex - and rarely come to general usage. Internal, or Embedded DSL's are abstractions over an API, or framework, within an application.

The idea of a DSL being used was briefly touched on in the Jan 2009 DotNet Rocks episode with Aslam Khan a software architect that lives in South Africa. The company he works with uses this to achieve Domain Driven Design (DDD). "Write a story that describes a problem", and understand that little piece, to understand the domain. "Something that describes it completely - that does not bleed into the other", which build up a dependency graph, it exists in context to the other things - behind each story. A story about the problem - the domain. The more you reveal incorrect assumptions in the dependency graphs and correct them, you don't have to prune source code trees -so you get smaller source code trees, and designing API's around the stories - means changing the granularity of the stories - not modules. In the podcast (just after 38:41) they describe a misunderstood story - that would have produced an incorrect system design - but writing out a story, that the users can understand - allows for corrections can be made before hand. Understanding the user's vocabulary, and you can write it in those terms, then you have the basis to build on(this goes back to the Eric Evan's Domain-Driven-Design "ubiquitous language"). It helps other people later on to understand the language of the application. Aslam Khan uses a Wiki to capture that language - and refers to the "Wiki as code" (about 44:44 in the podcast). He refers to it as "a DSL captured in business terms - that cannot be executed - but at that point you can start writing code". After listening to that podcast(in 2009), I went to Aslam's website - and discovered his posting about using Cucumber and driving it down into Rspec. That led to my reading of a post about Ruby and the latest on Ruby testing - using cucumber. (There is a language called Gherkin used with Cucumber to create a Ruby testing framework). The dynamic nature of Ruby - and the concept of Metaprogramming - became connected to the idea of how one could produce a DSL. Aslam Khan stated it, on his blog, as "the Code is the data" behind a DSL, and he encouraged learning about AST's (Abstract Syntax Trees) which to me connected directly to .Net Expression Trees - the basis of Microsoft Dynamic Language Runtime(DLR) in .Net 4.0.  DSL's can become Expression Trees which in turn can become running code in the DLR. At least, in theory, that would be one Dynamic-Language approach to implementing a DSL(There may be some limitations on how that can occur).
 
During 2010, I picked up a copy of Orin Eini's(a.k.a Ayende Rahein) book called "DSL's in Boo - Domain Specific Languages in .Net". (he did an interview in March 2010 with DotNetRocks on this topic).Ayende is known in the .Net development world for RhinoMocks( a mocking framework), his work on NHibernate(his company makes a profiler for NHibernate and EntityFrameworks), and now his RavenDB - document database project. Somehow, he also managed to have written a book on DSL's   - the guy is prolific at producing content - whether you see his coding output(RhinoMocks,RavenDB), his blog, and now his book.  In his book, he describes how he builds his own DSL's using the .Net language Boo as the foundation, as it gives him a parser,lexer, and great extensibility points, that compile into .Net code - that is not based on the DLR. He shows how the Boo language allows for defining your own expressions that can then be compiled - statically.  Boo is based on the released ECMA standard for the CLI. Interestingly -both the Boo Language, and the ECMA CLI standard, had recent updates(at this writing) Boo 0.9.4 was updated Jan 2011, and the ECMA Standard December 2010. Boo has some capacities that make the language very powerful. It can be an object oriented language, and it can do functional composition (where functions are first class citizens like those in F#), it has 'Syntactic Macros', and it has an extensible compilation pipeline - which is what the creator, Rodrigo B. de Oliveira, wanted to have in the first place, and it can run on multiple platforms (Windows CLR and Linux Mono). Boo has its roots  based on Python Syntax and looks like it has some great potential.  To use Boo that as the basis for creating a DSL seems like a very interesting choice - here it would be a statically typed implementation of a DSL. This could be a way of generating a concise Internal, or External, DSL that works for the users and programmers alike within a given domain. Ayende's book gets into the details of using boo for creating your own DSL.

I found a few entries that related how Powershell could be used at the basis of a DSL. There is a blog post from Keith Hill on how Powershell's syntax flexibility allows you to create a internal DSL. Doug Finke, a Powershell MVP, posted something that went back to the Oslo starting point from a Powershell point of view. Doug Finke shows implementing an OSLO grammar syntax using Powershell, based on the concepts originally introduced in that early video of the M Language example. So from Dynamic Languages or Scripting tools we can find approaches to creating DSL's today.  Doug Finke connected the concepts of DSL, DRL, and Boo; all the ideas together in his post "Creating a unified programming model on top of .NET" He cites "Trends and Directions in programming languages" from Anders Hejlsberg.  DSL's could certainly be part of that mix in creating solutions.

Jeffrey Snover, the architect of Powershell, had a discussion in 2008 on DSL's with Martin Fowler and Neal Ford from Thoughtworks. (recording on Channel9). In this talk they made the point that a DSL can be an External DSL, an Internal DSL or a 'workbench' with tools wrapped around it. Martin Fowler made the point that not many successful DSL's have been done starting from the business side and working toward the API - but that is where the concept is the most powerful, they made the point that it is usually an abstraction of an existing API that simplifies the underlying API - and that DSL can be replaced with the word 'Framework' and mean the same thing. Jeffrey Snover also posted that Powershell could be used to create DSL's by limiting the syntax. The key piece he refers to is the data segment SupportedCommands - which he alludes to as a way to limit a DSL done in Powershell.

Karl Prosser referred to the Powerboots library for Powershell as a DSL in a blog post. It is a Powershell set of commands that are specific to using WPF from within Powershell - which stays with the concept that it  is limited to that specific domain.

Sometimes the use of a Fluent API - can be used to write code that is very readable and expressive - such that it becomes an internal DSL within the general purpose language(Steven Hoisee blog has some coverage on this).  I came accross a paper on how JMock was developed and how they worked toward incorporating a Fluent API as part of their own Embeded DSL within the framework.

Martin Fowler, who took the time to write the book on DSL, has a post on BusinessReadableDSLs. Where the idea is different than business-writeable DSLs. That was the impression I got from Aslam Khan's use of Cucumber - that the business could read the DSL and confirm if it was correct or not.
Martin Fowler invokes the comparison to COBOL - which was supposed to be an english way of telling the computer what to do - and begs the question - how is this one different?  My impression is that the a correct implementation of a DSL is declarative - it describes what you want to do, now how you do it - and having programmed in COBOL - it is an imperative approach, not a declarative one.

Developing a DSL, based on the Jeffrey Snover video, leads me to see that in a DSL you have vocabulary and you have grammar that must be decided on - and the idea of keeping it small seems to be important. Just enough to keep and simple - and no simpler.

Jeremy Miller(Creator of the IOC container - StructureMap, an MVC framework called FubuMVC, and a testing tool called StoryTeller) did a presentation on creating Internal DSL's at Oredev in Oslo - Nov 2010.
He  contributed to the Fluent NHibernate project, and incorporated the use of an Internal DSL in these projects - and in the presentation he goes over some of the difficulties of using and developing an Internal DSL using the C# 3.0 language features. He touches on the separation of the Runtime and Configuration model in building a DSL, and that testing an internal DSL for configuration is very difficult - you can test the runtime model more easily, and then make sure your configuration model works correctly. (the video is a bit grainy - and a few of the questions, that came from the audience, are not heard - but the concepts that were used in creating an internal DSL are shown pretty well.)

From this set of touch points - on the various flavors of DSL's, it is something that can be done in a variety of ways. The simplest form is the internal or embedded, perhaps as a Fluent API approach. This simple form of a DSL can be for a small team that produces repetitive code, or business rules that are needed in in either a static or dynamic fashion - but still being an internal abstraction - within a small domain. Then there is an external DSL - and that would need to have a the same considerations as a full blown computer language - as the publishing of an External DSL approach tends to get the syntax set in stone, unless you can absorb breaking changes later on. 

I find this an interesting research topic, that may prove to be a practical solution to some future area of work. Along these lines - I recently purchased a book that looks promising; Terrence Parr's book "Language Implementation Patterns - Create your own Domain Specific and General Programming Languages". Terrence Parr developed  ANTLR and that tool is used in the Boo compiler.  I will have more reading and learning to do in this area - and, perhaps at some point, the payoff will be when I can see an area where a DSL can be used to invoke parts of a framework. Ideally this would be in terms of the users, a readable Business DSL, or an API syntax that developers for an application can use that brings a higher level of abstraction and makes code more readable - and perhaps more declarative.  The Jeremy Miller video shows that is not a simple task, however, he shows that it can be used to develop some powerful solutions too, and that I find to be valuable.

Tuesday, January 25, 2011 8:05:47 PM (Eastern Standard Time, UTC-05:00)
 Monday, July 26, 2010

In the July 2010 presentation, for the Atlanta .Net User Group, the presenter made a comment that Lambda and closures make your code cleaner, refering to their importance in a Silverlight example and doing testing with the test framework for Silverlight. Without these language elements,the testing framework in Silverlight would either require a great deal more code and variables, or simply would not work. These language features combine to allow for small amounts of code to perform asyncrhonously. Silverlight is inherently asyncrhonous, which makes Lambda and Closures important concepts for developers to understand.

Lambda and Closures, are considered an advanced C# topic, introduced in .NET 3.0 Framework. The Lambda operator in C# is written with two characters together, an equal-sign followed by a greater-than-sign (=>). A Lambda compiles into one of two ways: the first way is it converts to a delegate instance, and the second way is it converts into a type Expression<TDelegate> - making the code inside the lambda a traversable object model - an Expression Tree - an essential element that is one of several key language pieces that LINQ is built on. The root of the lambda is a delegate, and in my discussions with other developers, some are not aware of what that is, which explains why Lambda and Closures are considered more advanced.

So to understand a Lambda, understanding what a delegate is - becomes mandatory. Delegates have been around since version .Net 1.1 of the framework, each release of the framework from 2.0 through 3.5 enhanced the basic concept of the delegate to the point that the Lambda is a superset of the delegate. Delegates are the building block of some generics -Predicate<>, Func<>, and Action<> are delegate types. Lambda builds on the foundation of delegate and generics that were introduced in earlier versions of the framework. A delegate behaves like a function pointer in C/C++, where you can assign a function to a variable(an address of a function to a variable of type pointer) allowing you to execute that function through the variable. In the case of a delegate, in .Net, you are assigning a typed method signature to a delegate variable, allowing you to execute the method from that variable,as the method signature matches the delegate signature. A signature means matching the return type, and the arguments - same argument types and number of arguments, for both method and delegate - they all have to match for the compile to work.

    class Program
    {
        //Delegate is defined with a signature(the example signature is: return an int - when passed two integers)
        delegate int GiveMeBackNewResult(int a, int b);

        static void Main(string[] args)
        {
            //Create a variable for your delegate type (which implies the same signature and return type)
            GiveMeBackNewResult varYourVariable;
            //Assign a method (of any class) to your delegate - as long as the method signature and return type matches
            varYourVariable = DiffAge;
            //Execute the method - from your variable reference to that method
            Console.WriteLine("AgeDifference:" + varYourVariable(25,43).ToString());
            //Result of "AgeDifference:18" shows in console window until you press a key.
            Console.ReadKey();
            
        }
        // Created a method that matches the delegate method signature - so we can assign to delegate
        public static int DiffAge(int firstAge, int secondAge)
        {
            //Lets just show positive numbers for an age difference.
            if (firstAge <= secondAge)
            {
                return secondAge - firstAge;
            }
            else
            {
                return firstAge - secondAge;
            }
        }
    }   
   

Delegates in this context have names, and the functions assigned to them have names. In version 2.0 of the framework, along with Generics, there was the introduction of 'anonymous methods'. Direct assignment to a delegate variable, using inline code to define a delegate,assigning the inline delegate to the delegate variable, and with no defined method name, it creates an 'anonymous method'.

   
    class Program
    {
        //Delegate is defined with a method signature(the example is return an int - when passed two integers)
        delegate int GiveMeBackNewResult(int a, int b);

        static void Main(string[] args)
        {
            //Create a variable that is an instance of your delegate
            GiveMeBackNewResult varYourVariable;
            // declaring the right side as a delegate - identifies variables first, and then uses the variables
            varYourVariable = delegate(int ageOne, int ageTwo) { if (ageOne <= ageTwo) 
							{ return ageTwo - ageOne; } 
							else 
							{ return ageOne - ageTwo; } }; 
            //Execute the method - from your variable reference to that method
            Console.WriteLine("AgeDifference:" + varYourVariable(25,43).ToString());
            //Result of "AgeDifference:18" shows in console window until you press a key.
            Console.ReadKey();
            
        }
       //NO Method defined - since we are now using an Anonymous Method assignment to the delegate variable.
    }
   

One other item to point out in the anonymous method - the return type is inferred from the delegate signature, which in this case, is an integer result. If you tried to return 'strings' - you would get a compile error for the inability to convert 'string' to 'int'. The restrictions of arguments and return types is still there, it is just composed differently in the code.

So now we have established the concept of a delegate,how delegates are the basis of the 'anonymous method', we can now move on to understand one side of the Lambda -how it compiles to a delegate - actually an 'anonymous method'. The Lambda syntax, changes one line(as determined by the semicolon) but is the exact equivalent of what we saw in the anonymous method. A Lambda has implicity typed parameters - based on the delegate.

//Replace the right side of the assignment - from delegate(var) {method} 
//-- with  a lambda expression --                         (var)=>{method}
            varYourVariable = (ageOne,ageTwo) => { if (ageOne <= ageTwo) 
							{ return ageTwo - ageOne; } 
							else
							 { return ageOne - ageTwo; } }; 

   

Closures allow variables outside the lambda expression, to be referenced within the Lambda. Closures ability to pass data through to a delegate, and then pass it on to a subsequent delegate can be a powerful concept. The presentation on Silverlight, that I started with, demonstrated how well these concepts work, you had to pass the data to a delegate due to the asyncrhonous nature of Silverlight- Asyncrhonous calls use delegates. I found Jon Skeets article, from C# in Depth, on The Beauty of Closures - the article covers the Lambda and closures and he has comparisons between Java and C# and how they approach the concepts from each language, and version of the language. I am not sure I could restate his comments on closures better - so I will direct you there. I expect that this topic will come back, in a future post, as there is a flexibility that these two features combine into, that will only become more apparent with regular use.

The idea of the Lambda goes back to Lambda calculus. The concept in computer theory goes back many years. I came across the readscheme site. connected to the programming language SCHEME (a variant of LISP). They have white papers, dating back to 1976, on Lambdas "The Original 'Lambda Papers' by Guy Steele and Gerald Sussman". It is interesting how the .Net framework is now adopting ideas that have been around for a while. The developments however are very sound and developed in a thoroughness that I must say I appreciate. It may take work to understand how to use these well, but well worth the time to learn them well.

Monday, July 26, 2010 10:30:05 PM (Eastern Standard Time, UTC-05:00)
 Friday, September 05, 2008

At the DevLink codecamp, in Murfreesboro TN, I met a developer before the keynote, Corey Haines. He started explaining some things about how Ruby was a language that was going to change the developer experience, and then proceeded to demonstrate a very simple app that he got up and running in minutes - a web site application.

I attended the meeting where the Open Spaces were being planned and session on how Ruby was affecting the profession (or something like that) was proposed as a subject. I was curious - twice within a few hours - this topic had appeared.

I was standing in front of the OpenSpaces board later, and discussing the subjects with people who were standing around, and when I mentioned the Ruby discussion that was going to happen, two older individuals - who seemed like Managerial types chimed in that they have seen that developers can be very productive with Ruby. OK - that is three times before lunch and the subject of Ruby has been put in front of me - this is getting to be a bit ridiculous - so - my curiosity is growing.

The Ruby Language - is not used at my employer today (that I know of). The main impression that I got was that the productivity using Ruby can be an order of magnitude more than what other languages offer. This was a set of information that will take me a while to digest and experiment with.

I have downloaded IronRuby and got some learning materials to go through. I can see that the roots of Perl are in some of this. It will take some time with all the things I have going on right now. 

The little I have read indicated that both Python and Perl were not sufficient for the developer of Ruby, and that is how the language got its start. The breadth of technical areas that the books I got shows that this is a maturing language - I am sure that there will be more to say later as I have digested a bit of what I am learning.

Here are the books I got to become familiar with Ruby

 

Friday, September 05, 2008 4:43:38 PM (Eastern Standard Time, UTC-05:00)