Just a few thoughts on programming languages that have been rattling around in my head this week, but which don’t each merit a full blog post. The main theme is that the culture behind each programming language leads to some interesting choices, as is the case with spoken languages.

This week I started learning how to program in Rust. Even though I’m using the project-based Command-Line Rust to learn, the author still went with the traditional “Hello, world!” project for the first intro to the language. I was also working on a Go project last week and so it immediately stood out to me that (at least as taught by this author) Rust has the print! macro that allows you to succinctly print to the command line. By contrast, Go requires importing fmt before you can print. This was the first topic that was swirling around in my head this week. What makes language designers choose whether printing output (one of the most basic things a program can do) is built-in or requires an import. I even remember back when I was learning Java in undergrad (I think it was Java 1.8, but I don’t remember) we had to use the savitch library just to get program input (another very basic computer program concept). As I thought about it, I wondered if it has to do with thoughts around compilation and whether the language designers think you’re mostly making user-interactive programs or libraries? It makes sense to me that scripting languages like Python, Ruby, and Perl would have print built-in since you always have to have the interpreter along with you, so all the basics should be there. (The original Batteries Included Python promise, for example) But perhaps the Go developers thought you wouldn’t always be printing to the command line so a more efficient binary could be compiled by forcing you to import the functionality? I’m not entirely sure.

December was wholly dedicated to solving the Advent of Code 2022 problem set. Our job was to help the elves trek through the jungle to get magical starfruit. It was a lot of fun to do it live once again! This year I also had experience from the previous years (both live and on my own pace) that gave me the skills to solve some of the puzzles, including some puzzles that were variations on themes I’d seen before. In the end, I collected 36 stars, near my average for number of stars collected during AoC. Between work, family commitments, my programming and problem solving skill levels, that’s about the most I can usually do during the live period in December.

Python

This year I really worked a lot on Python web technologies so I came to appreciate all the work that the JetBrains team does to make all the little things (like running Django test server commands) incredibly easy. I essentially did all my Python development in Pycharm.  I’ve had access to the paid JetBrains suite because of the work I’ve done for my open source project: Extra Life Donation Tracker. Since development has slowed a bit on there, I may not be able to renew the subscription. If that’s the case, there’s a big chance that I’ll start saving up some money for a Pycharm Professional license. The only real exception to using Pycharm for programming was when I was editing code on a server. There I would use vim or nvim (more on that later).

In these last two months of the year I only worked on Advent of Code.

November

In November I worked through part of the 2016 problem set. I didn’t get too far because of how many languages I was doing at this point. Eventually I decided to allow myself to get a bit further in Python and then catch up with the other languages. Whenever I’d get stuck I’d go back to the other languages. Overall, once I’d figured out Python - Ruby, Perl, and Golang would be pretty easy. Haskell would still be hard, but I started getting the hang of it near the end of the month.

Across both September and October I got a decent amount of programming done. I just about finished the Learn You Haskell for Great Good book (got up to just before Monads) and started Head First Go. Once I had enough Go language to get started on AoC, I knew I’d be ready for the 2016 problem set. Let’s get into the nitty gritty!

Python (not Advent of Code)

Impractical Python

I finished chapter 11 which contained my old friend the Monty Hall Paradox. I’ve had a version up on my site for a very long time based on a PHP tutorial in Linux Format Magazine. This time I was able to code it in Python as well as creating a GUI version. Chapter 11 also touched upon The Birthday Paradox.

Throughout the spring and summer of 2021 a few of the times that I mentioned on the Advent of Code subreddit that I was doing the 2015 problem set in all 3 languages, some folks said they’d be interested in a writeup on the experience. Now that I’ve finally finished 2015 (my first set of 50 stars!) it’s time for that writeup. Before I continue, I’d like to thank everyone on the subreddit who has helped me. I have a README.md for each day’s problem and you’ll find my thanks to those who helped me within those READMEs here in my repo.

I didn’t do much coding in July, so I decided to combine the July and August wrap-ups.

Python

Dreamhost Dynamic DNS

I decided to clean up and update some code that uses the Dreamhost API to allow for Dynamic DNS. I cleaned up the logging output so that I could figure out why it was sometimes deleting one of my domains rather than just updating the IP. The original programmer had it printing out to the terminal. I used the logging package to send logs out to a file. While I was improving the logging, I also decided to use f-strings to make it more obvious what was going into the output string.

June was mostly Python, although I did do chapter 1 of Scratch 3 Games for Kids with Sam. He really, really enjoyed it and I anticipate doing the challenge problems and maybe chapter 2 in July or August.

Books

I read the intro and first couple chapters of both Flask Web Development, 2nd Edition and Data Visualization with Python and Javascript, both from a recent Humble Bundle. The Flask book may be useful for learning more about creating a non-Django site and, even if I mostly stick with FastAPI, it should provide some concepts that are applicable across both frameworks. With the data visualization book, I would love to use that to better visualize my annual Last.fm stats.

Advent of Code 2015 Problem Set

Day 10

There’s a lot to be said for doing the Advent of Code in December along with a few thousand other programmers. It’s fun to be part of something with others and you get to all the neat and wacky solutions that others come up with.

On the other hand, going at my own page with the 2015 problem set allows for interesting little coincidences to form. What I did one day (when I was at about Day 7) was to go through all the remaining days and write some first impression ideas at solutions. This got my brain thinking about what I needed for each day. One day, before getting to the Day 10 problems, I was idly flipping through the book Learn You a Haskell for Great Good! As I was trying to decide if it would be one of the languages I’d add for 2016. I ended up coming across a built-in library that would have made solving Day 10 a real breeze. Day 10 is the Look and Say sequence. I’m sure by paying close attention to that Wiki entry I could have figured out an algorithm. But, basically I just needed to group together each repeated number and then I could take the length of that list/array to find out how many numbers. That becomes part of the new number. Unfortunately, as far as I could see, that functionality was not built into Python. So my Python code looked like this:

I had a lot less variety in my programming month, but still had a lot of fun doing it. In fact, Programming consumed most of my leisure thoughts. More about why I was doing it below, but I’ve been reading Programming Perl as well as skimming through Introducing Go and Learn You A Haskell for Great Good!. Ever since some folks used Haskell during last year’s Advent of Code and this guy’s videos that I mentioned in an early 2021 blog post, I’ve been very curious about the language. In fact, at this point I’ve decided that Go and Haskell will be the next two languages I learn.

Back in 2019, when I did my programming retrospective I made a few predictions. How did those go?

• Work on my Extra Life Donation Tracker? Yup! See below!
• Write more C++ thanks to Arduino? Not so much.
• C# thanks to Unity? Yes, but not in the way I thought. I only did minor work on my game, but I did start a new GameDev.tv class.
• Learning Ruby? Well, I wouldn’t necessarily say I learned Ruby. I did finish the book Ruby Wizardry and I took copious notes. But until I do some practice - maybe via some code katas, I don’t think I’ll have solidified it in my mind.
• 3D Game Dev? Nope, not really.
• Rust and Go? Not even close. Although I did make sure to get some books on the languages.

So, what happened? On the programming front, I wanted to continue my journey to truly master Python after having used it at a surface level for the past 15ish years. I dedicated myself to doing the Python Morsels challenges (more on that below) and working through various Python development exercises. Outside of programming, the time I had off from COVID was used to play with my kids and they wanted to play lots of video games. So we took advantage of having way more time than usual to do that. So a lot of my goals slipped. We’ll get to 2021 predictions at the end, so let’s take a look at 2020!

You may notice it’s been a while since I last wrote about programming. Well, a lot of the programming I was doing with the kids was due to having more time on my hands thanks to COVID. With Scarlett back in school full-time, there’s a lot less time for that as we focus on making sure she gets the most out of her education as well as teaching the twins to make up for not being in preschool this year. This has left me with reduced time for all my projects and entertainment (games, TV, and reading). Up until now that has meant the programming was put off to the side - kind of. Because I’ve been loving my exercises from the Python Morsels website and I’ll be talking about that when I get to the Python section. But first up, Ruby!

I don’t know how long I intend to keep doing this, but I decided I wanted to document my programming as I went along. So yesterday I worked on Scratch and here’s today’s entry.

Ruby

A while ago I got a bunch of kids’ programming books in a Humble Bundle. I tried showing Ruby to my oldest, but I did it one year too soon (she wasn’t yet reading as well as she is today and couldn’t type as well as she can today) so for now she’s not into programming. But I was curious to see how it was presented since the book uses a story to present it (quite different from the Python book in the same bundle). Went through chapter 2 today and, so far, it seems that Ruby is pretty readable like Python is. That said, I’m not sure puts makes more sense than print, but maybe if I delve into the history of Ruby, I’ll understand why it’s puts? The author of this book uses snake case for variable names. I wonder if that’s because it’s the Ruby standard to use snake case instead of camel case or just to make it easier for the kids following along. I *did* really like the built in next and pred methods on numbers. Definitely more readable than a var++ or var = var + 1. Or rather, if you don’t have decades of programming experience (as I do), I think it’s just a faster bit of cognition to see var.next and understand it vs the older ways of doing the same thing.