Be careful with nl(module_name).

Just FYI.

Erlang shell command nl(module_name), as well as (obviously) c:nl/1 uses rpc:eval_everywhere/3 and code:load_binary/3, i.e. it loads the module code from local node on the entire cluster.

That's not even documented. Until I took a look at OTP sources, I assumed that it is just a networked version of l(module_name).

So, when you try to test new code on a couple of nodes in production cluster, putting the modules on them and invoking nl(module_name) in hope that it'll just reload the old code on the rest of the nodes, you'll find that you have the entire cluster updated. Good for you if your code isn't buggy.

Erlang could be much better, in fact

Since joining Yandex as an Erlang programmer couple of months ago I've developed strange attitude to the language and its framework. While being almost perfect language, Erlang has a couple of things that drive me mad.

First is the lack of return statement. Almost every sequence in which steps depend on previous data results in the terrific indent-ladder of nested case statements in which you go deeper with the usual order of things and then back to column 0 with error clauses and 'end's. Why, for God's sake, I'm not able to write all that in sequential, non-spaghetti manner, returning from function on errors? Return statement doesn't break the rule that everything should evaluate, and Erlang is not a purely functional language for it to be a blasphemy.

Then, dynamic typing in couple with non-informative exceptions is awful. I've spent enormous amount of time trying to find out where that goddamn 'badmatch' occurs and, more important, who generated the bad data. Exception contains only the data to be matched and not the pattern itself, and call stack knows nothing about message passing and OTP. Let alone record syntax in exceptions. Real, real pain in the ass.

Speaking about message passing: generally, there's no possibility to trace a message to receiving process or backwards, you can't even determine a caller function in gen_server:call handler without lots of black magic. I understand that a philosophy of Erlang states that it doesn't matter who send the message, but why they make that philosophy into religion?

After all, I really love Erlang. It is a wonderful language with a wonderful community, and I think that all of its problems are mainly because it was initially developed deep inside Ericsson without public feedback. I'm providing one now, actually.

Using console in development

Today I had a discussion with my friend on usage of console during the development process. He excels in Java, and just can't get the idea behind the Erlang/Python/Haskell-style console, in which you can evaluate language terms. He uses Python as calculator, and that's all. Main argument is, "why you should need that? If you want to run your program, write a shell script that will execute it in any way you wish. For testing there are unit tests and special frameworks. Console is just too awkward."

I find it pretty useful to hit "Run" button in IDE and to be able to test my (small) code pieces by simply calling them with any arguments I like. IMO unit tests aren't so convenient at very early stages of development, especially when you're writing small program without detailed project documentation and all that enterprise-level stuff. Or if your function is non-deterministic, i.e. uses something like random number generation? In this case console is just simpler, as it allows you to examine the output by yourself and quickly decide whether it is correct or not.

Then, you can use console to perform one-time tasks without including their code in your project. For example, imagine you wrote Erlang function that fills Mnesia table with data, executed it and found that it has a bug and the data is wrong. What should you do? Of course, write "mnesia:clear_table(something)." in console, hit return, fix your function and execute it again. Without console you'll write some ugly one-time function or script just to delete it after a couple of minutes.

I don't try to convince somebody that console is completely essential and I can't live without it, but it's definitely very useful thing that simplifies a lot of tasks.

Learning and SCM

Don't even try to learn new programming language and keep your code in public SCM system like Google Code.

It would be complete SHAME - to know that your obviously BAD code is available somewhere in public place.

And yes, I started dancing with Erlang.

Linux isn't that bad

Seems that Linux has finally became somehow usable.

FYI, some years ago I was pretty enthusiastic about it. All those FSF's "freedom" ideas sounded reasonable, juggling software bits was still interesting, and I spent endless nights compiling LFS. But then I became older, and after trying for three days to make my laptop's WLAN adapter work, I abandoned that, I thought, piece of shit. Then I've read a few holywar threads, saw feet-eating Stallman, and completely decided that I hate Linux.

Now I installed Ubuntu Netbook Remix on my FS Amilo Mini Ui 3520, and guess what? It not as bad as I thought! Optimized user interface perfectly fits small screen, performance is much better than XP or (good hackintosh, of course) Mac OS X, and software pieces are well integrated into each other.

But of course, there is a lot of what I call "OSS plague", consequences of low coordination. Dependency graph is overcomplicated, and every program (even specific kernel parts) in distribution has its own developers, maintainers and testers. Because of that, a lot of rough places emerge when it comes to programs interaction. For example, Karmic installer asks for my keyboard layout, I choose Russian, and after starting installed system I see THREE layouts in two groups: US and US,RU. Alt+Shift switches between all of them, and there is no indicator in the taskbar.

Seen all that, I think that for now Linux made GIANT leap towards usability, but, as always, it won't last over the next tech progress turn. Of course, unless somebody will fork all projects and start to develop entire system in single well-coordinated company.

Hey, Google, we're looking at you!