Hey you!

Postcards are cool! Go send some ->

postme.me

Programmers are born not made

Jan 05 2012

Programmers are a special breed, good programmers especially – our craft is more an art than we like to admit when trying to wrestle it into a Hard Engineering Discipline ™. It’s actually more like mathematics, music or the wizardry Kaylee does in Firefly.

Passion (novel)

Image via Wikipedia

Good programmers have a special feel, a talent that is difficult to explain and even harder to attain.

A few weeks ago @zidarsk8 came rushing to me “Dude! There’s this guy! I’ve been teaching him coding! He’s already better than me! Hasn’t even heard of a variable before a month ago! It’s so frikkin’ awesome!”

He made me promise to blog about it. Why is it some people just get it? What’s so special about them? Can anybody be taught to program or does it really take a special breed to become even a competent programmer, let alone a good one?

I remember tutoring a high school kid about a year ago. About to fail his programming class (CE high school, we have those), he came running to me. In a month I was to teach him everything I know, or at least enough to pass the class.

Come end of the month and he knew everything about loops, variable assignment, even understood that functions are packets of code that can do stuff. My parting words to his father were “Yeah, he knows everything. Just needs a bit of practice to get it.”

I doubt he ever passed the class. Or if he did it was the teacher’s mercy … and that teacher isn’t very merciful from what I remember of her in my high school times.

But this isn’t just because I’m a bad teacher – others came to me after that one kid on his recommendation and I got a “Thank you! I bloody passed! yay!” email from all of them – there are people who simply aren’t programmers. Never will be programmers. Not even mediocre ones.

The non-programming sheep

Jeff Atwood wrote about Separating Programming Sheep from Non-Programming Goatsin 2006 where he mentions a study that claims to have found a test to predict future programming ability.

The test is really simple:

a = 5
b = 20
a = b

What are a and be now?

And some more questions like that. Only 44% of the students formed a consistent mental model of assignment – even a wrong one. The rest failed or didn’t answer the questions.

Worse still, after a semester of learning to program, the numbers were the same. Only 44% of the students understood how assignment works.

Some people just dont get it. Apparently.

But I think there’s an even simpler test ->

Passion.

Sheep

Image via Wikipedia

Sometimes when you give an impressionable young mind (anybody deciding to learn to code, age is irrelevant) two tools and a problem, they will use the two tools to create four more tools. Then they will get on the internets and find some more tools … soon they have twenty tools and what was the problem you wanted me to solve again?

That’s passion!

Pure unadulterated passion for programming. When you can be fascinated, even excited, about this stuff without a need to solve a problem. Hell, even if you are solving a problem that you know is a meaningless exercise … that’s where greatness lies.

It doesn’t matter what age you started coding at – many studies have shown experience is not a predictor of quality in our world – what matters is that you have a passion for this stuff.

Because if you’ve got the passion, then you probably have everything else you need as well.

Enhanced by Zemanta

14 responses so far

Deca – a cool systems programming language

Jan 04 2012

DeCA partners with military to help promote su...

Image by Morning Calm News via Flickr

This post is a summary of  Eli Gottlieb’s thesis on the Deca programming language from May 2011. In short Deca is a language designed to provide the advanced features of sophisticated, high-level programming languageswhile still programming as close as possible to the bare metal. It brings in the functional, object-oriented and generic programming paradigms without requiring a garbage collector or a threading system.

Since it is a programming-language thesis, it is also dedicated to every programmer who ever wanted a better language but could not use a virtual machine or a run-time library. To them I dedicate this thesis and say: I am become type theory, destroyer of minds.

Problems of systems programming

I once contemplated doing some Linux kernel hacking, but decided to lie down until the feeling passes. That is my closest brush with systems programming and after reading this thesis – yikes.

Essentially the problems are what you’d expect when dealing with hardware-imposed limitations, lacking useful abstractions and safety features – in fact, you’re usually the one creating these.

  1. precise data representation - working so close to bare metal means datatypes must correspond directly to their hardware representations. You can’t just have a magical List datatype, you can have a block of memory though
  2. safety properties and confined unsafety - the most common form of safety is
    English: Kernel panic Magyar: "Kernel pan...

    Panic

    type safety, the idea being that the compiler makes sure you aren’t trying to multiply a sack of potates with a banana. But other safety features a good language should provide according to Gottlieb are escape analysis for pointers, region-based memory management and preservation and progress (well-typedness)

  3. abstraction, encapsulation, modularity - most modern languages provide ways of packaging code so it can be reused and encapsulated. For instance: when you are using a stack structure, you don’t really care whether it’s implemented as a list or a memory vector.
  4. extensibility - a way to extend the language itself with new features (for example, making the + operator work with new data types). So far possible solutions for this exist as OOP, ad-hoc polymorphism, macros and so on, but it remains an open question and the perfect solution might not even exist
  5. Stroustroup’s rule - the lead designer of C++ Bjarne Stroustrup once presented a rule that What you don’t use, you don’t pay for. But in many high-level languages automatic memory management runs whether you need it or not, or every function needs exception handling … all big problems in the limited confines of bare metal programming.

Deca’s solutions

English: Safety

Image via Wikipedia

  1. unboxed data types - for those of us who didn’t know, boxed types are represented by a point to an object; in Deca all types are compiled down to raw unboxed representations – just a value – so when the code is running there’s no more overhead. There are also two kinds of pointers (scoped and referenced) that allow you to use a pointer as if it was a variable, which sounds pretty cool from my experience with explicit pointers.
  2. type safety - admittedly, this section went a bit over my head, but Deca uses a magical combination of static type inference (static typing where the compiler guesses stuff for you) and bit-casting – this is a system that allows you to eschew type safety under certain conditions because systems programmers apparently need that. If you care for this sort of thing -> Deca uses a modified Hindley-Milner inference algorithm that also allows subtyping
  3. module system - just as you’d expect of any modern language, you can package things into modules and modules into modules
  4. encapsulated existential types - these are best known as the type-theoretic encoding of abstract data types – giving us the ability to use data structures without knowing all the internal logic. In Deca these exist as a language extension and the whole thing works out just like it did for Caml
  5. extensible types - Deca provides two ways of extending data types. The internal way of “open-sum variant types”, which I don’t understand and the thesis isn’t very specific as to what thi means. The other are good old friendly classes, which we all understand and love from object-oriented languages
  6. symmetric multiple dispatch - dynamic dispatch is a way to dynamically decide which method to call in order to process a particular message (polymorphism, pattern matching etc.) Deca does this by having a partially ordered list of possible methods, walking through it and when it finds something that can execute the given arguments, it is the most specific binding.
  7. low-level encodings of high-level features - this section of the thesis is a bit longer, but it essentially boils down to the idea of using the LLVM to run compiled code and making sure all the features explained above are compiled to their most basic incarnations. According to another section of the thesis this also ensures adherence to Stroustrup’s rule

An example

I would love to personally produce an example of what Deca looks like, but I’m already having enough fun learning Haskell, so here’s an official example of a List implementation.

 
module list
 
import malloc
 
type List<a> = class(e,n) extends Sequence<a> {
  element: a:= e;
  next: @List:= n;
}
 
function cons(element,next) {
  malloc.malloc(pool => new(pool)(List(element,next)))
}
 
function car(lst: @List) {
  match *lst {
    case Cons(head,tail) => Some(head)
    case Nil => None
  }
}
 
function cdr(lst: @List) {
  match *lst {
    case Cons(head,tail) => tail
    case Nil => Nil
  }
}
 
end

Conclusion

The thesis itself also compares Deca to other modern high-level languages for systems programming like Clay, BitC, Cyclone and Java “with magic”. That section didn’t feel too important, the resolution is simply that Deca is better.

Unfortunately though, Deca itself doesn’t look to be ready for real-world use just yet. Even though the language itself is pretty much defined and its grammar is known, no complete compiler yet exists. The official compiler, decac, developed by Gottlieb doesn’t yet support all the features and I’ve heard rumors it has been scrapped and is being developed anew because some fundamental issues were discovered.

All in all, this looks like an interesting language to keep an eye on if you’re a systems programmer, but I feel C will be the king for a long while yet.

Enhanced by Zemanta

No responses yet

Stypi – the perfect blogging tool

Jan 03 2012

Stypi is a collaborative text editing tool that came out of YCombinator a couple months ago. It’s supposed to be filling a blank left behind Etherpad when it chewed up by Google and spat out as Wave.

This post in Stypi

This post in Stypi

Though I’ve never used Etherpad and have only seen Piratepad once or twice I’ve come to rely on Stypi to produce blogposts.

The first time I saw Stypi in action was when Paul Graham posted a “Watch me write” on hackernews. It was a fascinating look into the way he writes because through Stypi’s magic we got to watch a playback of one of his essays coming together.

I remember being amazed by how often he typos not words, but whole paragraphs and started wondering how often I do something similar – off to Stypi! Been looking for a way to stop using WordPress for content creation for a while anyway.

At first I watched playbacks of my writing, but soon realised this was about as fun as watching a replay of your rally game – takes just as long, is super passive and kind of boring … except in Stypi there aren’t even any spectacular crashes!

However, I’ve come to love Stypi for a different reason – it’s the cleanest, most lightweight way to write. Nothing but me and my text.

… and anybody who guesses the url I’m writing at … One of the main selling points is collaborative editing, but I like to be alone when I write. Sorry Stypi :)

Another big selling point for me is that it works _everywhere_. The only contender so far has been iA Writer, but that only works on MacOS and costs money. But I really enjoy writing on my Linux box as well.

All in all it’s the perfect drafting tool that really encourages good drafting and rewriting principles. Especially because my better posts take about two or three rewrites before they’re good enough.

Enhanced by Zemanta

No responses yet

We take Carpe Diem too seriously

Jan 02 2012

Yesterday I received the best gift ever – a day completely off. Free.

Carpe Diem

Image by m.gifford via Flickr

What’s so special about a day off, you might think, I have like two every week! Or if you’re more like me, you’re thinking Psh! Dude, I get a day off almost every month.

This was different – I had a day off from me.

None of my little rituals. No exercise in the morning. Not a single cup of tea. No jotting down random-ish actions into Daytum. No tweeting. No instagraming. No marking down every bite into myfitnesspal. No time trackers. No email. Nothing.

Even wrote the 750words at almost midnight.

For a whole day I completely threw away every little thing I do day after day that doesn’t bring a rush of oxytocin there and then. Yes, I will continue doing all those things today, no, none of it is particularly useful, yes, they all tickle the nerd inside me.

I took one more step. I didn’t worry about the pile of email I’d return to. The day’s lull in my data, or the delay in stuff I’m working on.

A day like there’s no tomorrow! Carpe Diem is fine and all, but dear god we all take it so seriously. When did we collectively forget to enjoy ourselves? That Carpe Diem wasn’t [just] about working day and night to get the upper hand on your competition …

It felt great and against all expectations, my life is not a barren wasteland today.

I didn’t devolve into a fumbling beast, all my good [and bad] habits are still there. I’m still posting my daily blog. Still tweeting like mad. And still dutifully recording all the useless data about my life. I will even do some work despite Jan 2nd being a public holiday.

If you didn’t do anything even remotely like this yesterday – shame on you! You’re an even bigger nutcase than I am!

Give it a try tomorrow, I dare you.

Enhanced by Zemanta

One response so far

Sabbatical week day 3: Raining datatypes

Dec 29 2011

I’m taking a sabbatical week over the holidays. This week’s posts will serve as a sort of report of what I got up to the previous day instead of the usual schedule – wish me luck that I achieve even half of what I’d like to.

Data Points

Image by Voxphoto via Flickr

As I sit here slowly sipping on my tea I realize it may have been an incredibly bad idea to stay up until 8am trying to convince Haskellthat I really honestly don’t care about types as much as it seems to.

It’s really quite funny how weird a statically typed language feels after many years of dynamic languages. Yes, I know, this is a Numerical and that is a Double, figure it the fuck out man! It’s not that difficult! You’d think the hardest part about Haskell would be that it is incredibly strict about the functional programming thing, but no, here I am, having trouble with the most basic of concepts.

But! I prevailed!

I had in my hands a lovely algorithm that can in theory perform rudimentary predictions of how my spending is going to behave in the next few days.  During my morning exercise I realized the implementation doesn’t actually do what I think it does, but hey, at least I have the algorithm figured out :)

The idea is really quite simple:

  1. Smoothen data with a rolling average (a 7 day window seems to produce the nicest curve)
  2. The first unknown data point is simply the expected value (weighed average) of the last few points
  3. Expand weighed average window to include the new data point
  4. Calculate next one
  5. Repeat for as long as it makes sense – the more into the future you go, the more wrong you are

After reading a bunch of papers on data mining time series yesterday I realized that I’m thinking way too much into this. Sure SVM‘s are the best at predicting financial time series and people have extremely good results with backpropagation neural networks – somehow – but I honestly don’t need this complexity. I’m just making a simple tool for myself and it’s more important to have some result than the optimal result.

And either way, according to the papers a neural network is only marginally better than the sliding window approach, and even then only when you’re dealing with data when far-away points have a lot of impact on the future and/or there is a lot of repetition – none of which happens here.

Enhanced by Zemanta

One response so far

Sabbatical week day 2: I fail at Octave

Dec 28 2011

I’m taking a sabbatical week over the holidays. This week’s posts will serve as a sort of report of what I got up to the previous day instead of the usual schedule – wish me luck that I achieve even half of what I’d like to.

English: A selection of programming language t...

Image via Wikipedia

After I managed to get the toggl and toshl datasets on Monday it was time to do something useful with them yesterday. Turns out, I’m not very good at doing useful things with datasets because my biggest achievement of the day was coming up with a plot of the data.

You know that all awesome data format that is JSON? Every programming language except Java has a nice and easy interface for loading and saving right into native data structures. This makes it perfect and all ’round awesome! So it seemed only natural that my node.js scripts for fetching data would be storing it in JSON for future use.

Or so I thought.

If there is one thing I learned in ml-class it’s that one should always take some time to first model their machine learning algorithm in a mathematical language like matlab/octave before implementing in a production-like language. Something about how all those matrix operations are easier and how having a language created especially for the task makes it all that easier to play around.

I guess octave is to machine learning as InDesign or Illustrator are to web design?

Turns out not only doesn’t Octave have a native way of reading JSON, but even when you find a library it is impossible to say Here is a file, make it a string yo! Just doesn’t work. All files need to have a format or something … it’s really quite silly.

Luckily there was a simple solution – just dump the data as a column of numbers and Octave couldn’t have been happier about it.

As mentioned, I didn’t get very far, this graph is the extent of my achievements yesterday:

Toshl and Toggl plotted

Toshl and Toggl plotted

Just for fun I tried running linear regression on this data and, as expected, it failed horribly. The lowest cost is a function along the lines of y = -6.5541e+88*x +  -4.8840e+90 … I’m not even sure coming up with fake-ish quadratic and cubic function elements would do much good in this case and since I only have a single parameter neural networks wouldn’t do much good either.

And either way, anything that comes even close to modeling this data will suffer from horrible overfitting and won’t be much use anyway … luckily I have some other ideas I can try.

Enhanced by Zemanta

3 responses so far

Sabbatical week day 1: Toshl and Toggl datasets

Dec 27 2011

I’m taking a sabbatical week over the holidays. This week’s posts will serve as a sort of report of what I got up to the previous day instead of the usual schedule – wish me luck that I achieve even half of what I’d like to.

Image representing Toshl as depicted in CrunchBase

Image via CrunchBase

Toshl is a cool expense tracking app from Slovenia, that I have been using since November last year as it turns out. I just love collecting data that I never really look at – I think the only times when I actually went back to inspect my Toshl data were those holy fuck, why am I suddenly out of money, where’d it all go!? moments.

It was never the bank’s mistake :(

Toggl is perhaps more widely known – possibly the simplest time tracker I have come across. Started using it in early June as a companion app to my Klok data for tracking productive productive time (the definition for Klok also includes things like exercise and chores for instance). In September or October I tightened up my use a bit further so Toggl only includes my billable time now.

Combined Toshl and Toggl give me this awesome dataset to play with – a near daily report of my expected income and my actual expenses.

The next step is obvious – I’m making a service for myself that, once a week:

  • fetches toshl and toggl data
  • runs a simple machine learning algorithm
  • sends me an email along the lines of Hey dude, you’re gonna run out of money in two weeks. Just thought I’d mention that

Yesterday I made the fetching part in node.js – a surprisingly difficult task when there’s no ready-made Toggl library and Toshl doesn’t even have an official API – and I’m tackling the learning bit today … perhaps even in Haskell. That should be interesting and couldn’t possibly fail right?

Oh and if you ever find yourself in a situation where you have to reverse engineer an API from web forms make sure to send the ‘Content-Type’: ‘application/x-www-form-urlencoded’ header. Wasted at least an hour trying to figure out why my requests worked perfectly with Curl but not in Node.js.

Of course it also helps if your target doesn’t have csrf protection; thanks for that Toshl team. You guys are awesome :)

PS: ping me if you think this sort of service could be useful to you too

Enhanced by Zemanta

3 responses so far

Learning me a Haskell

Dec 23 2011

English: The Haskell Logo, a stylized >λ= . Th...

Image via Wikipedia

A couple of days ago I decided that doing my graduation thesis on a topic that, when suggested, brought a sparkle to my mentor’s eye and made him suggest I might want to think about picking a co-mentor just wasn’t hard enough – so I decided to do the whole thing in Haskell.

I want to show you what I’ve learned of Haskell in just a few hours, you can skip the next five-ish paragraphs to get to the juicy code examples :)

Now I’ve never done Haskell before, I’ve heard about how awesome it is and that it’s super fast and super awesome and utterly and strictly functional and did I mention I’ve heard it’s awesome? Until a couple of days ago I didn’t even really know what Haskell looked like!

The graduation thesis really seemed like the perfect excuse to get into Haskell – and I’ve been looking for one for a while. Somehow when I started out learning functional programming with Clojure it didn’t really reel me in, Haskell so far looks like it might capture my heart.

Maybe it’s just the cool writing of Miran Lipovaca who published Learn you a Haskell in April this year (and made it available for free on the great wide interwebs), that’s making the learning curve slightly easier to digest than it was when I was doing Clojure. (he was also my classmate in high school and is my sort-of classmate now in college, which makes the whole thing that much awesomer)

The first thing I noticed is just how bloody expressive Haskell is, it feels like I’m writing much less code than I’m used to in both JavaScript and Python to achieve cool stuff. Definitely less than when I was trying to learn Clojure by just perusing the docs.

After 3 hours of learning Haskell, here’s how it compares to my Python and Javascript – I had originally wanted to compare to Clojure, but that was just embarrasing :)

Sum multiples of 3 and 5 under 1000

Haskell:

sum [x | x <- [1..999], mod x 5 == 0 || mod x 3 == 0]

Python:

sum([x for x in range(1000) if x%3 == 0 or x%5 == 0])

Javascript:

for (var x=0,s=0; x < 1000; x++, (x%3==0 || x%5==0) ? s+=x : s) {}
s

Sum of even fibonacci terms under 4,000,000

Haskell:

fib :: [Int] -> [Int]
fib terms
  | head terms < max' = fib ((sum (take 2 terms)):terms)
  | otherwise = terms
  where max' = 4000000
 
sum [x | x <- fib [1], mod x 2 == 0]

Python:

def fib(terms):
     return terms if terms[0] >= 4000000 else fib([terms[0]+terms[1]]+terms)
sum(filter(lambda x: x%2 == 0, fib([1,1])))

Javascript:

function fib(l) { return (l[0] &gt;= 4000000) ? l : fib([l[0]+l[1]].concat(l)) }
fib([1,1]).filter(function (a) { return a%2 == 0}).reduce(function (a,b) { return a+b })

I was writing the python and javascript examples directly in the console, hence less new lines. But the point is, even after just very little time, haskell is proving to be pretty much as expressive as my two primary languages where I know all a lot of the tricks.

This looks like the beginning of a long relationship.

Enhanced by Zemanta

7 responses so far

Today I nearly died … four times

Dec 21 2011

My longboard

My longboard

Today has been such an epically clumsy day – knocking over everything I touch, nearly killing random people in the street and myself in the process – that I just had to share with everyone. Reading this might give you a good chuckle at my expense :)

Let’s start at the beginning then, shall we?

The day started out as any other day would. I woke up, looked at the internet, exercised, had a shower, ate some breakfast … pretty normal stuff right there.

Then I had a friend come over and I somehow managed to apply my knee to her ankle in what looked like an extremely painful manner. Judging from her shriek and holding her leg like the best football star in the champion’s league.

On my way to class I nearly tripped over an unwitting pedestrian. But hey, these things happen sometimes, people don’t look where they’re going and traveling on a longboard doesn’t make a lot of noise while still being quite fast for a sidewalk. Plus people don’t really expect to meet a guy traveling on a longboard when it’s below zero outside … I think.

Then at a stoplight I nearly tripped over another pedestrian. She was just sort of standing there and I wasn’t very efficient with my breaking and I think she got a bit spooked when I suddenly ran past her as I jumped off my longboard, narrowly avoiding killing her.

Got overtaken by a classmate on a bike and he offered to pull me to class to make the whole affair much quicker. I agreed … but it took me five tries to get a decent grip on his backpack.

In the process I nearly killed another pedestrian.

Actually, two pedestrians, they were suddenly in my way and I awkwardly jumped off the longboard so it sort off got between their legs and they’re quite lucky neither of them accidentally stepped on it because that would be a pretty nasty fall.

A hundred meters after this incident there was a car idly parked over the sidewalk – and when I say parked, I mean there was a guy chatting on the phone while lazily manuevering a big SUV into his garage thing.

English: Downhill longboarding example picture

Image via Wikipedia

Had to jump off the longboard. Nearly killed another pedestrian who was just waiting there for the car to move.

Not ten minutes later we approached a stoplight with great speed and I couldn’t decide what to do. Should I jump off? But we’re going too fast for me to run. Should I just brake? But I’m not stable enough at this speed for driving with one foot … and if I just wait until I lose speed I’ll end up a hundred meters beyond the crossroads.

So I did the stupidest thing possible – kept hanging on to the backpack and trying to break like that. Ended up nearly taking the guy over his handlebars. Lost my footing on the longboard and before I knew it I was standing in the middle of a busy crossroads picking up the damn thing from the ground.

Luckily nobody ran me over.

Not sure how many pedestrians I nearly killed on my way home from class, but at one point I nearly smashed into the side of a car who didn’t see me crossing the road. Not even a hint of trying to stop, was just plain going and I had to jump off the longboard at the last minute with about a meter to spare.

Then I went to an event at the Cyberpipe, again with a longboard. At this point I seriously stopped counting the number of pedestrians magically winding up in my way and almost ending up killed. It’s all just a blur, indistinctive people always winding up riiiiiight where I want to go.

As if by magic!

An even more interesting thing happened on my way back home. I was passing a group of pedestrians and another group suddenly appeared out of nowhere so people took up almost the entire sidewalk. Somehow managed to swerve around everyone and just as I was about to propel myself forward I suddenly lost balance and try to catch my footing.

Longboarding

Longboarding

Sure enough, to catch my footing I stepped on the longboard and shot it from underneath me with great speed. Didn’t fall but did have to run after the damn thing. Just when I almost caught it, the longboard went off the sidewalk and into the street.

Ran after it, but there was a bus and … hey, it’s going to come out the other end right!? It did come out the other end, or rather somewhat to the side and juuuust as I was about to pick it up, it approached a car.

And the light turned green. The driver not noticing anything started off and drove right over the front-left side of my longboard, shooting it up into the air about a meter and right in my fucking leg.

The longboard then bounced off my bone and under the bus again narrowly missing being run over by a very huge tyre.

Not counting another guy who nearly ran me over because he didn’t see my crossing the street, the rest of the trip home was rather uneventful.

Should I be happy I’m alive?

Enhanced by Zemanta

3 responses so far

The problem with threads

Dec 21 2011

Regular Expression NFA

Image by jl_2 via Flickr

This morning there was a link going around listing the 15 papers you should read to understand node.js’s background. A large portion of the list is devoted to the comparison of thread- and event- based models of execution. Since I hear a lot about event loops being better than threads, I read The problem with threads written in 2006 by one Edward A. Lee, a professor at Berkeley.

If the next generation of programmers makes more intensive use of multithreading, then the next generation of computers will become nearly unusable.

And this bleak future is almost inevitable when you think about it. The rule of Moore’s law has been changing from faster chips, to more and more cores. And yet the only software making good use of multiple cores are what Lee calls “embarrassingly parallel” applications – those that simply split themselves into independent processes.

Problems with threads stem from sharing memory space. Without proper care this can lead to a situation where one thread changes a piece of data, while the other is reading it. Now you have two threads that both have a different understanding of what the value of a certain variable is.

While in theory solvable with semaphores, locks and so on, without very proper care this can then lead to deadlocks – more importantly, taking care of  interleaving threads is very hard. You are essentially facing a nondeterministic machine and trying to understand it through a poor abstraction that doesn’t  make use of your natural ability to deal with concurrency.

Lee also makes the case that this isn’t merely a problem of syntax or tools, but that threads are a fundamentally flawed model of computation. I won’t burden you with his whole proof/argumentation (page 3 to 5). The gist is that

/../ given a sequental program and an initial state, you have a defined sequence of events. Any two programs can be compared – they are equivalent if they halt for the same initial states and the final state is the same. When threads are introduced these essential properties are lost /../ if two threads can provide the next action, we can no longer compare two programs, we might be able to compare all interleavings, but on a multithreaded envrionment even that is lost since we’d have to know about  all the other programs as well.

Essentially the problem is this – the core abstraction of computation is a deterministic assembly of deterministic components, but threads are inherently nondeterministic. The car analogy Lee provides is trying to compose an internal combustion engine out of a pot of iron,  hydrocarbon and oxygen molecules randomly moving according to thermal forces.

This is so bad in practice even using very strict and rigid engineering principles, doesn’t help. In early 2000 Lee started the Ptolemy Project, a project designing concurrent embedded systems. But this is also an experiment in battling threads with rigorous engineering discipline – they developed a code maturity rating system, design reviews, code reviews, nightly builds, the works. Reviewers included concurrency experts and there are regression tests with 100% code coverage.

When the system started being used in 2000 no problems were observed until a deadlock on April 26th, 2004. Just the fact they know the exact date this happened tells a lot about how rigorously engineering principles are applied. Still, a very serious problem took four years to be discovered.

Many other approaches exist that try to combat this problem, but they either wallow in obscurity or aren’t very effective; perhaps the most effective is the use of higher-order principles like MapReduce, which aim to  break the problem into tiny fractions that can be computed separately and then combining the results.

An interesting solution Lee proposes is using the so-called Rendezvous pattern, which as far as I can tell is a generalization of MapReduce, with the use of a nondeterministic merge, so that each part of the program is executing deterministically and nondeterminism is only used in a single spot on the network – where threads actually have to interact. Lee proposes using this with some sort of coordination language, so that programmers aren’t burdened with learning new ways of implementing their solutions (a historically very slow process), but can assemble different solutions almost like Lego‘s.

Lee concludes that concurrency in software is difficult, but much of it is our own fault due to using poor abstractions. To deal with concurrency in a robust and predictable manner, we should stop using threads and focus on using nondeterminism only where it is warranted.

Enhanced by Zemanta

5 responses so far

« Newer - Older »

« 5 months of blog traffic in 4 days Today I nearly died ... four times »