A Train of Thought — ALT.NET Seattle Edition

Yeah, I’m a week late with this recap, but I’ve had writer’s block.  The Seattle ALT.NET Open Spaces event was awesome.  The open spaces format is by far and away my favorite format now for developer gatherings.  I love the interactive aspect of this format.  We jumped right into a great set of topics without getting hung up in useless, angsty “What is ALT.NET all about?” discussions.  I love catching up with people that I’ve met at other conferences and meeting more of my blogroll.

 

Ready or Not, Here comes the Polyglot Programming Reality

A major topic in Seattle was the Polyglot Programming trend (I know it was a big topic because I have a lot of notes that I can’t read under the heading “Polyglot *********”).  Right now there seems to be an explosion in new programming languages or at least interest in different programming languages. 

There was a lot of discussion both about doing some or all project work with alternative languages like F# or IronRuby when it hits.  The general idea being that you would probably write infrastructure code in C#, then use a more dynamic language like IronRuby for business logic and “glue” code in the upper layers.  More on this later, but I think it’s somewhat comical that we’re calling C# the infrastructure language when a few short years ago it was C++ for infrastructure and C# was the high productivity language in the upper layers.

Would you mix languages on the same project, and if so, is that a good thing?  There were a lot of mixed opinions on this subject.  On one side is the fear that multiple languages will make a system harder to understand and require more skilled people to work on the system.  Then there’s the other side that thinks we’ll get more productivity by having multiple languages that are specialized for certain tasks.  Personally, I know I’d like to be able to easily mix and match C# and IronRuby on projects.

Complicating the discussion is the idea of little Domain Specific Languages that aren’t even remotely Turing complete.  To this point, I’ve been mostly interested in internal DSL’s using Fluent Interfaces in C#.  I look at that technique as merely a stopgap until we get IronRuby and its far superior language support for DSL’s.  The next bit of evolution is dabbling the toes into creating an external DSL.  I’ve always been leery of trying out some sort of lexical parser ala YACC or ANTLR, but the Language Workbench idea coming from the JetBrains MPS product is very intriguing.  Imagine being able to write your own focused mini-language for test automation or configuration without losing Intellisense or basic refactoring.  That’s what the Language Workbench products will eventually do for us. 

There’s a rumor that Microsoft might be interested in creating some sort of Language Workbench as part of their DSL efforts.  Thumbs up from me, but please don’t ruin it by making us use XAML.

Before you panic about the difficulty in learning new languages, think about this:  is a tightly focused mini-language DSL going to be any harder to learn than the equivalent new API in C# or VB.NET?  In many cases I’d argue that an internal DSL is preferable to an old fashioned API in C#.  Web programming with HTML and CSS was brought up as an antipattern because of the 3+ languages you have to know to develop.  I’d turn that around and say that web programming is a great example of polyglot programming.  Try to imagine what the C# equivalent would be like for replacing HTML and CSS.  I think I’ll take HTML and CSS, thank you.

 

 

Quick Hits

These should be on Twitter but I just feel weird shooting these things out in 140 characters at a time.

Code Generation versus Code Synthesis.  I think that one of the big debates in software development over the next couple years is going to be over pursuing better productivity through external tools like software factories and large scale code generation or by using different programming languages (I.e. not Java/C#/VB.Net) that have facilities to write much less code.  In this corner is Kathleen Dollard on Code Generation.  And in the far corner is Venkat Subramaniam on Code Synthesis (using Metaprogramming and language oriented programming to pack more punch with less code).  I’m with Venkat on this one.  Why do I want to muck with a separate model outside of code, then run the code generator if I can work at the same high level directly in the code itself?  Of course, to be a loud debate, the two sides of the issue would have to know that the other side even exists.  Today, code generation probably seems like the default choice in .Net development because we don’t have programming languages that support Venkat’s vision of Code Synthesis.  When IronRuby, IronPython, and F# are ready for production, Code Synthesis in the .Net space can be a reality.

Microsoft employees are a little too cloistered for their (our) own good.  Not all mind you, but many of the blue badges I interacted with didn’t have very much prior exposure to many of the topics that come up frequently in ALT.NET settings.  I get it, it’s a big campus full of smart people and you’re probably heads down on your own project.  Case in point, in ALT.NET circles we seem to be much more enthusiastic about Language Oriented Programming with textual DSL’s (or at least that’s my position, preference, and observation).  In Redmond, DSL == graphical tooling backed up by code generation.

After this weekend, I really think the concentrated blogging communities like Los Techies, Elegant Code, and yes, CodeBetter, are a very positive thing.

Why are teams still writing persistence code by hand?  There’s a bazillion persistence tools out there that all save development costs in some way over writing data access code by hand.  With very few exceptions, I’d say that at this point that if you’re writing ADO.Net code or SQL by hand, you’re stealing money from your employer. 

I wasn’t there, but there was a session roughly titled “Are Auto Mocking Containers Evil?”  I had this argument a little bit with Scott Bellware the other night, but it came down to a problem with wording.  He heard the word “container” and had awful images of Xml configuration hell.  All an AMC does for you is look at the constructor of a concrete class and use Dependency Injection to stuff in test doubles for all of the parameters in the constructor function.  I’d urge you to approach an auto mocking container (AMC) as simply a tool to reduce the mechanical cost of setting up interaction tests.  I initially resisted the AMC idea because I thought it would obscure the unit tests, but I’m sold on the AMC technique after using it for awhile on a project.  A class with a lot of collaborators is a code smell, but remember that code smell doesn’t automatically mean there’s a problem.  Some Controller-type classes do absolutely nothing but coordinate other classes.  Unit testing those classes will require two or more mocks in a single test.

I seriously think you should seldom use your IoC container inside unit tests.  The mass majority of interaction unit tests should be easy to set up with pure DI.  I say this for two reasons.  First, the IoC container is infrastructure code and you want as little code as possible directly coupled to the container.  Second, using a container inside of a unit test greatly ratchets up the risk of test data from a previous unit test polluting the results of a later unit test.  Unit tests need to be isolated for effectiveness, and using an IoC container in unit tests can easily abrogate that isolation.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in ALT.NET. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://elegantcode.com Jan Van Ryswyck
  • http://colinjack.blogspot.com Colin Jack

    Currently I mainly work at the back end (domain and below) so CSS/JavaScript don’t have much impact on me at the moment but I possibly should spend time learning more about dynamic/functional languages, however I have reasons for not doing it.

    Firstly I have a choice in how I spend my spare time, do I spend it learning different languages or do I spend it reading forums/blogs and books on topics that interest me (DDD/testing/dmessaging/patterns or whatever). Reading books/forums directly effects the way I program day by day and I just don’t have the time to do that whilst fully immersing myself in other paradigms.

    Its a balance though and I realize that by not really learning Ruby/F# (yet) I miss out on the great features each language has and the effect learning these languages would have on the way I write C#. But then at the moment I think I wouldn’t be able to dedicate enough of my own time to be anything more than a dabbler in either language and the associated mindset and I’m not sure being a dabbler is really enough.

    Obviously though I don’t though want just one language to rule them all.

  • Jeremy Gray

    I lost my previous comment because of codebetter.com’s insane requirement of allowing their javascript in order to submit a comment, so here we go with a shorter take on my previous, nicer comment. :)

    Scott can rail against a two-dependency controller all he wants, but encapsulating those dependencies behind some other class so that the controller need only have one dependency ignores the simple fact that the new class will still need to be tested and will still have two dependencies that need mocking, whether through an AMC or hand-rolled DI written right in the test.

  • http://blog.enginefour.com Shawn Oster

    Where one stands on polyglot programming seems to entirely depend upon how you view programming in general. If you consider it a craft that is enjoyable in it’s own right regardless of the problem you’re solving then you probably think “Polyglot Programming” is just a fancy name to something you’ve been doing for years whereas if you write your code and punch the clock then any number of languages beyond one probably seems like an annoyance.

    It’s very akin to how a master mechanic or carpenter doesn’t just drool over wrenches or hammers but over entire tool catalogs. I know a few mechanics and they’ll spend just as long talking about different tools and technique as they do the cars they work on.

    My greatest example against “One Language to Bind Them All” would be WebForms. In attempting to shield developers from the realtiy of HTML, CSS and a request/response model they greatly hindered devs ability to create standards-compliant web pages or to really understand the model they were working with, which in turn dramatically decreased their productivity. The mental shift (not to mention code) your basic WebForms dev has to perform just to implement a client-side message box is painful to watch as they repeatedly drop a button on a form, double-click it to get to the OnClick event and write MessageBox(). Every time I slowly explain client-side vs. server-side events in web development I feel like I’m pulling Neo from the tank.

    In my eyes .NET is currently the best platform to make mixing languages and language types a real-world productive approach, much how XHTML + CSS + JavaScript is a very easy and natural grouping because they all work on different aspects of the same idiom at different levels. .NET offers common libraries to be used and glued together in various aways using the language best suited for a problem all from familiar tooling and focused on a single target.

  • Lucas Goodwin

    @Scott

    I can’t argue with ya there. All valid points and conclusions.

    However, ruby is a language and that’s the point. XML (All derivations there of) is not a programming language. XSLT, maybe, but I’d argue a very specialized one.

    I don’t think XML is even a very good specification format for anything complex (such as specifying a DSL or configuring your IoC). It’s why I prefer to use StructureMap’s DSL for configuration unless I’m going for true dependency seperation at the compiled level (very rarely have I ever needed that).

    But back to DSLs and XML (which is what I was railing against originally). I’m leaning more and more towards using language grammars and tools like ANTLR for DSL development. Language development with an easy to maintain language and tooling generic enough to allow for multiple language targets and even supports TDD practices. That’s where I see the future of DSL dev in my book.

    BOO looks interesting in this regard as well, though I don’t have any experience with it beyond Ayende’s code samples.

  • http://scottic.us Scott Bellware

    Lucas,

    “Two words. Auto-complete. XML, XAML will never have Auto-Complete and it’s incalculable how much of a performance gain one gets from just this one feature in their IDE. Not to mention refactoring tools, static analysis, etc…”

    That performance gain is pale in comparison to the gains achieved through excellence in design, and in using better programming languages.

    When we don’t have such advantages, we can’t do anything but fall back on tooling.

    I often wish I had auto-complete and refactoring in Ruby, but Ruby has most often been a more productive environment without these affordances that C# has been with these affordances.

    Different paradigms are subject to different rules. When comparing elements of different paradigms, we need to make sure that our biases aren’t causing us to compare things in a way that isn’t appropriate, no matter what our long-held predispositions tell us.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Colin,

    Not that I know of. We were in that funny hidden room off to the side.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Scott,

    Well, you could also say that it’s nothing but a stop gap. We won’t need an AMC with Ruby.

    I don’t see the need for interaction testing going away anytime soon though.

  • http://colinjack.blogspot.com Colin Jack

    Jeremy,

    Yeah and to be fair even someone who has rad this blog for a while might have trouble recognizing you from the picture.

    Can I also ask, do you know if anyone recorded the session?

  • http://scottic.us Scott Bellware

    Jeremy,

    Not pissed off at all for being called naive – especially not in regards to such a concrete subject.

    Being naive on this is indeed a fear I hve. Although, my spider senses are tingling like mad, and when the vibrate this much I find that I’m usually on top something that others will pick up on some time later.

    My design compass points to “no” on the wide-spead auto-mocking thing. I still think it’s a valuable tool, but everything I hear in the dialog on auto-mocking suggests that this is the point where we delay a next stage of intellectual growth in regards to software design practice because of convenience tooling.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    Colin,

    I’ve taken that question quite a few times;-)

    Paper and/or talk only though.

  • http://colinjack.blogspot.com Colin Jack

    Ahh yeah, I was the one who asked the question. Must admit it was hard to get involved, had only met one of the attendees before and the whole no name tag thing…

    Still, good holiday and it was worth going just to hear Brad Abrams ask you “What IOC do you use?”.

    Agree with everything you say and will definitely be looking forward to reading the paper. I reckon there’s a good book, or part of one, in the whole topic :)

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Colin,

    You were there? I wish you would have said something, I wanted to meet you over the weekend.

    I need to do a better job elucidating this point with some examples. Like I said in the session, I’ve been doing some significant restructuring to the StructureMap code and bumped into some problems:

    * What I’ve found are a lot of unit tests that do their assertions on “side effects” of an operation instead of the intended result. These tests have dragged down the refactorings because the assertions aren’t very intention revealing and tied tightly to inner workings. Frankly, it’s meant having a larger focus on integration tests and more coarse grained tests.

    * Use meaningful data for the test data. I was using some nonsensical string values like “Red,” “Green,” or “Blue” and asserting that the correct key was returned. After this experience I’ve started using “TheMachineDefault” or “TheDefaultKeyFromTheProfile” or “TheKeyFromTheXml” as the test data to make the tests more self-describing

    * Use custom assertions!!!! A little bit of customer assertion language does a tremendous good in making the tests more readable and decouples you from the inner details. The places where I had done this were much easier to restructure.

    * Keep the test setup information as close to the test as possible. Things got a lot easier for me when I changed the model so that I could set up scenarios in a few lines of code instead of a big Xml file in another directory

    I think I’m going to write up a real paper on that session and get it published somewhere later this year.

  • http://colinjack.blogspot.com Colin Jack

    Bit off topic but I really enjoyed your session on maintaining structure map and had a question regarding it.

    It was all good but the bit I wanted to ask you about was where you mentioned that you do more goal oriented testing these days, not least to create tests that are less likely to break when you refactor.

    So I was wondering how you go about it? Do you use something like StoryTeller/FIT or are these likely to be higher level xUnit tests?

    Still trying to get my head around how best to write these sorts of tests because I haven’t yet found an approach I really like…

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Dave,

    My concern is almost 100% about the readability. Xml is simply not friendly to the human eye, and especially not friendly to a non-techie’s eyes.

    I guess I don’t care too much if it’s XML/XAML that’s capturing the details about parsing the DSL, but I think XML of any sort is a poor choice for the actual DSL syntax. Part of the reason for using a DSL is to achieve a more readable syntax to express the intent of the code with minimal compiler syntax noise. I’d much rather have a near English, human readable expression than a machine friendly Xml format of any kind. If it’s a business logic DSL, it’s doubly important that the DSL syntax be readable by the business people.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Dave,

    My concern is almost 100% about the readability. Xml is simply not friendly to the human eye, and especially not friendly to a non-techie’s eyes.

    I guess I don’t care too much if it’s XML/XAML that’s capturing the details about parsing the DSL, but I think XML of any sort is a poor choice for the actual DSL syntax. Part of the reason for using a DSL is to achieve a more readable syntax to express the intent of the code with minimal compiler syntax noise. I’d much rather have a near English, human readable expression than a machine friendly Xml format of any kind. If it’s a business logic DSL, it’s doubly important that the DSL syntax be readable by the business people.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @jdn

    “Scott did mention it in his BDD talk, and I thought his point was more that an AMC will hide when you are needing to setup multiple dependencies to run a test, and thus hiding a design smell. Which made sense to me at the time.”

    Yes, that’s true, but what I’ve found is that you still feel the pain of too much integration in test setup. Like I said, I was leery of AMC at first because of the obfuscation problems, but I just haven’t seen it as a problem in practice. Dynamic mocks help a bit. This is straying a bit into the TypeMock argument about using a tool to deaden your design sensory nerves.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Dustin,

    I’m not sure how much you’ll really mix and match languages on a single project. I really think it’ll end up being more of a split between different projects. Within a single project I think you’ll see the division if anything being by layer or component.

    I’d be very cautious myself about mixing languages in the same module.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Lucas,

    I think the pro-XAML argument, or really just the pro-XML argument, is that it’s relatively easy to build GUI tooling on top of it because Xml parsing is a known problem. Of course, with a XAML/XML solution you *want* to have tooling because it stinks to edit Xml by hand, so that’s kind of a self-reinforcing thing.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Scott,

    Just to piss you off, I think you’re being naive here.

    “Controller classes, don’t need two or more mocks to be tested. Those two or more mocks are very likely another abstraction that hasn’t been identified and formalized because auto-mocking caused the designer to skip over the “is this right” questioning phase of the controller’s design.”

    Maybe, but maybe not. Think about the case where a single, atomic action requires that three actions on three different, cohesive services needs to be performed in a certain order. How does adding a facade help here? Making the Facade just pushes some of the interaction down into the Facade class.

    Go do a complicated desktop client and come back to me on this one. I think this is yet another case of you mocking something that you don’t understand.

    “Two or more mocks injected into a constructor defined on a layer supertype represent an abstraction that follows a dependency aggregator pattern”

    True, but this doesn’t even begin to cover the cases that I’m thinking about.

  • Lucas Goodwin

    Two words. Auto-complete. XML, XAML will never have Auto-Complete and it’s incalculable how much of a performance gain one gets from just this one feature in their IDE. Not to mention refactoring tools, static analysis, etc…

  • http://dmihalik.com Dustin

    For me the real hindrance with Polyglot Programming is not getting everyone on the project to understand the different languages, it is the difficulty of refactoring between the languages. Lets say you had a UI in C# and a business layer in IronRuby. If you write something in C# and then later decide you would rather have it at a different layer you have some decisions to make. Do you introduce risk and extra time to rewrite it in Ruby or do you leave it where it is? The problem becomes worse when you start mixing CLR languages with non-CLR languages.

    Two other potential issues to watch out for is duplication of “utility” code between the different languages and developers who prefer one language over another and start putting code in the incorrect layers.

    I’m not against Polyglot Programming but you have to be careful in thinking about your design up front and specifying what each language should be used for.

  • Dave

    Are you more fearful of XML or XAML as a DSL substrate? Or Both? Why?

  • http://scottic.us Scott Bellware

    > Some Controller-type classes do absolutely nothing but coordinate
    > other classes. Unit testing those classes will require two or more
    > mocks in a single test

    You’ve just made my point about why auto-mocking is the alt.net version of drag-and drop.

    Controller classes, don’t need two or more mocks to be tested. Those two or more mocks are very likely another abstraction that hasn’t been identified and formalized because auto-mocking caused the designer to skip over the “is this right” questioning phase of the controller’s design.

    Two mocks in a test on a class that is in the family of a layer supertype is a design flaw. The test friction should have pointed that out. If you remove the friction with alt.net RAD tools, the flaw stays.

    Two or more mocks injected into a constructor defined on a layer supertype represent an abstraction that follows a dependency aggregator pattern, which presents a Demeter-friendly, delegating API, and constructors that accept the individual dependencies that the layer supertype depends on. It’s the dependency aggregator interface that is then mocked, rather than the individual dependencies themselves.

  • http://www.e-Crescendo.com jdn

    I’m even later on my wrap-up on Seattle than you. Maybe this week.

    Anyway, the AMC session never happened, it was negotiated out (he wrote it on the board in the “Mocking Yes or No” session…I was the only one saying ‘no’, surprise…LOL).

    Scott did mention it in his BDD talk, and I thought his point was more that an AMC will hide when you are needing to setup multiple dependencies to run a test, and thus hiding a design smell. Which made sense to me at the time.

  • http://www.peterRitchie.com/blog Peter Ritchie

    I don’t know about other people (and I regret I was unable to attend ALT.NET Seattle 2008 as I would have contributed the following) but I’ve been doing “polyglot” programming for years. I’ve worked in many projects over the years that have involved two or more languages in the development of a project. Worst case was C#, C++, VB6, VB.NET, and Delphi for one application.

    I’d actually have to say that polyglot for me is the norm, not the exception, and I’m not including ASP.NET n-tier or SQL in that…