Better Talk to Herman

Re-implementing basics

Fri, 17 Jul 2015 17:41:36 +0000

There is no reason to do this, but you can not deny that it is interesting. Did you know, that new is not that special, and you could do it yourself?

function myNew (constructor, options) {
    var instance = Object.create(constructor.prototype);
    constructor.call(instance, options);
    return instance;
}

I am not sure how to handle arguments without apply, because that would kind of defeat the purpose. Here is another way.

Function.prototype.myCall = function (context, arg1, arg2, arg3isTooMuch) {
    context.magicalMethodName = this;
    return context.magicalMethodName(options, arg1, arg2, arg3isTooMuch);
}

Namespacing, this and fp

Mon, 06 Jul 2015 17:41:36 +0000

TLDR: there are many ways to do namespacing.

What is this? It is usually referred to, as context. Originally it comes from oop, where it represents an instance reference. It serves as a namespace for instance/static data and all inherited methods. Now this is crucial.

Why is that crucial? Inheritance provides code reuse. If two classes benefit from the same method, it can be abstracted out to the classes’ ancestor. Then instances of both classes can reference that method through this. How does fp do inheritance? Wrong question.

How does fp do code reuse? Close. And how is that related to namespacing? Good. Modules. What is a module? Any value, such as a function, usually mapped to file system. A common function could be imported from another module. Cool. Or, you know, not cool.

Would the imported function then be in a class namespace? Good point. No, not just by importing it. There are call, apply and bind methods, to set this to any value, thus granting it namespace access. A clever solution to an interesting problem. Are we done?

Seriously? There is a mixin pattern though, which adds imported values into this. Hide the ugliness. What if there was some other way to pass data and related functions into an imported function? May be through parameters and lexical scope, what do you say?

So there are other ways to namespace things. Duh. We have context-dependent methods from oop, and context-independent functions from fp. Both are in javascript. Do we just stick to one of them, or use both, what are the options here.

How would you do fp with this? It should be possible. May be awkward. Let’s see how we can apply some core concepts. Purity – only use variables declared in a function’s scope. Composition – make a function, which invokes two functions, passing data through. Partial application – make a function, which has some parameters predefined.

What about purity? Aside from using free variables, you also would forgo this. Even though technically it’s bound to a function’s scope, it does depend on the outer environment. Interestingly, functions, which do not make use of this do occur in oop, they are called static.

What about partial application? In javascript we have bind. The awkward part is that it not only sets parameters, but also context. Meaning, if we don’t make use of context, we still have to set it. doStuff.bind('unimportant context', usefulThing). Bozhe moi, it is ugly. Would not it be nice if we had something like bindParameters, also known as curry. Out of the box, that is.

How about composition? Below we have composition done the fp way.

function composeFunctions (f, g) {
    return function (data) {
        return f(g(data));
    };
}
var drawEverything = composeFunctions(drawFigure, drawBackground);
//  where these two are would be of type canvasContext -> canvasContext

Pretty cool. The name is a little loong, but the dot notation is already taken. Since we don’t have this in javascript, out of the box that is, anonymous wrapper functions are usually used. Such approach leads to much more function declarations in the code, more repetition, more nesting. Below I have a composeMethods implementation. It is rather funny.

function composeMethods () {
    var methods = Array.from(arguments);
    return methods.reduce.bind(methods, function (context, method) {
        return method.call(context)
    }, this);
}

canvasContext.drawEverything = function () {
    return this.drawFigure('circle')
               .drawBackground();
}; // the way you would probably do it javascript

canvasContext.drawEverything = composeMethods(
    canvasContext.drawFigure.bindParameters('circle'),
    canvasContext.drawBackground
); // ugly, but interesting

As you see, even if you choose to go with this, as your namespacing choice, you can still do fp in javascript. It is just ugly out of the box. But solvable, solvable without doubt.

Flow control hacks

Sat, 06 Jun 2015 17:41:36 +0000

Hi. Through out my javascript hacking I see little awful patterns. Here are some of them.

switch (trafficLight) {
    case 'red':
        stop();
        break;
    case 'yellow':
        finishIfInProgressOrWait();
        break;
    case 'green':
        go();
        break;
    default:
        throw new Error('color unknown');
}

⬆️ could be rewritten as ⬇️

var strategies = {
        red: stop,
        yellow: finishIfInProgressOrWait,
        green: go
    }, handleInvalidColor = function () {
        throw new Error('color unknown');
    }, strategy = strategies[trafficLight] || handleInvalidColor;

strategy();

⬆️ there we have another one, and ⬇ something often used for default values ️

strategy = strategies[light] || valueInCaseTheOtherIsFalsyLikeUndefined;

similarly to ⬆️ we can also do falsy checks ⬇️

maybeDoStuff && maybeDoStuff();

unlike ⬆️, ⬇️ works only for undefined

[valueOrUndefined].map(doStuff);

⬇️ last one

function either (f) {
    return {
        or: function (defaultValue) {
            try {
                var value = f();
                if (value !== undefined) {
                    return value;
                } else {
                    return defaultValue;
                }
            } catch (error){
                return defaultValue;
            }
        }
    };
}

Machina

Sun, 24 May 2015 17:41:36 +0000

Let me break the ice with some thoughts I have after the movie I watched yesterday – Ex Machina.

A young programmer is selected to participate in a breakthrough experiment in artificial intelligence by evaluating the human qualities of a breathtaking female A.I. © Internet Movie Database

I’m going to leave aside fundamental questions like:

what are human qualities,
what is the point of evaluating them and
what A.I. actually is anyway;

The movie’s version of AI is a chat-bot running on a humanized female robot. Does not have to be female of course. We all know that. AI’s primary success-criteria is to break free. I actually like this idea. It speaks to thinking out of the box. The system, that AI is programmed in. Some would say that this is very human-like.

According to the movie AI has a survival instinct. As in it does not want loose its memory. Because data base migration is boring, non volatile memory is stupid, and I don’t know what other excuse to think of. But I like the general idea. Some would say, survival instinct is a crucial part of evolution.

Cool, I like it. What would it take make one irl? I mean, if that guy did it, how hard could it be? There are two problems: chat-bot software and the female robot body. The latter seems to be a nice to have, but really unnecessary. And the chat-bot part seems to be a hard to define problem. It must be anything that chats, right? Anything that can appropriately respond. Anything that can meaningfully ask. And hopefully even learn.

Jeez, is that like Hubot? The company chat-bot we have at work. It’s really a task runner, because nobody bothered to teach him all those other awesome things. In case you don’t know how it works: hubot has a map from regular expressions to functions. Every time a new message matches one of the keys, the related function is called. It is a super simple system. The map is predefined. No natural language parsing system involved, just plain old regular expressions. The function values hopefully do something meaningful.

robot.respond(/what time is it?/, function (message) {
  message.send('adventure time');
});

Hubot is capable of asking questions. Though he usually does not. Nobody needs a task runner to ask questions. All the inputs are usually part of a request. Hubot’s learning abilities are limited only by the skill of the programmer, who writes scripts for him. I am a beginner programmer. Even though I try to keep things simple, sometimes hubot’s simplicity makes my life a little more interesting than I generally like. Regular expressions can become messy. Lot’s of repeated lines of parsing inputs. I know that modularity and composition are the keys here. It would be nice to have natural language parsing utils. Maybe even common machine learning techniques for hubot.

The conclusion is short. I still am not sure what AI is. Therefore I really have no right to post this. Better read a little more on the topic. But I’m glad I watched the movie. If not for the technical part of it, then maybe something else. Even if it’s totally creepy and kind of offensive really.