Posts tagged with c

bitlbee and Usable OTR

October 2nd, 2009

Are you using bitlbee? Are your friends annoying you insisting on asking you nicely to use OTR? Then use this branch: http://khjk.org/bitlbee-otr/

But, what if your friends have a RL aren’t online and you still want to spam send them some nice message? Once OTR established a context, it won’t let go, so you will still send them encrypted messages, but once they come back, they probably won’t be able to read it. Sucks. But! There is hope! Use this small patch: otr.patch

Now bitlbee will only send encrypted messages when the recipient is actually online and otherwise fall back on plaintext. A little bit less secure, a whole lot more convenient. Yay!

Dijkstra, a quote

September 8th, 2009

In “The Humble Programmer” (1972), Dijkstra writes:

The analysis of the influence that programming languages have on the thinking habits of its users, and the recognition that, by now, brainbower is by far our scarcest resource, they together give us a new collection of yardsticks for comparing the relative merits of various programming languages. The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other  things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line programm on the desk of another either proudly tells what it does and adds the question “Can you code this in less symbols?” – as if this were of any conceptual relevance! – or just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language.

This is the year that C was invented in, and 15 years before Perl. I feel very guilty and amused at the same time.

Why Neo 2 is retarded

August 1st, 2009

This is a rant. Don’t take it too seriously. I’m sleep deprived and needed something to do, ok?

Neo 2 claims to be an ergonomic keyboard layout. I have been using it until about a month ago when I forked it and created my own layout. (I’ll upload it here once I get around fixing the last few bugs.) I don’t contend its claim as far as the letters are concerned. However, level 3 aka Mod3, containing the punctuation characters, is totally fucked up. How fucked up? Let me demonstrate.

First, let’s get some data. What’s a typical use for Mod3? Programming and normal texts. I decided on analyzing C (representing curly-bracket languages), Python (representing pseudo-code and list languages), my shell history and shell files (representing Unix usage) and Perl (representing line noise). Additionally, I included my local Usenet cache to represent normal texts. I took several thousand files each and in the end averaged them all together. (data: freq-c freq-pl freq-py freq-history freq-news average)

Second, we do a little experiment. Say, if Neo 2 is actually ergonomically optimized, we would expect the most frequent characters to be on the easiest to reach positions. Of course, it depends a little on personal taste, keyboard form and hand size how easy each position is, but let’s go with the arrangement the Neo devs chose for their letters. If the layout is optimized, the most frequent letters and the most frequent punctuation characters should be on the same physical keys.

Let’s see if this is true. Here is a little table, showing the letters sorted by (German) frequency and the corresponding Mod3 character. I’ve put the keys with “.” and “,” according to their left-hand equivalent. Green means 5% or more, yellow down to 1.5% and the rest is red (which is often around .01%). Have a look.

2009-08-01-130742_324x648_scrot

Great fucking job, guys. The 7 best keys get only 2 frequent characters. 6 frequent characters are in the middle of fucking nowhere. You decided to place an obsolete character, the long S, that no one in my fucking news cache even used at all, in a better position than ,, ., , [3] and #, which together make up a good 40% of all punctuation. [0] The one character that is more frequent in many cases than any letter except the friggin’ E, and more frequent than 2/3 of the letters in general, the underscore, isn’t even anywhere near a good position.[1]

Way to go, Neo, way to go.[2]

[0] Some of the reasoning behind this is that any Mod1 key is easier to reach than any Mod3 key. If you think that Mod3+N is harder to type than Ö, then I wouldn’t let you design a wooden stick because it seems your brain is barely able to use 2 fingers at the same time.
[1] “But I don’t program! I rarely need an underscore!” But you constantly use curly brackets, more often than any other bracket?!
[2] To be fair, it’s impossible to optimize for punctuation-heay curly-bracket languages and normal text at the same time. However, this half-assed mess makes it hard for both groups. That’s clearly not a good solution. I chose to optimize for the programming languages because a) I use them more and b) they tend to be so rich in punctuation that they simply overshadow normal text.
[3] Which are not even normal punctuation, if the Neo devs weren’t so inconsistent in their design. If you want to follow official guidelines[4], you should use the German quotation marks „ and “, and the proper accent ’. Which are even harder to reach. Which makes the whole thing even more retarded.
[4] Prescriptionist dipshits are the topic of another rant.

Language background

July 12th, 2009

When studying a programming language, I find it useful to look up the background of its creator(s). It will tell you much about its internal design, style and usefulness.

A few examples.

Lisp, and to a lesser degree, Python. You can really tell that John McCarthy and Guido van Rossum have a strong mathematical background. The language is simple, elegant and gives you few, very carefully designed tools. Lisp is maybe the language that is conceptually the most beautiful, yet totally impractical. You probably should write in Lisp, in some ideal world, but you won’t be able to get anything done. It completely clashes with how you actually think and would like to write a program.

C. Ah, a physicist. Simple tools, yes, but completely designed for the task at hand. A good C program may be very powerful, but you always feel you have to study for years until you can get it right. It often feels like black magic. Properly understanding pointers and memory allocation alone can take quite a long time, even just on a conceptional level. You may get the basic idea, but then there are all kinds of traps and exceptions and weird cases were just everything breaks down.
I always feel reminded of quantum physics. It may not be that hard to get the concept of uncertainty at first, but when you look at practical cases, it gets totally messy. You have to use funky equations that bloat and bloat, weird concepts just so you can handle it and get results at all, and when you design an experiment, it will still break down and you’ll spend weeks fixing bugs.
I love the language, but if the universe were written in it, it would have constant leaks, be insanely huge compared to its actually purpose and most of its parts would be all over the place, in seemingly unrelated places. Actually, that does sound quite familiar…

C# and Java. Designed by a committee, led by a software engineer. That really tells you everything you need to know. They are full of cruft (backwards compatibility is one of the worst ideas ever), concepts that sound nice on paper, but have not proven to be really useful and huge, quite often to the point of being slow. Companies and governments favor these, for obvious reasons.

Perl. The only (?) programming language designed by a linguist, which is probably why I love it so much. Actually, it feels a lot like Japanese to me. The set of keywords and basic functions is huge, with a word for each specific idea and fine nuances. Context is important and words can mean very different things depending on how you use them. In fact, because of context, you can often leave out redundant or obvious parts.
It may be the only language to encourage you not to use (explicit) variables unless you think you need to.
Looks reflect purpose, such that weird constructs actually look weird, while common constructs become clean and simple. This empowers you to represent ideas the way you think is best for the job. You can always say things differently, if you want. You can be more explicit when talking to a foreigner, slur and mumble when speaking among friends (or to yourself), emphasize a specific part or just use your own kind of dialect. While this makes it possible to write the most incomprehensible program ever, it also allows you to write poetry.
Of course, over time, this has led to weird exceptions, idioms that may not seem obvious at first and a full-on culture you can not ignore when using the language. But the reason why it’s maybe the most human language is it’s choice of elementary building block: Lisp is build around the list, C focuses on memory and numbers, in Smalltalk everything is an object, but the first thing in Perl is the word. Everything is (kinda) a string and most of it’s features are specifically designed just to handle those in efficient and smart ways. Humans do not think in objects, numbers or lists – our mental stack is way to small for this. We can barely add numbers with more than 4 digits or keep track of more than a few dozen people and our memory is kinda hazy, but we can easily remember and use tens to hundreds of thousands of words in complex structures, with ad hoc grammar and no formal (or even central) definition at all. There is a good reason why you use plain text to explain stuff and only the most twisted of minds would consider a mathematical proof straightforward and intuitive. So why do we build languages mostly like the latter and rarely like the former? I don’t know.