Tuesday, 22 March 2016

Terrorism As A Theological Statement



Sunday, 6 March 2016

The Parable of the Atom Seeker

A young student grows up in a society that holds the belief where she, like everything else, is made up of tiny unseen particles called atoms. So after learning something about the methodologies of science, she decides to understand what the science is behind the atom.

What strikes her at first is how the explanations for the atom didn't fit at all into the scientific method, but relied heavily on everyday experience. Furthermore, no modern physicists have witnessed such experiences, but rely solely on the accounts of early physicists. Some physicists claimed to have experiences that tangentially supported the experiences of the original physicists, but none of them could produce any evidence remotely like that which holds for other theories.

Upon further investigation, she realises that physicists disagree among themselves as to which experiences count as evidence of the atom. Some physicists argue that the experiences are interpreted too literally, while others hold to as literal a reading as possible. Some argue that the experiences can only be understood in light of arcane mystic writings and ancient mythic tales, and there is disagreement among those physicists as to the process this takes.

The quality of evidence is further called into question when other physical theories adequately account for the evidence for atoms without needing to posit atomic theory. She finds physicists will admit this in parts, but again there is disagreement between physicists over which scientific phenomena explain away the need for atoms in any given case. Some physicists spoke of the atom in metaphor, some shrouded knowledge of atoms in mystery, and some asserted that certain experiences of atoms were brute facts.

But not all physicists even agreed that evidence was important. Some physicists argued from first principles alone, invoking philosophical arguments that spoke of the atom's necessity in some respect. There were multiple of these arguments, though physicists disagreed among themselves as to the validity and significance of various arguments. Entire classes of arguments were championed by some physicists, while others favoured a different kind of arguments. She found the arguments for the most part lacking in any detail, and where there was detail it contradicted other established science. There was just no way to reconcile the arguments with the claims made about atoms.

She found some physicists who disagreed with both the arguments and the evidential approach. Some argued for the beauty of the idea as proof of the reality of atoms. Other physicists argued that atoms fit with our emotional needs. Some argued that the atoms were needed to keep social order. Some argued that their emotional response to the theory is its proof. Finally, some physicists admitted that a belief in atoms is a matter of faith, which a few embracing the idea of atoms precisely because they are an absurd concept.

The only constant she found in the exercise was the belief itself. Physicists couldn't decide among themselves what the implications were, let alone any detail that could be subject to the same scrutiny that other physical theories have. What follows is that the consensus among physicists is an artificial one, with no two physicist sharing quite the same view of what an atom is or how we know about it. And, finally, the reasons and evidence given in favour of atomic theory were unlike the various successful epistemologies that she had learnt about. At that point, there was nothing to do for the idea of atoms than to just walk away until such time the concept became more scientific... though she doubts that would ever be the case.

The question "does God exist?" has been the focus of more than enough academic inquiry that the inquiry itself deserves to be taken seriously. In any given field, outsiders looking in are looking at the promise of a discipline to be able to provide satisfactory answers on the questions it purports to cover. This isn't always easy, as academic discourse tends to become self-sustaining making it harder for outsiders to be able to make sense of it. So some latitude must be given for outsiders simply not to "get it" when it comes to the validity of the questions and the approach to answers the discipline offers.

Two things to recognise are that a) no human endeavour is truly in isolation, and b) there are a lot of ways to spend a lot of time asking wrong questions. Astrology and alchemy good examples of both. The methods of astrologers and alchemists throughout the ages have overlap with the methods used in science and philosophy. And both astrology and alchemy are nonsense notions that had a lot of ink spilled over a long time by some very smart and learned people. Very few of us are astrologers today, and none are alchemists, yet as outsiders we feel sufficiently qualified to write off both intellectual disciplines as failed truth-telling endeavours about the universe. It could have turned out both were true. It turned out neither were.

What I tried to do in the parable above was highlight my own experiences trying to understand the question of God as believers see it, including what philosophers and theologians have said about the question. I grant the possibility that there could be a theologian out there who has a legitimate case for God's existence, but I don't see the worth of exploring the subject in any great detail. Despite the towering intellects and sheer amount of manpower thrown at the problem, there doesn't seem to be the same conversation among learned believers about what God is and does - let alone a case made with the successful epistemologies we have developed. This stands out in contrast to the actual atomic theory - or any other scientific theory - where the scientists have general agreement as to what theories are and the state of the evidence, even if they sometimes disagree on detail.

Wednesday, 15 April 2015

The Cult of Health











Saturday, 28 March 2015

Game Review: Frozen Cortex

The rogue-like FTL: Faster Than Light was an uncompromisingly difficult game, where playing up to two hours at a time could be undone by one moment of chaos. So many times I ploughed through that game only to declare the universe as being intrinsically unfair as a simple mistake cost me a good hour of careful planning, only to have to start over again. The illusion is that next time I'd get it right. I'd shield the doors earlier, or make sure to stock up on extra missiles, or avoid saving the crew of a ship on fire.

The futility of the game combined with the (somewhat illusory) sense that I was in control kept me coming back. It was only when I could get through to the end of the game regularly that I finally lost interest.

Which brings me to Frozen Cortex.

Frozen Cortex is what you get when you cross American Football with Frozen Synapse - which is in turn what you get when you cross chess with guns. I really enjoyed the idea of Frozen Synapse, but I never could fully immerse myself in it (Hell is Internet multiplayer...) I haven't had that trouble with Frozen Cortex, already rocking up close to 30 hours of game time.

The funny thing is that there's really not a lot to Frozen Cortex. The entire game consists of short matches, with each player controlling 5 robots on rectangular arenas populated with various obstacles. It's simple enough to grasp, simple enough to control, and a tiny mistake can undo hours of meticulous planning. Any given match can be thrown away from incorrectly guessing what an opponent would do, and that makes knock-out mode all the more difficult.

Because the games are so short, minor mistakes have those major consequences. Screw up on your own offense, and it's virtually guaranteed to be game over. Misread your opponents and it can be similarly difficult to come back during your own. The game's annoying habit to "pause" the turn halfway through a touchdown pass can often be just rubbing it in that you didn't realise the opponent had that option open, and there's nothing to do but slam the PRIME button and hope there's still enough time to recover.

And there are many ways it can cost you. A slightly mistimed run means a key player is knocked out. Throwing to a player too close to an opponent gives them no time to act before they are tackled. Passes that get intercepted. Having your player slightly mistime an interception. Moving to the wrong side of an obstacle. And of course, all these are compounded with scoring pads littered throughout the arena. They are only worth 2 points (compared to a 7 point "touchdown"), but a good run can cross several pads at a time. One particularly bad example was a robot that could just sneak around an obstacle for an unguarded heavily-padded run to the end-zone.

It's that futility that like in FTL: Faster Than Light keeps me coming back. I didn't see that play. I'll be mindful of that next time. It's with that attitude I've been able to beat the game on season mode (and opened up interesting variations), but haven't quite gotten through a knockout comp yet. The game is cruel, uncompromising, punishing, and that's what makes it such a rewarding experience.

Monday, 15 December 2014

Slipping Back into Old Habits

I have a lot more time to think about coding issues than I have time to code. In some ways, this is quite handy as it allows me to plan through certain problems and foresee potential pitfalls of a particular solution. I think there are two key problems with this, however. First, even if I come up with a solution it's still only half the job done. Second, it gets be bogged down in coding problems that often are beyond my coding abilities. This all became apparent in the last month when I became bogged down in a particular design problem. A month later, I'm still no closer to a solution, and worse still I'm not making any progress in any other area. And instead of just coding a workaround for the time being, I became fixated on solving the problem.

(I needed compile-time polymorphism where I previously had run-time polymorphism. I read through books and websites on templating, tried rudimentary attempts at adjusting my code, but always I was trying to code up a perfect solution in my head, weighing up potential considerations and pitfalls. And at the end of it, all I have is the lament I just didn't code around it.)

What I find so disappointing is I know all this. There's nothing particularly revelatory in that I dwell on problems instead of working around them, but it is disappointing that I still haven't moved on from the problems I had when I was at university learning to code. I get too hung up on solutions that I haven't learnt how to code around it.

This game coding happens in the limited spare time I have. It's a hobby, and comes after other aspects of work and life. So maintaining motivation is always a struggle, especially in the face of seeming blockers. And from what I've come to know about the role pressure plays in inhibiting the creative process, the limited time often translates into fixating on particular solutions instead of just getting on with something else.

Given that I'm still adjusting back into C++, it's easy for me to think of failures as a lack of knowledge of the language itself. Sometimes that's apparent, and I know as I'm reading through various C++ material that I'm skimming for a particular solution context rather than internalising the language feature as a potential design tool in the future. But I think it would be a cop-out to blame my current understanding of C++ when the language is so flexible in the kinds of solutions that are permitted.

It's always, I think, going to be a question of motivation. That is, am I able to code something that's good enough for the task at hand? One thing that's problematic is that my initial scope is far too ambitious – that is, I'm trying to create a framework that could be used to make any number of 2D games. So in that respect I'm stuck trying to figure out generic solutions.

And therein lies the problem. How do I know I'm going to get to use any of the design work I've put in so far? For example, all the time I spent writing wrapper objects for SDL code, as far as I can tell, has had very little benefit so far. Indeed, the main reason I did that was to have a sort of platform agnosticism – the theory was that I could refactor out the core features of the engine to a different library without having to permeate those decisions down through game code. Yet if I'm never going to do that, then as happy as I am with some of the wrapper code I wrote, then a lot of that effort was wasted.

(Funnily enough, as I was trying to learn SDL, one thing I got frustrated with was that the tutorials were so direct in their use of the libraries. I took it as an act of clarity on account of the tutorial writers that they didn't try to muddle things up by enclosing their code in some simple patterns. But as I was coding up my input system, I wondered just what benefit I was getting out of mapping SDL structures with my own.)

This too, I think, highlights the perils of solo development. As I'm working on this project, I'm accountable to one person: myself. What I design, what I build, what my desired end-product is – all that is my decision. And since I'm starting from scratch and working completely unguided, it’s inevitable that I'm going to not only make bad decisions, but those bad decisions will lead t o a lot of wasted time. You live, you (hopefully) learn.

What I think I've learnt is something about the limitations of myself. If I have a certain disposition to coding a certain way, then it would be madness to think I can just overcome it by saying "don't". What I hoped with prototype-driven design was that I could better focus on what needs to be done, rather than what I would think might need to be done. That, now, seems like only addressing half of the equation, and what's missing are techniques for build-and-refactor so I don’t get bogged down where an elegant solution is not immediately apparent.

I know at times I need to get out of my head – I have notebooks that are filling up with ideas faster than I'm adding lines of code to the codebase. What will remain to be seen is if I can work with my own personal practices and habits. Like losing weight, if you try to do it on willpower, then you’re going to fail miserably.