Brandon wrote:
If the goal is to get business people interested in Lisp, wouldn't an Eastside venue such as Bellevue Community College or Digipen be more appropriate?
The business aspect is more of an outreach project. We'll most likely work with the WSA, ACM or perhaps UW to issue surveys. Subsequent interaction might take the form of a 1 or 2 day conference, and Meydenbauer Convention Center in Bellevue might be appropriate. I'm not expecting business executives to attend presentations by Lisp programmers. Such a conference might involve the Assoc. of Lisp Users (ALU) for legitimacy and would most likely be a year away. Promoting Lisp is a longer-term effort. First, we need to resolve important logistic details within the Lisp community itself. For example, with Python, you have "one stop shopping" for nearly all your needs. With Lisp, first it's which flavor? Then, which implementation? And of course, there is the matter of de facto libraries. (With Common Lisp, ASDF and ASDF-install should be standard but aren't because they arrived after the ANSI spec. With Scheme, you have the Revised^nth game...) Within a business perspective, these details add complexity, which in turn adds risk. In an effort to resolve all this, the early sessions I described yesterday are a first step. After a few months, maybe we'll come out with our own InstallShield-built packages or perhaps LispBox will be even more mature. Or maybe we merely each contribute a blurb to the new Lisp FAQ project: http://www.lispniks.com/faq/faq.html Either way, much of the activism is to get Seattle programmers more involved and contribute that much more to the Lisp community at large. By working together, the amount of work by any one individual remains quite small, but for any of us to do it alone would be more than a full-time job. I'm a practical idealist. :) -Daniel
Daniel J Pezely wrote:
I'm not expecting business executives to attend presentations by Lisp programmers.
Ok, I understand now. And considering the amount of effort I've put into making Chicken Scheme end-user friendly, the packaging problems are definitely non-trivial. XEmacs has a packaging system; in theory I could have gotten my Scheme modes from that. In practice, the packaging download mechanism is broken on my Windows installation, due to some perverse interaction with MSYS. It shouldn't be happening, because XEmacs is installed natively and shouldn't know about my MSYS environment. So I had to manually install it, which wasn't hard as it's explained on the XEmacs site pretty well, but it increases the 'chore' level. For sanity I also had to configure cua-mode.el to get the Ctrl-Z Ctrl-X Ctrl-C Ctrl-V behavior I'm used to. Can't abide learning a whole new way to use my fingers. So that required the full learning curve about how to configure site-specific .el files. Plus I had to check whether cua-mode.el worked with XEmacs; at one point I was led to believe that it didn't. There's that GNU Emacs / XEmacs compatibility paranoia. In principle, XEmacs is better for a Windows developer than GNU Emacs. In practice, it's not off-the-shelf. For awhile I was going to use SchemeScript in Eclipse, on the principle that Windows users would find Eclipse more palatable than XEmacs. But the plugin never worked properly for me. I gave up several months ago and accepted XEmacs, which I had been resisting for a long time. I still crank up Visual Studio because it has an easier-to-use Find In Files function than a grep command line. Plus every time I try to bind grep to a keystroke, my settings aren't saved! More futzing. It takes awhile to get rid of the handicaps in XEmacs. Especially if you're busy and mainly worried about slinging your code. Cheers, Brandon Van Every
participants (2)
-
Brandon J. Van Every -
Daniel J Pezely