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:
- The source code can be turned into an abstract syntax tree, in case of C++ libclang can be used for that with little effort.
- The AST can then be fed into a neural network. A library like cuDNN can be used to build such network.
- Github is a trove of source code, which can be used to train the network.
- 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.
- 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?
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.
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!
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:
- 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.
- 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.
- 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!
There are two main directions of evolution for mobile devices: sensors and form factor.
While there’s been some development in sensor technology, there’s still a lot of possibilities, so I’m looking forward to seeing a startup making advances in this direction.
Pocket mobile devices are quite popular, but the era of wearable computing is yet to come. Wrist devices seem promising. The current wave of smartwatches has not scratched the surface yet. Apple and other manufacturers completely don’t get it, so one day some company will come and create the perfect wrist computer.
Below is a breakdown of what an actually useful wrist computer could do.
A computer-like backlit mini-panel is a joke. It consumes a lot of energy, so it must be turned off when you’re not looking to save battery. The solution is obvious – take a look at Kindle. Current Kindle screens are slow to refresh, but they consume very little power and are readable in every lighting conditions, including bright sunlight and darkness. The optional backlight in a wrist device could be automatic and conditional on day/night as well as the “look at me” gesture (like in current smartwatches).
I am supposed to charge a smartwatch… every day? That is the biggest joke. That is not the direction this technology should be going in. Solar batteries and kinetic charging has been around for 30 years and more. It’s time these technologies are leveraged in wearable devices.
A touchscreen on a watch-sized computer, however useful and necessary, is really too small for most things, esp. typing. The input of such computer should be primarily based on voice recognition. Regardless of whether it can just listen-in for your commands or whether you need to press a button (and it should be ready within milliseconds), the input should be prefiltered and it should be able to tune-in to the owner’s voice, so that it is usable even in loud or public places, and does not accept commands from other people.
As for the actual speech recognition, solutions like SoundHound promise the future where you can say anything to your computer, and it will understand you.
Hardened and waterproof
When the device does not need to be charged (or can optionally be charged wirelessly) and does not have any buttons, it could potentially be made waterproof. The main challenge for making it waterproof would still be the microphone and speaker.
Connectivity and apps
You can expect these from any kind of computer these days. You need all sorts of notifications around the clock and you need the ability to call people and see them at the same time. The main challenge here lies in energy consumption.
Lots of sensors
Finally, there are lots of useful sensors that could make this kind of device a really useful companion:
- GPS, accelerometer, gyroscope, compass – nothing new here, you can expect these types of sensors in every mobile device these days. They can tell you your location on demand, figure out what you’re doing with the device (or with your hand), etc. I’m looking forward to the ability of using GPS without active connection, a feature of which the mobile Google Maps app has apparently forgotten, or maybe they can’t do that due to patents (all hail the patent law!).
- Temperature, pressure and humidity – it would be useful if your watch could tell you these.
- Heart rate and blood pressure – if you are in pursuit of healthy living, you need to know these.
- Spectrometer – if you go to a restaurant, you want to know if the fish you’ve been served has been poisoned with heavy metals. Even though spectrometers are still a feat of extraterrestrial rovers, someday they will revolutionize the way we do shopping and help us avoid unhealthy substances served to us by the food industry.
So would you wait for a wrist computer which is useful and not tedious, or can the coolness of the Apple Watch or an Apple Watch-like smartwatches lure you?
If you ever wrote any code which used floating point numbers, you are probably aware, that the widespread floating point format, also known as IEEE-754, is full of caveats.
Due to the representation used, floating point computations are usually unstable. The errors of certain operations grow rapidly, operations are order-dependent and you can obtain different results on different architectures.
Here is an incredibly promising proposal of unum, a number format which improves the current floating point format in all areas: John Gustafson Explains Energy Efficient Unum Computing.
There are many areas, where this could provide improvements, not only in the quality of programs, but also in energy efficiency.
Another example are statically typed languages, where an elaborate type system leads to headaches. With unum, this would no longer be a problem, and the type system could be simplified, especially because unums can be represented with a variable number of bits (although do not have to). Integer calculations can be carried as fast with unum as they can be carried out in regular 2’s complement representation. And at the same time, unums support floating point numbers.
Will unum prove to be useful and become widespread? I certainly hope so.
By popular request, I just uploaded the full WinAPI Wrapper library source code on GitHub.
This library is a very thin C++ wrapper for the Win32 API, which is a C API. The overhead of the wrapper is almost none.
The last modifications to this source originate from 2003. The development seized around that timeframe. I haven’t done any development on/for Windows for many years now, I rarely fire up Windows these days. The library can still be used for writing a wide range of apps, although I imagine that the Win32 API has evolved since and the library could benefit from some adjustments.
Whether I will maintain it further remains to be seen. 🙂