Kompetisi, kompetisi

(Berhubung lagi gak mut dan ada kerjaan2x lain, kelewat seminggu deh posting Iron Man. Menurut aturan, seharusnya status ane jadi kertas lagi :-( Ternyata tidak, karena ada posting dari zak. Thanks zak :) )

Tadi barusan baca postingan Sawyer X tentang postingan Adam Kennedy yang berencana mengadu Dancer dan Mojolicious. Exciting banget!

IMO, dari dulu seharusnya komunitas Perl menggelar inisiatif2x kompetisi seperti ini.

Biasanya yang sering terjadi di CPAN adalah kelahiran modul demi modul baru yang merupakan eksperimen atau proyek pribadi milik orang2x berbeda. Kurang suka dengan sebuah modul? Buat saja tandingannya, alternatifnya, versi Anda sendiri. Lihat ada berapa belas framework web di Perl sejak Catalyst, ada berapa puluh modul untuk validasi data (ane juga nyumbang satu nih hehe), dan mungkin seratusan modul konfigurasi.

Tapi yang membuat pengguna bingung, bagaimana memilih modul terbaik? Terpopular? Tercepat? Dsb. Kurang ada perbandingan2x atau benchmark2x atau kontes. Komunitas Perl seolah gak suka dengan kompetisi. Bahkan counter download aja dari dulu gak jadi dibuat2x.

Kita perlu ingat bahwa kompetisi mendorong inovasi. Kurang inovasi berarti mati.

Ayo kita berkompetisi, ayo kita saling beradu secara positif.

-- sh (Yang sedang menggodok versi Data::Schema berikutnya untuk menjadi DFV-killer :-)

Autovivification

Berdasarkan pertanyaan dari beberapa orang yang agak kebingungan dengan istilah autovivicationautovivification, mungkin secara singkat saya akan langsung memberikan contoh tentang apa itu yang disebut dengan autovivication.autovivification
Ini dia autovivication autovivification:

my $hash;
$hash->{aaa}{bbb}{ccc} = 'sebuah nilai';

Ketika dideklarasikan, $hash tidak mempunyai key dan value, tetapi kemudian kita memberikan suatu value pada key yang 'undefined'.

Ya sesingkat itulah definisi dari autovivication.autovivification

Modules *AND* applications

"Why choose?" -- Fatima Dinssa

In Modules vs Applications, Sawyer X noted that one of the "issues" (emphasis mine) of Perl people is the tendency to write modules instead of applications. That CPAN is great but due to the lack of end user programs there is no WOW factor. He suggested that we write programs/applications that everyone can use to attract more people to Perl.

While I agree with the last suggestion, I don't agree with the preference to modularize everything as an issue. As someone who wrote a program years ago that is comprised of many separate scripts and duplicated code (even in different languages, just for the fun of it) and still have to maintain it today, I'd say that not putting as much code as possible into reusable modules is a mistake.

I'd instead suggest that we still write modules (which is what made CPAN great anyway), but try to *also* accompany each distribution with a demo app (preferably in the App:: namespace).

I myself will try to do that from now on.

Log::Any::App (2)

Following up on my previous post, I've just uploaded Log::Any::App to CPAN.

Do you write or use modules that use Log::Any? Or, do you want to use Log::Any conveniently in an application? Now you can just do this:

% perl -MLog::Any::App -MOtherModuleThatUsesLogAny -e ...

and the logs will be displayed to screen. The default level is WARN, but if you want to debug things:

% DEBUG=1 perl -MLog::Any::App ...

or if you want to quiet things down:

% LOGLEVEL=error perl -MLog::Any::App ...

If you put 'use Log::Any::App' in your script, when run it will by default log to file too (~/prog.log or /var/log/prog.log). It can even automatically log to syslog.

Zero-conf. No more long incantation.

Please tell me what you think.

Choosing test names

Which test names do you prefer?

"tong() method can connect to database"
"tong() method can disconnect from database"
"sha() method can delete an existing file"
"sha() method fails when deleting a non-existing file"

or:

"tong 1"
"tong 2"
"sha 1"
"sha 2"

They are both rather extreme, but if I had to choose, I would still rather go with the shorter ones. I tend to treat test names more like unique IDs, and when things go wrong I just look up the actual test code.

I wouldn't mind verbose test names though if they can somehow be automatically generated (a future Google Translate project, perhaps?) from code, because they are just repeating what the code says.

To repeat myself, it's the DRY principle.

On reading code

Last week I started using github, forked a project, and read some of miyagawa's beautiful code. Later on the weekend, I imitated a particular style I found from his code to improve my own code.

And then I realized: during the course of many years as a programmer, I really really seldom read other people's code, especially real-world code. Sure, I do whenever I have to patch something. But other than that, practically never.

Other than code, I do read an awful lot: books, magazines, mailing lists, forums, blogs, web pages. I have never doubted the benefits of reading for improving knowledge and understanding, so why haven't I read more code? A couple of reasons I can think of:

1. We programmers are not paid to read code. We are paid to write programs, to churn out lines upon lines of code. Heck, we're not even paid to write good code, we're paid to get the job done.

2. Reading code is hard. It can really drain your brain. Imagine a recipe book where the flow of instructions is not linear (jump to line X, jump to page Y and then return here), where a misplaced character can destroy the whole recipe, and where everything is so interdependent and interlinked that you need to read everything twice first before you can begin to understand it.

3. Reading code is boring. Can you really curl up with a good program the way you can with an exciting novel?

4. Reading code is not necessary. A good reusable piece of code need not be read anyway, all you need is its API documentation. Programmers are hired regardless of their ability to read real-world code, there are no interview tests in reading code other than a few or at most a dozen lines of it. Heck, programmers are even hired despite their inability to write any code at all.

After experiencing that one session of code reading can do some wonders, I'll make it a program to read more (good) other people's code.