khi’s life with an ech

I did mistakes (I mean I discover some new ones).
I implemented programming tools, some of them far too quickly to provide them a good architecture. At this time, I only needed few functionalities, but as requests came I implemented some quick-fix/quick-adds. And now, even if we don’t planned to use those tools any further, I have to maintain those becomed-crappy-tools!
Too conclusions, choose one depending of your mood:

• Don’t do anything before to be requested to do so; don’t provide tools, keep it secret.
• Never implement software without specifications and stay humble: never never never do quick design before to be a expert/guru/grand-master/programming-giant/computer-god!

It took a long time to decide to learn Erlang instead of Haskell or OCaml/F#. What I really want to learn for now are the OTP principles of distributed application. So I wrote my first Erlang script (not yet an application) and it confirmed my point of view: Erlang make easy the development of distributed program! really!!!

At my work we needed to test performance of a TCP server (and we’ll used Grinder because most of our API is Python). I’ve decided to use Erlang to do the same thing as an exercise: grind.erl (of course it will never become neither as huge as Grinder neither as efficient as Tsung; I even do not hope it can be usefull). But with few lines of code, I was able to reproduce the same behavior as Grinder: launch on multiple machine multiple tester agents executing some test function and gather the results of all the tests.

Ok, I did not told all the truth: that’s not a very small number of lines: arround 260 (with tests and all). But all the code is for running multiple time a test function and gathering some statistics on its result (run_task). Distributed this behaviour among multiple Erlang node is only a map call (distribute_task)!

Here is a code extract:

distribute_task(NodeLst, Task) ->
    NodeLstLen = length(NodeLst),
    StatListener = spawn(grind, statistic_gathering, [now(), NodeLstLen]),
    io:format(
        "~w create statistic gathering process ~w on node ~w~n",
        [self(), StatListener, node()]
    ),
    TaskRunnerCreator = fun(Node) -> spawn(
        Node,
        grind,
        run_task,
        [StatListener, Task]
    ) end,
    Runners = lists:map(TaskRunnerCreator, NodeLst),
    io:format(
        "~w create a list of task runners: ~w~n",
        [self(), Runners]
    ),
    Runners.

And here is a usage example:

grind:init([node(), grinderl@node.net]).
grind:distribute_task(
        [node(), grinderl@node.net], % use 2 nodes
        {
            % on each node run the test function in 50 concurrent process
            {concurrent, 50},
            % two statistics to gather
            [{mean, writetime}, % a real value (mean, std. dev., min, max, med will be retrieved
             {count, writer_val} % a occurence counter
            ],
            % foo function to test: must return a tuple {ok|error, Pid, ValLst}
            fun(Writer, WritenValue) ->
                FWrite = fun() -> io:format("~s got ~w~n", [Writer, WritenValue]) end,
                {WriteTime, _Res} = timeit(FWrite),
                {ok, self(), [WriteTime, {Writer, WritenValue}]}
            end,
            % arguments to used for each call of the test function
            [{rr, ["bea", "pouf"]}, % first is taken in the list with a round-robin style
             {choice, [0, 1, 12, 42, 77]} % second argument is randomly choosen from the list
            ]
        }
    )

This first steps was to become more familiar with Erlang language. My next steps will be:

• use edoc …
• use logger/trace services instead of printing every function call
• use generic services (gen_event, gen_server)
• create an OTP application (application, supervisor)
• use Mnesia to gather statistics
• what about OTP release
• embed everything in distribution package (automake/autoconf ?)

Oh no! I will become a real nerd if I continue to laugh at those stupid (and so gr8) jokes!
http://xkcd.com/c184.html
Only one excuse: I used to work in 3D computer graphics field …

Zune: an iPod-like with Wi-Fi!
… but I don’t like all the marketing stategy behind those products 😦
Any iTux project?

Since I read this post from Joel Spolsky about Sonos, I cannot wait anymore to get such a cool wireless distributed system everywhere in my house … but I will try to wait a bit more for two reasons: first my house is too small :), second I would like the same kind of system but also including video.

(from the humor archives)

This blog has moved here and this post can be found at http://blog.khigia.net/wp-import/general/2006/11/02/what-is-my-next-programming-language.html

… This is a personal message address to me in future …

What is my next programming language?

Scala , F# , Haskell , OCaml or Erlang?

Yes, my next language will be functional, and I will focus on improving my skills in concurrent programming and distributed applications. And here come the reasons for the choice of the above shortlisted languages:

• I just experimented the threading system of Python … that really not fair guys, so I quit Python!
• Scala use the Java threading model, that’s good as far as I know (and Scala looks fine!);
• F# enable to use all .NET library so I could experimented Tao on Mono (.NET threading is also good, IronPython rocks);
• Haskell is pure … I’m curious to understand those mysterious monads;
• OCaml mixes functional and imperative … really efficient and yet simple;
• Erlang embed asynchronous model inside the language … concurrent and yet simple.

Why concurrent programming? Why distributed?

Nowadays computers aim to solve complex systems: large amount of data to process, large number of interactions, or naturally distributed systems. Parrallelism and distribution seems to be in the pipeline with multi-core processors and clusters supported onto a network more and more efficient (optic-fiber at home by example). Without looking at language theory (see Future of software design?), my next language has to enable a software design with those intrinsic features: parallelism (data or computing) and distribution.

And why functional?

I don’t really know … for the fun??? I read a lot about Haskell recently; I just want to change my mind with another programming paradigm, and I secretly hope that my functional code will be better optimized on multicore machine. If you want real justification you may have a look at Functional Programming For The Rest of Us or Everything Your Professor Failed to Tell You About Functional Programming.

Final choice of my future language

Still have to choose one in the shortlisted choices, but with which criteria?
Type inference is a must (coz above all, any good programmer has a special quality: he’s lazy). But I don’t see a strong typing as a must-have: it sure solves problem, but not all, and in the end you still rely on unittesting.

Let’s do a first cut in the shortlist based on personal assumption: .NET is a better platform than Java (wow!). So:

• remove Scala: F# offer same kind of possibilities using .NET;
• remove OCaml: shares a common ML-like syntax with F# but F# offer .NET platform access where OCaml offer efficiency.

Haskell is pure but I prefer easy development aiming at concurrent and distributed programming, which is not part of the Haskell language itself. Then I have to choose between Erlang or F#: let’s go for Erlang, let’s concentrate on distributed development embedded in Erlang language. If later I really need/want .NET platform, it will still be good time to review all those choices adding new languages progress!

Thanks to Hanna Wallach for pointed to some articles about autism and mirror neurons .

In the field of agent simulation in a VR world, some AI method give to an agent a representation model of its world where it can simulate approximate behaviors of other agents before to take a decision of its action in its real (virtual) world: simulation of a virtual world inside a virtual world…

But the first time I discovered this idea of “interpreting a model of other” was with Hercule Poirot who try to imitate the person he want to understand, and even some small movements (like the position of hands or the smile…) can help him to “take the place of other”.