Saat ini banyak kurikulum pemrograman yang dibuat untuk mengikuti tren terbaru. Sayangnya tren ini bisa cepat sekali berlalu, dan kadang baru disadari kemudian betapa jeleknya tren sebelumnya (misalnya Microsoft yang menyadari Visual Basic merupakan bahasa yang tidak scalable, tidak cocok untuk enterprise). Di posting ini saya akan menceritakan kurikulum yang dulu saya alami ketika belajar pemrograman di ITB. Sayangnya saat ini kurikulumnya sudah berubah, tapi saya tetap ingin menunjukkan di sini, kira-kira kurikulum yang baik itu seperti apa.

Ketika saya belajar pemrograman di ITB, kurikulumnya dimulai dengan dasar pemrograman. Dalam dasar pemrograman kami diajari LISP. LISP merupakan bahasa dengan paradigma fungsional. Tidak semua aspek LISP diajarkan (misalnya do-loop yang sifatnya imperatif). Ketika belajar LISP, fokusnya adalah memanipulasi struktur data (list, tree) secara rekursif dan mengenai stateless programming.

Setelah itu ada pelajaran algoritma dan pemrograman yang diajarkan dalam Pascal dan C. Kelas ini mengajarkan pemrograman dalam paradigma prosedural. Aspek fungsional sudah dipelajari di LISP, jadi dalam aspek prosedural, kami hanya perlu belajar mengenai aspek imperatif (state program, loop tanpa rekursi) dari sebuah program. Di sini terlihat bahwa paradigma prosedural juga mengandung aspek fungsional. Dalam kelas ini kami juga diajari cara menstrukturkan sebuah program (menjadi unit).

Pelajaran berikutnya ada dalam kelas Pemrograman Berorientasi Objek (obect oriented programming/OOP) yang sesuai namanya, mengajarkan paradigma OOP. Apa yang sudah dipelajari ketika belajar paradigma prosedural tetap terpakai di kelas ini. Semua jenis loop, kondisional, dsb semua masih terpakai. Jadi ketika masuk kelas OOP, hal tersebut tidak diajarkan lagi. Hanya aspek OOP saja yang perlu dipelajari, jadi kelas OOP benar-benar berfokus pada aspek OOP, bukan mengajari mahasiswa cara menulis loop atau mengajari konsep assignment.

Di antara konsep prosedural dan OOP, ada pelajaran mengenai paradigma deklaratif dengan menggunakan Prolog. Di sini kita diajarkan bahwa menyatakan setiap langkah program bukanlah satu-satunya cara untuk menyelesaikan masalah. Dalam pemrograman deklaratif, kita hanya menyatakan apa yang perlu dilakukan, tanpa perlu menjelaskan langkah-langkahnya. Ada banyak bahasa deklaratif di dunia ini (CSS, SQL, dsb), tapi pelajaran prolog ini kelak akan berguna di kelas Intelegensia Buatan, di mana kami diminta mengimplementasikan mesin inferensi untuk bahasa prolog sederhana. Saya senang pernah mengenal paradigma deklaratif, karena sangat memudahkan ketika saya terjun dalam bidang math modelling language yang memakai paradigma constraint programming

Kalau Anda menengok wikipedia, ada masih banyak lagi paradigma pemrograman, tapi tidak semuanya diajarkan secara khusus. Sebagian besar paradigma dimasukkan ke kelas yang paling dekat (misalnya event driven programming ketika memprogram GUI dalam OOP, metaprogramming ketika belajar tempate C++, dsb). Sebagian paradigma sangat sempit pengunaannya dan bisa dipelajari sendiri nanti ketika diperlukan.

Beberapa bahasa lain juga perlu dipelajari dalam kuliah yang berbeda. Dalam metode numerik, kami belajar memakai FORTRAN. Setelah mempelajari beberapa bahasa, FORTRAN sangat mudah dipelajari. Selain itu dalam kelas arsitektur komputer, ada pelajaran mengenai bahasa assembly. Bagi sebagian orang ini agak sulit, karena memang urutan kuliahnya tidak diberikan sesudah Teori Bahasa Formal (yang mengajarkan konsep turing machine, dan sudah cukup dekat dengan assembly).

Bisa Anda lihat bahwa setiap pelajaran merupakan dasar dari pelajaran berikutnya (paradigma yang satu mengandung paradigma yang lain). Aneh sekali jika di kelas OOP yang diajarkan adalah tentang loop dan pernyataan if (aspek prosedural) atau tentang rekursi (aspek fungsional). Di kelas OOP yang diajarkan seharusnya adalah hal-hal yang spesifik OOP, seperti masalah inheritance, polymorphism dsb.

Jadi menurut saya kurikulum yang baik seharusnya mengajarkan banyak paradigma (bukan cuma satu saja) secara bertahap. Setiap tahap akan membuat mahasiswa bisa memahami setiap paradigma dengan baik, dan membentuk proses berpikir yang lebih baik.

Respon kebanyakan orang bisa dirangkum menjadi tiga kubu. Kubu pertama: ah di dunia nyata kan orang pasti testing, keahlian buat memprogram dengan benar tanpa testing itu tidak berguna. Kubu kedua menyatakan: kalau program sependek itu tidak bisa dibuat tanpa testing, bagaimana mungkin bisa membuat program besar yang rumit, apakah tiap baris program harus ditest?. Kubu terakhir menyatakan: buat apa sih membuat binary search, kan sudah ada di library/API?

Untuk kubu terakhir, jawabannya sederhana: ada kasus di mana hal tersebut masih diperlukan. Misalnya fungsi binary search di library kebanyakan tidak menyatakan elemen mana yang akan dikembalikan jika ada lebih dari 1 data yang cocok, dan tidak akan mengembalikan lokasi di mana data bisa disisipkan jika data belum Ada. Contohnya di fungsi bsearch di C (POSIX):

The bsearch() function returns a pointer to a matching member of the array, or NULL if no match is found. If there are multiple elements that match the key, the element returned is unspecified.

Kadang diperlukan fungsi yang mengembalikan elemen pertama yang cocok, atau terakhir yang cocok, atau bahkan elemen random dari antara semua elemen yang cocok. Tentu saja salah satu solusinya adalah membungkus fungsi bsearch, lalu mencari ke depan atau belakang sampai tidak cocok lagi. Tapi dalam hal ini Anda juga tetap perlu memperhatikan batas index ketika mencari, jadi Anda tetap perlu menulis kode (yang perlu testing dan perlu dipikirkan).

Jika Anda mengimplementasikan fungsi binary search sendiri, Anda bisa membuat fungsi yang sekaligus mengembalikan posisi elemen di mana kita harus menyisipkan elemen tersebut jika elemen tidak ditemukan (ini bisa didapat dari lokasi perbandingan terakhir), dalam kasus ini kita tidak bisa membungkus fungsi bsearch, karena fungsi tersebut hanya mengembalikan NULL jika elemen tidak ditemukan.

Beberapa Pelajaran yang bisa dipetik dari posting dan diskusi adalah: testing itu perlu, bahkan untuk program kecil sekalipun. Pelajaran kedua adalah: kita tetap harus teliti dan berpikir ketika memprogram. Pelajaran ketiga adalah: meski isi library di berbagai bahasa sudah cukup lengkap, mengerti algoritma sederhana itu perlu, dan kadang kita perlu mengimplementasikan algoritma tersebut atau variannya.

Sebagian orang berpikir: ah tidak perlu terlalu teliti ketika memprogram, nanti akan ketauan salahnya ketika testing. Sebagian lagi berpikir: program ini sudah saya pikirkan, jadi gak perlu ditest. Sikap yang benar adalah: kedua hal tersebut berhubungan, kita harus teliti ketika memprogram, dan harus teliti juga dalam membuat testing. Mengapa tidak menggantungkan diri pada testing saja? ada beberapa masalah dengan testing, pertama testing itu sulit, untuk membuat test case yang baik perlu kasus yang sangat besar dan kedua testing tidak selalu bisa dilakukan.

Banyak sekali security bug dalam program terjadi karena off-by-one error, dan sering kali ini tidak diketahui. Kasus seperti ini akan sering jika penulis kode unit testing bukan programmer yang menulis kode, sehingga dia tidak bisa melakukan boundary value analysis. Oleh karena itu berpikir sambil memprogram adalah hal yang penting (jangan menggantungkan diri dari testing saja).

Ada kalanya testing kadang sulit dilakukan, misalnya jika program harus dijalankan di harware khusus. Hal ini terutama jika hardware tidak memiliki emulator, atau jika emulator tidak sempurna. Contohnya: banyak emulator ponsel (terutama Symbian versi awal) tidak mengimplementasikan bluetooth, kamera dan wifi. Mau tidak mau kita harus testing di hardware sebenarnya, yang biasanya memakan waktu lebih lama, dan kadang membutuhkan biaya yang lebih besar. Dalam kasus ini testing tetap bisa dilakukan, tapi harus diminimasi, dan harus dipikirkan dengan matang apa saja yang ingin ditest.

Jadi yang perlu diingat: jangan asal coding, lalu mendebug/mengetes sampai kodenya benar, pikirkan dulu sebelum menulis kode. Setelah dipikirkan, baru diuji, sambil memikirkan aneka kasus uji yang penting.

Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis. Alan Perlis

Kebanyakan orang tidak menyadari bahwa mereka butuh sesuatu, atau bahwa sesuatu itu jelek, sampai mereka diberikan sesuatu yang lebih baik. Di artikel ini saya ingin mengkritik PHP, tapi sebelumnya akan saya contohkan apa yang saya maksud dengan melihat sejarah MySQL.

Awalnya MySQL tidak mendukung transaksi. Komentar pendukung MySQL waktu itu: transaksi itu tidak perlu, yang penting cepat (Bahkan pembuat mysql pun berpikir demikian, coba lihat http://www.genome.ou.edu/mysql_manual.html#Bugs, bagian " Some things we don't have any plans to do"). Tapi kemudian transaksi ditambahkan, dengan catatan: kalau mau cepat jangan pakai transaksi. Lalu berikutnya: transaksi adalah salah satu fitur yang kami banggakan.

Nah, saya cukup yakin, isi kritik saya ini kemungkinan akan banyak ditolak oleh orang yang cinta buta pada PHP, setidaknya saat ini. Tapi ketika PHP sudah berkembang, baru akan bisa diterima. Memang begitulah sifat penggemar sesuatu, jadi saya bisa memakluminya.

Saya sendiri pernah memprogram PHP dari sejak PHP3, lalu PHP4, dan sampai awal PHP5. Semakin lama saya mempelajari dan memakai PHP, saya semakin merasakan keterbatasannya. Saya tidak menyangkal bahwa PHP merupakan bahasa yang sangat populer. Namun tidak semua yang populer itu bagus (ingat DBase? Ingat Visual Basic 6? dsb). Bagi pencinta PHP, Anda mungkin bisa berbangga PHP semakin membaik, meski caranya dengan "tambal sulam", dan meski Anda harus sering menyesuaikan program agar berjalan di PHP terbaru. Mungkin saya akan mencoba lagi PHP di versinya yang keenam, tapi saat ini mari kita bahas satu persatu kelemahan PHP.

Dari sejarahnya PHP berasal dari proyek pribadi (singkatannya waktu itu: Personal Home Page), dan ditambahi aneka fitur tanpa pertimbangan yang matang (magic_quotes, register_globals, dsb). Mereka kadang menyesali suatu keputusan dan menarik fiturnya (misalnya magic_quotes dan register_globals yang akan ditarik di PHP6), bahkan menurut saya kadang mereka bingung misalnya is_a sempat dianggap deprecated lalu di undeprecated.

Baru-baru ini PHP memiliki fitur namespace (yang sudah ditunggu lama), tapi sayangnya mereka memakai separator \ (backslash). Tidak seperti bahasa lain yang memiliki proses pengambilan keputusan melalui proposal yang kemudian disetujui/ditolak oleh komunitas via diskusi (yang biasanya memakan waktu beberapa minggu/bulan), keputusan memakai backslash diambil dari chatting IRC selama beberapa jam. Mungkin akhirnya orang akan bisa menerima ini, tapi ini bukan sesuatu yang elegan jika Anda beralih dari bahasa lain. Contoh ini saya ambil dari salah satu komentar slashdot.

Java/C#/Python:
Attribute/Method access: foo.bar
Static method access:    Foo.bar
Package access:          foo.bar.baz

Attribute/Method access: $foo->bar
Static method access:    Foo::bar
Namespace access:        foo\bar\baz

Pada akhir tahun 2005 ada sebuah webcast dari Zend yang berisi presentasi Zend Framework (sayang webcastnya tidak bisa saya temukan, linknya sudah mati, tapi Anda bisa melihat rangkumannya di blog ini). Framework tersebut berusaha meniru Ruby on Rails dalam masalah ActiveRecord, tapi ada satu masalah besar.

Masalah besarnya adalah: isi webcast tersebut tidak mungkin bisa diimplementasikan dengan PHP yang ada saat itu, dan bahkan baru bisa diimplementasikan di PHP 5.3 yang baru dirilis 3 minggu yang lalu. (ok sebenarnya dengan trik yang sangat jelek, dan membuat aplikasi jadi super lambat, itu bisa dilakukan, tapi secara praktis itu tidak bisa dilakukan). Sebagai catatan, PHP 5.3 menambahkan fitur late static binding sehingga sekarang isi webcast tersebut bisa diimplementasikan.

Perlu dicatat, metode tambal sulam dalam memperbaiki fitur PHP menyebabkan banyak program PHP3 tidak berjalan di PHP4, dan program PHP4 tidak berjalan di PHP5. Itu sebabnya Anda akan melihat banyak hosting yang masih menyediakan PHP versi 4 walau versi 5 sudah ada sejak tahun 2004 (5 tahun yang lalu).

Tidak konsisten

PHP memiliki banyak fungsi di namespace utama (lebih dari 3000 fungsi), namun penamaan fungsi sangat tidak konsisten:

• ada yang memakai underscore, dan ada yang tidak (isset, is_object, dsb)
• urutan verb object atau object verb tidak seragam, misalnya base64_decode bentuknya: object verb, sedangkan recode_string bentuknya verb object
• fungsinya banyak yang redundan (pencarian string: strstr , strchr, strpos, dsb, sorting: sort, arsort, asort, krsort, ksort, natsort, natcasesort, rsort, usort, dsb)
• pemakaian to dan 2 yang tidak seragam: ascii2ebcdic, strtolower

Daftar di atas itu hanya komplain saya, masih banyak hal lain yang lengkapnya bisa dibaca di url http://tnx.nl/php.html

Struktur Data

Tahukah Anda bahwa array di PHP sebenarnya adalah hashtable? Apa konsekuensinya: pertama ini butuh memori yang lebih banyak. Di C/Pascal/C++, dsb setiap elemen dalam sebuah array of integer akan membutuhkan space 4 byte. Dalam PHP, setiap elemen integer butuh 68 byte, berari overheadnya sangat besar (17 kali lipat dibanding array biasa). Detailnya: 6 byte untuk struktur value (zval), 36 byte untuk hash bucket, dan 2*8 = 16 byte untuk header alokasi memori. Ini pun hanya di sistem 32 bit, di sistem 64 bit penggunaan memorinya 2 kali lipatnya. Biasanya kita memiliki tradeoff memory vs speed. Dalam kasus ini kita memiliki konsekuensi kedua: akses array memiliki kompleksitas yang lebih besar dari O(1), sehingga lebih lambat di banding aneka bahasa lain. Tepatnya: tergantung dari cara Anda mengakses array, kompleksitasnya berbeda-beda (misalnya sebagian mengkomplain array_shift yang terlalu lambat, lebih lambat dari membalik array dan mem-pop hasilnya).

Di PHP 5.3 diperkenalkan kelas SplFixedArray untuk tipe array yang benar-benar array (area kontigu di memori). Mereka juga memperkenalkan kelas-kelas lain yang lebih cepat dan hemat memori, yaitu: SplDoublyLinkedList, SplStack, SplQueue, SplHeap, SplMaxHeap, SplMinHeap, SplPriorityQueue, dan SplObjectStorage. Sebagai catatan, array 1000 elemen yang tadinya butuh sekitar 200kb di php lama, dengan SplFixedArray sekarang hanya butuh sekitar 60 kb (catatan: saya menggunakan sistem 64 bit).

Perlu dicatat juga bahwa sebelum PHP 5.3 jika kita memiliki circular reference, maka garbage collector PHP tidak bisa menghapus objek-objek yang terbelit dalam circular reference. Dalam program yang berjalan lama, bug memori karena circular reference ini bisa menumpuk, Jadi PHP sebelum 5.3 tidak cocok untuk operasi yang berjalan lama (misalnya untuk daemon), kecuali kita memprogram dengan sangat berhati-hati.

Penutup

PHP merupakan bahasa yang sangat populer. Dengan adanya banyak pengguna, maka banyak pula demand untuk memperbaiki bahasa ini dan memperbaiki implementasi interpreternya. Karena itu kemungkinan bahasa ini memiliki masa depan yang cukup baik. Namun saat ini sudah mulai ada banyak pesaing PHP, sehingga PHP harus berusaha secepat mungkin membenahi diri agar tidak terlibas oleh bahasa lain. PHP6 yang sudah bertahun-tahun dikembangkan saya harap bisa menyenangkan banyak orang.

Microsoft pernah membuat bahasa yang super populer: Visual Basic (sampai versi 6). Tapi mereka menyadari keterbatasan dan kekurangan bahasanya, dan menggantinya dengan Visual Basic .NET yang sangat baik (dari paradigma OOP). Kiranya hal yang sama bisa terjadi di dunia PHP.

Link Tambahan

Bagi Anda yang tertarik dengan internal PHP, beberapa link ini mungkin bisa menambah wawasan Anda:

Implementasi Hashtable di PHP (artikel lama, sekarang strukturnya sudah agak berubah)

Masa depan PHP6 (artikel dari tahun 2008)

Benchmark Array dan Tipe Data Baru

1. Terlalu berfokus pada tools tertentu yang trend saat ini. Mahasiswa wajib memakai tools X (misalnya IDE-nya harus Microsoft Visual Studio, atau harus memakai Visual Prolog). Tools akan cepat sekali berganti. Ketika Anda diajari tools X, ketika lulus, tools tersebut mungkin sudah tidak ada, atau tidak didukung lagi. Ingin contoh? DBase dan Visual Basic. Dulu keduanya sempat menjadi tools yang "standar", tapi sekarang tools tersebut tidak disupport lagi.
2. Tidak mengikuti perkembangan zaman. Ini ekstreem sebaliknya dari yang pertama, ada yang masih mengajarkan kuliah C dengan standar Pre ANSI-C, dan menggunakan compiler Turbo C++ 2.0, yang dirilis kira-kira 20 tahun yang lalu, dan sudah tidak didukung lagi.
3. Kurang mengajarkan aspek algoritma. Pada sebagian besar bahasa, sudah tersedia library standar untuk sorting, searching, dsb, tapi tanpa memahami kemampuan dan batasan setiap algoritma, Anda akan menemukan hambatan ketika memproses data dalam jumlah yang besar.
4. Hanya mengajarkan paradigma tertentu. Umumnya paradigma yang dipakai sekarang adalah object-oriented yang digabung dengan procedural, tapi itu bukan satu-satunya cara menyelesaikan masalah.

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

Memahami floating point dalam program

#include <stdlib.h>
#include <stdio.h>
int main(int argc, char *argv[])
{	
	float a = 0.1;	
	double b = 1000000000;	
	printf("result = %f\n", a*b);
	return 0;
}

result = 100000001.490116

#include <stdlib.h>
#include <stdio.h>
#include <math.h>

int main()
{	
	float a = 0.1;	
	float b = 0.1;
	int i;	
	for (i=0; i<9; i++) {	
		b += a;
	}
	printf("a=%lf b=%lf a==b? %s\n", a*10.0, b, 
		b==(a*10.0)?"yes":"no");
	return 0;
}

a=1.000000 b=1.000000 a==b? no

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
int main()
{
	long double a = 0.1;
	long double b = 0.1;
	int i;	
	for (i=0; i<9; i++) {
		b += a;
	}
	printf("a=%Lf b=%Lf a==b? %s\n", a*10.0L, b, 
		b==(a*10.0L)?"yes":"no");
	return 0;
}

a=1.000000 b=1.000000 a==b? yes

Memprogram embedded system dalam C akan lebih mudah dibanding dengan menggunakan Pascal misalnya. Penggunaan C dalam embedded system juga menghemat memori, yang akan menghemat biaya produksi alat. Untuk dapat menggunakan suatu bahasa dengan baik, kita perlu mengetahui mengapa fitur tertentu ada di suatu bahasa, dan kapan sebaiknya kita memanfaatkannya.

Dalam kesempatan ini, saya akan membahas penggunakan tipe enumerasi (enum), yang jarang digunakan programmer pemula. Tipe ini banyak diajarkan di berbagai kuliah atau buku, tapi hal yang kurang dibahas adalah mengapa kita sebaiknya memakai tipe enumerasi dibandingkan menggunakan konstanta integer.

Tipe enumerasi adalah tipe di mana nilai yang mungkin disebutkan satu per satu oleh programmer. Misalnya tipe hari yang terdiri dari Senin, Selasa, Rabu, Kamis, Jumat, Sabtu, dan Minggu. Banyak bahasa pemrograman memiliki tipe enumerasi, misalnya C, Pascal, C#, Java 5 ke atas, Ada, dan Visual Basic.

Pertama, compiler bisa mengingatkan jika kita melakukan operasi aritmatika terhadap tipe enumerasi, tapi compiler tidak akan memperingatkan jika Anda melakukannya terhadap tipe integer. Jika Anda menggunakan pernyataan case/switch, compiler juga akan bisa memperingatkan jika Anda tidak menangani semua kasus enumerasi. Misalnya:

switch (hari) {
    case SABTU:{
    hitung_gaji(); 
    break;
    }
case MINGGU:{
    pemeriksaan_mesin(); 
    break;
    }
}

Compiler bisa memperingatkan bahwa hari-hari lain tidak ditangani dalam blok tersebut. Dalam bahasa tertentu (Java misalnya), tipe enumerasi ketika dicetak akan menghasilkan representasi string dari enumerasi, dan bukan sebuah angka.

Bacaan lebih lanjut: http://en.wikipedia.org/wiki/Enumerated_type