Functional Practice: Euler Problem #1

I've learned about Euler problems quite a while back. If you're not familiar with them, you can check out Project Euler.

These are very mathematically focused problems, and I was thinking about using them as practice problems for C#. Many people have done that; here's one example: http://www.mathblog.dk/project-euler-solutions/.

When I was looking at the problems, though, I always felt that my C# solutions would be a bit of a mess -- lots of if/else, while, switch, and so on. The solution is not functional or elegant (which always makes me think of this song).

But these seem like a great place to start using functional programming. Since I'm learning functional programming with Haskell, that's the language I'll use for my solutions.

Now, I'm not going to blog about all of the Euler problems (there are a lot of solutions out there). I'm just going to go over my thinking to solve the first problem. This will show how learning about functional programming will let you start to think a bit differently if you come from the OO world.

Euler Problem #1
Here's the first problem:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.

This doesn't sound that hard. We'll start by trying to replicate the sample: the natural numbers below 10.

Thinking Functionally
What I found myself doing immediately was breaking this problem down into different parts. We need the natural numbers below a certain value. We need to find the ones that are multiples of 3. We need to find the ones that are multiples of 5. We need to sum things up.

This is a great place to use a list in Haskell.

First, let's get a list of all the natural numbers less than 10. We'll use a list comprehension with a range:

[x | x <- [1..9]]

And here's the output

[1,2,3,4,5,6,7,8,9]

That's a good start.  Now we need to filter things a bit. Let's add the modulo function (mod) to get the values evenly divisible by 3:

[x | x <- [1..9], mod x 3 == 0]

 The "mod" function takes 2 parameters. This may look a little strange, so we'll change this to use infix notation by using a backtick around the function name:

[x | x <- [1..9], x `mod` 3 == 0]

This seems a little less strange. And here's the output:

[3,6,9]

And since we want multiples of 5 along with multiples of 3, we can "or" these together with "||". Here's how that looks:

[x | x <- [1..9], x `mod` 3 == 0 || x `mod` 5 == 0]

And here's the output:

[3,5,6,9]

Success! This matches the list from the sample. Now we just have to sum these numbers. Fortunately, we can just pass a list to the "sum" function.

sum [x | x <- [1..9], x `mod` 3 == 0 || x `mod` 5 == 0]

And the output:

23

This matches the sample case. Now we just need to swap out the "below 10" for "below 1000":

sum [x | x <- [1..999], x `mod` 3 == 0 || x `mod` 5 == 0]

And the answer:

233168

Note: I've verified this is correct by looking at the answer to Euler Problem #1.

Making a Reusable Function
The last thing that I want to do is create a reusable function. (I'm not really sure what use I would have for this, but anyway...) So, let's parameterize this with the "below this number" value (ignore any line breaks you might see).

euler1 belowThis = sum [x | x <- [1..(belowThis-1)], x `mod` 3 == 0 || x `mod` 5 == 0]

Basically, we created a named function "euler1" with a parameter for our "belowThis" number. Since ranges are inclusive, we subtract one from the value before creating our original list.

Now we can use this function with the sample:

euler1 10
23

Or with the target value:

euler1 1000
233168

That's pretty cool.

To create this function, we just started with the inside and worked our way out. And this is a big difference between thinking functionally and thinking procedurally. If I were to try this with C#, I would probably just "brute force" it. You can see an example of that here: http://www.mathblog.dk/project-euler-problem-1/.

But instead, we have something functional and elegant. And also a good way to stretch a bit to learn functional programming. And I'm already starting to see how I can use these techniques to make my everyday programming (in C#) much better.

I'll leave the rest of the Euler Problems as an exercise for the reader.

Happy Coding!

Shameless Promotion

Three of my Pluralsight courses are currently in the Top 100 as of 10/28/2013 (subject to change):

(I guess there's not much love for the BackgroundWorker Component.) You can see all of my courses in one spot on my author page.

I have more courses coming. If you have topics you'd like to see me cover, feel free to leave a comment. As mentioned before, the topics I select are based on several factors including (1) whether I know anything about the topic (this one is kind of important) and (2) whether Pluralsight already has a course covering the topic.

Pluralsight has over 1,000 courses with a ton of great content. Check the Course Library for some really good resources.

Happy Coding!

Unblocking Downloaded Visual Studio Projects

As a developer, I download sample projects quite frequently. Usually, when opening these projects, Visual Studio will give the following warning:

Now, we can simply click the "OK" button here. But there may be other problems. This is especially true if the solution includes compiled DLLs. These files may be blocked by Windows since they were downloaded from the internet.

Unblocking Files
The easiest solution is to unblock the files before opening the solution in Visual Studio. Here are the steps:

1. Locate the original ZIP file that you downloaded from the internet.
2. Right-click on the ZIP file and choose "Properties".
3. At the bottom, you may see a "Security" section that says "This file came from another computer and might be blocked to help protect this computer."
   
   
   
4. Click the "Unblock" button.
5. Unzip the files and open the solution in Visual Studio.
6. Before opening any specific project, go to the "Build" menu item and select "Rebuild Solution".

This usually takes care of the problems. (And, of course, only do this with files that come from a trustworthy source.)

Happy Coding!

New Pluralsight Course: Dependency Injection On-Ramp

My latest course is now available on Pluralsight: Dependency Injection On-Ramp.

Dependency Injection On-Ramp

What is Dependency Injection? The answers to the question seem to cause more confusion than help. This course will get us started on the road to understanding. We'll take an example-based approach to see the problems caused by tightly-coupled code. We'll add Dependency Injection to trade that tight-coupling for loose-coupling. And that loose-coupling makes our applications much easier to extend, maintain, and test. Finally, we'll see how Dependency Injection Containers can provide benefits that would be difficult to implement ourselves. This just scratches the surface. Once we're done, we'll be ready to start our journey on the Dependency Injection superhighway.

I've really enjoyed presenting on Dependency Injection over the last year -- I've given my live presentation 12 times since October 2012.

One of the reasons I really like this topic is because I've found it extremely useful in my own development. It took me a while to get the hang of it and to see the usefulness. But once it clicked (the "a-ha" moment (no, not that "a-ha" moment (but that's a good one, too (I miss the '80s)))), it's hard to imagine building complex applications any other way.

My goal is to give a short-cut to that "a-ha" moment. We can't cover everything we need to know about Dependency Injection in such a short time, but we can get a good understanding of the basic concepts and, more importantly, see real code that shows why we may want to use it in our own applications.

This may be my best course yet. Check it out and let me know what you think.

Happy Coding!

A Foo Bar Example I Actually Like

I really, really dislike "foo bar" examples. You can read about my worst foo bar experience here: Session Spotlight: IEnumerable, ISaveable, IDontGetIt.

There's 2 primary reason for this. First, I like real-world examples -- something that I can hold on to. "Foo" doesn't mean anything (that's why it's used), so I have a difficult time relating. The second reason is that "foo bar" makes me think of FUBAR (which may actually be appropriate).

Higher Order Functions
As recently noted, I'm learning functional programming with Haskell. It is a different way of thinking, and I'm starting to get the hang of it. I'm reading about higher order functions right now.

A higher order function is a function that takes another function as a parameter. To relate this to the C# world, this is similar to passing a predicate/delegate/lambda as a parameter to a method (like a LINQ method such as "Where"). But this seems more natural in a functional language.

Here's the function that we need: zipWith':

The scary thing is that I actually understand this. It uses a combination of a higher order function, recursion, pattern matching, and list heads/tails.

Rather than explain this line by line, let's look at an example of using this method:

This shows a call to zipWith that has the "+" function as the first parameter, then we have 2 lists of integers. This method will apply the function to the items of each list. So, it will add ("+") the first item of the first list ("1") to the first item of the second list ("4"). Then it will add the second items of each list, and so on.

Here's the output:

This is a list consisting of 1+4, 2+5, and 3+6. The 7 at the end of the second list is ignored since there is no corresponding item in the first list.

Foo Bar Baz
So, you've made it this far. Here's the foo bar example:

This has a different function: ++. This will concatenate 2 lists together. Since strings are lists of characters, this will concatenate the strings from the first list with the strings from the second list.

Here's the output:

The sin of using a foo bar example has been forgiven.

Happy Coding!

How Do I Change Someone Else's Code?

I had an interesting question come up at my Clean Code session at Silicon Valley Code Camp:

How do I change someone else's code?

This question came up as we were talking about refactoring code to improve the readability. And the question was not coming from the technical standpoint, it was coming from the interpersonal standpoint. So, the question could really be stated several different ways:

How do I deal with a developer who is possessive about the changes made to "his" (or "her") code?

How do I tell a developer that his/her code could be more readable?

Let's start with the first question.

Code Ownership
If people are possessive of "their" code in the codebase, this is a sign of a larger issue.

Note: I'm approaching this from a standpoint of developers on a team working for a company just so we have an idea of the environment. But this applies to other types of teams as well.

Our focus really should be on the business -- how the applications we build move the business forward. And the most productive environments I've worked in have this mindset.

In the agile world (and I'm reluctant to use that word since a lot of people who are "Agile" really aren't), everyone on the team is responsible for the code. If someone sees a problem in an application, he is empowered to fix it (or alert someone about it if he is not capable of fixing it himself) -- and arguably, he would be irresponsible to not do anything about it.

So, if you find yourself in a situation where you can't touch a certain module because "that's Jim's code", it might be time to bring in someone to help with the dynamics of the team.

We don't always have control over the team, but we do have control over ourselves. If you find that you're offended that someone changed "your" code, then it's time to take a step back and re-evaluate your own attitude.

Controlling the Ego
Developers are known for having large egos. This really isn't surprising because at its heart, development is more of a creative process than a technical process. The last thing that an artist wants to hear is that you think his painting is ugly. Developers generally react the same way.

But we need to take a step back and look at what we're really doing: we are building tools that propel a business forward. And we don't even own the code we write (from a legal standpoint), the company owns it. This means that the company can do whatever it wants with the code, including rewriting it, breaking it, using it incorrectly, or even never using it at all. So, we cannot get personally attached to any particular function that we create.

I won't say that this is an easy thing to do as a developer. I put a lot of thought and effort into the software that I write. When I see that it is not being used or being used improperly, it really annoys me. But then I take a step back. In my experience, there is very little benefit that comes out getting worked up over these things. I voice my opinion and then let it go (sometimes more successfully than others).

Learn from Other Developers
The same holds true if another developer makes changes to code that you originally wrote. Instead of having a kneejerk reaction, understand that the other developer is not calling your painting ugly. He (hopefully) has the same goal that we all do, to propel the business forward.

So, stop and look at the changes that were made. If you think they are good, learn from them. If you think they are bad, talk to the other developer. Communication goes a very long way in the development world. We don't always approach problems the same way (actually, we probably never approach problems the same way). It's good to understand what someone else is thinking. I've used this several times as a learning experience. And sometimes by working together, we come up with something that neither one would have come up with separately.

It's All in the Approach
So, now let's deal with the second question: How do I tell a developer that his/her code could be more readable?

A great way to approach this is to ask the developer to explain the code. "Hey, Jim, I'm having a little trouble understanding this block of code. Could you help me out?"

If he asks why you're looking at "his" code, tell him that you're just trying to get a better understanding of the system overall.

This may or may not work. It all depends on the other developer. We don't have any control over how other developers react. Just remember to keep your own reactions in check.

If he does explain the code, then you can offer some suggestions to make it more clear to someone just walking up to the code for the first time. Hopefully, you'll be able to work together on making the code better.

Sometimes We're Stuck
If we are part of a dysfunctional development team, sometimes there's nothing we can directly do about it.

But there is a big difference between being *on* a dysfunctional team and being *part of* a dysfunctional team. It is very easy to be overwhelmed by the things going on around you and let them affect you. I've had that experience. I let the problems of a team I was working with get the better of me, and it affected my attitude. I was lucky enough to have someone point this out to me, so I was able to readjust how I was reacting to things.

Attitude is Infectious
Just like a negative attitude is infectious, so is a positive attitude. We can't control others, but we can control ourselves. I've found that if I take a certain attitude toward development (focusing on the business, checking my ego, constant learning), it rubs off on other members of the team.

We *can* change the attitudes on our team. It starts with us re-evaluating our own attitudes. From there, we set a good example, pump out some excellent code, and focus on the goal. Others will want to follow. (And if that doesn't work, polish up the resume. If this is your approach to development, I want to work with you.)

Happy Coding!

Functional Programming with Haskell

So, I've been dancing around learning a functional language for a while. And although most of the people I know would like me to learn F#, I've decided to start with Haskell (sorry, Mathias).

So, I started reading Learn You a Haskell for Great Good! by Miran Lipovača (Amazon link).

Why Functional Programming?
I've heard from several folks that it's a really good idea to try to learn one new programming language a year. The goal isn't to make the language our "main" language but just to become competent with it and understand how it works.

A further recommendation is to learn a language that uses a different paradigm. For example, if we are C# developers (an imperative OO language), then learning Java (another imperative OO language) won't do us that much good. But if we pick up a functional language, it will force us to start thinking about problems differently.

And the programming techniques that we learn can help us in our "main" language. C# started as an OO language, but it's evolved into an all-purpose language and has many functional elements (delegates, lambdas, LINQ, etc.). When learning these functional elements, we don't usually approach them from a purely functional standpoint.

My hope is that by learning a purely functional language, I'll have a better grasp on the idioms and techniques of functional programming, and that will make me more effective as a C# developer.

Why Haskell?
Why did I choose Haskell over F#? Well, there are 2 reasons.

First, I already had the Haskell book. It's been in my heap for a long time (according to Amazon, I've had this book since April 2011).

Second, I wanted to break away from the .NET framework. I am concerned that if I started with F#, I would get wrapped up in things like "What IL does this generate?" and "How does this F# library integrate with a C# application?" As a first step, I want to focus on the functional paradigms.

I fully expect that I will take these learnings into the F# world. And after reading just a couple of chapters, I've picked up a few good things. I got a good head start at the Silicon Valley Code Camp by attending Mathias Brandewinder's "F# for the C# Developer" (Code Camp link). And the concepts of tuples and implicit typing now make a lot of sense.

More to Come
Stay tuned for more functional stuff. I'm already starting to see the coolness around immutability and "no side effects." And the idea that a function *must* return something seems strange to a C# developer at first, but it makes total sense when functions are the primary objects that we're dealing with. I'm looking forward to diving deeper into the concepts of composing functions. And near the end of the book, there are chapters on monoids and monads. That should be interesting since I have no idea what those are.

I'm looking forward to stretching the way that I think about programming.

Happy Coding!