Interview question: Which browser do you use?
Big Data says, that employees who use a non-default browser, such as Firefox or Chrome, stay with the job 15% longer than those using a default browser, such as IE or Safari.
Well, if Big Data says it, it must be true!
(There – I finally said it. 😉
Robots are coming!
…to a factory near you. But beware, they are after your job, too! Foxconn, one of the biggest electronics manufacturers, is looking to replace 70% of its human workforce with robots in a couple of years. The fear of robots replacing human workers originates from ca. 1970s, when robots have been introduced on production lines in many industries, but their deployment was expensive and limited. Only now the technology seems to have matured enough for robots to be feasible on a broader scale. If you combine robots with 3D printing, which is another hot area of development, humans will be pretty much redundant in manufacturing soon. I predict that humans will be replaced in most other areas too, from store clerks through medical staff. Think of a job a robot cannot do, and I guarantee robots will eventually be able to do it. Most likely, engineers will be one of the few jobs left to humans, but probably not for long. Some specialized, niche jobs may also be safe for some limited time. This will gradually happen over the next 30 to 50 years. We will soon need a brand new economy, in which humans will not be qualified or will be too expensive to perform any kind of work. Therefore, humans will not earn money, so they will not have money to spend. It is hard to imagine what social turmoil we will be going through. In my opinion, governments should start thinking about how to approach this problem now, when it’s not too late. It is inevitable and there is no way to prevent it. We will have no choice, but to adapt.
Which programming language is the best?
In this fascinating study, the authors analyzed commits on github to see what effect the programming languages have on the number of bugs.
Surprisingly, it does not seem to matter which programming language you choose – you will have the same number of bugs in your code.
The main difference between programming languages is what types of bugs programs written in these languages have. That’s no surprise though, for example while you can leak memory in C++, it’s quite hard to leak in Python.
I suppose what matters is who writes the code, not how? This would explain why it is so hard to find bugs in prof. Donald E. Knuth’s code.
Programming languages are for humans, they are essentially a human interface for compilers. In the future, when programmers are replaced by AI, programming languages will disappear as AI will produce optimal machine byte code and all software will be bug-free.
Women best candidates for Mars
This is a great piece: Women are cheaper to send to Mars than men.
If you think of it, it makes sense. Life support is one of the most expensive elements of any manned space mission. Every kilogram sent to orbit and then away matters. Among things which contribute to the total mass of any space vehicle are not only humans themselves, but also their food and all the equipment necessary to keep them healthy and happy.
Statistically, women are smaller (weigh less) than men and need less food. Given that men and women are equally smart, women seem to be better candidates for deep space missions.
So what next?
The mission to Mars may be the last mission where humans will break the frontiers of space exploration. Given the current rate of AI evolution, I won’t be surprised if sentient machines will be the ones going beyond Mars.
Job interview question idea
I doubt that everybody realizes, that job interviews are for both the company trying to fill in an open position as well as the potential employee trying to find a job. A usually small, but important part of an interview is when the person being interviewed asks the questions.
This idea is for those who have the chance to speak to their potential future manager. How do you know if a particular manager will be right for you?
The question to ask your future manager is: Do you prefer cats or dogs?
The explanation follows.
Dogs are followers, they need their master to tell them want to do, to give them direction. Cats on the other hand are soloists. They do what they want, whenever they want. If they want to be tapped, they come to you.
Of course, this is an approximation, a generalization.
Similarly, there are two groups of employees. Ones which need to be told what to do, and the others, who don’t need and don’t like encouragement, but rather pursue tasks on their own. This is universal regardless of the job type. Obviously, the first kind can be compared to dogs, while the other to cats.
Before going to a job interview, you need to ask yourself honestly, whether you are a follower and need to be told exactly what to do, or whether you like taking complete control over what you are doing. This has nothing to do with whether to like cats or dogs, it is completely orthogonal.
If you are more like a dog, probably a manager who prefers dogs would be better for you. Similarly, if you are more like a cat, a cat-person would manage you better.
It’s just a theory. As silly as it sounds, I wonder if there exists any statistical data which would help test it.
From iOS to Android
My iPod Touch is almost 4 and it’s growing old. I decided to swap it for a cheap Android phone. How did it go? Below are my impressions.
But first, what is an iPod Touch? Well, for all practical purposes, iPod Touch is just an iPhone without the phone. Mine was the first 4th generation device, the first one with retina display. I always thought that the price difference between iPhone and iPod Touch was just too big, it’s just not worth paying the extra bucks for the phone functionality. Plus, it was back in the US where cell phone plans are crazy expensive. Instead, I was always carrying a cheap, old simple phone and using a prepaid SIM card. You have to understand that I don’t use a cell phone too much, on average maybe ~5 times a month. Data plans? I’ve always had WiFi at home and at work.
The iPod Touch has been a great companion for all these years, so to speak.
- It has a great build quality (metal case, Gorilla glass screen).
- The retina display is perfect as the human eye cannot distinguish separate pixels. Everything looks crisp and smooth.
- Obviously it has all the goodness you can expect from a mobile device of this class, including useful apps for e-mail, news, calendar, and much more.
- Obviously there are lots of games for it, useful esp. in a waiting room.
- I could take it everywhere. My notes, my calendar, always at hand.
- I could watch Netflix in bed. And it doubled as an alarm clock.
On the down side:
- I had to carry a separate phone device, for emergencies.
- I sometimes missed the smartphone function, esp. when away from home and without WiFi access – e.g. I couldn’t read news or use maps. Also, it has no GPS.
- It started showing age. It was the last iPod Touch with a single core CPU. So some apps are really slow on it, including the Web browser.
- Only 2 days on a single charge under light use. I do have to give it credit though: after almost four years I still don’t see any battery deterioration.
Finally, my old simple phone’s battery started giving up and I got fed up with my current prepaid plan. When looking for a new cell phone plan, I’ve determined that you can actually get a new phone for free with it.
Now, let me tell you about one of the Europe vs. the US differences. In the US, cell phones really are a rip off. For example, the cheapest plans go for $40 a month. Maybe you can find a $30 one these days if you are lucky. But in Europe, you can really afford it and you don’t regret it. For example, my new plan is £5 a month and it comes with a free Android phone. It is a two-year contract, but hey, it’s only £5 a month! Free family and home calls – my most popular call destinations. Over the course of two years, I expect to pay the same amount I paid for the iPod Touch – and in this price I have a phone service with data, useful occasionally and in emergency situations.
So how does the Android phone stand up against the iPod Touch?
This is the LG D160, also marketed as LG L40.
Let’s get the obvious stuff out of the way:
- It came free with the plan, so no wonder the build quality is relatively worse. It’s made of plastic, both the body and the screen. I don’t expect any good durability.
- While the LG’s physical screen dimensions are the same as in the iPod Touch, the resolution is lower, so the pixels are visible and thus anti-aliasing artifacts etc.
- It’s Android, so I don’t expect to get any updates. I picked the only phone which had the latest Android K (4.4 KitKat). The list of the phones sold notably included much more expensive phones which still have Android G (2.3 Gingerbread). In contrast, my iPod Touch has received two major version updates over the years until Apple gave up on it. I’m still waiting for an Android phone manufacturer to provide updates for a couple of years.
Now, after a few days of use and despite of the above drawbacks, I am actually pleasantly surprised and expecting having a good time with this device, which may successfully replace the four-year old iPod Touch.
- It has a dual core CPU, which outruns the old iPod Touch’s CPU in most cases. For instance, the browser is much snappier. Apps start quicker.
- I installed most, if not all the important apps I used on the iPod Touch. Either the same or equivalent apps are available on Android. Many of the apps synced data without any problems and delivered the same experience out of the box, like the Calendar app, which obviously works with Google Calendar on all kinds of devices. The migration to Android was pain-free.
- Just by trying something new – I learned new stuff. For example, the Stocard app provides support for loyalty/rewards/gift cards, so no need to carry them in the wallet anymore. (This applies to iOS too, I just found it so useful that I thought it’s worth mentioning.)
- While the build quality is poorer and the screen has the same size, this LG phone actually feels better in my hand than the iPod Touch. And even though it’s probably a few grams heavier. I’m not sure yet whether it’s because it’s thicker or shorter, but it is somehow better to hold.
- I don’t know why iOS feels better put together. Maybe it’s because the LG’s screen is pixelated and generally worse, while the iPod Touch’s retina display was smooth and crisp? Maybe it’s something about graphics design and fonts? I’m not sure. Maybe it’s just a matter of getting used to.
- Maybe this goes back to the CPU speed, but the LG’s home screen scroll quality parallels that of iPod Touch’s. The scrolling on many Android phone’s I’ve seen in the past used to be choppy, but on this one it is smooth.
- The drop down control center draggable from the top on Android is much better than equivalent functionality on iOS. For example turning data, WiFi, etc. on/off is super easy.
- I miss notifications on the lock screen like on iOS, where I didn’t have to unlock the device to see the notifications.
- The keyboard and typing were actually better on iOS. Keys were slightly bigger and clearer, the key indicator when pressing keys was better visible. Also switching between alpha/numeric/symbols is slower on Android. I could type faster on iOS. Aside from the fact that typing is something you want to avoid on pocket devices like these.
- I haven’t used the built-in GPS much, but it seems to work. It may come handy one day. iPod Touch didn’t have it.
- I don’t care too much about the quality of the built-in camera, because there is no way a cheap lens and sensor like this can parallel those of aDSLR. But a review wouldn’t be any good if it didn’t mention the camera. So below are the photos taken by the iPod Touch 4 and theLGD160. These photos were taken at the same time, so the lighting conditions were identical and the scene is the same as well. Judge it yourself.
- iPod Touch 4:
- LG D160:
- iPod Touch 4:
Although I am hoping I could replace it with a device of a better build quality at some point, I think I will get a good run out of the LG D160. I would certainly recommend it to a friend who had an old iPod Touch.
OO design and classes in JavaScript
JavaScript is a language which has a lot of crufty syntax, but underneath the cruft it has many useful features.
One of the problems people encounter when coming to JavaScript with experience from other languages, is that there are no classes in JavaScript.
The rest of this post assumes you have basic knowledge of JavaScript.
Here are two basic ways to create objects in JavaScript:
// The most common way - using constructor function
function Point(x, y)
{
this.x = x;
this.y = y;
}
var p = new Point(1, 2);
// Using a create function
function CreatePoint(x, y)
{
return { x: x,
y: y };
}
var p = CreatePoint(1, 2);
This is not exactly object-oriented programming, is it? Let’s say we stick with it, how do we introduce inheritance? JavaScript has prototypal inheritance, which is not how most developers understand inheritance. Let me give you an example:
// The prototype
function Base(a)
{
this.a = a;
this.print = function() {
console.log("a=" + this.a + ", b=" + this.b);
};
}
var proto = new Base(0);
// Usable constructor
function Derived(b)
{
this.b = b;
}
Derived.prototype = proto;
// Classic approach to adding more members to the prototype
Derived.prototype.hello = function() {
console.log("Hello!");
};
var o1 = new Derived(1);
var o2 = new Derived(2);
o1.print(); // prints: a=0, b=1
o2.print(); // prints: a=0, b=2
proto.a = -1;
o1.print(); // prints: a=-1, b=1
o2.print(); // prints: a=-1, b=2
First observation: objects created by the Derived constructor share the same instance of the prototype, not a copy. If the prototype object changes, all objects which use this prototype see these changes.
Second observation: the base “class” is non-customizable from the Derived constructor. We don’t call the Base constructor from the Derived constructor. One workaround would be to add an Init function in the prototype, which would set some members of the object.
Third observation: if we have lots of functions and members in the base “class”, prototypal inheritance can in theory save on memory (the same members are not duplicated across all instances).
Fourth observation: there is no such thing as private properties.
“Real” classes in JavaScript
To the contrary of what most people think, constructors may be used the same way as classes are used in other OO languages.
The key to taking JavaScript to the next level are closures. Closures are variables accessible across functions. When an inner function (defined inside another function) accesses a variable of the outer function, that variable becomes a closure. In JavaScript a very interesting thing happens with closures: they survive the end of the function which declared them and are still usable in the inner functions which access them.
Let’s get on with it: Here is an idiom which lets us create classes in disguise using constructor functions, just like in any other OO language.
// Class (constructor function)
function Rectangle(x1, y1, x2, y2) // Constructor arguments
{
// Private variables
var w = x2 - x1;
var h = y2 - y1;
// Note: reuse arguments as members!
// Public functions
this.getWidth = function() {
return w;
};
this.getHeight = function() {
return h;
};
this.getArea = function() {
return this.getWidth() * this.getHeight();
};
// Accessor
this.getX1 = function {
return x1;
};
}
// Usage
var o = new Rectangle(1, 1, 3, 4);
console.log(o.getArea()); // 6
What about inheritance? Easy:
function Square(x, y, size)
{
// Call base class constructor on this object
Rectangle.apply(this, x, y, x+size, y+size);
// Other Square-specific members follow...
}
var s = new Square(1, 1, 2);
console.log(s.getArea()); // 4
Last but not least, this is a very useful idiom to complete member functions later, handy in user interfaces:
function delay(time, func)
{
window.setInterval(func, time);
}
function SomeObject(x)
{
// Save 'this' for lambdas
var self = this;
var v = x * x;
this.publicV = x * x * x;
this.getValue = function() {
return v;
};
// Private member
var alterValue = function(newx) {
v = newx * newx; // access private variable
self.publicV = newx * newx * newx; // access 'this' via 'self'
};
this.setValues(x1, time, x2) {
alterValue(x1)
delay(time, function() {
// 'this' is bound to something else in a lambda function,
// use self instead
alterValue(x2);
});
};
}
var o = new SomeObject(2);
console.log(o.getValue()); // 4
o.setValues(5, 1000, 6);
console.log(o.getValue()); // 25
// Wait >1 seconds, because after at least one second, the value will change again
delay(2000, function() {
console.log(o.getValue()); // 36
});
Summary
In effect, the above approach works like classes in other object-oriented languages. Arguably, it’s cleaner than a typical prototype-based approach in which one assigns members to a prototype outside of the constructor function – the guts of the object in a typical prototype-based approach are scattered around the source file(s).
I haven’t measured the performance of the above approach versus a prototype-based approach, but my gut feeling is that modern JavaScript engines deal with it comparably well.
Men: Have kids young, or never
You are a male and you think you still have time to have kids? Think twice!
New research suggests that the quality of male sperm deteriorates with ages due to more mutations happening over lifetime. Having children late in your lifetime bears a significant risk of genetic disorders and defects in offspring.
Relying on a roulette in such an important matter is not very wise. So get to work!
Happy birthday, Opportunity
Two weeks ago Opportunity had its 10th birthday. (In case you live under a rock, Opportunity is one of the robots roving Mars.)
In my opinion, this is quite an achievement for humanity. Opportunity should probably be brought to top of the list of the Wonders of the World. Except it’s not on this world…
Imagine a ten-year old car. What are the chances of a car surviving 10 years without any service and without breaking down? Add to that desert conditions (dust) and extreme temperatures (down to -40C at night, up to +40C during the day). Although it’s travelled only 38 km on land, to be fair for the expedition, one should add the distance from Earth, which varies between 54 and 401 million km.
For ten years, nobody has cleaned its solar panels. Let’s hope Opportunity will continue its journey for several more years without sharing the fate of its twin, Spirit, which probably froze to death during one of the Martian winters…
Parsing regular expressions in Haskell (part 1)
If you’ve read my previous posts, you know I’m learning Haskell. But I want to avoid any boring way to learn it – learning anything that is boring is a waste of time. My approach is to read some online resources, do exercises and write real world programs. So far I’ve been mostly reading the Haskell Wikibook, which has some good exercises. I’ve also found some interesting pieces in Real World Haskell, although I haven’t started reading that book yet. Both resources seem to be quite good.
In my previous assignment I’ve written a grep tool in Haskell. I’ve also done some exercises with lists. And I think these steps resulted in a breakthrough for me – I can now write more complex code, which sometimes works out of the box and sometimes I only have to do a few fixes, but I don’t seem to be stuck for good and I don’t have to search for hints to the solution online anymore. The key was understanding that:
- Recursion is an essential programming paradigm in Haskell.
- In conjunction with lists of course, which are the basic tool for writing algorithms.
- Monads are an important tool for achieving more beyond functional programming, and working with monads is different from working with functions.
You can notice that my first programs used more traditional programming, as if they were written in an imperative programming language. But the grep program started looking like a real Haskell program – no loops and even no classic conditionals (well, function overloading is a kind of conditional).
Simple regular expressions
I’ve always wanted to write a parser for regular expressions. Well, this is my opportunity. The nice thing about Haskell is that programs written in this language are quite concise. Once you understand the basics (which is not that easy), Haskell seems much less scary.
I started off with a simplified regular expression. Here is the definition:
- ^ matches the beginning of the string.
- $ matches the end of the string.
- . matches any character
- * indicates that the previous token can be repeated zero or more times (for example a* means that a occurs zero or more times).
- + indicates that the previous token can be repeated one or more times (for example a+ means that a occurs one or more times).
- Any other character in the pattern is treated literally.
My program requires 2 or more arguments on the command line. The first argument is the regular expression (definition above). Further arguments are tested against this regular expression, one by one, and for each of them we print either MATCH: string or just string if the regular expression did not match the string.
For example:
$ runhaskell regex.hs "^ab*c+" "abc" "ac" "bac" "abbcc"
MATCH: abc
MATCH: ac
bac
MATCH: abbcc
Without further ado, here is the source code:
import System.Environment -- for getArgs
main = getArgs >>= mainWithArgs
usage = putStrLn $ "Usage: regex REGEX [string...]"
mainWithArgs [] = usage
mainWithArgs [_] = usage
mainWithArgs (regex:strings) = mapM_ (runRegexAndPrint regex) strings
runRegexAndPrint regex string = if matchRegex regex string
then putStrLn $ "MATCH: " ++ string
else putStrLn $ " " ++ string
matchRegex [] _ = True
matchRegex ['^'] _ = True
matchRegex ['$'] _ = True
matchRegex ('^':rcs) scs = tryMatch rcs scs
matchRegex rcs scs = tryMatch ('.':'*':rcs) scs
tryMatch ['$'] [] = True
tryMatch [] _ = True
tryMatch _ [] = False
tryMatch (rc:'*':rcs) (sc:scs) = if matchSymbol rc sc
then tryMatch (rc:'*':rcs) scs ||
tryMatch rcs scs ||
tryMatch rcs (sc:scs)
else tryMatch rcs (sc:scs)
tryMatch (rc:'+':rcs) (sc:scs) = if matchSymbol rc sc
then tryMatch (rc:'*':rcs) scs ||
tryMatch rcs scs ||
tryMatch rcs (sc:scs)
else False
tryMatch (rc:rcs) (sc:scs) = matchSymbol rc sc && tryMatch rcs scs
matchSymbol '.' _ = True
matchSymbol rc sc = rc == sc
This program again heavily relies on function overloading and list operations (string is a list of characters).
One interesting thing is that + and * handling look very similar. Eventually it would be nice to collapse them into one function, esp. if we were to handle repeat ranges.
The + and * tokens are greedy. Any ideas how to make them non-greedy?
What’s next?
I am not planning to stop here. I’d like to implement things like groups, character ranges, repeat count/ranges, greedy/non-greedy selection, etc. I think a simple approach like above won’t suffice though, these features will require building a regular expression representation (known as compiling the regular expression) and then using that representation on the strings.
Another thing I would expect from a good regular expressions library would be to return found ranges, possibly multiple, so that we could e.g. subscript or highlight them when printing the strings.
One last point – unfortunately WordPress cannot highlight Haskell code, which is a pity. Also pasting pre-formatted source code is tedious.
Chris Dragan's Corner 