That’s a relief.

He also noted that my core stability needs to be worked on, which I’ve already guessed, and likewise with my ankle stability, which I haven’t. Also I could do with limbering up a bit, but he wasn’t overly concerned with that. Now he’s passing me along to a naprapath who’s expert on running to give me some concrete training tips for my calf (eccentric training), and core and ankle stability.

Then the week went on, but after two beers after work on Friday I couldn’t help noticing that my calf was… not hurting at all. And when I bounced around my living room I couldn’t trigger the “normal” pain any more. Naturally, with two beers in my body, and a vicious lust to run I couldn’t help myself, which leads us to:

Friday, 5km: And by damn! First run since late February completely without pain! Whooho! I went round in the woods around the corner. Got punished badly by the verticals, but took it easy and walked bits. I can really feel now that I haven’t been able to train properly for a while. But it is a lovely spring, and when I came back it felt like a huge weight had fallen off my shoulders. I’m running again!

A big fat hint: Despite my attempt to play with my footing the last weeks to find out what the problem is, I was far from the truth. I started the Friday run with 1km barefoot, and… That was a completely different step. On both feet. When I took the shoes off, both feet stopped pronating, I landed squarely on the middle on my soles, and my big toe got involved much earlier. Damn difference it made too!

Sunday, 5km: I was hesitant about going out. I wanted to run, but I wasn’t sure if it was too aggressive. I warmed up, took a couple of meters barefoot and then was pushed over by the glorious spring weather. And it seems it worked. No pain, and I had to hold myself back like an old racehorse not to speed up. Again I started with 1km barefoot, and after that the rest of the run was exactly as I want it: smooth and light.

So here’s to hope! Taking the shoes off made a huge difference in my gait. Now. I. Must. Not. Over. Do. It. Easy does it. Calma, calma…

• Medical Daily: Skin Cancer Drug Rapidly Reverses Alzheimer’s Symptoms in Mice http://www.medicaldaily.com/news/20120210/9085/alzheimer%E2%80%99s-drug-bexarotene-mice-dementia-apolipoprotein.htm
• The Pirate Bay’s Peter Sunde: It’s Evolution, Stupid | Threat Level |http://www.wired.com/threatlevel/2012/02/peter-sunde/
• (SE) Anna Troberg: Bitschslappad av verkligheten | http://bit.ly/A3PqfI
• “We, the Web kids” by Piotr Czerski: http://pastebin.com/0xXV8k7k
• Go sit by a lake. http://xkcd.com/1024/
• Neil deGrasse Tyson. We are starstuff: http://www.youtube.com/watch?v=9D05ej8u-gU
• Natural Running, from Dr Mark. Good stuff! http://naturalrunningcenter.com/2012/03/06/video-the-principles-natural-running/
• “E-mails ‘hurt IQ more than pot’” http://cnn.com/2005/WORLD/europe/04/22/text.iq/index.html
• ANALYSIS: When a Congressman Becomes a Lobbyist, He Gets a 1,452% Raise (on Average) http://shar.es/p5HJx
• Sveriges knarkpolitik sämst, inte bäst http://www.metro.se/kolumner/sveriges-knarkpolitik-samst-inte-bast/EVHlcu!MLBbFvbH4TPKk/
• @ScottJurek remembers his friend Micah True (Born to Run’s Caballo Blanco): http://ow.ly/a3MnD
• Searching for Caballo Blanco: http://www.outsideonline.com/outdoor-adventure/running/trail-running/On-The-Trail-Of-The-White-Horse.html
• To grasp a billion stars http://shar.es/r19JP
• Badasses in the History of Science: Archimedes: http://youtu.be/UzzaSWyIhHM
• Climate Change with Bill Maher.avi: http://youtu.be/2f6Z0_HMLo8
• (SE) Skogen vi ärvde i DN http://www.dn.se/kultur-noje/sveriges-nya-miljonprogram
• Mysterious barrier blocks access to delicious human child – Boing Boing http://boingboing.net/2012/05/03/mysterious-barrier-blocks-acce.html
• Those Revolting Europeans http://www.nytimes.com/2012/05/07/opinion/krugman-those-revolting-europeans.html?smid=tw-share

Enjoy!

*sigh*

I’m now scheduled for a very expensive doctor specialized in sport injuries for a check-up tomorrow. Here’s to hope!

Tuesday, 8km: Round Årstaviken. Pace was slow but calf was bad. Possible I was hurting from the 12K two days earlier. I don’t seem to find any flow at all on flat road running.

Thursday, 6km: The usual round in Årsta Skog. Here’s a new hint: it felt like my left foot does not land exactly like my right. Right foot pronates more, which the world upside down, as it is my left foot all *real* running centers have told me need pronation support. So, a bit of compensation going on? I kept the cadence up, and concentrated on letting my left foot mimic the right. And much better immediately!

Slow Sunday, 10km: Not really slow, and no “discovery” either. I kept it round Årstaviken. After 3km the calf loosened up, and after that it felt stiff, but not hurting. Cadence and pronantion felt OK. Another helpful hint: make sure the hip stays fairly straight, for me that means actively engaging the core. It helped the balance and the cadence.

Not too bad! The calf is still stiff but now at least I’m hoping that it is something I can train away. I’ll keep plodding along a week more at the same distances and paces. Well see!

Thursday, 6km: Slow pace in Årsta Skog (the local wood). I’m starting to feel that I haven’t been able to train properly the last couple of weeks. I got fairly punished by the 45m climb between 4.5 and 5.5km. The calf held up OK. Felt stiff, but not injured.

I went back to the naprapath on Friday and he proceeded to massage the shit out the calf (“OK, so the back exercises didn’t work, so let’s work on the soft tissues shall we?”). By god, that hurt, but walking away the calf felt better than for a long time, if a bit sore.

Slow Sunday, 12km: I decided that from now on Sunday will be 1) “slow Sunday”; and 2) “discovery Sunday”. Stockholm is an amazing city with areas all around which are perfect for running, so why just stay around the house? I started by taking the car to Hellasgården which is a classic in Stockholm. Lots of trails, restaurant, sauna, outdoor gym, etc etc. The calf felt bad the first kilometers (5 min/km pace) but when I settled back into my back driver speed (5.3-6.0 min/km) it stopped hurting. The trail was OK, with the last kilometers really good, and a few hundred meters the most technical I’ve ever tried. Great fun! I ended with a long shower, a short sauna, and a seafood soup in the restaurant.

The slow pace on the Sunday might have been a clue. I did up the pace after the winter, and increased my mileage. So perhaps I’ve simply overdone it and the calf couldn’t cope. We shall see next week, in which I’ll take. It. Very. Slow.

All in all a terrible week, but with something that could be a bit of sunshine at the end of the tunnel.

Here’s some more you could do with implicit constructors. Remember this class?

class Greeter(String name = "stranger") {

    function greet() returns Void {
        echo("Hello #{$name}!");
    }
}

It turns out that the constructor argument “name” live on within the scope of the class. That’s interesting, because one of the main pains in Java is beans, and bean accessors. We’ve already seen that we can alleviate that with field access. But how about making it even simpler. Have a look at the following, mutable and completely awesome bean:

@Mutable
class Person(@Field String firstName, @Field String lastName) { }

Adding the “@Field” annotation generates automatic fields, including getters for the argument, and since he class is mutable, it also generates setters. The above would be equivalent to the following Java bean:

public class Person {

    private String firstName;
    private String lastname;

    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

The amount of crud reduced is ridiculous. There is of course the problem that if you mix “@Field” annotations with ordinary arguments and an explicit constructor it might get too messy. But hey, it’s a neat idea.

I’ve had a look at the influx of new languages for the JVM the last couple of months. In particular I’ve read up a bit on Kotlin, Fantom and Clojure. And naturally I started thinking about what I would do myself if I designed a new language.

Well… the world don’t need a new computer language. But nevertheless, here’s what I’m thinking right now.

Main Ideas

Here’s what I’d aim for primarily:

• Readability: In real software projects in real life you need to understand other peoples code. This means you have to trade-off write-ability for read-ability. It also limits you in terms of variations: there should only ever be one way of expressing any particular statement. It also means I’d probably skip type inference, but more on that later.
• Modularity: Ceylon and Fantom all have it right, modularity should be build in from the start. However, it seems to me they are missing a very obvious extension to the language level modularity, which is…
• Dependency Injection: This is a kicker, as I don’t know of any language that have it built in. Think of Guice but as a core feature of the language itself. If this could be possible to combine with the language modularity, you could a potentially awesome productivity right from the start.
• Concurrency: I’m a server kind of guy, this is important. I think Fantom is on the right track so I’d probably end up with something similar. Ie. an actor style pattern where the only allowed interaction between actors are immutable objects. In fact, I think immutability is going to be a main feature as well…
• Immutability: Immutability enables cool stuff: Clojure has this down pat. And although I’m not sure at this point, I think all classes will be immutable by default, and you’d have to declare a class if you want it mutable. People would hate it though.

Hello World

Let’s get right down to it, shall we? We’ll do the standard “hello world” a bit more complicated immediately to highlight a bit more syntax:

/*
 * class is 'public' and immutable by default, the constructor
 * signature is immediately visible and has a default value
 */
class Greeter(String name = "stranger") {

    /*
     * member is 'public' and has an automatic accessor, it
     * is also initiated with the value from the constructor
     */
    String name = $name;

    /*
     * function is 'public' by default
     */
    function greet() returns Void {
        /*
         * 'echo' is a short hand for system out, and
         * strings are evaluated
         */
        echo("Hello #{name}!");
    }
}

So what do we have here? Let’s break it down.

Constructor

The constructor signature is declared immediately after the class name. It can contain default values for arguments. The actual implementation is done either implicitly, or in a “constructor” statement:

class Greeter(String name = "stranger") {

    String name;

    constructor {
        /*
         * 'this' denotes a raw field access and is only
         * allowed in constructors and setters
         */
        this.name = $name;
    }
}

Note that this constructor is equivalent with the previous example. Does this mean that a class can only have one constructor? Yes it does, but with default values for arguments, and named argument passing it should be enough.

And by the way, the constructor arguments are accessible through the entire class. So the greeter can be simplified:

class Greeter(String name = "stranger") {

    function greet() returns Void {
        echo("Hello #{$name}!");
    }
}

Pretty cool huh? This means there’s an implicit field for each constructor argument in each class, which is readable but not writable.

Class Immutability and Field Access

I’ll leave the collection classes for now, but ordinary classes are immutable by default, and all fields have a generated “getter”, and optionally a “setter” as well.  So, to start with, this would be illegal:

Greeter greeter = new Greeter();
greeter.name = "kalle"; // illegal!

If we truly want an object that can be mutated, we’d have to declare it as such:

@Mutable
class Greeter(String name = "stranger") {

    String name = $name;

}

And now, we can change it post-construction:

Greeter greeter = new Greeter();
greeter.name = "Adam"; // legal!

Access to object fields are done via accessors that are generated automatically. If you want to change their behavior you can, but only the “setter”, the access is always reading the field as it is:

@Mutable
class Greeter(String name = "stranger") {

    String name = $name with setter {
        /*
         * 'this' denotes a raw field access and is only
         * allowed in constructors and setters, and there's an
         * implicit "argument" which is what the setter was
         * called with
         */
        this.name = name;
    }
}

But all objects have another implicit function attached to fields, namely the clone operator. With this you can get a clone of the current object with one or more fields changed. If our Greeter was imutable, we could do this:

Greeter greeter = new Greeter();
greeter = greeter.name -> "Adam";

Under the hood this created a new Greeter object which is equivalent with the first, except for the new name. It would be nice if you could chain clone operations as well, but I’ll get back to you on that.

Functions and High Order Functions

We’ve seen a function already and there’s not much to add. The declaration is in the form:

function <name>(<arguments>) returns <type> { }

To this we’ll add a few short-hands. OK, I know I said we’d only have one way of articulating statements. But hey, I think these may be worth it. Consider the following example:

function greet() returns Void {
    echo("Hello ${name}!");
}

Mr Eagle-eye will spot two possible ways of putting this simpler: Why use parenthesis when there’s no arguments, it’s pretty obviously a method declaration anyway. And why declare a “return” when it’s void any way. So…

function greet {
    echo("Hello ${name}!");
}

In addition function should be possible to pass around as any other object. These high order functions comes in two flavors “strict” and “relaxed”.

• “strict” functions only accepts immutable arguments and can only return immutable objects
• “relaxed” functions accepts mutable arguments and may return mutable objects

By default all functions are relaxed as this is a great deal easier to work with. But by declaring strict functions we’ll enable functional programming out of the box a such functions will be guaranteed not to have side effects.

Here’s a bit of syntax for you. First, let’s imagine a “foreach” declaration on an interface:

function foreach(function(T item) visitor) returns Void;

And in a list of Greeter objects you’d call it like so:

list.foreach(new function(Greeter greeter) {
    greeter.name = "Adam";
});

“Primitive” Types and Literals

Everything is objects, and no excuse. Integers and Doubles are 64 bit. Strings are UTF-16. Characters are not integers. We have Bytes. So without further ado, here’s the list of literals:

true; // boolean
123; // integer
12.3; // double
1b // byte
§0010 // bits literal
0xAB // integer in hex
'\n' // character
"n" // string
`http://www.google.com` // uri
2s // duration (2 seconds)

The duration comes in the following flavors:

1ps // picosecond
1ms // millisecond
1s // second
1m // minute
1h // hour
1d // day
1w // week
1M // month
1Y // year

In addition to the ones above, here’s some shorthand, taken straight from Fantom:

[1, 2] // list
[1:"Adam", 2:"David"] // map

Modularity

A “module” represent a unit of code which belongs to a particular namespace, and which is versioned and is packaged must like a Java “jar” file, ie. in a ZIP archive together with some meta-data. I haven’t thought through the declaration syntax yet, but here’s what we want in a declaration:

• Namespace
• Module name
• Version
• Dependencies
• DI Configuration

We’ll steal the reference syntax from Maven. So this…

net.larsan.test.lang:Core:1.1.0

… would be the namespace “net.larsan.test.lang”, the module “Core” and the version “1.1.0″.  The format of the version is probably fixed, but mayinclude a “-SNAPSHOT” postfix option.

Here’s something though: the declaration will not include build information such as “source folder” or similar. That’s mixing apples and oranges, and unfortunately both Fantom and Kotlin are doing it.

Let’s do some imaginary code:

module {
    namespace = new Namespace("net.larsan.test.lang");
    moduleName = "Core";
    version = new Version("1.1.0");
    addDependency("com.whatever:Module:2");
}

Now, the module syntax is probably just a shorthand for this:

class <name> extends Module {

    constructor {
        namespace = new Namespace("net.larsan.test.lang");
        moduleName = "Core";
        version = new Version("1.1.0");
        addDependency("com.whatever:Module:2");
    }
}

The name of the module class would be anonymous and generated at runtime.

Dependency Injection

With modularity in place, DI is just a small step away. Let’s start with a type to use:

class Transformer {

    function transform(String str) returns String {
        return str.replace('k', 'y');
    }
}

Not very useful admitedly. But hang on:

class Greeter(String name = "stranger") {

    @Inject
    Transformer transformer;

    function greet {
        echo(transformer.transform("Hello #{$name}"));
    }
}

It get’s neater if the transformer was actually an interface:

interface Transformer {
    function transform(String str) returns String;
}

No we can play with polymorphism. I’ll skip ahead a bit here, suffice to say that I’m going to steal straight from Guice, including assisted inject, but this time with closures, so if you want to to imagine how it would look, go ahead. Some thing to note:

• By default all types are injectable, given that the module knows how to 1) identify them; and 2) construct them.
• Simple identification is made with a “name” attribute on the “@Inject” annotation, and a “@Name”  annotation on types.

The great thing here is that we have the perfect place to configure our type binding. Consider the following example:

module {
 namespace = new Namespace("net.larsan.test.lang");
 moduleName = "Core";
 version = new Version("1.1.0");
 addDependency("com.whatever:Module:2");
 bind(Transformer).to(MyTransfomerImpl);
}

Add to this high order provider functions, and make the module extendible for binding overrides (which would be neat for unit testing) and you have something awesome in the works.

Concurrency

We’ll do an actor model with a twist inspired by Clojure. We’ll need two concepts:

• “Executor” – Basically your Java thread pool abstraction
• “Actor” an actor is associated with a thread pool and has a state object and an inbox for functions

An actor is an immutable object with an immutable state. However, this state can be updated by visiting functions. So, let’s imagine our Greeter from before is immutable, we could have an actor with a Greeter state:

Actor<Greeter> actor = new Actor(new Greeter());
Future<Greeter> future = actor.act(new function(Greeter state) returns Greeter {
    return state.name -> "Adam";
});

That’s All?

No obviously not, only my eyes are starting to blur. But this should have given you some ideas, if nothing else about my personal taste. The concurrency model probably needs a bit of re-thinking. Should we allow Actors on mutable objects (provided they are cloned initially)? This would make the code one hell lot easier to write and should speed up execution for complex applications. Also actors needs to be able to talk to other actors.

There’s a lot of other stuff left that I can’t be bothered to cover tonight:

• Tuples. Yes we should have free-from data structures =  immutable anonymous classes.
• Type inference, yes or no? I’m leaning towards no for readability reasons in distributed projects.
• Should unit testing be a part of the language?
• The whole class / inheritance / mixing / interface stuff.
• Immutable collections and operations on them. Think Clojure.
• Generics.
• Etc…

And now my brain is hurting.

5 AM Saint (Amber Ale, 5%, 25 IBU) Total score: 3.8
“Bottle. Dark amber with a huge, foamy head. Lovely look! Smells like grapefruit heaven mixed with malts. Sweet and bitter. Quite simply a lovely red ale with a fresh hoppy edge.”

Dogma (Spiced Ale, 7.8%) Total score: 3.5
“Bottle. Dark clear amber, with lacing off-white, smallish head. Smells of pine and wood and spices with some caramel and malt in the background. Bitter sweet, with a distinct spicy edge from the honey. Dry fairly long finish. This is different, but well executed.”

Alice Porter (Porter, 6.2%, 186 IBU) Total score: 3.8
“Bottle. Brown black with a smallish beige head. Not a lot of lacing. Coffee and milk chocolate on the nose mixed with some light hoppy tones and an underlying streak of malt. Fairly dry and sweet with some alcohol notes. Long medium bitter, dry finish. Light, but spirit-y, carbonation. A very good porter indeed.”

Chaos Theory (IPA, 7.1%) Total score: 3.3
“Bottle. Clear copper color with a medium sized head. In fact: a lovely color. Heavy malts in the nose with old hops, in particular grapefruit, but also with some caramel in the background. Fruity beer. Apricots and peaches in a rather dry bitter mix with wood and alcohol. Somewhat bitter finish. Another grape-fruit IPA? Nah, this is rather boring.”

You’ll notice the reviews gets longer down the list, but I’ll leave it up to you to figure out why. Now excuse me while I stumble to bed.

My rating: 3 of 5 stars

I have to date read all of Alistair Reynolds books (at least I think I have, he is after all rather prolific). So. I’m a fan.

I’ve always seen him as slightly uneven though, and although a brilliant story-teller, not always the perfect craftsman, and his characterization leaves at times things to which for.

(Usual self-repeat: I won’t cover the story in this review, plenty of others do).

So let’s start with the major let down: characterization. The main character (Geoffrey) starts out a whining bitch and continues so for half of the book. This is a characteristic he seems to share with his sister, unless their together at which point the sister seems to grow a bit: clearly you can’t have two characters who’s only contribution to the dialogue is “it won’t work”, “we’ll all die”, or “what makes you think I like you”. Really, that’s a fair summary of nearly 85% of all Geoffrey’s dialogue through the first half of the book.

I’m all for anti-heroes, but there’s got to be something interesting in the character you can latch onto. But for Geoffrey there is nothing. His love for the elephants? Meh…

So in order to move the story along there has to be other people than the main characters around to not only explain things but also to take initiatives at all… Let’s just say that there is a certain construct who got a lot of disposition on her plate, poor thing.

Interestingly enough, I think my other major problem with the book stems from the first: When Geoffrey “grows up” and stop whining (which is, by the way, through with a suitably transparent kill-move) the feel of the entire story changes. From an anti-hero travelogue to an ordinary space opera. It felt… A bit abrupt and… sloppy.

That’s my whining out of the way. This is still a terrific read. Everything else is exactly where I want it. Pace, scenery, grandeur and story. It all slot together in a slick machinery that you just want to continue forever.

Although this is, by Alistair Reynolds measuring, fairly near future, and contained around the solar system, the feeling of awe and grandeur that Reynolds can magic up at times is astonishing. Someone said that the hallmark of great SF is the feeling of opening-up, of a sense of wonder, and this book has it in abundance.

A 3/5 rating? Well… It really is a very strong 3. Had the transition from anti-hero to “normal” story been smoother this would have been a 4. And with the whining toned down a bit and Geoffrey fleshed out a bit earlier in the book it would have been a border-line 5.

Good stuff! I can’t wait for the next volume.

View all my reviews

My rating: 4 of 5 stars

“The man in black fled across the desert and the Gunslinger followed.”

Honestly, if that doesn’t go down as one of the great openings of all time, to be remembered long after we’re gone, even if the the person recognizing it doesn’t even know where it comes from, I’ll be sorely disappointed.

In fact, this reading is a re-read, but I hardly remembered anything but the opening line from the first read-through; which must have been back in the eighties.

I remember being somewhat nonplussed with it though, without being able to articulate exactly why at the time. Perhaps I can now: it is the overall, sweeping, “introduction-type” style to the text that I didn’t really grasp. It is in effect, one long setup of a much longer tale to come. And read in that function, it succeeds admirably: It sketches at the grandeur, the mystery and the size to come.

As usual I’ll not cover the plot, you can find that elsewhere.

It is somewhat crude; if you read later King you’ll realize that he has indeed learned a thing or two about story-telling a the craft of stringing words together since this was written. But regarded as an introductory piece it still works well.

(Here’s a minor issue though: I had no problem with the town of Tull. The Isaac-moment I had forgotten though. And I probably didn’t care about it when I was sixteen, but now this particular version of Abraham’s dilemma doesn’t sit very well. I look forward to see if it’s going to be explained or resolved later.)

So: this time around I love it. What a brilliant setup! The lone gunslinger chasing his destiny across a Sergio Leone inspired waste land entirely owned by Stephen King. Awesome!

Now on to book number two, the plan is to read it all in one go. Wish me luck!

View all my reviews