Flutterby™! : Chandler transcript 2003-04-28 23:17:23.79485+00

Chandler transcript

2003-04-28 23:17:23.79485+00 by Dan Lyke 25 comments

Damn, I may have to learn Python. The transcript of the Emerging Technologies Conference presentation on Chandler makes Chandler look like a product I've been dreaming about being able to tweak for years and years.

Shirley somebody will write a Perl module wrapper if it's really all that... 8^)=

It looks interesting.. downloaded it and it ran.. With luck it'll make it to a higher version number.

Hrm. I read things like "a personal webserver (to read your emails while away from your machine)", and I only have one thought:

I imagine the reaction of the security admin at work, when told that somebody wants to install an MUA with a built-in web-swerver. And then I giggle.

(It may help to know that I find the security admin's profanity-filled outbursts to be amusing, generally.)

Seriously, what the hell does an MUA want or need with a built-in HTTP server?

If the MUA can delegate part of its GUI to a browser, the MUA gets out of writing a bunch of code. If the HTTP server limits access to localhost only, there's not really a security issue.

One of the MANY reasons I use Pine, is that I can SSH into MY desktop and run MY shell and Pine, with addresses, contacts, saves, folders, etc.. it runs on MY computer.. WebMail requires me to store data via IMAP on the mail server, and I am then subject to the limits placed on a shared server for file/folder retention, filters.. etc.

Having my local computer mail/PIM system have an integral http server may allow me to do this via the web, rather than SSH. But yes, the security concerns are INCREDIBLE for a normal user. - And I may still use Pine, the ability to scroll through junk with the 'D' (Delete) key is one of those user interface issues web browsers and GUI's just don't make an impact on.

If the HTTP server limits access to localhost only, there's not really a security issue.

Without getting into the whole question of whether the 'localhost lockdown' could ever really said to be working, if the HTTP server is locked down to localhost, it doesn't really do a whole lot for the "(to read your emails while away from your machine)" part of the quote, does it? I don't think this is about not having to write a GUI layer (and this thing is a Java app; I thought that was supposed to make this stuff trivial? <sarcasm/>); I think this is about moving web-based mail from the web server to the desktop.

One of the MANY reasons I use Pine, is that I can SSH into MY desktop and run MY shell and Pine, with addresses, contacts, saves, folders, etc.. it runs on MY computer.

I'm actually not thinking of it so much as a mail client. I've been diddling about for a while with some ideas for some information management, "my Palm

on steroids", and this looks like it's going that direction.

But I've also found that with a laptop I can have with me everywhere console access is becoming less of an issue.

On the whole HTTP thing, put it on your desktop machine, lock it to localhost, then tunnel SSH to it. Yes, IT groups are going to have fits at first, but as remote computing happens more and more there's either going to be that solution, or one involving virtual LANs.

- right now, chandler does virtually nothing, which is a shame. however it strikes me as having lots of potential -- lots more than the "lets clone an existing MS product" open-souce projects -- and they seem to have their shit together regarding actually implementing it. so I'm keeping an eye on chandler.

- yes, it does sound a lot like 'spaces' (which in turn sounds like groove), although chandler strikes me as being more flexible/scalable, but that's just based on very superficial skimming of the tech

- PINE is what I currently use for exactly the reasons meuon stated above. But it really doesn't cut it any more. I still use it, because everything else cuts it even less. If I could get zoe to run under OpenBSD I might have a new winner, though.

- i also want a "my palm on steroids", something that not only syncs with my palm but also seamlessly networks between my various machines, so I can get that phone number from my palm, from my windows desktop using a nice GUI, or from my BSD box via gnarly console tools. I want to be able to "print" a web page from lynx into my palmpilot.

Actually, I'm talking about Gnus. GNUS is something else. And please feel free to go there; I'm pretty sure I'm not the only Gnus user present. If you don't like the One True Editor, fine -- but that's not a reason to slag on Gnus.

PINE is what I currently use for exactly the reasons meuon stated above. But it really doesn't cut it any more. I still use it, because everything else cuts it even less.

Hmm. Like I said, I use Gnus for the same reasons meuon gave for using Pine, and it is sharp enough to cut the problems that I need sliced. Perhaps you should look into it.

John -- you're right that you aren't the only Gnus user around. I'm working on the nnrss backend for Gnus, so I guess you could say I'm committed.

And, canis, what is "emacs script"? FSF Emacs uses a varient of Lisp and all the Lisp I've seen out-powers Python. White-space as syntax? I'm /so/ not going there.

I actually use vm, which is yet another fricken emacs script. I've become quite enamoured of fricken emacs scripts, although I haven't delved much into Lisp beyond the occasional key binding and similar customization.

Really, emacs is a run-time environment, just like Windows, except that emacs provides much better support for complex data structures and manipulations, and rather than providing a lousy excuse for an operating system adapts to whatever it's run on. In fact, if there were better documentation and a little less dependence on lore for emacs development I'd probably be playing with these concepts in that.

I've been with John and Mark on Python: I got over whitespace as syntax around the time I realized that MVS/JCL and PL/1 were bad ideas, and what I've seen of Python as a language reminds me too much of "theorist" languages like Modula-II, too many ideas about software engineering imposed through the syntax. Maybe just continuing with my Perl and Tk diddlings is the right way to explore this application space.

I'll second meuon's comments regarding SSH/Pine, except that I prefer to use my e-mail client of choice tunneled through SSH. SSH tunneling is sublime.

Dan accidentally sums up what I mean by "Emacs script": Emacs is a runtime environment for LISP. The syntax is "just LISP" but the "libraries", if you will, are Emacs. If you take a LISP program written for use with Emacs, and try and use it in a non-Emacs environment, you are likely to run into issues (including but not limited to abject failure) just as if you try and compile a Win32 application under UNIX, even though they both have compatible C compilers.

The only advantage I can see is the macro language; and even that facility could be added to Python as a runtime module, it's that introspective. I discussed this recently with a friend of mine who used to use LISP extensively (in fact, both wrote code for, and maintained, the custom Scheme implementation his company used), and liked the macro facility, but couldn't stand to use the language any more... the poor chap was using VC.NET last time I looked. See what lengths LISP has driven him to! ;-P

The problem I have with LISP is that it is effectively "assembler for a theoretical list-processing CPU". In other words, it has all the disadvantages of assembler -- aggresively antisocial syntax, the user must build everything built up from primitives, etc -- and can't even claim to be fast (asm's only advantage). Now there's a "theorist" language if ever I saw one. Just because you can reduce everything to primitive list operations doesn't mean you should.

I was addressing Dan who wrote "Damn, I may have to learn Python." right at the start of the thread. If you're happy with PERL, fine. I'm not.

Except that you have to use Emacs in order to use Gnus, which means that if you do not wish to use Emacs, Gnus has a pretty large mark against it before we even look at anything else. Just as, if you don't have, use, or wish to use Windows, any Windows client has a pretty large mark against it before you even look at anything else. Notice I didn't slag anything else about Gnus off.

Also, if you look at Chandler's goals, they see it as very important to provide these facilities to people who are not hard-core UNIX hackers, and rightly so. I don't see the need for people like doctors, non-CompSci researchers, and businesspeople to learn Emacs and LISP in order to work collaboratively.

Whitespace as scope works fine. I haven't used MVS/JCL or PL/1. They may or may not be bad ideas, but if they are, I doubt it's because of whitespace. I've yet to hear a reasoned argument against it that doesn't depend on environmental issues that are a product of the arguer's working environment. Me, I fixed my working environment.

Python may remind you of a "theorist" language, but it's a fiercely practical one. I'm not interested in theorising, I'm interested in getting code written. That's why I like Python. Are there any examples of "theoretical" behaviour you'd like to cite? If you're suggesting it's a "B&D" language, I assure you it's not; I've never had to "fight" Python to get something done, in that way that (to take one notorious example) I do regularly in C++.

I don't actually care what you use, I'm not interested in flaming about it; I'm just recommending something I find useful. When you get down to it, use whatever you consider most appropriate to the task at hand. Personally, I find that to be Python. I say that as someone reluctant to evangelise any language, and I've seen a fair few over the last 20+ years of coding. Python is perhaps the first language in all that time I actually like, as opposed to merely hating less than the previous ones.

I've been tunneling ssh through a linksys home router for two years now. Is there a problem I should know about?

Wouldn't you run into those same issue if you took a bit of Python written to work with Chandler and run it in some non-Chandler Python environment? So what if a lot of Lisp written for Emacs is particular to Emacs. I'm guessing that a lot of Python written for Chandler will be particular to Chandler. "Chandler script" is what I'll call it.

Oh, but they should learn Chandler (or Outlook, or ...)? Come on. Emacs is no harder to learn than any other environment and Emacs' dialect of Lisp is no more difficult than XL macros. My father can handle XL macros -- He started on 123 in the 80s and kept updating his stuff. (Now retired, he was a QA guy for a rubber plant and then a carbon black plant.)

And I know of a grizzled, country gospel song-writer who uses Emacs for his work. Someone contacted me about some "emacs script" I had written to do weblogs on Blogger.com and said that emacs was the only way he could do the blog thing.

So, if people like my dad and Paul Stewart can handle things like XL macros and Emacs, I'm pretty sure that well-educated people like doctors and non-CompSci researchers could handle Emacs if they knew how well it suited their needs.

But, in all fairness, canis, I'm glad you like Python. You seem to feel about Python the same way I feel about Perl and Emacs Lisp. Its a good feeling. Go with it.

Oh, re: macros. To do macros like Lisp does macros, you pretty much have to have Lisp's syntax. Lisp's macros are so wonderful because everything is an S-Expression. Since other languages don't have as syntax that also serves as a data structure, any attempt at macros will be lacking the power that comes from Lisp's macros.

dws: The problem I have with the router (BEFSR41) is that it seems to cause "Disconnecting: Corrupted check bytes on input." errors; I was having problems with this when I first set up my BSD box and assumed I'd configured something incorrectly until I did some googling and found lots of other people had the same problem, and they all had BEFSR41 routers... I suspect it's something to do with it getting confused about NAT vs non-NATed addresses when calculating checksums. Say you connect from 192.168.0.10 to 192.168.0.11 -- no problem. But if you connect from 192.168.0.10 to your_real_IP and have the router set up to forward port 22 to 192.168.0.11, then you get disconnected regularly; if you connect from outside the LAN, it's less flaky but still unreliable. It's mildly annoying for interactive sessions, and crippling if you're forwarding CVS, POP3 etc across the tunnel.

Well yes, of course. Is there a problem with that? *blinks* I gather "Chandler Parcel" is the official term, but hey, whatever works.

I wasn't using "Emacs script" as some kind of derogatory term for LISP (I have so many others for that ;-P )

Perhaps if you qualified it as "Emacs is no harder to learn than any other programmer's development environment and LISP-based operating system from the '70s" I'd agree ;-P but sit two relatively neophyte computer users down, one infront of Emacs and the other infront of, say, MacOS, and see which gets their work done first. Your dad and Mr Stewart at the exceptions, not the rules.

Chandler users as opposed to Chandler developers will never need to look at a line of Python, even for complex automation tasks (according to the guys at OSAF; this is referenced in the page Dan originally linked to, by the way).

Oh, as for everything being an S-expression, see under "just because you can, doesn't mean you should"...

No, I'm not baiting you re: ease of use/ease of learning. For example, my wife uses Gnus to read email. These people aren't the exceptions except in the fact that they are going on a road less traveled and they have the means (usually another person or a book) to help them learn. I don't think their ability or motivation to learn really out-strips the average user when it comes to the environment itself. Scripting the environment (whether through Emacs Lisp, VBA or Python does require some motivation.

What's the task? Moving files around? Maybe a GUI would be better after you explain that the pictures represent files and that they can move the pictures by holding the mouse button down and dragging it around -- do you realize how many people struggle with mouse-button during drag-n-drop initially? -- and then showing them the two folders that contain the files and showing them that if they put the file picture on top of the folder picture that puts the file picture /inside/ the folder picture. Or you could just tell them "C-x d directory RET C-s filename RET R new-directory RET"

Of course, I'm not talking about relative neophytes here. I'm talking about complete neophytes. If you have no computing paradigm, then adopting a GUI is no easier than adopting Emacs. Point being, people have the ability to learn these things. It is a freak of marketing that led most current users down the Windows path. Don't underestimate the user.

Since I assume all their protocols will be documented, it shouldn't be that hard to integrate other PIMs (like Emacs) into the environment. If there is a compelling reason for me to want that interaction, I'd probably do my part to get Emacs integrated.

I need to take some time to clarify my own thoughts here, and that's not going to happen today, but the two things I just have to jot down are:

Anybody who seriously believes that needs to get their ass down to their local La Leche League meeting and talk to some mothers who are having trouble getting their kids to take the breast.

> Anybody who seriously believes that needs to get their ass down to their local La Leche League meeting ...

When I saw that Dan had used that quote about the nipple again I wondered how long it would be before the La Leche League would be invoked and then I scrolled down to see that it didn't take long. This isn't the first time that that quote has brought forth that same observation. Dan started it the other time I know about, too. It was also a relatively new dad that took exception to the quote. :)

Most babies will intuitively suckle a nipple if they are introduced to the nipple within a short time of their birth and they are not introduced to a bottle. There are exceptions to that rule as there are to all other rules. Pretty much the same can also be said about the GUI. You folks that find the GUI to be counterintuitive, or not as intuitive as promised, were just introduced to the command line too early in your computing lives. :)

This statement sits so far outside my sphere of experience that I can scarcely believe you mean it seriously. Emacs is all the reasons people think command lines suck, rolled up into one terrifying ball of idiosyncratic terms and symbols. It is the most opaque, convoluted piece of software I have ever tried. Even vi made more sense to me than emacs, and I can't stand vi. My dad has two master's degrees and has been using computers for twenty years. If I sat him down in front of emacs he'd look at me like I was trying to hurt him and go straight back to his Mac.

Yeah, I'm sure it's powerful, and yeah, I'm sure I could learn it if I were sufficiently motivated. But that doesn't make it better. Abstractions are good. Simplicity is good. Not everything needs to be a programming language.

This isn't the first time that that quote has brought forth that same observation. Dan started it the other time I know about, too. It was also a relatively new dad that took exception to the quote. :)

I'm not surprised -- women that have problems with getting their babies to suckle generally go through what looks like a pretty bad emotional place; there seems to be a lot of rejection perceived there, unsurprisingly. Seeing that sticks with you -- and it makes that quote jar just a bit.

Abstractions are good. Simplicity is good. Not everything needs to be a programming language.

Abstractions and simplicity are not always good. Sometimes (I would argue most times, actually), there's a trade-off between power and ease-of-use. To bring this argument back to where it started, if you get enough mail (FVO "enough" that vary by person, but I'm at the 500-1000/day mark at both home *and* work, and that's "enough" for me), then it behoves you to be able to approach the reading, archiving, and/or disposal of this mail with some fairly powerful tools. The need for the power means that you're going to have to learn to use them, and the interface you're going to learn is going to resemble some sort of programming language, if only to the extent that you're going to have to know something about regexps.

Now, if you only get 10 emails a day, then you can use a nice simple abstacted interface involving envelopes and stamps and other metaphors to make it easier to understand what's going on. That's not a problem. But lots of that sort of MUA exist already, and I don't think Chandler is trying to plan a flag in that space.

Just because I have a different experience then you is no reason to disbelieve my seriousness when I relate my experience to you.

My computing paradigm is probably extremely different than the concepts most people use. I started out on the command line. My first exposure was to on an Apple II or a Commodore 64. My family bought a TRS-80 just as Radio Shack was EOLing them and I spent hours on it figuring out how to pull up MicroSoft's Basic interpreter (which launched from an 180k floppy). I later found CP/M and played around with that (I don't think they ever made UNIX for the Z-80 processor ;-)

So, yeah, I guess I was exposed to the command line first and for a much longer time than most other people. But, I'm still serious when I say that even your average user has the capability to use Emacs.

It is also good to remember that the first major commercial users of UNIX were using it to create and typeset documents -- something that most people today would go to a What-You-See-is-All-You-Get tool (e.g. MS Word) rather than the superior What-You-Get-is-What-You-Mean model that is used in Latex/XML document processing.

Do people really think that command lines suck? That's why Apple put a powerful command line in Mac OS X after all these years of pure GUI goodness, right? Because command lines suck.

In fact, Apple made the most saavy decision possible. Continue to use their past marketing effort ("Mouse, Pictures are good! You are sooo cool!"), but extend it by putting the graphical shell on top of UNIX.

But putting the command line underneath OSX, Apple provided itself with a broader user-base (geeks who like pretty pictures but still want to get work done are now buying Macs), they provided their current "power users" with room to grow, and they expanded their developer base because it now costs nothing to develop for the system. If it doesn't give them the market-share edge on Microsoft, it at least keeps them afloat.

And all this because they added a command line despite the "command lines suxors" crowd.

Sucks for him if all he has ever tried is the Mac. But, he's in luck! The mac now has a command line! "sudo fink install emacs" is his friend. A 10x increase in productivity is just around the corner.