Category Archives: Technology

Thoughts on Languages

Programming

I’ve lately been working with OCaml and Haskell. Both are functional languages, and I’ve enjoyed functional languages for some time. that’s one reason I used Python for so long — while imperitive, it has a number of features commonly found in functional languages, such as anonymous functions and certain types of list manipulations.

OCaml and Haskell are both appealing to me. OCaml can be compiled to byte code, native code, or interpreted. It is a blindingly fast language, often beating C++ for performance, and occasionally even beating straight C code. This is quite a feat for a functional language, and helped get me interested in OCaml to start with.

OCaml has a marvelous type system. It is strongly statically typed, but has type inference and polymorphism. In short, this means that the type system stays out of your way (unlike Java) while still catching type problems in advance (unlike Python or Perl).

OCaml also has an OOP system, which is powerful though a bit odd.

One annoying thing about OCaml is that you have different operators for integers than for floats, and for lists than for strings, and the list operators are more powerful.

Haskell is a lazy, pure language. Its typing system looks very similar to OCaml’s, but it extends it in several significant ways. One way is with the use of typeclasses, a great way around OCaml’s problem with different operators.

Haskell also has a nicer module hierarchy system, and has a stronger standard library in most respects.

Haskell is not as fast as OCaml, especially relating to string manipulation. On the other hand, it’s no slower than Python, and has some powerful ways to exploit its lazy lists. (Haskell lists are the same as OCaml queues, but are also used for strings.)

One thing OCaml has that Haskell seems to lack is camlp4. Haskell has template Haskell, but it doesn’t seem as versatile. Haskell also lacks overt OOP implementations, but the OOHaskell people would want you to believe otherwise. (I’m learning about that now.)

I Still Hate Phone Companies

Technology

I’ve never been a big fan of phone companies. I’ve dealt with a small independent local company, lived in SBC territory in several states, and now live in Sprint Local area. I’ve never had good service, ever. The only thing worse than my phone company service has been cable company service.

Here’s my latest saga.

Sprint finally decided to offer DSL in our area. Great, I thought. We had been using fixed wireless for a couple of years since it was the only thing better than dialup available out in the country. But it has a huge problem: it require line-of-sight to the remote antenna. We have some very big trees here. Despite the company saying that the most powerful antenna should penetrate them, and mounting it on top of our roof — giving it a good 40 feet off the ground — we couldn’t clear the trees. So in summer, our connection would be very unreliable, and slow when it did work.

So we signed up for DSL the very day it became available here. Sprint scheduled someone to come out to install a DSL splitter the next week.

Our DSL modem arrived by UPS the day before the installer showed up. But the first problem: I ordered a static IP but there was nothing telling me what my IP is. Sprint DSL tech support (the one bright light in all of this — almost all of those people have a clue, and are helpful and can actually fix problems!) gave me the info I needed.

The next day, Sprint’s installer showed up at about 3:30, and said she had to leave very soon to get the brakes on her truck worked on. Great.
Continue reading I Still Hate Phone Companies →

Battle of the VMs

Programming

There are a lot of virtual machine interpreters out there. Java was the first well-known one, but VMs are also used for .NET, OCaml, Python, and the new Parrotcode VM will likely be used for Perl 6.

I started a discussion on the OCaml mailing list about some other bytecodes OCaml could target, with very interesting results. OCaml interpreters or compilers already exist for both Java and .NET.

There’s more to this than meets the eye, though. There are many different languages supported by .NET even though the .NET CLR does not lend itself to many of them very well. There are also a number of languages supported by the Java JVM, and Parrot is looking to support a good number, too. So it appears that no VM is going to promise the mythical language convergence .NET was talking about. Rather, we’re going to have too many choices. I wish we could standardize on a single VM and go with that.

Foundations of Python Network Programming

Programming

Update 9/23/2004: There is now a page for this book on my homepage, Complete.Org.

My latest book, Foundations of Python Network Programming, is now available for purchase (Amazon, bn, AllDirect, buy.com). This book is designed to show you everything from fundamentals of networking and low-level protocol design to work with higher-level protocols such as IMAP, HTTP, and FTP. For more information, please see the letter to the reader from the book’s back cover.

This is not a basic reference like Python comes with. Rather, it’s a hands-on guide. There are over 6600 lines of example code and the text strives to show you the big picture. For instance, there are several different ways of getting directory information from an FTP server, and some are not documented for use this way. The chapter on FTP explains them and provides example code to illustrate. There’s also an Apress page with details.

Below is the book’s Table of Contents along with a partial list of the examples you’ll find in each chapter:
Continue reading Foundations of Python Network Programming →

All Mail Readers Still Suck

Software

I’ve long been of the opinion that all mail readers suck. Some of them really suck. That’s why I wrote OfflineIMAP, after all.

Today I embarked on my periodic survey of mail readers to see what had changed. Things are encouraging but still not quite good enough. I have IMAP mail on two servers and I read it from four clients. I want to see the same mail on each client, and be able to work offline if I need to, and sync my changes back up later. I also maintain “Saved” folders for messages I want to archive indefinately. I want to see which folders have new messages and which ones have old messages. Finally, I want to be able to navigate entirely with a keyboard for all common functions.

Let’s take a look at how they all stack up.

First, there’s mutt with OfflineIMAP. Mutt by itself is not even worth mentioning; its IMAP support is so slow and buggy that it doesn’t even begin to make the cut. With OfflineIMAP, it’s actually pretty nice. I can easily create a macro to move messages to my Saved folder. I can also create macros to manage the two different e-mail account identities, using the correct one for replies automatically. So far so good. What mutt stinks at is the folder list. It just doesn’t have a good one at all. Also, since OfflineIMAP must be used, the integration is just not as clean as it could be.

Next, there’s the new KMail 3.3. This program has improved vastly recently. What was once a graphical client with more bugs than an entomologist’s lab is now a mostly reliable mail program. It integrates into the KDE or Gnome applet well for new mail notifications. It does everything I want with IMAP (with only one bug relating to non-selectable folders, which I can work around.) However, despite the khotkeys system, it is not possible to reliably script it to move a message to a saved folder or redirect it to my special storage address. Argh.

Then, there’s Mozilla Thunderbird. Another good contender, supports offline reading and all of that. Has nice junk mail features built in too. But its IMAP support is SLOW. When you delete a message, it goes out to the server (unlike KMail, which can cache this action). how do you like deleting 20 messages, having to wait 2 seconds after each press of Delete? Also, it suffers from the same scripting problem as KMail.

So it looks like I’m sticking with mutt+OfflineIMAP for now, but definately keeping a close watch over kmail.

Characteristics of Great Hackers

Programming

Paul Graham has written a tremendously insightful article analyzing great hackers. It is well worth a read whether you’re a hacker or not. Here are a few quotes:

  • I’ve found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent. The people I’ve met who do great work rarely think that they’re doing great work. They generally feel that they’re stupid and lazy, that their brain only works properly one day out of ten, and that it’s only a matter of time until they’re found out.
  • When I think about the great hackers I know, one thing they have in common is the extreme difficulty of making them work on anything they don’t want to.
  • Is there some quality that’s unique to hackers? I asked some friends, and the number one thing they mentioned was curiosity. I’d always supposed that all smart people were curious; that curiosity was simply the first derivative of knowledge. But apparently hackers are particularly curious, especially about how things work. That makes sense, because programs are in effect giant descriptions of how things work.

Note for the English-impaired: hacker does not mean someone that is attempting to breach security in this context.