Even though I’ve been using Emacs for years, I still have trouble
remembering a lot of the key combinations for commands that I
don’t use all the time (e.g.: killing and yanking rectangles,
bookmarks, etc.). I think Lotus 123 for DOS had a remarkably cool
user interface in that the menus let you explore around and find
things if you were a newbie, but once you knew the key sequences,
you could become very fast with it. This is my attempt at doing
something like the Lotus 123 menu system for Emacs.
The above elisp defines only the primitives for creating menus and not the menus themselves. The nice thing about this is that the user is free to define whatever menus and keybindings are most convenient for them.
Here’s an example of how I use it in my .emacs:
If you use this, let me know what you think and if you have any suggestions for improvements.
Interesting to see that Scheme is moving forward, though not everyone is totally happy with the direction.
Arto Bendiken: R5.97RS Scheme Considered Harmful
A bit of Scheme code that I was dorking around with a long time ago and never got around to posting. This probably only works in MzScheme since it uses implementation-specific APIs to do HTTP.
Here’s an example of using it:
Welcome to MzScheme version 352, Copyright (c) 2004-2006 PLT Scheme Inc.
> (load "yahoo-web-search.scm")
(let ((result (result->struct x)))
(printf "~s~n" (result-url result))))
(# # # # # # # # # #)
I’m no Scheme expert so this code is probably not particularly smart or readable, but maybe it will inspire somebody…
Here’s a page (from a blog that’s on my blogroll) which links to two screencasts that show using LispWorks (a Common Lisp implementation on the Mac with a nice IDE) to do HTTP client and server stuff and then to develop a Reddit-like web site in around 20 minutes.
I think these would be very impressive for someone who is a die-hard C/C++ coder
and who hasn’t played around much with Python, Ruby, etc. They are probably less impressive to the Python and Ruby crowd or to people who have watched screencasts for Ruby on Rails, Django, TurboGears, etc. Or the campy Erlang movie.
The main thing that is shown in these videos is the fluidity of developing in Lisp – the ability to make a change and see it right away without a lengthy compile/link. This of course is nice but is not unique to Lisp. There are also some neat things shown regarding the LispWorks IDE, but these have more to do with the IDE than with the Lisp language. The thing that is shown that seems most unique to Lisp is the seamless embedding of the HTML generation in the code via the clever use of s-expressions. On the other hand, the value of doing this is questionable as this is essentially throwing out the concept of separating presentation from logic and making it impossible to farm the web design out to the Dreamweaver crowd.
One interesting thing I noticed is that it was easy for me to follow along and to understand the code as he was writing it, but in the end the code had the quality that Lisp has for me – that is, the meaning of it does not leap off the page. I can follow it, but only after mentally parsing the indentation while ignoring the wash of parentheses and internally translating the
So while I like the whole rapid prototyping, incremental development vibe illustrated here, I still feel like I’d rather do it in a different language.
Sorry, no red pill for me just yet.
I like reading Paul Graham essays from time to time, but sometimes he makes me scratch my head.
In his “Revenge of the Nerds”, essay he says:
“As one data point on the curve, at any rate, if you were to compete with ITA and chose to write your software in C, they would be able to develop software twenty times faster than you. If you spent a year on a new feature, they’d be able to duplicate it in less than three weeks. Whereas if they spent just three months developing something new, it would be five years before you had it too…So when I say it would take ITA’s imaginary competitor five years to duplicate something ITA could write in Lisp in three months, I mean five years if nothing goes wrong. In fact, the way things work in most companies, any development project that would take five years is likely never to get finished at all.”
Ok, a twenty-fold increase in productivity. So does anyone see the irony when he speaks of his new language Arc (which is built on top of MzScheme) in http://www.paulgraham.com/arc.html:
“Arc is a new dialect of Lisp we’re working on. It isn’t ready yet for general consumption…When will that be? We have no idea. We reserve the right to take a very long time. It’s been almost 50 years since McCarthy first described Lisp. Another 2 or 3 aren’t going to kill anyone. So please don’t send us mail asking what Arc’s status is or when it will be done. (When it’s done, we’ll tell you.)
Now I realize that he may be busy working with startups and painting and writing essays and it would be understandable if he were implementing his language with something less powerful than Scheme – say something that’s only five times more productive than C. But twenty times? I guess we should be glad that he’s not writing it in C – in that case, I guess we’d be waiting 60 years.
Now obviously I’m only half serious here – I have no idea what’s going on with Arc, as there’s not a ton of info about it online. Might a team using C take substantially longer than a team using Lisp? Sure. But I’d speculate that a team that picked C for such an application (or was forced to use it) has deeper problems.