X11 Must DIE

Unix, C, computing like it's 1980.

Month: November, 2014

A short bit on lisp dialects


I’ve spent the last few days both extending a personal dialect that I’ve been writing on, and playing around with variations found in other branches of Lisp.  I love lisp, as it shortens the time between when I have an idea and when I can see it in action.  Compiled lisp programs are fast (not as fast as well written C, as some have claimed, but this is a whole other post that is far more technical…I’ll probably write it later), the core can be very clear and concise, and they do not require you to redefine the wheel for everywhere that you wish to place a tire.

That isn’t to say that the same cannot be true of other languages, such as Python and Perl.  It isn’t my point to debate using one language or the other.  Just use whatever serves your particular purpose.  On the other hand, to someone new to lisp in general, the differences can be a little unclear.  While I could write pages on dialects, I’ll try to keep this short, sweet, and clear.

Common-Lisp:  One of my personal favorites, as it’s very comprehensive and has some huge advantages for those who are looking to deal with large programs written in a relatively portable dialect.  Common-lisp has CLOS, which is a fun way to get really down and dirty with OOP at a deep level that actually makes OOP in other languages make more sense (to me, at least.)  I am a huge fan of SBCL as an interpreter and compiler, which is easy to set up on almost any Unix-like system.  The downside to common-lisp is that the choices and depth can sometimes be daunting to the newcomer, as there are often multiple ways to do the same thing.

Scheme:  You read SICP?  The lispy original?  If not, then you should.  It’s a great book, and also a great introduction to Scheme.  One of the big benefits to using Scheme is that it’s far more minimal at the core than CL, so it’s far more approachable and easier to learn the basics of.  The Revised5 Report on the Algorithmic Language Scheme is very informative and specific in covering syntax and semantics.  There are a few different options for getting Scheme up and running.  Racket (formerly PLT-Scheme), Chicken, or GNUGuile are some of the ones that come immediately to mind.  Many educational institutes teach Scheme, as it tends to be a good platform for learning recursion.

Clojure: I may need GekkoP’s input here, as I’ve not personally worked much with Clojure.  What I do know is that it runs on the Java Virtual Machine and that it’s lispy.  Beyond that, I’d just be writing someone else’s opinions that I haven’t personally experienced, so I’ll just leave well enough alone.  If you’re into Java, I would imagine it’s worth checking out.

Emacs-Lisp: A short dialect almost exclusively used for extending the functionality of GNU Emacs, elisp is an interesting one to be sure.  While it may seem silly to have a dialect based around a single program, there are many benefits to programmers of all lisps to using emacs.  I have personally used it more than I’d like to admit just to get some quality of life improvements for work on other projects.  It’s like sharpening your axe as a lumberjack, if that makes sense.  There are a few compatibility emulators, including the cl-lib extension for making it mimic the behavior of Common-lisp in some places.

All of that being said, it’s worth understanding that if program speed is the goal, C (or better yet, Assembly or Fortran for math….) is probably a better choice.  On the other hand, if you’re looking to learn a language that isn’t an ideology in and of itself while still giving you the freedom to explore ideas, then Lisp may be right for you.  Worst that can happen is you run screaming from a parenthetical overload. 😉


/Why\ I\ hate\ spaces\ in/filenames –v1

Sometimes, the modern conveniences of command-line computing give rise to terrible and horrible practices.  In order to combat the ever-growing and changing world of monoliths of file-storage and users having the freedom to name or rename files and directories as they see fit, our shells have greatly ‘improved’.  So have most scripts.  This is all for the best, right?  Now there is freedom and freedom is good and everyone can add lines of meta information right into the name of a file.  “I spit on (your) tradition &don’t care.ogg” is less than 255 characters, and can totally be used.

…but should it?

Keeping in mind that I’ve spent the past few days completing everything in Plan9’s rc shell, I’ve been reminded of many of the reasons that things just can’t be as simple as they once were.  (I feel like the mother in some sitcom yelling “This is why we can’t have nice things!”)  The benefits of better auto-completion, tab-completion, and *gasp* graphical file management have sometimes obscured exactly how Unix-like systems deal with things like odd characters and spaces in file names.

In rc-shell, tab moves the cursor to the right.  Nothing magical happens, so if you need to invoke a file to perform an operation on it, then you simply have to type it out correctly.  This is not a big issue, until you run into a file that contains 124 characters and 27 spaces, which all need to be individually escaped.  It may just be me (I doubt it), but I normally make at least one typo.  This is fine, right?  “Just hit the up arrow and you can fix the command,” says the command-line guru.  Incorrect!  You’ve become accustomed to GNU’s Readline (or OS-specific equivalent) and have forgotten that this functionality has not always existed either.  I end up using carats (“^old^new”) to fix it, before renaming the file to something far simpler.

But, that’s your fault for using a shell that was developed in the 1980’s.”  Ok, I’ll give you that one.  I could simply be using a totally different setup.  That being said, I can assure you that every single script that has been written in the last 10+ years has taken one of 2 stances on file-names.

1). Sanitize all possible user input using creative parsing or xargs to ensure that spaces within file-names are handled properly, forking extra processes and writing extra chunks of scripting for the sole purpose of dealing with variations.

2). Don’t care about the user.  They should not have spaces in file-names!

While I think that #2 is far more entertaining, most scripters and programmers err on the side of caution and go with option #1.  In all, possibly millions of lines of code have been written in everything from large applications to small one-off scripts to deal with something that could have easily been avoided.

Ok, Joe, I admit it…I want to be rid of these crazy spaces in my file-names, but it’s so much work to change them all!” – enlightened one.

Well, for the most of you using bash, this will quickly sanitize spaces in a directory for you by replacing them with underscores:

for f in *\ *; do mv -- "$f" "${f// /_}"; done

May your computing be precise.

Fun projects that totally distract me…

Ok, so the last few days I’ve been playing with porting plan9 from userspace over a towo kernel and some sketchily rewritten core-utilities that use 9lib.

I will say that this is easily the most ‘computering’ that I’ve enjoyed in a long time.  I don’t know that I’d recommend it for regular use, but for a testing system that I can afford to break, it’s awesome.  That’s all.

; exit

Choosing the right tool-set.

user@everywhere ~> 

Once again, I have run into some contention regarding the way that I prefer to do things from someone who doesn’t share my particular tastes.  That in and of itself is fine, as I’m pretty accustomed to ignoring personal opinions on subjects that don’t really have any relevance to me.  This time, it was in response to my user-space not being ‘modern’ enough.  This particular conversation only got interesting when he was showing me (as though I care) about the wonderful world of a fully-modernized KDE desktop.  “Hey Joe, look, my laptop’s battery is at 100%, and here’s the volume control right next to it.  It’s just really convenient.”

Now, first off, the laptop is plugged in, so battery life is pretty much a useless topic, but I got what he meant, so I kicked over to my shell and typed in:

cat /sys/class/power_supply/BAT0/capacity

Oh, look…there’s mine as well…and ‘alsamixer’ is right over here, which is a far more detailed volume control.  To tell you the truth, using KDE for me would be overkill, as I’d probably just open a terminal in it fullscreen and work from there.”

I doubt strongly that this guy took this to heart, or anything of the sort and really don’t care one way or the other what he does as long as his system works for him, I do have some opinions on how to choose your tool-set to fill out your own needs.

To draw an analogy, I like to lift weights.  I do it a lot and have done so for quite some time.  I don’t go to a big commercial gym, though, as I have everything that I need in my garage at home.  A rack, a couple of barbells, and a few thousand pounds of iron plates.  When I first got into lifting, I went to a large ‘fitness center’ and went through machine after machine, making sure that I hit all possible groups of muscles that I thought that I needed to according to the magazines I’d read on the subject.  After a few years, I came to realize that I was really wasting a ton of time.  I ended up stripping my entire workout down to a few complex barbell lifts, and my progress was greatly improved by it despite the fact that it took about 25% of the time that my previous workouts did.

One of my staples is the clean-and-press.  For those of you unfamiliar with the lift, look it up.  It’s a semi-complex lift, but the advantages to it are not so different from how I’d suggest you pick out your tool-set for computing.  The clean-and-press hits the entire body, stressing the ability to pull, lift with the legs, and ends in an overhead press that taxes both balance and pressing strength.  See, rather than using 20 different machines to isolate these parts into ‘perfect’ (some sarcasm here) form, I choose something that accomplishes as much as possible in the minimal amount of time and requires the least amount of extra stuff.

Shell (whichever one you prefer) is the complex barbell lift of the *nix world.  While there are different levels of mastery, I believe that the most productive possible use of anyone’s time up to a certain point is to understand how to work inside their shell.  As my own knowledge of shell syntax grew, I found myself needing and wanting less and less external programs to do the little tasks.  Unix nature is that everything is a little task, and the tasks that appear to be big are in reality a series of much smaller tasks that work together.  Master the little tasks using the most appropriate tool, and soon enough, no task is too great.

eshell: things I’ve totally underestimated


I’ve long been a fan of zsh.  I’ve extended my shell to cover a wide array of tiny little quality of life functions and I still think the world of it.  That being said, I have practically gone fully over to using the emacs included eshell for the past few weeks.  For those of you who are hardcore vim guys or not into lisp hacking, then most of this won’t apply to you…but I’ll share a joke I heard recently at the end of this post just for you.

For those who ARE into emacs and lisp hacking, I cannot tell you how much fun eshell can be.  It’s one of those things that has been there, and I’ve used it a few times before while playing with shell inside emacs before I swapped over to ansi-term and used my normal zsh…but I had missed a huge reason to use it.  It is an interactive shell that accepts elisp directly from command-line in addition to performing most standard shell functions with similar behavior to bash.

This isn’t a big deal as far as normal shell functions are concerned, `ls` still looks the same here, but to see some difference at the eshell prompt, type in `current-buffer`.  Better yet, enclose the little commands in parenthesis.  Try: (window-list).  Not too big of a deal, except that it looks a whole lot like an evaluated (window-list) in emacs’ scratch buffer.  When it really hit me what I was missing is when I started using load-file from it with short little lisp snippets that I was playing with.  Eshell, like anything emacs, is highly extensible via emacs-lisp.  Right now, mine behaves like the plan9 smart-shell, and I’m still adding more little quality of life things to it as we speak.  The more I hack away at it, the more I love it.  While it starts off simple, it can be made into a monster!

Ok, I promised the vim guys something funny, so here’s a quote I heard the other day:

I switched from emacs to vim about 3 months ago and haven’t gone back since…mostly because I can’t figure out how to close it.