The dark matter of programmers

Kate Gregory said in an interview that she likes to call C++ programmers the dark matter of the software development world. They’re not visible — they don’t attend conferences and they don’t buy a lot of books — and yet there are a lot of them.

I’ve thought the same about those who write code for games and embedded systems. I’ve hardly met anyone who works in either area, but there is a huge amount of such software and someone has to be writing it.

Game developers and embedded systems folk often work in C++, so my observation would overlap with Kate Gregory’s.

Related posts

Emacs a few weeks later

A few weeks ago I mentioned that I would give Emacs another try.  I said I would use it through April and then decide whether to keep using it or give up. Here are some thoughts on Emacs a few weeks later.

I thought that after using Emacs for a few weeks I’d either fall in love with it or decide to give it up. Instead, I’m somewhere in the middle.

It was satisfying to learn Emacs because it was challenging and because it has been in the back of my mind for a long time.

Using Emacs on Windows has been easier than when I’ve tried it before. Maybe the Windows version of Emacs has improved, or maybe I am more persistent than I was before.

Sometimes I try to use Windows keyboard shortcuts in Emacs or Emacs commands in Windows programs. Emacs is internally consistent, but not consistent with the majority of software I use. In the past I concluded that such inconsistency was too much. Now I’m willing to live with that inconsistency in exchange for other benefits.

A large part of my motivation for learning Emacs was to reduce the number of applications I use regularly. So far there hasn’t been as much consolidation I’d like, though I imagine over time I may use Emacs for more tasks than I do now.

People mean at least a couple different things when they say they use Emacs. Some simply mean that Emacs is their default text editor rather than something like Notepad++, Vim, or TextMate. But some mean much more. They live inside Emacs, doing tasks in Emacs that others would use more specialized software for. I’m closer to the former group for now, though I imagine the real return on the investment of learning Emacs comes from using it as more of a work environment and not just an editor.

Related posts

Complexity of HTML and LaTeX

Sometime around 1994, my office mate introduced me to HTML by saying it was 10 times simpler than LaTeX. At the time I thought he was right. Now I’m not so sure. Maybe he was right in 1994 when the expectations for HTML were very low.

It is easier to bang out a simple, ugly HTML page than to write your first LaTeX document. When you compare the time required to make an attractive document, the effort becomes more comparable. The more sophisticated you get, the simpler LaTeX becomes by comparison.

Of course the two languages are not exactly comparable. HTML targets a web browser while LaTeX targets paper. HTML would be much simpler if people only used it to create documents to print out on their own printer. A major challenge with HTML is not knowing how someone else will use your document. You don’t know what browser they will view it with, at what resolution, etc. For that matter, you don’t know whether they’re even going to view it at all — they may use a screen reader to listen to the document.

Writing HTML is much more complicated than writing LaTeX if you take a broad view of all that is required to do it well: learning about accessibility and internationalization, keeping track of browser capabilities and market shares, adapting to evolving standards, etc. The closer you look into it, the less HTML has in common with LaTeX. The two languages are not simply two systems of markup; they address different problems.

Related links

The good parts

I’ve written before about how I liked Douglas Crockford’s book JavaScript: The Good Parts and how I wish someone would write the corresponding book for R. I just found out this week that O’Reilly has published three more books along the lines of Crockford’s book:

I’m reading the HTML & CSS book. It’s a good read, but not quite what you might expect from the title. It’s not an introductory book on HTML or CSS. It assumes the reader is familiar with the basics of both languages. Instead it focuses on strategy for how to use the two languages.

HTML & CSS: The Good Parts reminds me of Scott Meyers’ Effective C++ books. These books assumed you knew the syntax of C++ but were looking for strategic advice for making the best use of the language. Some have argued that the fact Meyers needed to write these books is evidence that C++ is too complicated. The same could be said of HTML and especially CSS. Both C++ and web standards have evolved over time and are burdened with backward compatibility. But as Bjarne Stroustrup remarked

There are just two kinds of languages: the ones everybody complains about and the ones nobody uses.

Related posts

Taking your code for a walk

walking a dog

When I was in college, a friend of mine told me he liked to take his code out for a walk every now and then. By that he meant recompiling and running all of his programs, say once a week. I asked him why he would want to do that. If a program compiled and ran the last time you touched it, why shouldn’t it compile and run now? He simply said I might be surprised.

Even when your source code isn’t changing, the environment around it is changing. That’s why your code can break without anyone touching it. Peter Deutsch made this observation in the context of networks in his Eight Fallacies of Distributed Computing.

  1. The network is reliable.
  2. Latency is zero.
  3. Bandwidth is infinite.
  4. The network is secure.
  5. Topology doesn’t change.
  6. There is one administrator.
  7. Transport cost is zero.
  8. The network is homogeneous.

Kevin Kelly made the same observation in the context of data storage. Because data formats change and physical media decay, you’ve got to keep copying your data to save it. He coined the term movage to describe the active process of preserving data.

The only way to archive digital information is to keep it moving. I call this movage instead of storage. Proper movage means transferring the material to current platforms on a regular basis … anything you want moved to the future has to be given attention to keep it moving forward.

This morning I had problems running LaTeX (with Beamer) on an old presentation and thought about my friend’s advice.

Related links

Always invert

Carl Jacobi’s advice to mathematicians was “always invert.” See what you can find out by turning a problem around. This post came from following Jacobi’s advice.

A few days ago I wrote a note about how you can approximate a normal probability density by one period of a cosine. Specifically, the approximation has density

f(x) = (1 + cos(x))/2 π.

for x between -π and π and zero outside that interval. This distribution has variance σ2 = π2/3 – 2 and so σ fx) is approximately a standard normal density.

Why approximate a normal density by a cosine? The cosine is more familiar than the normal density and can easily be integrated in closed form. The rule to always invert suggests it might be useful to approximate a cosine by a normal density.

What is a nice property of the normal density? For one thing, it is its own Fourier transform. So it might be worthwhile to approximate cosine by a normal density to have an idea what its Fourier transform looks like. Maybe the function σ fx) above doesn’t change too much when taking Fourier transforms. Is that right? Let’s look at a graph.

plot of σ f(σx) and its Fourier transform

The solid blue line is σ fx) and the dashed orange line is its Fourier transform.

Other ideas

The cosine approximation for the normal density is more interesting than practical if your goal is simply to compute normal probabilities; there are more accurate approximations. But there are other uses of the cosine approximation, such as the example above. How else might you exploit the approximate relationship between sine waves and the normal distribution? I have the sense that there’s some application out there where this approximation swoops in and greatly simplifies a problem.

Update (6 May 2010): Here’s the Mathematica code used to create the graph above in PDF form. The code goes into more detail than the text of this post.

Related posts

Deconstructing Thomas Edison

I’m reading Remarkable Engineers to write a review for a website. The prose is pretty bland, though it got spicier in the chapter on Thomas Edison. It seems the author felt he needed to take Edison down a notch.

The career of Thomas Edison was not that of a great man of science, or even that of an inventive genius … His only major scientific discovery was the fact that a vacuum lamp could act as a rectifier, passing only negative electric currents. … He was said to have invented the business of invention.

So Edison was an engineer rather than a scientist. This criticism seems odd in a book devoted to remarkable engineers.

Surely Edison was an inventive genius; he held over a thousand patents, more than anyone has ever held. That is not to say anyone believes he came up with over a thousand unprecedented ideas completely by himself. He built on the work of others. He coordinated the work of his employees. He took ideas that were not being used and commercialized them. Perhaps he was more of an entrepreneurial genius than a scientific genius, but he was a genius nonetheless.

Related posts

Anti-antitrust

Rumor has it that “a federal antitrust probe of Apple is days away” according to PCWorld. I do not want to see this. Even though I criticized Steve Jobs’ statements about Flash in my previous post, it’s the hypocrisy I find most offensive. I would respect Jobs if he said

Hey, it’s my platform. I can do whatever I want with it. If you don’t like it, buy someone else’s stuff. Or better yet, go make your own platform.

That might make me want go out and buy an iPad.

However, such a statement may not hold water legally. No, you can’t do whatever you want with your own platform. Perhaps you should be able to, but that’s not the law. Hank Williams makes an interesting argument this morning that Apple may guilty of illegal restraint of trade through their use of warranties.

I’m suspicious of antitrust cases. They are often a way for competitors to win in court what they were unable to win in the marketplace. I don’t want to see Apple go through the antitrust wringer just because Microsoft had to. On the other hand, given the Microsoft precedent, it would be almost impossible to overlook Apple. The discussion of whether Microsoft should have included its web browser as part of the operating system seems absolutely trivial compared to the control Apple exerts over its devices.

Related posts