shahriar

Structural Pattern Matching using Exceptions

Shahriar — Fri, 17 Feb 2012 21:26:39 +0000

Back in college when I was first exposed to functional languages, I fell in love with algebraic data types and structural pattern matching. Now that I have joined the work-force I no longer have the freedom to work with those languages. So I decided to give a shot at emulating structural pattern matching in Java.

If this concept is new to you here’s a short intro. Let’s say we want to represent binary trees. We know that a tree has three kinds of structures:

A node that can have a left branch and right branch
A leaf that has a value
An empty tree with no value or branches

In Haskell, we can group these three structures under a single data type:

Now, whenever we do any kind of operation on trees, we can use pattern matching to find out which of these three structures we are dealing with. For example, here is function that calculates the depth of a tree.

This recursive function, tests the structure of the tree and returns different values depending on the pattern that matched.

Now, all that is good. But how do we implement the same in an object oriented language that does not support algebraic data types or pattern matching. Well, the closest thing to algebraic data types in an OOP language like Java is a class. And to simulate pattern matching we will use a feature called polymorphism.

Here’s our first implementation:

Nothing fancy is going on in this code snippet. I declared an interface called Tree which defines a method signature called “depth”. There are three classes that implement this interface. And each class provides it’s own implementation of depth. With this setup, the master depth function is trivial:

With the help of polymorphism, at each step of the recursion, the right implementation of depth is going to be called based on the class.

So? What’s the problem? Well, it was trivial to write, but it’s going to be a nightmare to maintain this setup. Let’s say, tomorrow we want to add a function to flatten a tree, or a function to do an in-order traversal. We would have to add the methods to the tree interface. And then we would need to add an implementation of these methods to each of the three classes. Doesn’t sound like a lot of work. But imagine if we were distributing these classes as a library and there were hundreds of other people using it. Each time we add a couple of utility methods to the Tree interface we would need to recompile all the classes and deploy a new version of the library, and ask hundreds of users to update to the latest version.

So, we will need to think of a different approach. One that does not require us to change the original classes. We need an approach that empowers the library user to write his own implementation of “depth” without any fuss.

The quick and dirty way would be to use the instanceof operator to perform pattern matching manually.

This version works, but it has its problems. By using the instanceof operator we are giving up all compile-time guarantees on whether we are doing our cast correctly. That means, if you make any mistake, you’ll only find that out only at runtime. Moreover, our previous approach used interfaces. So we were guaranteed to have an implementation of depth for each possible structure. In our new approach, there are no such guarantees. If the library user, forgot to check for a particular variant of the tree structure he wouldn’t get any compile time warning, just an exception at runtime.

We need a new approach. One that takes advantage of compile time checks and also forces us to exhaustively check for all possible structures. We can do that using Exceptions and Try-Catch blocks. Here’s our new implementation of Tree:

Here are the important differences:

Tree is not an interface anymore, it’s a concrete class
Tree extends Exception, so it can be thrown
Node, Leaf, and Empty are also exceptions, so they can also be thrown
The match method can throw an exception corresponding to each possible structure

With our new approach, here is our new depth function:

Since the match method of the Tree class exhaustively lists all possible structures as throwable Exceptions, the depth function will even not compile unless there is a catch block for each structure. As a result, you are getting both exhaustiveness and compile time checks at the same time. To be honest, this does not guarantee 100% exhaustiveness. The developer of the library has to make sure he throws an Exception for each possible sub-class of his algebraic type. But at least, in this approach, the burden of responsibility lies on the API side, not on the user. Therefore, if any future release of the library introduces a new structure, users won’t have to read the documentation, or discover it at runtime. They can just rely on the compiler to do the check for them and identify the affected methods.

There’s just one thing that makes this approach less than perfect. Unfortunately, our tree class cannot be generic. Because of the way generics are implemented in Java, sub-classes of Exception are not allowed to be generic.

If this is a deal breaker for you, check out this excellent blog post that describes another approach using the Functional Java library.

Paradox of a CS major

Shahriar — Wed, 08 Feb 2012 20:02:06 +0000

We know how to write a History essay or an English research paper, but don’t have any clue when it comes to writing a functional specification document or a technical design document.
We can accurately measure the run time complexity of an algorithm but cannot reliably say how long we will need to write a piece of code.
We can make sense of an assembly dump, but cannot parse a piece of code written by someone else and proceed to rewrite it.
We learn how how to code the hard way with Vim and Emacs, but never bother to learn to use all the features of Eclipse.
We can do miracles while coding alone, but have no clue how to commit, checkout, branch, tag, and merge using a revision control software for a team project.
We excel at writing thousands of lines of code, but have difficulty compiling, linking, and creating executables.
We enjoy the challenge of a good debugging session, but hate to write unit tests and regression tests.

LATW Episode 13 (January 1 – January 31, 2012)

Shahriar — Thu, 02 Feb 2012 21:15:24 +0000

Web Video Box Office

Breathtaking aurora formed by the largest magnetic storm in 10 years

Interesting short film about prejudice against robots

Computing

Science

Bonus

Pitfalls of Programming at Work

Shahriar — Wed, 18 Jan 2012 21:15:15 +0000

As I slowly approach to the end of my second year of work at GE, I can sense how much I have changed as a programmer since I left CMU. In this article I want to put down my “lessons learnt” on paper. Chances are that in a few years I won’t even remember what it felt like to go to college. So before I forget I want to pass on the experience that no text book could ever teach me. Rather than a write a wordy reflective essay, I will just list some of the common pitfalls that you should avoid as a newly hired programmer.

Resist the urge to rewrite code

This is probably the hardest one. So it deserves some special attention. You will come across a lot of crappy code in your work life. There’s seldom any documentation. So your only option will be to read through code. And the more you read, the more you will feel the code has no structure, things are not done in a proper way, there’s a lot of repetition etc.. Well guess what? It might be crappy code, but it’s well tested crappy code. A lot of the obscure code-blocks are undocumented patches to bugs people found after months of testing. If you are new to the company, you will have absolutely no clue about all the bizarre edge cases of a program. Chances are when you rewrite a piece of code, you will produce a clean but buggy application. If you are unsure whether to rewrite or not, ask yourself these questions:

Will cleaning up the code reduce development time in the future?
Will it make testing easier?
Will it make deployment less time consuming?
Does #1, #2, #3 take more time the time it will take you to rewrite the code?

If the answer to all four of these questions are “yes”, try to see if your coworkers think the same too.

Not being satisfied by anything other than your work

This is also a hard one. If you are a hard-working and productive programmer, you will get a lot of responsibility on your shoulder. There’s nothing wrong with that. But don’t go overboard. Typically there will be others in your company who can also code. You may not think that they are as skillful as you. But practically speaking, given enough time they can also get the job done. So don’t lose your sleep trying to be a one man army. Be a team player. Learn to delegate. Document your code, so that others can fill in when you go on a well deserved vacation.

Get over the need for speed

Yes, changing that data structure to a tree will make lookups O(1). But it will only reduce runtime from 10 minutes to 9.5. It’s usually very hard to give a find out the big O complexity of real life programs. So don’t jump at the first chance you get to apply your algorithm skills. Profile your code thoroughly. Get an understanding of what the real bottlenecks are and whether they are under your control. And even then, you should only optimize if your users are complaining about it.

Reluctance to test your code

Admit it. We all hate testing. We hated in college. We got mad at professors who graded your test cases. And we still hate it at work. The only difference is, now the code may affect the lives of hundreds or even thousands of people. So get over it. If you feel testing is a waste of time. Write test scripts. Write modular code. Write unit tests as you code. Get your co-workers to test your code. The more testing you pile up till the end, the more repulsive it will get. And then procrastination will take over and you will end up shipping buggy code.

Those were the main pitfalls I could think of. Maybe someday I will write a part 2 for this post with all the small tips and tricks I picked up over the years. Anyhow, if you manage to start your career avoiding these pitfalls, you should have a bright future ahead.

A rant against “religious spam”

Shahriar — Tue, 17 Jan 2012 20:34:18 +0000

I don’t claim to be a religious person. However I do view religion as a part of my identity, just like my nationality. Just like I won’t tolerate racist behavior against Bangladeshis, I wouldn’t tolerate mistreatment of Muslims either. However the opposite scenario is also true. Just like how I am sickened when I hear about a Bangladeshi doing something stupid to ruin our reputation, I am also ashamed when a fellow Muslim make us all look misinformed. This is really what this rant is all about.

Since the olden days of “Hotmail” people have been forwarding emails containing scientifically inaccurate “proofs” of vague concepts mentioned in the Quran. Even with the advent of social networks, people haven’t changed much. I still see some of my Facebook friends copy and paste statuses that outrageously inaccurate. Here’s one of my recent favorites:

So “all the rays will emit from your brain to earth”, will it? As if electromagnetic waves are like water drops and will drip of your hair when you lower your head? So why I don’t see sunlight coming out of ears when you pray. Or why not the latest episode of America’s got Talent? They are all electromagnetic waves just like mobile signals.

I don’t mind people posting religious content on Facebook. In fact I actually encourage it because social networks are a great way of reaching out to people and I don’t see why religious scholars shouldn’t make use of it. I would just like to see authentic material. Quote something inspiring from the Quran, or a Hadith. Translate it into English or in your mother-tongue so others can understand. Just stop posting this non-scientific nonsense. You guys are all educated people. Just exercise your high-school science skills before copying statuses and spreading religious spam.

And if you would like to go the extra mile, click next to the post and mark it as spam to help stop spread this disease.

My First Cinegraph

Shahriar — Thu, 12 Jan 2012 23:31:07 +0000

It’s not a perfect cinegraph, but she’s adorable nonetheless…

LATW Episode 12, (November 15 -December 31, 2011)

Shahriar — Fri, 30 Dec 2011 20:59:12 +0000

Web Video Box Office

Time lapse video of comet Lovejoy

Vertical progression through the human skull

Image Gallery

Long exposure photo of a candle procession

World’s largest 3d painting

Gale Crater: Landing site for the Curiosity Mars Rover

Larissa Sansour: Palestine in Sci-fi

Inventor of the multi-tabbed browser

Science

Computing

Bonus Links

LATW Episode 11, (October 1–November 15, 2011)

Shahriar — Thu, 17 Nov 2011 18:18:13 +0000

Web Video Box Office

Canon 5D2 DSLR Time Lapse

Bouncing water droplets

Throwable Ball Panoramic Camera

Whale Fall: After life of a whale

TED Talk: How to spot a liar

Image Gallery

Nikon D300s travel’s to the edge of space

WebGL Terrain Simulation

Design that solves problems for the poor

Science

Computing

Bonus

Sleep Timing

CS Reality Check: Attitude

Shahriar — Sun, 16 Oct 2011 20:22:15 +0000

I see CS kids bragging about their major everyday. Quite often bragging turns into insulting other people’s intellect. I used to be okay with this when I was a student. But after joining the workforce I see it as a mental disease spread by the CMUQ CS culture.

If you want a CS job worthy of your CMU education, a job that does not require you to be a code monkey, you will need to learn how to be respectful towards other people. Cracking a joke that makes a BA student look dumb doesn’t make you smarter, it only shows how arrogant you are. In real life, you’ll have to work with these people at some level, and if you can’t make them appreciate your work, you will find yourself replaced with more capable people.

As for IS students, don’t treat them as a lesser version of yourselves. Remember, the CS degree is focused more on the theoretical aspect of computing. In the workplace, IS students will have a competitive edge with their practical knowledge and communication skills.

Even if you get a technical job, you will be surrounded by people who are much older and experienced than you. If you are lucky, people will ask what major you were in, but never which college you went to. You have nothing to be proud of. So, from the next time on, watch that attitude !

CS Reality Check: Courses

Shahriar — Tue, 11 Oct 2011 21:22:10 +0000

Freshmen often ask me what CS courses do we take in CMU. Sophomores and Juniors want to know which CS electives would help them in their senior thesis. Seniors want to know which courses are useful to get a job. To answer everybody’s questions I have a prepared a list of CS courses I have taken in CMU, a short description of each, and a rating indicating it’s real life value. Note that some of these courses may not be offered any more and the content of some might have changed.

Introduction to Programming (10/10)

Taught me object-oriented programming. Taught me Java, the language I use at work the most.

Intermediate Programming (10/10)

More Java, and lots and lots of data-structures: Trees, Hashes, Linked Lists. Once you get a grasp of programming this course will give you a toolbox to solve real world problems.

Concepts of Mathematics (4/10)

This course gives you a gentle introduction to the world of discrete mathematics and proofs. For some, this is the first real challenging course in CS. It’s not at all useful in real life, however, it does prepare you for upcoming disasters in discrete maths.

Data Structures & Algorithms (7/10)

Even more Java. At this point, it starts to get repetitive. Her you learn about exotic data structures which you will most likely never use in real life. The only reason this course gets a 6 is because of the various graph algorithms you will prove to be a useful addition to your toolbox.

Great Theoretical Ideas of Computer Science (10/10)

Rating this course is tricky. It doesn’t teach you something that you can directly use in real life. But GTI helps build character. It separates the curious CS enthusiast from the ones who are worthy of a CS degree. This course helps you build the stamina to solve difficult mathematical problems and write formal proofs to justify your solution.

Programming in C in Unix (10/10)

I am one of the lucky few who doesn’t work in a Microsoft dominated company. Our entire software architecture is Unix-based. Whatever Perl and shell scripting I learned in this class, I use it every day. On the other hand, programming in C made me a better man and prepared me to face Fortran which I often face at work.

Fundamental Principles of Programming (5/10)

Better known to CS students as “ML”, this course attempts to bend your mind by teaching you functional programming. It’s really fun, if you get it, otherwise you’ll feel that ML is just a twisted language. Not much real world application today. However, functional languages are coming back in fashion. So doesn’t hurt to have a taste of it in college.

Web Application Development (7/10)

This is one of those light-weight courses that doesn’t add to your workload, but gives you a lot to learn. You are introduced to the wonderful world of Ruby on Rails, the bread and butter of IS students. Regardless of whether you like developing web apps or not, writing code in Ruby will be a breeze of fresh air after Java, C and ML.

Introduction to Computer Systems (9/10)

This is the first serious CS course in CMU where you really get your hands dirty. You get down to the assembly level and learn the basics of compilers, computer architecture and memory management. For sure, you won’t need much of this directly in real life. But the realization that “there is no magic inside the box” will help you understand performance bottlenecks of even the most complex systems.

Algorithm Design & Analysis (6/10)

This is the grand-daddy of all discrete math courses. While it’s not as mind-bending as its pre-requisite GTI, it’s still teaches you some useful stuff. Understanding how to determine the time and memory complexity of algorithms will help you design better applications. In a company where a lot of applications build on your work, demonstrating a sound knowledge of algorithm design will raise a lot of eyebrows

Algebraic Structures (0/10)

Really abstract mathematics. Simply pointless.

Formal Languages & Automata (3/10)

This is a course I really enjoyed, even though there is a lot of talk about abstract computational devices. Here you get to learn about regular languages, context free grammars, Turing machines etc. Nothing terribly practical, but very insightful nonetheless.

Foundation of Programming Languages (0/10)

More ML, but this time with a focus on formal analysis of programming languages. You get to write your own toy programming language every week. Sounds fun but terribly dry and useless.

Technical Communication for Computer Scientists (0/10)

This course has the potential to be a useful course. There is a variety of technical documents that a CS professional need to author on a regular basis, (e.g. Technical Design Document, Functional Specifications, Technical Requirements Document, Programmer’s Guide etc.) This course teaches none of them. I will write more about this point in a future article. CMU really needs to improve the content and instructors of this course.

Software Engineering (2/10)

Another course that had the potential to be very useful. But I guess there is no way to make students without industry experience appreciate the impact of good architecture and design. If I could go back to CMU and take any course, it would be this one. Any how, software engineering skills is what helps you climb up the corporate ladder and takes you from a code monkey to a software architect.

Computer Networks (8/10)

Another heavy duty programming course in C. A lot of new material. You learn networking from its dirty low levels of sending individual bits, error correction, collision detection & avoidance, routing, queuing, Ipv4, Ipv6, TCP/IP, and even some application level network protocols. The programming assignments are pretty demanding. You get to read the technical specification of the IRC protocol and build your own IRC server. You even get to write your bit-torrent client in the last assignment. The networking stuff isn’t that useful to me as a programmer. However, as a distributed systems programmer, the code from the assignments are a useful reference for me.