Slava Akhmechet wrote a piece a while back that that challenged my thinking in terms of design using an old familiar friend and adversary: Ant. If you are a Java programmer, you’ll recognize the patterns Slava is connecting with to share with you why Lisp is so interesting. BTW, this piece would work doubly well with Maven if it was updated. Go read.
Hopefully you’ve read the docs and know that you can override settings and implement your own extensions rather easily:
Create a Lisp file under
~/.emacs.d/ specific to your username (
$USER-NAME.el) or system (
$SYSTEM-NAME.el) that Emacs with emacs-starter-kit will load automatically at startup.
I’ve created mine specific to my user name –
~/.emacs.d/kmarti05.el. You can determine the value of your user-name in emacs by issuing
Here is the contents of my
;; visible bell (setq visible-bell nil) ;; allow selection deletion (delete-selection-mode t) ;; make sure delete key is delete key (global-set-key [delete] 'delete-char) ;; turn on the menu bar (menu-bar-mode 1) ;; have emacs scroll line-by-line (setq scroll-step 1) ;; set color-theme (color-theme-zenburn) (defun my-zoom (n) "Increase or decrease font size based upon argument" (set-face-attribute 'default (selected-frame) :height (+ (face-attribute 'default :height) (* (if (> n 0) 1 -1) 10)))) (global-set-key (kbd "C-+") '(lambda nil (interactive) (my-zoom 1))) (global-set-key [C-kp-add] '(lambda nil (interactive) (my-zoom 1))) (global-set-key (kbd "C-_") '(lambda nil (interactive) (my-zoom -1))) (global-set-key [C-kp-subtract] '(lambda nil (interactive) (my-zoom -1))) (message "All done!")
Is Programming more like ‘art’ then ‘science’? A debate that is continuous, but I know where Richard P. Gabriel stands. In 2003 he wrote the forward to “Successful Lisp: How to Understand and Use Common Lisp,” by David B. Lamkins titled “The Art of Lisp and Writing”. Recently it got shared at “Hacker News”.
I admit to knowing enough about Lisp to be intrigued (inspired by it even) but have never used it at work or in a personal project. His essay while touching on some differences between Java and Lisp (and he would know – he worked at Sun), talks more of the act of writing and creation and how programming is akin to that. It was a good read.
Taught that programming–or the worse “developing software”–is like a routine engineering activity, many find difficulty seeing writing as a model or even a metaphor for programming. Writing is creative, it is self-expression, it is art, which is to say it isn’t a science and unlike science and engineering, it isn’t a serious activity. Judgments like this, though, are easiest made by people who don’t seriously engage in making both science and art. Art, engineering, and science are–in that order–part of a continuum of finding truth in the world and about ourselves.
…The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you’re inadvertently making.
There are, of course, many situations when making change more difficult is the best thing to do: Once a program is perfected, for example, or when it is put into light-maintenance mode. But when we are exploring what to create given a trigger or other impetus–when we are in flow–we need to change things frequently, even while we want the system to be robust in the face of such changes. In fact, most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art. And the reason is that the requirements for a system come not only from the outside in the form of descriptions of behavior useful for the people using it, but also from within the system as it has been constructed, from the interactions of its parts and the interactions of its parts separately with the outside world. That is, requirements emerge from the constructed system which can affect how the system is put together and also what the system does. Furthermore, once a system is working and becomes observable, it becomes a trigger for subsequent improvement.
Read the whole piece.
Mike Taylor on Kernighan and Plauger’s “The Elements of Programming Style” (gotta buy and read this)
Deseret Tech: “NoSQL v. SQL is the worst holy war ever.”
Dennis Forbes: “Getting Real about NoSQL and the SQL-Isn’t-Scalable Lie”
Jesse Legg: “Emacs for Python Programmers: Basics”
the official hudson weblog: “Hudson at PyCon”
The website of Lei Chen: “Setup Perfect Python Environment In Emacs”
Extra Cheese: “Python vs. Ruby: A Battle to The Death”
Martin Fowler: “ConversationalStories”
Code Monkeyism: “What Developers Need to Know About Agile”
Coding Horror: “Cultivate Teams, Not Ideas”
Geoff Sowrey: “What makes a Senior Developer?”
At work props go to Michael Bevilacqua-Linn and his great brown bag on Clojure. I think it helped a few of us not only get exposed to Clojure, but Lisp as well.
Here are some great starting points for the procedural-biased:
defmacro: The Nature of Lisp – absolutely fantastic. Uses Java and XML examples to help bridge the conceptual divide.
Ward Cunningham’s WikiWikiWeb: LispUsersAreArrogant entry.
Steve Yegge’s Lisp is not an acceptable Lisp
Stuart Sierra: Clojure is a Lisp worth talking about
News and Blog: Getting it
Steve Yegge: Emergency Elisp
Me? I have a lot of practice ahead of me to become proficient, but since Emacs is my editor, it comes naturally.
Steve Yegge: My Save Excursion
Martin Folwer: BusinessReadableDSL:
I do think that programming involves a particular mind-set, an ability to both give precise instructions to a machine and the ability to structure a large amount of such instructions to make a comprehensible program. That talent, and the time involved to understand and build a program, is why programming has resisted being disintermediated for so long. It’s also why many “non-programming” environments end up breeding their own class of programmers-in-fact.
That said, I do think that the greatest potential benefit of DSLs comes when business people participate directly in the writing of the DSL code. The sweet spot, however is in making DSLs business-readable rather than business-writeable. If business people are able to look at the DSL code and understand it, then we can build a deep and rich communication channel between software development and the underlying domain. Since this is the Yawning Crevasse of Doom in software, DSLs have great value if they can help address it.
With a business-readable DSL, programmers write the code but they show that code frequently to business people who can understand what it means. These customers can then make changes, maybe draft some code, but it’s the programmers who make it solid and do the debugging and testing.
This isn’t to say that there’s no benefit in a business-writable DSL. Indeed a couple of years ago some colleagues of mine built a system that included just that, and it was much appreciated by the business. It’s just that the effort in creating a decent editing environment, meaningful error messages, debugging and testing tools raises the cost significantly.
The Fishbowl: Dear XML Programmers…
defmacro: The Nature of Lisp
Greg Newman’s six part Emacs Series. So far three are up: Part One: Distraction Free Programming with GNU Emacs, Part Two: Emacs Terminal Emulator and Part Three: Dired Directory Management.
Steve Yegge: Emergency Elisp – a great Emacs Lisp tutorial.