Every definition is a constraint

Every definition is a constraint.

Primarily they define operational limits of this reality. Even defining something to be “limitless and without constraint” is limiting because it requires either the written or the spoken form (albeit both spatial) and doesn’t allow for other possible means of communication.

The basis of most forms of science is definition, and thereby, observation.

Artistic expression is both a definition, and, an expression. Because it occurs within the operational constraints of this reality, it is by nature constraining and limiting. This is counter-intuitive, and, quite surprising. Perhaps this is already quite clear to those who have experienced things which are beyond definition?

Perhaps your are familiar with this phenomenon where in the attempt to define those things, you, quite unintentionally, tarnish and drag down those things. It is quite a bitter-sweet experience when you do want to share them, due to the sheer joy of it, and find that you simply can not.

You may have a feeling that you are not sharing, but, you must quite seriously ponder the question of “How can you withhold that which is intrinsic to every human being and is their birthright in this universe?”.

The Lenticular Text Style of Literate Programming

This announcement is pretty exciting because it reveals a new-to-me take on literate programming. The style is to store a single file as a source, and render disparate parts of that file in different buffers in a mode correct for the content.

For example you may have an Emacs Lisp file serve as the source and two separate buffers, one Emacs Lisp and one Organization (Mode), to work on the content, with all of the mode-specific assistance.

Is it a new idea? It is new to me and I am curious to find out about other approaches people have taken to realize this style.

Here is an overview and a nice video that demonstrates it.

Why Friends?

Another reason why…
In regards to an injury that may prevent the lead-singer of a rock band from ever playing guitar again, that singer relays what his friends (band mates) said:

As I write this, it is not clear that I will ever play guitar again. The band have reminded me that neither they nor western civilization are depending on this.

There are so many things woven into that. Painful and pleasant things especially. The love and kindness is quite apparent and sweet, and subtle, too.

Probably Try to Avoid local-set-key

When I first learned how to set up Emacs, I really liked local-set-key because you didn’t have to know about the keymap for the mode you just had to make the call in that mode’s hook. That is simple and makes total sense. That has worked well for me for years until two things happened:

  • Wanted to use prefix commands
  • Re-started using Windows again on a daily basis

The former is part of the natural expansion of use and its refinement. The latter is similar, but specific to running Emacs on Windows.

The last time that I ran Emacs on Windows I did not use the Super key. Then I went off into the wilderness and use it a lot only to return and find that Windows owns lot of my keybindings. Not only were they owned, but they would not let go of them no matter how I tried! Because if this major inconvenience, I’ve got no reasonable choice other than refactoring some of my perfect bindings into something, ahem, better.

This refactoring would have been pretty easy if I’d jus done normal keybindings against keymaps, but I didn’t, I used local-set-key. So this becomes a good learning opportunity about the key-map names and additionally how, at least for myself, this is generally a bad approach because makes re-factoring harder.

The good thing is that at least up front there is a good time savings, I suppose.

Expanding and Using Abbreviations in Emacs

A defined abbrev is a word which expands, if you insert it, into some different text.

They are really simple and really helpful if you like this kind of thing. If you grew up hacking on Java, then you surely already use this in IntelliJ IDEA!
Here is a nice post on how to choose and define abbrevs based upon actual usage.

On FORTH and a Friend

FORTH is a programming language with a lot of both interested and interesting users and implementers. Unbeknownst to you, your anti-lock brake controllers and fuel-injectors could be running by FORTH, and even if they aren’t, surely other critical parts of your vehicle are running on it, or diagnosed and maintained with it, or both.

The curious thing about the language is that its manifestation in this reality demonstrated how a single programming language could be both highly perform-ant and highly expressive. This is rare and uncommon. Today, no language achieve this feat. To consider that FORTH achieved it on limited computers, a long time ago, adds further wonder and respect for this delightful language. If you haven’t even taken at least a single look at it, then you should grab your copy of whatever you call hardware systems, along with the latest copy of gforth, to write hello world and play with the stack a little bit. It is interesting how much expressivity and power you can get out of a little computer system using this neat language. The language isn’t the most important thing though; it is the people.

When choosing a Scheme distribution, someone quipped that “When you choose one, you aren’t choosing a interpreter, so much as, you are choosing the a community”. This is true. Since it was tradition to implement your own FORTH interpreter, you could join a lot of different communities. The common traits among all of them were humans who could think for themselves, optimize at every level of the implementation (both software and hardware), and have a lot of fun doing it. One of those people was a best friend of mine named Bruce Langenbach.

Bruce passed away this year. His LinkedIn profile is still up; though I put in a request to retire it. For some bizarre reason, he never mentions FORTH on this resume. At Bear Automotive Service Equipment he used it to run all of the equipment (Bear sells automobile maintenance systems). The cool thing was that FORTH didn’t just run the equipment, it was also the operating system, code-editor, and debugger, all implemented and executed on-device. All of the REPL-joy that people blog about today was there long ago on little computers (which are somewhat dismissively called “micro-controllers” when in reality they are just computers like any others). That was a really, really fun job.

Bruce told me about it all of the time. It was the most fun job that he ever had. Anyone knows that with any job you have ups and downs. It is especially hard though when your first job is your best one. Fortunately he was investing in and exploring non-programming related forms of employment and expression. The neatest stuff was the encaustic painting.

Encaustic painting, using my simple understanding of it, uses layers of hot wax. It is beautiful, and, is a beautiful form of expression. Bruce was working on integrating LEDs and Arduino-systems with the canvas and the art. I loved hearing about it and was really, really looking forward to seeing what he was ready to share.

If he had been able to finish his work, he surely would have done it on FORTH. This implementation in particular says all of the right things, in spirit, intent, and implementation, and surely would have been a great place to start.