Maybe dynamically insert some funny quote here?—Simon Kadesh, October 2026
Hello!
My name is Simon. I am a software engineer, computer scientist, mathematician, and language enthusiast.
Contact Me:
If you'd like to contact me, please send me an email at simon@kade.sh
Education:
I am currently an undergraduate student at the Rochester Institute of Technology (RIT). My majors are computer science, computational mathematics, and the Japanese language.
In the process of completing my major in Japanese, I also had the opportunity to spend a semester studying at Sophia University in Tokyo.
My Projects:
Netbooting
In the winter of 2024, I had recently moved in to the house, and I was frequently reinstalling several computers while I was settling on how to configure my home network. In this process, I obviously saw the BIOS / UEFI boot prompts, like
Press enter to interrupt normal boot sequence
or, more relevantly,
PXE: No boot filename received
Seeing these prompts, as well as mentions of PXE netbooting within distro installation documentation, got me wondering: "I see this so often as a way to load an installer image, but can I make a real system run off of this?"
As I discovered and presented, it turns out you can.
A CPU Path Tracer in OCaml
I'm currently working on writing a CPU path tracer in OCaml. For the reasons stated above, I rather like both OCaml and path tracing, but I have found that there are some minor inconveniences when implementing the latter in the former. In particular, OCaml lacks both value promotion / demotion and operator overloading, which, while not dealbreakers, are major conveniences when one is doing a lot of numerical programming and linear algebra.
An output from my path tracer in its current state. Visible are such features as texture mapping, accurate reflections, and shadows.
My next target features for this project are transparency (once I decide on a satisfying way to integrate it into my current code structure), direct lighting / next event estimation, and something fancy like bidirectional path tracing or volumetric rendering
Source code here (Under Construction)
A Parser-Combinator Library in Scala
I had initially dismissed Scala as a programming language, since it's a functional language on the JVM. Having now learned Scala through this project, I realize I was missing out. Aside from just being "yet another ML (but this time on the JVM)," it has a number of modern and convenient features: a contextual abstraction system that spans the gap between Haskell's typeclasses and OCaml's modules incredibly well, refinement types, explicit co/contra-variance, and syntax sugar for monadic operations (unfortunately duck-typed)
Now that I'm done praising Scala, I should probably explain the actual project I did. I implemented a simple monadic combinator-based parser library in Scala. In simpler terms, what I built is a library that allows the user to build larger and more complicated parsers by connecting pieces from a collection of simple ones. It's kind of a contrived project, but it is also an incredibly useful one for getting a feel of a new language's type system and how building higher level abstractions feels in that language. Scala took some getting used to, but I'd seriously consider it for any new projects I was working on.
Source code here (Under Construction)
Professional Interests:
Functional programming languages
As of late, I have been doing a lot of programming in languages like OCaml, Scala, and Haskell. I find them enjoyable because they are simultaneously expressive enough to encode the actual program I intend to write, while also being concise and clear enough that one screen of code can comfortably fit a sensible implementation of many algorithms
I'm also interested in the design of functional languages. During my time at RIT I've had the good fortune to be able to take several PL courses with Dr. Arthur Nunes, as well as Compiler Construction, with Dr. Matthew Fluett, and Programming Language Theory, with Dr. Arthur Azevedo de Amorim. Between implementing a compiler with features like optimization and type inference, and learning how to reason about the behavior of programming languages, and prove properties like progress (that a well-formed program never "gets stuck" with something that it can't evaluate) and determinacy (a looser property similar to determinism—that although a program might have multiple possible execution paths, eventually they reach the same result state) even in the presence of increasingly complex language features, I've really taken the opportunity to throw myself into the deep end of programming language design (though I think I've come out stronger for it. Understanding how programs are structured and what the compiler's actually doing comes in handy sometimes)
Object oriented programming languages
I actually started programming in Java when I was twelve years old, in order to make Minecraft mods and video games. I think that as a language it has received an undeservedly bad reputation for its flaws, and not nearly enough credit for being a reasonably fast, mostly portable language with a wide array of features, comprehensible semantics, and a big ecosystem of libraries and tools.
(If only it had value classes)
Natural languages
My interest in natural languages probably began from a linguistics perspective, rather than from one of language-learning. In particular, I became aware of linguistics as a field when I learned about constructed languages. From there, it's a natural progression to want to learn languages with interesting properties.
I began my Japanese major at RIT when I was trying to fulfill my general education requirements. As I was surveying the catalog of valid immersions, I noticed that Japanese was an option, and decided that taking Japanese would both give me the opportunity to return to learning about languages, and give me an excuse to add some liberal arts courses back into to my schedule (which had otherwise been full of only CS and math).
Databases
I'm going to be honest. I don't have any special formal experience with databases, nor do I have much interesting commentary about them. I just think they're cool tech. (Obviously, I've written programs that use them, though)
Operating systems
If studying programming languages can be said to give you a good "top-down" understanding of what a program is doing and how it works, studying operating systems should be thought of as giving the same understanding "bottom-up." In general, I think having the understanding is valuable for its own sake, but being able to reason about what the computer's doing at any given point is also a foundational skill for software engineers. It saddens me that the practice has fallen so far out of favor that some universities (including RIT) have made OS optional
My largest formal experience working in this space has been during my operating systems class and my introductary compute architecture class, although I have built several throwaway toy programs that run at a similar level (a hex monitor in x86 machine language, a simple boot sector, etc.). On one hand, I really appreciate programming at such a low level, since the semantics for the C and x86 abstract machines are simple enough to be (relatively) reliably memorized, and they're both incredibly powerful languages. On the other hand, they can be incredibly frustrating, because features like generics, error reporting, and memory safety (by which I mean garbage collection) make implementing algorithms or data structures of any real complexity so much more pleasant.
Computer graphics (physically-based path tracing in particular)
Monte carlo path tracing (or the more general class of MCMC algorithms, which I haven't quite fully grasped yet) is one of my favorite algorithms. Looking at it out of context, it almost seems silly to say "let's integrate this function by guessing a bunch and evaluating the results," yet it is legitimately the best way to solve a significant class of problems. At the same time, once you include features like early ray termination, multiple importance sampling (with direct lighting, next event estimation, etc.), and volumetric rendering, the algorithm contains a surprising depth of mathematical rigour. It also produces a highly visual, often aesthetically pleasing result.
(although mine doesn't produce such results quite yet)
Theoretical machine learning
I have often said that I believe machine learning is the least interesting solution to any given problem. How can it then be the case that machine learning has ended up in my list of professional interests? I think of it like this: I like graphics (which can be thought of as the practice of simulating light and its effects); however, once you decide that the "solution" to computer graphics is (for example) neural rendering, you aren't really doing computer graphics per se—you're doing applied machine learning.
That being said, outside of the context of stripping away detail from some other field, the question of "can a general optimization algorithm find effective ways to do things like identify objects, generate human-like text, or predict what will happen next given an image and an action" is, in and of itself, a fascinating thing to study.
Systems administration
I consider myself something of a systems administration hobbyist. When I had the opportunity to live with like-minded college friends, we set up our house Wi-Fi with RADIUS authentication to each of our individual LDAP servers, as well as a SIP intercom system so that we could call the other rooms in the house. More routers lived in that house than people.
I was a regular participant in my university's Linux Users' Group (RITLUG), and have since sought out a local LUG whenever I have found myself in a new city. See a presentation of mine at the Tokyo Linux Users' Group in the projects section above
