DEV Community: Edison Yap

Real World Example with Elixir Protocol

Edison Yap — Sat, 13 Mar 2021 22:02:30 +0000

Today I'm going to write about Protocols in Elixir, and how I'm using them in my production app, Slick Inbox, a newsletter inbox app.

Protocol had always been a bit of a mystery to me, I've always been confused between it and behaviour, like when should I use one over another? I tried looking up resources on the web but I didn't manage to find much beyond the basics. I was interested in real world application, and learning how it could be used to apply to my situation. That's why I'm writing my journey here, perhaps someone could find this useful!

I was refactoring Slick Inbox, and one of the things I wanted to do is to identify my domains, group them up and enforce proper boundary/domain design. There's an excellent package, boundary in Elixir that can help with that, but the first step is for me to identify my domains first.

Phoenix ships with the concept of Contexts, which sort of nudges you in the right direction, but in the beginning things are pretty unclear so it is difficult to map out the domain upfront. Instead, I think it makes more sense to run your app in production and let the domain emerges itself.

Anyway, while I was doing that, I identified a few domains, and one of it is what I now call Messaging. The responsibility of this domain is to communicate with users, and in Slick's current set-up, there are three ways to do that:

Push Notification (when user receives a newsletter)
Email (when I send user an email to their personal email address)
Issue (when I send user an Issue in their Slick inbox)

The first two are self-explanatory. For the third one, Issue is a Slick entity. Slick is a newsletter inbox app, when an author sends users an email, it gets parsed into an Issue, which is then shown on the users' Inbox. One could argue that it's fundamentally the same thing as email, and one won't be too far off, but sending an Issue is a closed-loop action, there's no need to make a call to an Email Service Provider.

Anyway, now that I've established the three data type I want to be able to send/deliver to user, I thought this was a perfect use case for protocols. From what I know, protocols are meant for doing an action based on data type, which is exactly what I have right now. Protocols it is then!

I start off by describing what action I want. If you paid attention to my language earlier, you can see that I want to send/deliver something. That's my action. With this in mind, I created a protocol called Courier, which does one thing.

defprotocol Courier do
  def deliver(data)
end

Now, the next thing is to implement the protocol.

For Push Notifications, I use the Pigeon library to interface with FCM. My initial implementation was pretty crude, I was passing data around, and the function signature looked something like this:

def notify(user, title, message) do
  ...
end

It looked fine to me at first, I am passing in the user, then the title and then the message, but in reality there's a lot mangling with the parameters to fit into what Pigeon/FCM expect, and I figured with the protocol idea, why don't I create a new struct to hold this data? That's where I came up with Push.

defmodule Push do
  defstruct user: %User{}, body: %{}, data: %{}
end

I would also need to implement the protocol, so it ended up looking something like this:

defmodule Push do
  defimpl Courier do
    def deliver(%{user: user, body: body, data: data}) do
      result =
        user
        |> fetch_tokens()
        |> Enum.map(&do_send_push(&1, body, data))

      {:ok, result}
    end
  end
end

With this, I implemented my Context APIs like this:

defmodule Messaging do
  def send_push(user, issue) do
    body = ...
    data = ...

    %Push{user: user, body: body, data: data}
    |> Courier.deliver()
  end
end

I only send push notifications when an issue arrives in their inbox, so I can just pass in the Issue directly here. Keep in mind though, my Protocol still knows nothing about Issue, it has the perfect shape of data it needs with %Push{} to do its FCM magic.

I am pretty happy with this so far, and that's basically it really. The other two context APIs look pretty much the same, so there's not much to talk about:

defmodule Messaging do
  def send_mail(user, template, assigns \\ []) do
    %Mail{user: user, template: template, assigns: assigns}
    |> Courier.deliver()
  end

  def send_issue(user, issue) do
    Courier.deliver(issue)
  end
end

Frankly, I still don't really have the heuristic to decide when to use protocols vs behaviour, but I hoped by sharing my experience it could maybe bring clarity to you.

Do you have any heuristics that you can share when to use protocols vs behaviours, or do you have resources you'd recommend about domain driven design (I'm especially interested in Phoenix code), I'd love if you could share them with me!

ElixirConf US 2019 and the future of Elixir

Edison Yap — Fri, 30 Aug 2019 15:44:32 +0000

For those of you who aren't familiar with Elixir but are interested in the language, I compiled a little Resources section down below, feel free to get some inspiration from there! What's a better time to jump into Elixir? :)

As some of you may know, ElixirConf US 2019 is currently running over at Gaylord Rockies Resort, Colorado!

The best thing about it is, even though the conference is still running, the videos are already out, check them out over at YouTube! I think it's pretty amazing that the videos come out so quicky so people who aren't able to attend don't feel as left out :)

There are a plethora of interesting things that are happening and frankly I haven't even had time to go through all of them yet! Some of those are:

Lumen, an alternative BEAM implementation implemented in Rust, designed for WebAssembly, although the main goal is not to replace BEAM, it does seem like it could eventually head there! (Side note, I think a Rust-based VM is pretty exciting, just like what Enigma is trying to do.)
Elixir's Future (Stability + Extensibility, better deployment experience, better tooling experience like tools to help aid Code Analysis, ExUnit now diffs for pattern matching as well)

Just thought we could start a conversation here on dev.to, otherwise, the Elixir community is also on elixirforum.com and also very active on the Slack channel over at https://elixir-slackin.herokuapp.com, join us!

Resources

If you're new to Elixir, here are some great resources to get you started:

The official Elixir website
ElixirSchool, a community-driven website to help make Elixir easily accessible!
The amazing books, Programming Elixir by Dave Thomas and also Elixir in Action by Sas̄a Jurić
My personal favourite, Elixir and the OTP, video-based tutorial from Pragmatic Studio. I basically learned my Elixir crafts from here!
Other video resources like ElixirCasts and Alchemist Camp are also great!
If you're into podcast, I'm a big fan of Elixir Talk, they're perfect for your commute so definitely check them out!

P.S: With courtesy from ElixirForum (probably the biggest Elixir community forum?), you can sometimes get up to 40% off the learning resources! Just try to input elixirforum whenever you try to checkout :)

Introducing `Rocketman`, a gem to help you do Pub/Sub code in Pure Ruby. No Rails needed!

Edison Yap — Sat, 10 Aug 2019 15:52:55 +0000

Publishing my second Ruby gem here with the community, introducing Rocketman!

Description

Rocketman is a gem that introduces Pub-Sub mechanism within Ruby code.

As with all Pub-Sub mechanism, this greatly decouples your upstream producer and downstream consumer, allowing for scalability, and easier refactor when you decide to move Pub-Sub to a separate service.

Rocketman also works without Rails.

edisonywh / rocketman

🚀 Rocketman help build event-based/pub-sub code in Ruby

Rocketman

yes, I know it says Starman on the image

🎶 And I think it's gonna be a long long time 'Till touch down brings me round again to find 🎶

Rocketman is a gem that introduces Pub-Sub mechanism within your Ruby code.

The main goal of Rocketman is not to replace proper message buses like Redis PubSub/Kafka, but rather be a stepping stone. You can read more about the rationale behind the project down below.

Rocketman also works without Rails.

Installation

Add this line to your application's Gemfile:

gem 'rocketman'

And then execute:

$ bundle

Or install it yourself as:

$ gem install rocketman

Usage

Rocketman exposes two module, Rocketman::Producer and Rocketman::Consumer. They do exactly as what their…

View on GitHub

Usage

emitting events look as easy as this:

emit :hello, payload: {"one" => 1, "two" => 2}

and listening for events look like this:

on_event :hello do |payload|
  puts payload
end

There’s more information on the Usage section and Roadmap if you’re interested in the project, otherwise, feel free to comment here too!

How do you do API versioning?

Edison Yap — Wed, 24 Jul 2019 13:19:08 +0000

Recently been thinking how to do API versionings, and realised there's multiple ways of doing things. I do not think there's only one right way , but I am really curious to hear what you people have to add!

There's mainly a couple of questions I'm wondering (I wish dev.to has the polls features out already!)

Do you prefix the version to the resource, or suffix it to the resource? e.g: /v1/users/ or /users/v1/?
When you have a breaking change for a specific action (POST /users now take different params), do you bump the whole /users version, or do you bump that specific POST /users action?
Where do you keep the serializers? in the same folder, or different?
APIs are usually backed up by business logics, in some cases being called Service Objects in Rubyland — do you guys also bump your Services when your API is updated?

For more concrete example, let's say you have an API to reset password for user, eg: /v1/users/:id/reset_password, then for some reason you have a breaking change for /reset_password. What do you do now?

Bump the entire resource to v2 (e.g: /v2/users, /v2/users/:id, /v2/users/:id/reset_password)
Bump only specific action (e.g: /v1/users, /v1/users/:id, /v2/users/:id/reset_password)
Rethink versioning to scope by action instead (e.g: /users/v2/:id/reset_password)

In my opinion, this makes sense to me:

api/
 |> users/
     |> v1/
        |> api.rb
        |> serializer.rb

Couple of things I'm doing here:

I suffix the version to resource, not prefix (breaks REST)
I place serializers and endpoint in the same file

So whenever there's a breaking change in API (e.g: parameter changes), I think it logically makes more sense to bump the whole resource even if it's just one action, reason being as follow:

Deprecation is easier - if you know that /v1 endpoint is not being used anymore (through your APM), then just delete off the whole folder itself without worrying it'll impact other part of the app. No need to ask questions like: "v1 is still in use except for this specific action, for that it'll be in v2"
Locality - I think that inherently serializers are just a way to serialize your data into JSON, and so it should be versioned the same way as your API. By putting them in the same folder, it ensures that you're more likely to update both of them at the same time, and it also makes it much easier for developers to see which API is using which serializer.

So, what do you guys think/do currently?

Introducing `Behaves`, a better way to define contracts/behaviors between classes

Edison Yap — Fri, 07 Jun 2019 15:30:54 +0000

Hey guys!

I just published my first gem on RubyGems, and would love to hear your feedback!

edisonywh / behaves

Define behaviors and contracts between your code.

Behaves

Behaves is a gem that helps you define behaviors between classes. Say goodbye to runtime error when defining behaviors.

Behaves is especially useful for dealing with adapter patterns by making sure that all of your adapters define the required behaviors. See usage below for more examples.

Detailed explanations in the sections below.

Installation

Add this line to your application's Gemfile:

gem 'behaves'

Usage

This is how you define behaviors with behaves.

First, define required methods on the Behavior Object with the implements method, which take a list of methods.

class Animal
  extend Behaves

  implements :speak, :eat
end

Then, you can turn any object (the Behaving Object) to behave like the Behavior Object by using the behaves_like method, which takes a Behavior Object.

class Dog
  extend Behaves

  behaves_like Animal
end

Voilà, that's all it takes to define behaviors! Now if Dog does not implement speak and…

View on GitHub

Description

Behaves is a gem that helps you maintain contracts between different classes. This is especially useful for dealing for adapter patterns by making sure that all of your adapters define the required behaviors.

The idea for Behaves stemmed from my research into adapter pattern in Ruby and José Valim's article on Mocks and explicit contracts.

I found that the current idiom to achieve behaviors in Ruby is through Inheritence, and then subsequently defining a "required" (I put quotation marks around it, because it's not exactly required until you run it) method, which does nothing except raising a NotImplementedError. While I don't necessarily think it's bad, I do think that there could be an alternative that's more explicit, less boilerplate, cleaner ancestors hierachy, thus the birth of Behaves.

Best of all? No more runtime errors for defining behaviors!

Do let me know what you think!

A Tale of Curiosity at work - work doesn't have to be boring

Edison Yap — Sat, 01 Jun 2019 06:45:00 +0000

Well my usual articles are dead boring so today I'm going to switch it up a bit. Today I'm going to talk about, a day at work. Or if you will, A Tale of Curiosity. I promise it'll be fun, or at least I'll try to make it so.

Recently my team and I have been integrating with a third-party API, and I was tasked to translate the error returned by the third-party API into something that we can show to our user.

For example, if the third-party API responds with:

{
  "code": "123",
  "message": "Error message from third-party"
}

We do not necessarily want to render their message to our users, because it could very well be some random error that user would not understand (e.g Required argument is not passed in), also the fact that by mapping their error codes to our own allows us to control the tone and voice of our company. So, time to work!

After a bit, I was done with my task and I sent it off to a co-worker for review, like hooray, time for the next task.

He came back to me in 5 minutes and asked: why did you do it this way?

The pull request in question looks like this:

In fact, he was specifically asking me why did I choose to memoize my error_hash method?

The conversation went like this:

C: Hey why did you memoize this hash?
Me: Well, we're going to be accessing this rather often, wouldn't want to recalculate it again and again since this value is not going to change.
C: But you only really memoize for expensive computation, such as database calls, API calls etc.
Me: That makes sense, but I want every single call to error_hash to return me the same object, so it's more memory efficient that way.
C: I don't really see that as a good reason. And is that really how it works?
Me: Honestly I'm not quite sure, I just sort of assumed that. Can I get like 10 minutes to run a benchmark to figure it out?
C: You bet.

So I decided to do a quick benchmark to see if my hypothesis was right (and because I'm going to prove that little sucker wrong): that memoizing will return me the exact same object in memory, while if I don't, a new Hash gets generated every time.

Since this is a case of interacting with the Ruby memory, I turned to my best friend ObjectSpace (whom I've mentioned in a couple of my article). ObjectSpace basically allows you to interact with the living objects at runtime. Perfect fit for us!

I took about 10 mins to whip up this quick script. You can take a look at the code if you'd wish, but basically what I had hypothesized was accurate, that if I don't memoize it'd generate a lot of extra objects in memory.

However, did I go with my approach? Nope. He then asked me why didn't I just used a constant, and I realized that's exactly what I wanted, so I've updated my solution to use a constant instead.

Takeaways

Well if there's one thing that I hope you can take away from this is that you should be open to learning/feedback.

Let's take a look at this:

My colleague has questioned me, not in the tone of superiority, but genuine curiosity as to why I did what I did.
I explained why I did and he did not really agree with it, but we decided that I can run some tests to back up my claim.
I did exactly that, and now we have more data to be used in our judgement.
We both assessed the new information and decided that there's a better way (constant), and we both chose to let down our previously held opinion and go with what's the best solution.

This little interaction took maybe about tops of 15 minutes? And within 15 minutes we were able to learn more about Ruby internals and go home with more knowledge.

What looked like a mundane task at first had just turned into an interesting learning session, and it only happened because we were both curious. Trust me, curiosity doesn't kill the cat, let loose and let your curiosity roam free!

I hope by reading this, I had encouraged you to hold the mind of a curious and ask yourself, is there something I can learn from this, no matter how mundane the task looks.

If you have any similar story where you managed to turn a mundane task into a great learning opportunity, feel free to share them down in the comments!

Right, better head back to work now before my manager taps on my shoulder. (well he doesn't really do that..)

Function/Method look up in Elixir/Ruby

Edison Yap — Thu, 21 Mar 2019 10:31:17 +0000

So to preface, I'm a Ruby dev learning Elixir. I love to compare what I'm learning in Elixir back to what I know in Ruby, as I think that really strengthens my understanding of both languages. Today, I want to talk about function/method look up.

This article was prompted when I was learning about GenServer through PragmaticStudio's course (I highly recommend it), and they mentioned that GenServer can inject default implementations of functions if you do not define them manually. These default functions are:

init/1
child_spec/1
code_change/3
terminate/2
handle_info/2
handle_cast/2
handle_call/3

And if you want to override them, just define a function in the current module with the same signature (name + arity).

But this got me thinking, how is it that Elixir look up function definition that makes this possible?

Before we jump into Elixir, let's first look at how method lookup in Ruby works.

Your dad, your dad's dad, and your dad's dad's dad.

I have actually blogged about this before, which was retweeted by Matz himself! (I actually have no idea how much this actually means, but I'm still going to wear it like a badge of honor)

Ruby has no class methods

Edison Yap ・ Nov 9 '18

#ruby #rails

Ruby's method lookup chain can literally be summarized in one method call - ancestors.

Foo = Class.new
Foo.ancestors # Lookup path for instance methods
#=> [Foo, Object, Kernel, BasicObject]

Foo.class.ancestors # Lookup path for class (singleton) methods, read my blog to learn more!
#=> [Class, Module, Object, Kernel, BasicObject]

That's it -- that's how you see the entire method lookup chain for Ruby!

In fact, #ancestors is defined on BasicObject itself, so when you call Foo.ancestors, it asks this:

You: Do you implement `#ancestors`?

- Foo: No
- Object: No
- Kernel: No
+ BasicObject: Yes I do!

And that's how it works!

With that, we know that if we want to inject a function into Ruby, we just have to make sure that the newly injected function is the first method that gets found during the lookup (defining #ancestors anywhere before BasicObject).

So, Ruby is able to do this because of ancestors, but Elixir doesn't really have the concept of ancestors/inheritance, so what is really happening here?

It's about time to stop guessing, so I decided to try out an example myself.

defmodule Parent do
  defmacro __using__(_opts) do
    quote do
      def injected do
        "This is from Parent"
      end
    end
  end
end

defmodule Child do
  use Parent

  def injected do
    "This is from Child"
  end
end

My expected behavior is that my Parent.injected/0 will be overriden by my Child.injected/0, but when I try to run this file - iex lookup.exs, the following warning message pops up:

warning: this clause cannot match because a previous clause at line 12 always matches lookup.exs:14

Weird warning, but let's try to actually run it.

iex(1)> Child.injected
"This is from Parent"

To my surprise (well the surprise is kinda ruined when I saw the warning message), running Child.injected returns me Parent.injected/0 instead of Child.injected/0, why?!

I decided to dig into the doc and find out why, but the docs isn't really tell me much apart from the fact that GenServer will inject functions for you. But I already knew that, I just want to know how is it doing so.

So, docs didn't help, what next?

Source Code!

As like most other languages, Elixir is open source, so I could very easily dive into the source code itself.

Now I see something suspiciously named defoverridable, and I have a hunch that this might be it, but I want further proof to my hypothesis.

A quick Google about defoverridable sent me to a post in Elixir Forum, written by the man himself, José Valim.

Solution

So through that post I found out that I can use defoverridable, which would mean that I can update my code to the following:

defmodule Parent do
  defmacro __using__(_opts) do
    quote do
      def injected do
        "This is from Parent"
      end

+     defoverridable injected: 0
    end
  end
end

defmodule Child do
  use Parent

  def injected do
    "This is from Child"
  end
end

And now if we run it..

iex(1)> Child.injected
"This is from Child"

Voilà it works! Perfect 🎉

Conclusion

In his post, José clarified defoverridable for me, but he also went on to say that defoverridable is not recommended, and they are in fact moving towards to @optional_callback to mark methods as optional, along with an enhancement @impl (which the compiler will use to make sure "child" implements that function), so that was also an interesting thing that I learned. I recommend you to read the post and comments to understand it a little more.

My query was literally answered in the first 10 lines of his post, so it would've been really nice if I managed to find it in the first place. Then again, if I hadn't went into the source code I wouldn't have known what keyword to look for, and thus won't land at that post.

Still, an interesting journey for me because at one point I thought Elixir had inheritance like Ruby, heh.

(also, title is technically incorrect as Elixir does not really have "function lookup" - all it does is just look at the current module!)

Elixir's If and Elixir's Do

Edison Yap — Tue, 12 Mar 2019 15:50:57 +0000

So recently I came across the fact that Elixir is full of macros, and that it allows you to interact with its internal syntax tree pretty easily (using quote), and I thought that was a pretty cool thing.

In the simplest of terms macros are special functions designed to return a quoted expression that will be inserted into our application code. -- Elixir Lang

One example that I came across was the following -- say we have an expression that we want to evaluate:

if true do
  "hello world"
end

But sometimes you want to write a single-line expression. No problemo amigo, Elixir's got you covered!

if true, do: "hello world"

This statement is a single line long, but it excites me enough to write a post about it. Let's dive into why!

There are three things to note here in this one, simple expression.

There's a comma before do
There's a colon after do
There's no end keyword

These three are hints to a reveal that blew my mind.

The if statement you just saw? It's not really a language keyword, it's just a normal function (in fact, it's a macro).

The do block you just saw? Not a language keyword either, it's a keyword list (well technically it's a keyword list keyword according to source code). If you don't know what a keyword list is, keep reading, I explain it a little further down.

How did the hints help?

Let's revisit the hints and see how the hints help us uncover the truth which has been hiding in plain sight all along!

1) Comma

If you paid attention earlier, the first hint points out that true and the do statement are separated.

Do you know what else is separated? Function arguments.

if statement is really just a function that has arity of 2, first being the condition to evaluate, second being the action to do, and the comma separates the two arguments.

This means that we can translate our earlier statement to look like this, and it'll still work.

iex(2)> if(true, do: "hello world")
"hello world"

All I did was add brackets around it - don't they look a lot more familiar now? ;)

2) Colon

The second and third hints are actually very closely related, because they both point to one thing: keyword list.

Let's take a refresher on what a keyword list is, or what it looks like.

Official definition on Keyword List

A keyword is a list of two-element tuples where the first element of the tuple is an atom and the second element can be any value. - Elixir Lang

We know what a list looks like ->[]

We know what a tuple looks like -> {}

So, a keyword list looks like this:

[{:atom, "any_value"}]

Alright that doesn't look very nice/easy to type out, so Elixir provides a syntactic sugar to write a keyword list like this:

[atom: "any_value"]

At this point, we can use this newfound logic to apply back to our previous if statement, and that translates to this:

iex(2)> if(true, [do: "hello world"])
"hello world"

Again, all I did here was add square brackets around the do keyword, and it's beginning to clear up what they are.

In fact, we could get a little crazier with the original syntax of keyword list..

iex(2)> if(true, [{:do, "hello world"}])
"hello world"

Hooray, still works!

3) Where's the `end`? (and proofy time!)

Alright, so I've told you that they're the same thing and that they all work exactly the same, but as far as you're concerned I could be blabbering random shits (Although I promise I'm not). So let's prove that what I said was right!

I have also yet to tell you about the 3rd hint, which is - where did the end keyword go?

So, the end is actually completely ignored because there's no real need to represent an end of statement in an Abstract Synax Tree -- you should be able to infer it from the syntax tree itself. I also show evidence of this in Elixir's source code later on.

I won't talk too much about AST partially because it's a whole another topic on its own, but also because I honestly also don't know enough about it (😬) but a quick primer/what I understand so far here:

AST is how the machine understand the flow of code. It builds a tree based on the programming languages' syntax and how machine execution should flow.

In an essence, you write a block of text (the code), and the language tries to understand it (parses), and then it creates a mental model of what it currently understands (the abstract syntax tree).

The reason why I'm running the different expressions to produce an AST to prove that they're the same is because, the same-ness of the code isn't depended on any syntactic sugar, but rather what the language really understands from it, and in our case, it's the mental model (AST) of the language.

Time to verify!

first = quote do
  if true do
    "hello world"
  end
end
# {:if, [context: Elixir, import: Kernel], [true, [do: "hello world"]]}

second = quote do
  if true, do: "hello world"
end
# {:if, [context: Elixir, import: Kernel], [true, [do: "hello world"]]}

third = quote do
  if(true, do: "hello world")
end
# {:if, [context: Elixir, import: Kernel], [true, [do: "hello world"]]}

fourth = quote do
  if(true, [do: "hello world"])
end
# {:if, [context: Elixir, import: Kernel], [true, [do: "hello world"]]}

fifth = quote do
  if(true, [{:do, "hello world"}])
end
# {:if, [context: Elixir, import: Kernel], [true, [do: "hello world"]]}

We can run a final check to check if they all equal to each other!

first  == second #=> true
second == third  #=> true
third  == fourth #=> true
fourth == fifth  #=> true

I'll be frank, I don't know how Elixir actually decides to continue reading/parsing the statement until an end is met, I feel like there's a whole another topic of lexing, parsing and tokenizing that I'll need to understand first (along with AST, which I will, but not yet!)

BUT! What I can add to support this article is the evidence that when Elixir outputs the AST back as a string (with Macro.to_string/1), they have to explicitly append the end word into the outputted string, as seen from here!

Takeaway

if true, do: "hello world"

There's two things that I learned from just this one simple line of code, and that is:

if is just a language macro (it expands down to a case statement), and in fact, there's a whole new world about meteprogramming/macros in Elixir's world!
do is nothing more than a keyword list.

I had thought that basic things like if statements or declaring a function should be core language features with special meanings, but Elixir is able to beautifully build upon fundamental features like AST/keyword list and use that to build out other features.

This also means you can build any sort of macro that you want! Want to build an unless feature like in Ruby? You can do that (as shown in Elixir official guide), want to build a while loop?, you can do that too (Chris McCord shows this in his introductory video to Metaprogramming Elixir).

In fact.... let me just leave you with one thing. def itself is a macro, defined using defmacro. And defmacro itself is a macro, defined using defmacro. Mind blown yet? If not feel free to re-read that sentence until you do. Read more here.

Author's note

I've probably glossed over a lot of details (particularly about AST) because frankly, I do not understand them well enough yet (and the point of the article is not really on AST, they're just a means to proving they're all equal without the syntactic sugars).

But this means I know exactly what I'll be diving into next, and I can't wait to learn more about lexers, parsers, tokenizers and ASTs :) If you have any good resources on them, comment down below ⬇️, I'd really appreciate them!

P.S Credit where credit's due, I learned about this from the Elixir Slack channel over here, Martin Svalin was explaining that they're all equivalent, and I decided to dive a little deeper and explore the AST to verify what he's saying. Spoiler: he's right!

[ Elixir | Why Linked Lists? ]

Edison Yap — Tue, 12 Feb 2019 13:00:02 +0000

I've always thought data structures are cool, but you know what's cooler? Seeing them in the wild!

While going through Elixir's doc, I saw that Elixir uses linked lists under the hood for their linear data structure. I thought this was cool, but something struck me; I understood arrays and linked lists, but I had no idea how it relates to programming languages and it's bothered me ever since and I need to find out why linked list was used, hence this article!

So back to the article, from what I've found so far, there are three reasons as to why Elixir does this (and I could be totally wrong, feel free to correct me!). Let's go through one by one:

Immutable Data

In Elixir, (most functional languages actually), data are immutable. This is an important first step to understanding why linked lists is used, so let's explore this.

Immutable means that once a data is declared, it cannot be mutated/changed anymore.

Assuming you know how arrays work under the hood (check out my other article if you want a refresher). Let's take a look at what happens if we try to implement immutability with an array!

Array is defined as a continous block of memory. The problem with this is that, an array of 5 elements is still just ONE array, and when we are adding/deleting an element, we are MUTATING it. How can we use immutability with arrays then? It's not impossible, but let's look at why that's not practical.

If we want to enforce true immutability in arrays, this means that we need to make a full copy of the old array everytime we want to add/delete in the array.

Which means, if you have an array of size 5, if you want to add a new item to the array, your memory usage is instantly doubled (because you need to keep the old array as is, and you also need to make a new array of same elements). And that's just space complexity, there's also time complexity that we need to think about!

A linked list doesn't have the same constraint, as the nodes are all stored separately in memory, which means we don't really need to worry about space/time complexity while adding/delete nodes in list.

This gives us our first reason as to why it uses a list, however that's not the whole story - here's where recursive structural/tail sharing jumps in and everything starts making sense.

Recursive structure

Did you notice that linked lists are recursive by definition?

For example, A -> B -> C -> D is a linked list, but so is B -> C -> D, C -> D and so on, and each linked list is just a sub structure of another linked list!

Well that wasn't very exciting on its own, but this is vital to the next piece of puzzle!

Fun Fact: The recursive nature coupled with the fact that datas have to be immutable (so you can't have a loop counter) is why functional languages are usually associated with recursions - they kinda have to!

Structural/Tail Sharing

So, we know linked lists are recursive in nature. Combined with the immutable nature of the language, we know that the data can never change.

This is interesting, because now we can confidently say that A -> B -> C -> D is a different list from B -> C -> D (even though one recursively contains the other one), and because we have that guarantee (along with the fact that a list CAN'T change), we don't have to define the same datas twice, and we can reuse existing linked lists! This is called Structural sharing.

Awesome isn't it? Let's look at an example.

e.g:

list = [5,6,7,8]
list_one = [1 | list]
list_two = [2 | list]

Now we have THREE different lists! list, list_one and list_two, but all of them share the same reference (the tail) and the only difference between them is the head pointer.

This means that there will be a total of 6 elements in memory. Adding to list has low memory cost, while retaining the immutability that we desire.

Reusable baby!

If you want to read a little more, you can look into Trie trees which have the exact same concepts of sharing datas/prefixes!

Garbage Collection & Caching?

These two I'm not quite sure, but I've heard that linked lists are good for GCs and that tail sharing makes a good candidate for locality of reference/caching (I don't get how, because they aren't stored in the same places). Would appreciate if someone wants to chime in!

Closing Note

Sidenote, in actuality it's not as much about Elixir since it compiles down to Erlang, but also not much about Erlang because all functional programming does pretty much same thing, but this is what prompted my curiousity hence the ties to Elixir.

While writing this article, I found that I had to write in depth on how arrays work before I was able to dive into the Elixir part, so I've published that as another article over here instead; do read that to gain a better understanding on what the tradeoff is!

How arrays work the way arrays work

Edison Yap ・ Feb 12 '19

#ruby #computerscience #c

I also did not really talk about Big O notations because I felt they might add unnecessary reading time and complexity to the article, but they're pretty vital and fundamental to computer science, so I suggest you brush up a little on them.

If you're a podcast kind-of person, there's the BaseCS by CodeNewbie, co-hosted by Vaidehi Joshi and Saron.

If you want to read though, Vaidehi Joshi's blogpost version (which is what inspired the podcast I believe) is great too on BaseCS Medium.

As for video, MyCodeSchool is beyond amazing and is pratically where I learned everything that I know now, highly recommended!

Other than that, hope you guys enjoyed the article as much as I enjoyed writing it!

Sources

https://elixir-lang.org/getting-started/basic-types.html#linked-lists - The piece that prompted this article

How arrays work the way arrays work

Edison Yap — Tue, 12 Feb 2019 12:59:31 +0000

In computer science, there is the concept of linear data structure, which means that the datas are structured in a linear way in which order matters. There are Array and Linked Lists, but today I'll be talking mostly about arrays only, and a little about linked lists.

Most object-orientated languages come with Arrays, whereas most functional languages comes with Linked Lists (see why in another one of my article, mentioned at the bottom of the article).

There's a good reason for this differentiation which we will dive into later, but for now let's just have a quick revision about what are the differences between the two data structures, and to know this, we'll need to take a trip down memory lane.

Rewind Time

Objects and functions and everything that we know about computers, are fundamentally stored in bits and bytes in computer.

In languages like Java and C, you have to explicitly declare the size of an array beforehand.

Hold up, but Ruby does not do that?

In Ruby, we use Array for our linear data structure, we can add seemingly infinite stuffs into an Ruby array and it would not matter as far as we are concerned.



array = []
while true
  array << 0
  puts "#{array.length}"
end

That's great isn't it?! That means arrays are infinitely large right? And that Ruby is the superior language? Lucky us!

But not so fast. *pops your bubble*

There are no infinite size array, what you see in Ruby is what we call a Dynamic Array, and it comes with a cost.

To understand what dynamic arrays are, let's first take a look at how arrays are represented in memory. Since MRI Ruby (Matz' Ruby Interpreter) compiles down to C code, we'll look at how arrays are represented in C.

C-ing is believing

We'll dive into a little bit of C code to help us C a little better.

In lower level languages like C, you have to deal with pointers and memory allocation yourself, and even if you had not dealt with C before (Disclaimer, neither have I), you may have C-een one of the most (in)famous example below:



/* Example */
ptr = (cast-type*) malloc(byte-size)

/* Usage */
ptr = (int*) malloc(100 * sizeof(int));

taken from https://www.programiz.com/c-programming/c-dynamic-memory-allocation

Let's break down this bits of code:

malloc doesn't have any magic meaning behind it, it literally stands for memory allocation
malloc returns a pointer
malloc takes in an argument, which is the size the memory you want the program to allocate for you.
100 * sizeof(int) tells the program that we want to store 100 integers, so allocate us 100 * the size of what each integer would occupy.
ptr/pointer stores reference to the memory address.

Timmy stores luggage!

If the above example did not really make sense, try this analogy. Think of memory allocation as like, a luggage concierge. It works like this:

Timmy goes to the counter, tells the concierge that he have 2 pieces of luggages, about this big, and that that he'd like to store it in the storeroom.
The concierge takes a look over the store room and go "Yes, we've got some room at the designated B4 area and will allocate that space to store your luggages".
They hand Timmy a pick-up card with the designated area on it, B4 in our case.
Timmy is happy, goes around doing whatever, and when he wants to pick-up his luggages, he goes back to the counter and show them his pick-up card. "Have you C-een my luggages?"

In our example, Timmy's luggage is the data, the pick-up card is the pointer (it states where Timmy's bag is stored). The place that the concierge is storing Timmy's luggage is the memory block, and the counter is the program.

By showing the counter (the program) Timmy's card (pointer/memory address), Timmy can retrieve his luggage (data). Bonus? Because they know exactly where Timmy's bag is stored -- B4, this means that they can retrieve all Timmy's luggages relatively quickly!

Also, ever wondered why you access elements in array with index, like so?



array[0] # => first element
array[5] # => sixth element
array[99] # => hundredth element

This is because array holds the references to the memory block, and the index is telling it the offset.

An analogy of that is if I ask you to look for Timmy in a queue of 20 people, you would logically have to ask each of them if they were Timmy -- But, if I told you Timmy is the 6th (index) from the first guy (your original pointer), you know exactly where to look.

Retrieving elements in arrays are fast exactly because of this - the program doesn't have to look through all 100 elements to find what you're looking for - if you've got the index, it just has to add the offset to the original memory address, and the droid that you were looking for will be right there!

What are dynamic arrays then?

So I've told you a little about how array is represented in memory, but now it's time to talk about some cons.

Remember how you have to explicitly declare the amount of memory you need? This means that the array will find a spot that will fit exactly your size; there's no guarantee that it will be able to fit more than what you have (because the memory block right behind it might be occupied).

Back to our luggage analogy, think of it as if Timmy was to store 2 pieces of luggages, and B4can store exactly 2 luggages, so they allocate that to Timmy. Now for some reason Timmy wants to store another piece of luggage, but B4 can't store 3 luggages, only 2, so what do they do?

They take all of his existing luggages, move it into a new spot that can fit more than 3 luggages, and then store all of them together.

That is an expensive operation but it's exactly how memory works too!

In Ruby, you don't have to declare a specific size before hand, but that's because Ruby handles it for you automagically through dynamic array.

What dynamic array does is that if the array is nearing its full capacity, it'll automatically declare a new, bigger array and move all existing elements into it, and the old array is then garbage collected. How much bigger? The growth factor is usually 2; double the size of the current array.

In fact, don't take my word for it.

Ruby has a ObjectSpace module that allows us to interact with current living object in memory. We can use this module to take a peek at the memory usage of our dynamic array, sounds exactly like what we want!

I have written a small Ruby script that calculates the growth factor of the dynamic array. Feel free to take a look at it here, and if you do, you can see that Ruby arrays have a 1.5x growth factor (that is, they make an array that's 50% bigger on every copy)

I know what arrays are, what are linked lists?

Keep in mind that although arrays and linked lists are both considered as linear data structures, they have one big difference amongst them.

Elements in an array are stored literally right next to each other in memory (so we can have index for fast lookups), but nodes in linked lists have no such restriction (which is why there's no index lookup for linked lists) - each and every item can be stored anywhere on the memory block and it'd be fine.

It's almost as if Timmy's trying to store 5 luggages, and the concierge does not have a space and decides to leave 5 of them all over the place. Sounds unorganized?

Also if they are stored in different places, how do you know which bags are Timmy's? Hint: Just keep track of the next node/bag! In our case, the concirege keeps them separately but with a tag on each of them that points to the next bag.

A node in linked list consists of two parts - the data part and a pointer to the next node. This is how they're able to maintain the linear part of it -- they still have the concept of order, they just don't have to be stored in order literally!

node = [ data | pointer ]

For example, given the following example stored in memory:

[C | D] [A | B] [B | C] [D | nil]

This bits look like it's out of order - but if I had told you that the first element is A, you would be able to tell me the exact order of the list:

list = [A -> B -> C -> D -> nil]

There's a lot of interesting things that you can do with linked lists which I'm not going to dive into (also a lot on Big O that I didn't talk about), there are already a tonne of good articles out there on data structures. If you made it here, I suggest you to read from Ali's blogpost here.

thank u, next: an introduction to linked lists

Ali Spittel ・ Dec 5 '18

#datastructures #beginners #programming #javascript

You can also read more about List/Cons on Wiki here

Closing Note

I initially wrote this article for a slightly different topic - [ Elixir | Why Linked List?], but found it took way too long to explain how arrays work before I was able to explain explore why Elixir uses linked lists, hence I have separated them into two separate articles.

In that article I talk about why functional langauges use linked lists as their linear data structure. Do check it out!

[ Elixir | Why Linked Lists? ]

Edison Yap ・ Feb 12 '19

#elixir #computerscience #functional

Sources

1) https://medium.com/@rebo_dood/ruby-has-a-memory-problem-part-1-7887bbacc579 - This is where I found out about additional ObjectSpace methods by requiring it

Recursion, Tail Call Optimization and Recursion.

Edison Yap — Fri, 30 Nov 2018 09:27:31 +0000

Recently I thought I'd take a jab at functional languages just to try out a different paradigm of thinking, and I decided to pick up Elixir since it's so syntatically similar to Ruby. While I was learning, I found something.

TLDR:

Elixir has no loops

Recursion makes an additional call to call stack (which is why your stack overflows if you forget your base case)

Tail Call Optimizations is a compiler feature that optimizes recursions (if the last thing it does is call itself)!

There is no concept of loop in Elixir.

Yes, none of your for loops or .each. It's a bit of a strange concept at first, but let's see what's the alternative.

If you can't use an iterative approach to iterate a loop, how do you traverse a list? Recursion.

Brief recap: Recursion is when a function calls itself, like this

A Ruby Example:

def traverse(tail)
  head = tail.shift # shift takes out the first element
  puts "Element: #{head}"
  return if tail.empty?
  traverse(tail)
end

An Elixir Example:

defmodule Recursion do
  def traverse([]), do: IO.puts "Done"
  def traverse([head | tail]) do
    IO.puts "Element: #{head}"
    traverse(tail)
  end
end

Pretty interesting to traverse recursively instead of the iteratively aye?

LARGE NUMBERS!

Next, let's see what happens when it comes to a large number!

Ruby:

large_array = Array.new(500_000).fill { |i| i + 1 }

traverse(large_array)
# Element: 1
# Element: ...
# Element: ...
# Element: 10918
#=> stack level too deep (SystemStackError)

It crashes with a SystemStackError! Wow, does that mean recursion is bad? does that mean recursion is bad? does the mean recursion is bad? does that mean recursion is ... Okay, before we go crazy, let's take a look at how Elixir deals with it.

Elixir:

start = 1
increment = 1
length = 500000
list = Stream.iterate(start, &(&1 + increment)) |> Enum.take(length)

Recursion.traverse(list)
# Element: 1
# Element: ...
# Element: ...
# Element: 500000
# Done
#=> :ok

You can see that Elixir effortlessly handles all five hundred thousands recursion. But why does it work in Elixir but not Ruby?

Because of Tail Call Optimization!

What is Tail Call Optimization?

Tail Call Optimization (TCO) is a compiler feature in which the compiler automatically optimizes the stack, if the last thing that a function does is call itself.

But what is the stack? and what do you mean by 'optimizes the stack'?

Stack is a data structure that employs the LIFO mindset (Last-In-First-Out), think of it as a fixed array but you can only insert from one end and take out from the same end. What we're specifically talking about here is the call stack.

To understand this better, we need to first understand how call stacks work.

When you call a function, it gets added to the call stack, and when it finish executing, it gets popped off the stack, like so:

And when you have a recursive function call, it's basically adding itself to the call stack every single time. If you forget your base case/have too big of a call stack, it throws a stack overflow error! (what we saw earlier), like this.

All TCO means is that, when the compiler sees the last call of the function is calling itself, instead of adding the function call to the call stack, it does a goto instead, and basically restarts the same function call, requiring O(1) instead of O(n) space (we will prove this later).

Now this is what it looks like when it's TCO-ed:

Do we have that in Ruby?

We do indeed! However TCO is not enabled by default, so you have to pass in the compile option during runtime, and you can do it like so:

RubyVM::InstructionSequence.compile_option = {
  tailcall_optimization: true,
  trace_instruction: false
}

require './tail_recursion.rb'

large_array = Array.new(500_000).fill { |i| i + 1 }
traverse(large_array)

# Element: 1
# Element: ...
# Element: ...
#=> Element: 500000

Not very useful if you have to enable it with a flag, but it's there if you need it!

Proof?

Got your back! In RubyLand, We can inspect the current call stack with a call to Kernel#caller. Lets .count!

Change our code like so:

def traverse(tail)
  head = list.shift
  puts "Element: #{head}, Stack Count: #{caller.count}" #=> new line
  return if tail.empty?
  traverse(tail)
end

# Normal ruby
traverse(large_array)
# Element: 1,           Stack Count: 1
# Element: ...,         Stack Count: ...
# Element: ...,         Stack Count: ...
# Element: 10918,           Stack Count: 10918
# => stack level too deep (SystemStackError)

# TCO-enabled
traverse(large_array)
# Element: 1,           Stack Count: 1
# Element: ...,         Stack Count: 1
# Element: ...,         Stack Count: 1
# Element: 500000,          Stack Count: 1

Conclusion

Alright so that's it for today! Thought it's pretty cool that I'm trying to learn Elixir but end up learning something about compiler instead!

Check out my previous articles too:

Attribution

Russian doll cover image source

Ruby has no class methods

Edison Yap — Fri, 09 Nov 2018 11:19:02 +0000

Wait…. Whaaaaaaaaaaaaaaaaaaat?

I don’t know about you, but that was my exact reaction when I first heard Nadia Odunayo’s talk in RubyConf KL 2018 (mind you, one of the most captivating talk I’ve ever heard!), in which she showed that that Ruby has no class methods.

When I first started learning Ruby, I’ve been told that Ruby basically have two types of methods:

Class Methods
Instance Methods

class Foo
  def self.class_method
    puts "This is a class method of #{self}"
  end

  def an_instance_method
    puts "This is an instance method of #{self}"
  end
end

Foo.class_method #=> "This is a class method of Foo"
Foo.new.class_method #=> undefined method `class_method' for #<Foo:0x007f83960d2228> (NoMethodError)

Foo.an_instance_method #=> undefined method `an_instance_method' for Foo:Class (NoMethodError)
Foo.new.an_instance_method #=> This is an instance method of #<Foo:0x007f80aa92d150>

Well at first, it makes a lot of sense —

A class is an object, and when you call .new on a class, you create a new instance of that object.

Hence, instance methods are only available on instances of that class.

Okay so then.. what am I talking about when I said Ruby has no class methods?

Parents. Grandparents. Ancestors..!

First thing we need to understand is something called Ancestor Chains in Ruby.

Ancestors Chains is vital to understanding how Ruby works; the entire method calling chain works because of the chain, but here I’ll attempt at an overly simplified explanation.

In Ruby, everything inherits Object , and every Object inherits from a BasicObject.

Let’s do a quick check!

2.3.1 :001 > Foo.ancestors
 => [Foo, Object, Kernel, BasicObject]
2.3.1 :002 > Foo.superclass #superclass allow us to see what class the receiver inherited from. AKA, the parent of current class.
 => Object

2.3.1 :003 > Object.superclass
 => BasicObject

(Kernel is a Module, you could quickly verify it by doing Kernel.class)

When you call a method, it calls the method on the current class; if the current class does not have that method, it goes up the ancestor chain until it finds one.

Not clear yet? I’ve gotchu! Cue weird metaphor

Imagine you’re just a kid, and that annoying Little Johnny who is trying to outsmart you asks you sheepishly: “Do you know what .planets are in our solar system? I bet you don’t!”.

Well you actually don’t know the answer, but you wouldn’t let Little Johnny get his victory, and so you make this your life goal to find out, and you ask your parents: “What are the .planets in our solar system?”. And well, your parents don’t know that either, so they go on and ask their parents, who happen to know the answer.

Now it’s your turn to smirk sheepishly back at Little Johnny and tell him what the answer is.

So now whenever someone asks you what are the .planets in our solar system, you have the answer, from your Grandparents.

How is this relevant? Well, we talked about how method lookup work, and in my last post I talked about reusing methods (Module) with include, extend and prepend. Now let’s look at their respective ancestor chains when you include, extend and prepend a module.

Awesome = Module.new

class IncludeModule
  include Awesome
end
IncludeModule.ancestors #=> [IncludeModule, Awesome, Object, Kernel, BasicObject]

class ExtendModule
  extend Awesome
end
ExtendModule #=> [ExtendModule, Object, Kernel, BasicObject]
# WHERE IS THE MODULE?!

class PrependModule
  prepend Awesome
end
PrependModule.ancestors #=> [Awesome, PrependModule, Object, Kernel, BasicObject]

You’ll realize something strange:

When you include, the module is being inserted after the current class, which means it’ll be the first thing you hit when you can’t find a method on current class.
prepend is the opposite of include; it inserts before, so technically, you still wouldn’t be able to call it.
You don’t see the module on the ancestor chain when you extend a module

Hold on, we know for a fact that when we extend a module, we get access to class methods, and we also know that method calling happen via ancestor chains, but.. how can extend work if the module is not on the ancestor chain?

The reason is because of something in Ruby called Singleton Class (sometimes referred to as Metaclass, Anonymous Class or Eigenclass)

Whenever you initialize a class in Ruby, two objects are generated — Foo itself, and Foo’s Singleton Class. To prove this, in her talk Nadia showed a great way to inspect the current count of classes using ObjectSpace. ObjectSpace is basically a way for you to interact with all currently living Ruby objects in memory.

ObjectSpace.count_objects[:T_CLASS] #=> 920
Foo = Class.new
ObjectSpace.count_objects[:T_CLASS] #=> 922

Now, before we understand what extend is doing, we need to first understand Singleton Class, so bear with me, get through the next section and we’ll then be able to understand the extend magic!

The one about Singleton Class

Singleton Class, like its alternative name, Anonymous Class suggests, is anonymous, thus does not show up in the ancestor chain(!!!) That doesn’t mean we can’t access the singleton class though, in fact, there’s a handy method called .singleton_class that we can use.

class Foo
end

Foo.singleton_class #=> #<Class:Foo>

Let’s take a look at what is the .class of the class you just created.

class Foo
end

Foo.class #=> Class

As you may have noticed earlier, there's also an alternative way to initialize a class as below:

Foo = Class.new

Looks really familiar now doesn’t it? Foo is an instance of Class.

Why is this important? Because this means that the normal Class Methods that you have come to think you’re executing on Foo is in fact, an instance method on Class. — It works because Foo is an instance of Class!

We now know singleton classes aren’t visible on ancestor chains. Remember what else wasn’t visible on the chain? The module when you do an extend!

We can check the ancestor chain of the singleton class itself.

HiddenModule = Module.new
class Foo
  extend HiddenModule
end

Foo.singleton_class.ancestors #=> [#<Class:Foo>, HiddenModule, #<Class:Object>, #<Class:BasicObject>, Class, Module, Object, Kernel, BasicObject]

# Well HiddenModule is not so hidden anymore!

We can also prove that what we come to know as class_method, is actually just an instance method on the singleton class.

module Mystery
  def resolved?
      true
  end
end

class Foo
  extend Mystery
end

Foo.resolved? #=> true
Foo.singleton_class.instance_methods.grep(/resolved?/) #=> [:resolved?]
Foo.method(:resolved?) #=> #<Method: Class(Mystery)#resolved?>

So now we know what extend actually does behind the scene is basically an include on the singleton class itself. Let’s prove it!

class Bar
  Bar.singleton_class.include Mystery
end

Bar.resolved? #=> true
Bar.singleton_class.instance_methods.grep(/resolved?/) #=> [:resolved?]
Bar.method(:resolved?) #=> #<Method: Class(Mystery)#resolved?>

Still works!

But yeah, writing the full form requires a staggering three more words, that’s a lot of work, so we’ve got extend to save us that keystroke instead!

Author’s Note

I’ll be pumping out a few more articles, meanwhile do check-out my last post on included, extended and prepended hooks!

Phew, that’s it for my second blogpost. Looking forward to learning and sharing more!

DEV Community: Edison Yap

Real World Example with Elixir Protocol

ElixirConf US 2019 and the future of Elixir

Resources

Introducing `Rocketman`, a gem to help you do Pub/Sub code in Pure Ruby. No Rails needed!

Description

edisonywh / rocketman

🚀 Rocketman help build event-based/pub-sub code in Ruby

Rocketman

Installation

Usage

Usage

How do you do API versioning?

Introducing `Behaves`, a better way to define contracts/behaviors between classes

edisonywh / behaves

Define behaviors and contracts between your code.

Behaves

Installation

Usage

Description

A Tale of Curiosity at work - work doesn't have to be boring

Takeaways

Function/Method look up in Elixir/Ruby

Your dad, your dad's dad, and your dad's dad's dad.

Ruby has no class methods

Edison Yap ・ Nov 9 '18

Source Code!

Solution

Conclusion

Elixir's If and Elixir's Do

How did the hints help?

1) Comma

2) Colon

3) Where's the end? (and proofy time!)

Takeaway

Author's note

[ Elixir | Why Linked Lists? ]

Immutable Data

Recursive structure

Structural/Tail Sharing

Garbage Collection & Caching?

Closing Note

How arrays work the way arrays work

Edison Yap ・ Feb 12 '19

Sources

How arrays work the way arrays work

Rewind Time

C-ing is believing

Timmy stores luggage!

What are dynamic arrays then?

I know what arrays are, what are linked lists?

thank u, next: an introduction to linked lists

Ali Spittel ・ Dec 5 '18

Closing Note

[ Elixir | Why Linked Lists? ]

Edison Yap ・ Feb 12 '19

Sources

Recursion, Tail Call Optimization and Recursion.

There is no concept of loop in Elixir.

LARGE NUMBERS!

What is Tail Call Optimization?

Do we have that in Ruby?

Proof?

Conclusion

Ruby has no class methods

Edison Yap ・ Nov 9 '18

My Ruby Journey: Hooking Things Up

Edison Yap ・ Nov 3 '18

Attribution

Ruby has no class methods

Wait…. Whaaaaaaaaaaaaaaaaaaat?

Parents. Grandparents. Ancestors..!

The one about Singleton Class

Author’s Note

3) Where's the `end`? (and proofy time!)