Since beginning this undergrad program (really, the CS transfer program at my previous school) and starting my internship, I’ve found myself working in several different environments with several different tools. I’ve been able to scrape by in most of them, but haven’t stuck around with any one of them for long enough to become really familiar with it. I can specialize template classes and manage pointers in C++, but I don’t know how to use most of the standard library. I’ve grown from using a couple of Linux commands in a Manjaro VM to writing increasingly useful Bash scripts, but I’m not rapidly adding Linux commands to my toolbox. I’ve programmed in at least 10 different languages in the last year, but I’m not happy with my proficiency in a single one of them.

I think that this means that I need to start making use of the related Familiar Tools and Concrete Skills patterns, or at my own dot product reinterpretation of the two. The Familiar Tools pattern is all about developing consistency with a tool that you already trust yourself with, and Concrete Skills is about developing a proficiency foundation to build on. I have some foundation, but it’s split across a bunch of different technologies, and I need to rebuild it starting from a single tool that can become familiar to me.

The tool that I’d like to become familiar with is Rust. I share a lot of the general and technical priorities of that project. It’s great that it’s flexible and able to progress and fix mistakes without being paralyzed by a need to forever remain backwards-compatible. More importantly, I want to eventually work mostly with statically typed languages, and I love that it lets you opt into fewer levels of abstraction. For example, how cool is it that you can inline assembly in the same language that considers C-style undefined behavior to be a design failure?

Now that my formal education is ending, I’m going to use some of my spare time to develop my concrete skills in Rust by working on small projects. Hopefully, one of those will be working through Sedgewick & Wayne’s Algorithms again in Rust, some will be collaborative projects on fun things that I can’t yet get paid to do, and some will be projects where I figure out how to integrate a Rust backend with other tools that I need to learn more about anyway such as web APIs and AWS CloudFormation and Timestream.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Craft over Art is a pattern I’d like to start keeping in mind as I program. Because every functional specification can be implemented in more ways than any of us can imagine, I tend to think up the one best way that I can imagine how to solve a problem, and then continue solving the problems that come up on the way to that result.

There are two problems with this approach, both of which can be addressed by following the Craft over Art pattern. The first issue is that often, when trying to do a new thing, what I learn along the way indicates that there is some easier or more useful solution. When I treat programming as an art, these concerns are secondary to finishing the beautiful thing that I first set my mind on. In many cases, though, these realizations are a sign that it’s time to change plans in order to achieve some other goal that will be more useful or achieved more quickly.

The second problem with my process is that the best way I choose to set out on is often one of the artistically best solutions I can think of, not the way that most quickly results in a product with acceptable quality. As the author says, the professional goal of software development is to make useful things, not to write beautiful code.

I do think that, to some extent, writing programs in the most perfect way that you can is good exercise for developing mastery in an area of programming, as is continuing to learn and implement new ways to do things. After all, some problems really are suited to specific solutions, especially when some form of performance is important. For example, determining a superior route between nodes is a problem that should often be solved after considering the methods of graph theory. Sometimes, though, the stakes are low, and there really are no other concerns besides a solution’s approximate correctness and the speed with which it is implemented.

One of the main reasons that I like programming is because there is so much opportunity to be paid to work in a way that’s artistically fulfilling to me. But as an apprentice who wants to improve, I think that limiting this impulse to appropriate times is one of the most valuable skills that I can learn over the next few years.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

With the breakable toys pattern, the learner conducts experiments and observes the work of others to improve their own understanding of how to build complex systems. Apprenticeship Patterns suggests a few ways to go about this. You might build a simplification of an existing problem that you’re already facing. By reducing uncontrollable variables or emulating a single possible case, you can come to understand one key interaction, tool, or data flow at a time until you become capable of composing a solution to a broader problem.

Another possibility is building your own projects that are not focused on understanding one specific issue you are already facing. Doing so can build a familiarity with your tools, and can lead to unexpected creativity or interest in learning how others achieved problems you might never have otherwise encountered.

The third variant of this pattern is the analysis of external source code. The abundance of open-source projects provides an effectively infinite learning resource for studying how others design systems and resolve issues.

I think that this pattern is a very important part of long-term learning. It can be easy to build habits when programming: you can usually come to a desirable result either by brute-force trial and error from the bottom up, or by drawn-out requirements planning that gets done before any prototype is built. But I’ve found myself spending far more time invested in one of these two methods than I should have, when remaining flexible and incorporating aspects of the other would have led me to a better solution faster.

In general, I think it’s a shame how often the daily work of software development can feel detached from the playful curiosity of the scientific method. Much of the most rewarding learning happens as a result of developing a question and finding a finding out how you can reach a confident answer to it. Considering we’re working in the one field where rapid iteration and near-zero cost to entry makes the scientific method universally accessible, I’d like to hope I’d take advantage of that by putting myself in many situations that generate spontaneous curiosity.

That’s what I like about making a breakable toy. It’s usually more fun to play with than the projects that we have real responsibility for, and that fun makes us want to understand everything about the toy and how the toy could grow into something else.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Whenever you’re new to a thing, a comparative look at different tools can help you understand the problem by learning how each tool approaches a solution. As someone new to consuming and designing APIs for the web, I’m interested in understanding APIs by looking at the difference in approaches of the REST specification and the GraphQL query language. This post is based on Viktor Lukashov’s GraphQL vs. REST blog post, which explores some GraphQL basics from the perspective of a REST API user.

Priority: server-defined endpoints or client-defined queries

The largest difference mentioned by most sources is that a well-built REST API relies on extensive backend definitions of endpoints, while GraphQL puts the onus on the consumer to carefully query the correct data.

In REST, accessing multiple entities requires visiting an endpoint for each entity. These endpoints expose data through predefined parameters and responses. Meanwhile, GraphQL exposes a single endpoint while only returning data that corresponds to the consumer-defined query. This approach requires higher effort from the user, but allows them to construct tailored queries without the need for forethought from the API designer.

As a fan of query languages, I think this comparison is very favorable to GraphQL. For any interesting or useful dataset, a user exploring the data should have more ideas about how to observe it than its maintainers and gatekeepers will. Providing flexibility for query writers lets your interface be used in ways you can’t predict.

Implication: caching and performance

One upside of REST’s focus on a planned set of endpoints and parameters is that expected frequent responses can be use HTTP caching to improve performance. Responses to GET requests will be cached automatically, reducing server requirements and potentially improving response speed for future identical requests.

In GraphQL, the query writer is responsible for using a unique identifier to generate useful cache data. That said, the consumer may be able to use single queries across multiple tables that would require more than one REST API call to access.

Relying on architecture over following best practices is probably the better way to make performance accessible, which is a point in favor of REST.

Consequence: rules and security

Another difference Viktor mentions is how developers implement secrurity rules. REST’s default to the expansion of endpoint-HTTP method combinations includes setting rules on this basis. In GraphQL, with it its single-endpoint, rules are instead set per field. This may require a steeper learning curve, but it also provides more flexibility for easily making some attributes of an entity more available than others.

Conclusion: rigid or demanding

One recurring theme of this comparison is that REST APIs are built to be rigid, and another is that GraphQL requires higher effort from the client. This is how I would decide between the tools. If writing something that I expect to be querying frequently myself in new ways, I’d want the query freedom offered by GraphQL. If I wanted a small and fixed feature set, REST seems like the spec to follow.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Often when writing a function, we want it to be generic enough that it can operate in different ways for different inputs. Different languages will provide different ways to do this. Object-oriented solutions might include interfaces and polymorphism. Procedural languages might suggest template specialization or function pointers.

I’m going to talk about how functional programming languages use first-class functions to solve this problem in a satisfying way without any pointer syntax. Here’s some F#:

let rec filter fn lst =
    match lst with
        | [] -> []
        | head::tail -> 
            if fn head then [head] @ filter fn tail
            else filter fn tail

We’re defining a function named filter here which takes a boolean function and a list. The filter function will pass each element of the list to the function and eventually return a list of the elements for which the boolean function returns true. Let’s look at the result of passing some simple arguments.

let numbers = [0; 1; 2; 3; 4; 5; 6; 7; 8; 9]

let isEven i = 
    i % 2 = 0

filter isEven numbers
[0; 2; 4; 6; 8]

Usually when we see functions in the argument lists of other functions, we expect them to be glorified values. But in this case, isEven is not returning some value that gets glued to a parameter of filter. When a language has first-class functions, it’s perfectly fine to have functions themselves be the inputs or outputs of other functions. Here, isEven is itself an argument, and it operates on the head of each sub-list as we recursively cut our list down to one with zero elements.

In functional programming languages, it’s harder to write programs that aren’t reusable. If we want our filter to cut out any numbers that aren’t part of the Fibonacci sequence, we just write another boolean function and pass it instead.

let rec isFibHelper n x y = 
    if n = x then true 
    else if (y < 0) || (x > n) then false
    else isFibHelper n y (x+y)

let isFib n =
    if n < 0 then false
    else isFibHelper n 0 1

filter isFib numbers
[0; 1; 2; 3; 5; 8]

filter isFib (filter isEven numbers)
[0; 2; 8]

Because filter operates on a list, to filter a list of some other type we can just steal some documentation code for another boolean function.

let strings = ["abc"; "DEF"; "gHi"; "jkl"]

open System

let allLower s =
    s |> String.forall Char.IsLower

filter allLower strings
["abc"; "jkl"]

Functional programming is all about composition and modularity. You start with tiny Lego pieces and need to attach them until you have a gigantic ninja castle. In its most dogmatic form, that means sacrificing creature comforts like loops and mutable data that we use to quickly slap together solutions that can never be reused.

If you learned to write procedures or call constructors, I recommend giving one of these languages a try. It even makes recursion fun, so what’s not to like?

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.