You’re confusing code input with software engineering.

Those are not the same thing. They never were.

There was a time when programming meant knowing how to convert numbers into binary in your head and jam instructions straight into memory addresses, bit by bit, by hand. There was a time when programming meant knowing how to organize a punched-card deck, knowing whether the deck order was right, knowing where one bad hole wrecked execution, and knowing how to debug visually without the modern fantasy of infinite backspace. There was a time when real programming meant knowing 6502, Z80, and Assembly because computers had so few resources that every byte actually mattered, not as a figure of speech.

Front panel and switches: before editors, before IDEs, before comfortable terminals.

And there were phases of computing that were even worse than punch cards. The video below shows someone programming an LGP-21, one of the oldest personal computers ever made (the second oldest, after the 1950s Bendix G15). Starts at the 5-minute mark:

Imagine what that was: you typed the program in binary directly on a typewriter, looking at the accumulator, instruction by instruction, then physically flipped a switch to execute, and the result got typed back onto paper. The metric wasn’t framerate. It was characters per minute. An operation you can do today in the blink of an eye inside any app used to take hours of human work, typing bit by bit, verifying, testing, verifying again.

It’s the same thing happening with typing code in a text editor today versus an AI agent running in your place. The manual way still works, the same way the Altair front panel kept working for years after compilers became common. But the tool of choice shifted, and the gap in speed and effort is the same order of magnitude that separated the LGP-21 from a modern text editor. Our generation is watching this transition happen in slow motion, and a lot of people don’t want to see it.

Then compilers got better. C showed up. Machines got fatter, consoles moved into the 32/64-bit era, PCs got more decent, and Assembly stopped being the center of everything. It became what it should be: a low-level tool, local optimization, critical routines, bootstrapping, drivers, that sort of thing. Nobody serious looked at that transition and said, “well, that’s it, programming is over because the compiler writes machine instructions for you now.”

The 21st century brought the Web and shoved an entire generation into HTML, CSS, and a pile of markup bureaucracy that adds very little intellectual value while demanding a ton of manual labor just to get it mostly right. I still think the industry dragged that model out way too long. For way too many years, programmers became glorified form operators, CRUD assemblers, div aligners, priests of front-end frameworks that all do the same thing with slightly different syntax.

Then the 2010s bubble made it worse.

I’ve already written about that in RANT: Did AI Kill Programmers? and also in 37 Days of Vibe Coding Immersion. The startup bubble, cheap money, and the hiring frenzy produced a legion of very bad programmers, coming out of two-month bootcamps and sketchy online courses promising Google salaries with no foundation, no education, and no depth. The market spent a decade pretending that was normal. It wasn’t. Same story as always: lots of volume, little value, and a whole lot of people confusing inflated employability with actual competence.

And when the layoffs started in 2022, that did not come out of nowhere. I spent years warning that the bubble would pop. It’s all there in the playlist EU AVISEI. The message was always the same: once the cheap money dried up, the bar would go back up, and the only people with a real shot would be the ones who had made the effort to actually learn Computer Science. The next economic cycle was always going to be less about hiring volume and more about efficiency. That’s exactly what happened.

What really changed

LLMs went mainstream at the end of 2022. That’s true. But mainstream is not the same thing as useful for serious work.

Throughout 2023 and 2024, I was already using AI to write code. Did it work? Sure, it worked. But it was still full of nonsense: too many hallucinations, too many agent loops, context getting lost too easily, tooling breaking too often, too much cost for too little reliability. It was useful for experienced programmers who knew how to keep the thing on a leash. It still wasn’t a mature tool for day-to-day heavy lifting.

For me, the turn came at the end of 2025. That’s when the combination of better models, prompt caching, decent tool calling, inference optimizations, context windows that were actually useful in practice, and above all real agent interfaces made the whole thing stop feeling like conference-demo theater and start feeling like an actual work tool.

That was the point where Claude Code, Codex, OpenCode, and the rest stopped being “autocomplete on steroids” and became a different category of interface.

To me, Claude Code is already the new terminal. The editor has moved into the background.

I talked about that in Migrating my Home Server with Claude Code, too. I simply have no patience left to burn attention on Linux shell busywork when the problem is mundane: installing a server, bringing up and organizing Docker services, hardening a firewall, reviewing security rules, tuning kernel parameters, auditing dmesg, digging through systemd logs, that kind of thing. I let Claude do the heavy lifting, and I review direction and risk. Ironically, my Linux machines have never felt more stable, faster, or more robust.

Today, if you spend your day building software, going back to the raw combo of text editor plus terminal and doing everything manually starts to feel like regression. Not because typing became impossible. Of course not. I’ve been typing code for decades. The problem is something else: it became a waste of attention.

If I can describe an intent, ask an agent to inspect the codebase, edit twenty files, run tests, compile, fix the fallout, and bring me back a proposed change in minutes, why exactly am I supposed to feel nostalgic about hand-typing boilerplate inside VS Code?

I don’t.

And this is where a distinction a lot of people still don’t get matters. You should not use a coding agent like some dumb editor extension, the kind of thing where you say “generate this file here” and then spend the next half hour micromanaging every line in a tiny corner pane. That’s using a Ferrari to go buy bread around the block. The big gain does not come from treating Claude Code, Codex, or similar tools like glorified autocomplete inside VS Code. The gain comes when you drop the editor-operator mindset and start treating the agent like an actual pair programmer.

Instead of acting like a professional typist, you move up a level. You act more like a tech lead, product owner, QA, manager of the flow. You define intent, explain context, demand criteria, ask for a plan, ask it to run tests, ask for refactors, ask for alternative approaches, ask it to review its own change. You leave the manual code labor to the agent and use your own brain to judge direction, priority, risk, and quality.

But there is a balance there, and I’ve already covered it in other Agile Vibe Coding posts. You do not hand over the wheel and let the LLM git push everything blind. And you also don’t swing to the opposite extreme and turn into a comma cop, nitpicking every tiny detail until the agent becomes one more layer of bureaucracy and kills the speed advantage. Both extremes are bad. In one, you outsource responsibility. In the other, you strangle productivity.

The right point on that pendulum is somewhere else: use XP and actual engineering discipline to sustain the speed. Continuous refactoring. Tests. CI. Review. Fast feedback. Small code. Incremental change. That’s exactly what I documented in posts like From Zero to Post-Production in 1 Week - How to Use AI on Real Projects and Software Is Never ‘Done’. The 10x multiplier does not come from model magic. It comes from the model plus a sane process.

The interface changed. The need for judgment did not.

VS Code is the new punch card

That’s what the title means.

VS Code did not “become bad.” That’s not the point. Punch cards weren’t “bad” in their own historical context either. They were a massive step up from toggling bits by hand or rewiring a board. The point is that they were the mechanism of their era for feeding instructions into the machine.

VS Code is not the enemy. It’s just becoming the input mechanism of the previous era.

Today, text editors are becoming that again: an input mechanism that still works, will still be around for a long time, but is no longer the center of the activity.

If you’ve never looked at those older eras of computing, I already went through it in Akitando #86 - The Turing and Von Neumann Computer:

And if you want a refresher on why 6502, Z80, and old machines forced a different kind of discipline, go back to the Hardcore Guide to Computing Fundamentals and Learning About Computers with Super Mario (Hardcore++). That wasn’t old-man nostalgia. It was there to show that in every era the interface changes, but the machine still demands precision.

This is what a good part of Akitando existed for: teaching what still holds when the fashionable tool changes.

And it’s worth remembering something a lot of people forget: the 146 videos on Akitando, more than 96 hours of material, were built precisely to teach this kind of foundation to Computer Science students, juniors, and people trying to stop being framework button-pushers. I recorded all of that because I could already see the industry pushing too many people toward manual busywork and not enough understanding. Ironically, now that agents are here, that archive is more relevant than ever.

The interface changed again.

First you needed to know how to type the instruction. Then you needed to know how to organize the deck. Then you needed to know how to convince the compiler. Then you needed to know how to stitch together frameworks, HTML, CSS, YAML, CI, containers, cloud, ORMs, queues, observability, and fifty other layers of junk.

Now you need to know how to orchestrate an agent.

And again, that does not eliminate foundations. It only changes where the manual labor ends and the intellectual work begins.

“So we don’t need Computer Science anymore?”

Quite the opposite.

Now you need it more.

Someone with no foundation looks at an agent issuing a SELECT * FROM table, sees the thing working locally against 300 fake rows, and assumes everything is fine. In production the query pulls a million rows, blows memory, degrades latency, backs up a queue, congests connections, and the person has no clue why “it works on my machine” but melts in production.

That’s the real problem.

The agent does not know your system’s context the way an experienced engineer does. It doesn’t know which tables are going to grow tenfold next quarter. It doesn’t know which endpoint needs to answer in 80 ms and which one can take 2 seconds. It doesn’t know which flow needs a transaction, which one needs idempotency, which one needs a pessimistic lock, which one needs async compensation, which one needs auditing, which one can never leak sensitive data.

It may get the syntax right.

But syntax was never the hardest part.

I already said that in RANT: Did Akita Bend Over for AI??: what AI is really good at is removing the mundane work. And thank God for that. I did not get into computing to become an IDE operator. I have no romantic attachment to formatting HTML, fighting CSS, assembling the same old CRUD, gluing one more framework onto an old stack, or writing the same pile of infrastructure code for the hundredth time when any decent machine should be able to produce that by now.

So what is left after that mundane layer disappears?

Exactly the part that separates amateurs from real programmers:

• domain modeling
• architecture
• trade-offs
• performance
• scalability
• security
• observability
• maintainability
• readability
• operational cost
• product decisions

All of that still exists. All of that is still hard. All of that still depends on judgment.

The mistake people make when they think programming was typing

Some people genuinely think that if the machine writes the code, then the need to understand software is gone.

That is the same stupidity as thinking the compiler killed the need to understand computers.

It didn’t.

It only killed the need to write everything in Assembly.

And thank God for that too.

Same thing here: coding agents do not kill the need to understand software. They kill the need for you to be a syntax typist.

And good riddance.

There is a nice irony here too: for years the industry sold the fantasy that programming meant “learning a framework.” Then it sold the fantasy that programming meant “learning React.” Then it sold the fantasy that programming meant “learning the stack of the month.” Now it’s going to sell the fantasy that programming means “learning prompt engineering.”

It doesn’t.

Prompts are an interface. Frameworks are an interface. IDEs are an interface. Punch cards were an interface.

Programming is still the act of instructing a machine to compute something useful under real constraints.

People who understand that survive every tool shift. People who don’t become operators of whatever the trendy tool is, and when the trend changes, they go down with it.

What I think is going to happen to juniors

So let’s answer the original question properly.

Juniors are not going to stop learning.

But they are going to have to learn something else.

If the junior of 2015 could spend years hiding ignorance behind low-value manual tasks, tweaking views, adjusting CSS, assembling dumb endpoints, copying Stack Overflow snippets, and making it all look like “productivity,” that hiding place is going away.

The junior of the agent era is either going to level up faster or get exposed faster. There isn’t much middle ground.

If they use agents and actually study fundamentals, they’ll be able to test hypotheses faster, read more code, compare more solutions, iterate more, make mistakes earlier and fix them earlier. They’ll learn more in less time.

But if they use agents without foundations, all they’ll do is outsource their own ignorance. They’ll become reviewers who cannot review. They’ll accept patches they do not understand. They’ll approve decisions they do not know how to measure. They’ll confuse “passed locally” with “ready for production.”

That kind of professional is dangerous.

Far more dangerous than the old junior who was at least limited by their own speed.

The post-bubble world

The good news is that this comes right after the collapse of the dumbest phase of the hiring bubble.

It’s past time for the market to stop rewarding labor-intensive stupidity as if it were competence. It’s past time to stop treating stack bureaucracy as technical depth. It’s past time to stop confusing commit volume with engineering value.

If the new era wipes out a good chunk of that theater, great.

In a post-bubble, post-miracle-bootcamp, post-CSS-as-a-career, post-CRUD-as-a-profession world, foundations go back to being what they should always have been: the main asset.

People who understand operating systems, databases, networking, data structures, compilers, computer architecture, profiling, debugging, concurrency, consistency, security, and cost will use agents as an exoskeleton.

People who understand none of that will use agents as a crutch.

An exoskeleton amplifies strength. A crutch only tries to hide weakness.

“But this isn’t sustainable”

There is always someone with the same excuse: “well, I don’t think this is sustainable, the data centers can’t keep up, the prices are too heavily subsidized, there’s no way this can keep going like this.”

And to be fair, that person is not entirely wrong.

It just doesn’t change a thing about what I have to do tomorrow morning.

This kind of concern might be great for bar talk or an X thread, but it doesn’t help me decide anything useful. Me, you, none of us are going to sit down with Anthropic or OpenAI leadership and redesign data-center capex, renegotiate power contracts, decide subsidy margins, or plan the next GPU generation. There is no concrete action for us that comes out of this besides repeating that “someday this will be a problem.”

It’s the same mindset as the person in the 1990s saying, “let’s not use the internet too much, it’s too slow, the limits are too low, the price per kilobyte is absurd, better wait until someone fixes it.” Or the person in the early 2000s looking at mobile data and saying, “2G is too slow, too limited, better not depend on it.” Why exactly would you want to be that person?

Thank God OpenAI, Anthropic, and the rest are fighting like hell and heavily subsidizing this race. I’m taking full advantage of it. I’ve already burned through my entire Claude Max 20x, already hit the extra-usage ceiling, already burned through my Codex plan, and upgraded to Pro so I can keep using it this weekend. People paying a monthly subscription and barely touching it are, in practice, subsidizing me to use as much as I can. I have no intention of slowing down. Why would you?

If prices change tomorrow, if infrastructure gets tighter, if the game changes, then I reassess tomorrow. That’s how technology has always worked. While the window is open, the rational move is not to slow yourself down in advance. The rational move is to learn as much as possible, extract as much as possible, and build an advantage while everybody else is busy explaining why they still haven’t started.

The decision is still human

At the end of the day, nothing that matters actually changed.

Someone still has to look at the result and decide:

• can this go to production?
• can this handle load?
• is this readable?
• is this secure?
• is this maintainable?
• does this fit the rest of the system?
• does this solve the right problem?

If the answer is no, someone still has to know why it’s no.

More importantly, someone still has to know how to fix it.

That’s why, in the age of agents, foundational knowledge did not become less important. It became more expensive to be wrong without it.

VS Code is the new punch card.

Not because it became useless.

But because we’re finally entering an era where the act of typing code by hand stops being the center of the profession.

And honestly? About time.

AI reflects who you are.

If you’re good, it accelerates good code.

If you’re bad, it accelerates technical debt at industrial speed.

AI is not going to take a bad programmer and turn them into a good one. It never did, it doesn’t, and it won’t.

That’s why foundations matter more now than they did before.

The agent can write. You’re still the one who has to know whether what it wrote is any good.

Many tutorial series start introducing a new language by its syntax. I subverted the order. Elixir is not interesting because of its syntax. Erlang is interesting all by itself, because of its very mature, highly reliable, highly concurrent, distributed nature. But its syntax is not for the faint of heart. It’s not “ugly”, it’s just too different for those of us from the C school to easily digest. It derives from Prolog, and this is one small example of a Prolog exercise:

% P03 (*): Find the K'th element of a list.
%     The first element in the list is number 1.
%     Example:
%     ?- element_at(X,[a,b,c,d,e],3).
%     X = c

% The first element in the list is number 1.

% element_at(X,L,K) :- X is the K'th element of the list L
%    (element,list,integer) (?,?,+)

% Note: nth1(?Index, ?List, ?Elem) is predefined

element_at(X,[X|_],1).
element_at(X,[_|L],K) :- K > 1, K1 is K - 1, element_at(X,L,K1).

Erlang has a similar syntax, with the idea of phrases divided by commas and ending with a dot.

José Valim played it very smart: he chose the best of the available mature platforms and coated it with a layer of modern syntax and easier-to-use standard libraries. This is the same problem implemented in Elixir:

defmodule Exercise do
  def element_at([found|_], 1), do: found
  def element_at([_|rest], position) when position > 1 do
    element_at(rest, position - 1)
  end
end

If I copy and paste the code above in an IEx shell I can test it out like this:

iex(7)> Exercise.element_at(["a", "b", "c", "d", "e"], 3)
"c"

This simple exercise shows us some of the powerful bits of Erlang that Elixir capitalizes upon, such as pattern matching and recursion.

First of all, every function must be defined inside a module, which you name with defmodule My.Module do .. end. Internally it becomes the atom “Elixir.My.Module”. Nesting modules is just a longer name concatenated with dots.

Then you can define a public function with the def my_function(args) do .. end block, which is just a macro for the same def my_function(args), do: … construct. Private functions are declared with defp.

A function is actually identified by the pair of its name and its arity. So above we have element_at/2 which means it accepts 2 arguments. But we have 2 functions with the same arity: the difference is the pattern matching.

def element_at([found|_], 1), do: found

Here we are saying: the first argument will be an array, decompose it. The first element of the array will be stored in the “found” variable, the rest “_” will be ignored. And the second argument must be the number “1”. This is the description of the so-called “pattern”, and it should “match” the input arguments received. This is “call-by-pattern” semantics.

But what if we want to pass a position other than “1”? That’s why we have this second definition:

def element_at([_|rest], position) when position > 1 do

Now, the first argument again needs to be an array, but this time we don’t care about the first element, just the rest of the array without the first element. And any position other than “1” will be stored in the “position” variable.

But this function is special: it is guarded to only allow a position that is larger than 1. What if we try a negative position?

iex(8)> Exercise.element_at(["a", "b", "c", "d", "e"], -3)
** (FunctionClauseError) no function clause matching in Exercise.element_at/2
    iex:7: Exercise.element_at(["a", "b", "c", "d", "e"], -3)

It says that none of the arguments we passed match any of the clauses defined above. We could have added a third definition just to catch those cases:

def element_at(_list, _position), do: nil

Adding the underscore “_” before the variable name is the same as having just the underscore, but we are naming it just to make it more readable. Any arguments passed will just be ignored. And this is the more generic case if the previous 2 don’t match.

The previous line is the same as writing:

def element_at(_list, _position) do
  nil
end

I won’t dive into macros for now. Just know that there is more than one way of doing things in Elixir and you can define those different ways using Erlang’s built-in support for macros, dynamic code that is compiled at runtime. It’s the way of doing metaprogramming in Elixir.

Now, going back to the implementation, the first function can still look weird; let’s review it:

def element_at([_|rest], position) when position > 1 do
  element_at(rest, position - 1)
end

What happens is: when we call Exercise.element_at([“a”, “b”, “c”, “d”, “e”], 3) the first argument will pattern match with [_|rest]. The first element “a” is discarded and the new list [“b”, “c”, “d”, “e”] is stored as “rest”.

Finally, we recurse the call, decrementing the “position” variable. So it becomes element_at([“b”, “c”, “d”, “e”], 2). And it repeats until position becomes “1”, in which case the pattern matching falls to the other function defined as:

def element_at([found|_], 1), do: found

In this case the rest of the array is pattern matched and the first element, “c”, is stored in the “found” variable; the rest of the array is discarded. It only got here because the position matched as “1”, so it just returns the variable “found”, which contains the 3rd element of the original array, “c”.

This is all nice and fancy, but in Elixir we could have just done this other version:

defmodule Exercise do
  def element_at(list, position), do: Enum.at(list, position)
end

And we are done! Several tutorials will talk about how recursion and pattern matching to decompose lists solve a lot of problems, but Elixir gives us the convenience of treating lists as Enumerables and provides us a rich Enum module with very useful functions such as at/2, each/2, take/2, and so on. Just pick what you need and you’re managing lists like a boss.

Oh, and by the way, there is something called a Sigil in Elixir. Instead of writing the List of Strings explicitly, we could have done it like this:

iex(8)> ~w(a b c d e f)
["a", "b", "c", "d", "e", "f"]

Or, if we wanted a List of Atoms, we could do it like this:

iex(9)> ~w(a b c d e f)a
[:a, :b, :c, :d, :e, :f]

Lists, Tuples and Keyword Lists

Well, this was too simple. You really need the idea of pattern matching and basic types in your mind to make it flow. Let’s get another snippet from the Ex Manga Downloadr:

defp parse_args(args) do
  parse = OptionParser.parse(args,
    switches: [name: :string, url: :string, directory: :string],
    aliases: [n: :name, u: :url, d: :directory]
  )
  case parse do
    {[name: manga_name, url: url, directory: directory], _, _} -> process(manga_name, url, directory)
    {[name: manga_name, directory: directory], _, _} -> process(manga_name, directory)
    {_, _, _ } -> process(:help)
  end
end

The first part may puzzle you:

OptionParser.parse(args,
    switches: [name: :string, url: :string, directory: :string],
    aliases: [n: :name, u: :url, d: :directory]
  )

The OptionParser.parse/2 receives just 2 arguments: 2 arrays. If you come from Ruby it feels like it’s a Hash with optional brackets, translating to something similar to this:

# this is wrong
OptionParser.parse(args,
    { switches: {name: :string, url: :string, directory: :string},
      aliases: {n: :name, u: :url, d: :directory} }
  )

This works in Ruby, but it is not the case in Elixir. There are optional brackets, but not where you think they are:

# this is the correct, more explicit version
OptionParser.parse(args,
    [
      {
        :switches,
        [
          {:name, :string}, {:url, :string}, {:directory, :string}
        ]
      },
      {
        aliases:
        [
          {:n, :name}, {:u, :url}, {:d, :directory}
        ]
      }
    ]
  )

WHAT!?!?

Yep, the second argument is actually an array with elements that are Tuples paired with an atom key and value, and some of the values are themselves arrays with tuples.

1. in Elixir, Lists are what we usually call an Array, a Linked-List of elements. Linked-Lists, as you know from your Computer Science classes, make it easy to insert and remove elements.

2. in Elixir, Tuples are immutable fixed lists with fixed positions, with elements delimited by the brackets “{}”

If the previous example was just too much, let’s step back a little:

defmodule Teste do
  def teste(opts) do
    [{:hello, world}, {:foo, bar}] = opts
    IO.puts "#{world} #{bar}"
  end
end

Now we can call it like this:

iex(13)> Teste.teste hello: "world", foo: "bar"
world bar

Which is the same as calling like this:

iex(14)> Teste.teste([{:hello, "world"}, {:foo, "bar"}])
world bar

This may confuse you, but it’s very intuitive. You can just think of this combination of Lists ("[]") with Tuple elements containing a pair of atom and value ("{:key, value}") as behaving almost like Ruby Hashes being used for optional named arguments.

Then, we have the Pattern Match section in both previous examples:

case parse do
  {[name: manga_name, url: url, directory: directory], _, _} ->
    process(manga_name, url, directory)
  {[name: manga_name, directory: directory], _, _} ->
    process(manga_name, directory)
  {_, _, _ } ->
    process(:help)
end

And

[{:hello, world}, {:foo, bar}] = opts

The last example is just decomposition. The previous example is pattern matching and decomposition. You match based on the atoms and positions within the tuples within the list. You match from the more narrow case to the more generic case. And in the process, the variables in the pattern are available for you to use in the matching case clause.

Let’s understand the meaning of this line:

{[name: manga_name, url: url, directory: directory], _, _} -> process(manga_name, url, directory)

It is saying: given the results of the OptionParser.parse/2 function, it must be a tuple with 3 elements. The second and third elements don’t matter. But the first element must be a List with at least 3 tuples. And the keys of each tuple must be the atoms :name, :url, and :directory. If they’re there, store the values of each tuple in the variables manga_name, url, and directory, respectively.

This may really confuse you in the beginning, but this combination of a List of Tuples is what’s called a Keyword List, and you will find this pattern many times, so get used to it.

Keyword Lists feel like a Map, but a Map has a different syntax:

list = [a: 1, b: 2, c: 3]
map = %{:a => 1, :b => 2, :c => 3}

This should summarize it:

iex(1)> list = [a: 1, b: 2, c: 3]
[a: 1, b: 2, c: 3]
iex(2)> map = %{:a => 1, :b => 2, :c => 3}
%{a: 1, b: 2, c: 3}

iex(3)> list[:a]
1
iex(4)> map[:a]
1

iex(5)> list.a
** (ArgumentError) argument error
    :erlang.apply([a: 1, b: 2, c: 3], :a, [])
iex(5)> map.a
1

iex(6)> list2 = [{:a, 1}, {:b, 2}, {:c, 3}]
[a: 1, b: 2, c: 3]
iex(7)> list = list2
[a: 1, b: 2, c: 3]

Keyword Lists are convenient as function arguments or return values. But if you want to process a collection of key-value pairs, use a dictionary-like structure, in this case a Map, especially if you need to search the collection using the key. They look similar, but the internal structures are not the same. A Keyword List is not a Map; it’s just a convenience for a static list of tuples.

Finally, if this pattern matches the parse variable passed to the case block, it executes the statement process(manga_name, url, directory), passing the 3 variables captured in the match. Otherwise it proceeds to try the next pattern in the case block.

The idea is that the “=” operator is not an “assignment”, it’s a matcher: you match one side with the other. Read the error message when a pattern is not matched:

iex(15)> [a, b, c] = 1
** (MatchError) no match of right hand side value: 1

This is a matching error, not an assignment error. But if it succeeds this is what we have:

iex(15)> [a, b, c] = [1, 2, 3]
[1, 2, 3]
iex(16)> a
1
iex(17)> c
3

This is List decomposition. It so happens that in the simple case it feels like a variable assignment, but it’s much more complex than that.

Pipelines

We use exactly those concepts of pattern matching on the elements returned from the HTML parsed by Floki in my Manga Downloadr:

Floki.find(html, "#listing a")
|> Enum.map(fn {"a", [{"href", url}], _} -> url end)

The find/2 takes an HTML string from the fetched page and matches against the CSS selectors in the second argument. The result is a List of Tuples representing the structure of each HTML Node found, in this case, this pattern: {“a”, [{“href”, url}], _}

We can then Enum.map/2. A map is a function that receives each element of a list and returns a new list with new elements. The first argument is the original list and the second argument is a function that receives each element and returns a new one.

One of the main features of the Elixir language that most languages don’t have is the Pipe operator ("|>"). It behaves almost like UNIX’s pipe operator “|” in any shell.

In UNIX we usually do stuff like “ps -ef | grep PROCESS | grep -v grep | awk ‘{print $2}’ | xargs kill -9”

This is essentially the same as doing:

ps -ef > /tmp/ps.txt
grep mix /tmp/ps.txt > /tmp/grep.txt
grep -v grep /tmp/grep.txt > /tmp/grep2.txt
awk '{print $2}' /tmp/grep2.txt > /tmp/awk.txt
xargs kill -9 < /tmp/awk.txt

Each UNIX process can receive something from standard input (STDIN) and output something to standard output (STDOUT). We can redirect the output using “>”. But instead of doing all those extra steps and creating all those extra garbage temporary files, we can simply “pipe” the STDOUT of one command to the STDIN of the next command.

Elixir uses the same principles: we can simply use the returning value of a function as the first argument of the next function. So the first example of this section is the same as doing this:

results = Floki.find(html, "#listing a")
Enum.map(results, fn {"a", [{"href", url}], _} -> url end)

In the same ExMangaDownloadr project we have this snippet:

defp process(manga_name, url, directory) do
  File.mkdir_p!(directory)
  url
    |> Workflow.chapters
    |> Workflow.pages
    |> Workflow.images_sources
    |> Workflow.process_downloads(directory)
    |> Workflow.optimize_images
    |> Workflow.compile_pdfs(manga_name)
    |> finish_process
end

And we just learned that it’s the equivalent of doing the following (I’m cheating a bit because the 3 final functions of the workflow are not transforming the input “directory”, just passing it through):

  defp process(manga_name, url, directory) do
    File.mkdir_p!(directory)

    chapters  = Workflow.chapters(url)
    pages     = Workflow.pages(chapters)
    sources   = Workflow.images_sources(pages)
    Workflow.process_downloads(sources, directory)
    Workflow.optimize_images(directory)
    Workflow.compile_pdfs(directory, manga_name)
    finish_process(directory)
  end

Or this much uglier version that we must read in reverse:

defp process(manga_name, url, directory) do
  File.mkdir_p!(directory)
  finish_process(
    Workflow.compile_pdfs(
      Workflow.optimize_images(
        Workflow.images_sources(
          Workflow.pages(
            Workflow.chapters(url)
          )
        )
      ), manga_name
    )
  )
end

We can easily see how the Pipe Operator “|>” makes any transformation pipeline much easier to read. Anytime you are starting from a value and passing the results through a chain of transformations, you will use this operator.

Next Steps

The concepts presented in this article are the ones I think most people will find the most challenging upon first glance. If you understand Pattern Matching and Keyword Lists, you will understand all the rest.

The official website offers a great Getting Started that you must read entirely.

From intuition you know most things already. You have “do .. end” blocks, but you may not yet know that they are just convenience macros to pass a list of statements as an argument inside a Keyword List. The following blocks are equivalent:

if true do
  a = 1 + 2
  a + 10
end

if true, do: (
  a = 1 + 2
  a + 10
)

if true, [{:do, (
  a = 1 + 2
  a + 10
)}]

Mind-blowing, huh? There are many macros that add syntactic sugar using the primitives behind it.

For the most part, Valim made the powerful Erlang primitives more accessible (Lists, Atoms, Maps, etc.) and added higher abstractions using macros (do .. end blocks, the pipe operator, keyword lists, shortcuts for anonymous functions, etc.). This precise combination is what makes Elixir very enjoyable to learn. It’s like peeling an onion: you start with the higher abstractions and discover macros of simpler structures underneath. You see a Keyword List first and discover Lists of Tuples. You see a block and discover another Keyword List disguised by a macro. And so on.

So you have a low barrier to entry and you can go as deep as you want into the rabbit hole, all the way to extending the language.

Elixir provides a very clever language design on top of the 25-year-old mature Erlang core. This is not just clever, it’s the intelligent choice. Keep learning!

This is not my first time touching Erlang though. I was fortunate enough to be able to participate in a small workshop at QCon San Francisco 2009 with no other than Francesco Cesarini. Thanks to him I was able to understand some of Erlang’s exquisite syntax, the correct concept of Erlang processes, how immutability and pattern matching govern their programming flow. It was very enlightening. Unfortunately I couldn’t see myself doing Erlang full time. I just hoped those mechanisms were available in a language such as Ruby …

Between 2007 and 2009 Erlang had a renaissance among language aficionados because of the “Programming Erlang” book released by The Pragmatic Programmers, written by no other than Joe Armstrong himself, Erlang’s creator. Dave Thomas tried to push Erlang a lot in 2007, but even he wasn’t able to sell Erlang’s powerful engine because of the strange presentation of the syntax.

After 2009, José Valim had a long run to release the controversial Rails 3.0 big rewrite (which was fortunately a success) and he decided to step aside and try something else. His own research led him to Erlang for the reasons I mentioned above, but he decided that he could solve the “quirky syntax” problem. You can see some of his very first talks about Elixir in the Rubyconf Brasil 2012 and 2013 recordings. The very early beta was released in 2012 and he finally released the stable 1.0 in 2015. Chris McCord was able to release Phoenix stable soon after.

When I first heard about this, Elixir found its place under my radar. I didn’t jump right in though, between 2009 and 2015 we had a surge in “functional programming” interest because of the JavaScript renaissance, the release of Scala, Go Lang, Clojure, the promise of Rust, and so on. So I waited, carefully following every one of them.

Then 2014 came and suddenly everybody else found out about Erlang, with its spartan infrastructure that enabled WhatsApp to serve half a billion users with absurdly low costs and made Facebook buy them for a hefty USD 19 billion! We all knew about the WhatsApp case since at least 2011, but it was not until 2014 that everybody noticed. But not even this was able to steer Erlang to the forefront just yet.

When Elixir stable was released this year, followed by Phoenix stable, I knew it was time for me to start investing some quality time with it. Erlang’s core sells itself: everybody else is doing concurrency by means of immutability and lightweight threads (or green threads, NxM strategy between green threads and real threads). It is actually quite trivial to max out the machine just by spawning millions of light processes nowadays. What makes it difficult is to create a system that has the potential to actually achieve 99.9999999% reliability. Spawning processes is easy, how do you coordinate them in the same machine? How do you coordinate them between different machines? How do you update a living system without bringing it down? How do you handle failures? How do you supervise everything?

These are the questions that Erlang solved decades ago (20 years ago) with the now famous OTP, Ericsson’s Open Telecom Platform. Something that was created to meet the performance and reliability needs of telecommunications at large scale. When we say it like this it feels like it will be a royal pain to learn, something akin to the JEE (Java Enterprise Edition), but worse.

And I can tell you that learning enough OTP to be productive is actually very easy (you won’t achieve the legendary 99.9999999% reliability out of the blue, but you’ll be able to build something reliable enough). Think of it as a collection of half a dozen modules, with a couple of function interfaces to implement, a few words of configuration and you’re basically done. It’s so easy and lightweight that in fact many small libraries are written with OTP in mind and it’s easy to just “plug and play”. It’s not a heavyweight server-side only thing.

To harness that power you will need to learn Elixir, unofficially, a language that has an uncanny resemblance to Ruby, built to spill out Erlang bytecode for its BEAM virtual machine. You can’t find a better combination.

One Week

Having said all that, let’s cut to the chase. You definitely want to get acquainted with the Functional Programming concepts such as immutability, higher order functions, pattern matching. I made a list of links for those concepts in my previous post, I recommend you read it.

Assuming you’re already a programmer in a dynamic language (Ruby, Python, JavaScript, etc.) and you want the fast crash course, start by buying “Programming Elixir” by Dave Thomas and actually do each piece of code and the exercises in order. It’s a book so easy to read that you will be able to finish it in less than a week. I did it in 3 days. The Elixir-Lang official website has very good documentation as well and they link many good books you want to read later.

Then subscribe to Josh Adams’ Elixir Sips. If you’re a Rubyist, it’s like watching Ryan Bates’ Railscasts from the beginning all over again. Although it’s more akin to Avdi Grimm’s RubyTapas show, with very short episodes just for you to have your weekly fix on Elixir.

You can watch some of the episodes for free in low resolution, but I highly recommend you subscribe and watch the HD versions. It’s well worth it. There are more than 200 episodes. I’ve watched more than 130 in 12 hours :-) So I figure I’d take another 2 days to watch everything.

You should definitely watch everything if you can, but if you can’t, let me list the ones I think are the essentials. First of all, keep in mind that Josh has been doing this for quite a while, when he started Elixir was version 0.13 or below and Erlang was version 17 or below.

For example, episode 171 - Erlang 18 and time highlights the new Time API. You must know about this. Episode 056 - Migrating Records to Maps shows a new feature in Erlang 17 and Elixir where it makes Maps more preferable than the previous Records. Maps are explained in episodes 054 and 055. If you learn the Phoenix web framework, it uses the ORM Ecto underneath and Ecto models are Maps, so you must know this.

It means that the first 180 episodes, at least, are using previous versions of Erlang, Elixir, Phoenix, etc and you must keep in mind that new versions will have different APIs. This was one of the reasons I waited for the stable releases, because it was only natural that projects evolve and take time to reach stable APIs, and chasing several moving targets is really difficult for the uninitiated.

Having said that, watch this list first:

• 001 - Introduction and Installing Elixir.mp4
• 002 - Basic Elixir.mp4
• 003 - Pattern Matching.mp4
• 004 - Functions.mp4
• 005 - Mix and Modules.mp4
• 006 - Unit Testing.mp4
• 010 - List Comprehensions.mp4
• 011 - Records.mp4
• 012 - Processes.mp4
• 013 - Processes, Part 2.mp4
• 014 - OTP Part 1_ Servers.mp4
• 015 - OTP Part 2_ Finite State Machines.mp4
• 016 - Pipe Operator.mp4
• 017 - Enum, Part 1.mp4
• 018 - Enum, Part 2.mp4
• 019 - Enum, Part 3.mp4
• 020 - OTP, Part 3 - GenEvent.mp4
• 022 - OTP, Part 4_ Supervisors.mp4
• 023 - OTP, Part 5_ Supervisors and Persistent State.mp4
• 024 - Ecto, Part 1.mp4
• 025 - Ecto, Part 2_ Dwitter.mp4
• 026 - Dict, Part 1.mp4
• 027 - Dict, Part 2.mp4
• 028 - Parsing XML.mp4
• 031 - TCP Servers.mp4
• 032 - Command Line Scripts.mp4
• 033 - Pry.mp4
• 041 - File, Part 1.mp4
• 042 - File, Part 2.mp4
• 044 - Distribution
• 045 - Distribution, Part 2
• 054 - Maps, Part 1.mp4
• 055 - Maps, Part 2_ Structs.mp4
• 056 - Migrating Records To Maps.mp4
• 059 - Custom Mix Tasks.mp4
• 060 - New Style Comprehensions.mp4
• 061 - Plug.mp4
• 063 - Tracing.mp4
• 065 - SSH.mp4
• 066 - Plug.Static.mp4
• 067 - Deploying to Heroku.mp4
• 068 - Port.mp4
• 069 - Observer.mp4
• 070 - Hex.mp4
• 073 - Process Dictionaries.mp4
• 074 - ETS.mp4
• 075 - DETS.mp4
• 076 - Streams.mp4
• 077 - Exceptions and Errors.mp4
• 078 - Agents.mp4
• 079 - Tasks.mp4
• 081 - EEx.mp4
• 082 - Protocols.mp4
• 083 - pg2.mp4
• 086 - put_in and get_in.mp4
• 090 - Websockets Terminal.mp4
• 091 - Test Coverage.mp4
• 106 - Text Parsing.mp4
• 109 - Socket.mp4
• 112 - Benchfella.mp4
• 113 - Monitoring Network Traffic.mp4
• 124 - Typespecs.mp4
• 125 - Dialyzer.mp4
• 126 - Piping Into Elixir.mp4
• 127 - SSH Client Commands.mp4
• 131 - ExProf.mp4
• 132 - Randomness in the Erlang VM.mp4
• 135 - Benchwarmer.mp4
• 138 - Monitors and Links.mp4
• 139 - hexdocs.mp4
• 141 - Set.mp4
• 142 - escript.mp4
• 144 - Erlang’s calendar module.mp4
• 145 - good_times.mp4
• 153 - Phoenix APIs and CORS.mp4
• 155 - OAuth2_ Code Spelunking.mp4
• 156 - Interacting with Amazon’s APIs with erlcloud.mp4
• 157 - Playing with the Code Module Part 1 - eval_string.mp4
• 159 - Simple One for One Supervisors.mp4
• 160 - MultiDef.mp4
• 171 - Erlang 18 and Time.mp4
• 172 - Arc File Uploads.mp4
• 174 - ElixirFriends_ Saving Tweets with Streams and Filters.mp4
• 175 - Pagination with Ecto and Phoenix using Scrivener.mp4
• 176 - Prettying Up ElixirFriends.mp4
• 178 - Memory Leaks.mp4
• 179 - Rules Engine.mp4
• 180 - Collectable.mp4
• 182 - Phoenix API.mp4
• 183 - React with Phoenix.mp4
• 184 - React with Phoenix Channels.mp4
• 185 - Mix Archives.mp4
• 186 - Automatically Connecting Nodes.mp4
• 187 - Compiling a Custom AST Into Elixir Functions.mp4
• 190 - Testing Phoenix Channels.mp4
• 193 - Linting with Dogma.mp4
• 194 - Interoperability_ Ports.mp4
• 196 - Crashing the BEAM.mp4
• 200 - Custom Types in Ecto.mp4
• 201 - Tracing and Debugging with erlyberly.mp4
• 202 - Exception Monitoring with Honeybadger.io.mp4
• 203 - plug_auth.mp4
• 204 - Behaviours.mp4

This is roughly half of what’s available in Elixir Sips. All the other episodes are also interesting, but if you’re just getting started, this list should be enough to get your feet wet in the language.

Railers will enjoy Phoenix and the ecosystem that is growing around it. You can already authenticate through OAuth2, do will_paginate-style pagination with Scrivener, do CarrierWave-style file uploads with Arc, deploy to Heroku.

For more exercises, you can easily connect to HTTP endpoints using HTTPoison, parse HTML with Floki, parse JSON with Poison. For more libraries, you can follow this Github page called Awesome Elixir which lists many new Elixir packages that you can use. But make sure you walk yourself through the basic concepts first. Elixir has a Rake-like task management system with built-in Mix, you can add dependencies in a Gemfile-like file called Mix.exs, which every project has. You can add dependencies through Github urls or from Hex.pm which is like Rubygems.org.

In this learning process, the concepts that I find more important to learn first are:

• Elixir basic syntax and concepts (pattern matching, loops through recursion, immutable state, primitive types including Maps, the pipe operator)
• The concept of processes, nodes, and intercommunication between processes and nodes, including Monitors and Links.
• OTP Basics, learn what GenServer, GenEvent, GenFSM are.

After you learn that, you can figure out how to build OTP applications and do something practical for the Web using Phoenix. In particular, you will want to learn everything about Phoenix’s Channels, the infrastructure for robust, fast and highly concurrent WebSockets.

That’s it. This is my first week learning Elixir, and my next step is to train myself by doing more exercises and also learning more about Phoenix. Even though Phoenix is inspired by Rails, it is not a clone, it has its own set of unique concepts to learn and this is definitely going to be a very interesting ride.

If you have more tips and tricks for beginners, feel free to comment below.

My last translation article, on “Standards: Excellence vs. Mediocrity,” spun off an interesting side discussion specifically about “Design Patterns.”

For those not in programming: the term “Design Pattern” emerged in the 70s and was reinforced in the 90s by the “Gang of Four book.” According to Wikipedia, in software engineering a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It’s a description or template for how to solve a problem that can be used in many different situations.

For us in Brazil there’s a huge problem, and it only clicked for me because of the discussion in the comments of that article. The complaint was that I translated “Design Patterns Standards” as “Padrões de Design.” Ronald, the one who raised it, made a correct point: the English words “default”, “standard” and “pattern” all translate to the same word “padrão” in Portuguese.

But the 3 words have very different meanings:

Default – a pre-selected option adopted by a computer program or other mechanism when no other alternative is specified by the user or programmer. Example: the “default” is 50 lines

Pattern – 1) a repetitive decorative design (as in color “patterns” on clothing). A regular arrangement or sequence in comparable objects or events. A regular and intelligible form or discernible sequence in certain actions or situations. 2) a model or design used as a guide in embroidery or other craft activities.

Standard – 1) a level of quality or accomplishment. A required or agreed-upon level of quality or accomplishment. 2) an idea or thing used as a measure, norm, or model in comparative evaluations. Principles of conduct informed by notions of honor and decency. A form of language that is widely recognized as the correct one.

In summary:

Default – a pre-selected choice when no other is selected.

Pattern – a model that can be observed as recurring, with no value of right or wrong.

Standard – a norm, something everyone agrees on as a basis of comparison or minimum requirements to be followed.

The problem is that the word “padrão,” in Portuguese, is used much more often with the sense of “standard.” And many times what we’re translating is the word “pattern.”

That is, when someone says “Design Pattern,” they’re only saying there’s a “form” used more frequently than others in solving software problems. It isn’t necessarily the most correct one, and there’s no statement that it’s the conclusive form. It’s just the observation that it’s frequent, regularly used. The image below shows padrões in the sense of “patterns” (“more patterns”):

But translating to “Padrões de Design” brings in the Portuguese sense of “padrão” as the most correct, or minimally correct, form, and one that, being a “norm,” should be followed. The word “padrão” comes across like “obligation to follow standard Decree No. 288/2005,” that is, “obligation to follow the norm or regulation Decree No. 288/2005.”

Then “Design Patterns” gains the connotation of a norm or regulation, which is exactly the wrong meaning. Pattern is Pattern, Standard is Standard, they’re completely different things.

And that’s where the misunderstanding between so many people lives. Whoever understood Design Patterns in the sense of “Pattern” complains about whoever understood it in the sense of “Standard.” Both translate as “padrão,” and the discussion between these two people ends up sounding like a crazy conversation: “But this is just a padrão (pattern), it doesn’t have to be mandatorily followed.” – “No! This is a padrão (standard), so it must be mandatorily followed!”

Note: I noticed some people didn’t really like the title, but I put it that way on purpose, to draw attention to the subject. I’m not claiming Portuguese is essentially bad and other languages are better. Every language has nuances and differences that depend on context, local culture, colloquialisms, neologisms, fashion, and so on.

Precisely for that reason we always have to stay alert, so we don’t take things literally and apply them without thinking, starting from false premises.

Most of this was based on Cocoanetics article about universal static libraries. So, if you’ve paid attention to my previous article, you saw this screenshot:

I said that I only had these targets configured: CocoaOniguruma, Kiwi, Rubyfication and RubyficationTests. But there are 3 others: CocoaOniguruma SIM, Rubyfication SIM, and Build & Merge Libraries. The reason is simple:

• The “CocoaOniguruma” Target builds the libCocoaOniguruma.a binary that’s compatible with the ARM processor for iOS
• The “CocoaOniguruma SIM” Target builds the libCocoaOnigurumaSimulator.a binary that’s compatible with the i386 processor for the local iPhone Simulator
• The “Rubyfication” Target builds the libRubyfication.a binary that’s compatible with the ARM processor for iOS
• The “Rubyfication SIM” Target builds the libRubyficationSimulator.a binary that’s compatible with the i386 processor for the local iPhone Simulator
• The “Build & Merge Libraries” Target merges the corresponding particular binaries of each target into a single Universal (Fat) Binary that we can easily distribute and reuse.

Concepts and History

Some explanation is in order. When you’re developing iOS applications, you can test it directly on your iPhone device or within the Simulator. Now, Apple was very clever: any other vendor in the market will try to first create an ARM processor emulator to run on top of your i386 processor. Then it will get all the binaries for ARM and run within this emulator. The OS itself will remain compiled for ARM processors and run within the emulator.

Now, this is dead slow, impractical. Anyone that has experienced an emulation environment like this knows how ridiculous it is. Don’t confuse it for VMWare or Parallels solutions, which are fast because they are an emulated environment for the same processor , so you can run Windows on top of your Mac because the processors and operating systems now support VT-x, which means you mostly don’t have to emulate the processor. Now, every smartphone and tablet on the market uses an ARM processor, which has nothing to do with i386.

So, how did Apple deliver a super-fast iPhone/iPad emulator that runs at real-time speed on your Mac? Simple, it didn’t. It is called “Simulator” and not “Emulator” for a reason: everything that runs within the Simulator is compiled for i386, not for ARM. So what you’re running is an actual binary that runs natively over your Mac! No emulation required. The iOS is very portable. The same way Mac OS X was able to transition from the Power PC to Intel back in 2005, the iOS can do the same trick as they are basically the very same operating system.

When you choose the iPhone scheme in XCode, it compiles for ARM and uploads the bits to your iPhone device to run the application. When you choose the Simulator scheme in XCode, it compiles for i386, uploads the bits to your Simulator and runs natively as any other application in your Mac.

Now, going back to the main issue: when I distribute a binary of my Static Library, I have to remember that the developer will be linking against my library to deploy for both the ARM device (iPhone/iPad) and the Simulator (i386). So I would have to deliver at least 2 binary files. But Apple is even smarter than that. Actually, NeXT was. When they first transitioned the NeXTStep operating system from Motorola to Intel processors back in the late 80’s, they created Fat Binaries, which is essentially one binary that contains both processor-specific bits in one single package. When Apple transitioned from the Power PC to Intel they renamed it to Universal Binaries. And that’s essentially what we need to build now.

Operations

We now understand what a Universal Binary is. To make it easier, I right-clicked over the “Rubyfication” and “CocoaOniguruma” targets and duplicated them. They will be created as “Rubyfication copy” and “CocoaOniguruma copy”. We can change the “Product Name” in the build settings of each for a more reasonable name:

In my case I renamed them to “RubyficationSimulator” and “CocoaOnigurumaSimulator”. That will give me both “libRubyficationSimulator.a” and “libCocoaOnigurumaSimulator.a”. As you can see in the Products group:

Important: remember that the Rubyfication target had CocoaOniguruma as a target dependency. You will need to change the “Rubyfication SIM” target to point to the new “CocoaOniguruma SIM” target! The other thing is that you will need to force both new targets to compile to “Latest Mac OS X” in the “Base SDK" option in the Build Settings of each, and “32-bit Intel” in the “Architectures” build option. This will make them compile for i386 processors. The original targets should have their “Base SDK" to “Latest iOS” and “Architectures” to “Standard (armv6 armv7)”.

Now, we need to create a new target of the kind “Aggregate” :

I named it “Build & Merge Libraries”. In the “Build Phases” tab you will start with just the “Target Dependencies” phase. You just need to add the new “Rubyfication SIM” and “CocoaOniguruma SIM” targets. Then you need to add 3 more phases, one for “Run Script”, another to “Copy Files” and a last “Run Script”.

In the “Copy Files” phase I have just added all the public headers that I want to distribute together with the universal binary library. This is because the other developers will need to add those header files into their projects in order to be able to compile against my library. Now notice that I am copying them to an “Absolute Path” that states ${TARGET_BUILD_DIR}/../Rubyfication.

That’s where we come to the previous “Run Script” phase that should have the following code:

# 1. make a new output folder
mkdir -p ${TARGET_BUILD_DIR}/../Rubyfication

# 2. combine lib files for various platforms into one
lipo create "${TARGET_BUILD_DIR}/../Debug-iphoneos/libRubyfication.a" "${TARGET_BUILD_DIR}/../Debug-iphonesimulator/libRubyfication.a" -output "${TARGET_BUILD_DIR}/../Rubyfication/libRubyfication${BUILD_STYLE}.a"

The first thing it does is create this new “Rubyfication” directory. The second command uses the lipo command that merges 2 processor-dependent binaries into a universal binary. Pay attention to the PATHs if you’re reusing this script somewhere else. At least with XCode 4 that’s where it creates the binaries of each target:

• ${TARGET_BUILD_DIR}/../Debug-iphoneos/libRubyfication.a – the ARM version
• ${TARGET_BUILD_DIR}/../Debug-iphonesimulator/libRubyfication.a – the i386 version
• ${TARGET_BUILD_DIR}/../Rubyfication/libRubyfication-Debug.a – the resulting universal binary we created

Finally, the last “Run Script”, after the “Copy Files” phase described above, requires the following script:

ditto c -k --keepParent "${TARGET_BUILD_DIR}/../Rubyfication" "${TARGET_BUILD_DIR}/../Rubyfication.zip"

–

It just creates a ZIP file with the universal binary library and its companion public header files. Any other developer can get this zip file, unzip it and add the files to their own projects now. If you want to find where this ZIP file is, the easiest way is to go to the project viewer (the left side pane) in XCode, open the “Products” group, right-click over the “libRubyfication.a” file (or any other resulting file) and choose “Show in Finder”. Then you can navigate one folder up in the hierarchy (to the “Products” folder) and you will see something like this:

And there you go: there’s your ZIP file with your brand new redistributable universal binary!

Using the Universal Binary

In order to demonstrate how to use this distributable ZIP file, I have created a very simple, bare-bone iOS project called ObjC_OnigurumaDemo that you can download from Github and run in your own iOS device.

As you can see in the screenshot below, I just unzipped the ZIP within a “Dependencies” folder in my iOS project and added the universal binary “libRubyfication-Debug.a” within the Library Linking Build Phase:

This allows me to just use anything from this library in my project, in particular a piece of code that uses the Oniguruma regular expressions:

- (IBAction)runRegex:(id)sender {
    OnigRegexp* regex = [OnigRegexp compile:[regexPattern text]];
    OnigResult* res = [regex match:[initialText text]];
    NSMutableString* tmpResult = [NSMutableString stringWithString:@""];
    for(int i = 0; i < [res count]; i++) {
        [tmpResult appendString:@"("];
        [tmpResult appendString:[res stringAt:i]];
        [tmpResult appendString:@")"];
    }
    [result setText:tmpResult];
}

This demonstration application has a text-field called “initialText”, where you can type any string. Then you can prepare a Regular Expression in the “regexPattern” text-field and when you hit the “Run” button, it will trigger the action above that will run the Regular Expression against the initial text and write the matches within parenthesis in the “result” text view. The application looks like this:

And, voilá! Ruby 1.9-like Regular Expression, directly from Oniguruma, within an iOS Application!

The idea of this pet project is to be a Static Library that I can easily add to any other project and have all of its features. In this article I’d like to present how I am organizing its many subprojects within one project (and I am accepting any suggestions and tips to make it better as I am just learning how to organize things within Obj-C projects) and talk about a gotcha that took me hours to figure out and might help someone else.

To make this exercise even more fun, I also added a separate target for my unit testing suite (and see how XCode supports tests), then another target for the Kiwi BDD testing framework for Obj-C, and another one for CocoaOniguruma as I have just explained in my previous article.

I’ve been playing with ways of reorganizing my project and I realized that I was doing it wrong. I was adding all the source files from my “Rubyfication” target into my Specs target. So everything was compiling fine, the specs were all passing, but the way I defined dependencies was wrong. It is kind of complicated to understand at first, but it should be something like this:

• CocoaOniguruma Target: should be a static library, with no target dependencies and no binary libraries to link against, just a dependency to the standard Foundation framework. It exposes the OnigRegexp.h, OnigRegexpUtility.h and oniguruma.h as public headers.
• Kiwi Target: should be another static library, with no target dependencies and no binary libraries to link against, just having the Foundation and UIKit framework dependencies.
• Rubyfication: should be another static library, with CocoaOniguruma as a target dependency, linking against the libCocoaOniguruma.a binary and depending on the Foundation framework as well. It exposes all of its .h files as public headers.
• RubyficationTests: should be a Bundle which was created together with the Rubyfication target (you can specify whether you want a unit test target when you create new targets), with both Kiwi and Rubyfication targets as dependencies, linking against the libKiwi.a and libRubyfication.a binaries, and the Foundation and UIKit frameworks as well.

If you keep creating new targets manually, XCode 4 will also create a bunch of Schemes that you don’t really need. I keep mine clean with just the Rubyfication scheme. You can access the “Product” menu and the “Edit Scheme” option. Then my Scheme looks like this:

I usually configure all my build settings to use “LLVM Compiler 2.0” for the Debug settings and “LLVM GCC 4.2” for the Release settings (actually, I do that for precaution as I am not aware if people are actually deploying binaries in production compiled from LLVM).

I also set the “Targeted Device Family” to “iPhone/iPad” and I try to make the “iOS Deployment Target” to “iOS 3.0” whenever possible. People usually leave the default one which will be the latest release – now at 4.3. Be aware that your project may not run on older devices that way.

Finally I also make sure that the “Framework Search Paths” are pointing to these options:

"$(SDKROOT)/Developer/Library/Frameworks"  
"${DEVELOPER_LIBRARY_DIR}/Frameworks"  

Everything compiles just fine that way. Then I can press “Command-U” (or go to the “Product” menu, “Test” option) to build the “RubyficationTests” target. It builds all the target dependencies, links everything together and runs the final script to execute the tests (you must make sure that you are selecting the “Rubyfication – iPhone 4.3 Simulator” in the Scheme Menu). It will fire up the Simulator so it can run the specs.

But then I was receiving:

Test Suite '/Users/akitaonrails/Library/Developer/Xcode/DerivedData/Rubyfication-gfqxbgyxicfpxugauehktilpmwzv/Build/Products/Debug-iphonesimulator/RubyficationTests.octest(Tests)' started at 2011-04-24 02:16:27 +0000  
Test Suite 'CollectionSpec' started at 2011-04-24 02:16:27 +0000  
Test Case '-[CollectionSpec runSpec]' started.  
2011-04-23 23:16:27.506 otest[40298:903] [__NSArrayI each:]: unrecognized selector sent to instance 0xe51a30  
2011-04-23 23:16:27.508 otest[40298:903] ***** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '[__NSArrayI each:]: unrecognized selector sent to instance 0xe51a30'  

It says that an instance of NSArray is not recognizing the selector each: sent to it in the CollectionSpec file. It is probably this snippet:

# import "Kiwi.h"  

# import "NSArray+functional.h"  

# import "NSArray+helpers.h"  

# import "NSArray+activesupport.h"

SPEC_BEGIN(CollectionSpec)

describe(@"NSArray", ^{  
 __block NSArray* list = nil;

context(@"Functional", ^{ beforeEach(^{ list = [NSArray arrayWithObjects:@"a", @"b", @"c", nil]; }); 

it(@"should iterate sequentially through the entire collection of items", ^{ NSMutableArray* output = [[NSMutableArray alloc] init]; 

[list each:^(id item) { [output addObject:item]; }];

[[theValue([output count]) should] equal:theValue([list count])]; });
…

Reference: CollectionSpec.m

Notice that at Line 3 there is the correct import statement where the NSArray(Helpers) category is defined with the correct each: method declared. The error is happening at the spec in line 18 in the above snippet.

Now, this was not a compile time error, it was a runtime error. So the import statement is finding the correct file and compiling but something in the linking phase is not going correctly and at runtime the NSArray(Helpers) category, and probably other categories, are not available.

It took me a few hours of research but I finally figured out one simple flag that changed everything, the -all_load linker flag. As the documentation states:

Important: For 64-bit and iPhone OS applications, there is a linker bug that prevents -ObjC from loading objects files from static libraries that contain only categories and no classes. The workaround is to use the -all_load or -force_load flags.

-all_load forces the linker to load all object files from every archive it sees, even those without Objective-C code. -force_load is available in Xcode 3.2 and later. It allows finer grain control of archive loading. Each -force_load option must be followed by a path to an archive, and every object file in that archive will be loaded.

So every target that depends on external static libraries that loads Categories has to add this -all_load flag in the “Other Linker Flags”, under the “Linking” category on the “Build Settings” of the target, like this:

So both my RubyficationTests and Rubyfication targets had to receive this new flag. And now the Tests all pass flawlessly!

The Cocoa framework has both implemented as NSDateFormatter and NSRegularExpression that also happen to be available for iOS development.

You can format dates like this:

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];  
[dateFormatter setDateStyle:NSDateFormatterMediumStyle];  
[dateFormatter setTimeStyle:NSDateFormatterNoStyle];

NSDate *date = [NSDate dateWithTimeIntervalSinceReferenceDate:162000];

NSString *formattedDateString = [dateFormatter stringFromDate:date];  
NSLog(`"formattedDateString: %`", formattedDateString);  
// Output for locale en_US: "formattedDateString: Jan 2, 2001"  

And you can use Regular Expressions like this:

NSError *error = NULL;  
NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"\\b(a|b)(c|d)\\b"
 options:NSRegularExpressionCaseInsensitive  
 error:&error];

NSUInteger numberOfMatches = [regex numberOfMatchesInString:string  
 options:0  
 range:NSMakeRange(0, [string length])];  

But I have issues with both of these. The Ruby equivalent for the date formatting example would be:

require 'activesupport'  
date = Time.parse("2001-01-01") + 162000.seconds  
date.strftime("%b %d, %Y")  

And the regular expression example would be like this:

number_of_matches = /\W*[a|b][c|d]\W*/.match(string).size  

There are 2 specific things that annoy me:

• the Obj-C versions feel unnecessarily verbose. Now, I do understand that they are lower level and they will probably allow for more flexibility, but I think they should have higher “porcelain” versions, that are more straightforward.
• in Obj-C, the Date Formatting uses the Unicode TR-35 formatting standard and Regular Expressions use the ICU standard that is inspired by Perl Regular Expression with support for Unicode and loosely based on JDK 1.4 java.util.regex.

So, the ideal solution for me would be:

• to have higher level versions of those features;
• to have C-compatible strftime date formatting and Ruby 1.9’s Oniguruma level regular expressions.

It’s a Unix System

That’s when the obvious thing came to me: Objective-C is nothing more than a superset of C, so anything that is compatible with C is automatically compatible with Objective-C. More than that, the iOS is a Unix System! Meaning that it has all the goodies of Posix support.

So, how do I get C-compatible strftime? Easy:

# import "time.h"  

…  

- (NSString*) toFormattedString:(NSString*)format {  
 time_t unixTime = (time_t) [self timeIntervalSince1970];  
 struct tm timeStruct;  
 localtime_r(&unixTime, &timeStruct);

char buffer[30]; 
strftime(buffer, 30, [[NSDate formatter:format] cStringUsingEncoding:[NSString defaultCStringEncoding]], &timeStruct); NSString* output = [NSString stringWithCString:buffer encoding:[NSString defaultCStringEncoding]]; 
return output;

}

Reference: NSDate+helpers.m

Now follow each line to understand it:

• At line 4 it is returning the current time represented as the number of seconds since 1970. That method actually returns a NSTimeInterval which is a number that is essentially the same as the C-equivalent time_t
• At line 6 the C function localtime_r converts the unitTime number into the C-structure timeStruct
• At line 9 we call a custom method I created called formatter that just returns a strftime compatible string format. The Obj-C string (when we create using the “@” symbol) is an object that we must convert to an array of chars using the cStringUsingEncoding:. C functions don’t understand Obj-C strings, hence the conversion. Then we finally call the strftime itself that will store the result in the buffer array of char that we declared before.
• At line 10 we now do the reverse and convert the resulting C-string (array of chars) back into an Obj-C String.

Now this is too nice. I have added a few other helper methods that now allow me to use it like this:

it(`"should convert the date to the rfc822 format", ^{
    [[[ref toFormattedString:`"rfc822"] should] equal:@"Fri, 01 Jan 2010 10:15:30"];  
}); 

Reference: DateSpec.m

And the “rfc822” string will just be internally converted to @"%a, %d %b %Y %H:%M:%S" by the formatter: selector in the NSDate class.

Now, to add Ruby 1.9-level regular expressions you can go straight to the source and use the original C-based Oniguruma itself, exactly what Ruby does. There are several ways to integrate a C library into your Cocoa project, but someone already did all the hard work. Satoshi Nakagawa wrote an Obj-C wrapper called CocoaOniguruma that makes it dead easy to integrate into your project.

There are several ways to integrate an external library into your project. The easier way (albeit, not exactly the best) that I am showing here is by creating a new Static Library Target within my project, called CocoaOniguruma:

It will create a new Group called CocoaOniguruma in your project. Then you just add all the files from CocoaOniguruma’s core folder to that group, select the new target and all the source files and headers will be properly added to the project, like this:

Finally, you need to go to the original main target of your application and add both the new target to the target dependencies and the binary .a file to the binary linking section, like this:

With all this set, I recommend you to explore the OnigRegexp.m and OnigRegexpUtility.m, that are Obj-C wrappers to the Oniguruma library. The author already did some very Ruby-like syntax for you to use.

I have wrapped those helpers in my own classes like this:

- (NSString*) gsub:(NSString*)pattern with:(id)replacement {  
 if ([replacement isKindOfClass:[NSString class]]) {  
 return [self replaceAllByRegexp:pattern with:replacement];
 } else if ([replacement isKindOfClass:[NSArray class]]) {  
 __block int i = -1;  
 return [self replaceAllByRegexp:pattern withBlock:^(OnigResult* obj) {  
 return [NSString*](replacement objectAtIndex:(++i));  
 }];
 }  
 return nil;  
}

- (NSString*) gsub:(NSString*)pattern withBlock:(NSString* (^)(OnigResult*))replacement {  
 return [self replaceAllByRegexp:pattern withBlock:replacement];  
}

Reference: NSString+helpers.m

Which now allows me to use this nicer syntax:

context(`"Regular Expressions", ^{
    it(`"should replace all substrings that match the pattern", ^{  
 [[[`"hello world, heyho!" gsub:`"h\\w+" with:`"hi"] should] equal:`"hi world, hi!"];  
 });

it(@"should replace each substrings with one corresponding replacement in the array", ^{ NSArray* replacements = [NSArray arrayWithObjects:@"hi", @"everybody", nil]; [[[`"hello world, heyho!" gsub:`"h\\w+" with:replacements] should] equal:@"hi world, everybody!"]; }); it(@"should replace each substring with the return of the block", ^{ [[[`"hello world, heyho!" gsub:`"h\\w+" withBlock:^(OnigResult* obj) { return @"foo"; }] should] equal:@"foo world, foo!"]; });
});

Reference: StringSpec.m

If you’re thinking that it is strange for a snippet of Objective-C code to have keywords such as context or it, they come from Kiwi, which builds an RSpec-like BDD testing framework on top of SenTesting Kit for Objective-C development that you should definitely check out. But the code above should be easy enough to understand without even knowing about Kiwi. If you’re a Ruby developer, you will probably notice that the syntax bears some resemblance to what you’re used to already.

So, linking to existing standard C libraries or even third-party open source C libraries is a piece of cake for those simple cases, without having to resort to any “Native Interface” tunneling between virtual machines or any other plumbing. If you want C, they’re there for you to easily integrate and use.

Go is an ancient strategy game with simple rules and a profound degree of complexity.

Software development is the art of managing complexity using a limited number of rules, structures, and patterns.

Programmers should play Go.

Go in 2⁸ words or less

The beauty of Go is its combination of simplicity and complexity. On the one hand, go has only a handful of rules. Place stones, don’t get completely surrounded, control territory. Like chess, the mechanics can be picked up in a few minutes, though Go only has a single type of “move”, and only one edge case (the ko rule). And like chess, one can spend a lifetime discovering the strategic and tactical layers of the game.

While chess is quite complex and rich, such that it took a 30-node supercomputer to defeat the reining chess champion, no computer comes close to defeating even a skilled amateur Go player. There are 361 positions on a Go board, and with two players, there are 2.08168199382×10¹⁷⁰ valid positions. That’s quite a bit bigger than a googol (yes, that is the correct spelling). Realistically, there are something on the order of 10⁴⁰⁰ possible ways that a typical game could play out. And the number of possible moves roughly follows 361!, which means that only 20 moves in, there are many googols of possible ways that the game could shake down. (As a fun exercise, try plugging 361! into an online factorial calculator.)

Managing complexity

So how does one play Go, given this near-infinite complexity? On a tactical level, a player approaches Go like chess, thinking several moves ahead. But this only works in small spaces, like a tight battle in a small sector of the board. Beyond there, there are just too many possibilities. So on a strategic level, a player must think in shapes or patterns. These shapes provide shorthand ways of managing the complexity of Go. As a non-master, I may have no idea how things will proceed in one sector of the board, but I may be able to recognize strong and weak patterns of stones, vulnerable shapes and effective formations.

But there’s more: Go has several sorts of patterns. Beyond shapes, there are Go proverbs. These can be general: “Your opponent’s good move is your good move”; specific: “Don’t try to cut the one-point jump”; funny: “Even a moron connects against a peep”; and meta: “Don’t follow proverbs blindly.” These proverbs are principles which help a player make good decisions. They are less specific than shapes, and so they provide guidelines for whatever situations may arise on the Go board. Proverbs often conflict, and a player must determine when and how to apply them.

Finally, there are joseki. Joseki are patterns of play that are considered even for both sides. They typically happen in the corners of the board, and typically at the beginning of the game. Interestingly, there is a Go proverb that says “Learning joeski costs two stones,” meaning that memorizing these patterns isn’t helpful. Instead, a player should learn from joseki by understanding what is going on in each move.

Patterns in Go, patterns in software design

Each of these Go patterns has a rough programming analogue.

Shapes in Go aren’t unlike software design patterns. While there is nothing preventing you from placing logic in your views, this shape is recognized to be a weak one. Think of Gang-of-Four design patterns: the MVC, Adapter, and Factory patterns are recognized to be helpful in some circumstances (and not appropriate in others). On a lower level, iteration and recursion have commonly recognized shapes, as do database normalization vs. denormalization. Even if you can’t hold an entire program or algorithm in your head at once, recognizing common shapes helps you to understand what is going on.

Go proverbs are like another type of pattern in software: CapitalizedPrinciples (for lack of a better term) made popular by Extreme Programming. Think DontRepeatYourself, YouArentGonnaNeedIt, CollectiveCodeOwnership, DailyBuild, TestFirst. These aren’t specific code “shapes”, like a singleton class – they are general principles that guide the practice of programming.

Because joseki is about exchange between competing parties, its programming parallel is a little less clear. The closest comparison, in my mind, is programming exercises. This article, for instance, suggests 9 exercises to help you become a better OO programmer, like:

• Use only one dot per line
• Use only one level of indentation per method
• Don’t use setters, getters, or properties

In a real-world program, you’re unlikely to stick to these principles 100% of the time. But forcing yourself to write code in this way can be an eye-opening experience and can make you a better developer.

So what can Go really do for you?

Obviously, these parallels are structural. Specific Go proverbs (“Your opponent’s good move is your good move”) may not have direct relevance to software development. So can Go really make you a better developer?

I think it can, and I’ll go one further. I think Go can make you smarter. There is a lot of anecdotal evidence to this effect 1, 2, 3, for example, 4:

In fact, all of our minds can benefit from playing Go, which officially has the capacity to make you smarter. Research has shown that that children who play Go have the potential for greater intelligence, since it motivates both the right and left sides of the brain.

The research mentioned isn’t footnoted, unfortunately, so take statements like this with a grain of salt.

But it makes sense: like chess, Go requires pattern recognition, a mix of strategic and tactical thinking, and comprehension of complex structures, though in Go the patterns are larger and the complexity is greater. A mind trained to think in these ways is going to have an easier time attacking similar problems in other spheres.

Like software development.

Akita’s Notes

I’ve liked Go for a long time. As someone of Japanese descent, of course I’d been exposed to Go, Shogi, and other oriental games. But, like any good westernized Japanese, I paid very little attention to them. Because of this, today I know no more than the basic rules and philosophies behind Go.

My interest was particularly renewed when I read the Hikaru no Go series, which is an entire story built around Go, and one of my favorite series, by the way. I even bought a Go board and some joseki books, but didn’t get very far. These days I just peek at online games on the IGS servers.

I don’t remember where I read this, but someone once mentioned something interesting: chess is primarily a game of destruction. Go is essentially a game of conquest and expansion. Not literally true, but there are nuances in Go that bring this to mind.

And in the parallel to software development, design patterns aren’t just structures you copy and paste wherever you “think” they’re needed. A handful of design patterns doesn’t make good software.

What Jon was getting at makes a lot of sense. Just like a Go player, a software developer needs to be an artist. Playing is a creative activity. Strategy is a creative activity. Given a set of constraints, what’s the best path forward?

More than that: the only way to learn Go is by playing, hundreds of thousands of times over many, many years. Go professionals are formed around age 10 and climb from there into old age. The only way to learn is by failing, failing, and failing again. Which circles back to what Ryan said about Hurting Code.

Refactoring is something similar to this: conquest and expansion. Only a good developer understands the real reasons for refactoring. Nobody refactors because someone told them to, just as an artist doesn’t make a certain stroke because someone told them to.

A good developer values the form and philosophy of what is being built. Acronyms, brands, and fashionable names say nothing to them.

There’s a lack of eastern philosophy in today’s programmers. Being a brick-stacking coder is very easy: any grunt can do it. But reaching the 10th dan of programming is only for those who have put in the work in the art.