Self Unemployed

Why I don't use Lua

I sometimes find myself having to defend my choice to never use Lua, both professionally, and in my more personal work. Rather than explain it at length every time, I figure I would place all my misgivings into a single post. I don't think Lua will ever change to fix these misgivings, as it takes a different mindshare from that of other languages, and has quite a following in its community. Frankly, Lua and I just don't mesh.

This post can be seen as a rant, and should be taken as opinion. It is also a brief and shallow discussion of the many other minutiae I have regarding Lua. This post is not a call for discussion. It is a short rant on why I don't like Lua, and why I don't use it.

Read more »

An Attempt to Explain Monads in C++

Last time, I spoke about some potential continuations that someone can do in C++ with optional types. I briefly stated, in regards to the Boost.Expected proposal:

This is all well and good, however I noticed that these choice of words 'map' or 'bind' aren't what I think when reading.

Someone pointed out to me that the 'map' call comes from one of the three operations one can perform on a monad. The other two being 'join', and 'return'. After digging into the Boost.Expected proposal some more, I finally had that epiphany where one understands what a monad is. As such, I want to keep with the time honored tradition of trying to explain it to others, and continuing to confound the congregation of programmers who haven't yet grokked it. However, I'll explain it in the context of C++, rather than trying to explain Haskell, and how some of its features map to C++. And while burritos are delicious, I won't be referencing them at all.

Read more »

Optional Types and Lightweight Continuation Passing in C++

MNMLSTC Core is starting to near its 1.2 release target, and this will most likely be the last version that targets C++11 and may be the last non-bugfix release for the 1.x series. There are many reasons for this, but the primary one is the difficulty that exists in implementing C++17 proposals without C++14 language features. Before I move on to begin work on 2.0, I'm going to add be adding several extensions to the proposals that Core alrady implements. Specifically, I'll be adding extensions to the optional types. As of right now, the match member function that is provided for core::variant<Ts...> is now available for all the optional types that Core provides (optional<T>, expected<T>, and result<T>). However, this post is about a different feature that I'll be adding and it may be one that doesn't exist beyond the 1.x series. Please note that this post makes extensive use of C++14 library features that are implemented in MNMLSTC Core, as well as the extensions MNMLSTC Core provides (namely result<T>). In addition, the code contained within is not 100% correct, and should be approached as though it were pseudo code.

Read more »

C++ Needs Better I/O Facilities

C++ is not well liked by a large number of non-C++ programmers. One of the arguments that has stood the test of time against C++ is the streams library. It's even a point of contention within the C++ community. The main arguments against the entire streams library are usually:

  • Overloading operator <<
  • Performance
  • 'God Objects'

We're going to ignore that first bullet point, however, because it is entirely opinionated. Developers can argue about overloading operators and what should and should not be overloaded all day (and they usually do).

Read more »

RValue Reference Implications In C++11

There are several implications that one has to realize when it comes to using rvalue references in C++11 APIs. For starters, requiring an rvalue reference as a parameter to a function implies the following:

  • The object being passed in may be mutated
  • The object being passed in may exist until program exit
  • You (the caller) no longer own the object being passed in

This is fairly large in terms of writing an API. In days of yore, before the existence of rvalues and move semantics, one might have used a pointer, or non-const reference to designate that an object would be mutated. They may have gone a step further and passed the object in by value to show that a deep copy would be made as the object passed in was no longer your concern. But none of these implied one very important feature that C++ technically lacks.

Read more »

Your First Job Is the One You Remember Most

The first real job I had was at a small software company. Our dev team was small. Really small. 3 people to be exact. When looking to hire on someone new to the team, our team lead would occasionally show me people’s resumes, usually with a statement of “look at how bad this was”. As a brief note, our team lead was from Russia which, while related to this story, is for another post at another time.

Read more »