Hacker News Reader

Comment by dmix | Hacker News Reader

I started off as a designer before learning to program and I have a minor unhealthy attachment to the design and composition of functions. I've been learning Erlang recently and I have to say Erlang's pattern matching and list comprehension make it one of my favourite languages in terms of design (I should note I'm also a fan of Scheme/Clojure style which I know many people aren't).

It certainly didn't appear that way when I first came across Erlang, as it's not always readable to the uninitiated (and nearly turned me off the language) but brilliant for those that are familiar with it.

Elixir has also done a good job of translating it for people who like Ruby-style syntax, I prefer the flexibility of the more verbose Erlang.

View on HN

> Elixir has also done a good job of translating it for people who like Ruby-style syntax, I prefer the flexibility of the more verbose Erlang.

The really big deal about Elixir is the ability to do LISP-style runtime code execution and generation. Lots of the Elixir language is implemented as macros, and the beauty and power of it is evident when studying the source of Elixir itself and Phoenix. A good example of where this comes into play is implementing a gen_server: in Erlang, this is always a good bit of boilerplate. In Elixir it can be done with a couple of lines, with automatic default implementations provided.

The Elixir syntax is a nice bonus, but the runtime code-generation Elixir brings to the table is a game-changer that takes it to the next level.

While I like this idea, I think the parent's point is that the utter simplicity of the language is worth living without these things.

I personally prefer Erlang to Elixir aesthetically. The big wins I see from Elixir are protocols and standardized tooling (though I have high hopes for rebar3). Parse transforms are overkill for most things but that's about how often I need things like macros in the world of Erlang.

Even still, today's Erlang ecosystem is about the BEAM and it's great to have so many options. Erlang, Elixir, LFE, Lua, Joxa, &c.

Elixir macros are compile time.

Yes, sorry, I meant compile time!

Are macros an obstacle to having code completion for Elixir?

You can now do this in a sanctioned way in Erlang as of v18. They're including merl as part of the standard distribution now.

This is a very big deal. Thank you for telling me about it! As is so often the case, there's more value in the HN comments than the articles.

Since you mentioned Clojure and Erlang's pattern matching, I thought it nessicary to reference this Clojure library, [1] defun.

Here's a quick snippet:

    (defun fib
      ([0] 0)
      ([1] 1)
      ([n] (+ (fib (- n 1)) (fib (- n 2)))))

Then:

    (fib 10)
    ;;=> 55

Cool isn't it!

[1] https://github.com/killme2008/defun

That is indeed cool! Seems extremely handy and intuitive.

I've seen more than one control structure library for Clojure that would make certain algorithms more smooth and "easier to read" in code - I just wonder if it's actually confusing for the readers to start pulling in all of these to your project as you see fit.

This! Erlang's syntax is so small and simple, it probably fits on a postcard.

Although I appreciate the excellent tools and libraries built by the Elixir community, I have a hard time understanding how one can prefer Elixir over Erlang.

It is simple. I think it was one of the design goals.

The other interesting thing is over the years creators have added features but have tried to also remove features to keep it is simple. That is very hard to do but they fought for it, and I think it paid off after many years.

Yup, got bitten by this design goal once, when support for parameterized modules was removed (though I do agree it was the right move in retrospect).

Shame about the record syntax, though. That was the only part I explicitly disliked when working with Erlang.

Agreed, I have found myself wishing other languages have Erlang's pattern matching functionality.

I have to admit my first attempt Erlang was filled with nested cases and I knew something was wrong... Now, I avoid case statements in favor of pattern matching.

Erlang the language is nice, but where it really comes together is the runtime environment.

Although I was a programmer before I became a designer (and still am), I've also found that graphic design (typography in particular), has positively affected how I compose functions and methods. It first started with the how I laid out my statements, then progressed eventually to size and how they were arranged.

I argue with my colleague a lot about whitespace (he likes to get rid of all of it); sometimes I wish I'd done a Ph. D. on the effect on typography on programming just to win the argument.

I relate a lot with you. I would even see there a pattern, once that design oriented people normally have a preference for low boilerplate and beautiful designed languages as ruby or haskell or even lisp.

Reply on news.ycombinator.com