Our New Telepathic Overlord

Taken from On the record with Jim Whitehurst, Red Hat's new CEO: 'I must have a mission'

What's it like stepping into Matthew's shoes? You inherit his board, his employees, his company. It's a bit like moving into a house that someone else built. How and when will you begin to put the Jim Whitehurst stamp on the company?

I joined Red Hat because it shares my values. I fundamentally believe that what the company is doing is right. People shouldn't expect a change in Red Hat's core philosophy, because it's a philosophy that I share. I will focus on operational excellence, but Red Hat is still Red Hat. That's not going to change.

[NOTE: I didn't have the chance to ask that last question, but he answered it while answering a separate question.]

--end snip--

Clearly this man is telepathic. The world could use more people like this.

Why I don't like C

This is in response to my last blog post. I commented that while I grew up with C as a lingua franca of computer programming. Despite this handicap, I prefer to avoid C and C like languages for a very good reason. Instead of just explaining why, I am going to quote Bruce Sterling:

As it happened, the problem itself--the problem per se--took this form.

A piece of telco software had been written in C language, a standard

language of the telco field. Within the C software was a

long "do. . .while" construct. The "do. . .while" construct

contained a "switch" statement. The "switch" statement contained

an "if" clause. The "if" clause contained a "break." The "break"

was SUPPOSED to "break" the "if clause." Instead, the "break"

broke the "switch" statement.

Without even explaining what went wrong, it's easy to see the problem with a language with ambiguities. I can't deny the benefits one gains from C, and in this case, writing Telco programs to handle some very high end real time equipment requires a language with those benefits.

I also can't argue that Haskell doesn't have these problems, either. Seeing the kind of complexities using Monads brings, I can't imagine that it's impossible to write obfuscated code. (Actually I would love to see some horribly obfuscated Haskell code; it would be an interesting learning experience.) As actual program binary size grows, though, it's important to reduce the errors per bit ratio. People like to measure projects and code by Significant Lines of Code (SLOC). Assuming one bug for every thousand lines, a one million line banking project would have 1000 bugs, plausibly. There are two approaches found in trying to manage and mitigate this problem. The first falls under 'Design Patterns'. The goal of this solution is to create patterns for putting together ideas, so that the chance of error per LOC goes down. After all, if a good design philosophy could bring the error rate down to one bug per ten thousand lines of code, the bug count would go down, and a manager could get a raise.

The other solution is Abstraction. This actually comes two fold as well. It all means the same thing though. The first is the use of verified standard libraries. One example of this is the prolificness of web frameworks. All the data marshalling, network connection, session management, run time systems access, and connectivity to other services can be abstracted cleanly away with libraries that are tested, packaged, and sometimes sold. In some cases there's only so much that can be done through a library, so many languages come up with convenient structures for handling more esoteric duties, such as concurrency, object oriented programming, aspect oriented programming, certain design patterns, and orthogonality between data structures and language features, all of which require clear support from the syntax. Ultimately, it falls on the shoulders of compiler writers, the duty to make it all come together, whether it's a linked in library, or assembler code generated by a standard language library.

I want to include a new measurement for measuring code complexity, Logical Lines of Code (LLOC). Writing concurrent code in Erlang, with automatic handling of multiple threads that frobnicates foobars amounts to 70 SLOC. Considering that each line of code represents 20 lines of thread safe goodness, this program amounts to 1400 LLOC. A bug rate of 1 bug per 500 SLOC turns into a bug rate of 1 bug per 10,000 LLOC. Suddenly, someone is getting a very big raise. Similarly, a thread safe data container library in java would represent 10 lines of non thread safe container code that has the end developer playing with his own locks and mutexes.

As a side point, lispers have been claiming for years that they don't need to wait for language designers to make up new features, just so they can use them. Through prudent use of defmacro, any new language feature can be designed on the spot. Without going into the sometimes named 'autistic programmer' problem, it leads to alot of fragmentation of the design. LISP seems to have as many design patterns as Java, and they seem to focus alot more on reducing the SLOC count. It also creates a funny problem where no two people's code can look alike. I couldn't even call this balkanization, but it makes LISP the interesting black sheep of the language evolution family tree.

Ultimately languages like Erlang, Haskell, and even F# aren't free of these nasty syntax issues that have bitten the best of the best programmers at least once. Every program is doomed to fail at something, but when trying to reduce the epicness of the fail, you don't want to have low level code hanging around your neck.

Why Haskell?

Over the past few days, I've been taking time off my regularly scheduled programming to learn a bit of Haskell. Anyone who knows me knows I have a tendency to ignore those things I'm supposed to do to go an experiment with those really obscure things that interest me. I think my New Years resolution this year is to stay more focused on those things at hand, but allow me to elaborate why I think Haskell is such a great idea, and what I've learned from it these past few days. But first, let me digress.

In the beginning of 2005, I took my first stab at writing code in Python, for school. My school was pretty Java centric, and despite 5 months with the language, I was already seeing some of the problems with it. I was taking a discrete structures class, and I was working on some 20 line program that needed to 'just work' and after learning SETL in high school, Python, with its funny list comprehensions seemed like a good fit. I never got that program to compile, and I ended up dropping the course, because the professor couldn't teach. (Considering that the entire contents of the course can be summarized in three sentences on Wikipedia, I resolved long ago that I probably didn't even need to take the course in the first place.)

The biggest lesson I took away from that is what is involved in learning a language as an adult. I learnt BASIC, LOGO, C, and C++ by the time I was 14, and while I"ll never go near those languages (except LOGO) without adequate sanity protection, I have to remind myself that the learning process was very different then. In the summer of 2005, I was already writing webcrawlers and text parsing scripts in Python, and becoming quite familiar with the process. In 2006, I worked on a couple of J2EE projects, and created some tools in Python, using PyGTK, and picked up alot of theory in the process. Writing in Python seems like almost second nature after 3 years of use, but I can't let myself forget, my first program never worked. That was the most valuable lesson I could have learned in Python.

In order to learn Haskell, I picked two projects to work on. The first is a couple of patches to bos's cabal-rpm, and the second a patch to xmonad-contrib. Let's face it, 2008 was nearly upon us; how many more 'Scheme Interpreters' do we need to see written in under 48 hours [1] ;-). There were a few other projects one could do to learn Haskell, but I wanted to do something that seemed more practical to me. cabal-rpm was an obvious choice. If I am going to take learning Haskell seriously, the few days invested in making good RPMs out of haskell packages would pay for itself. Instead of fussing around with Cabal and Haskell's own library management, I could integrate it with the tools I already invested time learning, Yum and RPM. Despite my initial complaints about the pair, I've really learned a lot about them since then, and Yum especially has grown on me. (On that note, I'm trying to revive the Haskell SIG, so if anyone else is interested, please help.) The second patch was a bit more circumstance. As I posted I had been playing with xmonad, and I came up with a funny idea for inclusion. I don't know much about all the mathematical formalisms that go into a language like Haskell, but I use a huge number of them every time I tun on my computer, so I decided to just dig in and see how easy it would be to prototype my idea. I had to go through three different ideas before I could find something that made it work, and in doing so, I learned a lot about some of the more esoteric data types in Haskell.

http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours

The most exciting part of all this, though, is not that I learned a new language, but that my code actually works. Of course I'm an older and wiser man than I was 3 years ago (sarcasm included), so I was expecting that I would eventually come to understand Haskell better and faster than Python. But every time I came up with a prototyped idea that Haskell didn't like, I had to remind myself, I'm still doing it wrong, and I just had to come up with a better idea, to make it all work.

The most rewarding part of it all, was how once everything compiled, it worked. In the Python world, I have this bad habit of throwing in liberal amounts of debugging statements to make sure that all the types are matched up. The ease that one can just insert things into the language, jump into the interpreter, see the results live, and then continue developing certainly makes learning the language easier. None of this could match the high level formalism that I was able to achieve in Haskell. In writing code, it felt like I was nearly writing pseudocode that described the problem I was trying to solve. If I got a compiler error, it wasn't because my code was buggy, but because my idea was buggy. All I had to do was formally describe the data types I wanted, and if the idea really did fit in the code base, it would compile. Furthermore, by just glancing at a block of code, I could easily figure out what it did. If it didn't do what I wanted it to do, that was obvious. Once the code compiling, there was little need to test it, because I already knew it worked. When it didn't work, I would get some very clear messages from the compiler saying what didn't match up. (When I say clear, i mean the messages themselves were terse and a bit cryptic, but part of the learning process was to learn what they meant as well.) Once I got a good feel for what the errors were saying, I was able to use them as a guide to figuring out how to fix my code. It became a cycle of edit - compile - read - repeat until read = 0. Late at night, it felt almost like the compiler wanted my code to succeed, so it was giving me hints as how to fix my idea, so it could actually make sense. To my Python senses, it was certainly a more enlightening experience than a number of 'log.debug(obj.__class__, dir(obj)) statements.

So why should you learn Haskell? It wasn't as easy to get into the syntax the way it was with Python. I can't deny that Python is probably the easiest language to 'read'. For introducing people to programming, Python is still an excellent language. But if you're looking for a language where you can tell the computer exactly what you mean, and see it work right away, Haskell is a much better choice.

How to install your very own XMonad XMas

Last night, I posted up some xmonad packages for Fedora 8, sans install instructions. Here they are now. Right now these packages are only for i386, although the SRPMs are there, so if someone can compile them for another target platform, I'll include them, if I don't figure it out first. Do the following as root:


# wget http://fedorapeople.org/~ynemoy/xmonad/ynemoy-xmonad-1.0-1.fc8.i386.rpm
# rpm -i ynemoy-xmonad-1.0-1.fc8.i386.rpm
# yum install xmonad.i386 ghc681-xmonad-contrib.i386
# rm ynemoy-xmonad-1.0-1.fc8.i386.rpm #clean up a bit


This should install xmonad. To set it up, you'll need the directions from the following sites.

How to prepare your GNOME Session: http://xmonad.org/gnome.html
A sample configuration using contrib extensions to run in GNOME: http://haskell.org/haskellwiki/Xmonad/Config_archive/loupgaroublonds_xmonad.hs
A screenshot of this config: http://haskell.org/haskellwiki/Image:Loupgaroublond-config.png
xmonad: http://xmonad.org/

Enjoy!

bug reports, issues, complaints, and pictures of cute femmes in christmas costume can be sent to xmonad-fedora <squiggle> hexago <blip> nl

A very XMonad XMas

Last summer when I was working at my internship, I noticed some funny usage patterns when working with GNOME. As a testament to Red Hat's ability to challenge a person, I had 10 virtual desktops set up with something going on on each one. Usually there would be a virtual machine doing foo, a Turbogears app doing Bar, A Jboss server doing baz, and eclipse being totally useless. I also had all the accompaniments, amarok on another destkop all by its lonesome, MySQL administrator on another, mail apps, random web browsing as a catch all bucket, and terminals everywhere.

Since emacs would do just about nothing except make Java and Python code look pretty, I would generally have two or three terminals along side eclipse just calling rebuild via a few keystrokes. I would wake up the computer every morning would start arranging terminals like flower petals all over the system, in places so I could find them. All that talk people say about metacity 'getting out of your way, so you can get to work' was utter crap. Metacity just wasn't working for me.

Had I known about tiling window managers then, I might have made the switch. Who knows what I could have done, had I had a tiling window manager available to me. I might have been able to finish all the projects I set out to do, I might have even made my group look very good. Who knows? I might even have been able to make that 100 yard pass and cured cancer.

Since then, I've gone back to school, and writing papers really doesn't need all that craziness. (If anything, Hans de Goede's latest patches to gstreamer will make it easier to do my homework without having to go to the labs just to use a windows machine for media.) But being the hip, up to date, thoroughly modern person that I am, I've finally discovered the joy of Monads and X. Wanting to learn more about Haskell at the same time, I started tinkering with it, and so far, I've found it a joy to work with. As a side effect, I'm even noticing better VI habits thanks to the similarity in keybindings. Wanting to see Fedora packages, and learn a little more, I decided to hack cabal-rpm to make it create sane packages. Below are the product of these changes, your very owns set of XMonad packages for Fedora. I'm currently dogfeeding myself with them now. Enjoy!

http://fedorapeople.org/~ynemoy/xmonad/

(Just so you know, this is what Jewish people do on XMas when there are no good Chinese restaurants or good theaters around town. It was far more interesting than tearing toilet paper, which is a major Qabalistic thing, I kid you not. And by Qabalistic, I mean the teachings of the ancient Rabbis passed down by word of mouth from generation to generation, not the packaging system for Haskell packages.n)

Smolt and Privacy

The first public draft of the Smolt Privacy Policy is available. Publically that is.

https://fedorahosted.org/smolt/wiki/PrivacyPolicy

Enjoy!

(discussion is in fedora-devel-list@redhat.com and #smolt on freenode)

GTK Theming

This makes me so happy.



I had a dark theme i was using for a while that had transparent window decorations that seemed to clash slightly with the non transparent ones. Glad to see i'm not the only crazy person.


Thanks to: GNOME theme engine designer adds transparency to GTK