Seven Languages in Seven Weeks - Prolog

I've wrapped up chapter four of Seven Languages in Seven Weeks by Bruce Tang.  This one is on Prolog, an interesting language unlike any that I've worked with.  All of the other languages I've worked with are imperative languages, whereas Prolog is a declarative one.  With imperative languages you explicitly specify the steps that an application will perform, but with a declarative one, you don't have to.  You merely describe the context of a problem and what you know about it, and then let Prolog infer a solution.  A cool example from the book is the following code, which determines all of the possible ways to color a map of the southeastern states, using three colors and having no two states of the same color touching:

different(red, green). different(red, blue).
different(green, red). different(green, blue).
different(blue, red). different(blue, green).

coloring(Alabama, Mississippi, Georgia, Tennessee, Florida) :-
   different(Mississippi, Tennessee),
   different(Mississippi, Alabama),
   different(Alabama, Tennessee),
   different(Alabama, Mississippi),
   different(Alabama, Florida),
   different(Georgia, Florida),
   different(Georgia, Tennessee).

This example shows Prolog's power.  With just a few lines of code, it can solve some complex problems.  It's not a general purpose language, but it's a great language for constraint-based problems like airline scheduling and natural-language processing, as well as artificial intelligence.  I also once found Prolog to be the easiest way to solve a problem.

I really liked learning Prolog, so much that I bought a book on it.  I continue to be blown away at how easily Prolog can solve some problems - "I know this and this, now computer, tell me the answer!"  That's oversimplifying it, but it captures the spirit.  It's just fun to look at things in a different way.  While I'm curious whether I'll ever come across a reason to use it in the workplace, I have no doubt that learning more about Prolog will be useful, as it will give me a stronger theoretical background and another perspective to consider when approaching a problem. 

My answers are on GitHub.  Now on to chapter five, focusing on Scala.

Automate Everything

I recently attended the Great Lakes Software Symposium, where a lot of attention was given to continuous delivery.  And one of the takeaways I got from these discussions was that our friend the computer is the fastest, most reliable, and most accurate worker on the team.  He's also relatively cheap, doesn't get bored, and is willing to work crazy hours.  He should thus be given as many of the repetitive and lower-value tasks as possible - and preferably all of them.

On the other hand, you are a far brighter, more innovative worker.  You're capable of coming up with solutions that your computer co-worker couldn't fathom, making you way more valuable than him.  Therefore you should be given the problems that require the most insight and creativity.

To free you up to focus on the difficult and high-value work, everything that can be automated should be automated.  Everything.  Not just building and testing, but also deploying, configuring your application, configuring the application's environment, resolving issue-tracking tickets, setting up a new developer's local environment, adding a new developer to a project (adding him or her to version control, issue tracking, etc.), and any other repetitive task you can think of.  This is generally the fastest, safest, and most cost-effective approach to delivering software.  Making humans work on stuff that could be automated is unreliable and a waste of time, talent, and money.

Seven Languages In Seven Weeks - Io

Chapter three of Seven Languages in Seven Weeks is on Io, a prototype-based language that is very intriguing.  Io reminds me of Othello, the classic board game that takes "a minute to learn, a lifetime to master".  Io has a small, simple syntax that essentially is just a bunch of messages chained together, so you're hacking away with the language in a matter of minutes.  Yet its remarkable flexibility allows you to do some very interesting stuff - and do it kinda easily.  The book showed a few such examples, which took me a little while to grasp.  That's the thing about Io: it can do some powerful things, particularly along the lines of metaprogramming, but how to do these things is not immediately obvious, so you have to take the time to really learn the subtleties of working with the language.

The question, though, is whether it's worth such an investment.  Io has a small community, making it hard to find information.  Granted, there is a message board and some helpful sites, but often you can't just google around to quickly find the answers to your questions like you would for other languages.  Outside of Pixar, I'm not aware of a well-known enterprise application or consumer product that uses Io, which doesn't help its visibility.  I think it has been used in some embedded systems, so we'll see if it gains any prominence there.  For me personally, I think I'd be willing to use Io professionally if there's ever a demand for it.  But for now, there's other languages and technologies that interest me more and will probably have a greater impact on my career, so I only see myself occasionally working with Io for fun and a fresh viewpoint on things.  Nonetheless, I'm glad that I've had exposure to it.

I've added my answers to GitHub, so let me know of any corrections or improvements.

Next up is Prolog.

Seven Languages In Seven Weeks - Ruby

I've finished the second chapter of Seven Languages in Seven Weeks by Bruce Tang, which is on Ruby.  I already knew a little Ruby, so I was familiar with some of the content.  But the chapter, despite not being that long, covers some more advanced topics that I either didn't know or wasn't that familiar with.  Overall, it's a good start to an interesting book.  Answers to the problems aren't provided, so I've posted my answers on GitHub.  Feel free to review them and notify me of any incorrect answers or improvements to them.

Ruby has foremost been designed to increase the efficiency of the programmer versus making the language itself performant, and this emphasis is clearly evident.  I really appreciate how the language can be so expressive yet concise.  I've enjoyed messing with Ruby and can see why so many developers prefer to work with it.  Without knowing much about the Ruby environment, I'm wondering why more IT departments aren't adopting Ruby and Rails (or at least not adopting it faster than the current rate).  It seems like a great platform for rapidly implementing an application.  I know Ruby gets knocked for its performance, but in my experience there's a greater concern for implementing and releasing functionality in a timely manner than there is for ensuring a certain level of performance for the application.  It's a paradigm shift for many IT departments, but one that seems to offer large dividends.

I was interested in learning Ruby before reading this chapter, and now I'm even more interested.  But for now, it's on to Io...

Null Coalescing in Java

Since Java doesn't have a null-coalescing operator like C# does, I wrote a method that does the same.  The code and tests:

public class Coalesce
{
   public static <T> T coalesce(T value, T defaultValue)
   {
      return value != null ? value : defaultValue;
   }
}

public class CoalesceTest
{
   @Test
   public void shouldReturnValueIfNotNull()
   {
      Double nonNullValue = 123d;
      Double defaultValue = 1d;
      Double result = coalesce(nonNullValue, defaultValue);
      assertEquals(nonNullValue, result);
   }

   @Test
   public void shouldReturnDefaultValueIfValueIsNull()
   {
      Double nullValue = null;
      Double defaultValue = 1d;
      Double result = coalesce(nullValue, defaultValue);
      assertEquals(defaultValue, result);
   }

   @Test
   public void shouldReturnNullIfBothArgumentsNull()
   {
      Double nullValue = null;
      Double defaultValue = null;
      Double result = coalesce(nullValue, defaultValue);
      assertNull(result);
   }
}

It looks like Google's Guava library has a firstNonNull method that does the same thing, the only difference being that it throws a NullPointerException if both arguments are null.  I guess throwing the exception makes sense, particularly if the name is firstNonNull, but at the moment I lean towards just having the method return null if both arguments are null, similar to how the C# operator works.