Regular Coder

I program stuff.

Friday, January 11, 2008

I just found something that I think _finally_ explains something to me that I never quite understood about C++. I wish a saw this years ago. This is gold.

Const Correctness in C++

There are a few of things like this in C++ that I don't fully understand. A big part of me really dislikes C++ and would rather write in something else, anything else! But as long as we have so many Von Neumann machines around, C++ fills some important needs that no other language can or probably ever will at this point. It's pretty grandfathered in at this point. Sign, oh well.

Thursday, June 07, 2007

Mike Nelson's Mantras on Programming.

Mantra 1: Today's hot new system is tomorrow's legacy system. It will be hard to use, interface with, and support given enough time.

Mantra 2: Never call a routine 'smart', it is not. It doesn't matter how dumb the code was that it is replacing.

Mantra 3: Don't build for the future, it is unknown. Don't build for the past either for it is just as unknown. Building a new system to replace an old one is tantamount to ignoring the lessons of the past.

Mantra 4:
Build for the now. Only consider what it should do today. Not what may happen tomorrow or what it could do.

Mantra 5: Mostly the tenants of maintainable code are fallacies. When he says maintainable code he just means code that he would write.

Mantra 6: All code takes effort to understand. No matter how beautiful it is. Beautiful code just makes the puzzle more interesting.

Mantra 7:
No code is maintainable. Code is an object. It is only the coder that can take the action to maintain it.

Mantra 8:
Is the effort to make code maintainable greater than the effort to maintain it? Why do more of a thing in order to do less of another?

Mantra 9: Do not attempt to do today what you will know how to do tomorrow.

Mantra 10: Just because you are doing work that does not mean you are adding value; you might be removing value.

Mantra 11: Just because I am using newer tools that does not mean that I am smarter.

Mantra 11: Just because I am using better tools that does not mean that I am better.

Mantra 12: A programmer is not defined by his tools.

Mantra 13: Why must I always use the latest swiss army knife when I can use the sturdy blade?

Mantra 14: Just because I write the code that does not mean I am better than the people that maintain the code. They have to deal with what I write.

Mantra 15: Just because I write the code that does not mean I am better than the users. They are the ones that I wrote it for.

Mantra 16: My software is not a gift of my benevolence.

Mantra 17: How would it help for us all use the same tools? We are not all doing the same thing.

Mantra 18: Software is never good enough. Just make sure that it is good.

Mantra 19: Do not say, "I am a C++ programmer," or "I am a Windows programmer." Don't even say, "I am a computer programmer." Instead declare, "I am a programmer."

Tuesday, May 22, 2007

I got hit by this MSN messenger spam attack last night. It looked like someone I knew sent this in messenger,
"hi, check this and find out who deleted and blocked you from the Msn"

Thursday, May 10, 2007


This is pretty ingenious. Might not be too useful but I can imagine that it could be useful in some settings. Like for voice bindings ut2004 for instance. :)


Friday, May 04, 2007

Web 2.0 is the future now!!!

Seriously, what the hell is wrong with us?

Sunday, March 25, 2007

I was poking around at some programming languages again while thinking about concurency in programming and ran into a discussion on this very thing. Someone there mentioned Erlang as a good language to solve these sorts of problems. I'd never heard of it so I started checking it out. It does indeed have great concurrency support. I was going through their white paper and I found this other great feature that it has that has nothing to do with concurrency.

This program sorts a list using the Quicksort algorithm:
     sort([]) -> [];
     sort([Pivot|T]) ->
          sort([X||X <- T, X < Pivot]) ++
          [Pivot] ++
          sort([X||X <- T, X >= Pivot]).

from "Example 4 - Sort" of the whitepaper.

As it says in there ++ is the infix append operator and this example introduces what they call a list comprehension. Like it says in the whitepaper,

The notation [Expr || Qualifier1, Qualifier2, ...] introduces a list comprehension. Here Expression is an arbitrary expression, and each Qualifier is either a generator or a filter.

For example, the list comprehension

[X || X <- [1,2,a,3,4,b,5,6], integer(X), X > 3].

should be read as:

The list of X such that X is taken from the list [1,2,a,3,4,b,5,6] and X is an integer and X is greater than 3.

Here X <- [1,2,a,3,4,b,5,6] is a generator, and integer(X) and X > 3 are filters. This list comprehension evaluates to [4,5,6].

I was very impressed with this, at one time I was trying to come up with a syntax for this type of expression myself. At that point I'd never seen a language with a compact expression of this idea. I thought SQL where clauses are very close but the rest of the SQL statement is a bit to verbose for this type of case.

Then as I read the example program after understanding this I could clearly see the logic of the Quicksort program and for the first time I understood how the Quicksort algorithm works. I'm a little embarrassed to say but I've never fully understood how a Quicksort algorithm worked before reading the Erlang example. I very clearly remember reading my first introduction to this algorithm back in 1986, or something like that, in a Compute!'s Gazette (a magazine for Commodre computers). I never understood how that Basic implementation worked and from then on I've had some sort of block on my understanding how this algorithm worked. I've come across it may times in may different languages but all the implementations have been cryptic to my eyes. All I could clearly remember is the phrase "divide and conquer", which I think was mentioned in that first Computes!'s Gazette article, but never quite understanding how that helps you sort quickly. This phrase haunting my memory whenever I came across the Quicksort.

Well after about 10 minutes into reading Erlang's whitepaper with no exposure to Erlang before this and once I finished reading their "Example 4 - Sort" the program,

This program sorts a list using the Quicksort algorithm:
     sort([]) -> [];
     sort([Pivot|T]) ->
          sort([X||X <- T, X < Pivot]) ++
          [Pivot] ++
          sort([X||X <- T, X >= Pivot]).

simply blew me away. Suddenly all the pieces fell into place in my mind that had been starting to build in my mind since 1986 till now, 2007, and I suddenly for the first time in 20 years actually understood how Quicksort is implemented. It was here staring me in the face, plainly and succinctly written, which lead me directly to reasoning and logic behind it just like how a great equation compactly and cleanly describes the core of an idea. As a bonus I could see that my work on what they call a list comprehension was not only a good idea but is even a more powerful construction than I originally thought it was. It had helped me understand a difficult concept almost effortlessly.

I suspected before that something like a "list comprehension" is a very common abstraction in algorithms that really should be expressed in a language directly. Coding this sort of construction in C or similar languages is difficult and tiring, especially after you write and debug one for the hundredth time. But now I can see the raw power of using this kind of construction in practice. I think it was probably these details of the implementation of the Quicksort that was getting in my way of understanding the core idea behind the Quicksort itself for all these years. I can see that this language construction is a wonderful tool.

Wednesday, February 28, 2007

There's a great post at WTF about how bad programmers can continue to write bad code for a long time and think they have been writing great applications that whole time. This probably applies to most people, myself included. Not too surprising when you consider that usually the only real post-mortem is usually what you write up right before it hits production and all the data comes from memory with no hard evidence from production behind it.

What Could Possibly Be Worse Than Failure?