I wish I could say I came up with the below, and I suppose I did, but I more or less gathered two or three techniques I didn’t come up with into a few lines to code to make a macro useful for debugging. Its primary merits are readable output and extreme ease of use.

#define MY_MODULE_DEBUG_CATEGORY1  0x0001
#define MY_MODULE_DEBUG_CATEGORY2  0x0002
#define MY_MODULE_DEBUG_CATEGORY3  0x0004

#if !defined(MY_MODULE_DEBUG)
#  define MY_MODULE_DEBUG                 0x0000
#endif
#define _pp_string(x) #x
#define _pp_str(x)     _pp_string(x)

#if (__GNUC__ > 3)
#  define dbg(cat, fmt, ...)					\
   do {								\
      if (MY_MODULE_DEBUG_##cat & MY_MODULE_DEBUG)		\
      {								\
	 printf(__FILE__":"_pp_str(__LINE__)" [%s] "fmt,	\
		__func__, ##__VA_ARGS__);			\
      }								\
   } while (0)
#else
#  define dbg(cat, fmt, args...)				\
   do {								\
      if (MY_MODULE_DEBUG_ ## cat & MY_MODULE_DEBUG)		\
      {								\
	 printf(__FILE__":"_pp_str(__LINE__)" [%s] "fmt,	\
		__FUNCTION__ , ##args);				\
      }								\
   } while (0)
#endif
#if defined(_SOME_OS_)
#  define os_err(cat, errval)					\
   do {								\
      char *errstr = 0;						\
      error_string(errval, &errstr, 80, ERR_GET_ALL);		\
      if (errstr)						\
      {								\
	 dbg(cat, "OS ERROR:\n%s\n", errstr);			\
	 free(errstr);						\
      }								\
      else							\
      {								\
	 dbg(cat, "OS ERROR: %#lx - err_string() failed!\n",	\
	     errval);						\
      }								\
   } while (0)
#endif

Notice the “os_err” macro above, for use with OS-specific error string functions. This particular incantation is oriented toward a particular OS I interact with at work (names changed to protect the innocent), but the same idea would be applicable to any system, really.

The Programming and Management Blog » Most Influential Programmers Results

Nick Halstead recently took a month-long poll over at his blog recently of what people consider the most influential programmers, and below is the result:

1st – Linus Torvalds

2nd – Alan turing

3rd – Dennis Ritchie

4th – Donald Knuth

5th – Rasmus Lerdorf

6th – John Carmack

7th – Bill Gates

8th – Richard Stallman

9th – Tim Berners-Lee

10th – Bjarne Stroustrup

I can’t say I think this list makes any sense at all. Firstly, while Linus is definitely influential, I think it’s a stretch to say he’s the most influential of all time. Rasmus Lerdorf, similarly created something interesting, but among the most influential of all time? Bill Gates’ influence is due more to his technical strategy and business acumen, not his programming.

His own top ten list is here:

1. John Carmack
2. Linus Torvalds
3. Tim Berners-Lee
4. Douglas Andrew Bel
5. Dennis Ritchie
6. Bram Cohen
7. asmus Lerdorf, Andi Gutmans & Zeev Suraski
8. Jez San
9. Bjarne Stroustrup
10. Richard Bartle & Roy Trubshaw

He cheated with all the “&”s. Of course, mine would look much different, I think. Remember – this is for all time. The criteria must be something other than simple fame, which seems to be the impetus for the poll-driven list. It also should be something other than riches. Influence that sprang from work as a programmer is the criteria. It might should even be two lists: influence over the world in general (or over multiple industries), and influence in the programming and software industry. Perhaps, put simply, the idea is people who have significantly changed the way we think or do things.

Anyway, here is my list. It is unorderd, as I just don’t know how I could possibly rank the individuals. They are from different times which posed different problems, had influence in different ways which has meant different things in modern times. One might be able to do very lose rankings, but a 1-10 ranking I think isn’t very sensible.

• Richard Stallman
• Guy Steele
• Tim Berners-Lee
• Brendan Eich
• Larry Wall
• Kernigan & Ritchie – OK, I’m cheating a little here too, because you really can’t separate these two in their achievements.
• David Wheeler
• Dan Bricklin
• Bram Cohen
• Donald Becker
• Bjarne Stroustrup
• James Gosling

Have a look at Wikipedia to see info about more programmers.

The demons *must* be ice-skating by now.  There was an almost wholly on-topic thread on /.

The original article was an “Ask Slashdot” regarding programming languages. Below are some of the more informed comments (or so I thought), along with some of my thoughts. My apologies for not having links. I started this post using a firefox blogging plugin, and I somehow didn’t get the links included.

Don’t waste time learning a lot of computer languages. Pick one or two, learn them well, learn their standard libraries, write programs in them, and read/maintain other people’s code.

This sounds reasonable to me, but I think there are some important caveats here. I think I’d pick more than one or two languages to be in your toolbox. My preference is to be proficient in languages that fall across the following categories: statically-typed languages, dynamically-typed languages, scripting languages, functional languages, procedural languages, and object-oriented languages. Of course, there could be plenty of overlap in exactly which languages you choose. For example, my language of choice whenever practical is the C++ programming language (not “C/C++”!). C++ is a multi-paradigm language; it obviously supports procedural and object-oriented programming, but it also provides support (to varying degrees) for functional programming and generic programming (via templates and — if you can hold your nose — the preprocessor). Of course, the realities of my education required that I also be proficient in Java and C.

That takes care of the statically-typed languages. I think dynamic languages (not necessarily including their standard libraries, if there is one) are easier to learn, so why limit yourself to one? If you know C, being able to create something useful in PHP is simply a matter of learning a little Apache HTTPD administration and being handy with the PHP API. I chose to learn a little Python because it’s very useful, but also because it has some neat features and is really hot right now (which means it is gaining traction among developers and people who create tools for it, which in turn make it that much easier to use). Python has really become one of the necessary packages for a reasonably complete OS install these days. If you’ll be doing a bunch of web applications, it may be worth your while to learn Ruby; if not, then Python will be a better general-purpose dynamic language, I think. Python is very practical. There are lots of other dynamic languages out there; among the more popular are Ruby, OCaml, Lisp (and it’s dialects, like Scheme and Elisp), but don’t think it’s necessarily worth your time to be proficient in a bunch of them. Pick one or two that meet your needs.

That leaves scripting languages. The two that have been most useful to me over a number of years, and not by a close margin, are the bourne shell and sed. Of course, that gives me away as a *nix geek. I don’t have anything against Windows; I just don’t do most of my development there (and I don’t think scripting tools are as ubiquitous). I think there are very few things you could do in some other scripting language that you couldn’t do comparably using ksh99 and sed.

Update: after re-reading this, I decided to add a blurb about Perl to hopefully stem the tide of emails and comments complaining that I didn’t mention it. Fine. Perl can do everything the Bourne shell and sed can combined, plus a whole, whole lot more. It’s a true statement. Perl has incredible utility, and it’s (somewhat) portable between *nix and Windows. I just haven’t had a lot of use for it because ksh99 (or bash, as is more common) and sed take less time to learn and are sufficient to meet my needs.

So here’s the point – after the realities of my education, professional environment, and personal preferences are all accounted for, the list of languages I’m reasonably proficient in (or at least comfortable with):

• C
• C++
• Java
• C#
• Bourne shell
• sed
• Python
• PHP
• Common Lisp
• Scheme

This, obviously, is more than one or two. I suppose an important thing to remember is that several of these for forced on me by circumstance, and several of them were simply inevitable (seriously…what programmers out there with more than a year or two of experience, including school, can’t write a little bit of C?), and the rest were personal choice.

Spend most of your time focusing on concepts that generalize to all programming.

And

Knowing about design patterns is useful in any language. The intricacies of C++ template programming are not. If I say “That’s a singleton”, people will know what I’m talking about whether the code is written in Ruby, C++, Java, or Cobol.

This is certainly good advice. I think design patters can be a double-edged sword; they provide a neat little box to think in, but they can also convey the useful experiences and proven idioms of legions of programmers. It’s also simply smart to be able to take what you know and apply it in a broad domain spectrum.

However, I think it’s very, very important to be really proficient in at least one language. Don’t let yourself be such a generalist that you can’t answer a few questions about at least one of your languages:

• What are its strengths?
• What are its weaknesses?
• Does is support tail recursion?
• What 5 things would you change in your favorite language?
• If I were to create a new language that could only implement 5 features from your language, which would they be?
• Which is the best compiler?
• What can your language be practically used for?

Once or twice a year, spend some time learning about a language you don’t know. Try to understand how it’s different than the language you normally use, and more importantly why. Look at example code and code from open source projects and try to emulate their code with your code. For example, Ruby will let you open a file, read and process each line in a while loop, then close the file. But the “ruby way” of doing it is to pass a code block to the file’s “each_line” method. After you understand the syntax and the strengths of the new language, and the idioms used by the language, decide what you like, and what you don’t. Then figure out how you can apply the new things in the language you regularly use.

I like this very much, and I think it dovetails very nicely with my previous comments; doing a detailed compare-and-contrast between your most frequently-used language and a new one will help you answer the questions above, but it will also help you keep your toolbox stocked with the most useful tools for you.

More generally, languages should be treated just like essential tools are in any other profession (or craft, if you prefer). Mechanics have buildings filled with tools, each with their purpose. They have one pegboard or cabinet that contains a small set of tools that are used very frequently and those are the kind of tools that become like extensions of the mechanics’ own limbs. That’s how programming tools should be, including languages. Go ahead and get attached to one. It gives you a little personality, but don’t sell yourself short by thinking of languages as anything other than tools.