Immutable objects

Immutables are very interesting. The problems that immutables address is often neglected. These problems tend to surface later in the development process, when the project is becoming more complex.

Eric Lippert shed some light on this complex subject in a very interesting blog series. Immutability in C# Part One: Kinds of Immutability

Coding management

I had a discussion at work today with a project manager. She used to be a programmer back in the days and she shows both insight and interest in code related issues. Not to mention stubborn until proven wrong (no offence, you know who you are and you may see this post as a follow up on the subject). We had several in depth talks about different subjects in programming philosophy but the one that I want to bring back to surface is the one about coding conventions and project rules.

She told me about a successful project where all programmers got together and decided that they were going to follow a pretty simple convention of how to declare functions and subroutines (this was VB 6 I may say). Everything with informative texts that short and concise should inform anyone reading or calling this particular code what it actually does. Also the most important thing was that the writer was indeed responsible of releasing any allocated resources before return.

The reason that we end up in this discussion was the subject of scrum, which encourage programmers to be creative. Let’s face it, all projects have a couple of kick ass coders, some great coders that are eager to learn from the ass kickers and some coders that destroy the project for the others. Creative destroying programmers can be a mess.

This project was no exception. There was this one guy who didn’t care about documenting, and worst of all, he seldom released any allocated resources. This one guy made the whole project limp, and the moral sank, making all the great programmers unhappy and unproductive.
Now why am I telling this story? Could this problem be solved peacefully? I boldly states that the problem should never exist. It’s all up to the system architect and his/her choices of technology. Let’s analyze these two problems.

The matter of unreleased resources is of course a product of stateful programming (also known as imperative programming). If the environment that these programmers were working in was based on the principles of functional programming, the resources would be released automatically when returning from a function or procedure. They could be more careless with their code, and as a result more productive.

Second the matter of documenting the functions and subroutines. We all know from experience, few programming languages require a couple of informative lines of documentation prior to any major declaration. So how do we ensure that they are there? Eiffel successfully turned documentation into a major advantage to the programmers with their Design by Contract (DbC) principle. Also there are of course other positive side effects when using DbC. Eiffel and its killer DbC is a huge subject so I drop that for now. However using DbC, the compiler can force the programmer to follow the documentation rules.

Let’s get back to the story. In the end they had to let the bad programmer go because the rest of the team was more productive without him. Before you chuckle to yourself about how you dismiss bad code and their creators, you should take a good look in the mirror and ask if you really write such great code yourself. I know, only by looking at code that I wrote an hour ago that I sometimes write totally fucked up code. The reasons may vary, you may be new to programming or you may be tired or you may be in a hurry to deliver for a deadline. Or maybe you just have a hard time to grasp the concepts. It takes time for some programmers to understand the value of good code.

There are a lot of reasons why some programmers write bad code. What I am trying to point out is that you can reduce the bad code, using the right language and environment in the right place. It’s sad that the choice of language and environment is seldom a choice made by someone who understands the production cycle and the impact the wrong tools has on it. But then again, that person could probably not choose the programmers for the task either.

Template metaprogramming

Following up on the subject regarding my last post Generics, another type of metaprogramming I found a interesting Wikipedia article Template metaprogramming. Quoting (as I usually do);

“Template metaprogramming is a metaprogramming technique in which templates are used by a compiler to generate temporary source code, which is merged by the compiler with the rest of the source code and then compiled. The output of these templates include compile-time constants, data structures, and complete functions. The use of templates can be thought of as compile-time execution. The technique is used by a number of languages, the most well-known being C++, but also D, Eiffel, Haskell, ML and XL.”

The article makes it very clear that Templates is a compile time metaprogramming technique. This is something that I have pointed out in my earlier posts about metaprogramming aswell. Also the article compares Templates with Macros but points out that Macros is type unaware whilst Templates is aware of the types in the native language. All this with the exception of Lisp since Lisp Macro language is Lisp itself.

“Some common reasons to use templates is to implement generic programming (avoiding sections of code which are similar except for some minor variations) or to perform automatic compile-time optimization such as doing something once at compile time rather than every time the program is run, for instance having the compiler unroll loops which would otherwise not be.”

Reading this I am thinking, so I can use templates on other stuff than as a placeholder for a unknown type. And truly spoken, only a couple of lines further reading gives me a sweet example of how to use the compiler to pre calculate the factorial value of any given constant. This gives me a whole new view of Templates and what can be accomplished with them. The article goes on and describes another couple of interesting usage patterns for Templates.

Well worth reading!

Generics, another type of metaprogramming

This is probably obvious for most of you, but since I didn’t realize it until now, I will bring it to your attention. This C++ tutorial about templates http://www.cplusplus.com/doc/tutorial/templates.html points out that templates is compiled on demand. Close to the end of the article it states;

“From the point of view of the compiler, templates are not normal functions or classes. They are compiled on demand, meaning that the code of a template function is not compiled until an instantiation with specific template arguments is required. At that moment, when an instantiation is required, the compiler generates a function specifically for those arguments from the template.”

So what you do when you build templates in C++ is utilizing the metaprogramming paradigm in compile time. Now, referring to one of my earlier posts called Metaprogramming, I quote Wikipedia who states;

“Not all metaprogramming involves generative programming. If programs are modifiable at runtime (such as in Lisp, Python, Smalltalk, Ruby, PHP, Perl, and Tcl), then techniques can be used to perform metaprogramming without actually generating source code.”

I realize that the languages spoken of in the Wikipedia may perform other types of runtime metaprogramming, also any or none of these languages may or may not utilize generics. However looking at this text, I figure that metaprogramming is clearly a component in generics, even if it is done in runtime or compile time. One could argue that the programmer should be able to choose if a certain implementation of generics should be evaluated in compile time or runtime.

Finally, would it not be possible to define the functionality of generics if the possibility of generic metaprogramming, compile time or runtime, is available in the given language? If so, would you regard generics as a programming pattern rather than a programming paradigm? Are there more programming paradigms that we could squeeze under the roof of metaprogramming?

PS: I should bring my selfe to compile a generics example in C# and take a look at the resulting IL.

The mother of all languages

The last week or so, I have been roaming the internet (especially Wikipedia) for information about alternative programming languages, paradigms and theories about these two. I have no solution what so ever about this. But finally I know how I am going to attack this problem of understanding the magic of programming languages.

When I solve any programming related problem I usually break down the problem in layers of abstraction. In other words, I build many small problem solvers which in turn makes it easy to solve the bigger problem in the end. So I think I need to start looking at the roots, and then work my way from there. I want a language in which I can define any other language implementing any programming paradigms.

I will keep you informed of any progress..

Addition: After writing this article I googled "The mother of all languages". Didn't find anything useful. Went to bed, couldn't sleep. Got up and googled "programming paradigms" and found this article: Language Oriented Programming: The Next Programming Paradigm This is exactly what I'm after right now.

Metaprogramming

I was sick last week, made me turn the hours around. So another sleepless night brings me back from bed, into my chair in front of the computer. What is haunting me the most right now it the answers to my friend Johans riddles. And I stumble upon a word I didn’t recognize – Metaprogramming. So I use Wikipedia (as you may have noticed) as my major tool to understand all of these words and concepts that I have never seen.

http://en.wikipedia.org/wiki/Metaprogramming - Read it!

I soon discover that Metaprogramming is a fancy word for self modifying code, code generators, translators, macros. You name it, anything that has anything to do with generating new code. So I grasp the concept. I read on anyway because the article is interesting and might shed new exciting light upon the subject, mainly because I’m into code generators and O/R-mapping.

Then I read something that is very intriguing;

“Not all metaprogramming involves generative programming. If programs are modifiable at runtime (such as in Lisp, Python, Smalltalk, Ruby, PHP, Perl, and Tcl), then techniques can be used to perform metaprogramming without actually generating source code.”

I don’t understand this text. What does it mean? It sounds very intriguing, but I cannot grasp the concept. I read it over and over and I finally level with it, and realize that this is what I used to do with macros back in the days of assembler and C++ programming. Only now, the language itself supports generating itself in runtime. Whilst macros are evaluated at compile time or even pre compile. So I read on, the text talks about compilers being metaprogramming tools. Then, the second last sentence hits me hard;

“Having the programming language itself as a first-class data type (as in Lisp) is also very useful.”

Oh my God!

And a whole world of possibilities unravels before my inner vision..

ScopeGuard for C#

I just found this article by Nicholas Blumhardt at Ubik Systems (http://ubik.com.au/article/named/andreis_scopeguard_for_c). I should let the article talk for itself, but I must say something about it first.

What is it? It’s kind of a generic transaction engine. This means that if you have very important piece of code that must not alter the state of your application if not completed, then you can define steps to roll everything back.

How does it work? Simple as igneous, anonymous functions is stored up in an array as your code runs along. When the code hits an exception, each of the functions is executed in “Last In First Out” (LIFO) order. Everything is implemented in a single class called Guard.

I am fond of code that clearly defines the happy execution path. This solution will mess up the happy path and obscure the original intension of the code. However, this is a simple and creative solution to a tough problem.

Finally, those guys over at Ubic is really bright, you should read all of their articles and check out their projects aswell.

Stuck with the traditional approach

I wanted to write a blog about programming paradigms. But it end up being a personal story of my life, so I crapped it. Anyway, what I wanted to say is all experiences it good, even bad ones. And therefore it doesn’t hurt to try out new languages, to broaden your perspective. But before choosing a new language to learn you might want to look at these links first:

http://en.wikipedia.org/wiki/Programming_paradigm - talks about programming paradigms. The fact that there was something called programming paradigm was unknown to me until a while ago when I started to investigate different languages.

http://en.wikipedia.org/wiki/Multiparadigm_programming_language - this is the killer. It talks about how most programming languages are multi-paradigm.

Read these Wikipedia articles. They are both interesting and thoughtful. When you have read about them then you would probably want to continue with these:

http://en.wikipedia.org/wiki/Imperative_programming - imperative programming, common in most languages, but you never see “at least two years of experience with imperative programming” in job advertising.

http://en.wikipedia.org/wiki/Object-oriented_programming - object oriented programming, you know this one, and you see it everywhere “at least two years of experience with object oriented programming”.

http://en.wikipedia.org/wiki/Generic_programming - generics, the hot stuff in C# 2.

http://en.wikipedia.org/wiki/Functional_programming - functional programming, the hot stuff in C# 3.

Try to question what is good and what is bad in each paradigm. That is a valuable leasson for you!

What will the others think?

So in my last post I lightly shared some of my philosophical thoughts about generics. I can't say that I really understand what I’m on about in that post. However there is a lot of stuff that could be done to the most common languages out there. What I like about C#, is the fact that Microsoft continue to develop the language. This encourage the thought that we might have a really good programming language some day.

All of this is interesting, and I am always interested in ways to better my code. New syntax gives me more power and possibly new ways to design and write better code. So I am a coding geek, but I am also a professional. S0 when someone tells me that functional programming will improve my code and make it easier to maintain, then I can agree with that person to a certain level. Now, some of you might think that I am stupid to agree to this only “to a certain level”, but most programmers isn't interested in experimenting with new syntax that they feel uncomfortable with. And they usualy state that the way they've always solved problems work, changing it will only introduce more risk then reducing.

So what will happen when we enter the full blown era of C# 3? Well I will of course take advantage of this in my design. And I will probably write the toughest parts in our projects myself, but what will happen when one of the other programmers must put a lambda expression into a method call that I have written? I think they will question my thinking. It doesn’t matter what I think, they are content with how they solve problems already.

Let’s face it, functional programming and full blown utilization of generics turn object oriented programming on the edge. It’s totally a new way of thinking. And I don’t think that many programmers out there are ready for it, or even interested in getting ready for it.

My final point is that when I act system architect, I also have the competence of my collegues in mind. Not doing so will risk the time frame of the project. But keep in mind that I also have their personal education to think about. There must be balance.

Generics C# 2.0

I'm not an experienced programmer when it comes to generics. I thought that I was. However, the more interested I get in programming languages, the more I tend to look at other languages. Now I realize C# 2 is limited.

Disclaimer: Understand that I limit my discussion to C# 2 as reference, I haven’t checked out C# 3 fully just yet, so I will not even bother stating anything about it. Also realize that this particular subject isn't my primary. Johan (blog in Swedish http://hoomla.blogspot.com/), a friend of mine introduced me to the mysterious world of questioning why languages look the way they look. I find myself thinking in other patterns now days, that’s all. So I have some thoughts that I want to put down.

You all know how List<> work, you declare your List<> and give it a type to adopt. Then we have Dictionary<,> where you define two types that you want the class to adopt. Both are good, you can do great stuff with these things. But what if you could declare something like an Array<Tn> where n is a variable number of T’s. Example, I want an Array that holds two strings and a integer, then I would do this Array<string, string, int>. Or if I wanted an Array with one string, one integer and MyType, then I would declare it Array<string, int, MyType>.

As far as I understand, some languages have support for this, it’s called Tuples. F# has Tuples, I haven’t investigated if it is what I think it is just yet. So how would we go about using this generic generics then? What would a foreach look like? I don’t know, could we use foreach or should we need to use more functional programming?

However, generics aren’t limited to arrays or lists. That’s just the most obvious reason to use them. FPSharp is a great example of what you can do with generics (http://sourceforge.net/projects/fpsharp). Credit goes to Johan who find and investigate tons of these things every day.