The first Star Trek movie I've looked forward to since Wrath of Khan...
"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
"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.
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.
Welcome to Y2K redux?
"Senator James Inhofe has revealed that Henry Paulson was behind the
threats of martial law... prior to the passage of the bailout bill..."
"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
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
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
"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."
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.
"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!"
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.
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.
A lot of these games are very, very easy and fun - e.g. for an improv
session at an open space conference.
Now we've got 7.something unemployment, crumbling bridges, and a
Didn't some god tell some ancient people some time long ago to save up
your food store for the lean times?
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.
"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."