Command Line Wizardry

By the way, I made my first contribution to //arstechnica.com two weeks ago with the "Tools, Tricks and Tips" section of Ryan Paul's lately acquired linux.ars column.

Cixar

For the record, the name Cixar doesn't, in itself, mean anything. Rather, the name is an attempt to draw multiple parallels.

It starts with my moniker, Cowbert. Actually, it starts with my lack of a monicker. My sister, Kathy, has always had a "theme" for each phase she's passed through, albeit pandas, kiwis, or elephants. I, on the other hand, until the age of seventeen, was as stolid as a cow. Kathy meant to break this mould. She gave me a plush cow she earned for selling recipe books as my 18th birthday present. At the time, I read Dilbert quite heavily, and was planning to make a parody. Scott Adams claims in The Dilbert Future that his idea of originality is reading Garfield and changing all the jokes so they fit Dogbert. So, I made a Cowbert comic wherein I bore a striking resemblance to a particular, cube-headed, plush cow. To clinch it, was still available. So, these long years later, I am Baron Cowbert von Moo.

At the time, Ryan Paul and I were throwing together ideas for a new MUD, we were attributing IdealMUD, since we weren't ready to rule out any particular set of features for practical purposes yet. Quickly, the term "Cix" filled the analogous role for a collection of "Cowix" operating system ideas. Ryan Witt posited that "Cix" inherently "Cix OS", especially in a British accent. Cix has since evolved into a pile of ideas, not so much for an operating system, but for an internally consistent platform. Of course, it isn't internally consistent, but we plan to build Gnomebots to sort it all out.

Some of those ideas included "graphical command line" names for applications. Taking a page from Latin, the names were inflected. Each application had a three letter root representing the type of data it operated on. This base corresponded to the file extension. Then each application had a suffix of "or" for "edit-ors", "er" for "view-ers", and "ing" for daemons, a.k.a, services. For example; *.tex text files edited with texor, viewed with texer; *.pix picture files edited with pixor, viewed with pixer; tabular data edited with tabor and served with tabing. Of course there was in internal implication that Texar, Tabar, Datar, Vexar, and Pixar would be fantastic names for teams, companies, or loosely governed alliances of hackers devoted to the development of these tools. Then Ryan Witt bought cixar.com for our eventual Internet home, sealing the name around us like soo many soggy carpets.

So, summarily, Cixar is a loosely governed alliance of Cix developers.

Urban Dictionary for Firefox Toolbar

I took some time for the last couple days and implemented a Firefox extension for http://urbandictionary.com. It looks up words you select and displays their definitions (if extant) in a (normally hidden) toolbar.

Jeal

jeal
Pronunciation: 'jE(&)l
Function: noun
Etymology: zeal and jealous, Middle English jelous, from Old French, from (assumed) Vulgar Latin zelosus, from Late Latin zelus zeal, from Greek zElos
1 a : intolerance of rivalry or unfaithfulness b : a disposition to suspect rivalry or unfaithfulness
2 : hostility toward a rival or one believed to enjoy an advantage
3 : vigilance in guarding a possession
- jeal*ous adjective
- jeal*ous*ly adverb
- jeal*ous*ness noun
- jeal*ot noun

jeal*ot
Pronunciation: 'je-l&t
Function: noun
Etymology: zealot and jealous, Late Latin zelotes, from Greek zElOtEs, from zElos
: a hostile fanatic acting on jealousy
see jeal

Definitions parodied off Merriam Webster

Swilly the Pig

Ryan Paul and I have been working on Swil graphics.

1. The original SWL logo
2. Ryan Paul's excellent shaded version.
3. A vector rendition.
4. A simplified graphic.

I created [1] for SWL 2. I sketched the image on a 3x5 note card and scanned it. Dan Restuccio and I processed the image in Adobe Illustrator and produced a vectorized version and filled the cells with solid colors. This appears in the SWL 2 documentation.

Ryan Paul has been studying how to use Inkscape, a powerful graphics editor for Linux, to produce high-quality, cell-shaded images. His first attempt was on his personal, lambda-penguin logo. Ryan produced [2] with this technique, applying cell shading techniques to the cells of [1]. Ryan chose to use an obnoxious yellow for the tie to fabulous effect, IMHO.

Ryan and I collected comments on the new logo. A friend of his, used the theme to produce their first Inkscape image. Although his choice of color for the pig would "cause glaucoma at twenty paces", he did get a few things right that I didn't in my sketch. For one, he made the coffee cup look like a coffee cup. Mine turned out more like a gravy saucer. He also chose white for the cup and put spots on the tie, which Ryan Paul and I thoroughly approved of. The spots, in my imagination, are bubbles from the swill. Ryan Witt thought it would look better with glasses and a pocket protector, to go with his tie-clip. My coworker, Meshaal, suggested that it wasn't abstract or simplified enough to scale to icon size or be representative as a logo. Also, Trevor Bortins suggested that, since I pointed out that the swill cup is a Java parody, I should somehow work the "steam" motif in, since that's the most prominent feature of their mark.

I recreated the logo with vectors to produce [3]. In this version, I integrated the white cup, the glasses, the yellow tie, and spots. I think I might attempt to render "steam" in the tie next time.

Rendition [4] is for Meshaal. The pig is ridiculously iconified into a largely circular composition, between the pig and the cup. This rendition doesn't have the wide support of [3], but it has its adorable merits.

I also made icons.

1. 
2. 
3. 
4. 
5. 
6. 

SWL used a snout icon extracted from the first logo. I generalized the notion of the snout abstraction, since, so all of our icons bear the theme. [1] is the decided Swil 3 icon. [2] is the Moosh icon, already in use for the Moosh Firefox extension, /moosh. [4] is Ryan Paul's idea for the Moot icon. The yin yang motif conveys the sense of disperate people interacting to produce a cohesive whole. [5] and [6] were my original attempts to convey a "meeting" of cow snouts and a diff of a cow snout. We're running with the yin yang, but I'm still trying to find an idea for the icon that is less tenuous than these.

Overloads and Genericity

I disagree with Professor Bates' general assertion on the ACM Queue that overload is bad based on the specific weaknesses of C++. Bates cites the nightmarish growth of complexity of a C++ program because of a combination of arbitrary complexities. C++ uses a complex scheme of scope resolution and type casting, with multiple ways to invoke type conversions. Because C++ provides so many avenues for these features, there are arbitrary distinctions to determine where one begins and another ends. In a simpler language, as most functional and some procedural languages are, overloading is not a problem because there is only one scope resolution rule and a unified system for defining type conversions. In fact, that these complexities scale exponentially is considered an advantage; being able to understand how your code scales when it interacts with new code is empowering.

Bates argues that "[overloading] adds no significant programming capabilities at all." This overlooks the concept of genericity. Genericity is a concept implemented in static languages like C++ through the use of templates and in dynamic languages like Python inherently. Genericity posits that there are classes that are unrelated in terms of inheritance that subscribe to the same notional behaviors as defined by some set of algebraic identities. So, for all objects that subscribe to the same notion of "addition", a "sum" operator would behave the same way. Or, for all objects that subscribe the notions of symbolic logic, negating any of those objects once gives you an opposite, and negating again renders an equivalent object to the initial. This is a significant programming capability. This permits the implementation of libraries that behave on any object that subscribes to these generic notions.

I do agree that overloading can get out of hand, especially in the hands of programmers that are simply trying to be brief and have no respect for preserving algebraic identities so that their classes can behave predictably. Perhaps future languages simply need a way of explicating these generic relationships. I would be tempted to argue that one can emulate the exact same behaviors with object oriented programing and explicating these relationships with with interfaces, but I doubt this is practical in the long run. Frankly, some people are willing to give up the effort of explicating their intentions on the expectation that other users have taken the same math classes.