Build systems are a huge annoyance

Take Smalltalk. Do I have an object in my image? Yes? Well I can use it. Does it need to do some compilation or something? I have no idea, it just runs my Smalltalk.

Take Python. Do I have the python code? Yes? Well I can use it. Does it need to do some compilation or something? I have no idea, it just runs my Python.

Take C.

Oh my God.

C is portable, and there are portable operating system interface specifications for the system behaviour accessible from C, so you need to have C sources that are specific to the platform you’re building for. So you have a tool like autoconf or cmake that tests how to edit your sources to make them actually work on this platform, and performs those changes. The outputs from them are then fed into a thing that takes C sources and constructs the software.

What you want is the ability to take some C and use it on a computer. What C programmers think you want is a graph of the actions that must be taken to get from something that’s nearly C source to a program you can use on a computer. What they’re likely to give you is a collection of things, each of which encapsulates part of the graph, and not necessarily all that well. Like autoconf and cmake, mentioned above, which do some of the transformations, but not all of them, and leave it to some other tool (in the case of cmake, your choice of some other tool) to do the rest.

Or look at make, which is actually entirely capable of doing the graph thing well, but frequently not used as such, so that make all works but making any particular target depends on whether you’ve already done other things.

Now take every other programming language. Thanks to the ubiquity of the C run time and the command shell, every programming language needs its own build system named [a-z]+ake that is written in that language, and supplies a subset of make’s capabilities but makes it easier to do whatever it is needs to be done by that language’s tools.

When all you want is to use the software.

Posted in code-level | Leave a comment

Tsundoku

I only have the word of the internet to tell me that Tsundoku is the condition of acquiring new books without reading them. My metric for this condition is my list of books I own but have yet to read:

  • the last three parts of Christopher Tolkien’s Histories of Middle-Earth
  • Strategic Information Management: Challenges and Strategies in Managing Information Systems
  • Hume’s Enquiries Concerning the Human Understanding
  • Europe in the Central Middle Ages, 962-1154
  • England in the Later Middle Ages
  • Bertrand Russel’s Problems with Philosophy
  • John Stuart Mill’s Utilitarianism and On Liberty (two copies, different editions, because I buy and read books at different rates)
  • A Song of Stone by Iain Banks
  • Digital Typography by Knuth
  • Merchant and Craft Guilds: A History of the Aberdeen Incorporated Trades
  • The Indisputable Existence of Santa Claus
  • Margaret Atwood’s The Handmaid’s Tale

And those are only the ones I want to read and own (and I think that list is incomplete – I bought a book on online communities a few weeks ago and currently can’t find it). Never mind the ones I don’t own.

And this is only about books. What about those side projects, businesses, hobbies, blog posts and other interests I “would do if I got around to it” and never do? Thinking clearly about what to do next and keeping expectations consistent with what I can do is an important skill, and one I seem to lack.

Posted in advancement of the self | Leave a comment

A full-stack software engineer is someone who is comfortable working at any layer, from code and systems through team members to customers.

Posted on by Graham | Leave a comment

FOSDEM

My current record of FOSDEM attendance sees me there once per decade: my first visit was in 2007 and I’m having breakfast in my hotel at the end of my second trip. I should probably get here more often.

Unlike a lot of the corporate conferences I’ve been to in other fields, FOSDEM is completely free and completely organised by its community. An interesting effect of this is that whole there’s no explicit corporate presence, you’ll see companies represented if they actually support free and open source software as much as they claim. Red Hat doesn’t have a stand, but pick up business cards from the folks at CentOS, Fedora, GNOME, ManageIQ…

When it comes to free software, I’m a jack of many trades and a master of none. I have drive-by commits in a few different projects including FreeBSD and clang, and recently launched the GNUstep developer guide to add some necessary documentation, but am an expert nowhere.

That makes FOSDEM an exciting selection box of new things to learn, many of which I know nothing or little about. That’s a great situation to be in; it’s also unsurprising that I know so little as I’ve only been working with free software (indeed, any software) for a little over a decade.

Posted in Uncategorized | Leave a comment

Coercion over configuration.

Posted on by Graham | Leave a comment

The package management paradox

There was no need to build a package management system since CPAN, and yet npm is the best.
Wait, what?

Every time a new programming language or framework is released, people seem to decide that:

  1. It needs its own package manager.

  2. Simple algorithms need to be rewritten from scratch in “pure” $language/framework and distributed as packages in this package manager.

This is not actually true. Many programming languages – particularly many of the trendy ones – have a way to call C functions, and a way to expose their own routines as C functions. Even C++ has this feature. This means that you don’t need any new packaging system, if you can deploy packages that expose C functions (whatever the implementation language) then you can use existing code, and you don’t need to rewrite everything.

So there hasn’t been a need for a packaging system since at least CPAN, maybe earlier.

On the other hand, npm is the best packaging system ever because people actually consume existing code with it. It’s huge, there are tons of libraries, and so people actually think about whether this thing they’re doing needs new code or the adoption of existing code. It’s the realisation of the OO dream, in which folks like Brad Cox said we’d have data sheets of available components and we’d pull the components we need and bind them together in our applications.

Developers who use npm are just gluing components together into applications, and that’s great for software.

Posted in architecture of sorts, code-level, javascript, OOP, software-engineering | Leave a comment

In which the quantity 1/"booleans per module" is proposed as a software quality metric, and readers are left hanging.

Posted on by Graham | Leave a comment

New project: the GNUstep developer guide

I discovered by searching the interwebs that a significant number of people who try out GNUstep get stuck at the “I wanted to do Objective-C on my Linux so I installed GNUstep…now what?” stage. There are some tutorials for GNUstep around, but they’re not necessarily easy to find, and not necessarily pitched at beginners. Otherwise, you’re told to look at the Cocoa documentation, and as Xcode’s user interface turned into a combine harvester, Apple moved to Swift, and other changes happened, the relevance of Apple’s documentation to GNUstep has been on the wane for years.

Therefore today I’m launching the GNUstep Developer Guide. It’s not yet pretty, it’s not yet complete, but it is a place to look for GNUstep documentation written for GNUstep programmers. The first guide is up: the introduction to ProjectCenter and GORM.

Let me know if you find it useful!

Posted in gnustep | Leave a comment

This post on semantic versioning reminded me that we’re making a future in which Ubuntu 01.04 will be newer than Ubuntu 99.10.

This is fine.

Posted on by Graham | 1 Comment

The reality is not the abstraction

Remember that the abstractions you built to help you think about problems are there to help. They are not reality, and when you think of them as such they stop helping you, and they hold you back.

You see this problem in the context of software. A programmer creates a software model of a problem, implements a solution in that model, then releases the solution to the modeled problem as a solution to the original problem. Pretty soon, an aspect of the original problem is uncovered that isn’t in the model. Rather than remodeling the problem to encapsulate the new information, though, us programmers will call that an “edge case” that needs special treatment. The solution is now a solution to the model problem, with a little nub expressed as a conditional statement for handling this other case. You do not have to have been working on a project for long before it’s all nubs and no model.

You also see this problem in the context of the development process. Consider the story point, an abstraction that allows comparison of the relative sizes of problems and size of a team in terms of its problem-solving capacity. If you’re like me, you’ve met people who want you deliver more points. You’ve met people who set objectives featuring the number of points delivered. You’ve met people who want to see the earned points accrue on a burn-down. They have allowed the story point to become their reality. It’s not, it’s an abstraction. Stop delivering points, and start solving problems.

Posted in Business | Leave a comment