| |

Social Privilege and Online Trolls

I try and alienate myself from everyone, ever.
by Sunny Kalsi on Aug. 24, 2014, 9:41 p.m.

I’ve generally stayed away from this topic, not only because it is fraught, but also because it leaves me “on my own” as it were. No “sides” of the argument agree with me, and my opinion antagonises both of them, probably needlessly. Further, the opinion doesn’t have the memetic quality that people could latch onto. It’s hard to pick up, hard to agree with, and in the end not even really that important.

This is a dramatisation, but the reality is not far: On day one, two minor radio celebrities play a “prank” on an unsuspecting member of the public, or interview someone with a terrible secret, or carelessly lambast someone with a mental health issue. Day two, they apologise profusely and talk about how no one could have foreseen the consequences. Day three, they complain about internet trolls and how they are victimising everyone (including the hosts!), and these terrible people need to be taught a lesson.

Alternatively, an internet celebrity gets criticised, perhaps legitimately, starts blocking and reporting them for “abuse”, “trolling”, or “internet bullying”. Then posts public or private data of those doing the “abusing”, telling their readers to have at it.

The pattern is the same: use celebrity to avoid or deflect scrutiny, use celebrity to stir up outrage at your detractors, then paint yourself as a victim, somehow. I’m seeing it more and more often, a kind of brute-forcing of celebrity power. What makes it worse is that often these are people whose views I share or whom I otherwise respect.

Now, people calling out trolling on the internet by itself is not a bad thing. It’s the combined pattern of behaviour, where “abusive” is a code word for “disagrees with me”, and where the supposed abuse sits comfortably alongside tacit incitement against the “abusers”.

Long story short, I saw two people doing what I thought was exactly that, and I called them out on it. I was wrong. Basically, they were railing against abusive behaviour on the internet in general, and weren’t trying to take advantage of their status. Unfortunately, the attitude does empower those who are abusing their status on the internet.

It’s a difficult topic, because this sort of thing does affect internet “celebrities” more than most of us. Having a large community around them, getting their attention means getting the attention of everyone who listens to them. For an internet bully or troll, they are a high value target. For most of us, though, a troll or an internet bully isn’t unheard of, though they tend to be someone we know personally.

I guess what I’m saying is, this is mostly a problem for celebrities, and a problem that is directly offset by the power they wield through others on social media. Insofar as it applies to normal people, the scale of the issue has been far overblown because of the effect it has on the powerful.

This usually results in knee-jerk reactions from politicians, who start yammering on about “real name policies” on the internet, which really amounts to a total internet surveillance. While this sort of thing hurts internet users in general, it tends to greatly aid in shutting down dissent from the powerful, and that includes internet celebrities, even minor ones.

Having said that, I was reactionary. And I probably didn’t say what I wanted to say the way I wanted to say it. What I wanted to say was more like the above. It probably doesn’t occur to most people when they do things that benefit them but hurt others. In the same way as how white privilege is invisible, so is social privilege. This is not the sort of thing we want to entrench in our social mores.

Waving the flag

On what it means to be a pirate
by Sunny Kalsi on July 27, 2014, 1:46 p.m.

I care not for your laws, for I am a giant.

I’ve been having this feeling that we’ve been doing Pirate – The Movement™ wrong in Australia. I’ve never been able to put my finger on it, either, which is frustrating because you can feel pirateyness more than you can define it. There’s been a long discussion on The Why of Pirate Party Australia which is an attempt to distill what it means to be a pirate. I wrote my thoughts at the time:

A Youtube clip linked in IRC talking about the PPAU described us as “humanists”, and that rung especially true to me: Pirates have faith in people

It still rings true, but the problem is this: Lots of people have faith in people, but most of them are not Pirates. I failed to reason about this correctly even though I literally linked Amelia Andersdotter’s insightful post at the beginning of the post. Hers is an important post in the discussion for what it means to be a Pirate, I think.

I keep having this sense that the Pirate Party is clouding my thoughts about the Pirate movement, which has existed long before the political party, even if not in those terms. Back in the demoscene, if someone started making video games, they were called “sellouts”. I wonder if The Future Crew, makers of FutureMark, started making benchmarking software instead of video games because they didn’t want to be considered “sellouts”. It might sound like a random thought but it’s a salient one for chasing our identity.

I keep having this thought: We are defined by our weapons. Most people might not realise this but the act of being a Pirate is an act of intellectual crunk and bombast. Whether it is cracking into software, making intros or demos, or even breaking into online systems, it’s meant to assert dominance. It’s meant to be intimidating. It says “I care not for your laws, for I am a giant.”

But it goes further than that. The fundamental act of Piracy is one of social engineering. It actually says: “We care not for your laws, for we are giants.” The Pirate Bay is a perfect example of this: It is technology that empowers all of us. It is one of the most trafficked websites on the internet, it is high performance, and it’s still running, despite years of trying to shut it down via various means.

And this is the second part of the meaning of dominance. It doesn’t just dominate in a technical sense, it dominates in a social sense. The Pirate Party is a product of that dominance. It says “we exist, we cannot be ignored, and everyone is on our side”.

A Pirate’s primary fuel is creativity and vast swathes of spare time. Pirate Party Australia has been quite creative, and has put in prodigous amounts of time considering. But we’re still acting a lot like a political party. Don’t get me wrong, we absolutely need to do this, and when it comes to actual policy, we’re a force to be reckoned with. Not only do we have a vast number of well researched policies, but we’ve also made a large number of submissions to various reviews on several policies. As far as it goes, we cannot be accused of not taking part in the process. However, that isn’t very “Piratey”.

When we talk about recruiting, we also talk in terms very much like a political party: Going into universities and recruiting students, setting up societies, and the general political fare. However, the people we neeed aren’t 20, they’re probably closer to 15. And we don’t want them politicking, we want them creating. More than that, we want them to create intellectual crunk and bombast. Because this is how we get to a stage where we are giants, and where we cannot be ignored.

So in the end, have I figured out the why of being a Pirate? I don’t think so. For all the catharsis I’m still lost. All the “advice” here is purely speculative. But I feel like I’m getting closer. The Party is a veneer. It speaks of the movement, but not for the movement. In Australia, it feels like we’ve mostly been taking advantage of the movement rather than contributing significantly in our own right. I think that if we focus on the latter, we’ll eventually see a much stronger Pirate movement in this country, and therefore a stronger Pirate Party. And maybe that new generation of Pirates contributing to the movement can finally answer that question: What does it mean to be a pirate?

On Javascript

A while back I decided to dive headfirst into Javascript with node.js, knockoutjs, and couchdb. I reflect on my experience.
by Sunny Kalsi on June 17, 2014, 11:01 p.m.

My app, infonom is about half way to MVP. I decided to go full retard on javascript, mainly to force myself to learn the language, and how to use it in a decent context. Honestly, there’s a lot to like. I can see how a lot of people are into it. While I personally can’t survive without the velvet rope of type safety, I did enjoy the sort of flexibility that prototype based languages give you. It’s certainly an odd kind of flexibility, but also a good kind.

Prototypes still confuse me, mostly because of what properties are copied and what properties are mirrored, but it’s a fairly powerful concept. The idea that your “class” hierarchy is based on live objects that have the opportunity to be changed and updated can enable a bunch of tricks that generally require far more impressive language features. You can mimic a classes style system, or traits, or some functional semantics, all by using and abusing the idea of prototypes. In the end I’ve learnt enough about Javascript to make peace with it.

But I realised very quickly that I hated each of the three technologies I used: knockoutjs, node.js, and couchdb. But hold on because there’s a surprise twist coming.

Let’s start with node. There are a couple of reasons I like Node. One is that it makes it very hard to block. The code you must write to block is annoying to write. The second is that it “solves” multithreading in a novel way: By not having any. If you want your code to scale, it must work in a way that’s parallel. If you can “distribute” your code across several cores, you can distribute it across several machines. In normal multithreading there’s a huge discrepancy between many cores on a single machine and then switching to having the service go across multiple machines. Finally, it makes coding fun at first. You’re writing node and refreshing your browser and it’s all very quick and easy.

But it has problems. Incidentally, the node haters are just plain wrong. Without getting too distracted: Python runs slower than js, every language with blocking somehow has very slow frameworks (I wonder why), Node makes concurrency easy across computers, and “sharing code between front-end and back-end” is actually supposed to mean “I can decide later where I want this to run”, which you can’t do in, say, Java.

Where was I? Oh yeah! It does have problems! The first is that it’s javascript which is an awful language. I know, it’s got redeeming features, but that’s like saying “smoking helps you lose weight”. It also quickly scales to the point where it’s no longer fun. The language is no fun, the structure is no fun, the libraries are shit, and you start to wonder what the hell you’re doing in the baby pool. I could just as easily do this in another language by just removing all of the frameworks. It just all starts to grate. The language grates, the environment grates, and the benefit you had at the beginning: “quick” fades into the background.

In short, I’m looking for a way out of Node.

Now, onto knockout. I’m actually a big fan of MVVM. I think this is how applications should work, especially on the web. But after thinking about the zen of knockout, I’m finding myself increasingly at odds with the framework. The thing is, knockout treats JS as the view-model and HTML as the view, but HTML isn’t the view! If anything, it’s literally the view-model! It’s the representation of the model for the view (the browser). So, in a way, knockout is really just an elaborate translation layer between javascript and HTML. I still think there’s a kernel of knockout that’s valuable, but unfortunately it’s not the code.

In short, maybe I’m looking for something more akin to d3.js instead of knockout.

Finally, let’s talk about CouchDB. Couchdb is a document oriented DB written in Erlang. It has multi-master and effectively “solves” CAP in a particularly elegant way. However, it commonly uses Javascript to do map-reduce functions. It’s also no fun par excellence. Unlike “non-scalable” databases like SQL (or Mongo), Couch literally asks you to solve all the scalability problems up-front. It really does your head in. You want to make a simple website, and you have to start considering copy-on-write and merge conflicts. There’s also the temptation of doing micro-optimisations to lower the number of REST calls you make to Couch (talking to Couch is done using a REST interface, and it does so in JSON).

I can’t tell you how irritating it is trying to figure out how your data model is going to work when in reality you actually don’t care just yet and you promise to think about it later. However, you also know better and you won’t think about it later and it’s actually a good thing Couch is forcing you to do this. The good news is that once you’re done, you’re done. Start whacking the data in and… as they say… relax. Though it’s relaxing after like a year of constipation.

In short, I still like Couch but man I’ll really consider an intermediate data model before I use persistence in future apps.

So there you have it. Fuck node off, change knockout to be completely different, and keep Couchdb. In conclusion: Javascript!

Dynamic languages vs static languages

I talk a little about the benefits of so-called dynamic programming languages.
by Sunny Kalsi on May 28, 2014, 11:25 p.m.

We can look at programs in two different ways, firstly as the space inside a program, and secondly as the space between two programs. It has always been the case that more open systems concentrate more on the space between applications, and more closed systems concentrate on the space inside an application. We can see large monolithic pieces of proprietary software such as Adobe’s Photoshop have a lot of functionality built in, but do not communicate with applications outside themselves very well. On the other hand, small applications such as those on unix systems such as 'cat’ or 'cut’ can chain and connect to each other. If we want a dynamic and flexible operating environment, we must think deeply about the spaces between applications.

Importantly, though, is that we aren’t talking only about applications, but services, too. In fact, all data shared between applications, be it via files on a filesystem, or via a protocol, or via an API, all share a common thread: The data is either self-describing or it is not. Note that in reality, there’s no such thing as “self-describing data”. Mostly, the data is in a strict format, but that format might contain a description of the format. Notably, formats such as XML are strongly self-describing, formats such as JSON are loosely self-describing, and formats such as an IP packet are not at all self-describing. Also of note, even a binary format such as ASN.1 can be considered self-describing.

There are also grey areas such as protobuffers (or maybe even bson?), where a standardised externalised description will construct code that forms a generator / parser combination for non self-describing formats. Broadly, though, we may split formats into “self-describing” and “not self-describing”. Part of the reason is actually design intent. The design intent of a “not self-describing” format is to minimise the error space for a packet of information. A packet may, for instance, have a CRC which allows for rejection of the entire packet wholesale. On the other hand, a “size” field of a packet will be described as “n + 1”, so that a value of “0” is still considered valid. This is not being cheap on bits! If a value within a packet is invalid, what is a parser to do? In order to prevent this conundrum, all combinations of values in a packet should be valid, save for errors which allow an entire packet to be rejected.

By the same token, a “packet” of information can be defined as a piece of information which can be safely rejected. What “safely” means here is a little broad, but note that this doesn’t just apply for streaming protocols where both applications are present. A “packet-based” file format is quite common from compression formats to video codecs. The key is the safety and predictability of the parser: The parser simply doesn’t have many error cases to consider based on errors in the packet.

On the other hand, the design goals of a self-describing format are coping with change. These formats are generally only loosely sitting on top of a packet format, for instance XML or JSON which is just a long String in a particular encoding. Unlike the non self-describing format, the self-describing format leans heavily on both the program and the parser to ensure validity. An XML or JSON parser, for instance, have many checks that can be performed to ensure the validity of the message before it is even accepted, and even here there are many error cases that create grey areas for a potential parser.

For instance, if there are invalid characters, what does the parser do? What if there is a formatting error half way through a stream? What if the text validates but not under a more strict interpretation? What if the text validates but does not match the schema? What if all of that is true but there are other logic errors in the correctly formatted interpretation of the data? All of these are usually configurable options that a parser is usually initialised with. Even after all of that, there are various error conditions and corner cases to consider.

What does this have to do with statically typed and dynamically typed programming languages? Well, I’m about to argue that self-describing formats are most attuned to dynamically typed languages, and non self-describing formats are most attuned to statically typed languages.

This mostly has to do with the internalisation and externalisation of type information. In statically typed languages, as in non self-describing data, the type information is externalised. For data, by definition type information is externalised when it is not in the data. For programs, almost by definition, the closer type information gets to runtime, the more “dynamically typed” the language is. The whole point of a statically typed language is that you know the types at compile time.

There are, of course, various grey areas. Java has a runtime and reflection, but is “statically typed”. In my view, though, the runtime makes it dynamically typed when using reflection. Indeed, when you look at the error cases when using, say, Spring, it very much seems like a “dynamically typed language”.

On the other side of the coin, dynamic languages must keep all type information at runtime. This is as much about verifying type information that isn’t available at compile time as it is about determining the types of objects at runtime. While we are aware of Python and Ruby being fully dynamic languages with a full runtime, even languages like C++ and Java have RTTI and reflection. The easy way to think about this is that C++ and Java will throw Exceptions at runtime because the type information is incorrect, just like a dynamic language. In the same way, self-describing data describes its own type information within the data. To some degree, you do not need to know the structure of the data or what it contains.

Obviously, it is possible to use internalised data sources with statically typed languages and externalised data sources with dynamically typed languages, but it’s not an easy fit. For externalised data sources in dynamic languages, there’s a lengthy decomposition into their component parts, whereas in statically typed languages, it’s usually no more difficult than defining the data structure in the first place. Similarly, internalised data structures require complex parsers into static data structures in statically typed languages, whereas a dynamically typed language may not even have to care about the structures and types. It just inspects and alters them as if they were first class objects (in the case of JSON, they actually are).

The links go deeper though. In a static language and an externalised data format, you get the same guarantees: nothing has changed, by definition, since you compiled the code. The data format is the same, and so is the code interpreting it. Nothing can go wrong save for very specific error conditions. You effectively get static typing not only over the program, but also over the data it operates. Contrast with an internalised data format in a static language. All of a sudden you have error conditions everywhere which aren’t in predictable places. You may have noticed that static languages tend to have parsers that are very strict. The reason is purely to offer some clarity over how the program can fail. Having a statically typed program that can take a loosely formatted internalised data format and not explode (such as a browser) is no mean feat.

In the dynamic landscape, however, not only can this loosely formatted data be accepted, it can be passed directly into functions which carry out the actual computation. Even those functions need not know everything about the data structure. A module might be moving objects around or re-organising them, but it really doesn’t care what’s inside. As long as the structure is broadly the same, the code will continue to work. Even if the structure has changed completely, if the atoms remain intact then functions can operate over those atoms, keeping the structure the same. Even if both of those change, a dynamic language can introspect and deal with changes fairly elegantly.

This is where the idea of dynamic languages just being unityped static languages sort of falls down. If that were true, you couldn’t add two strings and two numbers as distinct operations. Once a value has been bound as an integer, it can be added, but importantly, if the language doesn’t know what the type of some data is, it doesn’t matter. As long as the transformations on that data don’t mess with the data the program doesn’t know about, the code just keeps on working. You can grab a bunch of XML data and pass it through a bunch of functions that do an addition operation, and the functions don’t need to know what data they’re adding, because that forms part of the internalised description of the data. Is it an integer XML attribute? The integers get added. Is it a String? They get concatenated. Is there other data or other data structures nearby that the code doesn’t understand at all? Doesn’t matter; executed correctly.

And this is where I’m getting at: In a world with many small apps, dynamic apps are king. This is why most scripts that keep a computer running nicely were written in Shell, then Perl, and now Python. These applications are effectively wiring data between applications. They need to know very little about the data, even though they may need to manipulate it before passing it on. Want to write a log parser? Python is probably far easier, more flexible, and more useful. Want to take a bunch of deep and complex JSON and parse out a simple calculation? Maybe Javascript is just the ticket. Having dynamic languages as high level co-ordinators of other applications is probably a very good idea.

It feels like people treat static or dynamic languages as a religion of sorts, but the fact of the matter is, these languages are more indicative of the kinds of problems we’re solving as opposed to the way in which we’re solving them. Static languages treat data as ingots of steel, and that’s good for when you want data that’s got to take a beating. Dynamic languages treat data like putty, and that’s good for when you need it to fit in that damn hole. In the end we need both kinds of languages sitting next to each other if we’re going to be able to process data correctly and flexibly, and we should be able to understand how to apply each to have the most powerful code.

In the end, the argument over dynamic and static languages is really an argument over which kind of data structures the program should be processing: data where the structure is expressed internally to the data structure, or data where the structure is expressed externally to the data structure. Ultimately, if we want the most flexible software, we need to know when to use which kind of data structure, and how to pass these data structures between programs in a landscape where the code is always changing. I feel that having static and dynamic languages co-operate in a multi-process environment will yield better and more flexible architectures than with a language monoculture.

Monads for Java programmers

I try and translate the value of monads from the wild and crazy world of Functional Programming to the rough and tumble world of Java programming.
by Sunny Kalsi on April 29, 2014, 1:07 a.m.

I’ve had about three goes at understanding monads. The first alone, the second via some category theory training at work, and the third via this tutorial. While each of the three approaches has helped me understand what’s going on, the monad tutorial is probably the best bang for buck. It’s quick and easy to understand.

One thing I’m aware of is that everyone who has tried to learn category theory has written a monad tutorial. There’s a joke going around that it only demonstrates their understanding of Monads, and doesn’t help anyone else. I’m going to attempt to buck that trend by explaining monads by using Java, and the terminology of traditional OO programming.

So firstly, the thing to understand is that Monads are a design pattern. Ultimately, what they are about is solving a design problem, in the same way as Interfaces, Factories, or Builders solve design problems. The difference is that usually these design patterns are about layering software, and abstracting responsibilities. Monads, however, are about abstracting side-effects. I think programming as a discipline has seen how important that is, so let’s have a look at how Monads solve this problem:

interface Monad<I>
{
    <O> Function<Monad<I>, Monad<O>> wrapFunction(Function<A, Monad<O>> fun);
    Monad<I> wrapValue(I val);
}

Before I continue, I’m doing my best to represent the Monad pattern in a “natural” way in Java. In languages with more advanced type systems, the same “code” above will actually be far more powerful, but even in Java-land, this is quite a useful pattern. Also, the Function definition is from Guava. I hope you’re familiar with it.

The above Interface will look odd to start with. After all, why have these “wrap” functions on an interface? What’s the interface for? How do you use it? How does one even remotely abstract side-effects with this? The answer is: Category Theory. At this point I wave my hands about and say “WOOOO” and everyone’s really impressed with how smart I am. Seriously, though, the theory is clever trickery but when you actually work with it in practise it’s pretty straight forward.

People talk about Monads as “boxes”, and that’s an apt metaphor, but be careful, these are mathsey-boxes, so the metaphor will break down easily (there’s no unwrap!), and the value of them is not in the wrapping and unwrapping anyway. Note that these don’t work at all like the Proxy or the Facade design patterns, which you can kind of think of as “boxes”.

In order to demonstrate its use, I’m going to create a UselessMonad:

class UselessMonad<I> implements Monad<I>
{
    I val;

    I unwrapVal() {
        return this.val;
    }

    <O> Function<UselessMonad<I>, UselessMonad<O>> wrapFunction(Function<I, UselessMonad<O>> fun) {
        return new Function<UselessMonad<I>, UselessMonad<O>> {
            UselessMonad<O> apply(UselessMonad<I> a) {
                fun.apply(a.val);
            }
        }
    }

    UselessMonad<I> wrapValue(I a) {
        return new UselessMonad<I>(a); // Pretend there's a constructor.
    }
}

Note: I’ve skipped public final etc. etc. for brevity. Note also that the Interface types are now UselessMonad. I did that so that the type signatures are clear in the Monad interface above, but you should know how to change things so that the cast isn’t required.

OK, So this basically wraps a function and a value so that they are “boxed” in a UselessMonad. So far, this should look… odd… but not “difficult”. You should hopefully also notice that you can do this:

UselessMonad<String> v = new UselessMonad<String>();

Function<String, UselessMonad<String>> sayHello = ...;

String val = v.wrapFunction(sayHello).apply(v.wrapValue("world")).unwrapVal();

OK First let’s talk about the v jiggery-pokery I’ve done. In Java, you can only put an interface on an instance. Unfortunately, we want to put those interface methods to be static. Since we can’t do that, this is a hack to get around it.

Next, I want to talk about the slightly strange signature of sayHello. I mean, why would a function like that return a UselessMonad? And also, what if a function just returned a String and not a UselessMonad? Well, you can just construct a Function from another Function!

Function<I, UselessMonad<O>> uselessOf(Function<I, O> fun) {
    return new Function<I, UselessMonad<O>>() {
        UselessMonad<O> apply(I a) {
            return v.wrapValue(fun.apply(a));
        }
    };
}

To put it into words: You can take a Function that takes an A and returns a B, and create another Function that takes an A and returns a UselessMonad<O>, by calling wrapValue() on the result of the function. Before we continue down the rabbit hole, I just want to make it clear that it’s easy to generate functions that return the “Monad” version of a value from “normal” functions.

OK, so what does that wrapFunction line way up above actually do? Well, it does the equivalent of the following:

String val = sayHello.apply("world").unwrapVal();

So why write all that wrapping and unwrapping cruft if all you want to do is apply a Function? Well, the magic trick above is that the input and output of the function are both boxes! What this means is that you can write:

Function<String, String> howYaDoin = ...;

String val = v.wrapFunction(uselessOf(howYaDoin)).apply(
    v.wrapFunction(sayHello).apply(v.wrapValue("world"))).unwrapVal();

I’ve thrown in a uselessOf in there for good measure. Hopefully it doesn’t make things too confusing. Nice, right? I mean, it looks like a dog’s breakfast, but the good thing is that you can just keep wrapping functions till the cows come home. This is the whole point of the Monad! You go to all this trouble of functions that return functions and wrapping functions and the crazy signatures just so you can do this wrapping and applying and wrapping and applying.

But how does this help abstract away side effects?

Well, imagine your Monad wasn’t actually useless. Imagine it was something like Guava’s Optional:

class Optional<I> extends Monad<I>
{
    // Imagine the rest of Optional code here.
    <O> Function<Monad<I>, Monad<O>> wrapFunction(Function<I, Monad<O>> fun) {
        return new Function<Monad<I>, Monad<O>> {
            Monad<O> apply(Monad<I> val) {
                if (val.isPresent()) {
                    return fun.apply(val.get());
                }
                return absent();
            }
        };
    }

    Monad<I> wrapValue(I val) {
        return Optional.of(val);
    }
}

This means you can call code like:

Optional<String> val = v.wrapFunction(optionalOf(howYaDoin)).apply(
    v.wrapFunction(maybeSayHello).apply(v.wrapValue("world")));

Now, we can see the Monad in action: it allows you to chain up commands that return an Optional without having to constantly check for null, even though the howYaDoin function doesn’t expect a null as its input, and even though the maybeSayHello function might return absent(), it all just works. What’s even better is that this isn’t just true of Optional, but things like Futures, Lists, Logging, Transactions, etc. can all be written and composed in this way. A few more things to note here are that the “side-effects” of what’s Optional and what’s not are written in a completely type-safe way. You can’t accidentally do something silly like pass an Optional value somewhere where it’s not expected. There’s also a clear separation of concerns between the side-effects of potentially failing functions, and the actual main flow of the code. This is the problem that Monads solve.

Another important note: You might, as you’re writing Functions and things, get to a point where you have a Monad<Monad<I>>. Another important property of Monads is that you can take a nested structure of monads and create a single one:

Monad<I> flatten(Monad<Monad<I>> m) {
    m.wrapFunction(new Function<Monad<I>, Monad<I>>() {
        Monad<I> apply(Monad<I> a) {
            return a;
        }
    }).apply(m);
}

Again, you need to liberally sprinkle more generics on there, but the idea is correct. This is slightly magical as well, but basically it takes a function that just returns the value that it’s given, wraps it so the input will be a Monad<Monad<I>>, and will return a Monad<I>.

That’s all kind of neat, but for the Optional case, why not just do:

Optional<String> val = Optional.of("world").transform(maybeSayHello).transform(howYaDoin);

The short answer is: Yeah, that’s probably the smarter way. In languages like Haskell the Monad has significantly more power than in Java, so Monad is clearly the more attractive solution there. However, in Java, Guava’s chaining approach is pretty good. There are cases where the Monad way will result in less boilerplate code, but it’s probably not worth the added complexity. This is especially true if you look at all those wrappings occurring everywhere!

In conclusion, hopefully now you have a hands-on understanding of what a Monad is and where you might want to use it. It has limited usefulness in Java, but nevertheless is a very powerful design pattern. Keep in mind that this tutorial is not meant to cover the category theory and all the requirements of the design pattern (such as the Monad Laws, which you must not break), nor does any of this code compile. It’s probably worth writing this code in a way that is type-safe and compiles, and having a play with Monads. They are a very powerful pattern and once you get the hang of them you’ll see uses for them all over the place.