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!
We may be on the brink of one of the most important discoveries in our history!
A few days ago the Cassini probe flew only 49km above the surface of Enceladus, the sixth-largest moon of Saturn. Notably, it passed through the cloud of material ejected from Enceladus’ south pole geysers.
So far there is mounting evidence that the white ice-covered moon harbors a global water ocean under the surface. After the data gathered by the probe is sent back to Earth and analyzed in a few weeks, we will know more about the chemical composition of Enceladus’ ocean and be able to assess whether it has conditions suitable for the existence of life.
While Cassini’s instruments are incapable of detecting life forms, the scientists should be able tell whether there is any hydrothermal activity going on, which could be important for sustaining life.
Discovering any form of life on a such a tiny rock (500km in diameter) would indicate that life is common in the Universe.
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.
Do you consider yourself a magical being driven by an invisible soul, or a biomechanical wonder, an incredible system consisting of nanomachinery and water, an organic robot?
If you can provide an unbiased, honest answer, I suspect your answer will be correlated with your belief system.
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. 🙂
As the era of robots is approaching, self-driving cars are a hot topic.
The transition to self-driving cars will be gradual. Initially, cars will be able to drive autonomously only in perfect road conditions, e.g. on the well-marked freeway. Perhaps initially we will have single lanes for self-driving cars, where it will be forbidden for humans to operate the steering wheel, except for critical situations. Eventually robot-only lanes will be expanded to entire sections of roads and freeways. Autonomous vehicles will be much safer and faster on the freeway than human-operated vehicles.
Less developed countries will soon become an excellent testbed for self-driving cars. In many countries, the quality of roads is very low, some roads don’t have lane markings and are full of obstacles. Also, the road laws don’t seem to apply in many countries and are treated by drivers only as guidelines. Driving in these countries is going to be a great challenge for self-driving cars.
Now, here is an idea for a self-driving car feature.
Imagine driving on a winding road with a high speed limit behind a tractor or another slow vehicle. You cannot overtake it, because you cannot see far enough ahead. A self-driving car could be equipped with a drone. When visibility is limited, the car could deploy the drone to check out the conditions ahead. The drone would be continuously sending images and its position back to the car, so the car would know, whether it’s safe to overtake even if there is no visibility. The self-driving car would know, that there are no other cars on the lane in the opposite direction.
The drone could also be equipped with a radar, which would make it useful in foggy conditions. Upon encountering fog, the car would deploy the drone and could keep driving at a high speed, because it would have the image of the road ahead.
The drone’s battery would have a limited capacity, so the drone could only be deployed for a limited time, and would need to return to the car for charging. A more expensive self-driving car could be equipped with two drones. While one drone is in operation, the other drone could be charging.
Ideally, the drones should be cheap and should use a standardized communication protocol as well as support a standardized docking mechanism. It would be common to lose a drone, so it should be cheap to buy a new one, or upgrade it.
The drones would probably be useful to self-driving cars even if all cars were self-driving and communicating with each other, esp. in cases where road visibility is limited and pedestrians or animals are present near the road.