Elixir: Syntax matters

Home / elixir / Elixir: Syntax matters

Elixir: Syntax matters

We are getting under way with our Elixir project. I kicked the tires around Clojure, and love the abstractions, but couldn’t get over the Java ecosystem or the syntax. I am dyslexic and have never been able to make the prefix notation languages work for me. But I loved the macros and the ways you could condense your ideas.

I am starting to see those ideas really come into play. We code a few concepts. Once we start to see some repetitive themes, we decide how to condense those common idioms. Sometimes, that means building a different set of functions. Other times, macros factor heavily into the equation. Here’s an example.

Chat Business Level API

We have a chat service where rooms, topics, and other ideas are all in implemented in different processes. We have a common process model which we wrap, and that has a simple receive that looks like this:

That works great… I can dial right in to the message I want to match through pattern matching. But look at the amount of noise in that function head:

  • The def
  • The conn and s parameters which are always the same.
  • The heavier key/value syntax
  • The type match will always be first and most important, but it’s lost in the map syntax

We can improve that api significantly:

 

Beautiful. A four line macro makes my intentions perfectly clear. I call out the action and message type much more clearly: I am receiving the start message.

Worth the cost?

I know that some readers will believe that macros are some type of radioactive jar of mayonnaise that’s been in the sun three hours too long. You can probably recite the objections by heart. If not, let me help.

  • This code will be hard to debug, or hide subtle bugs. (This objection perhaps ignores the bugs that I can inject by typos that impact my pattern match.)
  • Macros are dangerous because they are not explicit. (This objection has merit if there’s too much going on, but not for such a simple macro.)
  • Macros lead to code that is hard to extend.  (This objection ignores the fact that we still allow the earlier form of this statement.)

My Bet

But consider this.  I’ll need to write that code, or some form of it, several hundred times for this application, and maybe several thousand. I’ll need to read that code even more. My guess is that through selective use of macros like this one, we’ll move much more quickly, make fewer mistakes, and make training new developers much simpler.

Over the coming weeks, you’re going to see us play a similar set of games to improve the way we test.

What do you think?

Bruce Tate
Bruce Tate
Bruce Tate is the CTO of icanmakeitbetter.com, and author of more than 10 books, including the best-selling Seven Languages in Seven Weeks.
Recent Posts
Showing 2 comments
  • Robert Virding
    Reply

    I can add an extra objection to macros:

    – They can make code hard to understand and maintain for someone who didn’t write the code.

    And this coming from an old lisper who is very into macros. 🙂

    • Bruce Tate
      Reply

      Glad you found this post, Robert!

      I agree with one caveat. Languages with macros generally move faster because the language itself is written in macros. Why would we extend a programming language? Because “Sometimes, new language features are worth it.”

      I can add new language words and idioms to my program that improve my ability to reason about my business domain. Is it worth it? That’s the debate here. Usually, the answer is “Sometimes.”

      Striking the right balance is the answer here.

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you as soon as possible!

WordPress Lightbox Plugin