Jan 7, 2018 miscellaneous

In almost everything I try to do, there's one big problem that I always deal with. That problem is motivation. Now, don't get me wrong; I have no shortage of ideas that I want to try, no lack of motivation to start things over and over and over again. No, there's a bigger problem... I can't maintain the motivation to actually finish anything.

This seems to be a common problem, especially among freelance or hobbyist programmers, though I see the same problem in almost everyone. It's just part of human nature - we think of a cool idea, go to try it, find out it's more work than it seemed like it would be, and just slowly taper off into nothing. My projects folder on my laptop is full of things that I started, that I love the idea of, but that I couldn't work up the motivation to get through the long, hard slog and eventually abandoned - and that's after only a few months! I don't even want to try to count the ones on my desktop. I legitimately can't count the number of projects I've started, tried, gotten bored of, and come back to months later only to realize I have no idea what anything I wrote meant.

There is no perfect solution that I've found. I don't have much advice on this subject. All I have is a simple mantra - try, try again. I personally get far more frustrated with slow progress and demotivation than is probably healthy. But the only thing I can do it dust myself off, pick a new project, and try again. If you have any better ideas, I'd love to hear them. If my short rambling on the subject was helpful, I'd love to hear that too.

Stay motivated, friends.

Rigidity is not the same as power

Dec 6, 2017 programming, languages

The debate in question is this: How powerful is your programming language?

Programmers love talking about this. And talking, and talking, and talking... To be honest, it gets annoying after a while. People have an almost religious connection to their favorite programming languages, and after a few times you get really, really tired of reading people screaming at each other on Reddit about whether Javascript or Python is better, whether Kotlin or Scala is better, whether Lisp is still relevant, whether F# or Haskell is better, better better better better better. It gets old. No, more than that, it's gotten old. It's been old since long before I got involved, and it's still old now. It's legitimately tiring, and it does. Not. Stop.

Please... Just stop...

I'm not here to preach one language over another. That's not how I work. I have no religious attachment to the languages I use - I prefer the languages I prefer for the reasons I prefer them, and that's that. It doesn't matter what other people think, unless they show me something that utterly changes my mind (something that hasn't happened very often, I might add).

What I am here to do is try to bring a little sanity to the discussion. To calm down the warring religions of ML style vs. Lisp style vs. OOP vs. FP vs. vs. vs. and so on with a little calm, well-reasoned, logical discussion. So that's what I'm going to do, starting with debunking a simple misconception (or trying to, at least).

Far too often, the debate about "How powerful is your programming language?" becomes a debate about "How rigid is your programming language?". This is a misconception that personally bugs me every time I see it, for one simple reason.

Rigidity is not the same as power, nor is it the opposite.

Advocates of compiled, statically-typed, highly-structured and opinionated languages like Java, Kotlin, F#, and Haskell will try to tell you that their rigidity is what makes them powerful, by preventing you from making mistakes you would otherwise make. Advocates of interpreted, dynamically-typed, unopinionated languages like Javascript, Python, Ruby, and Lisp (yes, Lisp) will try to tell you that their lack of rigidity is what makes them powerful, by getting out of your way and letting you really make the most of your code.

I'm here to tell you that they're both wrong, and that they're both right.

Stop, you're both wrong.

Rigidity is a useful tool. Restraint forces you to be more clever, finding ways to work within the constraints you're given. It also helps rule out some problems and bugs by making it harder to make mistakes. On the other hand, being less rigid allows for faster, more intuitive development, effective meta-programming, and a lot of simple solutions to difficult problems that simply can't be done easily in a more rigid language. Just as flexibility can be taken too far, so can rigidity, and both are good in moderation and bad in excess.

Far too often, people see rigidity as either entirely good or bad. They see a spectrum of programming languages, from most rigid to most flexible, and they pick a side that they see as "good" and decide that therefore the other side must be "bad". They come up with (legitimate) reasons for what they see as good and bad about them, ignoring the (also entirely legitimate) reasons to think the opposite, and they go off to war.

In reality, this just isn't true. The more I think about the languages I've used, the more I see the same spectrum, with one key difference. I haven't labeled one side as "good" and the other as "bad". I've simply labeled them as what they are, more rigid or more flexible.

Rigidity is good. Flexibility is good. Which you should choose depends entirely on what you're trying to do.

Do you want the ability to bend your programming language to nearly any imaginable style of programming and any possible purpose? You should pick a flexible language like Javascript or Ruby, that gets out of your way and lets you cross the streams as much as you want, with the full knowledge and acceptance that yes, you might get burned.

Sometimes, you have to cross the streams.

Do you want your programming language to find your bugs for you, ripping out entire categories of problems in one fell swoop? You should choose a more rigid language such as Kotlin or F#, that holds you to strict, mathematically sound design principles and prevents you from making silly mistakes like not checking for null.

Funny internet images aside, both of these are beautiful choices with their own ups and downs. Rigid languages like Java, Scala, C++, and so on often have trouble dealing with the possibility that something could be multiple types of things. Their rigidity is their greatest strength, but also their greatest downfall (and one of the reasons for "Nobody uses Haskell" being a flat out meme).

One does not simply use Haskell.

On the other hand, flexible languages have the same problem! Their flexibility is both their strength and their downfall - they let you do amazing things with the ease of no restrictions, but they're a double-edged blade that will bite you if you're not careful to reign in their flexibility to controllable levels. This is the reason that Javascript is considered such a mess - it's flexibility goes almost too far, to the point of being barely-comprehensible quirkiness (you might check out wtfjs if you're not sure what I'm talking about).

WTF, Javascript...

I know my half-coherent rambling isn't going to stop the language wars raging across the internet. Hopefully, though, it'll do some good to the people who read it. I guess all I'm trying to say is that programming languages are tools designed to fulfill a purpose. There's no point getting dogmatic about which is better, especially on a non-issue like rigidity. There's two sides to every coin - it's time we stopped acting like our grass is the greenest and realized that everyone has different needs, preferences, desires, and so on. Everyone has their own list of things they need from their programming language - there is no silver bullet.

It's time we stopped the crusading. Time to wake up and smell the coffee, and realize that it doesn't matter whether you prefer Javascript or Java, Ruby or Crystal, Python or Kotlin, functional or object-oriented, compiled or interpreted, rigid or flexible. At the end of the day, we're all developers - let's stop tearing each other apart over our differences and start building each other up in our similarities.

Kotlin v. Scala: The JVM Showdown

Nov 16, 2017 programming, languages, jvm

So there's a new language craze going around the internet, a new JVM alternative by the makers of the popular Intellij IDEA, which goes by the name of Kotlin. Now, I'm not particularly a fan of Intellij - I'm an experienced Scala user, and I much prefer Eclipse or even VSCode over IDEA. Up until now, I'd passed over Kotlin as just another Scala knockoff, not worth the time to look into deeper. But with so much attention being put on Kotlin, I finally decided to take a look and see what all the rage is about.

Keep in mind that this isn't a definitive guide to the differences between Kotlin and Scala - these are my personal observations and opinions on the two, and what makes Kotlin worth (or not worth) the switch. I will also be focusing primarily on the differences between the two - I won't be covering the numerous great things that both do over Java, or their (in my opinion) failings in comparison to Java.

The Good Parts

One of the first things I noticed about Kotlin was that it definitely does some things right. There are some features in Kotlin that are just a royal pain to do in Scala, but come so naturally to Kotlin that it honestly astounded me. Let's start with the good stuff, shall we?

Null Safety

This is by far my favorite thing about Kotlin over Scala - Kotlin has astounding null safety. Scala relies primarily on an Option[T] type to deal with null safety. This has it's own advantages and disadvantages, but it often leads to a lot of code like this:

def parse(from:String):Stream[Token] = from.headOption {
  case None => Stream.empty
  case Some(c) => c match {
      // ...

There's nothing wrong with it, persay - but it is quite verbose. Kotlin, on the other hand, bakes null safety directly into the type system. Take, for example, the String type. In Scala, this value could be null, and you have to handle that. In Kotlin, however, this type quite literally cannot be null. In order to represent a nullable string, you would need the String? type. This forces you to think ahead of time about every possible way something could be null, and gives you an effective and simple way to deal with it.

Furthermore, Kotlin's compiler is extremely intelligent about this. In both Scala and Java, even if you know that a value isn't null, you still have to either handle it being null or unbox an Option[T] type. This leads to a lot of boilerplate code, wrapping and unwrapping types to handle the off chance that a value might be null. Kotlin, on the other hand, knows when you've checked that something isn't null. As soon as you hit code where you've already checked that a variable isn't null, the compiler automatically typecasts it to a non-nullable type, and you no longer have to deal with the possibility of null. That ends up looking something like this:

fun getName(person:Person?):String? {
  // return    // (Compile error: cannot access property of nullable)
  if(person == null) return null

Kotlin even provides some utilities to make this less boilerplatey, in the form of the null safe access and Elvis operators.

// Elvis operator
fun getName(person:Person?):String? {
  person ?: return null

// Null safe access
fun getName(person:Person?):String? = person?.name

All of this makes handling nullable values in Kotlin an absolute breeze compared to the boilerplate of Scala's Option[T], let alone Java's incessant null checks.

Easy Typecasting

Continuing on from the above, Kotlin's hyper-intelligent type checker doesn't just extend to null safety. Any time you do a type check, from then on in that scope that type check is remembered and reused. For example:

// Assuming Geek is a subclass of Person
fun getName(person:Person):String {
  if(person is Geek) return + " (Geek level:" + person.geek_level.toString() + ")"
  // println(person.geek_level)    // (Compile error: geek_level is not a property of Person)

In fact, a ClassCastException is almost impossible to achieve thanks to Kotlin's "smart casting". Nicely done, Intellij!

Inextensibility by Default

Kotlin and Scala both encourage the use of immutable variables ("values") wherever possible. This makes it easier to reason about the program you're working with by making sure you know what a value will be, for sure without question.

What Kotlin gives beyond Scala, however, is inextensibility by default. This is something that I wasn't so sure about when I first tried Kotlin, but I quickly realized just how good it is. Essentially, Kotlin prevents you from extending classes, overriding methods, etc., unless they're specifically designated as either open, abstract, or something that's implicitly abstract like a trait.

This seems at first to go against the grain of a statically typed, object-oriented language; not being able to extend a class? What even? But after a few minutes of working with it, it becomes abundantly clear why.

The big advantage of being inextensible by default is complete and total control over who and what can access your code. In Scala, you have to annotate everything that outside code shouldn't be able to touch with private, making it easy to forget to hide something that shouldn't be available, such as internal implementation details. Kotlin, on the other hand, forces you to think about what should be available, rather than what shouldn't. It ensures that you make good, intentional decisions about what outside code can see, rather than accidentally exposing something you shouldn't have.

Extension Functions

On the other end of the spectrum, Kotlin allows for something called "extension functions". This is essentially Kotlin's equivalent of Ruby's monkey-patching, and used well can make your program a lot more efficient and concise. This is something that Scala doesn't really have as such - the closest you can get is an implicit conversion to a wrapper class that provides the new method.

Java-like Syntax

One thing I noticed about Kotlin that Scala lacks in a lot of cases is a willingness to reuse Java's syntax. For example, Kotlin isn't afraid to have code laying around like this:

sealed open data class Polar(val radius:Int, val angle:Int) : Point

Whereas Scala relies a lot more on a tight, operator-based syntax:

case class Polar(val radius:Int, val angle:Int) < Point

Perhaps it's just me, but both have their advantages - I like the conciseness of Scala, but the readability of Kotlin is pretty nice too.

Extendable Case Data Classes

One of my biggest gripes with Scala is that case classes can't be extended, period. Kotlin's data classes, which are the rough equivalent, can be, albeit with some slight restrictions. Simple as that. In fact, the primary difference between the two examples in the last section is that the Kotlin class can be extended by classes in the same file, while the Scala one cannot.

Conversion from Java

I haven't experienced this personally, but apparently switching from Java to Kotlin is an absolute breeze, especially for users of Intellij IDEA. Having experienced the switch from Java to Scala before, this is definitely a plus for Kotlin.

The Bad Parts

Kotlin is far from perfect though. It has it's own quirks and flaws, just like any language. There are a lot of features of Scala that I missed bitterly in Kotlin during my short stay, just like there are a lot of features of Kotlin that I really wish Scala would borrow.

No Implicit Conversions

This was really the big dealbreaker for me. One of the beautiful things about Scala is the ability to define implicit conversions that will automatically convert one type to another using a predefined method. While this can cause issues if abused, it makes DSL syntax beautifully easy and sweeps a lot of annoying, boilerplatey unboxing under the rug.

Kotlin forgoes the power and expressiveness of implicit conversions entirely, however. While their reason is valid (implicit conversions, if abused, can confuse and complicate things greatly), the language loses out on a lot of power that could be gained.

The closest thing Kotlin provides is extension functions, which cover a lot of the basic use cases - however, they come with their own drawbacks. It's nearly impossible to call the original method from within an overriding extension function, let alone outside of it. You can also only extend a class with methods, rather than with anything you want via implicit conversion to a wrapper class.

For more complicated uses, such as a JSON DSL for example, you essentially have to run through a pre-processor stage. For example, in order to learn Kotlin I replicated as closely as possible the AST of my Scala JSON library, ScJson, in Kotlin, and ended up with this code:

fun obj(vararg pairs:Pair<String, Any?>) = JsonObject( {(k,v) -> Pair(k, json(v))}.toMap())
fun arr(vararg elems:Any?) = JsonArray(

fun json(v:Any?):JsonValue<*>? = when(v) {
  is JsonValue<*> -> v
  is String -> JsonString(v)
  is Int -> JsonInt(v)
  is Float -> JsonFloat(v)
  is Boolean -> JsonBoolean(v)
  null -> null
  else -> throw IllegalArgumentException()

While there is a certain beauty to this, in that the logic is consolidated into a couple localized areas, it was quite annoying to realize that I had to loop through and convert every value to a subtype of JsonValue manually, rather than just defining a half-dozen implicit conversions and having done with it.

No View Bounds

This one is pretty self explanatory - without implicit conversions, there isn't any need for view bounds. On the other hand, view bounds are one of the Scala features I find myself using almost constantly, and it's really quite a pain not to have them.

Subclasses of Sealed Classes Must Be Nested

This was just a slight annoyance, really, but when I went to define subclasses of a sealed class, Kotlin decided to yell at me that the subclasses had to be nested inside the parent. This led to a handful of redundant-feeling type aliases defined at the top of my file and a few extra levels of indentation that I wish I could have avoided. Apparently this is fixed in a newer version, but despite being on what I assume was the latest version, the compiler still complained. Go figure.

Inheritance Boilerplate

This is the flipside of being inextensible by default - there's a lot of boilerplate associated with actually making things extensible. Kotlin code quickly becomes polluted with an inordinate amount of opens and overrides. Not a big deal, just somewhat annoying over time.

No Operator Definitions

Another small gripe, but one that hamstrings DSLs in general - Kotlin doesn't allow you to define operators. You can override a small set of predefined operators (plus, minus, get, etc.), but you cannot define your own, and the set of operators that can be overriden is very small. The closest you get is the concept of infix functions, which allows you to define a function that can be used in infix position, like jwick arr "contacts" obj 0 v "name", for example. This isn't really a substitute for Scala's ability to define arbitrary operators, though - I much prefer a syntax like jwick | "contacts" | 0 $ "name" (and there's those view bounds coming into play again - I had to use two different functions in Kotlin, where one Scala operator did just fine).

... Java-like Syntax

This is a perfect example of something that can be great in some ways but annoying in others. Let's take a look at those two examples again:

sealed open data class Polar(val radius:Int, val angle:Int) : Point
case class Polar(val radius:Int, val angle:Int) < Point

... On second thought, I definitely prefer the conciseness.


So, is Kotlin the silver bullet the JVM has been waiting for, or does in pale in comparison to my beloved Scala? Well, the answer is....


I know, I know, it seems like a wishy-washy, cop-out answer. But to be honest, it's the answer the programming community needs to hear, in my opinion. Scala certainly isn't perfect, and Kotlin certainly does a lot of things right. But neither is Kotlin this amazing silver bullet of a language. It has it's advantages and it's disadvantages, just like any other language.

Don't get me wrong, I'm not saying Kotlin is bad by any stretch. I'm just saying that maybe we shouldn't hail it as the savior the JVM has been waiting for. It's just another language, with it's own highs and lows. Enough language worshipping - find what works for you and use it.

With that said, I think I'll be sticking with Scala. I won't be afraid to employ Kotlin if I need to, and I certainly won't be considering it "just a Scala knockoff" anymore, but it just doesn't do it for me, unfortunately. If you think differently, more power to you - just so long as you don't try to indoctrinate me, we'll be fine =)

Subterra: A Mistake Gone Right

Oct 24, 2017 programming, language design

About a year ago, I created a programming language. This wasn't the first time I'd done so; I'd churned out several Turing tarpits, none of which were likely anywhere near actually earning the Turing part of that name, and none of which had gotten much of any attention at all, even if I did release them. By this point, I was quite experienced at hacking together a bit of Python code to interpret a seemingly arbitrary sequence of symbols as simple operations on a single data stack. For the time being, that had satisfied me, but I was starting to grow a bit restless. I wanted to make something useful - not necessarily that would be used, but something that could be used if anyone happened to be insane enough to try.

This is the story, as best I remember it (and probably with a little poetic license), of how I created Subterra; the mistakes I made, the troubles I went through, and the lessons I learned.

The Goal

I set out creating Subterra with a simple goal in mind:

Subterra is an esoteric programming language designed to be simple yet powerful. Every instruction in Subterra consists of only one character, it uses a single stack for data storage, and the only datatype it handles is integers (a typical "tarpit language").

~ from the Subterra wiki

If that's somewhat cryptic to people not really involved in the esoteric programming language community, my apologies - essentially, it boils down to three goals:

The first two goals are simple enough; these are things I'd done with nearly every programming language I'd created before. The third, however, is a bit trickier - how do you define how powerful a programming language is?

In the case of Subterra, this essentially ended up meaning that it had a few features not usually found in tarpit languages:

This all seemed simple enough to accomplish on the outside, but in reality, it was anything but.

The Problems

For the sake of conciseness, I will skip over the issues raised by the latter three features above. For the most part, they were relatively simple to implement, and the worst I had to deal with in the process was tedium, not extreme challenge. Importing simply built on the existing subroutine structure, the source language imports were simply a matter of some slight tweaks to that logic and to the in-memory representation of subroutines, and error logging, while tedious to add, was far from complicated.

With that said, the other two problems provided much more difficulty. Let's start from the top...

Functions Subroutines

Subterra's implementation of functions is... interesting to say the least. Since all data is manipulated by the stack, there is no concept of "parameters" like functions in most programming languages; perhaps this is why I settled on the name of "subroutines" instead.

There are three types of subroutines in Subterra, which can be told apart by the type of brackets that enclose them:

Subroutines also had a sort of implicit return built in - excepting the {} type, at the end of their execution they would pop the top value from their own stack, if it existed, and push it to the calling context's stack.

When defining a subroutine, it would pop an integer from the stack to use as it's ID. This ID could be used to refer to and call the subroutine. Certain constructs, such as while (w) and if (?), were also implemented in terms of subroutines; they could be passed a subroutine body itself, or the ID of an already-defined subroutine.

This all sounds fairly simple in retrospect, but at the time, it caused me no end of trouble to implement. Stack overflow errors, recursion-related bugs, and more plagued me for days. Still to this day, I would say that the single biggest source of bugs in Subterra is this crazy, backwards way of implementing functions.

Lessons Learned


Strings, while not quite so large a problem as functions, were still quite the troublemaker. Trying to represent text in a language that only knew how to deal with integers was a perilous journey for a 16 year-old kid who had yet to fully grasp how binary worked for anything but math. There were two pieces to deal with: the representation of strings in the source code, and the representation of strings in memory.

The representation in the source code was the easier of the two. I used the typical style of enclosing the text in either single (') or double (") quotes. On the parsing end, I made a special exception in how the parser worked; on encountering a quote character, it would defer to a specialized parser that built the string, handled escape codes, and returned control to the main parser when the matching quote was found. On the whole, it was far less imposing a task than I'd expected.

The representation in memory was somewhat more difficult. There wasn't any way to build in awareness of what was and wasn't a string on the stack without changing the core ideals of the language. This left the task of keeping track of the difference between string and number to the programmer, which made my job somewhat easier. I eventually settled on pushing the string, character code by character code, onto the stack from the end to the beginning, followed by a length value. This gave an easy way to find the end of the string, without resorting to strange hacks or workarounds.

In the end, the trouble I had with strings was less an actual problem and more a problem with my own thinking. The solution was right in front of me, without even changing the limitations that I set for myself. I was simply too caught up in my own mindset to see it.

Lessons Learned

The Aftermath

A year later, I haven't really touched Subterra much. My last commit to the Github repo was on September 1st, 2016, only about 2 weeks after the initial commit. While it was a short-lived project, it's one that I remember fondly; not because it got me attention, or because I created something honestly useful, because it didn't and I didn't. What Subterra did do for me was teach me some important lessons, both about programming, programming languages, and about myself.

I don't recommend trying to make your own programming language for everyone. Until you get the hang of it, it can be quite a grueling process; it takes time and effort that a lot of people just aren't willing to spend. If you do decide to try making your own programming language, though, don't let setbacks like the ones I had with Subterra get you down - learn from them, move through them, and never be afraid to ask for help. Who knows, maybe your creation will be the next Java... or maybe it will be your Subterra. Either way, I wish you the best of luck.

The Beauty of Modulus

Oct 22, 2017 programming, game design

Modulus really is a beautiful little operator. So overlooked, but so useful, that it's managed to find quite a special place in my heart. At it's heart, it's a simple concept - the modulus of two numbers is the remainder of integer division between them. That is, if you have 10 % 3, you divide 10 by 3 to get 3 with a remainder of 1 - that 1 is the result of the modulus operation.

Modulus is represented in most programming languages by either % or mod - for the sake of this article, I'll be using the simpler and more common % form. I'll be using Ruby code to write my examples, but this applies to any programming language at all.

Let's take a look at some of the beautiful tricks you can do with modulus, shall we?

Checking Divisibility

This is actually probably the best known use for modulus - it can be used to easily check if one number is divisible by another.

if n % 2 == 0
  puts "n is even"
  puts "n is odd"

This is, for the most part, self explanatory - the remainder of dividing two numbers will only be 0 if the first number is divisible by the second. Simple!

Looping Numbers

One of the beautiful properties of modulus is that if you make a loop that increments a number and then sets it to itself modulus a maximum, the number will loop between 0 and the maximum. This is a bit clunky to think about in words, so let's write some code:

n = 0
while true
  n += 1
  n = n % 5
  puts n

This will output the following:


As you can see, the number now loops between 0 and 4. This is because every time n hits 5, n % 5 becomes 0. On the other hand, any time n is between 0 and 4, n % 5 is n, since n isn't divisible by 5.

This becomes very useful for things like game logic (think Snake's looping coordinate system, where going offscreen will lead you out from the other side) and dealing with things like angles (deg = deg % 360 means you never have to worry about treating numbers above 360 as the corresponding degree less than 360) or time (minutes % 60 anyone?).

Base Conversion

This is one of the more niche uses for modulus, but it's still quite useful to know - modulus can be used to convert numbers from one numerical base to another. For example, let's write a function that converts decimal (base 10) integers to trinary (base 3):

def b10tob3(n)
  out = ""
  while n >= 3
    out = (n % 3).to_s + out
    n = n / 3
  out = n.to_s + out if n > 0
  return out

Running a number through this function will return a string containing the same number in base 3 (feel free to boot up an irb session and double check for yourself). But how does it work?

If you strip out the boilerplate, it essentially comes down to three simple operations, repeated until the number is completed:

This makes the process remarkably simple, and quite easy to understand as well. It can even be adapted to start from other bases than 10 with a little clever math.

(Thanks to ncmathsadist on StackExchange for the really great explanation on this one)


I hope I've been able to show you a little bit of the magic that is the modulus operator. It's an extremely useful tool for various mathematical and logical operations, and has myriad uses in simplifying and condensing programming logic. Here's to the remainder (ba dum tss) of your programming careers =)