Thursday, July 31, 2014

Why I am letting my ACM membership lapse

I have been thinking about this lately but interestingly enough, Slashdot is carrying an article on why ACM is not interesting to programmers (link to original article by Vint Cerf).

For me it is pretty simple - ACM and the Communications of the ACM used to be a place where seminal papers and new algorithms used to be published. A place where you could explore clever ideas, tricks and fundamental issues all in once. Now the CACM publication has turned into a semi-scientific, semi-IT-manager set of articles with absolutely no attention paid to people who want to practice _computer science_. I swear, if I read one more article on "enterprise IT something", I am going to organize a public burning of the copy of CACM in question...

Friday, July 18, 2014

Saturday, July 05, 2014

Of horses, rodeos and people

This 4th of July, like every 4th of July, we went the local rodeo. It is a nice celebration and just being in close proximity to so many horses and cattle makes it all worth while.

However, this year an ugly conclusion struck me out of nowhere: if you love horses and cattle, you should not be at a rodeo! Why? Well, for one, the level of horsemanship at the rodeo is appalingly low. I am not a high-falootin' horse whisperer, in fact, I consider myself to be a beginner with only four or five years experience, however, I have high standards of what the horse should be doing, how they should be doing it and what tools the horseman or woman should be using to get things done. I may not know how to get there yet but I do know what I want and don't want.

First off, almost every horse at the rodeo was ridden with a tie-down and a shank bit in their mouth. The “horsemen” riding these horses were all heavy handed, it hurt just watching things unravel. Nine out of ten horses were prancing and jigging with the owners pulling one way and the tie-down pulling the other way with the horse's mouth in the middle.

It is strange because at the beginning I thought it must be the steer-wrestlers or the ropers or the barrel-racers that had the bad and antsy horses who just couldn't sit still (despite the tools and the heavy hands). Then I realized that the “pickup horses” were the same (by pickup horses I mean the horses used to untie and catch/steer the cattle, the bulls and the broncs).

Even the team of ladies who came in to help kick off the rodeo by doing their show with the American flag at a canter and a gallop had bad horses. They all looked uncontrollable and some of them looked like they could come unhinged within a matter of seconds. With the exception of two horses, that whole team too had tie-downs and harsh shank bits.

By the end of it all, I just thought to myself how awful it all is. These people are horseback almost every day and they are what signifies America's history and love of horses and horsemanship. They are what the general public comes to watch, no, pays to watch in some delusion that horsemanship experts are in front of them putting on a show.

How sad! But you know who I feel worst for? Those poor horses. Even with all the tie-downs, shanks and heavy hands (and sometimes whips as an added bonus), most of these animals are nice and still do what they are asked to do. If it were me out there with a saddle on my back, my chest tied to my head and a 3 inch shank pulling on my mouth, I am not sure I would be that nice.

Happy 4th of July!!

Wednesday, June 25, 2014

Is Scala the C++ of the Java world?

I have spent considerable time learning Scala. Read a few books, wrote some code. It is not a bad deal - you get the world of Java, all its libraries, all the code ever written in it - all wrapped in a nice object-oriented and functional approach.

However, the complexity of the language seems daunting at first. There are many exceptions, catches, constructs and assumptions in the language. No matter how many books you have read and how much code you have written, it always feels like you missed something, maybe a chapter in some book or some feature that could have made your code better or prettier or completely different. Many libraries outside what comes with the language are half-baked, in a state of flux, they all seem to be built differently. There are multiple frameworks for doing simple things, they all have some advantages and some drawbacks over the competition. Then there is SBT - where to begin with that one? ;-)

People keep saying more choice is better but what if many of the choices are half-baked or in a state of constant, never-ending flux? I will quote an old German proverb: "He who has a choice, has the doldrums".

Then there is Play 2, Akka and a myriad of other outside frameworks almost as complex (if not more complex) than the language itself - many of them trampling on each other by re-implementing some of the functionality of the other. Add to the mix ScalaZ - hey (!), I thought Scala was already supposed to be functional! ;)

At the end there is the question of being just able to sit down and write what works without much boilerplate and rituals to basically satisfy the compiler or the build tool. Python allows it (and I do not particularly like Python), C is easy, heck, even writing a piece of code in x86 assembly with gas/ld is easier and faster to get going!

So, why stick with Scala?

This article briefly outlined the negatives. In the next article I will weigh in with the positives and discuss whether it is just better to stick to Java or go the extra step and invest in learning Scala. I will also try to answer the question of why I brought in the (admittedly nasty) comparison to C++.

Friday, May 30, 2014

Case study in Scala: Avoiding imperative programming (does it pay off?) -> Part 1, The Ugly

Just for fun, let's consider the imperative example of counting words in a string, as presented in the Chapter 17 of Programming in Scala book by Odersky et al. In it, we have:

scala> def countWords(text: String) = {
  val counts = mutable.Map.empty[String, Int]
  for (rawWord <- text.split("[ !.,]+")) {
    val word = rawWord.toLowerCase
    val oldCount =
      if (counts.contains(word)counts(word)
      else 0
    counts += (word -> (oldCount + 1))
countWords: (String)scala.collection.mutable.Map[String,Int]

scala> countWords("See Spot run! Run, Spot. Run!")
res30: scala.collection.mutable.Map[String,Int] =
Map(see -> 1, run -> 3, spot -> 2)

Let's try and do it in a recursive/functional way, without mutable Maps:

scala> def countWords(s:String):Map[String,Int] = {
   def countW(str:List[String], 

              acc:Map[String,Int]):Map[String,Int] = {
     if (str.isEmpty)
     else {
       val k = str.head
       if (acc.contains(k)) {
         val wCtr = acc(k)+1
       } else
  countW(s.split("[ !,.]+").toList,Map[String,Int]())

scala> countWords("See Spot run! Run, Spot. Run!")
res21: Map[String,Int] = Map(see -> 1, spot -> 2, run -> 3)

Neither of these implementations are pretty. The recursive one essentially does the same thing as the iterative one but it does it in a "clunkier" way - we actually have to throw out the (String,count) pair and re-add it every time the same word is encountered. However, it does the job,

Let's see if we can improve on this in the next installment.

Thursday, May 22, 2014

Hacking on a FreeBSD port

I have been trying to check out the CURRENT branch of FreeBSD so that I can start playing with the kernel - ran into a tiny problem: for some reason FreeBSD folks use subversion (yuck) to manage the code. The port of subversion in the ports tree, however, segfaults on my machine. It does generate a core so I recompiled the port with debug symbols and then ran gdb on the program and the core file and got a file/line within the file where it is segfaulting. All I want to do is insert a printf() statement there.

Below is the sequence of commands to do it - I am sure there are better ways but hey...

(as root):

cd /usr/ports/

make clean distclean fetch

make extract

cp work/(path/filename) work/(path/filename).orig

vim work(/path/filename)
make the change

make makepatch (this will add your change to /usr/ports//files/ for "next time")
rm -rf work

make fetch
make extract
make build

The produced executable under /usr/ports//work/ should now have your change in it.