Tuesday, 31 December 2013


Last month I watched an entertaining BBC documentary about Computer Security, Defeating the Hackers. It deals with several common topics like the threat to security posed by Quantum Computers, and the solution provided by Quantum Cryptography. It also mentions a new concept to me, Ultra Paranoid Computing (well, it seems quite new to everyone, as there's no wikipedia entry), bringing up the idea of using passwords that we are not aware of and as such we can not reveal. This other post explains it a bit more, but above all, the most interesting part to me of the documentary is the section dealing with the Stuxnet worm. Well, indeed, being a computing and history/social issues freak as I am, it felt like quite embarrassing to me being absolutely unaware of such a "bomb". So far I think it's the most important CyberAttack ever done, and it gives me the creeps to think how these things can evolve in the future (ok, admittedly this time the output of the attack seems pretty good, Iran's nuclear program being damaged and delayed, but bearing in mind that the perpetrators were 2 ultra-nationalist governments: USA and Israel, I'm quite sure they could launch the attack against any other less "evil" target at any moment, just to ensure their "supremacy" and their role of "policemen of the planet". This paragraph in wikipedia is quite unsettling

Sandro Gaycken from the Free University Berlin argued that the attack on Iran was a ruse to distract from Stuxnet's real purpose. According to him, its broad dissemination in more than 100,000 industrial plants worldwide suggests a field test of a cyber weapon in different security cultures, testing their preparedness, resilience, and reactions, all highly valuable information for a cyberwar unit.

Last week I stumbled upon another related documentary (indeed, even more interesting), produced by Spanish public TV (unfortunately it's only in Spanish). En Portada has been producing some excellent documentaries for many years (for example the one from a few months ago about the fascist Greek party (paramilitary unit) "Golden Dawn" was outstanding), which is something really praiseworthy in a place where 99% of the TV production is stinky crap that is direct responsible for the illiteracy, passivity and amorality (or just plain degeneration) of a whole society. This program deals again with the Stuxnet case, and also mentions some other examples of cyberwar, like the attacks on Estonia (this was well known to me), and 2 cases where cyberwar was combined with "traditional" war: an Israeli attack on Syria in 2007 and a Russian attack on Georgia in 2008.
There's also some interesting info about the Bahnhof service provider. This program is previous to all the NSA surveillance scandal, so they do not mention how in the last months many organizations are starting to look at European companies to store their data to the detriment of USA ones, now seen with huge suspicion. I hope this trend continues on and it means some boom for European Data Centers and IT professionals.

Related to Security, some weeks ago Martin Fowler came up with a brilliant concept, Data Austerity , pretty interesting food for brain in these times of "Big Data coolness" everywhere.

Tuesday, 24 December 2013

Some Thoughts on C# 6

I'm a Programming Languages freak. Though I've never been into compilers programming, I've ever had an enormous interest in their input, languages (and even their output, MSIL and so on). This explains why I follow with much attention the development of ES6, Java 8, anything related to Groovy... and I've been quite upset by the lack of news regarding C# 6.

Hopefully, this summer we got some information from the very Anders. There he mainly highlighted the importance of Roslyn, how the next C# will come with the new managed C# compiler (as a service), and how this will allow for further development of the language in the future. I quite like what he mentions about his work on TypeScript making him more appreciative of Dynamic features (I'd like to see the astonishing dynamic features added to C# in v.4 getting some more love in the near future)

Last week some more news about probable new features in C# 6 were released on the web. Well, quite a bunch of things, but in first instance I felt a bit disappointed.
The one I'm mostly interested in is that they call (oddly enough) "Monadic null checking" and that is just the equivalent to Groovy's Safe Navigation Operator. I've really missed this feature so many times that I even wrote a sort of workaround for it both for C# and JavaScript.
On second thought, I'll say that Read Only Autoproperties and Property Expressions seem also rather appealing to me, but anyhow, as some people mention in the comments, these are mainly cosmetic/wrist friendly additions, but nothing involving any real change. Some people mention that if you want a really modern language for the CLR, you should switch to F#. I don't like the idea, though multiparadigm, F# favors Functional Programming over OOP, so it involves a sort of paradigm shift that I haven't done yet (I'm used and rather keen of the soft functional features in JavaScript and C#, but I really need to devote some time to understand the advantages of a more purely functional approach).

All this has made me think about what features I would add to a modern language like C# (or Java 8), and well, indeed, there are not so many. C# is (for the most part) a mainly statically typed language, so some of the things I love in JavaScript (or Groovy) can't easily be applied/used (I'm referring to expanding classes or instances with new methods or altering the inheritance chain). Also, I'm not sure to what extent Python's metaclasses (little to do with Groovy's ones) could be used. Anyway, after some pondering, I've come up with this (wish) list:

  • Some kind of Multiple Inheritance of Behaviour, like the one enabled by Java 8 with its Default Interface Implementation. Scala traits seem even more powerful, so they would be more than welcome (and would probably involve just some more compiler magic, but no IL changes).
  • When writing this post, I realized that Iterators (Generators in normal Programming Languages parlor) could gain some more power (send, throw, close, delegated yield).
  • Some more investment in the DLR and dynamic. Not sure if at this point (where Lightweight Code Generation has been superseded by Expression Trees in most cases) extending the access to the IL code could get us any benefits.
  • Allow Attributes (Annotations in the Java world) to receive delegates (lambdas) as parameters. This is possible in Groovy land, but in C# all you're left with is an error prone hack.

In terms of the CLR, I think Microsoft have got it quite wrong with TypeScript. They've decided to follow that (to my mind utterly stupid) trend of avoiding JavaScript and writing something that compiles to it. Sure JavaScript is riddled with some quirks and gotchas, but it's one of the most powerful languages ever designed, and what we need is speeding up the development and adoption of ES6, as it fixes many of those problems. So, what I'd like to see is a modern JavaScript engine for the CLR (something like Oracle's Nashorn).

Saturday, 14 December 2013

Fun with ES6 proxies

Proxies have been (and still are) a long awaited addition to JavaScript. Finally it seems like they'll be one more weapon of the ES6 arsenal. Though I remember having read information about them a few years ago, they're so new that only Firefox (always miles ahead of any other browser in terms of JavaScript innovation) implements them. You'll read that you can enable them in node.js with the --harmony-proxies argument, but that's an implementation of the old Proxy specification (Harmony Proxies: Proxy.create...) that is obsolete and has been superseded by Direct Proxies.

Ever that I've used proxies in other languages it's been for method interception, so when reading the documentation my attention was mainly drawn to the get and apply traps. It seems interesting to me that they enable 2 different approaches for the same purpose.

Let's say you have an object with just one method, something like this

var cat = {
	name: "Kitty",
	sayHiTo: function _sayHiTo(subject){
		return "Hi, " + subject + " my name is " + this.name;

and you want to intercept calls to its sayHiTo method. You can wrap your cat object in a Proxy and use a get trap, so that when the method is requested (got) you return the wrapping function:

var proxiedCat = Proxy(cat, {
	get: function(target, name, receiver){
		return function(subject){
			console.log("intercepting call to method " + name + " in cat " + target.name);
			return target[name](subject);

Notice that target is the object being proxied, name is the property being requested, and receiver is the proxy itself.

We can use a different approach for this, just wrap the sayHiTo function in a Proxy and use the apply trap.

cat.sayHiTo = Proxy(cat.sayHiTo, {
	apply: function(target, thisArg, args){
		console.log("intercepting call to " + target.name + " in cat " + thisArg.name );
		return target.apply(thisArg, args);

With the first approach you would be intercepting calls to any method in the class, so the thing seems clear to me, if you want to intercept all methods (or want to use any other trap besides get), this is the way to go. On the contrary, if you just need to intercept one (or a few) specific methods, using the second approach seems more appropriate.

The thing is that we've been intercepting (or decorating) function calls for years, just by doing something like this:

function formatString(st){
	return "X" + st + "X";
console.log("formatString.name: " + formatString.name);

formatString = (function(){
	var target = formatString;
	return function formatString(st){ //notice that I'm naming the function expression, so that function.name continues to return "formatString"
		console.log("intercepting call to " + target.name);
		return target(st);
console.log("formatString.name: " + formatString.name); //returns formatString

so one could wonder if there's any advantage in using "function proxies" (I mean wrapping a function in a proxy with just an apply trap:

duplicateString = Proxy(duplicateString, {
	apply: function (target, thisArg, args){
		console.log("intercepting call to " + target.name);
		return target.apply(thisArg, args);
console.log("duplicateString.name: " + duplicateString.name); 

well, the functionality is the same, so the only advantage that I can see is that the code is more semantic (the Proxy call clearly indicates that you are intercepting that function).

One very interesting point with ES6 proxies is that they try to be as transparent as possible. For example an instanceof of a proxy, or a myProxy.constructor, will work just as if we were applying it to the the proxied object (target). Also, if we proxy a function, myProxyFunction.name will return the name of the target function. This makes me wonder if there's anyway to know if a given object is a normal object or a proxy around it. So far, I haven't found a way to distinguish them.

You can see some code here, and run it from here (in Firefox+Firebug)

By the way, time ago I uploaded a small interception library to github based on the old approach.

Friday, 6 December 2013

One more Programming Mashup

It's been a while since my last "list of interesting programming stuff" kind of entry, so here it goes a new installment.

  • JavaScript is already very well packed with reflective features: Introspection, Object Expansion, Runtime Code Evaluation (eval is not evil), so it called my attention to find Reflect API planned for ES6. As the document says, it does not provide new functionality, but is a convenient way to place this already existing functionality (I've always considered Object as an odd location for functions like: freeze, seal, getOwnPropertyDescriptor). It's also interesting to see how nicely it plays with proxies.
  • Talking of proxies, it's clear that it's one of the hottest and more expected additions to JavaScript, and we'll see all sort of interesting uses of it, one that I pretty much like is this one, adding negative indexes to arrays. If you take a look at the code you'll see it's just a couple of lines!
  • I pretty much like the usage (and the code) for this Dependency Injection library for JavaScript
  • With my love for Prototype based languages, I've never been much keen to use any of the many class emulation libraries for JavaScript, and indeed I don't like the idea of adding Classes syntactic sugar (internally it'll continue to be based on prototypes chains) to ES6. But when one comes across so many discussions about different approaches to inheritance, with names like "parasitic inheritance":
    • http://www.benlakey.com/2013/05/javascript-prototypal-inheritance-done.html
    • http://helephant.com/2009/08/17/javascript-prototype-chaining/
    • http://stackoverflow.com/questions/7250423/javascript-parasitic-inheritance?rq=1
    • http://javascriptissexy.com/oop-in-javascript-what-you-need-to-know/http://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical?lq=1
    • http://stackoverflow.com/questions/16929353/parasitic-combination-inheritance-in-professional-javascript-for-web-developer
    • http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/">
    one can end up changing his mind and thinking that the homogeneity that the class construct will bring to most developments, can be indeed a promising prospective.
  • I've found interesting this entry about how a bad design it is when a class requires its inheritors to call some of the parent methods. There's no way to force that an inheritor will do that, so if he skips that call, this new Child class will be wrong. As the article mentions, we should change the design to use the Template Method Pattern (one of my favorite ones)
  • I've always felt quite happy using normal objects when I need a Dictionary in JavaScript, so this post has been a real eye opener.