The future of programming

21.11.2016 Leave a comment

In the near future, AI and robots will replace humans in most jobs. Until recently I thought programming would be one of the last jobs where humans would be replaced, but I don’t think so anymore.

AI-based static analysis

AI will soon find its way to help us in everything we do. Today, computer programming has lots of challenges, writing correct and bug-free programs is hard. However, I would not be surprised if there was already a startup developing a new AI-based static analysis tool to aid programmers.

We already have all the technology needed to create such tool for, let’s say, C++, or any other programming language for that matter. Here is how such tool could be crafted:

  1. The source code can be turned into an abstract syntax tree, in case of C++ libclang can be used for that with little effort.
  2. The AST can then be fed into a neural network. A library like cuDNN can be used to build such network.
  3. Github is a trove of source code, which can be used to train the network.
  4. The real innovation and the main challenge is annotating the source code with issues which the network should detect. Initially, this could be done using existing static and dynamic analysis tools, like Coverity, valgrind or sanitizers.
  5. The output from the neural network would just highlight issues in the source code.

The tool could be available from the command line and it could be integrated with IDEs.


The static analysis tool described above could be further improved in several ways.

If fed with a single function as input, the tool would produce output only relevant to that function. When more context was given, e.g. a file or an entire program, the tool would detect more types of issues.

It would be easy to extend it to accept AST for more programming languages. Eventually, the neural network would be able to recognize problems in programs written in any programming language.

The output could be enhanced beyond just highlighting errors. The neural network could produce one or several proposed fixes for the problems found. At some point, the tool should also be able to select and apply the fixes automatically.

An even more interesting enhancement would be extensive code refactoring. This would require the tool to recognize problems with the design.

In a more advanced version of the tool, a human programmer would only be writing the outline for the program and our tool would be filling up the functions with code and fixing any issues in the design. Eventually, the “programmer” – actually the user (e.g. grandma), would describe what is needed using words, and the tool would generate the program directly in the machine code form, no intermediate code would be necessary.

In an even more futuristic setting, such tool could also work with an advanced 3D printer, and produce a design of a chip to print for the printer.

Do you think programming as a job for humans has a future?

Categories: Computing

Rvalue references in C++

30.08.2016 Leave a comment

This is a great article by Scott Meyers: Universal References in C++11

It explains what rvalues are in a very clean and concise way. This is the best explanation that I’ve found so far. All the other descriptions of rvalues and rvalue references are detailed, but too complicated…

The main topic of this article is that T&& in C++11 not always indicates an rvalue reference, but sometimes it indicates what he calls a universal reference, which is collapsed by the compiler to either an lvalue reference or rvalue reference, depending on T!

Worth a read, even as a refresher.

Categories: Computing

C type system strikes back

9.06.2016 Leave a comment

Today is one of those days when C++ surprises me. Here is a snippet:

#include <stdint.h>
#include <stdio.h>

int main()
    const int64_t a = 3;
    if (a < -0x80000000)
        printf("%lld is negative\n", a);
    return 0;

This time the surprise comes from the intricacies of the C type system.

Hint: -0x80000000 is mathematically INT_MIN.

In case you’re wondering, it is not about improving the above snippet. It is about actually seeing a piece of code like this in the wild. It looks correct. But it is incorrect.

Categories: Other

git, where am I?

6.05.2016 Leave a comment

git is a great piece of software, it is a marvel of engineering, it is very useful and reliable.

However there is one problem with git, which barely anybody mentions – it has a very unintuitive user interface! After years of using git I still feel like most git users – I have very little idea about what happens when I issue particular git commands.

Aside from its user interface, git works so well, that other version control systems exist only because they are easier to use. For example, bzr is trivial to master if you’ve ever used any other VCS. Mercurial is slightly more complicated, but after a few days of use you can get the gist of it. But git will surprise you even after years of use.

There are two reasons why git is so difficult to master. First, the git nomenclature is confusing. There is a sea of git commands and switches which modify the commands in subtle ways, so it is easy to get lost. For example, git checkout does not do what you would normally expect it to do, if you have experience from other VCSes. git reset is outright confusing and many users can’t distinguish it from git checkout. A branch in git is not really a branch, it is merely a pointer to some revision in the repository, you can conceptually use it as a branch, but you can also move this pointer to any existing revision in the repository.

Secondly, there is very little information about the state of the tree. It is very hard to find information how to see your location in the tree. Where is your HEAD pointing? Where is master pointing? These questions only scratch the surface.

Today, however, I came across the best git command, which makes it much easier to determine where things are:

git log --graph --oneline --decorate --date=relative --all

This command shows a graph of commits, it shows the location of HEAD, branches, etc.

One note is that this command does not show dangling commits, i.e. commits which are not reachable from any branch or tag. Dangling commits are created by moving the HEAD and adding new commits at that location, or by doing git reset –hard. Typical advice to find such commits is to use git reflog, but it is still difficult to extract useful information from it. The easiest way of finding all dangling commits is the following command:

git fsck --lost-found

Now if you want to include a single dangling commit in the graph, you can use git checkout to go to that commit and then display the graph. This makes life with git a little easier!

Categories: Computing

Indentation in Python

15.03.2016 Leave a comment

Python is one of the best designed programming languages. It is very easy to learn and it has very few gotchas (features which work in surprising ways).

There are so many languages younger than Python, which suffer from horrible design mistakes. For example, compared to many other scripting languages, in Python there are no undefined variables; Python does not prefer globals – you have to declare globals explicitly; when you try to read a non-existent object property in Python, you get an exception; Python does not perform type promotion, so it is easy to distinguish between values of different types; the list goes on.

Everything has pros and cons, and so does Python. One of the commonly mentioned issues with Python are indentation-based blocks. It’s a relatively minor issue and even though I’m not a fan of it myself, in my opinion some people make too much fuss about it.

A frequent argument against indentation-based blocks is that they rely on invisible characters, in particular tabs. There are three ways in which it could be solved:

  1. Set your editor to use 8-column tabs. 8-column tabs are the de facto standard, so if anyone complains about Python because their editor is buggy and defaults to any other tab size, it is essentially their own problem.
  2. Set your editor to convert tabs to spaces. Due to buggy editors being so widespread, it never makes sense to use tabs in source code, regardless of which programming language is used.
  3. Last but not least, the problem could be fixed in Python itself, by disallowing tab characters. This is a small oversight on the Python side.

As you can see, this trivial issue could be solved in several ways and there is no reason to complain about Python.

If you know a programming language, which is better designed than Python, please let me know!

Categories: Computing

Learn Polish

1.02.2016 Leave a comment

If you have some spare time and want to learn another language, I recommend Polish. Polish is a lot of fun! For a start, here are a few words in Polish and their meaning in English:


Polish word Meaning in English
no yes
do to
to this
go him
pies dog
much flies
bat whip
paw peacock
but shoe
wanna bath tub
pan mister
baby women
was you (plural)
my we
we on (a day)
on he
one they (women)
ten this one
grab hornbeam
bark shoulder
jest is
fart luck


Categories: Other

New Year’s Resolution

4.01.2016 2 comments

One of my New Year’s resolutions is to keep this blog more active. While my activity has been low during the year 2015, I have not abandoned the blog. I was simply spending most of my free time working on my personal project. In the mean time I’ve gathered several ideas for new posts, it will be great if these posts finally see the daylight this year!

Hopefully my personal project will also reach a publishable state this year. Here’s an interesting detail about this project.

C++ has been the primary programming language for me in my professional career. Over the years, I’ve used many programming paradigms provided by this versatile language. However, to the surprise of many, my new project is currently written in pure C!

Why C? Out of admiration for a coworker, who writes programs in C, which are of high quality, and which are readable, maintainable and extensible. And also as a personal challenge. Writing *good* quality software in C requires more skills than in C++, because the language is much simpler and doesn’t have mechanisms provided by C++, which help avoid certain classes of bugs. To be fair, I’ve seen a lot of bad C++ source code which fails to use these mechanisms, but that’s another story.

So here are my impressions about going back to C so far. First of all, RAII, which is the cornerstone of C++, is not available. This makes cleanup more tedious. Again to be fair, C++98 without lambdas also makes cleanup more tedious by requiring you to write or use classes just for the purpose of cleanup, which makes the code scattered or complicated. Secondly, handling error conditions in C is more tedious. Exceptions in C++ can provide a great way of signaling exceptional errors, if used carefully(!), together with RAII, which makes returning from functions easier without the need to babysit allocated resources. Mildly missed are classes, which can help to logically organize functions, although in many C++ programs they are abused by implementing unnecessary OO designs, which lead to too much boiler plate code and eventually hamper readability. One of the most missed features are container templates, which greatly simplify memory management in C++.

On the bright side, some of the advantages include better portability due to unencumbered linkage. Because the language is so simple, it also leads to simpler code, which can in turn be easier to read, maintain and extend, contingent on the type of program and the way in which it is written, of course!

Surprisingly, it is possible to write readable code in C without drowning it in macros! Many C projects I’ve seen overflow with macros, which impact readability. But this can be said about C++ projects, too.

Now back to the editor. Let us see what the New Year brings!

Categories: Other