Heart procedure

I suffer from arrhythmia. As I type this my heart is doing some really weird things in my chest, and for me that’s normal. Left and right ventricles are confused, beating out of sync, slow missed beats, sequences of rapid beats. It’s not life threatening, but does impact on quality of life. Walking up the stairs is difficult, and strong physical exercise is too hard.

On Wednesday I am having a procedure done on my heart. It’s called ablation, and involves sending a device up from the groin area all the way up to the heart, and then making a small hole to get from one side to the other, and once there finding an area of electrical activity and burning it out to create scar tissue.

It takes about 3 hours. It’s done under local anaesthetic, with a bit of sedation to make me drowsy. Drowsy, but awake.

Everyone I have spoken to that has had this procedure has told me that it was not a big deal, and they are glad that they did it. I believe them, and despite being a bit nervous I am looking forward to this, to the hope that I attach to it. I want to get back to a normal live, back to my daily run and being able to walk up a flight of stairs without getting out of breath.

There are of course risks, and to accept the fact that I need the operation means that I must accept the risks, and the possibility of things going wrong, of the life changing impact of things going wrong. It’s at times like this that I can understand why some people choose blind faith over a desire for cold hard proof. I am the kind of person that will definitely look a gift horse in the mouth, and cannot accept any hypothesis that is not falsifiable. The God hypothesis is not falsifiable, and so for me it is useless.

Still, we all need hope. If you get hope through faith, I am happy for you, I am happy that you have hope. My hope comes from another place, from a kind of fatalism, and a little bit from a buddhist idea, that it is the desire for things that makes us unhappy. I must accept that my future is unwritten, and it could be one of many, and I should not desire one future so much that an unfavourable outcome will leave me unhappy. I must accept the risks and whatever comes next in order to be calm and to be happy.


Friends… How many should you have

This is an interesting little piece on the BBC website about not having friends, or at least not many.


I wonder, is there societal pressure to have or to at least declare that you have groups of friends. I ask this because I have never been shy about my very small and poorly defined friendship circle. One might even call it a dot.

I have always been comfortable with my own company and have not yearned for somebody to call ‘friend’. I have what I might call friends, but isn’t even the definition of friend a subjective one. Somebody might say a friend is a person you know and spend time with, whereas another might define friend as somebody you are close with and would go out of your way to help under any circumstance, and they likewise.

So aren’t we looking less at people that have fewer friends, and more at people that have a differing definition. After all, it’s a broad world with many varying ways of thinking about it.

I have once heard of a definition of friend as somebody you may not speak to for ten years, and then out of the blue you’ll call them (or they you) and you’ll pick up on the last conversation as if it were yesterday. I personally like that definition, it really speaks to me as a kind of kindred spirit.

So do I have many friends. I have many people I share my life experiences with, and maybe go to the cinema with. Of those I have a tiny set of people that would go out of their way to help me, and I likewise for them. And then of the final definition, somebody with whom I could pick up on a conversation after ten years… Well, maybe I am being too picky.

Do we need another functional language?

I want to create a new functional language.

Most of you are not developers. This is not for you… Sorry, but that’s how posting works, everyone gets to see it. Others are, and will be tutting at that first line. “What, another one!!!” is what they’re thinking, and I agree. But, I have the bug. I am doing this.

At this time the most popular and/or forward thinking languages are crossing the line between imperative and functional. Kotlin is imperative, but with a lot of functional goodness. Haskell is pure functional, but has IO monads as a way of behaving more like an imperative language.

I wonder if we can do better. This is what I am thinking:

  1. Grammer and vocabulary that are familiar to the imperative programmer. To my mind one of the drawbacks to the current crop of pure functional languages is their heavy reliance on symbols and strangely named things that make most people scratch their heads. When you spend enough time the concept of monad turns out to be quite simple, it’s the name, descriptions and documentation that suck. Let’s pull back a bit and use a vocabulary that the majority of developers will recognise. I am thinking of something that straddles the line between Kotlin and Python, with a light sprinkling of Haskell.
  2. No standard library. That doesn’t mean that there aren’t standard algorithms or structures, just that there is no external dependency beyond the binary itself and libc. Ideally a small hello world program should load as fast as its C equivalent and not be more than twice the size.
  3. Following on from point 2, it should use reference counting memory management. Garbage collection implies a large and complex algorithm to manage the heap. We can use the functional nature of the language to reduce the overhead of reference counting (just like Haskell reduces the overhead of GC), and steal some tricks from Swift.
  4. Implicitly parallel. You have a four core machine!.. Great. No special tricks. No understanding threads or locking semantics. It just works… So… No pressure.
  5. No curly braces for basic blocks like Kotlin has, but also, no indent based grammar like Python has. It can be done, you just have to make the decision very early so that grammar decisions are made wisely to stay on the path.
  6. Generics. Kotlin and Haskell have generics, albeit by different names. Python has duck typing. I’d like to lean more towards the Haskell end of the spectrum, but using a more Kotlin inspired syntax.
  7. Unused memory should be released to the host quickly.

This is just a starter list. I have began prototyping, with the goal to have a very simple hello world working soon. That means getting heap management working, function calling, type inference and IO.

What do you think. Am I a fool to try, or do you with me luck?

My perfect laptop exists

I have seen my perfect laptop. It’s fully configurable, fully user serviceable, fully upgradable, has a 3:2 display and the manufacturer is even working with major Linux distros to make sure it’ll work. Normally that makes me think of a bulky machine, but no, this time it’s compact as well!

Unfortunately it is not available on our lovely shores yet, but I have registered interest and hope that it will come.

Here’s a great review by Linux Tech Tips.

This Elon Musk interview resonates with me

Everyday Astronaut interviewed Elon Musk whilst being shown around Starbase. It’s really interesting to hear two geeks talking tech. What really resonates with me starts at time code 13:30 where Elon describes his thoughts on the development process. It reminds me of my own thoughts on best practice in software companies. I’ll link below, and give the TL;DR so you don’t have to watch it all.

  1. Make your requirements less dumb. Doesn’t matter who came up with the requirements, they’re dumb. If that person is smart it’s more dumb.
  2. Prune the process. If you don’t need to add stuff back in, you didn’t prune enough. Any requirements need to come with a name, not a department. No use having a requirement if there isn’t somebody to back it up. Departments forget.
  3. Simplify or optimise. Common mistake of the smart engineers is to optimise something that shouldn’t exist.
  4. Accelerate cycle time.
  5. Automate, with the sub-note not to duplicate in process automated tests that are represented at the end of the production line.