DEV Community: Onorio Catenacci

A Handy Way To Clear The Terminal In Python

Onorio Catenacci — Fri, 02 Aug 2024 19:35:38 +0000

So I have been using the Python REPL quite a bit lately. I've been using it on Windows and it was really getting quite annoying to me that I couldn't clear the terminal screen.

With a little bit of work I was able to hack together this code to allow me to clear the terminal. There were a few small issues that made this non-trivial.

Running CLS

Most of the examples I could find on StackOverflow used os.cmd to call either clear or cls. Using os.system is deprecated. I needed to figure out how to run this as a subprocess. This made it slightly more tricky because cls is an internal command. That means it's built into the cmd executable. We can't execute cls directly therefore we need to execute it as part of an invocation of cmd.

The command line is cmd /c cls. The /c parameter tells the command processor to immediately exit after executing the cls.

import subprocess

def clear() -> None:
    command = ['cmd']
    args = ['/c','cls']
    cli = command + args
    subprocess.run(cli) 
    return None

Making Clear Available Automatically

So while we have the right code now we want it to automatically be available to us every time we fire up a Python REPL clear is available to us.

It's my understanding that there are multiple ways to stash this code so that Python picks it up automatically. Here's how I did it.

I created a new User Level Environment Variable PYTHONSTARTUP and pointed it to my %USERPROFILE% directory. USERPROFILE is the Windows analog of the HOME directory on a *nix machine. I saved the code in a .pyrc file which I stored into the %PYTHONSTARTUP% directory.

This is nothing major or earthshaking but it took me a few minutes of work to figure it out so I thought others might like to know about it as well.

A Quick Utility Module

Onorio Catenacci — Tue, 30 Apr 2024 15:36:51 +0000

I was working on some code with a friend of mine and we came up with what seems a relatively clever way to do a couple of validations. I'm putting this post here to share this in case it benefits anyone else:

defmodule Validations do
  @moduledoc """
  This module contains a few validation predicate functions.
  """

  @doc """
  Checks if a string contains only specified characters.  The specified characters are passed in a list. The list can be one or more characters. You could pass an empty list if you wished but that would always return false.

  ## Examples

      iex> Validations.string_contains_only_specified_chars?("abc", ["a", "b", "c"])
      true

      iex> Validations.string_contains_only_specified_chars?("abr", ["a", "b", "c"])
      false
  """

  @spec string_contains_only_specified_chars?(String.t(), [String.t(), ...]) :: boolean
  def string_contains_only_specified_chars?(string, list)
      when is_binary(string) and is_list(list) do
    string
    |> String.graphemes()
    |> Enum.reduce(true, fn letter, acc -> letter in list && acc end)
  end

  @doc """
  Checks if a string is of a specified length or not.

  ## Examples

      iex> Validations.string_expected_length?("abc", 3)
      true

      iex> Validations.string_expected_length?("abc", 2)
      false
  """
  @spec string_expected_length?(String.t(), integer) :: boolean
  def string_expected_length?(string, length) when is_binary(string) and is_integer(length) do
    String.length(string) == length
  end
end

Nothing innovative or surprising--just a little something I whipped up that I wanted to share for the potential benefit of others.

On The Value Of Listening To Warnings

Onorio Catenacci — Wed, 31 Jan 2024 16:41:02 +0000

One common mistake I've seen repeatedly over the years is the assumption that compiler warnings (in those languages which provide them) are simply noise that one can safely ignore. It's a bad habit to get into for a few reasons:

It encourages the sloppy practice of letting warnings go for month after month with no developer investigating the problem the warning is indicating.
It encourages a mentality of it compiles so it's right which is almost never a good approach to take.

I was recently having a conversation with another developer about one of the most seemingly useless warnings--"unused variable".* Now I'm unsure of the original reason for warning but it's not hard for me to imagine.

I believe (and may be wrong) that the notion of compiler warnings originates with the C language. The whole notion of compiler warnings was to flag code that is syntactically correct but may be suspect. Consider this code fragment:

if(x = 1)
{
  printf("It's 1\n");
}
else
{
  printf("It's not 1\n");
}

I'll bet more than one or two of you can spot the problem without trying very hard. But this used to be legal C code. Doing an assignment inside a test that way is almost never a good idea but it was perfectly legal in C. You'd get a warning about it but if you're in the habit of ignoring warnings, you may never bother to check it because "it compiles so it's right." Now when you look at a code fragment that way what's wrong with it is usually pretty easy to spot. Let's say that our if test occurred in the middle of a 200 line routine. Then, maybe not so easily spotted.

Ok, so that's all well and good but why is it (or would it be) useful to warn about unused variables? Consider this code fragment:

int addemup(int n, int m)
{
  int M = 1;
  /* code
     more code
     more code */
  return n + M;
}

Now, again, in isolation like this it's probably pretty easy to guess that someone should have written return n + m; (although that may not be right either). But the code is syntactically correct. Did the developer mean to ignore the parameter? We can't tell from the context.

This is why I think warnings about unused variables and/or parameters is a warning a lot of us should pay a lot more attention to. If you really don't need the parameter, then why is it being passed at all? You may say, "Well, there's a requirement to pass it due to old code that requires it." Consider that an odious code smell.

Code should be built intentionally, not accidentally. If you've truly got a routine with a parameter that it doesn't need then you're building code accidentally.

This, by the way, is an example of what I call code that works in spite of itself. This is when you run across code that makes you scratch your head as you're trying to figure out what the developer was doing and why they took such an odd approach. Did they mean to ignore the parameter passed in? The function is called "addemup" so it seems like it should add its parameters, right? The code doesn't seem to have any obvious problem but it just looks odd and you may have to spend a lot of time deciphering it.

Of course most code doesn't start this way; it acquires warts and oddities as it's maintained by multiple developers over the course of time.

In summary, not only should you not ignore warnings, if the option exists, treat them as errors so you cannot build your product until the warnings are addressed. You'll save yourself a lot of work and your code will be easier for others to maintain.

Notes

I am unsure if more recent versions of C have promoted this to an error but that seems to be the current behavior. I cannot find anything definitive either way.

Creating Repeatable Builds

Onorio Catenacci — Fri, 12 Jan 2024 17:40:21 +0000

Repeatability

There's a very important concept in building reliable software. It's repeatability. If you work building software for any appreciable amount of time you will run across a situation where a client reports a bug in your software which you cannot recreate. This is what is meant by repeatability. You want the same behavior regardless of whether it's on your machine or the clients.

Another difficult situation is the case of an intermittent bug. The client repeatedly sees an issue but there doesn't seem to be any consistency to when or how it happens. This is also the opposite of repeatability.

Both of these situations are bad. For one thing they eat up time in hunting down bugs that are especially hard to diagnose. They also make the client less likely to trust you in the future; after all if you can't make your software work, regardless of the actual cause, why should they trust you?

A Funny Machine

Let's imagine for a second that you've got a machine that takes four inputs (e. g. threads) and transforms them into something else (e. g. cloth). Further let's imagine that you make some sort of mechanical change to the machine and suddenly it stops working as expected. What's the cause of the problem? While it might be any number of things, the most likely cause is the last change we made. It was working before we made the change and now it isn't so logically the change seems to be the most likely cause of the problem.

Now let's imagine that we change two of the inputs and we change the machine at the same time. And the machine stops working. Which alteration was it that caused the machine to stop working? The change to the machine or the change to one or the other input? This makes diagnosing the cause of the failure a lot more time-consuming and complex.

So there are two lessons we might draw from this imaginary scenario:

Try not to change more than one thing at a time
If you must change more than one thing, try to test after each change.

All Other Things Being Equal

So how does our imaginary machine relate to the idea of repeatability? In this way: if we create a process that works correctly when we deploy it to a client's machine anything that differs on the client's machine may cause a failure. Hence if we can we want to deploy to a client machine that as closely as possible matches the machine on which the software was built. In other words we want to keep everything "equal" other than the actual software we're deploying.

How can we achieve this state of "all other things being equal"? Docker is one great way to achieve this. By using a docker image and being very careful about the software included in the image we can remove differences between our machine and a client's machine. This is one of the strong appeals of using docker in the first place--it helps us to eliminate the "works on my machine" syndrome. However, there are steps beyond using docker we can take to eliminate any sort of variability.

When we deploy software we're dealing with at least two things: the code we've written ourselves and its dependencies. We need these dependencies else we'll end up having to build everything from scratch. What developer would bother to rewrite routines to fetch a file from the hard drive? We all use the OS provided routines to do this. But using the OS routines does introduce a dependency. Usually these dependencies don't concern us but any time any software we depend upon changes it's a potential source of a bug.

Versioning

If you've ever heard the term DLL Hell, in essence it was a problem with dependency management. When Microsoft's team first designed dynamic link libraries they relied on the name of the assembly alone to test if they had the right library. Hence if I had a library called mylibrary.dll and another application had a library called mylibrary.dll if I were not careful the application might use the wrong version of the library. There was nothing present in the linker/loader to check the library being loaded to insure it was the correct one.

Now one answer to this problem is strong versioning. In other words I make sure I identify the version of mylibrary.dll I need and I make sure I update the version any time a change is made. Semantic versioning is a step in this direction. In my code I can add code to test that I'm getting a particular version of a library--helps me to avoid DLL Hell. Of course if I have version 1.0 of mylibrary.dll and another software package has version 1.0 of mylibrary.dll then I still have a problem.

There's also the issue of a developer who isn't careful with his/her versioning? What then? He or she makes a change to a library (or a Javascript module etc.) that seems so minor they don't bother to change the version number. How do we account for that? The answer is a hash of the binary artifact.

What is a hash? Imagine you had a process to take every byte in a file and reduce them to a single value. Maybe you'd take the first byte and add it to the second and then take that sum and add it to the third and so forth. (Note: that example is extremely simplified. A real hash function is considerably more complex.) This is what we call hashing a file. In hashing we're trying to create a value from the file that is

Totally unique to the contents of the file.
Not likely to accidentally be the value of a different file (this is called a hash collision).
Reduces to a value that's not too large.

The first property is the one we're most interested in. If I have a file that starts with the bytes 0x10, 0x15, 0xFF, I want the hash derived from the file to be different than the hash derived from a file starting 0x10, 0x16, 0xFF. In this way I can easily programmatically detect that the two files are not the same.

By hashing the binary artifact I no longer need to worry about the version information provided by the developer. If even one byte in the file has been altered the hash will be different and I'll know.

Great But How Does This Help Me?

This is what the NixOS package accomplishes for us. It gives us the infrastructure to build binary artifacts with confidence that all the dependencies (or inputs if you will) are invariant.

This is along the same lines as mocking when one is creating unit tests. If unit tests depend on potentially variable inputs then when we have a failure we need to check if the failure was caused by changed code or by changed dependencies. Mocking allows us to keep our dependencies unchanged between runs of our tests so we can be confident that if we see a failure it's our code change that's caused it.

NixOS allows us to take that idea of holding external elements the same and apply it much more rigorously to the entire build process. It allows us to build docker images that use precisely the same shared libraries to insure that if there is some sort of failure we don't have to spend time examining external dependencies. With so many of us deploying docker images to AWS and other cloud services, being able to know that the image on our machine and the image in the cloud is identical is a huge win.

Proud Moments In Mentoring!

Onorio Catenacci — Mon, 30 Oct 2023 15:07:29 +0000

Ok, yeah, I'm bragging a bit. But it does give me a (possibly undeserved) sense of accomplishment to help other developers step up their coding game. And I strongly suggest that if you want to step up your coding game, try mentoring others. As the old saying goes when one teaches, two learn.

https://exercism.org/profiles/OnorioCatenacci/testimonials?uuid

Searching For Polar Bears In Chicago

Onorio Catenacci — Fri, 04 Aug 2023 13:51:42 +0000

This is a post I've been meaning to write for some time. It's a pretty common scenario. Someone proposes using some outside of the mainstream language for a project at a company. IT leadership stiffens up. "How are we going to find developers for language x? We can find scads of developers for {Java|C#|Javascript Library} but how will we find people who can code x?" I wish sometimes I could be in those meetings. And I sincerely wish I could speak to recruiters who seem to think it's impossible to find developers for anything other than Java or C#. A couple of thoughts to share:

You're Not Looking In The Right Places

Scour LinkedIn for developers with experience in oh, let's pretend it's 2001 and you want developers for Python. I know things have changed in the last couple of years since the folks doing LLM and other numerical work have found Python but there was a time when Python was considered "niche". Heck there was a time when Java was a rare skill as hard as people may find that to believe today. There's some survivorship bias that makes languages like Java, Javascript and C# seem as if they were inevitably destined to win.

But, my apologies, I'm digressing. If you were scouring LinkedIn for Python devs (assuming LinkedIn existed back then), you probably wouldn't find many. This is not because there weren't Python devs in 2001. It's because Dice, LinkedIn etc. were not the right places to find these developers at that time. Today's niche languages will be tomorrow's "every developer in the world wants to learn them so he or she can get a job" language.

There are now (and were back then) forums, IRC channels (2001), slack channels (today), and conferences where people who liked Python would gather to chat. That's where one could find Python developers. And back in 2001 when you found a Python developer chances were that he or she was exceptionally good at their job. This is exactly because it was hard (then) to get a job coding Python so most developers coding in it were coding in it because they truly cared about building good software and they considered that the best way to do it.

My point is if you're looking for people coding non-mainstream langauges you'll have to do a bit more work than just searching LinkedIn. Find them where they congregate. If you're not sure where they congregate ask someone in the community. It's not usually that hard to find people advocating for a particular language and they're usually more than happy to help recruiters find the right spot to find developers.

They're Teaching Javascript/Java/C# In Bootcamps

This is very true and if you're looking for an endless supply of junior developers to learn their trade on your codebase you're in luck! Don't get me wrong; I've met lots of folks from bootcamps that were very capable and could certainly hold their own against any developer in the shop. But, honestly, they stood out to me exactly because they were so capable.

And, again, don't get me wrong; most folks from bootcamps will grow into good developers. I've seen that happen too. But be honest--do you want them learning why it's not a great idea to use inheritance as opposed to composition on your codebase? Do you want them learning that making calls to a database inside a loop is a recipe for very poor performance?

My point is while there's certainly safety in sticking with the herd, you're never going to build a world-changing IT team by swimming in other team's wakes. And don't you really want to build an IT team that people will be beating down the door to work for? I can remember a time when working at Google was incredibly prestigious. Isn't that how you want people to view working for your IT team?

Calling A Tail A Leg

Onorio Catenacci — Mon, 13 Feb 2023 21:46:41 +0000

How many legs does a dog have if you call the tail a leg?
Four. Calling a tail a leg doesn’t make it a leg.

-- Attributed to John Hulbert and Abraham Lincoln

I've seen a few things lately about functional programming in C#. This reminds me of the days in the early 90's when people confidently proclaimed that you could certainly code OOP in Visual BASIC. My response to them then is closely related to my response to people saying you can code FP in C#; "calling C# functional doesn't make it functional."

So why isn't C# functional and why can't it ever be? One very simple reason: default immutability. This assertion requires a bit of explanation. I need to peel back some abstractions but I trust it will be worth your while to follow me on this.

What Is Mutability and Immutability?

Consider the simple pseudocode x = 1; the actual programming language is somewhat immaterial at this point. Abstractly what I'm telling the compiler to do is to mark some memory location with the name x and then put the value 1 in to that memory location. As a developer I normally do not need to know where x actually lives in memory.

Now, let's say that I need to add one to x. There are a few ways I can do that. First I could read the value at the memory location identified by x and add 1 to that value and then store it back to the original memory location. That's referred to as "destructive assignment" and it's a trait that most (maybe all?) imperative languages share. I change the value in place; this is what mutability actually is. Or I could read the value stored at x, add 1 to it and then write it to a different memory location. I trust you can see why this might be slightly confusing though; if I write x to a different location then am I still talking about x?

Now why do I care about changing a value in place versus changing it and writing it to a different memory location? Because of multiple threads of execution.

Consider this scenario. I initialize x to 0. I then run two threads against my current memory state. The first thread adds 1 to x. The second thread tests if x is greater than 0 and then runs logic (call it l) based on that. Now I cannot determine in advance which thread is going to run first. If thread one runs first then l will be run. If thread two runs first then l will not be run. I cannot determine exactly what will happen because what will happen depends on which thread runs first.

On the other hand if I initialize x to 0 (immutable) and then it cannot be changed, then this is trivial. The first thread adds 1 to x but stores the result in some other memory location. The second thread always runs l.

What Does Mutability Have To Do With Functional?

Impure functional languages (e. g. F# or Scala) usually make values immutable by default and a developer has to make a special effort to make a value mutable. That is, making a value mutable must be intentional in these languages; it can't happen by accident or ignorance. Pure functional languages (e. g. Haskell) do not allow mutable values at all. C#, which is an imperative language, defaults to all values being mutable and if you want an immutable value you must indicate it. Again, an immutable value is something that has to be intentional in C#; it cannot happen accidentally.

So does this mean that it's impossible to write functional code in C#? Nope. It does mean that writing functional has to rely on developer discipline. Developers have to put "const" on pretty much every quantity.

Ok, So Why Is Const Everywhere An Issue?

So let's imagine you've got a crew of very experienced and disciplined developers who indeed do slap a const on every quantity that should be treated as immutable. Even when they do put "const" on every quantity there are still two big holes:

1.) They cannot control the mutability or immutability of quantities used by 3rd party libraries.

2.) They cannot control code constructed by the compiler.

And even if you're willing to live with those holes, how much extra effort do you think that insuring const is used correctly everywhere will add to a C# project? How much extra testing effort will be added to insure that everything behaves as expected? And remember that you cannot control the behavior of third party libraries so you'll need to be very careful about data being sent to and received from third-party libraries.

You can call a tail a leg but that doesn't make it one. You can tell yourself that C# supports functional programming but that doesn't make it a functional programming language.

By the way, I'm not trying to disparage C#. It's a fine language and lots of good software is written in it. But if you want the advantages (and yes the drawbacks) of writing in the functional paradigm you're far better off to choose a language that actually supports functional programming.

Git Force Push Current Branch Only

Onorio Catenacci — Thu, 18 Aug 2022 20:38:12 +0000

So recently I found out there's a good reason to use a particular syntax for force pushing a branch to the backend.

I was doing this for a force push:

git push -f

Why would I force push a branch? Because I often end up squashing lots of small commits on the branch into a single commit to make the commit history easier to read. When I do that I need to force push to overwrite the existing history. Mind you I'm only doing this on my own branches.

However, I found out much to my distress that if you've got multiple references to your backend (that is multiple branches tracking to origin) they all get force pushed when you do -f. If you're curious about this it's here in the git documentation.

There is an alternative that works just fine if you're only meaning to force push your current branch. What you can do is this:

git push origin +<branch>

This will only force push the named branch. However since I need to do this fairly often (as I say after I squash all the commits on a branch I force push so that instead of having 12 commits on a PR, I've got one) I want a git alias to make this easier for me. And so I came up with this:

fp = "!p() { CURRENT_BRANCH=$(git branch --show-current); git push origin +$CURRENT_BRANCH; }; p
(I'm indebted to Phil Haack for demonstrating this technique of using a shell function in a git alias to allow for trickier stuff!)

First I get the current branch name into the CURRENT_BRANCH environment variable. Next I create the git push command substituting the CURRENT_BRANCH name. Finally the shell function is invoked.

This does a force push but only on the current branch so I don't have to worry about inadvertently forcing other branches to the backend.

Three Ways To Share Values Between Elixir Modules

Onorio Catenacci — Thu, 21 Jul 2022 19:44:50 +0000

I find that as I get older I find myself trying to remember coding techniques and idioms that shouldn't be hard to remember but sometimes are anyway. This is one of those cases--the module attributes took me a bit of effort to work out so I thought I'd write it down. I'm sharing it here so others might benefit from it as well.

What Do I Mean By Constant?

First it feels appropriate to say that when I say constant I have a definite technical meaning in mind. In a mathematical sense a constant like pi or e is simply a value that's fixed on the number line. In the sense that software developers use the word "constant" we usually mean something which is an extension of the notion of a mathematical constant--a fixed value. It could be a number or a string or even a more complex data structure; the point is that in the course of the normal execution of the binary it won't change.

Here I'm using the term constant to name a value that needs to be referenced in two or more modules in Elixir which none of them will change. The value will be defined in one module and then read from others. There are two reasons to do this approach:

It makes the code more readable
It keeps the developer from repeating his/her self.

Both of those are good reasons for using this approach. I'm going to examine them a little bit before I discuss the coding techniques specifically.

Keeps the Developer From Repeating

It's become a mantra chanted over and over by developers who don't know much but they do know that repeating anything in code is a bad idea. Except it isn't always a bad idea. The trick is to know when it's ok to repeat things and when it isn't.

Part of distinguishing between one case and the other is to understand why repetition is a bad thing in the first place. The problem is that if I duplicate code and said code needs to be fixed later there's a good chance I won't find all the duplications and fix them too. And that's assuming I'm working on my own code. It's even more likely to be a problem when someone else will be maintaining your code. They're more likely to miss spots where the code needs to be fixed.

So the next time you're tempted to copy/paste a bit of code think of your future self (or perhaps the poor person who will maintain your code) and do a bit of refactoring so you don't need to repeat the code.

Now, there are times when repeating code actually simplifies things. Part of the issue with removing duplication is that it introduces coupling. As long as your coupling is clean and simple (in the decomplected sense of "simple") you're fine. Shared definitions--numerical constants, strings that signify names, etc.--definitely fall under this rubric.

However code under maintenance tends to get a lot of "this is almost what I need but not exactly". This is part of the reason people tend to copy/paste code in the first place. So the admonition to avoid repeating code is not an absolute one and you should apply your judgement. Is the place where you're thinking of copy/pasting likely to change frequently? Are the changes likely to differ from changes to the original code? Then by all means copy/paste. On the other hand, if it's not likely to change frequently then you're better off to reference the single defintion from the other places in your code. An example of something which may change but is not likely to change often is a company name. It's possible for a company to change its name but it's not likely to happen very frequently. If you've hard-coded that name 50 places in your code that's 50 places you have to find and fix. If you hard code it in one place and then reference the constant in other code then you only need to fix it in one place.

Partially the decision about what should be repeated and what shouldn't comes down to cohesion; that is to say, how much does the code in some particular block of code all serve one function. If a piece of code is highly cohesive (e. g. a function to calculate the area of a circle) vs a lower cohesion function (e. g. calculate the area of a circle, print the circle in three colors and then return the current date) then it's better not to repeat the code. Our judgement about copying and pasting code should be inversely proportional to the strength of the cohesion of the code.

Like many ideas in engineering the notion of "don't repeat yourself" is not one that can be applied without thought or judgement.

Constants In Elixir

Now having said all that let's talk about a couple of ways to deal with values shared between modules in Elixir. You can register an attribute in one module and then reference that attibute from the other modules or you can create a (for lack of a better name) constant function--that is a function that takes no argument and simply hands back a constant value. If someone knows the right name for this sort of function please post it in the comments for me! For sake of illustration I'll pretend I need a Pi constant in my code.

Consider the following code:



defmodule MyMath do
   Module.register_attribute(__MODULE__, :pi, persist: true)
   @pi 3.141592653

   def pi, do: 3.141592653
   # this could also be: 
   # def pi, do: @pi
end

and now there are two ways for me to fetch the value of Pi in other modules:



defmodule My.Other.Module.That.Needs.To.Know.Pi do
   defp get_pi do # module attribute approach
      [pi] = MyMath.__info__(:attributes)[:pi]
      pi
   end

   def circle_area(radius) do
      MyMath.pi() * radius * radius #constant function approach
   end

   # or
   def circle_area_alternate(radius) do
      get_pi() * radius * radius
   end
end

Both of these approaches will work. The attributes approach is really not recommended for a constant shared between modules. It's more recommended for metadata about a module--author, last revision date etc. The more recommended way to do this (although I will grant that it looks a bit odd) is a constant function.

EDIT:

After I originally posted this article it was pointed out to me by several smart Elixir developers that there's a third way to share values between modules. I wish I could take credit for coming up with it but as far as I know that credit belongs to Paul Schoenfelder who's a super-smart developer!

The trick is to define the value to be shared in a using macro in the source module. Like this:



defmodule MyMath do
 defmacro __using__(_) do
    quote do
       @pi 3.141592653
    end
end

Then you can simply use the module in a different module and the using macro is run and the value becomes available. Like so:



defmodule My.Other.Module.That.Needs.To.Know.Pi do
   use MyMath

   def circle_area(radius) do
      @pi * radius * radius #"using" macro approach
   end
end

The main idea here is that if you're using the same named value in multiple modules, you want to avoid defining it more than once. Defining the value in several different modules is an excellent way to insure that someone will miss changing the value somewhere in maintenance and that can lead to some really odd, difficult to reproduce bugs.

And you can run this via ReplIt too:
Shared Values Between Modules

Just In Case

Onorio Catenacci — Mon, 13 Jun 2022 13:06:46 +0000

Recently I was working on some Elixir code and I ran into something which sort of surprised me although I guess it shouldn't have. I was typing code something like this:

alternate-value = 4

and iex responded with this:

** (CompileError) iex:8: cannot invoke remote function :erlang.-/2 inside a match

I thought to myself, "who's trying to subtract?" but then it occurred to me what was actually happening. And so I thought I might write this up for the sake of helping to reinforce the lesson for me as well as maybe to help some beginners understand a basic property of Elixir.

Let's Get Down To Cases

For sake of this discussion there are four ways of casing variable names that we're interested in. Casing meaning the mixture of upper and lower case letters in a variable name and what that conveys.

PascalCase

There's PascalCase which seems to have been the preferred casing of the Pascal programming language. I'm not sure of that and I've honestly never bothered to check because it isn't important.

If you PascalCase a variable in Elixir something odd happens:

iex(3)> PascalCase = 1 ** (MatchError) no match of right hand side value: 1

What's going on here? Well by default in Elixir any name starting with an uppercase letter is an atom. In fact if we do this:

iex(3)> is_atom(PascalCase) true

Yep, PascalCase is an atom. And because PascalCase is an atom the only thing it will match is itself.

iex(8)> PascalCase = PascalCase PascalCase iex(9)> PascalCase == PascalCase true
Hence PascalCase = 1 is attempting to pattern match 1 to the atom PascalCase and it fails because the only thing that matches an atom is itself. Not to short-circuit the suspense but pattern matching is an important topic in Elixir and I'm not going to treat it here.

camelCase

The second type of casing for variable names is camelCase. In case you don't get the developers' (weak) attempt at humor here, the capital letter in the middle is supposed to resemble a camel's hump. Hence the fact that no developer is going to be booked into the Improv in our lifetime.

As far as I know, Elixir has no issue whatever with camelCase but it isn't standard Elixir idiom. This works:

iex(1)> camelCase = 1 1

However your colleagues may scratch their heads a bit at the funny casing you're using. Most of these casings are intended to allow us to use multi-word variable names without it all reading like alowercasesentencewhichcanbeveryhardtoread.

snake_case

Again, I think this name comes from a subtle attempt at humor. We developers are nothing if we're not a lot of frustrated comedians.

I once heard the "Baby Boom" generation referred to as an example of the "python swallowing a pig" model. If you visualize this rather gruesome (for the pig) scenario then you can probably figure out why it's called "snake_case".

snake_case is the preferred casing of variables in Elixir so try to get yourself in the habit of using it--except in module names where Pascal case is the rule.

kebab-case

As far as I know this casing style comes from Javascript and if you try to use it in Elixir (as my very first example showed) you'll get a very odd error. It may bear with a word of explanation.

Consider this code:

iex(8)> kebab-case = 1 ** (CompileError) iex:8: cannot invoke remote function :erlang.-/2 inside a match

Now if you've come from most other languages that looks as if you're assigning the value of 1 to the name kebab-case. But that would be incorrect in Elixir (well, as far as I know in Elixir and any other BEAM based language). This is not assignment; it's actually pattern matching.

I won't belabor the point because far better writers than me have spent a bit of time explaining pattern matching. Suffice it to say that when you write kebab-case = 1 you're not doing assignment; you're actually pattern matching. And because Elixir code is ultimately translated into the bytecode of the BEAM virtual machine, when it sees the minus sign in your variable name it thinks you're attempting subtraction.

A word about that message: :erlang.-/2 is the BEAM's way of uniquely identifying a function. In Elixir an uppercase letter at the start of a symbol name signifies an atom; however you can also signify an atom with a leading colon. Hence :erlang is the identifier for the Erlang module. -/2 is the function name. It means the minus function taking two arguments.

So the message is essentially telling you that the beam thinks you've tried to invoke the subtraction function in a pattern match and that invoking a function in a pattern match is not allowed.

EDIT: It was pointed out to me that kebab-case doesn't come from Javascript. In fact as far as I can tell it's actually a coding standard in HTML and CSS. The point that it won't work in Elixir still stands though.

Using Ack To Search Elixir Code

Onorio Catenacci — Fri, 27 May 2022 16:03:21 +0000

I've been a fan of ack for quite some time. Somehow (and I'm not quite sure how) once or twice it's found stuff in source code that VSCode simply misses (likely I was searching wrong with VSCode). And there are a few things I've found that make it even more effective in searching Elixir code that I thought I'd share.

How Do I Configure Ack?

First, how to get ack? If you're on a Mac then simply use Homebrew to install it: brew install ack. For those on Windows there's a Chocolatey NuGet package here. If neither of those are an option for you there are installation instructions on the homepage.

Secondly how should you configure ack for optimum use with Elixir? I think the easiest way to set things up is to create an .ackrc file in your home directory. So a ~/.ackrc file. This is mine:

--type=elixir --smart-case --ignore-dir=deps --pager=less -R -F

In order, this is what this .ackrc does:

It tells ack to assume I'm searching elixir files (--type=elixir). Ack is smart enough to ignore .git directories and other temporary files when it's searching for text. This tells ack that I want to search only through Elixir files by default.
Smart case tells ack to search case-insensitive unless I have an upper case letter in my search string. Obviously Elixir is case-sensitive so this is very helpful.
Ignore directory (--ignore-dir) tells ack not to search in a given directory and below. Since I don't usually want to see stuff that's brought in via Hex packages I ignore everything in any of the deps directory by default.
Use less for the pager. Less is a very neat tool that allows you to scroll forwards and backward through text output to the terminal one screenful at a time. So by specifying less for my pager the ack output is sent out one page at a time and I can scroll forward and backward through it as I need to.

If you want to use ack without these settings (assuming you've added them to an .ackrc on your machine) you can simply pass the --noenv switch to ack on the command line and any settings in your .ackrc will be ignored.

How Do I Actually Search?

Open a terminal and then change to the root directory of the source code you want to search (e. g. ~/git/myelixirapp). Then it's ack stringtosearchfor (e. g. ack defmodule). If you want to search for a string containing spaces you need to enclose the string in double quotes (e. g. ack "defmodule MyGreatModule do").

One very interesting option for ack is to tell it to search within a given range of code. For instance if I'm looking for a function called "reverse_string_and_json_encode" then I can use a few parameters to ack on the command line to help me quickly narrow my search. By using this command line: ack --range-start 'def reverse_string_and_json_encode do' --range-end 'end' I can find the exact definition of the function whereever it's defined. Two important details about range-start and range-end:

Range-start and range-end both support regular expressions. For example, if I weren't quite sure of the name of the function I could also pass --range-start 'def reverse\w+' and --range-end 'end'
You use single quotes (not double quotes) around the strings you use with range-start and range-end.

Are There Other Options?

If you don't care to use ack (or you have some sort of aversion to it), ack actually lists several good alternatives on their home page (under More Tools → Other grep-like tools). I won't bother to repeat them here.

What Else?

If you spot something I've got wrong, please let me know! One reason I even bother to write this up is that I know of no method faster to find something I've gotten wrong than to share it with nerds.

i = i + 1

Onorio Catenacci — Mon, 02 May 2022 20:05:07 +0000

My father ran a job shop over in Fraser, Michigan. In this job shop he had some computer numerical control (CNC) machines. These were machines that had been purchased from a Swiss firm and although they worked pretty well, like any machine they needed occasional maintenance. And my father, like any smart business man, was loath to spend money he didn't need to spend so he'd try to figure out problems with the CNC by himself before contacting the vendor's paid and expensive tech support service.

He had in his shop one person who fancied himself a bit knowledgeable on the subject of computers and so he volunteered to take a look at the problem and see if he could solve it. I gather from what my dad told me afterward that this machine had its instructions coded in something akin to BASIC. This employee studied the instructions and finally thought he'd found the issue. He pointed to the source on a line reading something like i = i + 1 and told my father that must be the problem because there was no way that could be correct.

My father related this to me and I, of course, informed him that wasn't meant to be read as an algebraic statement; it's meant to be read as an instruction. Take the value in i, add one to it and then store that value back into the memory location where i is.

Now having said all that I can certainly understand why my dad's employee thought it must be the problem. Algrebraically the statement would be nonsense. Most of us who write software for a living have gotten so accustomed to this idiom (or the C/C++/C#/Java idiom of i++;) that it doesn't give us a moment's pause to see it any more.

Why Do We Accept This As Normal?

So to my mind the question naturally arises--when so many of us (and indeed the inventors of most programming languages of note) have a good background in mathematics, why do we accept this sort of abberation of expression as being perfectly normal and needed?

At one point given limited memory it likely made a lot of sense to allow this pattern that I've heard referred to as "destructive assignment". Since I'll use that term a few more times from here on out I'll refer to it as DA. When you've only got 64Kb of memory then conserving memory is a major engineering concern. The alternative (writing the value to a different memory location and binding it to another name) would quickly become a problem in a tight memory situation. But unless someone is doing embedded software development I'd think the issue of tight memory constraints is no longer a main consideration in how we write software.

Also not everyone does accept it as normal. There are a few programming languages which distinguish assignment from equality testing. Pascal uses := for assignment and = for equality testing. C and languages derived from it use = for assignment and == for equality testing (a situation that has caused some very tricky bugs in C code over the years). i := i + 1 is a very visible way to show we're not trying to assert equality.

Even more to the point DA does contradict our understanding of mathematics. If I have an equation 4 = x + 2 there's only one value that will make that statement true. While I don't know what x is (let's pretend that the answer isn't trivial to arrive at) it's an unknown value not a variable. It doesn't vary at all. In that sense calling something which supports DA a "variable" is actually more correct than we may initially realize.

Modeling Reality?

The people I know who are the biggest proponents for OOP usually tell me they prefer it because it allows them to code in a way that mirrors reality. That's an excellent goal for sure. We certainly want to create software that closely mirrors the problem domain we're tackling. And it's true, that is a benefit of OOP. But in what reality can an unknown take on arbitrary values? For any algebraic equation you can name (or at least any I can think of) there's a limited set of values which make the equation true.

In fairness I am conflating two ideas. OOP isn't the same as imperative programming; DA is a feature of the imperative programming paradigm. That said though, so much OOP is so closely aligned with imperative programming that they often seem synonomous. And pretty much anytime someone codes a loop in any imperative language they code a loop counter (or their colleagues give them grief). Absent newer approaches (like LINQ which, coincidentally, is modelled on the functional programming paradigm) if you code a loop that needs to execute a definite number of times without a loop counter all you're going to do is cause a lot of head-scratching and perhaps anger among your colleagues.

Now having done both functional and imperative programming I can tell you that there are good and bad aspects to both paradigms. But one thing that is a big accidental complexity in the imperative paradigm (at least to my mind) is DA. If a developer uses DA carefully and intentionally then it's no problem. But all of us get under deadline pressure and carefully checking things is one of the first things we jettison. We assume everything will proceed on the happy path.

And there's another very important accidental complexity associated with DA. Most developers working in software these days will not be aware of all the issues that manual memory management caused for developers in the past. And part of the problem with manual memory management was DA. In the days of manual memory management it was a common practice to store memory addresses in memory (C's pointers). When I can easily overwrite a memory address with another one and not only does the compiler not warn me--it is actually expected behavior--the potential for buffer overruns and other hard to trace bugs is greatly increased.

And even if you are very careful to insure you don't do DA unless it's absolutely justified your colleagues may need to interact with the software artifacts you provide and they may not be as careful as you are in insuring they only use DA when absolutely needed. I mean why should we rely on software developer discipline when we can push the issue to the compiler where it really belongs? Let the compiler check us so we don't have to worry about having missed something.

It's Past Time To Move On From Destructive Assignment

There's a whole class of errors which can be laid right at the feet of DA. One can make off-by-one errors occur in functional languages (which lack destructive assignment). It is, however, considerably more difficult to have it occur due to the fact that DA simply isn't allowed and the compiler will raise an error if you try to do so. In fact running a loop for a fixed number of times actually becomes slightly more work in the functional paradigm. Off-by-one errors are sadly quite common in languages that allow DA.

C. A. R. Hoare once refered to nulls as his "Billion Dollar Mistake". And, no doubt nulls and null checking seem to have added far more complexity than they've removed. But DA is also responsible for a lot of accidental complexity and there's not really a good reason to allow it going forward. We can't fix all the legacy code in the world that relies on this but we can learn better ways of coding to remove this accidental complexity.