From my days as a games developer for PC, PlayStation 2 and Xbox (classic), about 10 years ago, I remember reading some interesting advice from the famous game designer Peter Molyneux, which may come handy now in the world of startups.

See, when creating video games, one of the most important elements to giving players a compelling experience is to reach the correct balance. All the different parameters in the game have to be just right: difficulty, rewards, comparative power of the different options available to players, etc…  it’s really hard to get this right, and a significant part of the development process must be devoted to getting this right. Game developers and designers who can do this well outshine the competition.

In thist context, the advice from Peter Molyneux was something like this: “When you are balancing a game, don’t do small adjustments. They take you nowhere, and you can’t really even know if you are on the right path. If you need to increase the cost of some element in the game, do not add or remove 10%, make it double or half.”

This stroke me back then as genius advice, and it came from someone who really knew what he was doing. It has stuck around in my memory since then, and in twisted comeback, it has resonated with me lately, as it is quite applicable to our situation in our start-up. Let me explain.

The setup

We released our system to easily create native mobile apps a few months ago. After having invested a long time developing it, we finally pushed it online and announced it, where but in Hacker News and the programming Reddit. Quickly, it turned out the reaction from developers on those places was not positive. You can read the comment threads following the previous links. Developers didn’t like that it added custom CSS tags, that it wasn’t open-source, or that it wasn’t based on HTML5.

After reflecting on this a bit, we were thinking how to move the situation forward. There were issues with the presentation of the technology and how it was packaged, presented and documented. We could try to improve the situation that way. But did we want to put all our efforts in improving this? It would still take a long time, and it wasn’t clear whether this would help overcome the barriers people found with our project.

Pivot hard

So, evaluating it, we decided to attack the core problem of lack of attraction for programmers, and embody the same technology in another product that could really overcome most of the obstacles in the previous announcement. Too complex technology and documentation? Go for a vertical target that does without hardly any documentation at all. Not attractive for programmers? Package together a product that doesn’t target programmers.

And so we came up with Mouinpress: a system that allows you to create native mobile apps for your WordPress site. It completely sidesteps the main problems with the original technology: install a WP plugin in 15 minutes and order your app. Hardly any documentation needed. Target customers won’t complain about custom CSS tags or HTML5, since they just don’t care about how the technology achieves the goal.

We’ve been talking about it with different people, potential partners and customers, and the conversations are already much more fluid and constructive than with the previous offereing.

Pivot hard. That was Molyneux’s concept, and we are going to see how well it helps us in our foray.

Live hard

As an extra, another issue has come now, and it is that there is someone else who came up with a similar idea, and they released it a couple weeks ago. And not only that, it’s a fellow HN’er too, mind you, so of course they announced their solution on HN last week!. He also explained that he’s quit his job to do this. Same as ourselves, we’re putting all our passion, effort and illusion behind this product.

So the times coming ahead are really interesting:

• We are going to see whether the “pivot hard” philosophy really helped.

• We are going to be competing with a fellow HN’er halfway across the world (we are in Spain, the Appifier guys are in Canada).

• We are all going to see what size of an opportunity there is in this market, and whether our competitors’ approach and our approach are attractive to the market.

Live hard. You can’t put it in a different light.

Ready… go!

Exciting times ahead. I will try to document our advances. I hope that the reflection about Peter Molyneux’s Pivot hard philosophy can help you when thinking about your own projects. I hope that it serves our project well. And I hope there is a market for all our competitors and for ourselves.

And, by the way, we are looking for partners and investors, so if you can help in these areas, I will be happy to hear from you! I’m available on Twitter as @jonbho.

I really enjoyed the conversations resulting from publishing “I want to fix programming“, and I’ve come to a few quick conclusions I want to share:

• It’s great to have so much intelligent feedback, both on Hacker News and on the post itself. Very smart and knowledgeable people, some of them having explored the same area. Lots of insights. Lots of pointers to interesting projects. Proposals for approaches to get somewhere. I’m really happy to have brought this up in the open. There are a few “haters” there too, but I guess it’s the price of being out there – and this is key to getting the invaluable feedback from other people!
• Raganwald suggested that just the notation could be useful. Invaluable advice. Maybe that should be the first goal. Still, I plan to publish the full series with my progresses so far before really getting down to work, so this is some time away. Also, Raganwald is probably the only person who uses github as a blogging platform.
• Gruseom suggested the great idea that restricting things to a given problem space could be a great way to get somewhere practical.
• There is interest out there. Many people are (more than reasonably) skeptical, but many other people would love to see some advance in this area and are happy to contribute ideas, etc… this is great.

I do not have an academic background, and I sure lack some or many of the necessary skills. But I’ve done my homework, or at least a lot of it. I have insights and approaches that can add some value. I may be able to contribute a “general sketch” that can help in building a practical tool. But in any case, attempting this here in the open and without any commercial interest can be the best way to advance!

Now, since we are launching a new startup and product later today, please excuse me from this topic and I’ll get back to posting on this topic in a few days. Thanks for all your comments.

(The SB series, part 1 of 7)

Programming is broken. Completely broken. The very way we write code today is just so broken that it makes you want to puke. I’ve been saying for years that I hate programming. I am and have been a fulltime developer for over 20 years, I don’t regret it, and I still love what you can do with programming. Still, I hate programming.

The way code is written is just braindead. At each step of the process, you can crash the program, be it by filling up all available memory, accessing a stray pointer or reference, or entering an infinite loop. No doubt programming feels like walking barefeet in a floor filled with broken glass. One tiny inch out of the right place, and bang, you nearly lose one of your toes.

Every step of the way, in every statement, line of code, function call or sequence-point, if you want to write good code, you need to think about all the different possible states of the whole program. This is invisible and impossible to define. Provably. Always. In all existing languages. That’s the reason 100% code-coverage unit-testing doesn’t guarantee bug-free code, and it never will. This is also the reason bad programmers don’t become good: they just can’t think about all those possible cases in a structured way.

(By the way, this only gets about a thousand times worse with multithreaded code – so it’s not getting better, it’s getting worse.)

The problem is that the fundamental way that code is written is wrong. It’s just wrong. You write a bunch of instructions, step by step, which supposedly result in a given wanted state. But each step is separate from all others, it is only understood by the compiler/interpreter separately, and it’s almost easier to screw things up than to get them right.

I thought for a long time that functional programming could be the solution, and studied it in detail. Lisp. Haskell. The Lambda calculus. The functional approach brings indeed several improvements over regular imperative or object-oriented programming. But still it’s not the solution. It is still composed of many discrete simple steps that excruciatingly calculate the output.

What is the key thing that is wrong with code? The fact that you don’t express what you want. You express what steps have to be taken. Imagine telling your pal to grab you a beer from the fridge, step by step, with each step being robotically-rigid and with very little regard for context.  It would be excruciating. And prone to catastrophic failure. Exactly like code is.

Libraries help with this phenomenon, but they are only shortcuts for higher-legoal-specific needs. They don’t really fix it.

There was recently a very interesting post by John Carmack about static code checking, where he cited a great tweet by Dave Revell on code checking:

“The more I push code through static analysis, the more I’m amazed that computers boot at all.”

A vision

So, how should code look? Let’s take a simple example: sorting a list. Say you have an input list, let’s call it, ahem, input. Assume it has several elements. And now we want to compute a new list, called output, containing the same elements that the input has, but sorted in ascending order. How should we do it?

Traditional methods include bubble sort, quick-sort, shell-sort, insertion sort, etc… these are all algorithms that allow us to sort a list in a way that provably works. For example, bubble sort:

def bubble_sort( input, output ):
  output = input    # start with the unsorted list
  swapped = True
  while swapped:
    swapped = False
    for i = 1 to length(output) - 1:
      if output[i+1] > output[i]:
        swap( output[i+1], output[i] )
        swapped = True

Straightforward enough. But if you write the code to do the sort, you may still make a mistake! What if you forget to set the “swapped” parameter to true when you exchange two elements? Or more typical than that, what if you make an off-by-one mistake with the loop counts?

This is why I say that programming is broken: sorting is a simple concept to grasp and describe, and still, the code to do this is convoluted, and full of traps where you can crash the program or generate wrong output. It’s nuts!

Someone could come up with a functional version of one of the algorithms above, but it would still be very similar: no side effects, but many steps to do all the tasks needed. Recursion may be more elegant than iteration (ahem), but it isn’t fundamentally better.

So, how should the code to sort a list really look like? After many years, I’ve come to the conclusion that it must be something like this (pardon the pseudo-code for a style of programming that doesn’t really exist yet):

def sort(input[]) = output[]:
  one_to_one_equal(input, output)
  foreach i, j in 1..len(output):
    where i < j:
      output[i] <= output[j]

Let me try to explain it: the first line of the sort definition says that there exists a one-to-one set of “relations” between elements in the input and output sequences. We will see later how the one_to_one_equal definition achieves this. But this ensures that the input and output list contain the same elements. It defines the space of possible answers.

Second, the key thing, the next line specifies that for each pair of elements in the output sequence, when the first index is lower than the second index in the pair, then the value of the element is less or equal. Which basically states that the output list is sorted. It defines which of the possible answers is the solution.

And it’s that simple. The sort function only specifies WHAT sorting is. Not HOW it is done. It shows the properties of the output and the input, related, and it leaves as an exercise for the compiler to figure out how to get there.

Undoubtedly, there are two key questions here:

• First, how can the compiler process this? Is it actually possible? In future articles, I will try to show that yes, it is indeed possible, and that the compiler could even be able to figure out the algorithms to get this result.
• And the second key question is, how applicable is this to more complex problems? I will also try to show that it is indeed applicable to any fully-general programming or computation task, and that such a way of programming can be much simpler, more efficient, and much closer to being failproof!

I had been meaning to save this knowledge to set up a company in the future, but several circumstances have made me rethink this plan. I’d rather share this knowledge now, and see where things go. Watch out for the next articles in the series.

   def one_to_one_equal(output[], input[]) = c:
     c = relations(input[i], output[j])
     foreach x = input[i]:  len(c(x,)) = 1
     foreach x = output[i]: len(c(,x)) = 1
     foreach x(a,b)=c[i]: a == b

My current day job involves Mouinpress (a system to turn WordPress sites into native iPhone, Android, Blackberry and J2ME mobile apps), and ViEmu (a vi/vim emulator for Visual Studio, Word & Outlook, and SQL Server). If you want to help me with my project to fix programming, I’ll be grateful if you have a look, evaluate, and maybe buy or promote either of them’products. Or, since I’m looking for investors, maybe you can help with that!

I’m available at http://twitter.com/jonbho

I have reflections to share. Stuff I’ve been mulling over for the past few years. Let’s see if I can share these matters in a way you can get some value from what I write. I’ll be happy to host, read and respond to your comments. Mistakenly, I’ve done too much one-way communication in my life. It’s now the time to try and get some two-way communication rolling.