I recently watched ‘Fog of War‘, a movie long interview with Robert McNamara (Secretary of Defense during the Vietnam war). It was pretty compelling, he was definitely a smart ‘numbers guy’, and thought like a programmer. He talks about his early work in ‘optimizing’ bombing (resulting in the firebombing of Japanese cities), optimizing safety at Ford (resulting in seat belts) and then of course Vietnam. Being a programmer type myself I wondered if the seat belts saved more lives than the wars cost, which I suppose is the kind of thinking that can lead to firebombing cities in the first place.

It reminds me of Fritz Haber, the brilliant chemist who gave us synthetic fertilizer and poison gas. He certainly has billions in the plus column of his body count chart, no doubt a net positive – but oh my do you have to forgive a lot when you start doing arithmetic with people.

The accepted narrative here is technical genius doesn’t really understand or care about ethical dilemmas, they just are obsessed with the math of it all. Yet in both Haber’s bio and these interviews you see that they were keenly aware of the moral issues, and also weighed heavily the potential consequences of inaction. Maybe the feeling of resignation you get when a programming problem doesn’t have a ‘good’ solution is a tiny hint of what it’s like.

He has a great line towards the end of the film, “I’m damned if I do and damned if I don’t – so I’d rather be damned if I don’t”.

Rule of thumb: if an equation ever says something like, “Let L represent human lives…”, then it isn’t enough to triple check your logic. You should run the problem itself through the quote above, and determine if it’s a member of that set.

I’ve spend the last few weeks learning Objective C with XCode, it has been reasonably fun. I find the language a little rough and thus the IDE a bit wanting, but it compiles fast and the simulator is good which goes a long way. In the end developing a game with it isn’t that different that with Flash or XNA (or anything else really).

For the prototype I used Sandy’s graphics from Four Letter Word, but the game play is pretty different. The way the grid works is deceptively complicated, and it the type of thing that ‘would have’ been an excellent candidate for unit tests. It is up on gitub, and here is a video if you don’t have a Mac.

Not sure if I’ll finish this one, my daughter Summer suggested this could be a neat way for people to send a “message as a game” type greeting cards. Hmm. There is a level editor that could be beefed up to make that work.

I’ve spend the last few weeks learning Objective C with XCode, it has been reasonably fun. I find the language a little rough and thus the IDE a bit wanting, but it compiles fast and the simulator is good which goes a long way. In the end developing a game with it isn’t that different that with Flash or XNA (or anything else really).

For the prototype I used Sandy’s graphics from Four Letter Word, but the game play is pretty different. The way the grid works is deceptively complicated, and it the type of thing that ‘would have’ been an excellent candidate for unit tests. It is up on gitub, and here is a video if you don’t have a Mac.

Not sure if I’ll finish this one, my daughter Summer suggested this could be a neat way for people to send a “message as a game” type greeting cards. Hmm. There is a level editor that could be beefed up to make that work.

Yuriko and I are going to Idaho to visit some great friends this week. Always love the stark beauty of Western North Dakota/Montana, and the spectacular scenes of the Rockies. Made all the better with such good company at the other end.

I finished the Max3002 board yesterday, I must say the technique of etching with a sponge of Ferric Chloride works *amazingly* well. I wasn’t very careful soldering this one, and used smt caps instead of drilling (really trying to get away from drilling), but in a batch of 20, 20 were perfect etches. That has never happened to me before : ).

You often hear how much you can learn by studying a new programming language, but it seems you hear far fewer details on what you actually might learn. One reason is people often learn a similar C based language to the one they know, so it is more domain learning than anything computer science like (which is great too). Once you start moving into less familiar territory though – for example functional languages, SQL, HDLs – you’ll find volumes of concrete and practical insights. Solutions to problems you didn’t even know you were having!

VHDL is a hardware description language used for designing microchips. It is ‘declarative’, meaning it describes hardware in a way that can be synthesized – something like the way HTML describes a web page, not ‘programming’ per se. It is based on ADA syntax, so it looks quite different than C based languages. What drew me to it, other than how totally cool it is to be able to ‘design a chip’, is that hardware has orders of magnitude fewer bugs than software. I figured the language must have something to do with that, and indeed it does. All this makes it a great language to learn, but if you don’t have the chance, here are a few concepts I’ve found so far that could potentially ‘make us better programmers’ in the C variants world…

(caveat: I’m new to VHDL, totally welcome any corrections and additions here)

When passing parameters in a dynamically typed language like Javascript, you really should confirm they are the types you are expecting, and coming in the right order. Of course hardly anyone does. Moving to a statically typed language makes these types of bugs impossible, so problem solved right? Well actually not so fast. Imagine a method that asks you to ‘pick a number between one and ten’… You pass an int, or if your language allows and you don’t mind occasional useless casting, a uint (uint seems a better choice, but really it has the same number of invalid possible states, always a grey area). Then you pretty much have to do a runtime check to make sure it is bigger than zero and less than 11. Then a bunch of unit tests, probing all the edges, yuck. Of course hardly anyone does.

Type safety in VHDL in many ways is much narrower. For integers you can say:
signal test: integer -1 to 15;
and that is different than arrays of ‘bits’, which use a vector of STD_LOGIC:
data_bus: out std_logic_vector(7 downto 0); -- 8 bits
which is a different ‘type’ than
mini_bus: out std_logic_vector(6 downto 0); -- 7 bits

If you wanted to map part of that data_bus to something that had 4 bits, you would have to use something like data_bus(7 downto 4). Imagine the tests that don’t need to be written here, and the validation you would get for free. Much increased clarity of intent, and a bit more cumbersome.

Takeaway: Types are on a dial and always stop at some arbitrary cutoff. It is very helpful to recognize where that is, as it’s an area that tends to be full of tiny cracks. I posit that the harder something is to get to compile, the less likely it is to have bugs. Flame war ensues.

It seems a bool can only ever be zero or one, on or off, has a voltage or doesn’t… but real life (which VHDL has to describe) isn’t quite that clean. There are actually nine possible states for a std_logic ‘bit’, and for completeness here they are:

‘U’, — Uninitialized
‘X’, — Forcing Unknown
‘0′, — Forcing 0
‘1′, — Forcing 1
‘Z’, — High Impedance
‘W’, — Weak Unknown
‘L’, — Weak 0
‘H’, — Weak 1
‘-’ — Don’t care

That is a mouthful, but it does expose some of the things that are glossed over in most C like languages. Bools can be (in dynamic languages) null and undefined, uninitialized, drawn from variables that don’t exist, from variables that are later assigned null, etc. Oh the tears. Even for languages where value types are auto set to defaults, they is still possibly ‘uninitialized’ – the value isn’t necessarily the initial value you intended unless you specify it.

In VHDL if you don’t clearly specify everything, you will see a lot of “XXXX”s (aka unknowns) when you simulate, and a lot of ‘WTFWTF’s when your design becomes electronics. These X’s tend to propagate as well, so you learn early to clamp things down right off the bat – which of course pays off in the long run.

The don’t care ‘-‘ is interesting, it is essentially ‘no effect’, but allows functions that do things like:
if (std_match(address, "-01---") then ...

The high impedance ‘Z’ is quite important, as it represents a wire that is virtually ‘unplugged’. When two USB devices send data over the same cable, it is important one is ‘Z’, or they will tromp all over each other. As we’ll see next, the fact that wires are only being able to handle one ‘voltage’ at a time is a big limitation, but working with this limitation really helps keep the monsters in your code at bay.

Takeaway: Things are usually more complicated than they seem, so it is important to clearly define and limit states through the life cycle of an object. Even a simple bool can set off a chain reaction of obfuscated misery. State is the enemy, and proper initialization is the first line of defense.

In VHDL, the default is one signal can only be ‘driven’ by one thing (and must be driven by one thing, as explained above). Basically this comes down to electricity again – if you have two wires connected to one pin and the first gives it 5 volts and the second 0 volts, information will be lost. So to translate,
int foo;
foo=5;
// and somewhere else
foo=10;
would be an error in VHDL. Multiple assignment locations (‘drivers’) are something I’ve never consciously thought about while programming, though they were involved in plenty of bugs I’ve had to think about! Debugging gets much more difficult once you realize a problem state could be coming from a number of sources (the fact that ‘Find All References’ is one of your first debug questions tells you something already). I think we instinctively try to limit assignments with choke points, scope and visibility. If you’ve ever written threaded code this is probably even more instinctive to you. It is very helpful to stop and recognize this as a problem, and then more deliberately limit and track ‘assigners’.

Of course sometimes you need two sources for one assignment, and VHDL is no different. A common pattern is to have a ‘variable’ that indicates which wire is ‘on’ – kind of like a group of radio buttons where only one element can be selected. The ones that aren’t ‘on’ become ‘Z’, aka high impedance, aka unplugged.

target <= sourceA when control = '1' else 'Z';
target <= sourceB when control = '0' else 'Z';

Takeaway: Many of the code breakdowns you see are from ‘assignments gone wild’. Unless there is a good reason, variables (especially those that set state) should have one boss. If that isn’t possible, then assignments should have careful and scheduling that doesn’t overlap. I think this explains more than anything why most DeclarativeUI is such a disaster. It isn’t enough to limit scope or make something private. You want to limit the number of inputs, not just their locations.

In VHDL the elements of an interface declare their direction. They can be in, out, inout, or buffer. Combined with the previous restrictions on assignment you get fine grained control and certainty over how data moves around between modules (which are akin to class instances). A common pattern is a container hooks one module’s ‘out’ to another module’s ‘in’ – this can be thought of (almost literally) as a wire connecting one chip to another.

in – input only, can not be written to from inside the module (~class)
out – output only, can not be read from inside the module
buffer – output, but can be read by the module
inout – input or output, used for bidirectional signals

Some languages in the C world have ‘get only’ and ‘set only’ properties, but that is a little different as they generally have a private holder variable with no such restrictions. There are virtually no tools to limit access to class level variables within a class – everything is ‘inout’ by default, where in VHDL that only used for bidirectional signals.

Takeaway: Data crossing class boundaries is always a bit uncomfortable in the OOP world, too much feels like spaghetti. VHDL gets around this by making it very clear what is hooked to what, who is sending and who is receiving. It makes you realize that some things are naturally hooked to external things, there is nothing wrong with that – it’s the loose way we hook them together that gets us into trouble.

In VHDL, like in most electronics, everything runs on a clock tick. You can have different clocks, but generally they will be synchronized (eg, one is every third tick of the other). You can make asynchronous multiple clocks, but everything I’ve read says never do that… unless you are a pro and know exactly why you need it. Which takes a lot of pressure off me.

Running all code off a synchronized clock tick is a really powerful technique, which comes as no surprise to any game programmers out there. Divided and multiplied clocks (though still synced) are common in VHDL, and very interesting. I’ve never tried that in a game, and think I will next time – something like uiClk = (clk % 32 == 0) ? 1 : 0; Hmm…

Takeaway: Ticks are your friend. If you are coding anything beyond a PHP function call and haven’t used an update loop, give it a look. It simplifies many complex problems, and gives you a lot of control over states, transistions, and hairy timing issues.

It isn’t a big secret that inheritance loses its shine as it grows, and it is inspiring to know that VHDL can layout 5 billion transistors without it. In VHDL you define modules using an interface (entity) and an implementation (architecture). You then you create instances of these in higher level modules, and instances of those in higher level modules, all the way to the top. This makes it tree based, much like an OOP object created using composition only. The top level module represents the chip itself, and its interface describes the pins.

Takeaway: I’m not an inheritance hater, but certainly prefer composition over inheritance. VHDL takes you a bit further here and shows what is possible without inheritance in the way. On the flip side, other structures it has (next) suggest what you might be missing with a strict composition only OOP design.

VHDL modules define an interface (entity) and implementation code (architectures). This is somewhat akin to a class that implements an interface. What is different is you can define multiple architectures for the same entity, and then specify which one to use when you create an instance. The problem this solves for VHDL is it gets synthesized to different types of hardware, and the efficiency low level gate structures varies a lot based on the target (yes, VHDL gives a whole new meaning to control freak, and that is before even talking about nanosecond timing attributes). This is somewhat like if you had the option of specifying the assembly code your class would generate, and then allowing instances to choose which to use.

The interesting thing about this is it allows a sort of ‘same level inheritance’. An example of where this could be useful is a button and all its offspring. Imagine a Button, ScalableButton, ToggleButton, RadioButton, ThreeStateButton, Icon etc. The traditional thing to do is make a super duper generic button class, and then everything inherits all over the place, often ignoring things defined in the parent (eg a 9box button probably doesn’t use a single background image, another button may not have text). Composition doesn’t fare much better as your Button class gets so generic that is starts looking like Object’s twin. It might be useful to be able to say b = new Button’toggle(); and have it grab the toggle code instead of the radio button code. The real problem here is these are really just different ways of saying the same thing – they are types of buttons at the same level in the inheritance chain, so they don’t fit into a clean hierarchy.

Maybe a better example would be an ‘OK’ button on Windows vs an ‘OK’ button on Ubuntu – same thing, but you clearly need two sets of code.

Takeaway: Next time you end up not being satisfied with your inheritance chain, and feeling that a composition solution will be awkward to define and initialize, don’t beat yourself up. Maybe the real problem is they are objects at the same logical level. There are plenty of examples of things in the real world that are the same in spirit, but treated differently in practice. Think crimes of the rich, crimes of the poor.

In VHDL, concurrency is the default. You can quite easily turn an FPGA into hundreds of independent mini CPUs, or a massively parallel DSP. With single point of assignment per clock tick it actually isn’t that hard to ensure things do not explode in the way you are used to with C style concurrency. Much to be learned here.

Takeaway: Traditional approaches to concurrency that I’ve seen focus on managing resource contention, avoiding lockups, and cleaning up the inevitable messes. I haven’t seen a lot of attempts to just ensure sure things don’t collide in the first place and skip the rest. Given state is passed around like a crack pipe in C based languages that isn’t much of a surprise. VHDL suggests that sensible management isn’t as impossible as it sounds.

VHDL uses finite state machines a lot, and this is already a great lesson to take back. It also distinguishes between types of state machines. With Mealy state machines the output is based on the state as well as the input, with Moore the output is based solely on the state. Obviously the Moore ones are preferred in that they are simpler and synthesizes to something cleaner and smaller, but naturally they can’t always solve the problem at hand. That is fine, but you should at least be aware of which you are using.

Often in the C variants world we aren’t even aware of tying secondary values to outputs. Some methods will just return a value based on internal class properties, some combine that with input parameters, some with states of other external objects… and worse. While this is certainly needed sometimes, we should be very aware that we are adding ‘cost’ geometrically with each expanded step. When fusing variables isn’t avoidable, we need to make sure it happens in one place, at the logical location, and the right level of abstraction.

Takeaway: In programming, code that generates cleaner assembly is usually easier to read, debug and maintain as well. The less properties are bounced around and combined the simpler and more obvious the code will be for both you and the compiler. VHDL reminds us coding is kind of like driving, where you shouldn’t move the steering wheel more than you need to.

This is a huge area in VHDL, and enough for another book length post. One point you can’t overlook though, is testing is built in to the language. In the C world we tend to rely on unit tests at best, but here there is much more focus on simulation. VHDL also pays great attention to what is happening over time, which is a kind of forgotten area in most of the C world (I hit a breakpoint, and see the state of the world – how it got here, the lord only knows). Scheduling is also a huge focus in the code itself, not just the testing part.

Takeaway: Verification is super important, and while we take steps to get that right there is much more to do. VHDL is a rich area to learn from in order to extend what we know. Verification is not something you just bolt on – like security it really has to be integrated into every step of the process and thinking.

Anyone who thought writing complex code is somehow better would soon be making things as obvious as possible in VHDL – the last thing you need here is intentional complexity! Debugging is *much* harder with hardware, so it forces you to build level by level, with fully tested small and functional modules. The chances of buggy code compiling is already low, but if it does run it is much more likely to fail completely. So much time is saved in a ‘fail early and fail big’ environment, but we are often stuck with, ‘fail silently and keep going’. We can still intentionally structure our code to fail big on problems, and VHDL reinforces why you would want to do that.

Takeaway: Not mentioned, but being harder also means the language attracts (or creates?) better programmers with better attitudes. It makes you ‘think like an engineer’, which surprised me because I thought I was already doing that : ).

Ultimately there are fewer bugs when there can’t be bugs, so maybe what really need to do is reverse the question. It isn’t, “why are there so few bugs in hardware”, but more, “why is it ok to have so many bugs (to different degrees) in the C variants world”? Is it culture? Is it quality of libraries/runtimes? Does it not actually matter as much? I’d love to know.

Want to learn more VHDL? I’d recommend looking at the Papillio!

So last week I deleted my Twitter account after being on there for a few years. I didn’t rage quit or anything, actually I really liked all the people I followed along, and I enjoyed Twitter to the end. Still, the feeling of wanting to quit has been growing over time, not 100% sure why, but approximately the following…

First, it takes a lot of time. Not huge amounts, and it is easy to ignore if you are busy or otherwise occupied, but it tends to siphon away your free time – something few of us have enough of. As Kevin Lindsey wrote, “It seems like all these self-imposed interruptions make it difficult to make progress on original thought”. Umm, yes, exactly that too. (And in 106 characters, dang he’s good!)

It siphons away your need to create and communicate. I have a vague theory that people have a ’spinal cord’ need to create and communicate, even us geek recluses. Over time pressure builds to the point that we are pushed into action, to speak our mind fully, clarify with debate, and do our deeds. This leaves us nicely satisfied, until the next build up. Assuming that is true, Twitter is basically a steam release valve for this. It gives you momentary satisfaction in trivial doses, and a nice little bong hit for our greater ambitions.

We own our words, thanks. One thing that was a bigger yuck than I thought it would be, is once you delete your account, everything you said disappears. Not only that, all your photos (twitpic etc) are gone too. All the links to things you found interesting. All the things friends said to you. You can go and backup some of this up with various services, but so what? – where are you going to put all that without any context? This is the problem with having your relationships facilitated by a business. Is the world going to miss my profound musings? Not at all, but I did go to the effort of typing it all out and putting it on the internet. I feel Trotskyed.

We own our words, part two. The more you read and type into a social network, the more money you earn (for someone else). In most contexts that is called a job. On the internet too, but you get paid in status – and if anyone is wondering what exactly status is, it’s a number. Keep working, get a bigger number. Leave and you’ll never see your friends again. I have zero problem with people making money, but something in this new AOL universe smells like the old AOL universe.

Btw I could have kept my account and not used it. I can also keep wine in the cupboard and not drink it.

Twitter isn’t great at building mind hives. I know it’s meant to be an endless free running conversation, and it’s great at that, but humans are best when they can collectively iterate on what they are building. As flawed as the Wikipedia process is (and it is flawed), its stellar success is due to the fact that it moves forward faster than it moves backwards. The same goes for science. The same goes for almost everything worth doing. Twitter is wonderfully fluid because almost everything disappears within an hour or so, but we shouldn’t confuse that with short life spans/rapid generations. It is a light show. Over time it is kind of like progress a species makes with masturbation vs having sex. Search doesn’t lead to Twitter because ideas don’t evolve there.

Online friends have a tragic flaw. It can be funny if you threaten to “go home and hang out with my internet friends” at a party, but in reality we all have really really good friends online that are very close to us. Most of us have never met each other. This summer our family went through some tough times, and friends and family were so beautiful to have close. That did not in any way make ‘online friends’ seem superficial in comparison, in fact it was the opposite. You know there are people that would be your BFFs, you even know who, but distance is in the way. Hard to explain I guess, but it’s kind of like looking at pictures of food when you’re really hungry.

Skull walls do not a prison maketh. The one huge creepy thing about online social sites they seduce us into giving up control of ourselves. Social media is great for people just wanting to ping their friends, or keep in touch with kids and grandkids — it’s there, it works and it’s easy. But we are the technicians here! We know how to create places and do all those cool things over TCP/IP. We shouldn’t be seduced into exchanging control of a technical medium for some fake status or cheap sales pitch. We can carve out whatever world we want here, if we just ignore the light show, and move forward faster than we move backwards.

It’s ours to take back.

…

I was going to make a bubble etcher today when Google led me to this: A way better way to etch.

This is from the people who make the excellent transfer paper I use. They claimed you get way better etches using a sponge with Ferric Chloride on it than even a bubble tank! I tried it out with a cheap foam paint brush (the kind used for painting window frames etc), and it worked really really well. I was much quicker, and because of that a much cleaner etch. I tinned this board as well.

I’m looking into making boards without drilling – not just surface mount, but also bending dip pins, flattening 7seg pins etc. Not sure how that will go, but KiCad is great for that as the footprint is disconnected from the pin.

These boards are for a level shifter, based on the MAX3002. Everything is perfect except the paper bent on two of them (used toner transfer with glossy laser paper, but I wasn’t careful and the laminator creased the paper a bit). Oh, and I forgot to mirror the damn printout : ).

The scroller ball stopped working on the Mac mouse, and I was a bit surprised to find that every single person in the world has had this problem twice. Once I broke the glue seal (ugh!) and disassembled the wheel I could see it was cloged with lint. What I couldn’t see is how it was possibly not going to get clogged with lint given its design. Stuff will fall into the ball, which is in a metal box, which means it can’t get out. This is worse than the old roller ball mice because it is smaller, it is inaccesible, and there are four rollers instead of two.

I’m pretty sure they won an award for this design, it has the three essentials: it looks cool, they were ‘thinking outside the box’, and it doesn’t work. What gets me is how people go on and on about the perfect design of these mice, even when their own is broken, even after the third time. Mac fans have always had lots more blind love to give out than PC or Linux users, and I’ve never really understood why. There are certainly things that are better about Macs, and there are certainly things, key things, that are worse. The windows expand from the bottom right only, disconnected menu bars, years of right mouse button neglect, war on tabbed UIs… mouse lint. Every OS has issues, so whatever, you can always get work done. It’s when people call Windows ‘unusable’ that I have to wonder what kind of learning block they might have and why they seem so proud of it.

The recent passing of Steve Jobs, RIP, and the ensuing reaction has brought some clarity on the whole Mac love/hate thing for me. Probably more than anyone else, Apple has shepherded historically tech hostile people towards embracing technology, up to thinking it’s cool for some, and well beyond for others. Computers were once unusable cold mathematical machines as the narrative goes, and suddenly they were transformed into warm creative beautiful tools. This paticular brand allowed you to keep your soul and creative mind while still enjoying the benfits of rigourous mathematics. All credit for this miracle goes solely to Apple – faith doesn’t allow accepting other views as essentially the same ideas positioned differently.

Apple gets points for this though, convincing arts types to use computers has been a huge (and profitable) accomplishment — just the emphasis here is on ‘convincing’. Macs, Windows and even Linux desktops are essentailly the same thing as far as OS goes, and they run on the same hardware. Beautiful things, tons of work, red blue or green.

The problem for me, and probably you, is that I’ve never for one minute needed convincing that tech was cool – that is just obvious by inspection. From the physics level of the P-N junction, the micro pulses of directed energy, the storage and buildup of bits and logic, the HDL’s that scale the physics up into chips, the mind boggling steps taken to produce them, the insanely high speed coordination between specialized periphials, the sensors and interfaces that allow us to interact, the compilers, the protocols, the languages, programs, meta programs, form factors… It is all amazing and it’s turtles all the way up and down.

So next time someone says in a hushed tweet, ‘computers wouldn’t be usable if it wasn’t for Apple’, they are ‘magical’ and ‘they just work’… it might help to translate that to ‘I love technology’ and just be glad they agree. Yes, it will still feel like a hairless ferret is wet humping your bare leg, but that doesn’t make you a hater. It is just a recognition that technology is a massive massive cross cultural global ongoing collective effort, and you are comfortable not personifying it with a single face or name.

And it is very very deeply fucking cool.

Oh, got the mouse working again. No idea why they didn’t use IR LED tracking on the top as well, they could probably piggyback on logic already in the hardware. Oh well, fun to take apart, other than the glue.