I just started a talk about DSLs.  I’m posting the slides for consumption.

Slides

Slides w/ Notes

I’ve been working on a presentation and some other stuff all month, but I had to work on a T-Shirt idea for IndyALT.NET.  It’s been nagging at me for a while.  And it was fun!  It has been far too long since I pushed pixels!

Last week, IndyAlt.NET had a series of lightning talks that was a lot of fun. We where covering tools we’ve used. It was kind of a show and tell night.

Turns out that giving lightning talks are a specialized skill. I learned some things and I want to share.

There are two types of things you can talk about, small things and large things. This seems obvious, but you need to know which one you’re covering.

Small things: You may run under. This is okay. State the thesis quickly and up front. “Why do I care”. It can be cool, address a problem, or just be “pink”[0]. You can cover some neat use cases in that time.

Large things: It’s fine to not hit detail. Think of this as an overview of your thing. Give me a hook so I want to look into it more. I want to see why I want to look into this tool. Think of this as a 5 minute infomercial for the “Rolly”, not a lifestyle comercial for a cadillac. If it’s open source, I should want to commit to it. If it’s a product, I want to use it. If its a cool technique, I want to do it.

[0] My wife eleveates “Being Pink” to core functionality. When she got her pink Razor, that was its defining and most important feature. She was shocked to find out she likes her iPhone more, but she had to get a pink case for it. It was a moral imparative.

There is an erlang syntax that is beloved by OO converts to the language,  the parametrized module.  Here is why.

> Obj = param_example:new("Tony").
> Obj:name().
"Tony"

This Syntax makes an OO guy feel cozy.  And taking a look at the implementation of our module, we see the the implied variable is defined on the module definition.

-module(param_example, [Name]).
-export([get_name/0, set_name/1]).

get_name() -> Name.

There is a caveat.  If a module is parametrized, all functions are parametrized.  You cannot use non-parametrized functions to wrap your parametrized function, like this.

> Obj = param_example:new("Tony").
> ListOfNames = param_example:new_from_list(["Tom", "Dick", "Harry"]).

In fact, there’s some magic, functions actually have an arity of one more than you think. Actually, an extra parameter for each module parameter. In addition, these are constant, like all erlang variables. Since you don’t have access to a recursive call stack, you can’t change them.

However you can use a separate module to front- end the parametrized calls. And “mutating” calls can return new instances with new parameters.

So when Is it a good thing and when do you not want to use it?  I like the idea of using parametrized devices to wrap a bunch of data I’m going to be passing around but still has some functionality that needs to be called.

The scenario I didn’t find it useful for is having several processes that I can call without having a reference.  More concretely, I need to have rooms addressable via names of some other soft reference.  And their variables need to be modifiable. I abused named gen_server services for this.

-module(named_example).
-behaviour(gen_server).
-export([start_link/2, get_description/1, handle_call/3,init/1]).
-record(room, {name, description}).

server_name(Name) -> list_to_atom( lists:concat([ ?MODULE, "_", Name])).

start_link(Name, Description) ->
  gen_server:start_link({local, server_name(Name)}, ?MODULE, #room{name=Name, description=Description}, []).

get_description(Name) ->
  get_description:call(server_name(Name), description.

handle_call(description, _From, State) ->
  {reply, State#room.description, State}.

So, there are two ways of dealing with a collection of processes that are cleaner (don’t use the raw message send) than just passing around a Pid.  They do different things, but might could be used in combination.  I’m just not sure how, yet.

Oh, hey. If you have a better solution, please post a comment.