For the last year or so, I’ve been using GEdit to write Haskell code. It’s worked pretty well for the most part. Haskell is a pretty simple language, and thanks to the REPL, I find myself not really missing most fancy IDE features. However, GEdit has its limitations. While GEdit has plugin capabilities, they are somewhat limited in what they can do. Additionally, there doesn’t really seem to be a vibrant plugin culture. Most people just use what Gnome provides, and that’s mostly sufficient. Put simply: I’ve made do. Honestly, I had a pretty effective setup: With my file browser on the left, and my built-in terminal on the bottom, I had 95% of what I needed. However, one always wants more.
Recently, I started at UCSD, and if any of you are familiar with its Computer Science program, you’ll know that they push Vim. They push it Hard; deep down your throat. They have basically an entire class dedicated to learning Vim, and programming assignments are set up in ways that break IDEs. Due to this, I’ve had plenty of time to consider my editor choices. So far, I’ve worked around these issues; using NetBeans to code my C, C++, and Java like a civilized person. However, I can’t help but feel that I’m swimming up river. Surely my life would be easier if I gave in.
Don’t get me wrong, I don’t care for Vim. I learned to use Vim over ten years ago in my various sysadmin jobs, so it’s not that I don’t know how to use it. I’d just rather not. Sure, for a quick edit to a file at the command line nothing beats Vim. However, I find the idea of trying to use a command line editor for a large software development laughable. I’m a fan of the GUI. Keyboard shortcuts can save time, but at some point the brainpower you devote to remembering the correct incantation for an operation you perform maybe once a week could be better spent solving some software engineering problem.
Now I know what you’re probably thinking: “But Mr. DMP-Man! Emacs is a command line editor fraught with arcane keyboard combinations, each more inscrutable than the last!” And you’d be right. However, I feel that Emacs has more effectively made the leap into the 21st century. It’s GUI isn’t the greatest, but I give it the edge. Additionally, since all editor functions are just elisp functions, and you can call them by name and by shortcut, it supports discovery more effectively. Where in Vim, you’re likely going to turn to google to tell you how to do something, in Emacs, you can just do
M-x foo-do [TAB] and get a list of things that are probably what you want. In short, I can learn a few incantations if the benefits are worth it.
But I digress: the point of this post is not to proclaim what editor you should use. Some people like Vim, some people like Emacs, some people don’t care. All three are valid points of view, and there is no objective right answer.
So, what compels me to give Emacs a shot? The vast library of plugins, of course. I spent a few days configuring plugins for Haskell development, and I do believe I’ve settled on a setup that’s going to improve my productivity. I’d like to share my findings.
Most of what’s in here is inspired by this excellent tutorial by serras.
Before we get started, we need to add a repository to Emacs. Emacs comes with a built-in repository system, similar to what you’d find in your favorite linux distro. However, this repo is more Debian than Ubuntu; it’s missing a lot of stuff. Thankfully, the community has stood up more robust repositories. The two big ones are Marmalade and Melpa. You can use both, or one or the other.
I settled on Melpa, of which there are two:
melpa stable. Some bad experiences with Debian Sid, I’ve learned to stick with stable repos.
Either way, go ahead and add a repo to your Emacs, and you’ll have a much better selection of plugins. To setup
melpa-stable, add the following to your
(require 'package) (add-to-list 'package-archives '("melpa-stable" . "http://stable.melpa.org/packages/") t
Of course something called
haskell-mode would be a good candidate to download for Haskell development. Haskell-mode provides quite a bit of functionality: syntax highlighting, formatting help, and integration with quite a few external programs to facilitate development.
haskell-mode can be installed from Melpa.
Details on configuring this can be found in Serras' tutorial
For indentation, I recommend the
hi2 plugin mentioned in the tutorial. It provides visual cues as to where the tabs are located, and the behavior is much less wonky than the basic
The next thing to install is
ghc-mod Provides integration with GHC. Most notably:
ghc-mod provides IDE-style error and warning messages inline with your source file! It also provides simple code completion, and is required infrastructure for a lot of other plugins. Recommended.
Unfortunately, it takes a bit of configuration. Check Serras' tutorial for more info.
Lately, I’ve become a fan of the 80-columns rule. I used to think that it was silly in this age of widescreen monitors. However, I’ve been forced to abide for the last quarter, and I’ve realized that it helps readability. Additionally, Haskell code tends to slide to the right thanks to extensive indentation. Due to this, some discipline is good to keep the left half of your screen from being filled with whitespace characters.
GEdit has a feature that it shows the 80th and beyond in a different shade than the first 79. Unfortunately, EMacs is somewhat lacking in this department. However,
whitespace-mode serves just fine in this case.
It doesn’t mimic the GEdit behavior, but it can be configured to highlight code that goes past 80 columns. To enable whitespace mode for programming modes, add the following to your
(add-hook 'prog-mode-hook 'whitespace-mode)
whitespace-mode can be configured using the visual customize functions within Emacs. Enter
M-x customize-group [ENTER] whitespace [ENTER] to access the visual customization. I have mine set up to put a dreadful red box around anything that passes the 80th line:
rainbow-delimiters is a plugin that color codes matching parenthesis. It’s pretty simple, but it can help greatly when working with lots of matching brackets.
Configuration is simple using the visual customization:
M-x customize-group [ENTER] rainbow-delimiters [ENTER] should get you going.
rainbow-delimiters can be found in Melpa.
My journey with Emacs has just begun. Maybe I’ll fall off the wagon, maybe I’ll become a Priest of the Church of Emacs. Either way, I’m sure you’ll likely hear about it here!
Lately I’ve been distro hopping. Between projects and lacking inspiration, I’ve been in search of a new DE and a new text editor. I’ve come to realize that I don’t have the patience to deal with XMonad and friends, and of the mainstream DE’s, I like Gnome 3 the best.
However, that still leaves the question of the text editor. I’ve been using GEdit to do Haskell, and it’s been working for the most part. However, while GEdit supports many languages by way of GtkSourceView, it doesn’t support them all. What if I decide to learn some fringe langauge?
Of course a google search for “GEdit fringe-lang syntax highlighting” turns up “Use EMACS” or “Use VIM”. I’ve some experience with VIM from my past life, and I’ve tried to get into EMACS in my new life. Neither of these are terribly appealing. Which leaves me with GEdit for the time being.
So today, determined to do something productive, I fired up GEdit for the first time since reloading Ubuntu GNOME and was greeted with this:
Yeah… Vaguely remembering dealing with this issue before, I went into the module preferences and tried to configure the build-in terminal.
Irritating… After some googling, and message-board hopping, I found the answer. So that I don’t have to figure this out again next year, I’d like to preserve the solution here.
The fix is pretty simple. First, launch
If this isn’t installed, it should be in your distro’s repositories. On Ubuntu:
sudo apt-get install dconf-editor
Browse to org -> gnome -> gedit -> plugins -> terminal.
There are plenty of interesting configuration options in here, things that would normally be done in the gnome-terminal profile config dialog. However, I just want my terminal to use the built-in theme. To do this, we need to ensure the
use-theme-colors option is selected. After that’s done, close the dconf editor and re-open GEdit. It should now look like this:
I now have a nice, well-behaved embedded terminal. Much better!
Well, the day has come and gone. DMP Photo Booth’s final test on June 21st went off without issue, and DMP Photo Booth has left Beta and is now considered “production ready”. The initial 1.0 release can be found on GitHub.
The significance of June 21st is the very reason DMP Photo Booth was created; the 21st is the day of my wedding. My wife wanted a photo booth for the reception. We looked into renting a photo booth, but it turns out that they run around $1,000. I turned to open source. Some quick googling turned up some options, but they were all personal projects or out of date. Sure I could get somebody else’s project working, but what’s the fun in that? I decided that we didn’t need to rent one, or download one, I could build it!
In late 2013, I set to work in earnest. I had a couple of months of downtime in school, and since I’m not currently working it was the perfect time. I decided I had three main objectives for this project: get some arduino experience, get some GTK+ experience, and do this all as portably as possible. I had initially decided to mostly ignore GLib and focus on GTK, but slowly I grew to appreciate GLib for what it is: the standard library that C never had. First I used GModule to handle shared libraries in a portable manner. Next I decided to use GLib primitives to keep from having to deal with cross-platform type wonkiness. Next, having grown tired of dealing with return codes, I refactored the project to use GLib’s exception replacement: GError.
It’s not all roses and puppies though. There are certainly things I’d do differently. DMP Photo Booth is developed in an Object Oriented style, passing opaque structs with “method” functions that operate on them. Each component of the program are organized into their own source file with file scoped globals scattered throughout. Said globals are protected by mutexes to create a semblance of thread safety. That said, threading issues have been a major thorn in my side. Long story short: I regret this design choice. While I still feel that this is the correct way to structure C code, and that if globals are required, this is the correct way to handle them; I feel that I should have made more of an effort to limit side effects. Recently, I’ve spent some time doing functional programming, and if I could do it again I’d try to write in a more functional style. Fortunately for me, this is something that a little refactoring could help with.
Additionally, one thing I thought would be a major help is something that began to be a major thorn in my side: NetBeans. As the size of the project grew, NetBeans got slower and slower. It seemed that I spent more time fiddling with IDE settings than actually coding. Even worse is that the IDE-generated makefile is so convoluted that it’s extremely difficult to modify by hand in a satisfying way. I’ve always coded with and IDE so I wouldn’t have even considered not using one, but then I spent some time with Haskell. One of Haskell’s “problems” is that it doesn’t have good IDE support. It doesn’t seem like any IDE really handles it well, so most people use Emacs. Personally, I haven’t really warmed up to Emacs, but GEdit has syntax highlighting for Haskell and a built-in terminal for GHCI. GEdit also has syntax highlighting for C. Next time, I will seriously consider using a lighter-weight text editor for a C project. All this said, I think NetBeans for Java remains the way to go.
Like any program, version 1.0 is just one of many versions. There certainly remains a lot of work to do with DMP Photo Booth. Some major items you are likely to see whenever I get around to working on DMP Photo Booth some more:
I think anybody who has seen it will agree: the options dialog in DMP Photo Booth is bad. It’s poorly organized, and kind of wonky. Personally, I modify settings using the
.rc file, which is telling. This is certainly a high-priority improvement.
Like I said above, the code could use a pass to limit side effects. Funtions need to have their side effects limited, and globals need to be eliminated unless absolutely necessary. However, C is not a functional language. While one could argue that function pointers enable functional programming in C, this is a very pedantic argument. I won’t be going crazy with functional programming techniques. There will be no Monads, or for loops being turned into mappings of function pointers.
Optional Module API
An idea I’ve had on the back burner for a while is an optional module API. This would be used for very specific quality-of-life things. For instance, a module could provide a GTK widget to be shown in the options dialog. Any module that doesn’t want to implement any or all of the optional API can just ignore it. The module loading function will gracefully handle the
dlsym failure, just treating it as it is: declining to implement the API. I have no plans to change the current existing API, so all you module developers can rest easy!
User Interface Module
It occurred to me that it might be good to have a UI module. This would provide the UI, and wouldn’t be tied to the trigger/printer/camera module start/stop system. This module would be loaded at startup and unloaded on shutdown. This would allow the Photo Booth to use different widget toolkits: QT, Curses, Cocoa, WinForms, or whatever else. Under this scheme, the current GTK+ interface would be abstracted into the reference UI Module.
For as long as I’ve been trying (successfully or not) to program, I’ve been using C like languages. When I was a kid, I struggled in vain to learn C++. As an adult, I learned Java. After that, I used Java as a spring-board into the wonderful world of C Like Languages: C, C++, Perl, Lua. I wrote hello world in dozens of others as well. I found myself proudly proclaiming that “I’m confident I could pick up any C Like Language!”
Then one day I thought “what about the rest of them?” Sure, maybe I can speak Latin. Maybe I can pick up any Latin based language with relative ease. But what if I need to move to China? I speak C, but what if C falls out of favor for something else? I decided it was time to try something else.
C and it’s cousins broadly represent the Procedural and Object Oriented paradigms. We’ve all been there and done that. Procedures and Subroutines may or may not take arguments, do something, and may or may not return a result. The global or local state may or may not change. Loops happen. I don’t think it is a stretch to say that these are the two most mainstream paradigms. For the purposes of this blog post, I’m going to lump the Procedural and Imperative paradigms together. I understand that they are not the same thing, but roughly speaking, the Procedural paradigm is an evolution of the Imperative paradigm.
This leaves us with Functional Programming. Unlike the functions of an Object Oriented or Procedural language, the functions of a Functional language closely resemble those in math. In math,
f(x+2), where x = 2, will always return 4. Similarly, a function in a Functional language will always return the same result given the same input. Where a function in a Procedural or Object Oriented language describes the steps to perform some task (usually, this involves some sort of loop construct), a function in a functional language just describes what the result of some function is. (usually involving recursion)
f(x+f(x-1)) adds x to the result of
f(x-1), which recursively adds x-1 to
f(x'-1) and so on until the end of time.
So, what programming language to choose? Many languages support functional programming to an extent. Python, Lua, and even C# if you squint hard enough. However, these languages are multi-paradigm. As such, it will be easy to fall back into my C Like ways. What about Lisp?
Lisp is a family of languages: Common Lisp, Scheme, Clojure, Emacs Lisp. Sure, I could learn one, and theoretically be able to transition with ease, but this isn’t a level of fragmentation that I’m comfortable with. In addition, Lisps are multi-paradigm, so I’m more likely to not keep the faith. Which leaves me with…
Haskell is a “pure” Functional programming language. While any useful program must have the side effect of reading from or writing to some external source, Haskell places that part of the program neatly in a corner. Let’s talk about some of the neat features of Haskell:
Expressions in Haskell are evaluated lazily. What this means is that a value isn’t computed until it’s needed. Let’s take a look at an example:
embiggen :: Int -> [Int] embiggen x = x:embiggen (x + 1)
This function takes an integer, and creates a list out of it. (Lists in Haskell behave much the same way as a normal linked list: O(1) insertion, O(n) traversal) The passed-in integer is pushed on to the front of the list resulting from
embiggen (x + 1). You may have noticed that this function will go on forever. While maybe not ideal, this is ok in Haskell because of Lazy evaluation. The infinityeth element of this list will not be evaluated until it’s needed!
show (take 5 (embiggen 5)) [5,6,7,8,9] show (embiggen 5) !! 17 22 show (embiggen 5) [OMG INFINITE RECURSION!!!!!]
In the first example, we call the library function
take, which returns a list containing the first
n elements of the passed in list. In the second example, we call the library function
!! (all operators are functions), which is the list indexing operator, which returns the
nth element of the list. In a language with strict evaluation, the list would need to be completely evaluated before these things could happen. In Haskell, it doesn’t! Only in the third example, where we attempt to call show on the entire list, does infinite recursion occur.
Tail Call Optimization
This is one of those terms that gets thrown around a lot, but what does it actually mean? The short answer is that it prevents a recursive function call from consuming a new stack frame. In a language without this feature, if
foo() calls itself, the new call will consume a new stack frame. This will cause a stack overflow if allowed to go on too long. In Haskell, this isn’t a problem because of Tail Call Optimization.
Haskell’s type system is quite different from the usual type systems. Sure there are Ints, Chars, Floats, Bools, and the like, but there’s more to it than that. Haskell is very strongly typed. There is no casting in Haskell, if a function takes an Int, there’s no getting around giving it an Int. However, the whole type system operates in a manner similar to generics in languages like C++ or Java. Take the following examples:
putInList :: a -> [a] putInList thing = [thing] addStuff :: (Num a) => a -> a -> a addStuff lhs rhs = lhs + rhs
The first function takes some arbitrary type, and returns a singleton list containing the passed-in argument. Much like generics, the argument shouldn’t depend on any type-specific behavior.
The second function takes two arguments of the same type that behaves like a number (Int, Float, Double, and friends) adds them, and returns the result. the
addStuff function accomplishes this by specifying that arguments of type
a should be members of the
Num Typeclass. Despite the word “class”, Typeclasses aren’t the same as classes in Object Oriented languages. You CAN think of them as being the same as Java’s interfaces. When you create a type, you can make it a member of any number of Typeclasses. You must then implement the functions specified by the Typeclass, just like when a class in Java
implements some interface, it must define the methods of that interface.
This is just the tip of the iceberg, but I’m sure you’re beginning to see how you can make very general functions in a very type-safe way.
Partial Function Application
A feature of functional programming is higher order functions. This means that functions can take functions as arguments, and functions can return functions. While nice, this isn’t exactly a new concept. Even C supports this to an extent with function pointers. What is new is partial application of functions. Recall the
addStuff function above. It takes two arguments of type
a and returns a result of type
a. Now let’s look at an example:
doNumFunc :: (Num a) => (a -> a) -> a -> a doNumFunc f a = f a addThree :: (Num a) => a -> a addThree a = addStuff 3 a
doNumFunc function takes a function that takes a type
a and returns a type
a (This is what
(a -> a) means), and a second type
a, and returns a type
doNumFunc calls the passed in function with the second passed in argument. The
addThree function takes a type
a and returns a type
addThree takes an argument, and calls the
addStuff function we defined earlier with its argument and 3. How does this all pan out?
addThree 3 6 doNumFunc addThree 3 6
Seems pretty straightforward, right? Though, this isn’t very re-usable. What if I want to add 4? Do I need to define a function
addFour? No, I can partially apply
addStuff. If you call a function in Haskell with less arguments than it takes, it will return a function that takes the remaining arguments and returns a result! Observe:
doNumFunc (addStuff 3) 3 6
Now things are getting cool. By calling
(addStuff 3), we’ve created a function that takes a type
a, adds 3 to it, and returns the result! You can’t do that in C!
Excited yet? You know you are, don’t try to act like you’re not. But how does one get started? Like any language, you need two things to begin: a compiler/interpreter and some reading material.
First up, you should go download the Haskell Platform. This package contains your compiler/interpreter and all the standard libraries. Haskell can be compiled, or interpreted. Or, you could use
ghci, the interactive interpreter, if you just want to doop around and try stuff.
If you’re running a Linux distro,
haskell-platform is likely in the repositories. In Debian or Ubuntu, it’s a simple:
sudo apt-get install haskell-platform
… and you’re set! Unfortunately, there doesn’t seem to be a great IDE for Haskell. NetBeans definitely has nothing to offer in this regard. Luckily for us, Haskell is simple enough to not really need an IDE. GEdit, the default text editor that ships with Gnome, has built-in syntax highlighting for Haskell. Just enable the built-in terminal in GEdit to test stuff and you should be good to go. I like to run
ghci in the embedded terminal to test functions as I write them. Plus, as you code, you can periodically attempt to load the script in
ghci to make sure everything is formatted correctly and you haven’t messed up your syntax/types.
One of the biggest barriers to learning a new language is money. Nobody wants to put down cold hard cash on learning something new when what they have is working just fine. Luckily for us, you can learn you a Haskell for free! Learn You A Haskell For Great Good is a beginner’s guide to learning Haskell aimed at developers coming from C Like Languages. The best part is that the whole book is available to read online for free! You can check it out for the low-low price of zero dollars. If you like it, maybe you buy a copy for your bookshelf. Or maybe you just spread the word.
Whatever you do, you should have a good base of knowledge in Haskell. At that point, you can just consult Hoogle to learn more.