Lately I've been digging into Rust, a new programming language sponsored by Mozilla. They recently rewrote their docs and announced a roadmap to 1.0 by the end of the year, so now is a good time to take a look at it. I went through the new Language Guide last night then wrote a small ray tracer to test it out.

One of the biggest success stories of the last three decades of programming is memory safety. C and C++ may be fast but it's very easy to have dangling pointers and buffer overflows. Endless security exploits come back to this fundamental limitation of C and C++. Raw pointers == lack of memory safety.

Many modern languages provide this memory safety, but they do it at runtime with references and garbage collection. JavaScript, Java, Ruby, Python, and Perl all fall into this camp. They accomplish this safety at the cost of runtime speed. While they are typically JITed today instead interpreted, they are all slower than C/C++ because of their runtime overhead. For many tasks this is fine, but if you are building something low level or where speed really matters, then you probably go back to C/C++ and all of the problems it entails.

Rust is different. Rust is a statically typed compiled language meant to target the same tasks that you might use C or C++ for today, but it's whole purpose in life is to promote memory safety. By design, Rust code can't have dangling pointers, buffer overflows, or a whole host of other memory errors. Any code which would cause this literally can't be compiled. The language doesn't allow it. I know it sounds crazy, but it really does work.

Most importantly, Rust achieves all of these memory safety guarantees at compile time. There is no runtime overhead, making the final code as fast as C/C++, but far safer.

I won't go into how all of this work, but the short description is that Rust uses several kinds of pointers that let the compiler prove who owns memory at any given moment. If you write up a situation where the complier can't predict what will happen, it won't compile. If you can get your code to compile then you are guaranteed to be memory safe.

I plan to do all of my native coding in Rust when it hits 1.0. Rust has a robust FFI so interfacing with existing C libs is quite easy. Since I absolutely hate C++, this is a big win for me. :)

Coming into Rust I was worried the pointer constraints would make writing code difficult, much like puzzle languages. I was pleasantly surprised to find it pretty easy to code in. It's certainly more verbose than a dynamic language like JavaScript, but I was able to convert a JS ray tracer to Rust in about an hour. The resulting code roughly looks like what you'd expect from C, just with a few differences. Let's take a look.

First, the basic type definitions. I created a Vector, Sphere, Color, Ray, and Light class. Rust doesn't really have classes in the C++/Java sense, but it does have structs enhanced with method implementations, so you can think of them similar to classes.

use std::num;


struct Vector {
    x:f32,
    y:f32,
    z:f32
}

impl Vector {
    fn new(x:f32,y:f32,z:f32) -> Vector {
       Vector { x:x, y:y, z:z }
    }
    fn scale(&self, s:f32)    -> Vector  { 
       Vector { x:self.x*s, y:self.y*s, z:self.z*s }
    }
    fn plus(&self, b:Vector)  -> Vector  { 
      Vector::new(self.x+b.x, self.y+b.y, self.z+b.z)
    }
    fn minus(&self, b:Vector) -> Vector  {
       Vector::new(self.x-b.x, self.y-b.y, self.z-b.z) 
    }
    fn dot(&self, b:Vector)   -> f32     { 
      self.x*b.x + self.y*b.y + self.z*b.z 
    }
    fn magnitude(&self)       -> f32     { 
      (self.dot(*self)).sqrt() 
    }
    fn normalize(&self)       -> Vector  { 
      self.scale(1.0/self.magnitude())  
    }
}

struct Ray {
    orig:Vector,
    dir:Vector,
}

struct Color {
    r:f32,
    g:f32,
    b:f32,
}

impl Color {
    fn scale (&self, s:f32) -> Color {
        Color { r: self.r*s, g:self.g*s, b:self.b*s }
    }
    fn plus (&self, b:Color) -> Color {
        Color { r: self.r + b.r, g: self.g + b.g, b: self.b + b.b }
    }
}

struct Sphere {
    center:Vector,
    radius:f32,
    color: Color,
}

impl Sphere {
    fn get_normal(&self, pt:Vector) -> Vector {
        return pt.minus(self.center).normalize();
    }
}

struct Light {
    position: Vector,
    color: Color,
}

Without knowing the language you can still figure out what's going on. Types are specified after the field names, with f32 and i32 meaning integer and floating point values. There's also a slew of finer grained number types for when you need tight memory control.

Next up I created a few constants.

static WHITE:Color  = Color { r:1.0, g:1.0, b:1.0};
static RED:Color    = Color { r:1.0, g:0.0, b:0.0};
static GREEN:Color  = Color { r:0.0, g:1.0, b:0.0};
static BLUE:Color   = Color { r:0.0, g:0.0, b:1.0};

static LIGHT1:Light = Light {
    position: Vector { x: 0.7, y: -1.0, z: 1.7} ,
    color: WHITE
};

Now in my main function I'll set up the scene and create a lookup table of one letter strings for text mode rendering.

fn main() {
    println!("Hello, worlds!");
    let lut = vec!(".","-","+","*","X","M");

    let w = 20*4i;
    let h = 10*4i;

    let scene = vec!(
        Sphere{ center: Vector::new(-1.0, 0.0, 3.0), radius: 0.3, color: RED },
        Sphere{ center: Vector::new( 0.0, 0.0, 3.0), radius: 0.8, color: GREEN },
        Sphere{ center: Vector::new( 1.0, 0.0, 3.0), radius: 0.3, color: BLUE }
        );

Now lets get to the core ray tracing loop. This looks at every pixel to see if it's ray intersects with the spheres in the scene. It should be mostly understandable, but you'll start to see the differences with C.

    for j in range(0,h) {
        println!("--");
        for i in range(0,w) {
            //let tMax = 10000f32;
            let fw:f32 = w as f32;
            let fi:f32 = i as f32;
            let fj:f32 = j as f32;
            let fh:f32 = h as f32;

            let ray = Ray {
                orig: Vector::new(0.0,0.0,0.0),
                dir:  Vector::new((fi-fw/2.0)/fw, (fj-fh/2.0)/fh,1.0).normalize(),
            };

            let mut objHitObj:Option<(Sphere,f32)> = None;

            for obj in scene.iter() {
                let ret = intersect_sphere(ray, obj.center, obj.radius);
                if ret.hit {
                    objHitObj = Some((*obj,ret.tval));
                }
            }

The for loops are done with a range function which returns an iterator. Iterators are used extensively in Rust because they are inherently safer than direct indexing.

Notice the objHitObj variable. It is set based on the result of the intersection test. In JavaScript I used several variables to track if an object had been hit, and to hold the hit object and hit distance if it did intersect. In Rust you are encouraged to use options. An Option is a special enum with two possible values: None and Some. If it is None then there is nothing inside the option. If it is Some then you can safely grab the contained object. Options are a safer alternative to null pointer checks.

Options can hold any object thanks to Rust's generics. In the code above I tried out something tricky and surprisingly it worked. Since I need to store several values I created an option holding a tuple, which is like a fixed size array with fixed types. objHitObj is defined as an option holding a tuple of a Sphere and an f32 value. When I check if ret.hit is true I set the option to Some((obj,ret.tval)), meaning the contents of my object pointer and the hit distance.

Now lets look at the second part of the loop, once ray intersection is done.

            let pixel = match objHitObj {
                Some((obj,tval)) => lut[shade_pixel(ray,obj,tval)],
                None             => " "
            };

            print!("{}",pixel);
        }
    }

Finally I can check and retrieve the option values using an if statement or a match. Match is like a switch/case statement in C, but with super powers. It forces you to account for all possible code paths. This ensures there are no mistakes during compilation. In the code above I match the some and none cases. In the Some case it pulls out the nested objects and gives them the names obj and tval, just like the tuple I stuffed into it earlier. This is called destructuring in Rust. If there is a value then it calls shadepixel and returns character in the look up table representing that grayscale value. If the None case happens then it returns a space. In either case we know the pixel variable will have a valid value after the match. It's impossible for pixel to be null, so I can safely print it.

The rest of my code is basically vector math. It looks almost identical to the same code in JavaScript, just strongly typed.

fn shade_pixel(ray:Ray, obj:Sphere, tval:f32) -> uint {
    let pi = ray.orig.plus(ray.dir.scale(tval));
    let color = diffuse_shading(pi, obj, LIGHT1);
    let col = (color.r + color.g + color.b) / 3.0;
    (col * 6.0) as uint
}

struct HitPoint {
    hit:bool,
    tval:f32,
}

fn intersect_sphere(ray:Ray, center:Vector, radius:f32) -> HitPoint {
    let l = center.minus(ray.orig);
    let tca = l.dot(ray.dir);
    if tca < 0.0 {
        return HitPoint { hit:false, tval:-1.0 };
    }
    let d2 = l.dot(l) - tca*tca;
    let r2 = radius*radius;
    if d2 > r2 {
        return HitPoint { hit: false, tval:-1.0 };
    }
    let thc = (r2-d2).sqrt();
    let t0 = tca-thc;
    //let t1 = tca+thc;
    if t0 > 10000.0 {
        return HitPoint { hit: false, tval: -1.0 };
    }
    return HitPoint { hit: true, tval: t0}

}

fn clamp(x:f32,a:f32,b:f32) -> f32{
    if x < a { return a;  }
    if x > b { return b; }
    return x;
}

fn diffuse_shading(pi:Vector, obj:Sphere, light:Light) -> Color{
    let n = obj.get_normal(pi);
    let lam1 = light.position.minus(pi).normalize().dot(n);
    let lam2 = clamp(lam1,0.0,1.0);
    light.color.scale(lam2*0.5).plus(obj.color.scale(0.3))
}

That's it. Here's the final result.

text

So far I'm really happy with Rust. It has some rough edges they are still working on, but I love the direction they are going. It really could be a replacement for C/C++ in lots of cases.

Buy or no buy? Buy! It's free!

The Art of LEGO Design: Creative Ways to Build Amazing Models

by Jordan Schwartz

No Starch Press is really doubling down on their Lego books. Their latest is a stunner. The Art of Lego Design by Jordan Schwartz is less of an art book and more of a hands on guide. It shows actual techniques used by the Lego artists featured in other No Starch books like Mike Doyle’s Beautiful Lego.

As one of the LEGO Group’s youngest staff designers; Jordan Schwartz worked on a number of official LEGO sets. His attention to detail and gift for teaching really come through in the book. Many of the models that seem impossible at first, such as stained glass windows, are actually pretty simple once explained in the book.

The Art of Lego Design is the perfect entry point to rabbit hole that is Lego sculpture. With Lego specific jargon like cheese slopes, SNOT (Studs Not On Top), and the Lowell sphere; it would be easy to get lost; but Jordan explains it all clearly, along with general design principles like texture and composition.

The book takes the reader through many styles of construction and technical advantages of different pieces, with as dash of Lego history thrown in. I didn’t know there once was a Lego set with a fuzzy bear rug or a line of big Lego people for the Technic sets.

Read or Read Not? Read!

Get it from No Starch Press

TinkerCad is a free web based CAD program. It runs entirely in the browser using WebGL, so you’ll probably want to use it with Chrome (I think Safari may work in Yosemite+). TinkerCad is meant for novice CAD users. So novice that you can know absolutely nothing about CAD and be able to make something after five minutes of their built in learning quests (tutorials). Then you an save your creation to their cloud or download it for 3D printing.

TinkerCad isn’t full featured. You can’t add chamfered edges for example, but you can combine shapes with CSG operations, stretch and rotate them, and add useful prefab shapes like letters and stars. There is even a scripting language for building programmatic objects. The UI challenge of building a CAD for newbies is daunting, yet somehow they did it. TinkerCad almost went out of business since it turns out novice users are also unlikely to pay for CAD applications. Fortunately AutoDesk bought them and have made TinkerCad their free entry level offering.

But this is a book review, right? 3D Modeling and Printing with TinkerCad is a new book by James Floyd Kelly. it walks you through the basics of navigation, creating shapes, merging and subtracting them, all the way to printing models and importing them into Minecraft. The book is very well written and easy to follow with lots of pictures.

So should you buy it? That depends. TinkerCad’s own interactive tutorials are quite good. While I enjoyed the book I’d say 75% of it covers the same things you’ll learn in the tutorials. It really comes down to whether you are more comfortable learning on screen or by reading a paper book. If you learn by paper, then buy it.

3D Modeling and Printing with Tinkercad: Create and Print Your Own 3D Models, James Floyd Kelly

Michio Kaku, the science popularizer and theoretical physicist, is always a wonderful speaker. I’ve greatly enjoyed his TED talks. In Physics of the Impossible he takes on the many improbable technologies of science fiction to determine if they are in fact impossible. Surprisingly, few truly are. He divides technologies into three levels of impossible: likely today or in the next 20 years with existing science (ex: replicators), likely in the next hundred or so without violating any known laws of physics (shockingly, time travel is in this bunch), and the truly impossible without some new laws of physics. There are very few things in the last category. It’s an easy read and lots of fun.

Should you read it? Yes!

Physics of the Impossible: A Scientific Exploration into the World of Phasers, Force Fields, Teleportation, and Time Travel, by Michio Kaku

Dr. Kaku on the Daily Show

No Starch Press is on a roll with its series of Lego themed books. While most of them are about model ideas or construction techniques, Beautiful Lego is different. This is a Lego art book. In classic coffee table style it is filled with gorgeous photos to thrill the reader. Beautiful Lego does not seek to discuss 'can Lego be art', but takes it as fact. These are works by artists, just artists using the medium of Lego instead of paint or clay, and the results speak for themselves. Stunning.

Beautiful Lego is written and photographed by Mike Doyle, a lego artist himself as well as an excellent graphic designer, but features the work of over 70 different artists. The book is organized by topic -- spaceships, people, architecture, robots -- with interviews of artists interspersed. Each artist is asked the single question: "Why Lego?"; with an immense variety of answers. There is a common theme, though: the desire to create using an incredibly malleable medium.

Some models are beautiful and some are terrifying, such as "The Doll" (pg 5) and "Disscected Frog" (pg 79). The architectural models really shine; good use of the few curvy pieces in Lego can make amazing results. There is even political art: The Power of Freedom (page 124).

Beautiful Lego surprised me by the diversity of styles within the medium of Lego. Some are hyper detailed, some expressive, some minimalist. Angus MacLane has a cute style known in the book as CubeDudes, which are head on caricatures of famous figures like President Lincoln, Kirk and Spock, and the Stay Puft Marshmellow Man. (page 36)

You will appreciate the book on two levels. First, the beauty or expression of the piece, then a second time as you pour over the photos trying to figure out "How did they do that with Lego?" Mike Doyle's victorian house series in particular will amaze you with the flexibility of Lego. (And make you wonder how big his Lego collection is:) While re-reading the book for this review, I'm struck by how much good photography makes a difference when experiencing a model.

I heartily recommend Beautiful Lego to the adult Lego fan in your life. It just might make you pull out the bin from the garage and build a few orignal models yourself. And yes, there is a Freddy Mercury model called Fried Chicken.

Beautiful Lego can be purchased from No Starch Press, Amazon, or Barnes and Nobel.

The idea of computer vision has always fascinated me. The ability to get from a plain image to an understanding of it's contents seems magical. Though I understand a bit of the underlying math, to build my own computer vision system would take years of study. Fortunately, this book and an open source library come to the rescue.

Practical Computer Vision with SimpleCV, published by O'Reilly, is a wonderful book; with an emphasis on Practical. It explains a bit about how computer vision works then dives right in to building things using the open source computer vision library: SimpleCV. SimpleCV is a Python library (linking to an underlying C implementation, I think), and quite easy to use. Since the book examples are all in Python anyone with basic programming experience (Java, C#, JavaScript, Ruby) should have no trouble with the example code.

The first half of the book starts with an explanation of basic computer vision concepts then jumps right into build a simple time lapse photography app with a few lines of Python code. Next comes image manipulations such as cropping, color reduction, simple object detection, and histograms. This is enough to create a blue screen effect and parking detector.

The second half contains the real meat of the book: detecting features. SimpleCV can pick out different shapes, filter by colors, look for faces, and even scan barcodes. One of the examples looks at a table of change to calculate the monetary value using coin size. The final chapter covers some advanced techniques like optical flow and key point matching.

While I like the book overall I do have a few nits. First, I really wish it was printed in color. Several chapters have images which can't be easily distinguished when printed in black and white. Second, I wish it was longer. While the book does covert almost every feature of SimpleCV, I'd love to read some larger example apps that combine multiple techniques. All that said, the book was still a good read and informative. It will stay on my shelf for future imaging projects.

Most book publishers don't really have a 'brand'. You buy a book because of the title or the author. No one cares who Stephen King's publisher is. However, every now and then a publisher comes along who simply makes cool books. A publisher who's books I will buy regardless of the title or author. No Starch Press is one such publisher.

No Starch has consistently published fascinating books on a wide array of topics. Their slogan is the finest in geek entertainment and they mean it. Currently my shelf includes an illustrated Periodic Table of Elements, Python for Kids, and the Super Scratch Programming Adventure. I'll be writing these up soon, but in the mean time I want to talk about a trilogy of cool books No Starch just sent me. They cover a topic near an dear to many an engineer and hacker: Legos.

Lego Technic Builders Guide

The first title is The Unofficial LEGO Technic Builder's Guide by Pawel "sariel" Kmiec (link). I've read Lego books before, but this is no ordinary title. Devoted exclusively to LEGO's Technic line of models for older children/adults, it dives deeper than I knew Legos could go. While I played with the Technic line as a child, I had no idea the wider Lego enthusiast community had taken their designs so far.

If you've never played with Technic sets, you should really take a look. They are designed around real-world models with functioning gears, motors, and mechanical assemblies. Think of a sports car with rack and pinion steering and a proper differential drive train, or a pneumatically controlled steam shovel. These sets are also the basis of Lego's robotics sets, as they allow you to build almost arbitrarily complex systems entirely from little Lego bricks.

At first glance you might think Pawel's book is just a set of models to build, but it's actually the opposite. He specifically doesn't give you models to build. Instead he focuses on the how, not the what. He explains how a differential drive train actually works, then gives you the instructions to build just that component. Then he shows how to improve it with more robust parts and smoother gears. His goal is to teach you *how* the mechanical systems , giving you the knowledge to integrate the components into your own larger models.

Toy parts, real engineering

As I read through the first few chapters I realized I was not only learning about advanced Lego techniques, but also an introduction to real mechanical engineering. In Chapter 5 he covers the many types of gears, what they are used for, and the unique advantages of each. Chapter 6 covers chains and pulleys, where he explains many of the common pulley combinations used in real mechanical systems. The illustrations are impressively clear and concise. Chapter 7 covers levers and linkages. Even if you've never heard of a Chebyshev linkage or Pantograph, you'll know how they work by the end of the chapter.

My favorite section is probably Chapter 8: Custom Mechanical Solutions. Pawel shows how to improve on the standard LEGO gearing systems with new designs that have unique advantages in strength, locking, and features. The Schmidt coupling is especially intriguing. Later chapters cover advanced mechanics like suspension systems, transmissions, tracked vehicles and the modeling process. The book is impressively comprehensive.

The book covers both old and newer Technic sets, explaining how individual components like the pneumatic system have evolved over the years. (I'm especially fond of the pneumatic claw system I had when I was twelve).

I heartily recommend this book to any adult. Be aware that this really is for older children, probably 12 and up. I imagine an 8 year old would be bored to tears reading it. For younger Lego enthusiasts I suggest one of No Starch's other Lego books (which I will covers soon).

So. Verdict: buy or no buy? Buy! Buy Now!

Though normally 29.95$ you can get it by Christmas for only 19$ if you order with Amazon Prime.

Disclaimer: I did not pay for many of the books I review here. One of the perks of being an O'Reilly author is easy access to free copies of almost everything O'Reilly publishes. However, all of these reviews are freely done of my own initiative. I choose the books I review and I receive no compensation other than the free copy. These are my own opinions and do not reflect the opinions of O'Reilly or my employer Nokia.

The Arduino Cookbook, by Michael Margolis

When you first begin hacking with Arduino, as I recently have, you will most likely spend the first few weeks scouring the Internet for information. The Arduino system is so cheap, powerful, and flexible that you will immediately think of a million things to do with it. This can be a problem. Not only do many of us lack the time to build every project we've dreamt up, but using just the web for information is problematic. The docs on Arduino.cc are great for introductory topics but I quickly found my self at its limits. As a software guy I need to know not only about Arduino itself, but sensors, components, 3rd party libraries, and power systems. In short, I need a complete electronics background to fully use my Arduino board. That's where the Arduino Cookbook comes in.

The second edition of Arduino Cookbook, by Michael Margolis, was recently published by O'Reilly. In my opinion this is the best one stop shopping source for Arduino information. It is not a pure introductory tome, though the first chapters do give you a quick review of Arduino to keep you up to date. The bulk of the book is organized around functional topics; things you would actually want to *do* with your Arduino.

The first few chapters cover the Arduino language, math, serial IO, and basic switches. Though it was not hard for me to pick up the Arduino language (essentially a simplified C++), these chapters covered a lot of finer details I had missed when reading the online docs. Each chapter is structured as a series of how-tos such as "Shifting Bits" and "Using a Switch Without External Resistors".

Later chapters cover specific topics like Getting Input from Sensors, Physical Output, Audio Output, and Wireless Communication. I really like that each how-to section not only shows you how to complete the task at hand but also gives you background into what is really going on. This is especially useful when you reach advanced topics like driving motors. The book gives a background of different kinds of motors, how they work, and how they are controlled before diving into specific tasks. This structure gives you a great electronics primer as you learn the ins and outs of Arduino.

If you buy only one book on Arduino, make it this one. It gives you everything you need to get the most out of your hacking endeavors.


on Amazon, paper and Kindle

or

direct from O'Reilly as paper, ebook, or no-DRM PDF

As regular readers know I have recently jumped into Arduino and hardware hacking full-time. One of the things which fascinates me is the idea of monitoring our environment. I mean not only the global environment but also our own local spaces. Sensors and computation are incredibly cheap. Network access is almost ubiquitous. This means we can easily monitor our world and learn interesting things by analyzing simple data points over time.

Being an engineer I started by picking out some books to read. First up is an amazingly thin but info-packed tome from Maker Press: Environmental Monitoring with Arduino: Building Simple Devices to Collect Data About the World Around Us by Emily Gertz and Patrick Di Justo. As the name would suggest, it is exactly the book I was looking for.

Before I continue I must warn you, reading this book will make you spend a lot of money. You will find yourself spending hours checking out cool sensors and outputs on websites like Adafruit, SparkFun, and Emartee. Tracking your environment with simple sensors is simply too intriguing. I apologize in advance for the new habit you will form.

Though short (81 pages by my count), Environmental Monitoring with Arduino contains a lot of information. It starts with a chapter called "The World's Shortest Electronics Primer" introducing Arduino, basic electronics, and then runs through an LED blinking tutorial. From here you jump straight into your first sensing application: a noise monitor with an LED bar graph.

The book is organized in mostly alternating chapters. Each chapter either introduces a new piece of hardware or a project using that hardware. The chapters cover how to measure electromagnetic interference, water purity, humidity / temperature / dew point, and finally atomic radiation as used by individuals in the wake of the Fukushima disaster.

The components required to build most of the projects in the book are surprisingly cheap. For example, Emartee's mini sound sensor, a tiny board containing a microphone and the support circuitry, is only seven dollars.

The only really pricey component is the Geiger counter from Goldmine that costs $137. Of course it uses a special beta and gamma ray sensitive mueller tube from Russia so it's actually fairly cheap. Most components are under $10.

While I love the book there are a few things that could be improved. Each chapter contains a few paragraphs explaining what we are measuring and how it works (water conductivity was especially interesting), but I'd like to learn more about the science behind each effect. This probably isn't possible in a book of this size, so links to external websites would be greatly appreciated.

I'd also like an appendix with links to learn more about Arduino and environmental sensing, as well as a list of sites to buy cheap components that are easy to work with.

Finally, there is no information on the authors. Most books include a short bio or an introduction by the authors to explain who they are and why you should listen to them. This book contains no biographical information at all beyond the authors' names.

Go - No Go?

A definite go.

If you are new to environmental monitoring this book is a great place to start, even if you know nothing about electronics and Arduino. And for the price ($7.99 for the print copy and half that for ebook) it's a steal. You can get it on:

World of Ptavvs, Larry Niven, 188pp, 1966

If you are a scifi reader but don't know Larry Niven then you aren't reading this blog because you don't exist. However, in the off chance that you slipped in from an alternate dimension where Larry Niven never took up writing, then allow me to explain. Larry Niven is known for hard-SF writing, mainly in the 70s and 80s, though he is still writing today. Unlike contemporary SF that moved on to cyberpunk, steampunk, and singularity visions, Niven still writes about humans exploring the cosmos. He is also quite a stickler for scientific accuracy, to the extent he has created an entire universe called "Known Space" with a history extending from the early 21st century to the 32nd.

Larry Niven is probably best known for the Ring World series, about adventures on a giant ring the diameter of earth's orbit circling an alien star. The book I just finished, World of Ptavvs, is set in the same universe but much earlier. It also happens to be his first full novel, expanded from several short stories. Given that he was still early in his craft, I was impressed that it was so interesting. Clearly he got better, but even this early work is quite entertaining.

World of Ptavvs is a short novel (almost novella) about humanity's first-ish contact with an alien species, under the most strange and amusing circumstances. Kaznol, a greedy alien with power of mind control, is accidentally stuck in a stasis field which freezes him in time. Two billion years ago he crashes on an empty planet that eventually becomes the earth of today. In the mid 21st century humans find the frozen alien at the bottom of the ocean and attempt mental contact using a man with slight telepathic abilities (he practices on dolphins who are by this time known to be intelligent). Due to lack of planning on humanity's part, they accidentally free the alien and in the process the alien imprints his memories on the telepath. So now we have *two* rampaging aliens from billions of years ago bent on conquering the earth.

I know, it's sounds super cheesy but it's actually a very entertaining story with some cool twists. Throw in a team from the ARM (CIA of the future), some angry asteroid miners, and a few stolen spaceships and you get a rockin' adventure. Best of all it's *short*. Less than 200 pages. In an age when many authors feel the need to produce thousand page tomes it's nice to read a book that is no longer than it needs to be.

So, should you read it? Yes!

 

I've always meant to go back and read some of the really old scifi that people have always talked about but I've never read.  Now is finally that time. As a fan of mainly 50s through 70s (Asimov, Clarke, Heinlein, Niven), I've rarely read anything earlier than the late forties. (Jules Verne being a notable exception.)  My goal is not so much to read the novels for pure enjoyment, but to determine if they really are worth of their place in history?  Were they really that good? Did scifi get better? Has it gotten worse again?   In that spirt, lets the the time machine to 1917.

A Princess of Mars

Edgar Rice Burroughs, 1917, 326 pp

I've read a few of the Tarzan novels by and never felt drawn into them.  With the upcoming film adaption, John Carter, I thought it was time to finally get into the series.

A Princess of Mars is the story of Civil War vet John Carter searching for gold out west in the 1870s. He is mysteriously transported to Mars and quickly captured by a race of tall multi-armed green martians.  Thanks to his fighting skills, resourcefulness, and a body accustomed to the heavier Earth gravity; he quickly learns the language of his jailers then escapes with the captive princess Dejah Thoris of the red martians (who conveniently look like really attractive humans).  Throughout the book he goes on various adventures across the planet, gaining fame and glory among the martians all while learning the secrets of their planet.

The Martians call their planet Barsoom, so you will often hear the novels known as the Barsoom series.  Burroughs wrote 10 more in the series over the next thirty years though I get the impression they get progressively derivative as time goes on.

Princess of Mars was his first novel but it's much better than I expected. The science is horrible by today's standards because it was written in a time when we believed Mars had canals, water, and possibly intelligent life, but for the time it was pretty visionary.  He reasonably explains the different societies, lighter than air travel, light based power sources, and the thin but sustaining martian atmosphere. Pretty good for the time it was written.

Make no mistake: this is a swashbuckler.  People of the teens and twenties liked their buckles fully swashed, and swashed they shall be. The Princess of Mars has exotic women in skimpy outfits, green bug-eyed villains, oodles of chase scenes, and sword fights by the score. It's quite fun to read and imagine it played in a theater between The Lone Range and Flash Gordon. Being public domain and free on the Kindle doesn't hurt either.

Conclusion

So, is it worth reading?  I say yes. It's a fun and fast read as well as a piece of sci-fi history. You will find references to Barsoom in many later works throughout the 20th century. It also inspired a generation of authors and scientists from Clarke to Sagan.

Wikipedia entry

Amazon Kindle page

John Carter movie website

 

I'm home all by myself this weekend (the missus took the baby to CA to visit family for a few days) so I am at long last catching up on some reading. Today's book is Hackers & Painters: Big Ideas from the Computer Age by Paul Graham. It is a selection of Paul Graham's essays collected into a single volume, most notably Hackers & Painters. Paul Graham is the co-founder of Viaweb, an early software as a service provider that was later sold to Yahoo in 1998. He then co-founded the Y-combinator startup incubator. He blogs and speaks regularly on topics of startups, hacking, and creative collaboration. Though the book was first published in 2004 it has aged pretty well because Paul mostly focuses on timeless topics: Why are hackers the way they are?. Startups are a great way to create wealth. Musings on programming languages. His chapter on web based software: The Other Road Ahead is not only still relevant, but more relevant than ever before. Software as a Service is now the order of the day. While he missed the concept of shipping software as a packaged mobile app instead of just websites, he got the core concepts of always available, always updated software right on. Over all I like the book. The musings about what makes a good programming language towards the end are especially good, though you may come to the conclusion that all languages eventually grow to become inferior dialects of Lisp. My biggest beef isn't so much with the book but with Paul Graham's tone. Sometimes he steps beyond merely authoritative to become overbearing and down right arrogant. Especially in the name sake chapter on Hackers and Painters one gets the impression that Paul can be quite a know-it-all dick when he wants to be. He puts his kind of person, the hacker, on a pedestal: equating the best hackers with the great painters of the Renaissance. Uber-men who are experts in many fields and outperform the work of 30 mediocre employees. This attitude of superiority pervades the book and can become a turn off for the reader. But the thing is: throughout the book he's completely right. In virtually every essay he digs into the topic and divines the underlying truth, even when we might not which to acknowledge it. He even has a chapter on that topic: What You Can't Say. I suspect his peculiar narrative tone simply reflects how Paul is in real life. I have to respect people who write how they speak. I always strive for honesty in my writing as well. Would I ever want to work with Mr Graham in his startup incubator? I don't know. I haven't met him. He may be a right jolly fellow in person. In any case, I enjoyed reading the book and will read his further essays on his blog, just always knowing to adjust the tone to my personal liking. I have only two real complaints with Hackers & Painters. First, the chapter on catching spam seems very out of place with the rest of the book. Not that I didn't like it, just it was more technical rather than discussing more universal topics. Second, he has several chapters which discuss the programming language of the future, or one that might last 100 years. He dives into the problems that must be solved but never proposes any real solutions. I'm not asking for a full BNF but a few examples of what such a dynamic concise super-language would look like might be handy. But then. I suspect it would just be full of parenthesis. One final item: read the notes section at the end. More than just the footnotes for the book, the provide more entertaining tidbits to ponder and entice further trips to Wikipedia.