Atk writes code

Siphon

My university dissertation project was Siphon. It's a free open source browser extension (currently for Firefox only) that watches your internet activity and records how much data is sent to known tracking domains. It's meant as an educational tool to the less internet savvy to show them how much telemetry and analytics are being collected on them by big corporations like Facebook - but it does not actually block anything itself. This was mostly to differentiate Siphon so it wasn't a completely done-to-death concept for the university's sake, but is also useful because it means it's guaranteed to not break websites. The extension has a little pop-up that shows statistics about the current tab you're on, as well as leading onto the graphical statistics pages Siphon also provides

For more information, check out the repository on Codeberg

Java

I respect Java for it's dedication to the object oriented paradigm and really like how classes are their own files. I think it's a great programming language to learn as it's strict enough in its syntax (looking at you Python) to teach good habits, without being too niche. It's GUI tools are lacklustre at best and multithreading is tedious, but it's nice for being cross platform and very general purpose

Java was the primary programming language taught over my university course. It was the first true object orientated programming language I picked up and is currently my most confident language. I used to privately teach Java in my spare time, using self-made materials

My biggest gripes with Java its idiomatic code style, and its giant 'ball' of mutable state (both problems Rust addresses fantastically, of course)

Java's idiomatic code style is what I call "object orientation to a fault", and the problem I find with it is that it makes unfamiliar code incredibly hard to sight read. If you want to follow a higher level process/'story' of a function or system, you have to dive through file after file, context switching continually. It's hard to keep track of and hold in your head, especially when documentation is sparse (and let's be real, it usually is). Plus, some code is relatively 'undiagnosable' without the use of the debugger. You might not know what the concrete type is at runtime, and thus you can't look at the implementation of a method if it's an abstract (or maybe overidden) method. Fortunately Java is mature enough that the debugging tools are robust and useful, but you shouldn't have to run code to be able to understand it, that's a security risk (or a collosal inconvenience if you trace it fully by hand)

The way Java almost never prevents mutability (preventing reassignment is not the same thing) makes it so difficult to rely in invariants in code you're contributing to a wider code base. For instance, there's no concept of a pure function in Java. There is no proper way to prevent a function from accessing or modifying state that isn't explicitly passed in. And you know what, maybe that would be okay, if there was any way of knowing what side effect(s) a function might produce without having to read and understand the entire thing. This results in code bloat as you constantly have to re-assert or check assumptions you're making because it's incredibly difficult to reason about the circumstances code other than yours might create. Encapsulation was supposed to be a solution to this, but once you move away from primitive types, you very quickly realise that a getter can often be abused to set if you really want to too, so are you really protected after all? Protecting assignment (through final or encapsulation) is pointless if you can't enforce immutability. listWrapper.getList().clear(); listWrapper.getList().addAll(newList); circumvents listWrapper being final and not having a setter, but you haven't protected the underlying elements at all

Don't get me started on NullPointerExceptions. Once you've tried a null-safe programming language, you'll never want to go back

Projects completed in Java (in no particular order):

• Hello, world!
• Implementing abstract data structures, including a circular array queue and circular array ring*
• A distributed election system that is tolerant to crash failures and Byzantine failures*
• Depth first, breadth first, iterative deepening, and A* search methods for finding a solution to a sliding puzzle* (implementing the puzzle was also part of the assignment)
  My solution also came with the built-in ability to generate puzzles and benchmark the various algorithms using them
• A multi-threaded restaurant simulation, emulating meal creation using ingredients and staff members, delivery drones*
  The GUI for the server was also part of the project
• TCP & UDP socket communication for various purposes (logging/communication in the election system, and placing orders in the restaurant simulation)

Shell scripting

Shell scripting is kind of a force of habit to learn alongside Linux when you're a programmer, unless you think Python is the best thing since sliced bread. In any case, I've picked up a fair amount of shell scripting, and I have to say I'm not a fan, regardless as to whether I'm targetting bash, zsh, or any POSIX-compliant shell. The syntax is fiddly and too whitespace dependent (conditionals), and 'normal' programming language features (like adding two numbers) feel like they were added as an after thought as opposed to from the ground up. Don't get me wrong, I love the Unix philosophy of "do one thing and do it well" coupled with the idea of working with data streams, but any time a script spills out over a line there's something I'll have to write that'll make me grumble about poor design. I use shell scripts because they're native to their platform and the fastest interpreted language you'll get in Linux (at least as far as I'm aware), but I'm never going to make a whole distribution just using shell

There isn't really such a thing as a 'project' in shell script for me, but the little helpers I write and bind to keys can be found in the ~/.local/scripts directory of my system, and they certainly are handy

I'm the lead maintainer of wd, a zsh directory changer that lets you set custom nicknames for long paths