|Ned Batchelder : Blog | Code | Text | Site|
» Home : Blog
I read Simon's complaint about Eclipse this morning, and spent a little time looking into it. I considered downloading the latest milestone, and I investigated what version I was running, and whether it would upgrade itself, and so on. And then I realized that fiddling with Eclipse was not how I wanted to spend my software engineering energy. I wanted to write code. And I thought about The IDE Divide, which says you're either a language person or an IDE person. Bob responded to that division of the world by saying, "you need both". I guess my attitude toward the dichotomy is that you can do really well with neither.
A great parody of middle-school book reports: How To Kill a Mockingbird.
Frink is a programming language by Alan Eliasen. It is really good at dealing with physical matters, tracking units along with numbers, so that physical calculations are really simple.
For example, how many gallons of gasoline have as much energy as a teaspoon of water (according to Einstein)? A line of Frink prints the answer:
The Sample Calculations are a hoot, ranging from frat-house liquor calculations to fart jokes to spam-debunking. And of course, the name of the language is from every geek's favorite Simpson's character. Frink will be the topic of one of the talks at the Lightweight Languages 2004 forum.
I have nothing to add to Nancy Bea's description of Friendship, other than to say that I've experienced exactly the same thing with my autistic son.
Oliver Steele has an interesting essay about two world views:
Artist Chris Cobb has reogranized an entire bookstore so that the books are arranged by color rather than subject. He talks about the project, and some other things he's done (sculptures made with glue sticks and mashed potatoes, among other things). The bookstore was done overnight by 20 volunteers, will stay that way for a week or so, and will then be undone overnight by the 20 volunteers. Maybe it's the bookstore aspect, but I find this oddly attractive.
There must be something in the air: two bloggers are talking about two alternatives to the standard Python unittest module:
I've been writing unit tests for my Python projects, and I am definitely hooked. The feeling of having the correctness of my code pinned down by extensive unit tests is a great security blanket. I can't imagine working without them (except at work, grrrr...). And I've had my own difficulties with unittest, so I'm interested in other possibilities.
I haven't tried doctest, and it seems very clever and cool, but I can't see it working out in the long run. The needs of documentation and tests are different, and they will necessarily diverge. For one thing, documentation ideally should be concise, and tests ideally should be exhaustive. And not all methods can be well documented by showing execution examples.
In fact, the PyCon talk about doctest admits to some of these difficulties, and recommends creating functions whose only purpose is to carry docstrings full of tests. To me, this is an admission of failure. Maybe I'm being too harsh and should give it a try.
As to py.test, I'll definitely have to look into it. It seems like unittest, but written Pythonically from the start, rather than ported from Java.
Ken Iverson, the creator of APL, died last month at the age of 84. I wrote a bit about APL last spring. It was innovative and unusual if nothing else. In the early sixties there were not many styles of programming available, certainly not many that have persisted to the 21st century. APL was one of them.
I attended a lecture by Iverson when I was at Penn in 1985 or so. I'd like to say that he was witty and urbane, a visionary and an inspiration. Unfortunately, I remember only two things from the talk, and they both were Iverson being obnoxious.
First, talking about APL, he had a set of slides explaining the good points about the language. One of the bullets was: "easy to read". Now say what you will about APL, but most people considered it the most difficult language to read (this was before Perl!). Even if you found it easy to read, you understood that it had a different reputation, and you addressed it. Iverson simply declared it easy to read (I guess because of its conciseness) and moved on. I think most of the audience was dumbstruck.
Second, at Penn we had a Univac something-or-other mainframe, and a grad student there had implemented APL for it. It was something of an achievement. This student stood to ask Iverson a question, and as a bit of an introduction, mentioned that he had written an APL implementation. Iverson interrupted him to say something along the lines of, "lots of people have implemented APL". What his point was, I don't know. I know what the effect was: he unnecessarily insulted his hosts.
I don't mean for this to be all negative. Iverson was something of a legend. I suppose being cantankerous was part and parcel of that. He was influential, iconoclastic, and clearly brilliant.
Lambda The Ultimate has more about him (including, naturally, some sniping about Dijkstra's legacy vs. Iverson's).
I am a software developer working in the opening decade of the 21st century. This means that many of the solutions I devise will involve XML. Of course, choosing XML is only part of an answer: the exact form of the XML must be chosen as well. As with many software problems, I can use an existing solution, or I can make up something new.
The latest problem at hand involves describing the schema of a relational database in XML. The proposed existing solution is XML Schema. The question: is it better to use XML Schema to describe a database, or to use a new XML dialect custom-tailored to the job?
In brief, the upside of using XML Schema is that it already exists, has been thoroughly thought-out, and may allow us to use existing tools to work with our database description. The downside of XML Schema is that it wasn't designed to describe databases, and it is complex.
The summary is: I don't want to use XML Schema to describe a relational database. Have I missed something? Am I making a mistake?
File this under "dumb moves in the movie industry": 'Toy Story 3' in the works. Disney is going to make the third Toy Story movie, but without Pixar. Disney has marketing down pat, but they've got nothing on Pixar when it comes to making great movies.
If you're like many of my readers, you may have been pondering the problem of what to get me for a gift. Look no further than Bathsheba Grossman's sculpture. They're mathematical, they're beautiful, and they're unique:
And they're made with an astounding 3D metal-printing process:
Plus, how cool a name is Bathsheba Grossman, with a domain name of bathsheba.com?
Koders is a search engine targeted at searching code. It's an interesting idea. I often search Google for code samples. Koders might be better because you can select the programming language you want, and when you find an intriguing result, you can navigate around the whole project as a file tree. On the other hand, it seems to only index open-source projects, so you won't find samples from documentation, or tutorials as Google would find. And I'm not sure why it tries to estimate the labor cost to develop each project?
More along the themes of The Incredibles vs. The Polar Express: Here are two short films in roughly the same niche: science fiction about giant machines. But the production techniques and values of the two couldn't be more different:
Yet with all the differences in the production of the two movies, there's little difference in the story-telling impact of each. I'd actually give Walk-Smash-Walk the edge. Filmmakers should put story-telling first, and technology second. Like many other people, they concentrate on technology when they should be focusing more on connecting people together in whatever way they can.
BTW: Sakupen's other movie is Dad's Home, which is more of a traditional cartoon, but also very well done.
I'm constantly surprised at the good will I find among my readers. Alexander Belchenko has surpassed all others, though, in volunteering to translate some of my pages into Russian. He's started with Cog (here's the original in English). I couldn't be more pleased.
If anyone else wants to help bring my meager words to the rest of the world, drop me a line.
Who can say we're losing our technlogical edge when there are still engineers out there with the vision and foresight to build RoboDump 1.0?
Along with The Incredibles, The Polar Express is opening this week. The general consensus seems to be that The Polar Express is creepy. This is explained by The Uncanny Valley, a theory about human response to near-humans beings (robots, cartoons, stuffed animals, whatever). The theory says that the more similar a being is to a human, the more positively people feel about it, until they get really close to human, and then it just gets creepy (uncanny in the original wording). In the case of The Polar Express, the eyes just seem really cold (Max says it's because they can't motion-capture the eyes).
Looking up some details of UTF-8 in the always-fabulous Wikipedia, I found this choice tidbit:
I had no idea that the Bell Labs superheroes were behind it! Wikipedia also kindly provided a link to Rob Pike's authoritative recounting of the history.
This is just here because I seem to search for it every few weeks, and now I'll know where it is: INFO: Syntax of the Res: Protocol and Some Known Related Issues.
I was going to include a screen-shot of some tasty widgets on my desktop, but they are vampires: they don't appear in magnifiers or screen captures. Perhaps it's due to their transparency?
In my experience, this debate comes down to a mindset. If you are fundamentally database-focused, you will like stored procedures. If you are fundamentally application-focused, you will not. Generally, requirements like portability and maintenance costs will outweigh personal preferences any way. For example, if your application has to run on more than one database, stored procedures will be very expensive to use (because they will have to be re-written for each database platform). Personally, I find writing code in pre-paleolithic SQL extensions to be absolutely abhorrent, so I don't like stored procedures. Some day, maybe I'll work on a project where their benefits outweigh their disadvantages.
I went with the whole family to see The Incredibles yesterday. I loved it, of course. Here are some thoughts:
¶ Design Observer: writings about design & culture: Mr. Vignelli's Map: history and appreciation of a classic NYC subway map (the one I grew up with).
¶ Election 2004 Results: A purple map of counties.
¶ Cars: the next Pixar film (after The Incredibles).
¶ A Time Lapse Lunar Eclipse: clever and beautiful representation of the recent lunar eclipse.
¶ Image * After: free images and textures.
Shlomi Fish has compiled a Comparison of SCM Systems (SCM is Source Code Management, or version control system). The list is pretty good, and had a few products I hadn't heard of yet. Interestingly, the very feature I liked most about Darcs and Arch (their server-less topology) is missing from his comparison.
But Shlomi himself seems to be a bit of a oddball. See his $20 million needed for the "Better CVS" Initiative page, for example.
Ever wonder just how bad belly-button lint can get? How about having a seed germinate and sprout in your belly button? Check out Belly Button Plant. Euwww.
Looks like Iris/Lotus/IBM has finally made public an updated version of NotesPeek. I don't know exactly what's been changed, but I expect it's mostly to add support for new ND6 structures. While the easter egg still has my face, it no longer has my name. D'oh! Also, the program icon has changed, to match the new ND6 icon scheme. Old on the left, new on the right:
I almost took a whack at adapting the "X-ray screen" theme to the new orange logo! While it's hard to see little personal touches like the X-ray screen go, I'm glad that it's finally being updated to keep it current with the Notes product.
Darcs is a source code control system, but with a different feel from most. Where most systems (CVS, Subversion, Perforce, ClearCase, Arch, and so on) use client/server topologies, Darcs is purely peer-to-peer. With Darcs, every working tree is a repository, on an equal footing with every other repository. And connectivity between repositories is as easy and as varied as accessing files: you can use the file system, FTP, a web server, or even email, it doesn't matter. Changes flow from one repository to another via the "push", "pull", or "send" commands. There is no central authority.
I've recently started using Darcs for personal projects, and it fits that need admirably. I don't have to run a server, I don't have to checkout before I can make changes, and I can set up repositories on other computers as backups. I can even create a repository on a thumb drive!
I don't how well Darcs will scale up to large projects, or many developers, but for my personal use, it's perfect.