perl
In The Problems of Perl: The Future of Bugzilla, Max Kanat-Alexander* laments the state of the Bugzilla codebase: Once upon a time, Bugzilla was an internal application at Netscape, written in TCL. When it was open-sourced in 1998, Terry (the original programmer), decided to re-write Bugzilla in Perl. My understanding
programming languages
In case you hadn't noticed, it's that time of year again: let the wholesale buying of crap begin! As a technology enthusiast with a bad impulse purchase habit, I get a lot of complaints that I am difficult to buy for. That's sort of
algorithms
In my previous post on shuffling, I glossed over something very important. The very first thing that came to mind for a shuffle algorithm is this: for (int i = 0; i < cards.Length; i++) { int n = rand.Next(cards.Length); Swap(ref cards[i], ref cards[n]); } It'
programming languages
Earlier this week I wrote about The Two Types of Programmers. Based on the huge number of comments, it seemed to strike a nerve. Or two. This surprised me, because it was never meant to be the inflammatory, provocative diatribe that many people interpreted it as. It got so out
programming languages
Contrary to myth, there aren't fourteen types of programmers. There are really only two, as Ben Collins-Sussman reminds us. There are two "classes" of programmers in the world of software development: I'm going to call them the 20% and the 80%. The 20% folks
programming languages
Reginald Braithwaite writes consistently great stuff on his blog, but I think my absolute favorite thing he's ever written is We Have Lost Control of the Apparatus. But we programmers have lost and we must be realistic about things. The fact of the matter is this: people own
operating system limits
Raymond Chen notes that if you have to ask where the operating system limits are, you're probably doing something wrong: If you're nesting windows more than 50 levels deep or nesting menus more than 25 levels deep or creating a dialog box with more than 65535
software development concepts
I often trot out Steve McConnell's doghouse analogy [http://stevemcconnell.com/articles/art03.htm] to illustrate how small projects aren't necessarily representative of the problems [https://blog.codinghorror.com/the-long-dismal-history-of-software-project-failure/] you'll encounter on larger projects. > People who have written a few small programs
software development concepts
Here's an interesting thought question from Mike Stall: what's worse than crashing? Mike provides the following list of crash scenarios, in order from best to worst: 1. Application works as expected and never crashes. 2. Application crashes due to rare bugs that nobody notices or cares
programming languages
Tim Berners-Lee on the Principle of Least Power [http://www.w3.org/DesignIssues/Principles.html]: > Computer Science spent the last forty years making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The
software development concepts
Rich Skrenta writes that code is our enemy [http://www.skrenta.com/2007/05/code_is_our_enemy.html]. > Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you
software development
If I told you to choose between two technical books, one by renowned Windows author Charles Petzold, and another by some guy you've probably never heard of, which one would you pick? That's what I thought too. Until I sat down to read both of them.