Me: Thanks so much for your fix to my issue. My friend, who majors in business, once told me that I should no longer major in Computer Science because “programming is like banging your head against the wall repeatedly, but with less reward.” I find that to be a rather rash dramatization, but I know in dealing with bugs as subtle as these it may feel that way. I hope at least the end-result is rewarding for you.

Programmer: Are you a Computer Science major? If so, don’t let your friend discourage you. Just ask him about “head banging” when those business majors find that their product development and marketing efforts fail to work after spending millions of dollars.

Me: Yes, I’m a CS major. And you’re right — the reward is great in software, and the cost of building an useful product is relatively minimal. That is one of the reasons I chose this path. It’s why I love helping out honest, intelligent developers such as yourself in any way I can. I have found that hardworking CS majors who are not only better programmers, but more often than not better thinkers and better managers — if you’d give them the chance. I am happy in my decision, and still have that naivete that perhaps I can change the industry a bit, shake things up, come up with an idea that changes everything, innovate in whatever way I can. Big aspirations; we’ll see what happens. For now, I’ll just keep respecting the good software I find in the world, such as yours.

Indeed, my life for the last 3 years has been dominated by the language. In many ways, pursuing a startup and enduring the associated financial hardship was partially because I had become frustrated with using Java in my full-time work and wanted to convert hobby projects I was building outside of work hours into full-fledged projects.

Something else I noticed in the last three years is that my programming life has become very zen-like. I now rarely discuss or debate things like programming language features, strange constructs like generics, or which framework to use or ignore. Instead, I spend most of my time building a product that people love. My colleagues and I communicate with code. And what better language to communicate in than arguably the world’s most readable? What better language to deliver value in than one that simply gets out of your way?

I therefore get a great amount of joy of showing other people what the Zen of Python can mean in their lives. Last year, I gave a training course to a 20-person team of government employees who were using dated languages like Fortran and COBOL to build important government systems. A bright manager in the organization realized how much more productive their team could be if they stopped worrying about compiler versions and IDEs and started thinking in code. But the key was to understand the value of Python, not necessarily as a language with a certain set of features, but as a way of doing things, as a cultural influence. This is a culture that says, “the language should fade away”, similarly to how Edward Tufte argues that the chrome and administrative debris should fade away when displaying content.

Since then, I have used these slides countless times to espouse the virtues of my favorite interpreter. This has included giving short seminars in NYC, training Parse.ly interns and new hires (here’s a shot of me and two Parse.ly engineers, Michael and Zach), holding Python office hours at HackNY’s hackathon (indeed, here’s an action shot on Flickr to prove it!), and introducing my friends to the joy of building software.

Code and Slides: The Zen of Python in 3 days

It’s therefore with elation that today I am able to provide the slides and materials for this talk free to the world on my Github account. Simply click here:

https://github.com/Parsely/python-adv-slides

Or, if you’re not interested in the code behind the slides (because the slides are actually created with the help of Python itself), you can go here to simply view them.

http://pixelmonkey.org/pub/python-training/

(note, modern web browser like Chrome or Firefox recommended for speed and smoothness)

This may be my first “open source presentation”, in that the slide presentation itself is provided as code that is freely available, and reproducing the slide presentation is a matter of running a code generator.

A touch of NLP with Python

I mentioned that one of the reasons I love Python is because it gets out of your way. Nowhere is this more evident than Python’s ability to prototype algorithms to natural language processing and corpus linguistics problems, something I do everyday. The Natural Language Toolkit (NLTK) provides an excellent starting point from learning about this aspect of computer science.

Recently, Parse.ly has gotten some new engineers on the team who are great Python programmers but without any background in NLP. To give them a taste of how well-suited Python is for this task, I gave a seminar entitled, “Just Enough NLP with Python”. Just as with the prior slides, you can view these online on Github:

https://github.com/Parsely/python-nlp-slides

And you can view the compiled slides here:

http://pixelmonkey.org/pub/nlp-training/

Between these two pieces, you can learn the Zen of Python (PEP 20) very rapidly, and incorporate it into your everyday software life.

If you have any comments or feedback, feel free to reach out to me on Twitter. I’d love to hear what you think. And if you, too, are bitten by the Python bug (as one of our Parse.ly interns recently was in a big, almost romantic way) then you should reach out to us, since we’re hiring.

And, sadly, our top engineering graduates don’t always become engineers. They move into finance or management consulting — both of which pay far higher salaries than engineering. I have seen the dilemma that my engineering students at at Duke University have faced. Do they take a job in civil engineering that pays $70,000, or join big Wall Street financial firm and make $120,000? With the hefty student loans that hang over their heads, most have made the financially sensible decision. In some years, half of our graduates have ended up taking jobs outside of engineering. Instead of developing new types of medical devices, renewable energy sources and ways to sustain the environment, my most brilliant students are designing new ways to help our investment banks engineer the financial system.

[...] We also need to make the engineering profession “cool” again, with the same sense of excitement and urgency in engineering and science that we saw during the Sputnik days. Back then, engineering was considered essential to the nation’s survival. Engineers and scientists were national heroes. It’s not that we don’t have problems to solve. The economy is in dire straits. Natural resources such as food, water, and crude oil are becoming scarce. Drug-resistant bacteria threaten us with doomsday plagues. But we’re not offering our best minds incentive to solve them.

From Mr. President, there is no engineer shortage.

Luckily this is happening already in high tech in NYC, thanks to awesome programs like HackNY and collabraCode (both of which my startup Parse.ly formally supported). As much as it pains me to say it, I also think The Social Network may be seen as a cultural catalyst for software engineers becoming “cool”.

But high tech is only a small piece of the puzzle — we need the same active marketing for students’ minds in biotech, education, medical research, civil engineering, etc.

Frederick Brooks, author of the The Mythical Man-Month, disinguished between two problems in software development: the accidental problems and the essential ones. (Read Brooks’ watershed article, “The Silver Bullet“.) The industry likes to argue that we have made huge leaps in terms of the accidental in recent years. Programmer productivity is better with the help of better software revision systems, but more importantly there are RAD tools like GUI designers, powerful IDEs like Eclipse/VS.NET. Do I think we’re headed in the right direction?

In a sense. I think those tools are useful, but only because I think all we can do is shrink the accidental problem as small as possible, and then do our best to tackle the essential. The major win in terms of the accidental and even the essential is high-level programming, and I mean really high level, like Python. Why is this important? Well, Brooks once talked about how PL/I was a great software engineering language because the statements written to the compiler are “pretty close” to the “thought stuff” the programmer is working with in his head. But PL/I is nowhere near there (neither is C++, or even Java or C#). However, Python heads in that direction.

In my head, unless I really am immersed in C code all the time, I don’t think of things like types, memory management, or, God, pointer arithmetic. When we solve problems, we solve it in something computer scientists have used for years: pseudocode. Pseudocode is nothing more than code that expresses an algorithm or approach without worrying about the gory details of the underlying hardware.

Python isn’t quite pseudocode, but it’s closer than anything else I’ve seen. And that’s a huge help to productivity not just from the point of view of the single developer, but, I’d argue, also from the point of view of a team of developers. Code readability is hugely important in team environments. C and Perl can be very unreadable, which makes them ill-suited to team development. Java and C++ are better, but even they suffer from some readability problems (where the actual solutions can be masked by “best practices” and strange ways of exploiting constructs of the language). Python can be hacked too, but it tends not to be, and it tends to have very high readability.

But what about the tools mentioned above (Eclipse/VS.NET)? I often wondered about all the *nix programmers (including many of my Computer Science professors) who still load up X11 and dump into vim or emacs for their programming needs. Wouldn’t they benefit from the latest and greatest in IntelliSense, Refactoring, CallTips, SaneOnlineDocumentation, and any other CamelCase ideas I can think of for a development environment? Most *nix users would say that stuff is unnecessary–and in many senses, they are right. The essential problem remains, no matter how fancy your IDE is.

A lot of *nix developers shrink their accidental problem on a “as-needed” basis, by coding plugins or complex configurations for their highly-extensible text editors. But nowadays, productivity is starting to be a concern even in the OSS world, where things have traditionally stuck with the old “mortar and pestle,” or, should I say, “gcc and gdb”. That’s why we see projects like Mono gaining a lot of popularity.

But Python offers a nice, alternative path, I think. The accidental problem is worth shrinking, and I think it can be done simply by one major refocus:

(1) make the language usable, not the tool. (IMO, already done with Python)

and

(2) create source code analyzing tools that integrate with development environments to make the language-bearer more productive.

You can see enormous success in (2) with the Eclipse IDE project. My main problem: Eclipse’s focus is on a language that isn’t very usable. Java is certainly better than C, but still, it has significant problems that stop it from connecting me (the programmer) with my problem-solving ideas (the thought-stuff of programming).

At my new job, I work with Java eight hours a day, but my code just doesn’t read and work like my Python code, which is much closer to the underlying algorithms and approaches. Java certainly pushed forward OO on the masses of computer programmers, but it did so without learning non-OO but very handy scripting language concepts, like having Lists and Hashes be built-in types, with tons of syntactic sugar, for crying out loud. Most problems break down to List and Hash problems, after all. What’s more, OO on its own isn’t a panacea: I’ve seen many convoluted OO designs that I wish were written procedurally, and which might have been more performant if they had been. The software engineering community thinks that there will be a silver bullet (OOP! AOP! XP! MDE!), but I think just getting programmers closer to the “thought-stuff” will be an effort with better rewards.

The main reason we’re depressed is because, though both Sak and I like the Facebook and are users, we can’t help noticing one thing:

It’s not that complicated to build a website like that.

In fact, it’s downright easy. If I weren’t so busy with computer science classes, I probably could have threw something like it together myself.

Now, we know that business opportunities don’t have to be complicated to make money. They just have to be Right, that is in the Right place, with the Right look, taking advantage of the Right fad, etc.

But doesn’t it seem to you that a straightforward PHP/MySQL application just isn’t worth $2 billion? I mean, that’s $2,000 million. That’s $2,000,000,000.

Yet, I can’t say I’m entirely unhappy about it. Mark Zuckerberg, here’s to you, man. You’re my age, and you did exactly what I wish I had done. Built some crappy website, and made out like a bandit with sacks of cash. Kudos. You’re honestly my fucking hero.

I think it’s pretty clear that despite the disagreements I have with Mr. Gates over a subject known as “business ethics” (if such a subject truly exists!), he does seem to be a genuinely patriotic guy who loves technology. I mean, what good is it for more Americans to get into CS, if other countries are diving in and filling whatever knowledge gap may exist? Can’t Bill just hire those workers, and what’s more, for less money per hour?

Well, I think Mr. Gates really wants innovation in computer software to remain “America’s Great Industry.”

I was very intrigued by this response to the article:

Everyone knows that Open Source is taking over the software development industry. And according to the Open Source philosophy; developers should be enslaved, source code should be free. No, no, that’s not politically correct, let me try again. Developers should give their work away because code needs to be free (as in speech) and the needs of the code is more important than the needs of the people who create it. Well, that doesn’t sound quite right either but in any case, it doesn’t really matter to me because my kids won’t be studying computer science.

This is a very interesting post. True, it will be seen as a troll by some, since open source philosophy definitely doesn’t say anything about programmer enslavement. But his point is real and felt in the industry. That is, if you aren’t selling software, how are software developers to make money from it?

I think the response to this was best-articulated by Eric Raymond, when he pointed out that of programmers, only about 1-2% make their cash from off-the-shelf software sales. Instead, most make their money from “in-house” or “custom” software solutions. In other words, the majority of developers aren’t working on the Adobe Photoshop team, they’re working on Acme Inc.’s payroll or issue tracking system.

I kind of love this sort of propaganda, though. Because it is all good news for me.

When I first decided to do CS, I considered the possible effect of outsourcing and other factors on my employment possibilities. I thought, what if there are no jobs when I get out of college? But I stuck with it.

Well, it turns out, everyone had a hunch similar to mine, but they were more wooed by it than I was. So everyone fled CS. And now I’m the only one left. (An exaggeration, but you get what I mean — my computer science classes are nearly empty, whereas they were packed during registration only a few years ago).

It turns out, firms are hiring more than ever before. Why? Because the dotcom bubble is over, and green-eyed imposters are getting flushed out of the industry. But the demand is still there. Software is pervasive. Everyone needs software development done. There simply isn’t anything under the sun that can’t benefit from a little software developer finesse.

You can’t have all this work done in India and China because, it turns out, people want software developers to work with customers (big surprise). They want applications which meet their sensibilities, and they want them changes when the environment changes.

I liked that Mr. Gates said the #1 thing he’s looking for is project management IT types. Funny, it’s the #1 thing I’m looking for, too. Software developers are a dime a dozen. Find me a software developer who doesn’t get nervous when you ask him a tough question, or ask him to write, in plain English, a high-level overview of the system you’re asking him to create, and you’ve got yourself someone who’s valuable.

I personally find this to be very true in my life.

When I was in high school, I prided myself (from the point of view of “tools”) as knowing graphic design (Photoshop/Illustrator), web development, and print/page layout. Handy tools to know for (1) making money and (2) working on a high school newspaper. The only real programming languages I knew back then were Actionscript (for Flash), JavaScript, and (eegads) Perl. Then I got to college and armed myself with algorithms, data structures, and systems, and started picking up Java and C on my own. Now I consider myself well-versed in those, and this past summer learned Python and used that on a lot of different projects. Then this semester I got interested in C++ and used that a lot. Nowadays, when I look at problems, I look at them in terms of my tools. Text parsing problem? Wow, Python’s re (regular expressions) module could handle that pretty easily. Big engineering project? Wow, using templates and OO features in C++ may lead to a nice design. Database-driven web application? Well, Java/JSP may fit you nicely. (I know, I know, what am I doing not knowing Ruby on Rails!)

I think Mark’s onto something. Changing toolsets often is definitely useful. Even though I couldn’t write full programs for you in Perl nowadays, what I do know about it (its limitations, capabilities) is definitely good enough to see when it may be the best choice for the job.

As for academic tools — very true. A lot of techniques I learned in e.g. Discrete Math, Linear Algebra were in one ear and out the other. Alas, I think the main point is to learn them once and then be able to Wikipedia them later, when needed

That said, stuff I learned in my algorithms and data structures and operating systems courses have stayed with me. I think some of that stuff is just essential.

That said, after spending some time in the humanities (where writing quality is high) and much time in Computer Science (where literacy is defined as being able to read code), coming back to traditional math textbooks has been quite a culture shock. They are so horribly written, it really blows my mind.

So, in response to my horrible Calculus II textbook (published at NYU only for NYU classes, this book features minimal explanation and the maximum amount of notation), I have been using it only for the homework problems and using instead James Stewart’s excellent book, Calculus: Early Transcendentals for rigorous proofs of concepts (because Stewart really does present them nicely), and the lighter but infinitely more illuminating Calculus Made Easy, by Silvanus Thompson.

A somewhat controversial book, Calculus Made Easy chooses to skip the notation-laden explanations of Calculus concepts provided by typical textbooks, and opts instead of a clear, textual elucidation of core concepts in the context of their applications. The philosophy of the book is well-described by this excerpt from the Epilogue.

I think this is wonderful writing, however damning it may be:

It may be confidently assumed that when this tractate Calculus Made Easy falls into the hands of the professional mathematicians, they will (if not too lazy) rise up as one man, and damn it as being a thoroughly bad book. Of that there can be, from their point of view, no possible manner of doubt whatever. It commits several most grievous and deplorable errors.

First, it shows how ridiculously easy most of the operations of the calculus really are.

Secondly, it gives away so many trade secrets. By showing you that what one fool can do, other fools can do also, it lets you see that these mathematical swells, who pride themselves on having mastered such an awfully difficult subject as the calculus, have no such great reason to be puffed up. They like you to think how terribly difficult it is, and don’t want that superstition to be rudely dissipated.

Thirdly, among the dreadful things they will say about “So Easy” is this: that there is an utter failure on the part of the author to demonstrate with rigid and satisfactory completeness the validity of sundry methods which he has presented in simple fashion, and has even dared to use in solving problems! But why should he not? You don’t forbid the use of a watch to every person who does not know how to make one? You don’t object to the musician playing on a violin that he has not himself constructed. You don’t teach the rules of syntax to children until they have already become fluent in the use of speech. It would be equally absurd to require general rigid demonstrations to be expounded to beginners of the calculus.

One thing will the professed mathematicians say about this thoroughly bad and vicious book: that the reason why it is so easy is because the author has left out all the things that are really difficult. And the ghastly fact about this accusation is that — it is true! That is, indeed, why the book has been written — written for the legion of innocents who have hitherto been deterred from acquiring elements of the calculus by the stupid way in which its teaching is almost always presented.

I should note that my Calculus professor is actually quite good, and provides very nice explanations of complex topics, usually beginning with an elucidation of the general idea, and then going on to the formalities. But our assigned textbook is not nearly as clear, and many professors I’ve had in the past have lived entirely inside their constructed notational apparatus.

This reminds me of an old joke I heard awhile back:

A math professor begins his lecture by writing on the blackboard. He only pauses for brief moments of notational explanation, but continues writing and writing, one symbol after the other, for thirty minutes on end. He fills up six blackboards full of derivation, algebraic manipulation, and what have you. At the end, he smiles and draws the open box, indicating the completion of the proof. “Is that clear?” the professor asks. Blank stares all around.

At that point, the professor stops himself. “Oh, no, I believe I’ve made a mistake.” He then looks at the six boards of writing, and begins pointing at certain sections while nodding his head, clearly doing calculations internally. He then paces back and forth across the front of the classroom, with his head bent down and his fist to his chin. For five full minutes, he paces and nods, thinking about the proof just presented.

Then he stops pacing, looks at the students, and says, “Ah, yes, yes. It’s clear.”

Here’s an interesting read, by the way. Came as especially relevant to me, as I “rediscover” math for math’s sake.

Here’s the blurb I sent out when I advertised the talk:

Have you wanted to work on open source projects, but just don’t know how to get started? This talk will provide the basics you need to start working on open source software the next time you sit down at your computer.

In particular, this talk will cover:

(1) A brief overview of open source development in the industry and press.

(2) The UNIX development platform. A brief and whimsical overview of the UNIX shell, its surrounding tools, and the power of shell scripting. (Useful to anyone wanting to learn more about UNIX tools.) Learn how to do in a few lines of shell script what you only thought was possible with a big, extravagant hundred- or thousand- line program, and learn why so many of the world’s best hackers hack on a *nix system.

(3) The basics you need in order to hack on open source project: how mailing lists, wikis, bugzillas, source code revision systems all come together to form an organic code management process, and how to get started using those tools and others to learn about a project and what parts need development work done. This will include a brief introduction to CVS.

(4) The last part of the talk will involve actually watching open source development in action. In particular, the speaker will checkout some code from a source repository, make a change to it, create a patchfile from that change, then track down the mailing list or bugzilla related to the project and submit the patch to the maintainer. You will actually get to see open source “in action,” and will want to do it right when you get home!

If you’re a Windows or Mac OS developer who has always wanted to learn more about *nix systems, or if you’re a developer who wants to either take his own project open source or work on existing open source projects, this talk is for you.

Of course, if you’re someone who is just interested in the concept of open source, this talk will give you an inside look at “how things get done” in this community.

This talk was at least partially inspired by Nat Friedman’s blog post, check it out here:

“How to be a Hacker”

The talk was a general success, I think. About 12 people attended. You can see the talk in PDF or ODP formats, and you can also download the patches I wrote specifically for the talk to illustrate “open source development in action.” The patches are pretty stupid, but do illustrate the point, at least. Plus, each of the three patches served one of my own goals (hacking my CPU frequency scaler, fixing a gnome-terminal bug, and hacking galeon “for fun”), so that’s that. I think it’d be cool to give this talk again (maybe a little refined to include less basic UNIX tools and more hacking stuff) at a later date. We’ll see.

On the one hand, big guys mean bigger projects, more formally managed projects, and at least from that point of view, harder “software engineering” problems.

Small firms are less formally managed, but you may be pushing some technology to the limit, rather than just providing some service (however essential it might be) to the company. It’s the software that matters, not “the System.” And you’ll probably be working with better coders. (The best coders fill up the small shops, whereas they are just diamonds in the rough at the bigger shops).

In either case, this is turning into one of those things your parents always warned you about. You know, when they say it isn’t about the company, but it’s about you and what you put into it. Just like college was. I honestly could have gotten just as much out of college with a library card and Internet connection, and lots of free time.

Now that I’m moving up to the “real world,” I keep thinking: no matter what I do, it’s gonna be my responsibility to grow my skills and knowledge, and no one else’s.

It’s definitely going to be an interesting year…

If that’s your approach, why not be a buisness major instead? I mean, if you’re not really passionate about the work, why not pick an occupation that a) pays more and b) is easier to fake your way through?

Heh.

Pretty awesome, no? Check out the project if you haven’t yet, its MoinMoin wiki is here. I might post up a video of it in action soon.

It uses a clever skintone detection algorithm across the RGB colorspace, along with clever segmentation of the regions of interest to determine the cardinal direction a hand is moving in and retargeting the box to the new area and running the algorithm again. I am quite happy with the results. It can only get better, but it’s already pretty fun to play with.

At first I was gonna do the user interface in Python and have the image processing done in C, but then I decided that the user interface was simple enough that I should just give GTK+ in “pure C” form a try. Of course, I used Glade, which drastically reduces the amount of annoying code for things like Vboxes and Hboxes and Containers you have to write. In fact, using Glade, interface design becomes somewhat straightforward in C. Which is weird, because C seems like it was never built for user interface design, but the g_signal system makes it easy to catch events that occur in your program, and GTK+ is high enough abstracted that you can do pretty well. I don’t know how well GTK+ scales for large programs (i.e. many dialogs, many lists, etc.)–in that case, I think I’d definitely pick a higher level language.

Looking forward to how this application may turn out. OpenCV looks like a pretty awesome library.

Truthfully, the book kind of pops the lid off Linux and makes you understand it as much less glamorous than say Wired Magazine described it to the public. Linus really just talks about not having a social life, sitting in his room with curtains covering his window, coding all day. Not exactly the ideal role model, I think. Don’t get me wrong, I love the Linux kernel (as much as one can love imperfect software), and Linus made a great contribution toward keeping the UNIX world and UNIX principles alive, but it’s just that I like to think of open source developers as something other than the stereotypical, introverted geek. In fact, much of Linus’s chapters is devoted to his apprehension about giving a public talk about Linux. When I think about the fact that I’ve given three or four of them to date, and enjoy it more every time, I see how different I am from this kind of stereotypical geek.

It also kind of made me dislike Linus. When I saw Revolution OS (a DVD on the rise of open source), the movie kind of endeared me to Linus’s practical nature as opposed to Richard Stallman’s religious idealism. I like idealism, but Stallman is really religious about it. And he’s bitter. Linus, on the other hand, has that great Northern European, “I’m just gonna go with the flow” attitude.

But this book made me realize that Linus is religious is his own sort of way. Included in the book is Linus’s flame war with Andy Tanenbaum on monolithic versus microkernel designs. Truthfully, I’ve studied operating systems and I’m not even sure which design is best, and Linus makes a decent argument of why microkernels end up being just as complex, or more complex than monolithic ones. But what I didn’t like is that in the flamefest, Tanenbaum said that deficiencies in MINIX were due to it being a hobby, and that he had duties as a professor. Linus responded, “Re 2: your job is being a professor and researcher: That’s one hell of a good excuse for some of the brain-damages of minix. I can only hope (and assume) that Amoeba [Tanenbaum's future OS project] doesn’t suck like minix does.”

This just shows me that Linus really is an asshole sometimes. He states this outright in his book. So now, truthfully, I may like the open source movement, but I think I “at least dislike” two of its most major players (Torvalds and Stallman).

Finally, I think a clip from Tanenbaum’s website points out a nice principal in OS design:

Also, Linus and I are not “enemies” or anything like that. I met him once and he seemed like a nice friendly, smart guy. My only regret is that he didn’t develop Linux based on the microkernel technology of MINIX. With all the security problems Windows has now, it is increasingly obvious to everyone that tiny microkernels, like that of MINIX, are a better base for operating systems than huge monolithic systems. Linux has been the victim of fewer attacks than Windows because (1) it actually is more secure, but also (2) most attackers think hitting Windows offers a bigger bang for the buck so Windows simply gets attacked more. As I did 20 years ago, I still fervently believe that the only way to make software secure, reliable, and fast is to make it small. Fight Features.

I agree. But does a microkernel design actually reduce the overall size of the operating system, or does it just reduce the size of whatever you consider to be the “microkernel”? That is, just because a file system is implemented as a file system daemon talking to a driver subsystem through message passing doesn’t necessarily mean the file system, or driver subsystem, are secure. Insecurity could exist even at the boundaries, no? Not to mention instability.

I think Linus and Tanenbaum have to agree that this debate isn’t an open and shut case. The best kernel is probably one that mixes modularity, a strong kernel/userspace boundary, and some of the fancier features of a microkernel approach, while not sacrificing elegance of design or performance.

I set up a mailing list with GNU Mailman (link above), which was decently painless under Debian Sarge. The only annoying thing was utilizing my virtual e-mail address mappings which are stored in MySQL, but I figured out a trick for that.

I’ve already spoken, via e-mail, with an open source developer who works on gstreamer among other projects, Ronald S. Bultje. He has already tentatively agreed to do a talk for us sometime this year.

I recently read some articles comparing the speed of Python to Java, most of which concluded that about the only place that Java beats Python is in actual interpreter speed (i.e. how fast statements and parsed and executed), and that since Python opts to provide thin wrappers for standard C libraries, Python performance ends up being really good.

A good comparison of the language features between Java and Python can be found online, along with a nice comparison of code simplicity and efficiency.

I think I agree with the first author: Python is a better high-level language, and should thus be used for higher-level tasks, and especially for one-offs. What’s interesting is that a lot of people look at Python, say “Man, Python is slow, I could do this better in C,” but then forget about Amdahl’s Law. If your program is accessing the network, the disk, or any other non-CPU/non-memory resource, no amount of optimization through lower-level languages will save you an order of magnitude on performance. So why waste the programmer time, when it can be done in a few lines of Python?

(I think one forgotten benefit of Python in both these articles is SWIG: if you’re truly a performance-oriented engineer, you can always profile your code, find the bottleneck algortihm/code fragment, rewrite it in C, and wrap it with SWIG so that you can access it as an object in Python. Not hard to do, and potentially huge performance gains. OTOH, you can even write Python-accessible code directly in C, using the same abstractions the Python interpreter uses.)

In other news, my Averatec laptop almost broke again today when I had it on my lap and it almost fell off. I caught it last-second, but this damn laptop is so small that sometimes I don’t even realize how close it is to being off the edge of my lap!

The thing has been working better and better. I got a program called fvcool which can send the Averatec into “low-power mode”, which means that the CPU gets sent HLT instructions and “powersave signals” on idle. The result is that it runs a lot cooler and saves more battery power, but at the expense of “real-time” apps like movie playing and even some MP3 playing, so you can’t have it on all the time.

The only bad thing about this laptop is sadly a trivial thing: the paint job. We all know laptops (except the TiBook/AlBook) are made of plastic under the shiny silver finish, but we wish that that silver finish would never come off. However, Averatec apparently used cheap paint, and so there are “palm prints” under where my palms have rested near the keyboard, as well as already a couple of spots (on the corners of my laptop) where the paint has rubbed off just from getting in contact with things. Kinda sad, because high-quality paint isn’t exactly expensive. Regardless, I’ll just have to paint it myself (or have M help me)… it might be a bit of an ordeal, but I think it’s possible to do. I’d just have to figure out a smart way to cover the LCD, keyboard and touch pad… maybe I can get M’s help when I come to that juncture.

Maybe I’ll switch this laptop’s color to something a little less “blah” than silver–a really shiny black would be awesome, I think.
In addition, I fixed some of my nasty X issues, so now my machine doesn’t hard lock ever. So that’s good too.

Now I gotta get studying for Basic Algorithms… fun fun.

Then I came back to my dorm, ate some food, and played with vim for literally 2 hours. I guess that was a waste of time, but I learned so much about this editor. Now I feel I can be twice as productive when I code. Especially with all the stuff I implemented for prototype previewing in my vimrc, and with all the support for ctags vim always had but I never used. Wow, this is one powerful programmer’s editor.

Matt has been telling me that I should use emacs with vi emulation (viper), and then I’ll get access to all that great emacs stuff. Maybe. I have nothing against it, except that emacs seems like an operating system unto itself. Eh, it doesn’t matter I guess, I just need to know one of the two well. They are both portable, and run on all major platforms.

For one thing, computers aren’t the center of the universe. What may be an ideal for computer scientists may not be an ideal for normal people. And very often, computer scientists affect normal people because everyone uses computers (or at least, everyone will).

All these computers sit around on our desks, we only use a fraction of their power at any time. Right now, I am typing this blog entry, using less than 1% of my CPU’s power. Theoretically, it could be doing things–helpful things, things that will make my life easier. It could be doing smart analyses of what I’m writing and try to predict what I’m going to do next. It could be some sort of extension of my mind, helping me produce better work. Instead, it sits there idle, useless. Glorified typewriter.

There have been many innovations, but the “humanity” of computers has been lost. We shouldn’t be designing our lives around them… they should be designed around US. The way the human mind works needs to be complimented. I should not change my ways for the computer, except if in changing them it makes my life easier, less complicated, and makes me more powerful as a human being.

These should be enabling devices. They surely have the potential to be enabling devices. But right now, in many ways, they disable us. We are restricted by the rules programmers place on us. We live under a sort of “law of code” which Lawrence Lessig describes in his books. In addition, the gov’t and other groups seek ways to use computers to control people.

Computers need to become more like us, so that they can seem familiar, useful, but at the same time, a whole lot more powerful. What computers have that we don’t have is speed, time (CPU time), and infinite storage. What we have that computers don’t have is the ability to reason about our experiences in very flexible ways. Wrapping a computer’s speed and storage capabilities around our own flexible abilities as conscious beings would mean a very powerful harmony.

Why are we still talking about how to isolate faults, or make device driver subsystems better, when this human element is so sorely needed, and would be so well appreciated?

A quote Dennett cited (attributed to Fodor) made me laugh out loud and receive stares in this quiet lounge: “If, in short, there is a community of computers living in my head, there had also better be somebody who is in charge; and, by God, it had better be me.”

I have to re-read, and re-read, and outline, and re-read, and maybe, eventually, write.

quote (Two Slashdot posters):

---

They [Microsoft] have already made the deals w/ Phoenix to make a MSFT certified BIOS that will enable them to not boot �insecure� OSs [read: Linux]. They are in talks to get the RIAA to support a format to make CDs unreadable in machines other than those running Windows (I presume this would include insecure versions of Windows as well). They are working to get the MPAA to agree to allow them to distribute movie materials via WMP which will likely lead to DVDs �protected� with MSFT products…

Sure, you can run all the free software in the world on your OpenBIOS computer. You will not be able to watch media, listen to media, surf the net, etc, because everything will require a “trusted” computer.

Yeah, it’s paranoid, yeah it’s probably [it seems] unlikely, but this is where we are headed whether we like it or not.

---

I understand now why programmers end up so conflicted. They have to work to meet deadlines, but often problems could be solved much more elegantly if there were extra time.

If I ever did run a software development company, one of the rules would be that everyone runs Workrave, a great free tool that forces you to take breaks from your computer every once in awhile. Not only does this reduce your chance of RSI/Carpal Tunnel, but it also provides a way for you to sit back and think about a problem in the abstract, rather than code your way through it.

I know deadlines are a reality. But in a perfect world, programming projects would be done “when they’re done.”