Star Trek

The first Star Trek movie I've looked forward to since Wrath of Khan...

The Emacs Way

I had a good beer talk this week with Merlyn about IDEs and Emacs. Merlyn's been playing with Clojure, a Lisp for the JVM. And he was looking at the effort it might take to provide support for Clojure in IntelliJ. Our conversation started briefly before the http://xpdx.org meeting.

"Why not Emacs?", I asked.

Merlyn's face scrunched up a bit in that look that Emacs seems to cause on many programmers' faces.

"Emacs has had great support for Lisp for decades.", I pleaded. "I like that Clojure is bringing a lot of programmers to Lisp these days. You only have to learn a bit of Emacs to use it for Lisp. It's not any harder than learning Lisp itself."

"Yeah. Maybe", Merlyn told me, unconvinced. Then the meeting began.

After the meeting, over at the Side Door, with a good, draft Pilsner in hand, I was asked by Merlyn, "What's the fundamental difference between an IDE like IntelliJ or Eclipse and Emacs?"

The argument I made was this: In Emacs, everything is a buffer. If you edit a program, it is in a buffer. If you edit a directory or even just choose a file in a "dialog", it is in a buffer. Some of the functions in the directory buffer are directory and file-specific. Most are just general editing functions. If you run a shell or any subprocess, that process' input and output is in a buffer.

And across all these buffers the contents are made up of text, but also things analagous to words, sentences, paragraphs, etc. Many functions operate as expected within "text editing" even though the more specific mode is for files, or programs, or email, or whatever.

I compared this to what little I know of the Eclipse-like IDE, especially Eclipse as a framework for building extensions. In Emacs this is easy and many people build small or large extensions. In Eclipse my sense is this is relatively more complex and not as many people, as a percentage of total users, extend Eclipse in any significant way.

Here's what I think the Eclipse framework provides: an "architecture" for an editor. There is an implementation of the text editing area; there is an implementation for those tabs at the bottom where build results and test results go; there is an implementation for those trees to the left where file and class hierarchies are displayed; and there is an implementation for the pop-up dialogs that ask you to choose a file or set a property of some kind.

The problem is these are all big imposing structures with an "A.P.I." - users cannot edit their contents in general ways, and extenders cannot extend them in general ways. They a "CLASSES" which are supposed to be "ABSTRACT" and "MAINTAINABLE".

Horse hockey! The Emacs way wins even if the culture is all for IDEs as a Pascal-ish Pyramid.

Wel, I didn't explain my reasoning with that much enthusiasm, but by the end of our discussion I *think* Merlyn's willing to give Emacs a try.

Some references...

• "A Cookbook for an Emacs", Craig Finseth
• "EMACS: The Extensible, Customizable Display Editor", Richard Stallman
• Foreward to Structure and Interpretation of Computer Programs, Alan Perlis

The foreward by Perlis does not address text editing or Emacs at all. It addresses Lisp. The Emacs way *is* the Lisp way. They grew up together. Neither would be as good without the other. Maybe neither could have existed for so long without the other.

From Perlis...

Algol 60, never to be an active language again, lives on in the genes of Scheme and Pascal. It would be difficult to find two languages that are the communicating coin of two more different cultures than those gathered around these two languages.

Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place.

The organizing principles used are the same in both cases, except for one extraordinarily important difference: The discretionary exportable functionality entrusted to the individual Lisp programmer is more than an order of magnitude greater than that to be found within Pascal enterprises. Lisp programs inflate libraries with functions whose utility transcends the application that produced them.

Even scarier...

Maybe I am more afraid of this blog and the people who comment on it,
than I am even of Paulson...

http://www.prisonplanet.com/paulson-was-behind-bailout-martial-law-threat.html

Welcome to Y2K redux?

Hank Paulson, $700B, No Oversight, and Martial Law

We cannot get Hank Paulson out of power soon enough. Via Steve Dekorte...

"Senator James Inhofe has revealed that Henry Paulson was behind the
threats of martial law... prior to the passage of the bailout bill..."

http://www.dekorte.com/blog/blog.cgi?do=item&id=3723

Smalltalk and UIs

Stefan Tilkov nearly apologizes for saying...

"I can't help but wonder why VW and the apps built with it have a UI
that sucks so much. Smalltalk is pretty obviously a great language,
the development environment is great – why is there no support for
native UIs?"

http://www.innoq.com/blog/st/2008/11/smalltalk_uis.html

First, this is nothing new. Second, don't "native UIs" generall suck,
no matter what the implementation language?

But today I believe it is possible once again to say that Smalltalk is
at the forefront of user interaction. It just has more company in the
way of other languages and frameworks.

I would off as evidence Seaside, Croquet, and even the work Michael
Lucas-Smith, et. al, are doing with VW and Cairo.

Don't expect the innovation in UIs to be happening at the level of
traditional desktop widgets. Not that there's not room for improvement
there. For my money that's happening with Flash/Flex and, ahem,
SIlverspoon. As of a year or so ago there was a Smalltalk running in
both those environments, but the blog seems to have turned its lights
off.

VW could be a good VM / environment in competition with those in
search of a widespread audience, but that does mean it's a good use at
this time of development and marketing resources. So probably "Ho,
hum. Things are happening elsewhere for Smalltalk as they are for
other languages."

Server-side Actionscript

http://www.swartzfager.org/blog/index.cfm/2008/11/19/Sneak-Announcements-at-MAX--Serverside-ActionScript-and-Durango

Those Crazy Patents!

A clever patent...

"A method of providing Resource-Event-Agent (REA) model based security, the method comprising: identifying an association between a first object and a second object in an REA model; creating an association class for the association between the first object and the second object, the association class defining security between the first object and the second object."

http://www.wipo.int/pctdb/en/wo.jsp?IA=US2004023829&DISPLAY=CLAIMS

Yes, this patent (or is it still just an application for a patent?) is for associating a set of security properties to an association between to objects. Damn clever of them. Never would have thought of that.

No Silver Scrum Bullets

Bob Martin...

"Of course it's true that a two day certification course is neither necessary nor sufficient to create a good software leader. It's also true that the certificate you get for attending a CSM course is good for little more than showing that you paid to attend a two day CSM course. It's also true that scrum leaves a lot to be desired when it comes to engineering practices. But it is neither the purpose of scrum nor of CSMs to make engineers out of us, or to instill the disciplines of craftsmanship within us. That's our job!"

http://blog.objectmentor.com/articles/2008/11/16/dirty-rotten-scrumdrels

Yes! There is no process description for any creative, collaborative activity anywhere in the world, in any language or notation, that can make up for a lack of brain waves. Process descriptions are at best the starting battle tactics of a long, hard war.

When I taught, and now when I talk, about "agile" my key point is that these are merely tools that may help communication among collaborators who have (or should have) a shared objective. The tools will not do the thinking or the communicating for you.

15 Helpful In-Browser Web Development Tools

http://saravananrk.wordpress.com/2008/11/19/15-helpful-in-browser-web-development-tools/

Improv

I attended the second of seven intro to improv classes at the Brody
Theater tonight. Last week was mostly group games - improv in a big
circle, mostly actions, some sounds and words. Tonight we transitioned
from whole-group action games to small group emotion and scene
games... limited to sounds and/or gestures still. A lot of good
lessons learned both classes - I won't write those here - the
instructor is emailing them and I may list them or pick a few out in
more detail if the mood strikes me.

Several of the games have involved quite a bit of movement. I have an
injured right shoulder from an accumulation of abuse, the least of
which is not my physical enthusiasm at the Oregon State game Saturday.
But I played through the pain tonight, and now I am in continuing
discomfort - and I fear a good deal of pain in the night and the
morning. I need heat.

http://www.brodytheater.com/classes.html

A lot of these games are very, very easy and fun - e.g. for an improv
session at an open space conference.

Caching and the Tool What Drew It

Nice article on HTTP caching...

http://tomayko.com/writings/things-caches-do

Handy tool that draws the diagrams...

http://www.websequencediagrams.com/

Saving for a Rainy Day

Oregon didn't. We loved our kick back a year ago though. Spent it
on... well, we spent it.

http://www.blueoregon.com/2008/11/we-could-really.html

Now we've got 7.something unemployment, crumbling bridges, and a
crumbling economy.

Didn't some god tell some ancient people some time long ago to save up
your food store for the lean times?

ScalaCheck

ScalaCheck is derived from, and expands on, QuickCheck for Haskell.
Similar kinds of tools have been developed for Erlang, etc. Seems to
be useful for Java and other languages as well. I've not tried it yet,
but plan to.

One thing to note - I don't see these xCheck tools as replacements for
TDD and unit tests per se. Rather they are an addition to them, and
are more of a functional test tool. But I've not used any of the
xChecks for more than kicking the tires so far.

http://code.google.com/p/scalacheck/

Nothing New

What Jim is observing is a problem, but I don't see this as a decline
from a previous position. This has been a problem all along...

http://www.infoq.com/news/2008/11/decline-of-agile

"James Shore has declared agile to be in decline. He cites the many
teams doing 'sprints' and stand-up meetings, without adopting any of
the technical practices necessary to produce high-quality software
over the long-haul. In his estimation, this has led to thousands of
Scrum teams doing agile so poorly that they will almost certainly
fail, and possibly take the agile movement with them.

James lays a large portion of the blame on Scrum, and the
misapplication of Scrum. He compares Scrum with Extreme Programming
(XP) and notes that Scrum intentionally leaves out the engineering
practices that XP includes. Scrum is silent on topics such as pair
programming, test driven development, continuous integration, and test
automation. Without such practices, a team can quickly build a large,
buggy, and unmaintainable code base. This then becomes a weight around
the neck of the team, preventing them from responding quickly to
change, as an agile team should.

James thinks it's not all the fault of Scrum, however, as each team
must take responsible for its own success or failure. Many are
choosing to adopt only the superficial, and easy, parts of Scrum such
as short development sprints and daily stand-up meetings, while
ignoring harder, yet critical practices such as reflecting and
improving. Via this process, teams are empowered to identify and adopt
the engineering practices that they need to deliver shippable software
every iteration. Unfortunately, many teams fail to take this step."