mardi 28 avril 2009

unique 0.2

Python source files are now processed more intelligently : tokens within comments are now ignored. Also, the filtering procedure has been improved a bit. You should get less repetitive results... of the repetitive patterns in your code :-)

get it from https://sourceforge.net/projects/unique/

dimanche 26 avril 2009

unique

Last weekend I wrote a little prototype to help me find patterns in my source code. It was a little python script. This weekend I revisited the script and transformed it into a small wxpython application.

You can get it from http://unique.sourceforge.net/

I labeled it as pre-alpha. It's really only a prototype. Ugly and bare-bones.

Ideas, bug reports et compagnie are all welcome.

mercredi 15 avril 2009

The evil of long-lived branches

Long-lived branches make good practices bad.

When coding in a branch that will eventually be merged, it's a bad idea to refactor. All the global changes required to correctly implement the feature you need to code will send lines flying all over the code base and there is no VCS capable of dealing with that automatically.

I mean, the VCS will be able to apply the changes you have made to some other codeline, but the changes done in the branched code that has been moved & refactored won't be merged properly.

Because you are on a branch, you can't code as local as possible anymore. You can't, because you won't be able to refactor when you will need to re-use this local code. You need to know in advance what will be re-used and how. That sends all those agile tricks out the window. Overdesign becomes the only solution. It means that the quality of the code is getting worse every day those branches are maintained apart. And if this situation lasts for a couple of months, it comes to a point where you don't even want the different branches to be merged anyway.

Features go in the mainline, stabilization in a short-lived regularly-merged (towards the mainline) branch. Doesn't it make sense?!

lundi 13 avril 2009

What is Lisp?

Confusing. Misunderstood. Lisp is plural.

Is it fast? Yes and no - it depends.
Isn't it old? Almost the oldest. But it's not a bad thing because it never stopped to evolve. New doesn't mean powerful, by the way.
Is it object-oriented? If you need it to be, sure. Even when it's not, it is.
Is it only good for research? It's reliable and fast, but not always. It has huge libraries, but not always. It's been used in big commercial systems, too. It sure is good for research, but it can also be used commercially.

Lisp sure is hard to explain briefly. But I think I found a way to keep it to a minimum when I'll have to say something about Lisp to my future collegues.

Lisp is syntax.

The only constant between the various dialects, platforms, interpreters, compilers... is the syntax. I used to repeat that lisp has no syntax. That may be true, but if everything else is blurry and contradictory about lisp, you end up with lisp being nothing and everything. It's nothing because it's only syntax and it has no syntax. It's everything because that nothingness of a syntax is fully programmable - and people have made everything with it.

Please pardon this nothing-of-a-post. I am myself trying to understand what my new favorite programming language is. If you can light the lantern of the newb that I am, go ahead - flame at will :-)

C++ interview questions/inspiration - part 3

Back to basics

Early exit is a nice and simple optimization strategy. If you are designing an interview algorithm to help you select great hackers, you can expect most candidates to fail the test. That's why you should try to sort your interview questions. By putting the better discriminants first, you will know sooner if the candidate is not quite as good as you would like him to be.

Knowing how good the candidate is early in the interview does not necessarily mean asking fewer questions, it means making the most of the little time you've got. If the guy looks like a super star you will want to skip one or two easy questions and get with the fun stuff. With super stars, it's the interviewer that has to show how good he is. Stars like to be asked tough, relevant questions. An easy interview indicates that anyone could get the position - and that the 'winner' will be surrounded with mediocre coders.

All this to say : don't focus on this 3rd question if the candidate looks like a star. Don't skip it entirely either, it's not that bad a discriminant. You definitely want to be sure that everyone that works with you can answer it straight, it's just not very challenging to experienced C++ programmers.

The feature presentation

a) What is printed on the console after the execution of this program?
b) What would you have done differently?



#include <iostream>


struct animal
{
~animal()
{
std::cout << "bye\n";
}

virtual void print()
{
std::cout << "I am an animal.\n";
}
};

struct bird : public animal
{
~bird()
{
std::cout << "bye bye birdie\n";
}

virtual void print()
{
std::cout << "I am a bird.\n";
}
};

void print( animal a )
{
a.print();
}


int main()
{
animal* a = new bird();
print( *a );
delete a;
return 0;
}


Low level

Can he spot the obvious errors? The print free function taking its argument by copy. The destructor of the super class not being virtual. Can he explain what the default copy constructor does? Does he know how to disable it? What about the assignment operator - did he think about it by himself? Virtual member functions - how do they work? What happens if the derived class's destructor is specified as virtual but not the super class? What if it's the other way around? Ever heard of a vtable? A vpointer?

High level

Will the candidate only worry about the low level details or will he think about the design globally? Does he know his sacred books? Can he actually recite Meyers and say "Make non-leaf classes abstract". Why make the super class's destructor virtual if there is nothing to free? Program in the future tense, of course.

Dazed and confused

Only the best will be able to speak about high level concerns easily, others will need a little help. You can help them with a derived example

int main()
{
animal* a = new bird();
animal other;
*a = other;
print( *a );
delete a;
return 0;
}
Is it sending them on the wild goose chase of virtual assignment operators or do they know better? It's ok to need a little help - it's not ok to become confused and disoriented.

Stay tuned for the next episode - it's a tough one.

Update

Part 4 is now available.