Learning Elixir, frst impressions ( plz don't kill me ! )

Questions / Help
21

Generally if you are having a serious discussion, or with people you don’t know, it’s usually best to avoid humour - unless you’re certain it won’t be taken the wrong way. (Going by your comment above though, it appears this isn’t the case in your experience… that should probably be telling you something :lol:)

I’m also struggling to see what the purpose of this thread is. Are you trying to point out that Elixir is ‘different’, lacks some FP stuff, is peculiar in places? If so you’re not telling us anything we don’t know.

As has been pointed out by others, Elixir is not trying to be like Haskell (or other similar languages). It is at its most basic, simply trying to be a modern version of Erlang with some key influences from Ruby and other languages thrown in. Erlang itself was built with a very specific job in mind - one that it excels at. You could argue that Elixir is merely trying to be as close to a perfect language as its creator wanted - constraints allowing. It just happens that so many of us love it as well, warts and all.

If you’re wondering why, take a look at this thread:

And then if you are still excited about the language, I recommend learning it by reading some of the excellent books available - here are some recommendations based on what I have read or done myself, although there are of course many more (see: Books and Courses)…

If after reading the Why Elixir? thread you’re not enthused or you feel the language is not for you - that’s cool too. Good luck on whatever you decide to adopt.

As a general note, if you’re new to a community it’s a good idea to put yourself in the shoes of others - and ask yourself how your comments/thread might come across. If you’re genuinely interested in helping the language, or hearing the thoughts of others, diplomacy and tact (not humour and unfair or immaterial critique) is usually the best way to achieve your goal.

12 Likes
22

Ahh I love my programming drama in the morning.

Just wanted to point out this, since no one else has, I think. Your default value slashes are the wrong way around. It would be def foo(x \\ 1, y \\ 2), which would not be mixed up with a typical C++ style comment. But even if it was //, there’s plenty of other things you can mix up in Elixir if you think all languages look like C++. :stuck_out_tongue:

2 Likes
23

Dude, Erlang has been like this for more than 3 decades. Elixir just adds different kind of syntax and toolings and web frameworks on top of it. We say Elixir as functional programming language, because it has no class, no object, no pointer as well. Just simple functions, in and out.

Jose Valim wants to bring the power of Erlang and OTP, but he wants it to be like that, the Elixir. The surface syntax looks like Ruby, Phoenix web framework kinda looks like Rails.

I’ve been coding Elixir in the last 4 years, and haven’t found a single monad or currying or for loop (even Haskell don’t have for loop as well, CMIIW). I love Elixir, because it has no monads and other functional aspects that are really hard to explain to other devs coming from OO/imperative.

And that is, Elixir code should be optimized for reading and understanding. There is a huge amount of effort on making an official Elixir code formatter.

If you are looking for pure functional programming language, I’m sorry, then Erlang and Elixir are probably not for you.

Well, TBH even Java that is marketed as OO from a very long time ago, is not pure OO. You want pure OO? Go get some Smalltalk.

3 Likes
24

Looking for OTP tutorials try Learn You Some Erlang for Great Good (online or as a book).

OTP is covered in most introductory/intermediate Elixir books.

25

If you are looking for pure functional programming language

In my understanding that is the silliest mistake, a developer can make: to look for the language to be fully compliant with some specific fashionable/hipe paradigms. What is the benefit of being “pure functional programming language”—well, none.

4 Likes
26

This post literally compelled me to write a long answer, so I’d drop the link to it here fwiw.

3 Likes
27

Careful now. I am not here to insult anyone I am just expressing my first impressions while trying to get a grip of the true nature of Elixir.

If I had to pin point the problem with my post it would be that I had all these notions and expectations on what features a FP should have and then when I realized Elixir didn’t I felt frustrated and I think that shows on the original post.

However, jumping from that to you are not making posts with good faith is a long jump and one that I believe is rather unfair. I am not here to tell you that Elixir sucks and language X is better or the other way around. I mean, going to an Elixir forum and complain that Elixir is bad because reason A, B, C would be rather unproductive, don’t you think?

Try to give me some time and know me better, who knows, you might like me ! ( or not? I’ll leave that up to you :stuck_out_tongue: )

And now, after reading over 20 replies I completely understand this :smiley:
Also, thanks for the resources, can’t wait to get started !

Easy there champion! That is in the " Elixir Weirdness ( aka, stuff you will eventually get used to )" section. Which means that it is only strange to me because of my background. Which means I am aware of it, and thus it’s only a matter of getting used to. Not a big deal :smiley:

I just wondered if someone else from a similar Java / C# / Javascript background had the same experience or thought when they started with Elixir.

This is actually something I value a lot. But while watching Thinking like an Erlanger I got this idea that syntax is secondary ( no one cares if it looks pretty or readable ) and that thinking is the principal part. As in protocols matter, how you implement them doesn’t ( as long as they work ).

Perhaps I miss-interpreted something? Could you show me some light on this ?

You are correct Sir ! ( also why I eventually left Java and God forbid I ever return … )

This OTP thing looks important. Will look into it !

Replied in your article :smiley:

28

If you want to use the list Monad, you could use the base syntax [1, 2, 3] as the unit mechanism for putting values into the monad, then use the functions of the List or the Enum modules to manipulate the values in the monad. You could bind multiple functions together using the pipeline operator if you like.

If you want to use a the Maybe or Result monad, a common technique is to use a tuple. A tuple of {:ok, value} might represent the Some or Just value, while either a tuple of {:error, term} represents. If you like you could also use {:some, term} and :none as the appropriate values. To bind them together you would commonly use a with statement in order to get the short-circuit behavior common to that monad. Something similar could be used for most variations on the State monad.

If I wanted to use a “clock face arithmetic” monad, for example, I would use judicious application of integer division and the rem function (for modulo arithmetic). I would probably bind the functions together using the pipeline operator again.

My point, of course, is that Elixir is currently full of Monads and there is nothing that would stop any particular developer from creating any monad they need to use. To your point there no concept of a Monad “typeclass”. There is not type-based facility, with syntax support, for treating Monads as a first-class construct, but there is plenty of facility to use monads in the language.

3 Likes
29

That’s good enough for me!

30

Weird is in the eye of the beholder, of course, but let me see if I can explain why this is the case. Elixir uses separate contexts to bind named functions and variables. This, as I understand it, means that Elixir is a “LISP 2” language. Here is a code sample:

defmodule DotSyntaxExample do

  def ambiguous(x) do
    IO.puts("I am in the ambiguous named function #{inspect x}")
  end

  def entry_point() do
    ambiguous = fn (y) -> IO.puts "I am in the ambigous variable. #{y}" end

    ambiguous("Hello")
    ambiguous.("World")
  end

end

DotSyntaxExample.entry_point()

# λ <521>$ elixir Ambiguous.exs
# I am in the ambiguous named function "Hello"
# I am in the ambigous variable. World

In this contrived example, when you are in the context of the entry_point function, there is a binding in the space of named functions for ambiguous and the function itself creates a binding to a variable named ambiguous that happens to lead to an anonymous function.

At the call site I need to tell the system which of the two I am interested in calling, the named function, or the value in the variable. For that reason, Elixir uses the .() syntax to indicate that I want to use the variable binding instead of the named function binding.

2 Likes
31

What I mean by weird, is that when compared to how you call normal functions in Elixir. Your example illustrates this in perfection:

 ambiguous("Hello")
 ambiguous.("World")

Now I get why you need .() in this example. It is a disambiguation.
However when currying ( in he article I presented and in here ) it seems that the only way to use dynamic functions is to bind them, which results in the syntax .(), instead of the more natural ().

But perhaps I am mistaken? Perhaps there is a way to call anonymous functions when currying that doesn’t require binding ? ( and thus promotes the usage of the () syntax ? )

32

About your serach at hex.pm, I think the most complete package is https://github.com/expede/witchcraft

1 Like
33

People seem to forget that a curried function is a workaround for the constraint in lambda calculus that a function can only have one, single argument. So in its original form (((f(1))(2))(3)) was necessary instead of f(1,2,3).

Languages like Haskell and OCaml popularized a notational convenience where you can use forms like f(1) and f(1,2) to return another function. But somehow people conflate that notational convenience with “currying”.

What is worse is that the obsession with currying seems to obscure the fact that “partial application” is the useful and powerful idea - which can be implemented simply by capturing available parameters inside a closure and returning a function that is ready to accept the remaining parameters.

As far as I’m concerned partial application is the meat and potatoes - currying is a mere frill.

12 Likes
35

These two statements are curious and interesting to me. “Horrible” is obviously a subjective opinion, and, in my opinion, a rather strong superlative to paint the entire API with. I’ve never seen anyone else mention that the the position of parameters in a function call being a “basic concept of FP languages”.

Is it somehow tied into your apparent penchant and desire for partial application?

I’ve not really had any strong problems using the Elixir API. It’s something I do have to think about switching back and forth between Elixir and Elm. Even so, I certainly wouldn’t categorize it as “horrible” myself so I’m genuinely curious to know, what do you find so objectionable?

36

That topic does come up regularly but because on the BEAM different functions can have the same name as long as the arity differs, creating Haskell-style “compile time notational currying” is basically out of the question anyway.

(In Bucklescript, which supports curried functions, parameter position was an ardently discussed topic).

1 Like
37

Plus, an additional reason for data-first API in Elixir is consistency with (most of, except a few modules) erlang existing conventions. This is a very pragmatic, down-to-earth consideration, one that in my eyes brings much more value than bikeshedding around not-so-important syntactic preferences. This is a typical example of what I like about the way Jose and the core team are designing things, being pragmatic and resisting the temptation to over-design. In my view, this gives Elixir a credibility that is rare for a young language, the opposite of a toy language or a research-oriented one.

1 Like
38

Not every FP language is a Haskell-derivative :slight_smile: so it’s odd that you are expecting the same set of features in every FP language. Have you ever tried Idris or ATS for instance? would you say that Haskell is less FP just because its type system lacks linear, uniqueness or dependent types?

1 Like
39

There is no requirement to bind an anonymous function to a name before it can be invoked:


  def partially_apply_me(left_addend) do
    fn (right_addend) -> left_addend + right_addend end
  end

  IO.puts partially_apply_me(3).(5)

Or simply:

iex(4)> (fn (x) -> IO.puts(x) end).("foo")  
foo
:ok

But in these examples, as well as the one above where the function is bound to a variable the .() syntax is consistently applied to indicate that you are applying parameters to an anonymous function.

It might be that in the partial application case you could unambiguously drop the dot, but then that would then be an inconsistency in the syntax of calling anonymous functions.

1 Like
40

So why use Elixir ?

If for no other reason – The BEAM! :smile:

That. That right there is worth overcoming any issues you may have with Elixir or Erlang as languages. It’s the Erlang Run-Time System (ERTS) that separates it from the pack.

[mike drop]

3 Likes
41

So did you accept the job offer of not? Let us know as there are a of people on this forum that find programming in Erlang/Elixir/Phoenix a joy and my guess is many would accept the offer with little hesitation. I know I would ( well if I don’t have to sacrifice a virgin and goat and yada yada yada to get it ).

There is a course that examines different programming languages down to the compiler/interpreter level and goes into details about the trade-offs. It even shows how to create functional like language interpreters using an OOP language and vice versa. It will take about 3 months to go through it but it’s worth it and here is a blurb about it:

Purescript is an example of a language that is transliterated into another language - javascript. I read the book and did the examples and like it a lot - would love a job using it as well - just don’t know if there will ever be much of a demand for it.

Getting into the syntax difference reminds me of the endless flame wars between Ruby and Python and how having to indent code was a horrible thing - well I loved programming in Ruby but anyone can now see that Python is rising to the top of the list of most programming languages used. I now use and enjoy both and they are way more alike than different and syntax is no issue - at least to me.

But you can and I think should should hold out for a job using pure functional languages only - you will never really be enthusiastic about your job if you don’t. Here is a partial list to get you started: