Website of Martin Sústrik, creator of ZeroMQ, nanomsg, libmill and ribosome.

Feuilletons about software design, economics, complex systems and psychology of programming.

All the opinions stated here are my own. Any resemblance to opinions of other people, living or dead, is purely coincidental.

Structured Concurrency

This article is a follow-up to the Getting Rid of State Machines blog posts, so you may want to read those first: part 1 part 2 Before going on, let me return to the fundamentals and make it clear what this effort is all about. As Joe Armstrong nicely puts it in his blog: TCP uses the idea a session and the only rational way to program a session is as a process or (horrors) as a thread. [ ] Session management involves mutable state concurrency. A program that is a dozen lines of Erlang...

Comments: 6

Getting rid of state machines (II)

So, as explained in the previous article, with green threads every state machine can be rephrased as a simple imperative function. Nice. So we are done, aren't we? Well, kind of. It's useful to do a reality check though. And it turns out that in the reality state machines have an unfortunate tendency to spontaneously emerge in the code that was never meant to be a state machine. Here's an example in pseudo-Go (I am too lazy to try to compile it). This example gets events from two distinct...

Comments: 6

Getting rid of state machines (I)

I've written about state machines before. The message I was trying to convey was that using state machines is superior to relying on callbacks. Which it is. Most definitely. However, state machines have a bunch of problems of their own. In this article I wan to discuss these problems in detail and propose what has to be done to replace state machines by standard linear code. What's wrong? Let's go straight to the problem: State machines are large and brittle. Typically, there's no built-in...

Comments: 12

Enforced Error Handling

If you don't mind your program crashing once in a while and I am not making fun here: for some programs making them 100% error proof doesn't pay off using exceptions for error handling is pefectly adequate. However, when writing code with strong reliability requirements your priorities are different. After all, large fraction of production outages comes from botched error handling. You really want to stop and think about each error code at every level as it is passed up the stack. In that...

Comments: 14

Software Totemism

We have a long-standing disagreement with Pieter Hintjens (who invested in ZeroMQ in its early stages and is now leading the community thanks, by the way!) about nature of software project. I guess it boils down to the difference in personalities, with Pieter, being an extrovert advocating the idea of a software project treated as a social club, place where people with similar interests get together, feel at home, have a good time and eventually do some good work. Me, being reclusive to the...

Comments: 17

Centrifugal Governor or Why I am not a Libertarian

As anybody who has properly internalised their Economy 101 and Evolutionary Biology 101 classes I have a strong inclination towards libertarian philosophy. I have almost Hayekian distrust for central planning (incidentally, I grew up in Ostblok) and almost Dawkinsian fascination with autonomously evolving systems. However, every time I become too enthusiastic about all that I remind myself of centrifugal governor and calm down a little. Centrifugal governor is a device, first added to the steam...

Comments: 3

Ecology of Software Quality

I've read a nice article about economics of software correctness a recently. It was a nice reminder that we are often forgetting about economics when dealing with the minutiae of our industry. However, let me try to paint a bit broader picture, dealing not only with software correctness but software quality in general. It's no secret that basically all the code we have is a mess. And that's putting it bluntly. Lot of people would choose more expressive language to describe the status quo. So...

Comments: 5

Celestial Emporium of Benevolent Knowledge

Programmer! Every time you are about to create a class hierarchy stop for a while and recall this taxonomy of animals in the ancient Chinese encyclopaedia called 'Celestial Emporium of Benevolent Knowledge': Those that belong to the emperor Embalmed ones Those that are trained Suckling pigs Mermaids (or Sirens) Fabulous ones Stray dogs Those that are included in this classification Those that tremble as if they were mad Innumerable ones Those drawn with a very fine camel hair brush Et cetera...

Comments: 2

Saving the journalism. With bitcoin.

We hear that journalism is dying every now and then. People are not willing to pay for news anymore. They expect to get them for free. If a journalist wants to live out of what they are doing they can either turn into an advertisement shop, virtually selling they readers to the advertisers or get gone. The problem is made much more grave by the fact that media is supposed to be one half of our democratic feedback loop. Paywalls are often proposed as a solution. Fair enough, but I as a reader...

Comments: 9

A really hard problem

It's not that often that one encounters a really hard problem. Complex, yes, you deal with that daily. You have to integrate with different mutually imcompatible technologies, you keep bumping into edge cases and so on. But a problem that's hard in its essence, not very much so. Hard problems are rare and precise. That's why I want to share the one I stumbled over recently. And, to warn you in advance, I have no freaking idea about the correct answer. And here's the problem: Have you ever had to...

Comments: 9

You cannot have at-least-once broadcast

I've written down this argument several times before but I think repeating it over and over until people internalise it is worth it. On this particular ocassion I was inspired by Tyler Treat's You cannot have exactly-once delivery which isn't very formal but boils down to you can't have exactly-once delivery and side effects at the same time . It's something that would be really nice to prove formally at some point. Anyway, my proof tackles a bit different problem: Ability to do...

Comments: 4

Be just or be data-driven?

There was some Amazon-bashing going on at Hacker News lately and one of the commenters came up with a story about a guy whose business used Amazon for sales and advertising. One day Amazon permanently revoked his account, no explanation given. The comment describes the consequences: This person lost everything they built over four years of hard work and had to file for bankruptcy when the commitments made by the business to support a multi-million-dollar-per-year supply pipeline caught-up with...

Comments: 4

OO languages spend most effort addressing a minority use case

Programming language design must take many aspects into consideration. Fitting it's target domain, performance, style and so on. One aspect I am personally most interested in is expressivity. Specifically: If I take a diagram from my sketchbook, is there a way to express it in the language? If I draw two boxes connected by an arrow, is there any way to capture the relationship in the language itself or do I have to resort to comments? For example, SQL is good at expressing cardinality: For one...

Comments: 16

Documentation at scale: The principles

I've been thinking about documentation a lot recently. Namely, how to maintain internal documentation in a large-scale project where multiple teams are involved and whose lifetime is measured in decades rather than years. The challenges in such environment are very different from what you experience when writing the documentation for your personal hobby project. In the latter case it's just a question of writing the document. In the former case, though, there's a whole bunch of different...

Comments: 10

Document intent not algorithm: A use case

It's often said that when writing comments you should document intent rather than algorithm. However, I think lot of programmers haven't really grasped the maxim. Therefore, I was trying to come up with a minimal use case, an example that would illustrate, in very simple and easy to remember way, why that is the case. Imagine you are debugging an application written by someone else. You have little understanding of how it works, what are the data structures or algorithms and so on. When you look...

Comments: 11

Advanced metaprogramming in C

Metaprogramming in C is the art of creating new language constructs, typically using macros. Great introduction to C metaprogramming by Simon Tatham can be found here: Metaprogramming custom control structures in C Recently, however, I've faced a problem that could not be solved by the means outlined in the article. I was implementing a control structure with variable number of clauses, similar to C's 'switch' statement. To be more concrete, I was trying to implement an equivalent of golang's...

Comments: 2

Let's stop kidding ourselves about APIs

I've browsed resources about API design on the web lately and I was rather surprised that I haven't seen a single mention of the most important thing to know about APIs. And by most important I don't mean covers 20% of the topic but rather solve it and the rest of it can be done by a monkey sort of thing. Here it is: API is a POLITICAL concept, not a technical one. Arguing that API is a technical problem is like arguing that state borders are a geographical phenomenon. Yes, boundaries...

Comments: 11

The Second Use Case for Literate Programming

Everyone have heard that Donald Knuth have invented something called literate programming . Everybody thinks that it's something like commenting your code very heavily, but maybe not maybe it's different in some way. Wikipedia isn't of much help. Nobody is quite sure. To understand what's going on, you have to remember what Mr. Knuth does for living: He's an academic. He writes papers and textbooks. And how does a paper about computer science look like? It's nicely formated text, with...

Comments: 10

A case for unstructured programming

Let me say few words about unstructured programming. First of all, almost nobody can do it any more. You don't believe me? Just try writing you next project in unstructured way, Instead of: if(x) { do_stuff1(); do_stuff2(); } write: if(!x) goto stuffed; do_stuff1(); do_stuff2(); stuffed: Very soon you'll feel that creeping sense of insecurity: Am I doing it right? If this thing going to be maintainable? And what are the best practices anyway? To be fair, the above doesn't apply to...

Comments: 12

Where are Python macros?

Everyone believes that macros (as in C preprocessor and assembly macros) are the Bad Thing and no modern language with any self-respect has them. Yes, UNIX philosophy explicitly says Avoid hand-hacking; write programs to write programs when you can but without a decent macro language, code generation has to be done by an external tool, which makes it obscure and unreadable for anyone beyond the author of the code. (We've actually seen this. OpenAMQ project was havily code generated which then...

Comments: 12

page 1 of 41234next »

Website powered by Wikidot.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License