Have you heard of mastermind? It’s a logic game in which one player repeatedly tries determine the secret code that another player set at the beginning. With each guess, the player is given information on how many correct pegs his guess contains, and how many are in the correct position. For more details on the rules, check the wikipedia article.

I built a Clojure implementation of Mastermind as a learning project. (Code and details of functionality at github.) My primary goals were to gain familiarity with the language, and to see what the functional programming paradigm feels like when working on a project that is larger than one big function. After I finished, I re-implemented (almost) all of the features in Java for a comparison. (Code also available at github.) Interested in the results? read on.

Some numbers

Lines of code: Clojure 140, Java 450
Source code files: Clojure 5, Java 11

But it’s really worse than that. I didn’t implement a few features in Java, which code have amounted to another hundred lines. And about 10% of the lines in Clojure were comments, but I didn’t add any comments to the Java code. So I don’t think that it’s unreasonable to expect four times as many lines of code in Java compared to Clojure.

Semantics

Suppose you need to compare two lists, and count the number of pegs that are the same, and in the same place. This is necessary to determine the number of colored pegs given in response to a guess in Mastermind. Here’s how you do it in Java:

private static int exactMatches(List<Pre> guess, List<Pre> actual) {
    int matches = 0;
    for (int idx = 0; idx < actual.size(); idx++) {
        if (actual.get(idx) ==  guess.get(idx)) {
            matches++;
        }
    }
    return matches;
}

Not too bad, right? Just a loop, with a conditional that increments a counter. But notice that since we are comparing two lists, it is necessary to use the indices. That doesn’t seem like a big deal, because it is common, but understand that this question being asked has nothing to do with indices. Let’s compare this with the Clojure implementation.

(defn exact-matches [guess actual]
  (count (filter true? (map = guess actual))))

In my mind at least, this function is not only more succinct, but far closer to my mental model of what is happening. There is no counter, only a count function. There is no loop containing a conditional, rather a filter function that takes a function and a sequence. For the comparison, map applies the equals function successively to each of the items in the two sequences, producing a boolean sequence. Feel free to browse the code for more Java/Clojure comparisons.

Performance

Unfortunately, Java clearly won regarding performance. I’m not going to include any numbers here, because benchmarking should be done with simpler algorithms, where it is more obviously a fair comparison. Nevertheless, I won’t be recommending Clojure for any performance intensive applications soon.

Conclusion

For algorithmic problems, the flexibility and functional semantics are a huge win for Clojure. The performance is a negative. I didn’t miss Java’s static typing either, but that’s unfair, given how small this project was. As for objects, I haven’t missed them so far, and I’m loving the ease of use of Clojure collections. Time for another Clojure project, this time something that makes use of Clojure’s concurrency language features.

Using a textbook or a technical book is like using a highway: To get where you want to go, you need to find the right exit. The end isn’t a real goal, and it likely isn’t that interesting, anyway.

How do you know when to exit? Know where you want to go. If your goals are very specific, this is trivial, and you can use the book as a reference, rather than reading. But if you are learning completely new technologies or concepts, it is sometimes hard to know where exactly you hope to go, but I find the following techniques useful:

• Read from a combination of sources: one or two books, along with tutorials and blog posts.
• Combine the book learning with a toy project.
• Pay attention to your progress — finding the material too difficult could be an indication that this isn’t what you most need to learn right now, or that it is poorly written.
• Talk (you know, face-to-face) with others that have similar goals

If you start with a goal, and continue to adjust your course appropriately, you make much progress with books, they will often take you within miles of your destination. But if you confuse the books with the goal, you can go the entire length of I-95 without seeing anything more interesting than some roadside attractions.

But there’s another important part of the job-seeking process. The career services all tell you that networking is important, that you should “network” with professionals in your field, and develop those all-important contacts that lead to interviews and jobs. I’d guess that 90% of aspiring programmers make no effort to build a professional network before graduation, and that 90% of those that do try are completely ineffective. After all, if you enjoyed talking to strangers and building relationships, you wouldn’t be a computer science major, right?

Building a professional networking is actually not that difficult, it just looks very different from your imagination. 

Why networking is actually fun

Professional networking amounts to building relationships with people that share your geeky interests. This isn’t AmWay here, this is talking about programming, software, languages, frameworks, and platforms! But how to begin?

Start with the people you already know

Do you know anyone that hires software developers and system engineers? Great! But most of you don’t. But you might know someone that knows such a person. And if you don’t, you surely know someone that knows someone that knows a hiring manager. So work through your network. Do your parents have friends in technology? Do your friends have parents in technology? Any relatives, or acquaintances from church that could help?

Don’t be too picky. Don’t imagine that you need to be connected to a engineer or a manager. Maybe your mom’s cousin works as a receptionist at tech company. Or maybe your neighbor is the maintenance man for an office building that houses several start-ups.

Start meeting people in the industry

Contact your mom’s cousin, and tell her what you are doing. Ask her for the name of an engineer that might be willing to meet with you. Make it clear that you are not asking for a job, just a chance to talk about what sort of work he does, what the company and industry are like, and what sort of things they look for in students coming out of college.

Participate in user groups and conferences

Find out what technology user groups are in your area, and pick one or two to attend regularly. Make sure to spend time every month working with the technologies, so that you have questions to ask. Bring your laptop, and be ready to open it up and ask questions about your code. Volunteering to help with the work of the group, whether giving a five minute talk or manning a registration table, can help to establish you as part of the community.

Don’t be boring

When you get an opportunity to talk with a programmer, keep the conversation on things he is interested in. Hopefully, he is interested in programming, technologies, software development, etc, so focus on these things. Ask him what he does specifically, and then keep asking him to dumb it down until you are learning something. If you don’t get to the point of understanding something of what he actually does, this will be rightly perceived as a lack of interest.

Remember that most people find themselves far more interesting than they find you, so don’t talk about yourself any more than necessary. If you want to ask questions about your future path, express them in terms of his experience: “What do you wish you knew when you were a sophomore in college?” If you want to talk about projects you have done, ask for his insight on how they can be improved.

Avoid asking for a job.

At some point, you will need to ask for a job, but put that off for as long as possible. Asking too early will establish you as a job-seeker in their mind. No one wants to hire the guy that wants to be given a job, we are looking for the guy that wants to do a job. So make sure your eagerness to do work is understood before you talk about positions or resumes.

Think long term

This is not a project to begin your senior year. And it doesn’t end when you get your first job. You should start building your network when you decide on your future profession, and you should work to maintain it until you retire. If you have waited to long, start now, but think towards your second job, don’t let your fear of unemployment stunt the growth of your network.

Some technical interviews obvious successes, and many others are obvious failures. But there are many that are muddled and hard to interpret, often in ways that were preventable. Read on for my thoughts on how you can make the best of the technical interview.

Know what is on your resume

As you prepare for the interview, look at the most prominent items on your resume, and brush up on the details. You can’t be prepared for every question, but you can study like you would for a test. Not sure what to study? Start by pretending you are an interviewer, and coming up with a list of questions that would fit with your resume. Search for interview questions, and make sure you understand the answers. Ask your professional contacts and colleagues to interview you and to give an honest evaluation of your answers.

Be prepared to code

There is no shortage of programming problems on the internet. Start practicing. Can you implement merge-sort in every language on your resume? Why not? We will want to see that solving problems with code is something that is natural for you. Looking up a few things is okay, but I should be convinced that you work in this language, and are comfortable with it.

Do you like to code in Eclipse or Visual Studio? Maybe you should practice coding in more primitive environments. Write Java in Notepad++. Or on paper. When it comes time for a coding exercise in the interview, you should be eager to show that you can code, and that you don’t care whether it is on the whiteboard, or in nano, or with a magnetized needle.

Expect far less than perfection

If you draw a blank on the first three questions on your math final, things are very unlikely to end well. Interviews are very different. Sometimes the first five questions accomplish nothing more than establishing what types of questions I should be asking you. Similarly, while I have had students get perfect scores on exams that I have given, I hope to never finish a technical interview without asking a decent number of questions that the candidate cannot answer. I won’t understand the limits of your knowledge otherwise.

So don’t get rattled when you miss a question. Don’t be offended if you feel the question was unreasonable, and you don’t really need to remind me that you know how to use Google. A simple “I don’t know” is often the least painful way to move on to the next question.

Don’t bluff

One of the worst interview strategies is guessing. I don’t expect you to know everything, but I expect you to know what you know. I can’t expect you to solve problems effectively if you aren’t sure what you actually know, and what you only suspect. So answer confidently when you know. If you don’t know, it can be helpful to talk out what you suspect and to give a reason. But don’t bluff. It will make you appear both incompetent and dishonest.

Make the most of what you know

When I ask about something you know well, show me. Answer the question confidently and completely, and volunteer important related information. Tell me about what can go wrong with a lack of understanding of this issue. Show me the enthusiasm that I expect when I ask a colleague for help in his area of expertise … and the discernment that knows when you’ve said enough.

You will be most remembered for your best moments and your worst moments of the interview. A really good answer to one question can make up for quite a few blank spots. Did we fail to ask about your specialty? Feel free to volunteer information.

Be useful

Interviewing tips are just the finishing touches. Your career will depend on how consistently you are able to do useful work. So focus on improving your skills and understanding how your skills bring value to your business. If you do this, then it will be easy and enjoyable to show what you have to offer in an interview.

Before long, you find that in a different situation, you want to pass a different function, so you make an interface, another class, and make both classes extend the interface. Now the two functions that would have logically fit in some already existing file have generated three source files.

Does it have to be this way? It’s a lesser known fact that in Python, everything is an object. A function is an object, a class is an object, a module is an object. But somehow, a commitment to everything being an object didn’t lead Guido to conclude that everything should have it’s own class file. Somehow “Everything Is An Object” doesn’t imply (in Python or Ruby) that functions must be defined in classes.

I’ve been using Spring with Java, and that is certainly preferable to me than Java without Spring, for medium or large projects. But it strikes me that much of what Spring helps me manage is the simple fact that I need many functions available in situations where I don’t want to instantiate an object first. When I use Spring to inject a singleton object, often what I really want is a handful of related, stateless functions. I would guess that about well over half of the classes in my projects are essentially one of two things: glorified namespaces or data types without behavior.

More to the point, as I build complex applications, I fear that building them in Java significantly adds to the complexity. I fear that I’m building in a way that requires some acclimation to a handful of patterns and a framework that ultimately shift the complexity of the problem to a different sort of complexity. It seems that this is the best that the Java world allows: familiar patterns of complexity.

So what’s a Java developer to do? Where to go from here? It’s time to learn another JVM language. Despite the abundance of JVM languages (Groovy, JRuby, Jython), only Scala and Clojure offer hope of reasonable performance. I was close to investing in Scala. It’s very flexible, far less verbose less verbose than Java, and it’s fast.  It has a much more sophisticated type system than Java, and has great support for concurrency. But I balked at Scala’s complexity. It’s type system is a bit much for the real world, and I worry about the multi-paradigm approach, allowing for object-oriented, proceedural, and functional programming.

If not Scala, then what? The only other option that looks like a potential path forward is Clojure. I’ve toyed with Scheme in the past long enough to get the hang of writing functions that end with a bunch of right-parens, but never long enough to understand what a substantial program would look like. I’m ready to give Clojure a real shot. I plan on spending at least a year with the language, trying to get to a real understanding of Clojure, Lisp, and the functional paradigm.

I’ve resisted the functional programming crowd for a few years. I haven’t been convinced that it is practical in the real world. I spent some time learning Haskell, and it reinforced that notion. I found it extremely enjoyable to write mathematical functions, solving a number of Project Euler problems in Haskell. But when your language requires the concept of a monad in order to do simple IO, then you have taken a wrong turn.

I’m hoping that I’ll find Clojure more pragmatic. In the end, I may find the kingdom of verbs is no better for building large complex systems. But even if I settle on Scala, Groovy, or another mult-paradigm approach in the long term, I expect that I need to immerse myself in the functional world first.

If you are interested in machine learning at all, I think that a Naive Bayes classifier is a really good place to start, especially if you have half a semester’s understanding of probability.

Set up my router to allow remote ssh access.

This didn’t seem so important in development. But on the day that I realized while driving to work that I needed to manually run the batch job (due to an error I introduced in crontab), remote access seemed more important. And the day that I discovered a potential error as I was trying to leave town with my family for the weekend, I realized that remote access was completely essential, for any application in production.

Set up good logging:

For the batch job, it was obvious that logging was essential. But for the web app, I left it out. After all, when things didn’t work, I could always look at the console output. But as I considered advertising my modest web application to others that might find it useful, I realized that I would really like to know how frequently my application was being used, and by how many people.

Prepare to recover from errors:

During one of the first runs of my batch script an error occurred that left my application in an intermediate state. Fixing the error in the code and re-running the job wasn’t sufficient, since the database had changed. I needed to write an ad-hoc re-run script to finish the job correctly. Of course, since it is my production database that has this problem, I found myself testing that re-run script in production.

The common theme:

There are some other little things, but you get the point. So what went wrong? Is “Do The Simplest Thing That Could Possibly Work” bad advice? Or am I just really bad at determining what can work?

I think that it’s easy for developers to grab that mantra and do the simplest thing that could possibly work — in development. Some simple things that can work in development, simply can’t work in production. It’s an easy trap, because developers live in (where else?) development, where certain types of production issues never arise.

I still plan to do the simplest thing that could possibly work. First in development, and then in production … and both before initial deployment. And as I gain experience, I’m sure that my view of what “can work” will grow to the point where such mantras are in fact useful, and not merely a seductive trap.

Lisp

At some point in your computer science education you were probably exposed to Lisp. Perhaps you worked through part of the SICP book, or maybe The Little Schemer. If not, I highly recommend the latter.

But most of us get tired of Lisp. Even though it has been used very effectively in cases, it feels like a trick, an academic ploy to unsettle our previous convictions about programming languages.

Haskell

If you are still interested in functional languages, you are likely to try Haskell next. (Probably starting with Learn You A Haskell.) Haskell has enough syntax to feel like a real language, and if (like me) you have a background in mathematics, it is loads of fun. I spent some time working Project Euler problems in Haskell (here), and it felt like cheating. Once a problem is solved mathematically, it isn’t much trouble to translate it to Haskell.

Haskell isn’t just for mathematics, of course. It is a great place to learn to think functionally, and to gain comfort with recursion and functional concepts like map, filter, and fold.

But Haskell wore me out in the end. The quest for functional purity has lead Haskell to an impractical place, which was never more clear to me than the day that I spent several hours studying monads so that I could read from a text file. It was that day that I was convinced that Haskell would never be relevant in industry.

Erlang

Recently I started learning Erlang on a whim, using Learn You Some Erlang. It’s my favorite so far. It’s not painful to read, like Lisp. And I don’t have to worry about types and monads, like in Haskell. You are required to think functionally, as you cannot change the state of a variable … but Erlang doesn’t worry about purity, which is refreshing.

Erlang is clearly not my first functional language, but I think that it would be an excellent choice as such. It lacks the most intimidating aspects of Lisp and Haskell, but without allowing for procedural code. And as a bonus, Erlang has some sort of super-awesome concurrency model that is extremely parallelizable. I don’t know anything about this yet, but I’m looking forward to learning about it.

But when the page that I was scraping changed format, there was no joy in figuring out what to change to get the updates working accurately. I’ve got other fun and worthwhile things to do, both in programming, and in real life.

So thanks much to the 200+ folks that found @py3k_update worth following, I hope that you appreciated what it did provide, and aren’t too disappointed to see its demise.

But the post bothered me. I don’t just enjoy programming, I enjoy teaching young people to program, and I have often told technically minded young men that it is essential that they learn programming skills. I also enjoy advanced mathematics, and I have very much enjoyed teaching calculus, linear algebra, probability, abstract algebra, and topology. Math is more fun for me than programming, but somehow …I don’t encourage bright young men to pursue mathematics. Moreover, since leaving academia, I haven’t looked for any opportunities to teach mathematics outside of my family. I do look for opportunities to teach programming, as I think it is an extremely useful skill, both for the professional opportunities, and for use in other technical vocations.

So Jeff is correct in that the notion that everyone should code is absurd. But let’s forget about “everyone” and ask ourselves what we should teach those bright young men that want to solve technical problems. Currently we teach them Algebra, Geometry, Trigonometry, Calculus, Biology, Chemistry, and Physics. For those of you that solve technical problems for a living, which is more valuable: coding skills or derivatives and integrals?

I don’t think I need to look up the numbers to convince you that far more men pay their bills with programming skills than with mathematics expertise. From my personal experience, as I was changing vocations from academia to software development, there was never a time that someone suggested that my calculus skills would be useful for a particular type of job. Moreover, I don’t know of anyone that regularly uses higher mathematics in work outside of academia without also using programming skills.

Programming isn’t for everyone. But is far more practically useful than Calculus, while still providing the benefits of exercising logical thinking skills. As one that loves mathematics more than code, but cares even more about training our young men effectively, it is time for programming to have a real place in the high school and college math/science curriculum.