2021-10-13 Update

Lately I have not done much programming on my own time or learning new things.

I have been updating my site with images. I found a few sites with images from medieval manuscripts, and I have been adding them to this site. One commenter mentioned there should be more visual variety on this site. I do not have a much in the way of artistic skills, so I decided to go with stuff that is in the public domain.

The images usually do not have anything to do with the content of the post, so if you don’t see a connection, there probably isn’t any.

I got a lot of the images from Wikimedia, and a lot from various state and national libraries in the USA and Europe. I am not affiliated with any of these sites.

Plus I don’t know a lot about art, and this seemed like a good way to learn a bit more about it. I like manuscripts from the start of the Carolingian period to about the twelfth century. Then a lot of stuff starts to look like greeting cards. But Byzantine, Armenian and Georgian manuscripts maintain their quality for a few more centuries.

The only downside to medieval art is they aren’t making any more of it. At some point, I might have to learn some libraries for generative art.

More Lisp/Racket/Clojure coming soon, perhaps with Go or Elixir as well.

You’re welcome.

Image from Cycle of miniatures, a 12th century manuscript housed in the Benediktinerkollegium in Sarnen, Switzerland; image from e-codices, assumed allowed under Public Domain.

2021-05-31 Update

I did not do much with any programming projects this past month.

I got through The Seasoned Schemer. Not all of the code worked for some reason. I barrelled through it pretty quick. I might go through The Reasoned Schemer.

I have been looking at Go. I made a new bookmarks folder for my Go bookmarks. I think I need to be well-versed in a non-JVM language, and the contenders are Go and Elixir. One thing that I do not like about Elixir is that it seems like you have to know some Erlang and know about the Erlang VM. One think that I am not liking about non-Java JVM languages is that it seems like you have to know some Java to be useful. And it looks like Kotlin is going with the Spring/Hibernate route for web applications; those are parts of the Java ecosystem I am trying to get away from. Vert.x looks interesting, and does not seem to use Hibernate or Spring, but it is not commonly used. If I am going to go with something less common, I might as well branch away from the JVM. That said, I will still look into Clojure.

I have been working more on the Org Mode course by Rainer König. I plan on going through that some more. Hopefully this will transform my life.

You’re welcome.

Image from Biblia Latina (Vulgata): Evangelia, made in Fleury around 820. There are several places in France named Fluery; the source is not clear which one this manuscript is from. The manuscript is at Burgerbibliothek of Berne  (Wikipedia page here), image from e-Codices, assumed allowed under Fair Use.

2021-04-11 Update

I know I said I was going to focus on Clojure, but I looked at some other things in the past week.

I am looking into some Amazon certification for AWS. There is a big push to get certified at my current employer, and I would like to do something different.

I started the org-mode tutorial from Udemy.

I also looked at The Seasoned Schemer. I think that having already gone through Simply Scheme I may have gotten some of the concepts. A lot of it deals with recursion.

Chapter 12 dealt with “letrec”. letrec is like let, but instead of binding a name to a variable or data, you can bind a name to a function, and you can call that function recursively.

One thing this can allow you to do is it can relieve you of the need to call a helper function. In Simply Scheme, I made all the functions tail-recursive. To do this, you usually need a parameter that is the “accumulator” or the output (see this answer on Stack Overflow or my post here).

In The Seasoned Schemer, they use letrec for functions in which one argument does not change and one does, such as checking if an atom is a member of a list, or performing a union of two lists:

I know I think the whole argument about Lisp/Scheme being hard to read because of all the parentheses is usually exaggerated, here I think for these letrec examples there might be something to it. These were hard to type correctly from the book. For example, the internal function has to be after the “(set-1)” which is the argument to the “lambda”, but before the closing parens for “lambda”. And the call to the internal function has to be before the closing call to “letrec”. You can have multiple functions defined in a “letrec”, and your call to the internal functions can be in a cond.

A helper function to do the actual work with tail-recursion might be more lines of code, but I think it is easier to understand.

Chapter 13 is about let/cc, combining let with “call-with-current-continuation”. I think some people consider this Scheme’s defining feature.

They have a function rember-upto-last which takes an atom and a list of atoms and removes everything in the list before the last instance of the atom as well as the atom.

Here it is:

Here is a tail-recursive version:

Both of these have a commented out call to “(R (cdr lat)” (with a second arg in the tail-recursive version) below the call to “skip”.[Note 1]. In the tail-recursive version, either  call gives the proper result. In the regular version, we are building our answer through a chain of calls to “cons”. The “skip” eliminates all the pending “cons” calls, and the function is called anew with whatever the then-current values are. In the tail-recursive version, we can get rid of those “pending” values ourselves.

I think Java might get continuations soon.

You’re welcome.

[Note 1]: For some reason, the code formatter I am using does not always color comments correctly. In all variants of Lisp that I have seen, comments start with a semi-colon.

Image from Psalterium Gallicanum with Cantica, a 9th century manuscript from the monastery of St. Gall, housed at Central Library of Zurich. Image from e-Codices. This image is assumed to be allowed under Fair Use.

Every and Any in Clojure

Today we look at a few functions in Clojure that take predicates and look at collections: any?, every?, not-every? and not-any?

any? seems to return true for any argument. According to the docs, it is used for clojure.spec. Maybe when I learn more about spec, that will make sense. You would think a function called “any?” would be useful if you had a collection of numbers, and wanted to know if any of them are odd, or greater than 10, or something like that. Perhaps they could have given it a better name than “any?”

every?, not-any? and not-every? behave as you would expect them to. You can always simulate “intuituve-any?” by calling “not-any?” and then calling “not”.

You’re welcome.

Image from the Rheinau Psalter, a 13th century manuscript housed at Central Library of Zurich. Image from e-Codices. This image is assumed to be allowed under Fair Use.

Reduce In Clojure

The last of the Big Three Higher Order Functions in Clojure is reduce. In other languages it is called fold, accumulate, aggregate, compress or inject.

Sometimes reduce is compared to aggregate functions in databases, like average, count, sum, min or max. These functions take multiple values, and produce one value. Some functions in Clojure, like the four main math functions (+, -, * and /) are processed through reduce if they are called with more than two values.

I would like to point out that unlike the other aggregation functions that databases have, “average” cannot be done with reduce. To do an average, you sum the amounts, and then divide by the number of elements. No implementation of reduce (or fold or whatever you call it) keeps track of the number of elements and allows for an additional operation at the end. Maybe some languages or implementations have a reduce and an enhanced-reduce to cover this case.

The first parameter to Clojure’s reduce is a function that takes two parameters. There is an optional parameter that is an initial value, and the last argument is the collection you want to process. Reduce takes either the option initial value and the first element of the collection, or the first two elements of the collection, and passes them to the function. The output of the function is then used along with the next element in the collection. Reduce keeps using the output from the previous element and the next element as arguments to the function until the collection is exhausted.

I cannot find it now, but I remember reading somewhere that reduce can be hard to understand because “reduce” is frankly not a good name for it, and there are many functions that do what reduce does. As stated, some of the functions in Clojure (like max, min, and some math functions) call reduce. So you are actually using reduce a lot under the covers.

There is a cartoon about this. A teacher gives a student a few chances to say what is “2 + 3” equal to. The student says it equal to “2 + 3” and it is also equal to “3 + 2”. The student gets an F. The cartoon ends with: “Sad fact: many math teachers do not know the difference between equality and reduction.” I admit I do not either. A lot of the cartoons are about Haskell, which I have no desire to learn.

You’re welcome.

Image from  Aurora Consurgens, a 15th century manuscript housed at Central Library of Zurich. Image from e-Codices. This image is assumed to be allowed under Fair Use.

Focusing On Clojure

I have decided to focus on Clojure going forward.

I think of all the Lisps, Clojure right now has the most momentum. And I got a couple of inquiries about Clojure positions.

I have been going through the Clojure API, inspired by an article called “One Weird Trick To Become a Clojure Expert“. The article advocates going through the API alphabetically. Maybe I should have done that, but I think I might be better off going through a few books.

I know at some point I have to stop learning and start making something. But I think that going through the API might not be the best way. And the two are not mutually exclusive.

One of the books I will go through is the third edition of Programming Clojure. One of the co-authors is Alex Miller, who helps make Clojure at Cognitect. Clojure does things differently than other languages, and if anyone can explain it, it is the people at Cognitect. The same publishing company has a book called Getting Clojure, which is written by Russ Olsen, who also works at Cognitect.

Reading books by Cognitect employees is one way you can get Clojure.

You’re welcome.

Image from Ms DF III 3, a 10th century manuscript housed in the Strahov Monastery in the Czech Republic; image from Wikimedia, assumed allowed under Public Domain.

The Map Function In Clojure

The next member of the Big Three Higher Order Functions is “map“.

I don’t think “map” is a good name for it because 1. There is a data structure named “map” (which has different names in different languages) and 2. I don’t think it is the most descriptive name for it. “apply-to-every” or “apply-to-all” might be better.

The “map” function takes a function and one or more collections, and applies the function to each member in the collection. In Clojure, if you send multiple collections, they will be concatenated into one output collection.

I think the reason it is called “map” is that you are using a function to map a collection onto another collection.

Clojure also has “mapv” which does the same thing as “map” except that it returns a vector, and “mapcat” which takes functions that take collections as arguments. The functions sent to map and mapv take single arguments (if you send one collection) or multiple args, but not collections.

You’re welcome.

Maps In Clojure

I was planning on looking into Clojure’s map function, the second of the Big Three Higher-Order Functions. But looking over my Clojure API page, I noticed there were a few functions with the word “map” in it that I had not gone over yet that deal with the map data structure.

Just as “map” is a noun and a verb in Clojure, the map data structure goes by different names in different programming languages: associative array, map, dictionary, symbol table, hash, hash table.

Anyway, I have looked at some of these functions earlier, but here are some more functions dealing with maps:

You’re welcome.

Clojure Filter

The first higher-order function in Clojure I will look at is filter. It takes a predicate and a collection. It returns all the members of the collection for which the predicate is true. The docs say that it takes a “predicate”, but that predicate duty is frequently fulfilled by a function.

I tried calling filter with “true” as the predicate, and it did not work. I guess in Clojure (and probably all Lisps), a predicate is just a function that returns a boolean.

Filter is one of the Big Three Higher-Order Functions, the other two being Map and Reduce. This one actually has a name that describes what it does.

Clojure has two versions of filter: filter and filterv. The difference is that filter returns a lazy sequence, and filterv returns a vector.

If filter is called with just the predicate, it will return a transducer. I will cover transducers later.

There are also another “filter” function in the clojure.core.reducers namespace. It takes the same arguments as the core filter, but when I tried it in a REPL I got an error. After looking at the Clojure page on reducers, I think the functions in that namespace only work if you chain them together.

You’re welcome.