Monday, March 31, 2014

Getting started with Herbstluftwm

It's no secret that I am a fan of tiling window managers. When my workflow consists of having 5+ Windows open in one workpspace, tiling is the easiest and most logical way to do it. So, what distinguishes herbstluftwm from other Window Managers, and how does one get started with it?

What Herbstluftwm does
Herbstluftwm is a manual tiling window manager. Which means, by default it ships with one pane where windows will be placed.
When you open windows in the workspace, they will maximize the space in this master pane. How they do so depends on what kind of layout you choose.                     

However, this is not the way that herbstluftwm is meant to be used. Manual tiling is about splitting your windows into sub-panes, like a binary tree.
Each pane essentially becomes a new herbstluftwm ready to hold windows or be split down even further.

You're probably saying to yourself "Well, that sounds top! How can I get started?"

The answer is a bit more complex than I would like to admit.

Setting up Herbstluftwm
Herbstluftwm works in a peculiar way, but a way that I personally find to be one of the best design patterns on Unix. Herbstluftwm is configured completely by a client, called herbstclient, that can be called from the command line. To facilitate consistency across sessions,  herbstluftwm allows a regular BASH script to be written to bind keys, run autostart programs, etc. This is usually placed in ~/.config/herbstluftwm/autostart. To launch herbstluftwm, just make sure that your ~/.xinitrc contains "herbstluftwm -c ~/.config/herbstluftwm".-c is the flag to set the configuration file.

My autostart script looks like this: https://gist.github.com/anonymous/9893756

Now, barring the wallpaper I use, and a couple of programs that are not installed on many systems by default, it works very well. Windows+v for a horizontal split, Windows+h for a vertical one, etc. Whether or not you can even use this exact configuration, it's a good launching point for your very own herbstluftwm experience.

Sunday, March 30, 2014

Rust Language Review / Predicitons

Rust is a new systems-level programming language with inspiration from Haskell, C++, and D backed by Mozilla. It has been hailed as everything from "language of the future" to "hobbyist plaything". As someone equally interested in hobbies and viability, I decided to learn Rust, with great help from #rust on irc.mozilla.org.

However, my learning experience was anything but smooth. Let me preface this by saying that I am familiar with 10+ programming languages, with at least two from every paradigm (barring logical). It obvious what snippets of other languages rust takes from, but even then it was impossible for me to write even the simplest code without asking for help in IRC.

As an educational experiment, I was trying to implement "car", a function that returns the first element of a list.

Here is an implementation of that in, say, D:
T car(T)(T[] a){ return a[0]; }
Or Haskell:
car (x:xs) = x
But what about Rust?
fn car<'a,T>(v: &'a [T]) -> &'a T { return & 'a v[0];}
Oh boy.
For a modern language, that type of syntax is frankly unacceptable. This is the part where the rust users will come out of the woodwork with their pitchforks, saying "You can't criticize it once you just started! You can't see the beauty in it!" The harsh fact of the matter is, if any beginner has to type THAT monstrosity, for something that is shorter in even Java, the language won't find wide success.

What the Rust syntax gives it is power and correctness, and those are noble goals in a programming language. They're standing on the shoulders of giants (namely Haskell) with their type system, and extending it with lifetimes, eliminating a slew of errors. But the end result is a correct program that nobody particularly wants to maintain or continue developing. It's not comfortable to work in, but it's pretty on a deeper level. So, here's the conundrum of Rust. How much usability do you want to sacrifice for functionality?

My guess is that Rust will not replace C++, but userland C in many cases. Like C, rust is a paradigm in and of itself, and it serves the same purpose that C does, but safer. But I've seen Java programmers who don't know what an interface is, Lisp programmers who don't use macros, and Haskell players ignorant to typeclasses. The beauty that makes Rust the low-level userland programming language of the future will go right over the heads of most of its prospective users.