asads
U2FsdGVkX1+oAnwbnskvya69szTjdFpGybhS2NzdrKHSjoJTr08Mjc5tbPuHiBiBO8XlWYvlkceixZrnmV7xdQ==

Baca Juga

Ditulis Oleh : Bernaridho I. Hutabarat Pada Majalah PC MEDIA.

Penulis berangkat dari Inggris pada 31 Agustus 1997 dan tiba kembali di Indonesia 1 September 1997.  Saat itu penulis mulai gerah dengan C, C++, dan Pascal; dan mulai ingin membuat bahasa pemrograman sendiri. 

Pada tahun 1998, penulis membimbing 9 orang mahasiswa dalam melakukan tugas akhir. Seorang mahasiswa bernama Rudy Harinugroho tidak memiliki ide awal, dan saya memberi ide untuk membuat bahasa pemrograman baru, namanya Batak. 

Inilah untuk kali pertama Batak dibuat. Nama Batak sendiri dipicu oleh ketidaksukaan saya akan Java. Rudy dan saya membuat parser (pemeriksa sintaks dan semantik) bahasa pemrograman Batak dengan memakai Abraxas PCYACC dan Turbo C++ 3.1 dari Borland.  Saat itu, STT Telkom memang memiliki lisensi PCYACC yang relatif tidak terpakai (karena minimnya riset bahasa pemrograman). 

Tugas akhir Rudy usai pada tahun 1999, saat di mana penulis mulai bekerja penuh sebagai profesional TI, penulis berhenti bekerja sebagai dosen STT Telkom pada Agustus 1998.  Sintaks bahasa pemrograman Batak yang dibuat terbatas ke sintaks pendefinisian tipe. Batak memungkinkan defi nisi seperti ini : 
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Pada bahasa pemrograman C pendefinisian seperti di atas harus ditulis :
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Kata typedef pada C itu buruk sehingga tidak saya pakai.

Pendefinisian target_type sebagai array-of-sometype harus ditulis seperti sometype target_type[array_size].  Ini menyulitkan belajar ekspresi-tipe dan assignment.  Kata struct pada C juga buruk, kata ‘Record’ seperti pada Pascal jauh lebih baik. Pada bahasa pemrograman C++ pendefinisian seperti di atas harus (atau biasanya) ditulis :
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Yang buruk dari cara C++ adalah pemakaian dua kata untuk metatype (metatype disebut metaclass pada Java).  Pemakaian dua metatype tidak perlu. Bagaimana membuktikan pendapat atau teori ini? Dengan membuat sintaks dan semantik bahasa pemrograman. Jadi, salah satu motivasi penulis membuat bahasa pemrograman baru adalah membuktikan kesalahan teori-teori atau klaim di banyak buku tentang bahasa pemrograman apapun. Perlu dicatat bahwa C tidak memakai operasi assignment untuk pendefinisian tipe. Ini juga menyulitkan pembelajaran dan pemahaman ekspresi-tipe.  

Kembali ke contoh pendefinisian tipe, untuk pendefinisian yang sama kita harus menulisnya pada bahasa pemrograman Pascal sebagai berikut :
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Pada Pascal, deklarasi array menjadi terlalu panjang dengan adanya kata of.  Yang juga buruk dari Pascal adalah pemakaian tanda = untuk assignment (sementara tanda := dipakai untuk assignment pada hampir semua kasus lain). 

Kesalahan pemakaian terlalu banyak lambang untuk assignment mirip dengan pemakaian terlalu banyak istilah untuk metatype seperti pada C++. Selain keburukan-keburukan yang spesifik, C dan Pascal memiliki keburukan yang umum : menyulitkan pemahaman ekspresi tipe. 

Pascal memiliki keburukan yang lain : kita tidak bisa mendefinisikan beberapa tipe sekaligus dengan menuliskan metatype satu kali saja.  Dengan kata lain, kita tidak bisa menuliskan seperti ini di Pascal.
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Pada Java, pendefinisian dua tipe char_array dan Coordinate secara sekaligus akan sangat menyulitkan. Yang biasanya dilakukan adalah membuat class untuk Coordinate.  Mudahkah mendefinisikan satu tipe array dengan panjang tertentu di Java? Tidak.

Tonggak (Milestone) Berikutnya: Amerika Serikat.
Setelah tidak lagi bekerja sebagai dosen penuh di STT Telkom, penulis berganti pekerjaan dua kali. Sejak awal tahun 2001, penulis bekerja di Atlanta, Amerika Serikat, sebagai DBA (DataBase Administrator).  Pada saat itu penulis diizinkan memakai fasilitas kantor untuk riset yang tidak dibiayai oleh kantor.  Pada tahun inilah, secara sendirian penulis mengembangkan sintaks bahasa pemrograman Batak dari sekadar deklarasi tipe menjadi bahasa pemrograman yang penuh. Sudah ada sintaks untuk assignment (non-type—expression), operation-call, statement, operation-header, operation-declaration, module, dan main-module. Dengan kata lain, Batak sebenarnya kali pertama diselesaikan secara utuh di Amerika Serikat, bukan di Indonesia. 

Kali ini karena penulis tidak lagi bekerja di STT Telkom, penulis memakai PCYACC versi gratis dari Abraxas, yang saya download dari www.abxsoft.com. Untuk translator C, penulis memakai Visual C++ yang lisensinya dimiliki perusahaan tempat saya bekerja di Atlanta. Versi gratis dari PCYACC memiliki states yang sangat terbatas, yang menghalangi penulis membuat parser yang lebih kompleks.  

Walau pernah memakai Red Hat Linux 6 yang sudah memakai GUI, penulis kesulitan memakai YACC gratis dari GNU.  YACC gratis dari GNU mampu mengolah states yang lebih banyak daripada PCYACC yang gratis. Penulis mengumumkan keberhasilan pembuatan bahasa pemrograman ini kepada banyak mailing list orang Indonesia, tetapi tidak ada yang sangat antusias.  

Hanya ada satu orang bernama Steven Haryanto (saat ini CTO dari Masterwebnet dan kolumnis di PC Media), yang setelah melalui perdebatan yang agak panjang ingin menulis tentang bahasa pemrograman Batak. Tulisan tentang Batak akhirnya muncul di majalah Masterweb edisi November 2001, dan pada saat itu penulis sudah kembali di Indonesia. 

Sebelum penulis kembali, bahasa pemrograman Batak sempat diuji kemudahannya kepada 3 orang rekan saya yang memiliki expertise berbeda : seorang programer, seorang administrator SQL Server, dan seorang administrator Oracle. Hasil mereka sangat positif: Batak memang lebih mudah dipakai daripada C, C++, dan Delphi.  Pemiliki perusahaan mendapatkan lapor an uji, tapi tidak berani untuk terjun pada bisnis pembuatan software infrastruktur.

Dari Parser ke Translator.
Setelah kembali di Indonesia, Batak matisuri. Saya sesekali membuat catatan tentang perkembangan bahasa pemrograman lain, dan melakukan perubahan kecil untuk membuatnya tetap up-to-date. Pada tahun 2003, penulis disemangati untuk membuat translator Batak.  Translator bukan parser: translator mampu translate code. Dengan susah payah, dalam periode 2003-2004 penulis berhasil membuat translator Batak.  Translator tersebut mampu translate source code Batak ke source code pseudo assembly. 

Pseudo assembly adalah bahasa pemrograman imajiner dari saya sendiri.  Dengan source-code seperti ini: 
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Translator translate source-code Batak menjadi source code pseudo assembly yang kira-kira seperti ini:
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Saat itu, penulis membuat psedo assembly yang mirip dengan Intel Assembly.  Hal ini terlihat dari pemakaian kata MUL untuk operasi MULtiply, dan semantik bahwa operand pertama akan menjadi target sehingga statement terakhir secara ekuivalen mirip dengan semantik statement di C seperti ini:
Penulis membatasi diri ke statement yang berisi assignment nilai dari ekpresi aritmetik 2 operand, dan belum melibatkan floating-point.

Ternyata membuat translator terbatas ini saja sudah sangat sulit. Berapa test-cases diperlukan untuk memastikan kebenaran translasi ekspresi aritmentik 2 operand?  Mari kita hitung. Ada 4 kemungkinan untuk operand pertama : objek (seperti a), -objek (seperti –a), nilai nonnegatif (seperti 5), dan nilai negatif (seperti -5).

Ada 4 kemungkinan untuk operasi : + - * / . Ada 4 kemungkinan untuk operand kedua (dengan kombinasi seperti operand pertama).  Kita peroleh hasil a64 kemungkinan.  Penulis berhasil membuat code-translator yang translate source-code Batak dari 64 kemungkinan.

Ekspresi Aritmetik dengan Parentheses dan n-operand (n > 2).
Pasca pembuatan translator ke pseudo-code ini, di akhir tahun 2004 penulis ingin melakukan sesuatu yang lebih sulit : translate code dari ekspresi aritmetik yang melibatkan parentheses. Sebagai contoh :
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Uji kebenaran beberapa statement di atas perlu sebelum kita dapat menguji kebenaran hasil translasi dari statements yang lebih rumit seperti di bawah ini:
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Mengenal Sejarah Bahasa Pemrograman NUSA bagian Dua
Ternyata membuat translator dengan kemampuan di atas sangat sulit. Jumlah kombinasi yang harus diuji meledak dari 64 ke nilai yang sangat besar.  Secara praktis, enumerasi kasus-kasus yang perlu diuji menjadi mustahil.

Penulis membatasi diri kepada enumerasi (pembuatan contoh kasus secara menyeluruh/exhaustive) ke-4 operand dengan melibatkan semua kombinasi penempatan dan level dari unary minus dan parentheses. Untuk ekspresi aritmetik dengan 5 operand ke atas, saya hanya melakukan uji acak. Upaya yang sangat sulit dan “berdarah-darah” ini berhasil pada sekitar Maret–April 2005.  Dengan ini penulis memahami betapa sulitnya membuat translator.

Code-translator Sederhana yang Sebenarnya.
Menjelang medio 2005, penulis disemangati Pak Wiyono (saat tulisan ini dibuat merupakan Manajer TI di PLN P3B Gandul) untuk melanjutkan pembuatan translator Batak.  Entah kenapa, penulis bersemangat. Kali ini, target code bukan lagi pseudo assembly, melainkan Intel Assembly 80386 yang run di atas DOS.

Penulis masih memakai PCYACC gratis, Windows 2000 Professional, dan Visual C++ yang dilisensi oleh bekas perusahaan penulis (namun tidak dipakai lagi), dan Microsoft Assembler 6. Microsoft Assembler 6 sudah digratiskan oleh Microsoft.  Windows 2000 Professional yang dulu dipakai saat ini sudah diganti oleh Windows XP yang legal (yang penulis beli secara pribadi).

Singkat kata, penulis akhirnya berhasil membuat translator yang translate source code Batak.  Pemrosesan sample-programs yang source code-nya ditulis dalam Batak adalah seperti ini. Yang melakukan operasi translate adalah Batak.Exe, yang melakukan compile dan link adalah ML.EXE.











































































Loading...