Andrey Listopadov


I often hear this phrase: “programmers are counting from zero”. No so long ago I’ve actually decided to check if it is true, and asked some programmers I know to count to ten out loud. None of them counted from zero. Well, this phrase is usually brought up when discussing various programming languages, which share the common idiom - zero-based arrays indexing.
The last time I touched ClojureScript was almost two years ago. It was a really fun experience, and actually, it was a bit special to me personally. Prior to that post, I only learned lisp1 via books and mostly used it only for configuring Emacs, and while I’ve liked the idea of code as data and other lisp aspects, I never did anything more with the language.


I think that the only acceptable test coverage percentage is about 100%. And in this post, I’ll try to explain why I choose to believe it.

A day ago I was asked if it’s possible in C to make some preprocessor macro that will create a tuple object from something like tuple(a, b, c). I’m not writing in C actively anymore, since I’ve switched to Clojure some years ago, but I still like to poke with C from time to time.
Originally these were all separate posts, but this generated way too many entries in the feed, so I’ve decided to put these into a single one. I’ve kept the content as is, and this very post originally contained the following message: This is just a quick update on the upcoming posts schedule.
This is it. The last puzzle of the event. We’ve almost made it through. The only thing that stands between us, and the sleigh keys are two herds of sea cucumbers. Cucumbers are constantly in the move, and our task is to simulate their behavior.
As it seems, when there are neither any problems to solve outside of the submarine nor inside of it, the computer still wants to give us some trouble! This time, though it is just a mere desire to play a game with us.
With the scanners fully deployed (totally, yeah, totally), we now can compute the map of the trench. But when we get the image from the scanners, it looks like a random noise (I wonder why, perhaps because of the extremely convoluted positioning in the previous task?
This weekend is quite different from the last one! Tasks are much harder this time, and I’m also out of the town without my laptop. So I’m writing this on my phone!1 I’m doing it in Emacs, installed inside Termux, which thankfully has a lot of packages, that allow me to continue working even without a laptop.
Today we need to send the probe into the ocean trench. To do that we need to fire the probe with certain x and y velocities, which are integers. For the first part, we need to find such velocity that the probe reaches maximum y position while still reaching the trench.
We’ve finally left the caves! This is such a relief, no more walls full of Chitons, or volcanic activity. And since we’re out of the caves, we’re able to receive a transmission to our submarine! The transmission is encoded with the Buoyancy Interchange Transmission System (BITS) and is represented in hexadecimal.
We’ve almost reached the exit of the cave! But there’s another problem, the walls are getting closer together, and the walls are covered with chitons, and we need to find the safest way so we wouldn’t damage any. Our input is a map of risk values, and we need to reach the bottom right coordinate:
Unfortunately, I wasn’t able to solve today’s puzzle myself, so I’ve asked my friend for help. The task was again about exponential growth, very similar to the day 6 puzzle. However, I wasn’t able to grasp how to keep things from growing this time.
It seems I’ve celebrated early, and the cave story goes on still. Our submarine reached another volcanically active part of the cave! In order to progress, we need to use our onboard thermal camera, which, unfortunately, wasn’t activated ever since it was installed.
The cave story seems to come to an end, as we’re finally heading out of the cave system! However, in order to do that, we need to determine the best path out, and the only way to do that is to find all paths.
After figuring out the deadliest basins, we enter another cave full of dumbo octopuses, officially named as Grimpoteuthis. There are 100 octopuses arranged in a 10 by 10 grid, and each one has an energy level from 0 to 9. Each discrete moment, every octopus gets one additional power to their power level, and after an octopus got more than 9 power, it flashes red.
Yesterday’s task was challenging, the task the day before yesterday wasn’t. The seventh’s day task was pretty straightforward, and the sixth one was kinda tricky to figure out. Today’s task is pretty easy again… I think I’m starting to see the pattern!
While I find the event to be awesome, I saw some negativity regarding Advent of Code noise over the internet. People are writing things like “this is just yet another code jam”, or “go build something practical and useful instead of wasting your time on pointless coding”.
Woke up late today, and didn’t have any time before work to do today’s puzzle. Turned out, this was actually good for me because the task today was quite tricky! I’ve spent several hours on the second part, and likely wouldn’t be able to finish the task before work, so it would have haunted me the whole day.
Remembering last year’s AoC, I can tell that solving one puzzle per day is much more pleasant than solving a bunch of puzzles in a single day. Last year I felt the burden of unsolved days, and an eternal race with the clock to keep up with others.
A new working week started, so without further ado let’s get started. Lanternfish New task! Today we’re watching how a massive school of glowing lanternfish swims past our submarine. There are a lot of them, so their reproduction rate must be growing really fast, or, as the task explicitly mentions, exponentially fast.
Looking at my post schedule, I’m starting to think that if the event will go as good as it goes right now, I’ll write more posts than I wrote since I’ve started this blog. Oh well. Maybe I need a separate section/category for this stuff.
The winter just has started, and it’s already the first weekend! The time goes pretty fast this time of the year. I guess it’s because there’s so much going on! There’s always some kind of rush at the end of the year at work.
So far the event went pretty straightforward! The tasks were simple but interesting. Looking at other people’s solutions, I’m starting to feel that I’m overgeneralizing things quite often. But I think it’s a good thing, as I can see and highlight the points I need to improve!
Day 1 was not that hard, let’s see how the day 2 puzzle goes! I’m going to continue solving tasks as early as possible for me, but I’ve decided to publish respecting posts a bit later the day, so I won’t spoil solutions to anyone who reads me and also participates in AoC.
Welcome to the series of posts on this year’s Advent of Code event! This year, to keep myself motivated, I decided to write a small post each day, in which I’ll describe the way I’ve approached this day’s AOC puzzle. As I’ve mentioned I’ll be solving puzzles in Clojure, (usually) formatting the code as can be seen in the REPL.
Lately, I’ve been into understanding asynchronous programming. Since my background is mostly bare metal C, which has no asynchronous programming whatsoever (apart from running on multiple chips, and communicating via shared memory), and I did only a little bit of C++ and Rust, it’s fair to say, that async is pretty new for me.
Today’s topic will be about lazy sequences and how these are different from iterators. I’ve wanted to make an article on this topic for some time, but unfortunately, there was no good way to show the differences using a single language (that I know), because usually, languages stick to one of those things.
Not long ago I’ve posted a small article on a Condition System in Clojure language. In that article, I was mostly trying to understand what a condition system is, and how it can enhance error handling in the code I write. Since that time, I’ve understood this system a lot better, by actually trying it in the Common Lisp language, the place where it came from, as far as I know.
A while ago I’ve watched this amazing talk: Condition Systems in an Exceptional Language by Chris Houser. And more recently I’ve found one interesting library called farolero, which provides a set of functions and macros that mimic Common Lisp’s condition system. So I was generally interested in the topic, and decided to give it a shot, and try both approaches.
Today we’ll take a look at interesting Java library, called PF4J, which describes itself as Plugin Framework for Java. The main purpose of this library is to provide a way of detecting, initializing, and using plugins to extend your Java application with new features without the need to modify the code.
Update: All the patches1​, 2​ has been merged into main branch of Fennel language, so expect to see improved fennelview in next stable release! Some semantics have been altered, so I’ve updated the post a bit to reflect the changes. Pretty-printing in Lisp is a way to represent data structures that we operate in our program in a human-readable way.
Previously I’ve decided to implement a rather basic raycasting engine in ClojureScript. It was a lot of fun, an interesting experience, and ClojureScript was awesome. I’ve implemented small labyrinth game, and thought about adding more features to the engine, such as camera shake, and wall height change.
Ray casting is quite old technique, that was heavily used in the early days of game development in a lot of games to create illusion of 3D space. Most known example, and perhaps first widely successful game that used this technique, was Wolfenstein 3D, made by ID Software in 1992.
At the end of the Part 2 I’ve mentioned that quasiquoting was problematic in GRScheme, due to some of the internal representations and algorithms, but now it is not an issue (I hope). I’ve figured out correct way to maintain list invariant, splice one tree into another tree, and so on.
Good things happened since my previous post! I’ve finished rewriting of interpreter from recursive to iterative, which means that there will be no stack overflows when traversing deep trees. I’ve also simplified name binding and lookup systems, added support for arbitrary-sized integers, fractions, and 64-bit floating point numbers, but most importantly figured out tail call elimination and closures.
At the end of my previous post I’ve mentioned that I will write more about GRScheme - language that I’m working on. As of this moment I’m rewriting it to be more robust and to fix some design flaws that make it impossible to do such things as tail call elimination.
This is my first public post that I wrote because I’ve finally thought that I’m clever enough to do so. Yet I must mention that I have never actually studied Programming Language Theory (PLT), so I’m not a specialist on the topic I gonna talk here.