Don Park turned 41 today/yesterday, and immediately started cranking out a series of posts with some of the ideas he's got for his RSS Aggregator. There are three big areas (one post for each) that are interesting.

• Chunking news over time
  I like his idea of various timelines for looking at news, especially in special categories. Stepping back and seeing the big picture is important. I think that what SharpReader is doing with building threads is a form of this. Also, there's another way that I'd use this. There are some topics that I'm interested in but don't want to read every day. I want to read them periodically and not lose the information there. I'd use this sort of chunking for that as well.
• Scanning versus reading
  This is a big one for me. I do a scan / read pass across the huge HTML page that Aggie presents. Unfortunately what I've discovered is that the titles are not enough information to determine whether posts should be read or not. Having the content in-line is important.
• Permanence / context
  Permanence and context are about remembering and finding something that you read. My Aggie page is so huge that position in the page is meaningless for retaining context. For a number of interesting posts, I can't remember which blog they came from. There's enough surprise in post content, that I don't think I'd be able to adequately remember which category/section a post was in either. Which makes the problem of finding things later a bit harder. Right now, it's impossible because Aggie overwrites the HTML page each time, but it'd be trivial to fix that so that Aggie just inserted the date/time as part of the filename. Then you'd have an archive of pages that you could search. But that's a little bit low tech. In my scan and read workflow, I'd want to be able to search just the posts that I actually read, as well as all the posts that were retreived. I'm not sure that a search engine style interface isn't the best for this.

Sam Gentile's blog had a reference to a C/C++ Users' Journal article on enforcements in C++, which is a way of using templates to create assert like constructs. For the example that they show, you end up needing two versions, one for const and non-const objects. Then the authors decide to parameterize the enforcer class a bit more and end up with a template class that has a nested templatized operator. The creation of enforcers is so complicate that the authors define a macro which calls another macro and instantiates the template. Ouch. This makes Lisp macros look easy in comparison. That's 2 language mechanisms (template classes and macros -- three if you count the nexted templatized operator) in order to do what one mechanism, macros, can do in Lisp or Dylan.

Next up, a pair of articles from Carlos: In the first, he cites what he sees as disadvantages of dynamically typed languages:

The pros I perceive is not what most would argue. It's actually based on my experience using the Visualage and Eclipse environments. The pros are that it's easier to navigate and search the code base. See the absence of type information makes it difficult to find the dependencies between code. Ask any smalltalker their experience of trying to reduce the size of the smalltalk image, it's an extremely painful process. Just because you're liberated today from type information, doesn't mean that it's not going to strike you back tommorrow.

The question you've got to ask is, should I sacrifice the code completion, quick-fix, search, etc. for a little fewer keystrokes?

I think that the ability to build an intelligent development environment and the ability to build minimal images (for languages that have them) are orthogonal. On the building of intelligent environments, we need only point out that Visual Age and Eclipse have their roots in Smalltalk environments. The environment that I'm using for Python, WingIDE can do code completion and reasonable searching. I think it's a matter of work to some of the features like quick-fix. Here are some screenshots of Apple's Dylan environment from 1994, that give you an idea of the kinds of things that can be done. There's an interesting article about this in CACM.

As far as reducing image, that's possible to do as well. The Dylan folks found an innovative solution to the image problem -- known as the tree-shaking problem in the Lisp community. Instead of starting with a whole world image and trying to strip it down, they started with an empty world and added only what was needed. A Dylan app that was under development ran in a debugger nub that only contained the code needed to run that app. As the app grew, code was added to the code in the nub. When it came time to ship a standalong application, you cut the tether to the nub (an IPC connection) and what was in the nub was your application.

The second of Carlo's posts contains questions:

What if you could remove type information from a static typed language?

What if you could annotate a dynamic language with type information?

Shouldn't languages have more than one mode?

If static type checking is just one kind of analysis, should we not be able to turn it off and on?

If I knew the type of an object is my code, should I have the capability to tell the compiler what type it is?

If tests were so important, shouldn't I be able to ask the compiler to generate some of these tests ?

The right language should not be a choice between static and dynamic checking, it should give you that choice.

The right language allows me to choose how much static analysis I really need.

The right language allows me to give hints to make that analysis possible.

The right language makes creating tests easier.

I'm aware of two languages (at least) that allow you to add type declarations to parts of a program as needed: Common Lisp and Dylan. I'm sure that there are probably more, but I know for sure that this can be done in those two languages.