Saturday, October 3, 2009

BA Chap. 11 - GNU Emacs

When I first began exploring the various applications that came with Fedora Core 3 in 2004, I originally thought Emacs was an over-bloated text editing application, with meaningless features. But reading this article made me realized how much I missed out!

One of the coolest features is its ability to pipeline commands for text to be navigated, searched, organized, trimmed, and sorted all at once. As the article explained, this is possible due to their Model Design of text buffers. Also, it provides support for text terminals while simultaneously managing graphical frames. These are features you can't do with Visual Studio nor Eclipse.

Using the MVC pattern is a natural choice for text editing applications. It proved to be particularly useful in the case of Emacs since their Controller code, in isolation from the Model & View, was almost done entirely in Emacs Lisp. I haven't written code in any language related to Lisp but, apparently, Emacs Lisp provides the following advantages:

1. Making small changes/additions requires little programming effort compared to other strongly-typed languages. "You can write a useful command in under a dozen lines"
2. Can test expressions in the Emacs buffer for immediate evaulation. This is similar to how you can test PHP & Python regular expressions at websites such as http://re.dabase.com/
3. As a unique programming language, it's powerful enough to make sense of thousand-line programs.
4. It doesn't crash when run-time bugs are encountered but it does report the errors. Since I don't know the technical details, I wonder how they handle null pointers and the avoidance of data corruption. I would think one would prefer to crash the application then to continue running and corrupting data.

My only concern about the architecture is that every function in a package is visible to other packages. What happened to Encapsulation? Wouldn't these lead to complex dependencies if functions just started referencing functions from other packages at will? Also, I was expecting the article to explain the Model's complexity in its section, "How complex is the Model?". But all it really does is explain how it doesn't support stylessheets, among other features, as in the case of Microsoft Word documents.

Lastly, I did enjoy reading about how it compares & contrasts with Eclipse & Firefox. Although it bashes Eclipse for all the boilderplate code necessary to implement a simple plug-in, from an Eclipse user's standpoint (not from a developer perspective), this is a straight-forward and convenient architecture. And the author took the opportunity to credit Emacs for Firefox's successful architecture since the Emacs project may not be around for too long.

No comments:

Post a Comment