Lotus 'Agenda' Returns as Open-Source 'Chandler'

RobotRunAmok writes "Before there was Outlook, or Evolution, or The Brain, there was Lotus Agenda, a DOS-based Personal Information Manager created by Mitch Kapor. Wired is reporting that Kapor is throwing 5 Million USD at the Open Source Applications Foundation to create an open-source resurrection of this PIM-Of-The-Gods in the form of Chandler, available now as an alpha for Windows, Linux, and Mac. For the Agenda hardcore among us, it's as though Atlantis is rising..."

Comments

This Story is Three Years old

[asv108]

The whole "Chandler is going to be an outlook killer," is a three year old story.

So far, they've only managed to produce alpha quality software at best, after more than three years. I always felt that they made some bad technology decisions from the start, like Python is probably not the best language for writing a PIM.

The requirements for this project have gone all over the place. Initially, it was touted as "exchange without the server," using some P2P method. Then it became an "outlook killer," then a "repository," and now they even have a "higher ed version," thats been talked about for some time.

Instead of trying to do a few things really well to start with, this project has become the poster boy for scope creep.

Re:This Story is Three Years old

[bitMonster]

Why is Python a bad choice? It's just a high-level OO language with lots and lots of libraries. Speed shouldn't be an issue with this sort of application. Whatever GUI library they use is surely written in C or C++ with Python bindings. Also, training developers to use Python is very easy (lots of personal experience), especially if they already know Java, C++, or C# pretty well.

Would you have chosen C, C++, or Java or ... what? I think that if the project is taking too long, Python, or any other language like it, would be the last thing to blame.

-Jeff

Re:This Story is Three Years old

[IamTheRealMike]

Python was a dumb choice because:

• It's too slow. You say that doesn't matter in "an app like this" but performance always matters. If you are competing for users then performance matters, it's as simple as that. You can get away with crap performance only if your app is so unique or valuable that people will tolerate the lack of it. I don't know if this is still true but at one point Chandler took over a minute to start up. The whole point of a PIM application is to collate and present a potentially large amount of personal data, fast. Python is very, very, very slow compared to C unless you use tricks like Psyco which trade memory for CPU time making it merely very slow.

• It's too inefficient. Python leaks memory by design. Go read up on it - the PyMalloc allocator never frees memory back to the operating system. It always holds on to the peak heap size as a misguided optimisation. What's more, data is just more expensive in Python due to its highly dynamic, reflective nature. Lots of strings are kept around where a C++ program would be using numbers instead. On a desktop machine (where you run a PIM) memory is speed: use too much and you drive the machine into swap hell. Similar problems contributed to the death of desktop Java.

• It's too dynamic. This doesn't just hurt performance. There is a school of thought that claims having safety features in a language doesn't matter, because you should write unit tests for everything anyway, and they'll catch all the bugs. That doesn't tally with my own real world experience; at any rate it can be very hard to construct accurate and comprehensive unit tests even if you are very disciplined. For instance there is no reliable way a unit test can catch a race condition or mutex inversion. Compile and runtime safety checks can do. A Red Hat developer whos name I forget commented that a huge number of bugs in their Fedora tools (all Python) would have been caught by the compiler if using an alternative language. This doesn't strictly mean type safety bugs, rather, bugs that would have been caught by the features of the language that can be used to check for correctness.

• It's interpreted (or just-in-time compiled if you're feeling very generous). This means NO opportunity for automatic program optimisation. These sorts of optimisations can make a huge difference, especially if whole-program optzn is used. Especially important because optimisation can remove a lot of the overhead of modern design patterns (very useful in c++).

Basically, the Chandler team allowed ideology to overrule engineering fact. There is only one language suitable for writing complex client-side software and that's C++: anything else doesn't have the performance characteristics necessary. You can also eliminate the most common sort of bugs in C++ code by using a garbage collector like Boehm GC; the Unreal engine uses this approach.

That said, Python has many tasks for which it is appropriate: prototyping ideas, simple scripting tasks, even small desktop apps like configuration applets, teaching etc. Basically anything where there's no risk of your program being undercut in the market by a tighter, more robust competitor. So no PIM suites then.

Lotus Improv

[Mean Variance]

Drop me a line when that app is revived as open source. It was a unique spreadsheet app that I have yet to see replicated anywhere. If my memory serves me, it was actually developed for Next and quietly went away.

On the other hand, my recollection of Organizer was when it came bundled on my old Hitachi laptop, circa 1996. I found it to be mostly "cute" with its binder metaphor but otherwise nothing special.

One more Lotus app I miss: Magellan.