Totally plugging other people’s blogs…

“In each of my friends there is something that only some other friend can fully bring out.” CS Lewis.

A few weeks back I mentioned Clojure, and requested some input from an internet friend of mine.  I got to thinking about this a bit, and decided that it would be a horrible disservice to not share the blogs of a couple of guys that I regularly bounce ideas off of.  Ironically, the below are both Java guys, with some Clojure experience.

http://informatica.boccaperta.com/ – gekkop

http://franksn.github.io/index.html – frank sinistra

While I can’t speak for the quality of their blogs (which are almost 99% certain to be of higher quality than my own), I can say that the authors of each are both respectable and knowledgeable people.  Seemed a shame to not give credit to them for sharing ideas with me.

Sharp Reality

“If anyone tells you that a certain person speaks ill of you, do not make excuses about what is said of you but answer, “He was ignorant of my other faults, else he would not have mentioned these alone.”
― Epictetus

I  believe in constantly pushing myself to do and be more than I currently am.  In doing so, I am reminded of a few facts on a regular basis.  I suck at everything.  Programming regularly with Scheme has reminded me that I am terrible at Scheme.  When I spend more time with C or common-lisp, I’m far more certain of how much I fail at those too.  Every time I do something, my blatant failure rises to the surface.  I figure that this is good, as it means I’m still human…but just instantly getting things right would be cool too.

Still, I’ve come to realize something through lifting that might be worth sharing.  The longer out from gym or competition that someone has been, the higher their perceived ability.  It never fails.  Most conversations go something like:

Random Guy:  “Hey bro, how long have you been lifting weights?”

Me: “A few years.”

Random Guy: “Cool stuff.  What do you bench?  When I was in high-school, playing football, I benched sets of 5 at #700.”

Me: “….”

Normally, this is coming from a guy that I would say without a doubt has never seen more than #225 on a bar.  It’s like the longer that they’ve been out of the art, the more weight the imagination put on their own abilities.  After a few years, they’re mentally breaking world records.

That being said, regularly doing anything is a great reminder of where our abilities really are.  As I improve at anything, I meet opposition and utter failure which tends to keep the ego in check.  Ironically, perhaps, it’s when I’m really making improvements in my own skills that I feel utterly humbled by all that I don’t know.  Maybe there’s something to that.

This is one of the biggest reasons that I instantly turn off someone who’s always talking about how awesome they are at anything.  Every once in a while, it’s true, but more often than not, it’s the inflation of ego caused by not having actually done anything at all.  The people who do the most, seem to be too busy talking about the things that aren’t working over the things that they have fixed.

I guess if there is some way to summarize this inherent babbling, it’s “Stay humble…which tends to take care of itself if you’re making progress.”

The Tai’ Chi approach to code-kata.

For those of us who can readily admit that there are areas where we personally could use improvement, I present a simple idea based on archetypes from martial arts.  Now, let me first of all state that while I’ve done a good bit of boxing, I am NOT a kung-fu master, so I am making relationships from nothing but my extensive time watching bad Hong Kong Cinema kung fu movies.  If I blow the metaphors out of their original context, you’ll just have to excuse me.

Anyhow, code-kata is not a new concept.  It’s actually a pretty solid idea, that by practicing something, you get better at it.  Almost everything works like this, and I think that kata styled programming is an excellent way to stay sharp on what you have learned.

That being said, I’ve watched enough kung-fu movies to know how the student eventually learns the secret technique that he needs to defeat the super-awesome bad guys and/or evil dragon-style master who killed his family.  He goes to the mountain or temple, meets an unlikely hermetical master (often a drunk), and through repeatedly failing learns some secret technique that allows him a leg up on the competition.  Sometimes, he/she will see a mantis fighting a spider or something, and then ‘pow’, inspirations strikes.  There is a moment of enlightenment where all of our hero’s weaknesses have been addressed because after the regular training, he was sitting quietly and contemplating something.

I would say that this is the step that kata often ignore, and for the sake of this discussion, I’ll call this the ‘tai chi’ approach.  It’s not the movement itself, but the repeated introspective practice followed by meditation on the subject that allows us to have the insight to rise above our current level.  I am not by any means suggesting that you wear silk robes to work and burn incense at your desk (unless your boss is fine with that, in which case, by all means…it seems like it would be pretty comfortable.)  What I am suggesting is that if you do use kata of some kind, to do so with a thoughtful presence, closely examining each step.  How could you make it better?  What is really happening behind the scenes?  Is there another way to do the exact same thing?

Often, it’s only after I’ve finished a project that I’ll look back and realize the problems with my own methods.  There is almost ALWAYS room for improvement, and by spending more time looking at the small parts of the small projects, the bigger projects are easier and more concise.

I’m not saying that studying is a replacement for regular practice, but that BOTH are necessary to reach enlightenment…and by enlightenment, I mean when you can spot a segfault in three-star pointers at a glance (or whatever your language of choice has to offer.)  In the end, it is the practice of solving problems that leads us to find the answer when we are finally able to still our busy minds.

“It took me ten years to discover my chi, but thirty years to learn how to use it.”
– Ma Yueh Liang

Furthering the list of things I (or (didn’t) (don’t)) know.

After my last post, I decided that my knowledge of the current state of any language outside of those that I might regularly use could use some refreshing.  As such, I spent some time speaking to a few schemers to figure out what I’ve been missing.  The answer, in as few words as possible, is “a lot.”

First of all, the R6RS has been ratified.

There are so many implementations that I will just link you to another wonderful page that includes a bunch of them.  If you have a question that isn’t clearly answer, there is the #scheme IRC channel on Freenode who actually has shared the previous years+ of IRC logs, which you could search through and probably learn a ton.

…and finally, I’ve learned that my own grasp of Scheme beyond basic educational writing is pretty weak.  I plan to personally ratify that, as it’s a really beautiful and simple language with some insanely powerful applications.  While I realize I’ll never know everything, it never hurts to know more than I currently do.

Fun Links!!!

((Schemers dot org) (community scheme wiki)(readscheme dot org)(community on choosing first implementation)(some wikibook with more links))

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 Revised⁵ 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.“

When life DOESN’T reflect art.

life is not a t43

As my last post may have indicated, life gets to be really hectic from time to time.  During my last few weeks, I accidentally stumbled upon a ‘moment of clarity’ as I’ve heard them called.  For me, it was when I realized that while I know exactly what I need as far as technology is concerned, life in general is a whole different scenario.

So, as a result, I have started what is probably going to be a long-term effort to de-bloat my life a bit.  As I tend to do a pretty decent job of only installing what I plan to use, I have been spending the time to look at what I ‘actually WANT to use…in life.’

Essentially, overextending yourself is a result of picking up projects and appointments that do not align with the ‘design philosophy’ that you had in mind.  When someone asks me to help out on working with something, quite often, I agree to do so if it seems like a simple thing to do.  The problem is that then I begin to suffer from ‘feature creep’ in my life.  All of those little commitments and promises add up, and then in the effort to manage them all, concessions in quality and single-minded purpose are made.  Life ends up bogging down because we take on too much, and then have to put aside something to do something else.

While I won’t go into details about my personal plan, as it only applies to MY priorities, I guess that I’d like to stress that it only makes sense that if you’re going to be minimalistic in one aspect, that it would probably serve you well to apply that to other aspects of life as well.

“Doing nothing is better than being busy doing nothing.” – Lao Tzu