64bit assembly

I've spent some time over the last few days looking for books and or tutorials on x86_64 assembly language. Much to my disappointment there dose not seem to be anything at the moment.

If you look on forums the best answer you will get is learn x86_32 assembly then look here to see how 64 bit is different. This is fine if I allready knew 32 bit assembly but I don't I'm starting from scratch. So why should I waste time learning how to do things on on 8086, or even the 80386 when I want to write programs that run in 64 bit mode.

Now I realise that there is an awful lot of common ground here but there are also important differences. There is an lot of legacy 32 bit and 16 bit ways of doing things which I don't strictly need to know when working in 64 bit mode.

so Instead of following the evolution of the chips I want to start with today's chips and learn how to adapt that to yesterdays chips if or when I need it. For anyone reading this who knows x86_64 assembly, you should write a book, or at least a good tutorial.

The tribulations of Setting up a Goldfish Tank

After spending the last three weeks setting up a goldfish tank I have to endorse the opinion that you should steer away from the generic pet stores. And I mean completely.

Chances are the staff haven't a clue, and management couldn't care less, even if they are cheaper. Before I knew this I went down to the local generic store to buy the basic materials, a tank, a filter etc. I fooled myself into thinking I'd pay less by buying basic glass tank, and compeltly failed to factor in the price of a filter and a light. Even on this score It's hard to tell if I came out ahead or behind.

At every jucture I asked if item x was suitable for a cold freshwater aquarium. Turns out the gravel I brought wasn't, it buffered the water and drove up the Ph, so much so that I couldn't make it budge from a reading of 7.5 no matter how much ph down I put in.

So I spent half a day replacing the gravel, with the stuff I got from an aquarium shop. Unlike the generic pet store these guys will not sell you a fish without testing a water sample first. When I complained about the buffering the first thing the Guy said to me was, you have white gravel don't you? And yes I did.

So I went back to the pet store and asked for a refund on the gravel, No can't do that, Not responsible. The manager says in a I've got your money and I couldn't care less tone. Half way through the conversation after telling me how all his gravel comes from the same place he admits that the ph problems occurs, but stress that its not his responsibility, as its prepackaged. He says the black gravel can be even worse. Still after all this the only thing he offers is to replace it with another bag from the same place. Then turns his back on me to go and get money out of another customer.

Needles to say I was ticked off (yes self censorship is going on here). Still I have new gravel and the ph is dropping towards where it's supposed to be, and I have learnt a lesson. Now all I have to do is find an alternate place to buy replacement pads for my filter, as I don't plan to give that particular shop any more of my money.

I have half a mind to make a complaint to fair trading, would I be wasting their time on an item which cost $16.00 though?

PS while fantails at the Pet shop were $1.50 cheaper even I could see the difference in quality. The fish I got from the Aquarium shop are shiny, with bright orange and gold scales. The ones at the Pet shop meanwhile don't look shiny at all, and have pale dull colours. If the fish weren't a different quality to begin with, clearly the petshop is doing something wrong to them.

PicoLisp in a chroot

Picolisp has a nifty feature where you can include inline c code, and it will be automatically compiled for you, and just work.

Unfortunately I'm on a 64 system, and pico dosn't at the moment compile under 64 bit. Now I'm told that if I install the right things and tweak the right options I can get 32 bit binaries to compile anyway. But that involves modifying the upstream source and I don't like doing that, unless I plan to submit a patch.

In this case It seemed somewhat pointless. So I though I'd try setting pico up in a chrooted environment. I came accross the following post on the matter: Installing apps in a 32-bit chroot in AMD64 Debian systems.

I followed most of step 1, with the following exceptions:

• I skipped step 1.3 (decided not to mess with my main gcc instalation.
• Installed gcc, and build-essentials into the chroot. (also locals and less which didn't get installed by default.
  
• Installed dchroot into my real system ( I think this is soemthing the tutorial does later).
• Compiled picolisp in the chroot enviroment and installed it to /usr/local/
  
• Added some scripts to my real path which would execute picolisp and psh in the chroot.

All in all it was a surprisingly easy process and at the end of it I have a fully functional picoLisp. which is accessible form anywhere. even the scripting is easy.

!#/bin/bash
dchroot --preserve-environment <> "$@"

This lets me run pico the same way weather I'm in the chroot or in the main system. And there are no gremlins. I started a picolisp server in the chroot, started firefox (I mean Iceweasel) in the main system, and everything worked, even the ondemand compilation of c from inside pico.

Partially I did this because I wanted to learn how to do it, and now that I have a 32 bit chroot I'll probably move my IceWeasel into it and install flash.

Hmm, I wonder which I'll see first, 64 bit PicoLisp or 64bit Flash? I have it on good authority that they are both in development.

Programming is not that different.

It seems I'm not the only one who thinks programming is
just anther form of composition.

Applying Strunk and White to programming - absolutely inspired (I wish I'd through of it first).

I have seen a few places aregue that Design Patterns, as they are commonly used, are a complete missinterpreatation of A Pattern Language by Christopher Alexander.

Just two examples of how Programming is not that different from everything else. And why Extreme Programming is a step too far.

PIcolisp Cookbook

One thing which picoLisp needs is a Cookbook. A set of recepies on how to use its quite rich set of primitives to solve particular problems. Currently most of this information is somewhat implicit in the Reference docs. And requires making some big inferences after considering which sets of functions have links to each other.

All of the built in functions are documented, what is missing at the moment however is the various idioms for using them in practice. Thankfully you can usually get a prompt answer on the mailing List.

I came acrose one such are the other day. I was trying to break a circular list, built by fifo, into a plain list. In Common Lisp I'd do this with set. so I tried it to no avail. In Pico (set (cdr A) NIL) actually sets the 2nd element of the lsit A to nil.

It turns out that to set the cdr portion of a cell I want a function called con. My first reaction to that was ... well that's annoying. But then I got to thinking that its not actually a bad thing. Essentially we have to setting functions which are subtly different.

set: is used for setting values, and con is used for manipulating structure. Yes things get a little confusing if you use cells to build a tree structure where both the car and cdr contain pointers to other cells. That aside I when reading code I can assume that calls to set will change values but not alter the underlyign datastructures, while calls to con will alter structure.

The more I think about it the more I like this distinction. It adds something usful to the code. In the end the only thing which tripped me up was documentation. The Picolisp docs are good as far as they go, but missing a few bits.

Alex, the maintainer of PicoLisp, seems somewhat reluctant to make the official documentation more verbose. Well we may have to agree to disagree on that one. But there has been talk of building a picoLisp wiki (powered by picoLisp). And this may go some way to adding the Cookbook style reference that appears to be needed.

Inform - first lesson learned

As a programming language inform is an excelent tool for writing fiction. Take the built in 'What not to wear' example. On the one hand it shows how far the language can be pushed. On the other I haven't seen code this contorted since reading a book about Visual Basic 6.

Examples like this really show how much Inform is not natural language.
To be honest I still can't understand how the damn thing works. Getting it requires a much deeper understanding of Inform Grammer then I currently possess. Here Lies the nub. Inform makes simple things simple, and allows you to write interactive fiction. But like most special purpose tools it makes hard things harder.

From a language point of view we have conditionals, looping constructs and an object hierarchy. We can also construct data tables and lists. All in all we have a language which is not only Turing complete, but as feature rich as general purpose languages like Java. The problem, form a programming perspective, is that we have a syntax which can be more cryptic then Perl!

The short answer; If Clothing is not a central focus of your game; ie your character is not a catwalk model, then don't implement a generic clothing system. Changing a characters description when they put on a Jacket, or a Has mat suit is so much easier, and for most games is all that is required.

The other problem with overloading your games with generic systems is that most will be published as Z-code files, and this places some major limitations of executable size. Recent posts I've seen on rec.arts.int-fiction suggest that even the z8 standard has trouble reaching novel length (about 50,000 words) and that is without including bucket loads of extra real world simulation rules.

Interactive Fiction

I've been toying with the idea of writing a text adventure for a few months. Granted I didn't do anything more than think about it untill a Random post on slashdot, or ReadIt (I forget which) linked me to Inform7.

Suddenly I discover that there is a thriving home brew community writing and playing Interactive Fiction. And Inform is a rather interesting approach to writing it.

Interestingly while story files are free they are not open source, as most games are shipped in binary form only.

Inform 7 is both very enticing and frustrating at the same time. Its goal to allow Interactive Fiction to be written in plain english is admirable and works quite well for simple cases. However in the end it is not english but a language which overlaps with it. The upside is it looks cool, and the fact that you are porgramming is generally hidden from few. The downside is that when you do need to do some programming you end up with a very verbose syntax, which often does not make sense as an english sentence.

For example: 'the list of things carried by the noun'. In English this is nonsense as nouns can't carry things, however it does make perfect sense to inform. As a comparison I had a cursory glance at Inform6 and TADS3, and there really is no contest in the given domain.

With inform I feel Like I'm writing a story, while with the others I'm very clearly programming. The challange now is to write somthing worth playing. Now I have a plot in mind, and I'm learning the tricks on how to extend inform to do new things. This leaves one stumbling block: I've forgotten how to think about Interactive fiction puzzles, solving them is hard enough, actually writing them, well I'm yet to come up with an interesting puzzle. Guess I need to play more Interactive Fiction first.

Anonymous Recursive Function

I thought I'd give the 99 Lisp Problems a spin as a way of exploring Pico Lisp. One of my first outings came up with the discovery that if you call a function without enough arguments the remaining arguments get set to NIL this can be used to do default arguments as follows:

(de fun (X Y)
(let (Y (or Y 5))
  (+ x Y)))

(fun 1 2) -> 2

(fun 1) -> 6

I did this to simulate an accumulator argument in a recursive function. But then i got to thinking, I'm executing the let on each recursive call, which seems kind of a waste as it is only needed on the first call. Well Pico has an answer for this recur and recurse which allows you to define an anonymous recursive function. Now this is something you don't find in your garden variety common lisp!

a list reverse (yes I know its built in but it see the 99 Python problems above) is then implemented like this;

(de my-rev (lst)
 (let (res ())
   (recur (lst res)
          (if (pair lst)
            (recurse (cdr lst) (cons (car lst) res))
            res))))

That is one neat way to make do without auxiliary functions.

Lisp is addictive

A week or so of Pico Lisp and I'm addicted again. Now the label was right, this is no common Lisp. Part of this means that a lot of built in functions have different names but then lets be honest, 'filter' is a much better name then 'remove-if-not'. I also found that there is no 'reduce' function but it was trivial to implement.

I have to say that having having one name space for functions and variables works, and using quote as lambda is growing on me. Pico lisp is proving to be a very succinct lisp to program in, which is a good thing.

Time permitting I'll be doing a lot more pico lisp hacking in the near future, port a few scripts I've done in python as practice and then on to some more interesting stuff. I've got some pointers on how to mix pico lisp and c code, which will is bound to prove useful

Been away from Lisp too long.

Yes I'm sad to say that I've spent too long without messing about in Lisp. Now that I'm trying with pico lisp theres a lot of basic logic which seems to be bogging me down, such as when to quote and unquote things (though Pico lisp seems to be a little different in this regard).

Another omission, from the point of view of convenience, is the lack of a well developed string formatting function. Granted the built in symbol manipulation primitives are more general then a format function but in simple cases they lead to more verbose code. Note Pico Lisp does have a function called format but it is restricted to formating a single number as a fixed precision decimal.

Still I'm working slowly in adapting some examples from a Common Lisp book into Pico Lisp, and if nothing else its an enjoyable exercise.

It looks like I am on the Pico lisp mailing list, though I never got notified that my subscription request was accepted. Still I got to ask my question now, which is good.

The Demise of the Desktop ... Not

Predicting the pending demise of the desktop seems to be quite popular. In the very near future, we are told, all our apps will be on the net, and all our files will reside on massive, but benevolently run servers. Our computers won't in fact need a hard drive at all, just a connection.

Frankly I don't see this happening for a number of reasons.

• My Laptop is offline most of the time. I mostly use it on the train and don't have wireless broadband. In any case I doubt it would work too reliably sitting in aluminum clad train under high voltage cables.
• At home my download limit per month is about 300MB and is about right for my usage. frankly I couldn't afford to access online apps all the time.
• I don't trust the benevolent administrators of huge online file servers to keep my files confidential if it ever comes to the crunch. If large chunks of the worlds data are in one place then it becomes easy for governments to mandate the removal of 'harmful' material.
  

There are still a lot of development hours being poured into desktop environments, Gnome and KDE, as well as dozens of others, are active projects. Clearly the developers working on them see a future for the desktop, otherwise why would they bother? The grand Idea of the centralised file store has flopped a number of times, as Joel argues in Architecture astronauts take over.

And in a corporate environment there is another host of problems with thin client, issues of Privacy regulations and Commercial secrets. An interesting fact comes up in this artilce on The Daily WTF. Switching a corporate environment to thin client increases infrastructure costs. Suddenly your junior desktop support staff who know how to run Norton Utilities just don't cut it any more, instead they need more servers and more system administrators.

Personally I like my Desktop applications and I use them all the time. My laptop is set up how I want it and not how Google wants it. Even when I do use my firfox it is usually to read pages I've saved for off line viewing using the scrapbook plug in. And importantly the files that detail how I'll achieve world domination are tucked away in a computer that can't be hacked without physical access (one of these days I must encrypt them).

White space

I came across an interesting blog post the other this morning: Python Indentation considered boneheaded I like meaningful indentation. Because I find it easier to think that way. I had coded in other languages for quite some time before discovering python.

This means that I have probably spent weeks of accumulated time going back and adding semicolons to statements because I forgot to terminate them the first time round.

As for using python on larger projects. Well the answer is internal standards. If you try to contribute to C projects like GTK they come out and say things about standards right up front.
If you submit a patch and it doesn't meet the coding standards then we are going to reject it out of hand. Its quite a reasonable position to take.

Moreover a good editor will support a whitespace delimited language. My examples are from vim, though I assume that Emacs can do similar things as well (no need for another editor flame war).

• Auto indentation sticks consistent indents on my lines.
• Editor can highlight lines that mix tabs and spaces in their indents.
  
• Files can carry a special comment which defines indentation rules.
• If all else fails you can switch to a mode where whitespace characters are rendered so they are visible.
  

In my day jobs all the code is python. The code base is quite large and has probably had over twenty developers working on it over the last nine years. For reasons which are lost to history we use tabs only in all the files, and it works. Some developers do seem to feel strongly about the tabs vs spaces debate. Before starting here I used spaces, but when it comes done to it I really don't have a preference. About the only Thing I will attest to is that you should not mix the two approaches in the one file.

I had to write some java a while back, only a small simple problem, and after python I found it unbelivably hard. I realise this is largely personal preference, but iit felt like the syntax was fighting against me rather than helping me.

At the end of the day a good syntax is one which you don't notice. Foe me being a visual person seeing well indented code gives me a quick graps of what the code is supposed to do. One of my egocentricities in this regard is that I prefer:

if foo:
  return
else:
 # do something else

to:

if foo:
  return
# do something else

Python will behave the same way in both cases, however for me the first option is more explicit. as I can see that we have an else branch without having to reach the code. If the body of the if is long enough it could be easy to miss that pesky return statement.

Pico Lisp

In my continuing search for a language to play with, other than python, I came accross Pico Lisp the other day. A very intriguing lisp dialect for several reasons:

• Fully interpreted and yet faster then compiled lisp in some usecases
• Persistent storage (essentially an object database)
• built in Prolog.
  
• built in web server and support for online applications.
  
• No floating point numbers ?
  

That last point seems a little curious. but then i got to thinking how many applications out there really need floating point numbers? Well there are really a lot of applications that don't. In my day job I deal with online payments. No floating point numbers here, just express things as cents and be done with it.

Using floating point in financial circles is in general a big no-no, people get a lttle tucky when your working with money and make rounding errors. Also its a little hard to do anything with a fraction of a cent.

Graphics. Well yes and no. Fixed precision might be quite good enough. Heck there's a 3d flight simulator application to prove it even. The Documentation claims it can be easily extended with C, including writing C functions inline, unfortunately exactly how this is done, or what the limitations are, is not explained. Once I get onto the mailing list I plan to ask.

First impressions are that this is a very small, neat and yet still useful language. Time will tell if I can do something interesting with it though.

Bad Karma

I'm really going away from what I intended on this blog but ...

Sharon Stone's Karma comment has to be the dumbest thing any celebrity has said this year.

Karma is supposed to return to whom ever generated, and I fail to see how school children in Sichuan have oppressed Tibet. Its clear to anyone that this is a natural disaster which has affected perfectly ordinary innocent people. They have nothing to do with setting government policy in Tibet.

Seeing images of collapsed schools with a childs hand sticking out of them brings tears to my eyes. I can't imagine what it must be like to shift through ruble looking for your child. For some starlet to suggest that its Karma ... I'm lost for words really ...

Even the Democrat Presidential hopefuls haven't managed a gaff this bad.

I'd call for a boycot of Stone's movies myself, but in all honest I've never been a fan so I probably wouldn't have rushed out to see them in any case.

The Horse and His Boy

In my recent reading I came across The Darkside of Narnia a critique by Philip Pullman. Here is an essay which has had raised some very heated responces. A common thread seems to be to say that If you think this than you musn't have read the books. I don't think this retort is justified, and it would be very poor form to publish such an essay without reading the matirial you are critiqueing.

I can't speak for Mr Pullman, but I have read the books (ok I didn't get to the end of the last one) and I have to agree with him. Let Us take 'The Horse and his boy', which until I read it a second time had been my favorite of the Narnia books. So here we go with some questions

Is it racist?
Very much so. The Calormenes are depicted as dark skinned, turban wearing and following a religion based quite clearly on Islam. Every single Calormenian male depicted is a shrewed dishonest and evil. so much so that Shasta cannot conceive of anyone being charitable and honest. The only female Calormenian (other than Aravis) is portrayed as a twit who is interested in nothing other than cloths and parties. I believe in the last book Susan is condemned for having smiler interests.

Mean while all the honorable Humans are White, and Aslan fearing.

Are there literary shortcuts?
Rule number one of fiction is show don't tell. Lewis tells constantly. Aravis tells the start of her journey. Later one of the Narina's describes to Shasta exactly how to get to Narnia. Note he is not doing this deliberately, and any inteligent person would not divulge this information in enemy teritory, but he does so simply because the story demands it.

Rule number two: the Author should not speak directly to the reader. Lewis does this a few times as well, once to compare to contrast Calormenian story telling and Essay writing (as taught to the assumed audience) and again to urge his audience to also read "The Lion the Witch and the wardrobe", In case they have not done so already.

Rule number three: the Protagonists should not rely on the Caverly to save the day. Well the Story is driven by Aslan roaring. He herds the children together, and protects them form wild animals, and guides them every step of the way.

At the end of the day the evil are punished, the good (those who accept Aslan's will) are rewarded, and in true cristian fasion the Proud horse becomes humble. Instead of the expected growing attraction between the protagonists they get married in the future for the sake of convenience. While there would be no call to make that the main focus of things, some subtle hints of romance would not have been out of place, holding hands even.

All in all there is no character development over and above the intended moral lessons. So Pullmans critique is spot on. Narnia really is nothing more than thinly disguised preaching from the pulpit. The plots may be good but there is nothing holding them up.

What Erlang is bad at

Recently I wanted to write a program which would take sections from a texmacs document and run them through the style command. And then process the results to get a particular set of statistics.

This includes some additional crunching on what style produces. As it was my language of the month as it where I thought I'll do it in Erlang, but after spending a train trip searching the documentation I found that making system calls in a subshell is not somthing that erlang can do at all easily. I certainly couldn't find a way which did not involve writing a c wrapper around in any case.

So it was back to python for this one and a usable script done in about an hour. Lessons learned: Erlang is not a good language for quick and dirty scripts. I'm not saying that it can't be but the standard library dosn't seem to support such a use case.

An aquantence who is also programmer told me once that he is also tempted to look at Erlang now and then, but he can never seem to find a project that he really wants to implement in it. More often then not he ends up in exactly this position "Man this would be so much simpler in Python" and so that is what he uses.

I think I have a new point to add to my list of what makes a good language:

"Can be used to solve small problems easily"

In this regard anything which requires copious poilerplate or is missing simple ways to interact with standard in and out looses instantly.

Virtual Machines

In the recent debate about weather or not languages should ship with there own virtual machines, or use an established one. I'm with diversity here. Put simply different languages have different needs. Just because the JVM is good for java it doesn't follow that it will be good for Erlang. And Erlang is sufficently different to warrant it's own vm.

1. An Erlang vm can assume that memory will not be modified. I expect his has a big impact on how you manage memory
   
2. An Erlang vm requires tail recursion optimization. if you don't have this your code will be slow and use up more stack space.
   
3. Every Erlang process has a message queue. Most VM's will not provide a message queue out of the box.
   

A lot of the same things also apply to Haskell, you can't expect a functional language to work optimally on a vm designed for procedural languages. the code optimizations and memory management strategy needed is radically different. In this I'm quite in agreement with the following post:

Making it stick.: Huh?: "The fact that it runs on its own interpreter, bad."

Setting up a new Laptop

Just got a new midrange laptop and thought I'll install xubuntu 7.10 on it. but hay its 64 bit so lets install the 64 bit version.

OK that seemed to work so lets install the things I'm playing with at the moment. vim-full ... sorry no can do, Erlang ... no not this one either. In both cases the problem was a dependency on tk8.4 which does not work in 64 bit mode.

perhapses in 8.04 but then there's no easy way to migrate from 32 bit to 64 bit so I might not do that either.

Anyway I reinstalled in 32 bit mode and everything installed nicely, about the only thing I don't have working yet is flash but I'm sure that can be fixed if I get around to it. honestly I don't do much web browsing from my laptop, even though

More Erlang

I'm finding erlang to be a fun language to learn. One of the differences between it and other functional languages is that there is no type system. Well no extensible type system. we are really down to Atoms, Numbers, bytes, Tuples and Lists. With bytes generally being used as lists of bytes.

Even Strings don't get their own type, which is a little bit of a liability but can be muddled through for, at least for latin1 characters. Some people have hailed this as an advantage saying hay look I can learn to program and don't have to learn some complex type system.

So far my toy programs havn't felt the lack of types. But even there it seems to me that this could easily be added as with a preprocessor just like records where, if we take the perl approach of saying classes are modules then you can easily rewrite Var.doSomthing(...) to module.doSomthing(Var, ...) providing you know what module should be. which we could have declared at the time the variable was assigned to by writing Var~module (I picked ~ as it dosn't have any meaning that I'm aware of as yet.

The Question is then, is such syntactic sugar worth while and does it gain anything in reasability over the syntax that it is being written into? At the moment I'm undecided. It certainly seems like it would be doable, after all Lisp Flavoured Erlang is doing somthing much more complex then this. The key question would be how hard is it to write an Erlang parser in Erlang?

Erlang

I've started messing about in Erlang, and so far I like it. At my current, very basic, understanding of this language it seems to be much closer to the original Object Oriented Model then most of the so called Object Oriented languages are. The syntax is purely functional and inspired by prolog, though the execution model is different as there is no automatic backtracking.

Basically it's all about message passing. And having the kind of flexibility where any object can pass arguments to any other object. In the case of Erlang every object will be a process which has an event loop at its core. naturally by loop I mean a tail recursive function.

The only thing which appears to be lacking is any explicit mechanism for inheritance, however this can be addressed with small amounts of boilerplate code. It early days so anything I try to post up at present will probably look woefully amateurish, if not plain wrong, to anyone with more Erlang experience then me.

The big advantage being that each object (or process as Erlang calls it) can be executing on a different cpu or even on a different machine. This fact is essentially invisible to the caller. There are some syntax shortcuts for sending messages to local objects but they really are quite minor.

Coincidently there have been a number of Erlang posts on reddit recently:

• What Sucks about Erlang
• Response to What Sucks about Erlang
• Erlang get Unicode Strings
• Lisp Flavored Erlang
  

I'll get back to Unicode a little later but the first two deserve a little more comment. About the only thing I strongly agree with in the critisims of Erlang is that Records really do seem like bolted on afterthought.

having named fields is very useful, but we don't really have named fields only the illusion of them, but I guess that's what normally happens with macro features. Sun implemented inner and anonymous classes in Java in much the same way, and with some of the same warts.

The subject of Unicode support is another thing entirely, I recently bagged Arc for not having it. Now the interesting thing here is that Erlang does not differentiate between a list of integers and a string. So in theory at least you can represent any set of code points you like, as all existent Code points fit within the bounds of an Erlang integer.

What you don't have however is any indication of which of your lists of integers are stings, nor any indication of what encoding a particular string might actually be in at the present moment.

In practice things are nolonger so simple. In Ascii you could get away with treating a string as an arry of bytes and things just worked. but nowadays things are not so simple. With UTF-8 different characters take a different number of bytes. Even with utf-16 you still have the problem that the same visual string can be represented by several different byte sequences.

The same problem means that a lot of Python code I've written in the last year or so will break badly if I tried to migrate it to Python 3.0. The assumptions of binary / string compatibility are simply nolonger there. Such I guess is the price of progress, we can represent almost every language on earth, but even the basic case is now harder than it used to be.

And finally there is the promise of Lisp Flavored Erlang. On the face of it this seems fantastic, and I plan to play with it extensively. Not yet however, it may be valuable to learn Earlang before I start playing with alternative syntaxes. I believe the big thing that LFE adds is scheme like macros. Let us see what happens to LFE once the 'new shiny thing' hype clears a little.

The folly of Arc

Somewhat belatatly I learned that Arc had finnally been released. A few moments of excitment soon ended when I learned that what had been released was a set of mzScheme macros. Worse yet a set of MzScheme macros which require an old version of said language, because the latest version breaks something.

Having read 'Arc is Out' I have to say that I haven't seen anything is contradictory to good software engineering practice in a very long time, at least not outside writing which is meant to be satirical.

How Ironic that Paul Grahams Announcement of the language spends several paragraphs belittling attempts to not break existing code when releasing new versions of a language. Interestingly He pre-picked the two things that everyone would object to:

1. Supporting ASCII only
2. Shipping with a table based web framework.

On the first of these points. No wrong answer you should have supported UTF-8 to begin with. The ability to do character set conversions can wait, but at a base UTF-8 seems like the way to go. Right here a lot of programmers who need to use languages other than English will say, this isn't worth it, even to mess about in.

On the second point. This isn't just not Politically correct, its plain wrong. Tables are ridged structures which do not sport much in the way of experimentation. Do the same thing with Divs and Spans and you can experiment, shape and reshape, make things align differently. I don't know anyone at the W3C personally but I can respect that they have spent a very long time thinking about the problems of markup languages. Somehow I'm more inclined to trust them then a single person who is effectively saying I'm right and the rest of the world is wrong.

Looking at the rest of the Essay, Yes lists are good but lets be honest they are not always the best choice. In most programs I may not know exactly what I want but I'll have a fair idea, and no I wouldn't represent a point as a list, I'd use a tuple. Why? Because chances are I know that I need two elements, or three elements and that all my points will have that many elements.

Using the right data structure for the right job is frequently important. For the most part I prefer to do this early rather than late, and can usually work out where I need a List, or a Tuple or a Hash or a Set.

Where structures with named fields come into there own is that while experimenting I can add fields at any time. I f I used Lists or even tuples this becomes much harder. When you know your points are just lists it takes an awful lot of discipline to not treat them as such, and sooner or later doing so is going to come back and bite you.

I speak from experience here I've dealt with data structures which where just nested lists (something like seven layers deep) and it was not fun. Worse yet code which references things by field name is much easier to read then code which has indexes peppered all over it instead.

All in all I'm sad to say that I won't be looking any deeper into Arc, because if fails my basic tests on what languages are worth spending time on. Last time I ignored my standards I spent several weeks looking into newLisp, even though I had grave misgivings on the Authors memory management philosophy of one reference to any object (ever), and Dictionaries can exists as top level objects only.

One day there will come a Lisp to rule them all, but it would appear that Arc is not that language.

What is in a Name

I'm still looking for the perfect word to name my blog. My critria being:

1. Has to be a single word so that the Wind in the Willows quote works
2. Has to cover programming
3. Has to cover Writing Fiction

I'm thinking that the meaning of Lexicons needs to be stretched a fair bit to do this, but for some reason I'd rather not use Languages. Somehow that brings up the wrong connotations (such as bad language) in my mind.

Anyway Lexicons it will stay until I come up with something better.

I just finished reading 'World Building' and it was an all together very interesting book. And has a couple of interesting conclusions:

1. If we find another advanced civilisation out there changes are they will be carbon based oxygen breathers like us. Gillet outlines several other possible bio chemistries but all of them seem to be hostile to getting to the advanced phase because they either preclude the existence of fire, damage metals too quickly or both.
2. In geological time Ice caps on earth have been the exception not the rule.

This last point seems to have a lot of implications for cries of global warming. Simply put the sun is getting hotter, and you would expect the earth to be getting hotter as well. Granted we are talking about geological time here.

On the whole however Since the age of the Dinasours the Earth has gotten colder and is still colder. One reason is that the atmospere has thinned somewhat. There are fossils of Dragonfiles with a wingspan of over a foot.

Such a creature could not exists in the current atmospere, it would suffocate. Likewise the flying reptiles with wingspans equivelent to a small plane would not be able to generate sufficent lift in one atmospere to get anywhere. All of the dinasours would find the present world much too cold for them.

Another little tidbit is that CO2 is nothing compared to Water vapor when it comes to global warming. All in all the case for saying that we are making things get hotter seem rather thin on the ground. And here's another question if we shift to using hydrogen fule and start spewing extra watervapor into the atmospere at the same rate as we are currently unlocking carbon what effect will that have? If the water vapor stays up there for any length of time it could cause more warming instead of less. Recently some scienists worked out that Bio fules acrually cause more polution then fossil fules when you factor all the steps in, so it is a question worth asking.

Reducing pollution is a good thing, and I wouldn't argue against it, but reallistically speaking reducing pollution won't stop climate change. Simply because the Climate changes, it always has and it always will.

Reduce polution by all means, and perhaps you can slow down the warming a fraction, but I suspect that it will still happen regardless of what we do. And the truth is climate change is going to be inconvenient for our species no matter which way it goes.

If it gets hotter then small ilands submerge and the ideal farming zones shift (and possibly shrink). If things go the other way, (and every full blown iceage has been proceeded by a sharp temperature spike). Then good chunks of continental Europe and North America could end up under glaciers again. The population affected is probably a lot greater then in the warming senario.

In either case habitats change accross the world and overly specilised animals die out in the wild.