An Empathetic Functional Language(blog.drewolson.org)
blog.drewolson.org
An Empathetic Functional Language
http://blog.drewolson.org/an-empathetic-functional-language/
23 comments
Community and attention to user interface is definitely one of the more striking aspects of Elixir. I've seen José (the creator) stress over unclear error messages that he has no control over and focus design of even the smallest aspect of an API. Often times changing designs multiple times until its right.
That sort of attention to detail is apparent across the board in the language and the community.
That sort of attention to detail is apparent across the board in the language and the community.
I feel like this article lacks a lot of details that would make his point. I've spent the past few weeks learning F#, and I see nothing in this article that makes it clear why Elixir is more "empathetic" than F#.
Elixir creator here.
As part of my "job", I end-up playing, using and reading a lot about functional programming languages and I like F# a lot. It feels like the team behind F# put a lot of effort in transmitting the concepts in an accessible and clear way (F# Workflow in my opinion are one of such examples). It is not surprise given Microsoft has been introducing functional concepts into languages like C# and VB for a long while.
For Elixir, I have put extra attention into how you to get started with the language because it is not only about learning a functional language (and thinking in terms of recursion, immutability, etc) but also about concurrency and building fault tolerant applications. So help and guidance on every step really matters.
Documentation is extremely important and must be easily accessible. The language should be easy to explore, in your editor or terminal. Error messages should be clear: if you read an error and you don't know what to do next, it is a compiler bug.
I hope I have answered your question. I also would like to say it is not about finding the most empathetic language. They will all have pros and cons, many times even depending on the developer previous experience.
As part of my "job", I end-up playing, using and reading a lot about functional programming languages and I like F# a lot. It feels like the team behind F# put a lot of effort in transmitting the concepts in an accessible and clear way (F# Workflow in my opinion are one of such examples). It is not surprise given Microsoft has been introducing functional concepts into languages like C# and VB for a long while.
For Elixir, I have put extra attention into how you to get started with the language because it is not only about learning a functional language (and thinking in terms of recursion, immutability, etc) but also about concurrency and building fault tolerant applications. So help and guidance on every step really matters.
Documentation is extremely important and must be easily accessible. The language should be easy to explore, in your editor or terminal. Error messages should be clear: if you read an error and you don't know what to do next, it is a compiler bug.
I hope I have answered your question. I also would like to say it is not about finding the most empathetic language. They will all have pros and cons, many times even depending on the developer previous experience.
Thanks for a thoughtful answer. I'm with F# regardless of its particular merits (I'm lucky enough to have the privilege to write F# when the other coders here work in C# as it is), but I wish you the best of luck with your project.
"More specifically, empathy for the user.
This empathy is demonstrated in a variety of ways. Many have been extensively discussed: the natural syntax, ... "
I guess the author means "empathy for the user of Ruby"?
This empathy is demonstrated in a variety of ways. Many have been extensively discussed: the natural syntax, ... "
I guess the author means "empathy for the user of Ruby"?
What Drew is talking about is the syntax is natural in its representation. Things that we think of as keywords in most languages, ie `def`, `if`, `unless`, `defmodule`, etc are all just macros in Elixir which accept arguments. The syntax is incredibly natural when you see how Elixir is represented internally and built up using macros from a tiny base. This is what Drew is talking about, not some Ruby similarities.
How did you arrive at any of those conclusions?
That doesn't strike me as a very straightforward interpretation of the offhand reference to the syntax's being natural, made without any further comment. Nor do I see why "def" being a macro makes the syntax "natural in its representation" (or even what you mean by that).
Just as a test: if that is what he meant by the syntax's being natural, he should be willing to claim that the syntax of Scheme is at least as natural.
That doesn't strike me as a very straightforward interpretation of the offhand reference to the syntax's being natural, made without any further comment. Nor do I see why "def" being a macro makes the syntax "natural in its representation" (or even what you mean by that).
Just as a test: if that is what he meant by the syntax's being natural, he should be willing to claim that the syntax of Scheme is at least as natural.
Usually, when people talk about Elixir's syntax being natural, they go on to contrast it against either Erlang, which is known for having some odd syntax quirks such as having to end lines with different punctuation marks depending on context (something that can make changing or refactoring code difficult -- although, tbf, Erlangers have tooling that does help with this), or Lisps like Clojure, from which Elixir takes many ideas (it's macro system and the idea of the AST being normal language data types, it's protocols, etc). In fact, I've seen "natural syntax" defined as something like: functions are called like this: `my_function(arg1, arg2)`, and with operators so that numbers are used naturally, as in mathematics, like: `1 + 2` in contrast with lisps where function calls are like `(my_function arg1 arg2)` and math becomes `(+ 1 2)`. I do not know if this is any kind of technical definition, or just one that's been internalized by the Elixir community to some extent (I've seen it repeated in at least two or three places) but that's my guess as to what the author meant.
While Elixir may appear similar to Ruby syntactically, because of it's `do, end` blocks, that similarity is actually somewhat superficial. In reality, a Rubyist will only feel slightly more comfortable with Elixir's syntax than someone coming from another imperative language, for a couple reasons. One, Elixir's usage of do/end is far more regular than in Ruby, where `do/end` have a very specific meaning, and two, the differences from Ruby syntax (defmodule, defstruct, fn -> end, |>, calling anonymous functions) are actually greater than the similarities. But I think both the Rubyist and the (Javascript, C, Go, Python) programmer will find Elixir's syntax more natural than they would find the syntax of many other functional languages.
Of course, at the end of the day, our intuitions and feelings about syntax are quite subjective, and syntax is a very tricky thing because of this.
I can't say for sure what the author meant by natural syntax of course, but this would be my guess, based on how I've seen the term used in other descriptions of the language.
I'm curious what language background you come from, and whether there are particular things about elixir's syntax you found unnatural, difficult or uncomfortable?
While Elixir may appear similar to Ruby syntactically, because of it's `do, end` blocks, that similarity is actually somewhat superficial. In reality, a Rubyist will only feel slightly more comfortable with Elixir's syntax than someone coming from another imperative language, for a couple reasons. One, Elixir's usage of do/end is far more regular than in Ruby, where `do/end` have a very specific meaning, and two, the differences from Ruby syntax (defmodule, defstruct, fn -> end, |>, calling anonymous functions) are actually greater than the similarities. But I think both the Rubyist and the (Javascript, C, Go, Python) programmer will find Elixir's syntax more natural than they would find the syntax of many other functional languages.
Of course, at the end of the day, our intuitions and feelings about syntax are quite subjective, and syntax is a very tricky thing because of this.
I can't say for sure what the author meant by natural syntax of course, but this would be my guess, based on how I've seen the term used in other descriptions of the language.
I'm curious what language background you come from, and whether there are particular things about elixir's syntax you found unnatural, difficult or uncomfortable?
It looks like you skipped all examples given next, which do not seem to be Ruby related at all: the inviting community, the extraordinarily involved creator and the tooling.
I ... well, yes, obviously? Since all I was concerned to address was the claim that the syntax is "natural", I didn't feel any need to include anything else. That's why used ellipses, which mean "the sentence continues, but I'm not quoting the rest".
[deleted]
> Elixir is a pure functional language
No, it is not.
No, it is not.
Author here. You're right. I removed references to "pure" in the article.
The lack of empathy in your comment is exactly what ends up pushing people (like me) away from functional languages.
Your comment just points what is wrong, without any help to guide those who would like to know more, be them the author or a reader. It is interesting because you just dismissed everything the article was about: being empathetic and providing guidance.
For the curious, I understand a pure functional language one that explicitly marks all side-effects, for example, by using monads. So Elixir indeed does not seem to be a pure language. More information can be found on wikipedia: http://en.wikipedia.org/wiki/Purely_functional
Your comment just points what is wrong, without any help to guide those who would like to know more, be them the author or a reader. It is interesting because you just dismissed everything the article was about: being empathetic and providing guidance.
For the curious, I understand a pure functional language one that explicitly marks all side-effects, for example, by using monads. So Elixir indeed does not seem to be a pure language. More information can be found on wikipedia: http://en.wikipedia.org/wiki/Purely_functional
I didn't "dismiss" anything. In fact, I didn't bring up anything about the article other than this one factual inaccuracy. Moreover I pointed out why it wasn't purely functional when someone asked me. What else do I need to do in order to be a good commenter in your eyes?
Check the HN guidelines re-comments https://news.ycombinator.com/newsguidelines.html
> When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
This is exactly what I did. The author made an error, which I corrected without any other commentary or name-calling, and which the author then corrected. This is the only guideline which is relevant to what I wrote.
This is exactly what I did. The author made an error, which I corrected without any other commentary or name-calling, and which the author then corrected. This is the only guideline which is relevant to what I wrote.
Funny I found that today https://onfido.com/blog/using-cpus-elixir-on-raspberry-pi2/
Elixir is not homoiconic: https://news.ycombinator.com/item?id=7623991
It's close enough that arguing over the definition without explanation isn't useful. For those curious, Elixir's AST is represented by its own datastructures. Based on where you look up the definition, this is or isn't enough to classify as homoiconic, but the point Drew is making is the same. A programmable AST is hugely powerful for metaprogramming.
The talk of "empathy" as a core value also reminded me of the focus of Ernie Miller's "Humane Development". http://erniemiller.org/2014/12/17/humane-development/