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

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

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: 9

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: 9

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: 10

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

Dissecting Software Component's Reproductive System

After writing reusability trap blog post where I played with evolutionary concepts in the area of sofware engineering I was pointed to the Selfish Class essay, which explores similar landscape. The article is fine although a bit naive. It makes it sound like programmers were in control of the evolution of software. Whereas, in fact, they are just a useful source of random mutation in the self-driven evolutionary process. That is, I guess, both bad news (The horror! We are not in charge!) and...

Comments: 0

Finish your stuff

If there is one principle that should be added to the UNIX philosophy, it is: Finish your project. It's the most simple, yet the most disregarded software engineering princinple I can think of. I dare you to list three finished software projects. Having hard time, eh? Except for some basic UNIX tools, like grep or make, it's almost impossible to find anyting that's truly finished, not simply abandoned. Imagine the carpenters were like programmers. You bought a chair. You bought it because...

Comments: 22

Reusability Trap

Truly reusable components are clearly separated from the code that uses them. That makes it easy to use the component in a different project. It also makes it easy to rip the component out and replace it by a different one. Non-reusable components cannot be used in different projects. At the same time, they tend to be hairy and almost impossible to rip out of their native project. They are interconnected with the rest of the codebase in subtle ways. Replacing them can break the functionality in...

Comments: 10

Coroutines in C with Arbitrary Arguments

There are many C coroutine implementations out there. However, they usually allow only a single predefined type of function to be exected as a coroutine. For example, both libtask and libcoro require that the coroutine has the following prototype: void foo(void *arg); The following toy implementation of coroutines shows how to execute an arbitrary function as a coroutine. The idea is that if the coroutine invocation performs the context switch to the new coroutine straight away, it can use C...

Comments: 0

A cryptopuzzle. Ready, steady, go!

I've solved a nice cryptopuzzle yesterday and solving it was so much fun that it would be a shame not to share it. The background is simple: Elections. There's a lot of clever crypto being devised to help with elections (see e.g. E2E audiatable voting systems , also nice talk here), but, as you might notice, there's always an assumption that the voter will come to the polling place to cast the ballot. Half a minute or so of the enforced privacy in the booth is necessary for the voter to do their...

Comments: 18

Non-interactive zero knowledge proofs for fun and profit

Intuitive explanations of the zero knowledge proofs on the web have been rare. There is the classic Alibaba's cave parable, but while it is generally comprehensible it's too simplistic, in my opinion, to explain the topic fully. Luckily, recent article by Matthew Green does a great job at providing an intuitive introduction to the topic: http://blog.cryptographyengineering.com/2014/11/zero-knowledge-proofs-illustrated-primer.html But while good explanations of zero knowledge proofs have been...

Comments: 2

The Clockwork inside Game of Thrones

When Ned Stark got executed by the end of first season of the TV series everyone went like: Ugh! Not possible! He's the protagonist! He just cannot die like this in the middle of the story! Ridiculous! What's the next season going to be about? The deep sense of confusion that the event causes is he result of a completely new story-telling device invented G.R.R. Martin. And when I say completely new I don't mean it in the sense of the best one this season but rather as I cannot think of such...

Comments: 3

Bullshit jobs

There have been a nice article by anthropologist David Graeber about what he calls bullshit jobs. I recommend to read it in full, however, in case you don't, here's a short summary: In 1930's Keynes, reflecting on the improving productivity, predicted that by the turn of century we should be working only few hours a day. The productivity did in fact improve but, surprisingly, the working hours are longer today than they've used to be back then. So what's happening here? Mr. Graeber attributes...

Comments: 15

Magic numbers in C

I was asked today why I often use magic numbers in my code. It's a small issue, but I feel passionately about it as the current trend of replacing every constant by a symbolic name is extremely annoying. And insistence of some code analysis tools on treating all magic numbers as coding style errors drives me crazy. Just the give you the context, here's an example of magic number: i = i + 4; And here's a fixed version of the code: #define FOO 4 ... i = i + FOO; There are certainly cases...

Comments: 9

Are you a programmer-mathematician or a programmer-handyman?

I always assumed that programmers hate complex tools and, if given the option, choose simple tools that get the task done over complex multi-purpose ones. (And that complexity we encounter in the tools these days is mainly because develops are paid by hour rather than by delivery. If dealing with a complex tool meant you'll miss your kid's baseball game rather than just the project schedule slipping slightly, there would immediately be an enourmous pressure on tool developers to keep the tools...

Comments: 40

Idiot's Guide to ABI Versioning

Libtool ABI versioning is used in both nanomsg and ZeroMQ, so I've been dealing with it for a long time now. However, for some not completely obvious reason it seems almost impossible to remember how it works. I've observed myself as well as other people forgetting the rules over and over again. This short article is my attempt to formulate libtool ABI versioning rules in such a way that they can be actually remembered. First of all, don't think of the ABI version major/minor/patch version, e.g....

Comments: 0

Unit Test Fetish

I hear that prople feel an uncontrollable urge to write unit tests nowaydays. If you are one of those affected, spare few minutes and consider these reasons for NOT writing unit tests: 1. Return on investment of unit tests is an order(s) of magnitude lower than that of end-to-end tests. If you write a single end-to-end test the execution of the test will probably cover a substantial part of the codebase: If you write a single unit test, you cover just a small piece of the codebase: If you are...

Comments: 25

Design of PUB/SUB subsystem in ØMQ

This article was originally written on June 23rd 2011. As there was some discussion of subscription forwarding on nanomsg mailing list, I am republishing an enhanced version of the article it in this blog. Introduction PUB/SUB (publish/subscribe) is a messaging pattern used to distribute data to arbitrary number of subscribers. In context of ØMQ the focus with PUB/SUB is on scalability, ie. on ability to add more subscribers to the system without overloading it. Minimising Network Traffic Aside...

Comments: 0

Code Generation & Visual Smog in Code (part II)

(continued from the previous episode ) 14. Now that we've dealt with repetitive code and escape sequences, here comes the actual meat of the problem: The indentation. Indentation is a way to employ the 2D shape recognition capability built into the human brain in the service of understanding the code. If the indentation is broken, our innate 2D scanner switches off and we are left with having to understand the structure of the code the hard way, the way the compilers do. This off-switch of...

Comments: 2

Code Generation & Visual Smog in Code (part I)

1. I am reading that code generation then called automatic programming originally referred to the automation of the task of punching the paper tape. Later on it became to mean generation of the real code from a higher level language like, say, Fortran. Today it's not longer about creating full-blown programming languages. It's still about compilers, but rather about compilers for ad hoc, domain-specific and thow-away languages. 2. Technically, to implement a compiler one needs two major...

Comments: 2

page 1 of 3123next »

Website powered by Wikidot.

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