Jika membaca Body dan Header dan Penulisan Header File yang baik membuat anda kesulitan menggunakan C, jangan khawatir, java bisa menjadi solusi tepat untuk kemalasan anda berpikir, tapi yang jelas selalu ada trade-off.
Somehow, entah bagaimana Java melakukan enkapsulasi/pembungkusan kerumitan hal-hal yang rumit dalam C, jadi santai aja! Sama dengan jika menggunakan IDE dalam memprogram C/C++, buat dari wizard, klik run, alakazam!,
hello world
Java sebagai bahasa murni OO merupakan bahasa terkini yang terpopuler. Setelah OO dinobatkan sebagai panasea atas segala penyakit dunia pemrograman, bahasa ini seakan merajai jagad opensource. Opensource saja? Sebagai bahasa yang jalan diatas virtual machine java dengan hasil kompilasi berupa byte code secara teoretis program dengan java selalu bisa didekompilasi, berarti source code selalu bisa dibuka, kecuali program dibuat acak adul penuh dengan komentar yang menjelaskan keberantakannya maka pengguna dekompiler akan pusing 7.68 keliling(0.68 adalah konstanta ketidak pastian, dinyatakan pertama kali oleh pakar Indonesia bidang keahlian baru IT; superficial intelligence, r sapatuhnamanya). Bagaimanapun juga komentar tidak dikompilasi, maka tidak pula dapat di restore dengan decompiler. Namun tentunya tidak akan pernah ada pelajaran bagaimana memprogram yang buruk sehingga sulit dimengerti orang lain, jika ada please drop me a line or some!
Program mahal/eh super mahal ding ERP semacam SAP yang ditulis dengan java pun seringkali didekompile oleh programmer malas yang nggak mau/nggak mampu baca spesifikasi/dokumentasi SAP(atau jangan-jangan mungkin kualitas dokumentasi SAP memang awful).
Fenomena kontroversi Java dan bahasa nenek moyangnya mungkin seperti saat Linux mempunyai GUI. Orang2 kolot menganggap bahwa command line adalah state of the art, sehingga hanya amatir saja yang pake GUI. Ya bagaimanapun juga cita-cita linux kan Linux untuk semua, profesional pun amatir pun ignorant. Sedikit demi sedikit cita-cita ini mulai dicapai dengan GUI. Analogi di bahasa pemrograman programmer assembly merendahkan C, programmer C merendahkan Java dst. Pun Java mungkin berusaha mewujudkan pemrograman untuk semua, selain juga mendukung ide kalangan struktural (Niklaus Wirth) yang menganggap C pun turunannya C++ adalah bahasa yang gagal menjaga struktur. Lihat kajian ttg bahasa ketat type.
Anda merendahkan programmer bahasa apa?
Deposuit potentes de sede et exaltavit humiles.
Saya yakin semuanya mempunyai tradeoff. Saya de jure memilih C, merendahkan java. Tapi de facto rilis produk saya yang pertama saya buat dengan Java. Terbukti bahwa Java memungkinkan menulis program dengan cepat, IDE gratisan yang berlimpah, support dan potongan kode program yang berlimpah di internet. Dengan C hmm, mampus deh.
Mungkin untuk ke depan saya memang harus mengubah paradigma dan mengikuti kata-kata Achmad Aidit 40an tahun yang lalu "Java adalah kunci". Namun demikian artikel klasik kontra java "Perils of Java School" harus dibaca.
28 Agustus 2007
LISP
Bahasa yang sangat menarik, apalagi bagi mahasiswa baru. Bahasa ini berhasil memberi dogma tentang memprogram yang baik. Bagaimana menghemat memori, bahkan menghemat langkah eksekusi. Bagaimana tidak demikian, bahasa ini aslinya adalah bahasa fungsional yang tidak memiliki state, tidak memiliki assignment. [Sebenarnya bisa juga melakukan assignment, tapi itu bukan aslinya, dan lagi rasanya sulit sekali(aneh karena tidak pernah belajar sungguh-sungguh pada bagian ini) membuat skema program dengan assignment].
Bahasa ini secara natural tidak memiliki variabel, sehingga sebagaimana kita berpikir dalam memanipulasi fungsi matematis, itulah yang dilakukan. Hal ini akan sangat baik untuk memberikan dogma "buat variabel jika dan hanya jika harus dibuat. Proses-proses perulangan dilakukan secara secara rekursif dengan basis dan recurrent yang membutuhkan keyakinan tinggi bahwa program akan berhenti pada tempat yang tepat. Keyakinan ini saya yakin akan membentuk raasa percaya diri programmer dalam mengkonstruksi loop, sehingga tidak mengecek nilai sana-sini berulang-ulang untuk meyakinkan programnya benar.
Perguruan tinggi sekelas MIT masih menggunakan bahasa ini untuk membentuk karakter fundamental pemrograman, program yang digunakan namanya scheme, sedikit berbeda dengan LISP biasanya.
Sebuah tulisan menarik bagi programmer Java tentang LISP ada di the beauty of LISP, yang ada di situs ibm, java. Dalam tulisan ini penulis meyakinkan bahwa programmer java akan bisa membuat program lebih baik setelah belajar LISP.
Sementara resource LISP yang saya rasa paling bagus ada di Paul Graham
Bahasa ini secara natural tidak memiliki variabel, sehingga sebagaimana kita berpikir dalam memanipulasi fungsi matematis, itulah yang dilakukan. Hal ini akan sangat baik untuk memberikan dogma "buat variabel jika dan hanya jika harus dibuat. Proses-proses perulangan dilakukan secara secara rekursif dengan basis dan recurrent yang membutuhkan keyakinan tinggi bahwa program akan berhenti pada tempat yang tepat. Keyakinan ini saya yakin akan membentuk raasa percaya diri programmer dalam mengkonstruksi loop, sehingga tidak mengecek nilai sana-sini berulang-ulang untuk meyakinkan programnya benar.
Perguruan tinggi sekelas MIT masih menggunakan bahasa ini untuk membentuk karakter fundamental pemrograman, program yang digunakan namanya scheme, sedikit berbeda dengan LISP biasanya.
Sebuah tulisan menarik bagi programmer Java tentang LISP ada di the beauty of LISP, yang ada di situs ibm, java. Dalam tulisan ini penulis meyakinkan bahwa programmer java akan bisa membuat program lebih baik setelah belajar LISP.
Sementara resource LISP yang saya rasa paling bagus ada di Paul Graham
Penulisan Header File yang baik
Header file (*.h) merupakan file yang sering diinclude. Oleh karena itu ada beberapa hal penting/sangat penting untuk diperhatikan dalam file header.
0. Berikan preprosesor yang mencegah redefinisi type/class ketika header diinclude berkali-kali.
#if ndef _HEADER_FILE_NAME__
#define(_HEADER_FILE_NAME__)
1. Jangan mendeklarasikan variabel. NEVER EVER do this!
Header file adalah file yang diinclude berkali-kali. Bayangkan akan ada berapa banyak memory terbuang jika selalu terdefinisi, dan lagi hal ini bisa menyebabkan redefinisi variabel yang membuat gagal kompilasi. Lebih lanjut mengenai variabel ini kemungkinan dibutuhkan keajaiban dari keyword extern. Belum kenal keyword ini, yaa jika ada kesempatan anda mengulang mata kuliah dimana bahasa ini diajarkan, seperti saya Y(^-^)
0. Berikan preprosesor yang mencegah redefinisi type/class ketika header diinclude berkali-kali.
#if ndef _HEADER_FILE_NAME__
#define(_HEADER_FILE_NAME__)
1. Jangan mendeklarasikan variabel. NEVER EVER do this!
Header file adalah file yang diinclude berkali-kali. Bayangkan akan ada berapa banyak memory terbuang jika selalu terdefinisi, dan lagi hal ini bisa menyebabkan redefinisi variabel yang membuat gagal kompilasi. Lebih lanjut mengenai variabel ini kemungkinan dibutuhkan keajaiban dari keyword extern. Belum kenal keyword ini, yaa jika ada kesempatan anda mengulang mata kuliah dimana bahasa ini diajarkan, seperti saya Y(^-^)
Body dan Header
Seringkali/selalu programmer menginclude file *.h pada source code program C/C++. Apa, mengapa, bagaimana dengan menginclude file itu suatu fungsi bisa terdefinisi dan jalan?
Sebenarnya yang terjadi file *.h itu adalah header file saja, sementara body fungsi tersimpan sebagai suatu library yang sudah dikompilasi. Dengan membuat struktur semacam ini vendor dapat menjaga kode sumbernya sehingga tidak bisa dicopy orang lain, tapi jika ada orang yang ingin menggunakan fungsi2nya dapat menggunakan header file *.h dengan library yang sudah dikompilasi.
Pada distribusi IDE C/C++ file-file *.h biasanya tersimpan dalam folder include dan file-file library hasil kompilasi bodinya ada di folder library. Pada saat kompilasi biasanya ada direktif -I dan -L atau -LIB. Direktif ini penting ketika menggunakan library diluar IDE yang terletak terpisah dari folder include dan library IDE, misalnya gtk+, openGL, dan qt.
Bagaimana membuat program semacam itu?
Dalam membuat program semacam ini, header harus dipisahkan dari body. Deklarasi type, class, dan header/deklarasi fungsi dan prosedur diletakkan di file *.h, sementara body fungsi dan prosedur dituliskan di file *.c. Lebih lanjut mengenai header file dapat dibaca pada "Penulisan Header File yang baik"
Sebenarnya yang terjadi file *.h itu adalah header file saja, sementara body fungsi tersimpan sebagai suatu library yang sudah dikompilasi. Dengan membuat struktur semacam ini vendor dapat menjaga kode sumbernya sehingga tidak bisa dicopy orang lain, tapi jika ada orang yang ingin menggunakan fungsi2nya dapat menggunakan header file *.h dengan library yang sudah dikompilasi.
Pada distribusi IDE C/C++ file-file *.h biasanya tersimpan dalam folder include dan file-file library hasil kompilasi bodinya ada di folder library. Pada saat kompilasi biasanya ada direktif -I
Bagaimana membuat program semacam itu?
Dalam membuat program semacam ini, header harus dipisahkan dari body. Deklarasi type, class, dan header/deklarasi fungsi dan prosedur diletakkan di file *.h, sementara body fungsi dan prosedur dituliskan di file *.c. Lebih lanjut mengenai header file dapat dibaca pada "Penulisan Header File yang baik"
Ikhtisar
Tulisan ini merupakan napak tilas kuliah bersama Ibu Inggriani Liem(selanjutnya disebut Ibu Inge) sebanyak 19 sks termasuk mengulang. Hal tersebut berikut ini telah saya ketahui sejak saya kuliah bersama beliau, namun saya tidak mengerti sama sekali waktu itu, mengapa harus demikian?. Untung saya masih bisa mengulang agar dapat mengerti materi yang beliau sampaikan. Beberapa minggu ini saya dapatkan tulisan-tulisan DR Edsger W. Dijsktra(RIP 2001). Dari tulisan EWD ini saya dapatkan beberapa alasan mengapa Ibu Inge mengajarkan pemograman seperti yang diajarkan kepada kami.
0. Bahasa Saya (Bahasa Algoritmik karangan Bu Inge), sebenarnya setahu bahasa ini tidak ada namanya, cuma saja beliau pernah bercerita ketika ada orang yang menanyakan bahasa apa yang diajarkan sebagai dosen pemrograman, terus beliau menjawab "bahasa saya".
Bahasa Saya oleh Bu Inge disarankan tidak dibuat kompilatornya. Mengapa? Tulisan Dijkstra pada EWD1036 menjelaskan bahwa pemrograman adalah penulisan dalam bahasa formal matematika, tidak ada kompilatornya sehingga mahasiswa tidak tergoda untuk mencoba program, tapi meyakini kebenarannya dari sketsa. Formula ini cocok untuk fresh man yang belum pernah belajar memprogram, karenanya Bu Inge menekankan untuk tidak mengulang kuliah dasar yang beliau ajarkan. Memang sih, pas mengulang rasanya rada aneh ketika diajar lagi dengan joke yang lebih kurang sama dengan tahun sebelumnya, tapi saya gak mengerti juga tuh. Tulisan ini lebih banyak saya sarikan dari pengambilan kuliah yang pertama daripada yang kedua. Mungkin pas ngambil yang kedua sudah mulai sombong jadi kurang memperhatikan, tapi dasar bego masih saja tidak dapat A.
Meskipun seharusnya menggunakan bahasa yang tidak dapat dikompilasi pada prakteknya bahasa pemrograman yang nyata juga diajarkan. Mungkin ini merupakan suatu bentuk kompromi atas kebutuhan dunia nyata dan kebutuhan kemampuan memprogram pada kuliah-kuliah lainnya. Pilihan sulit memang.
1. Perilaku Program.
Masih EWD1036. "we should reason about programs without even mentioning their possible behaviour". Ini merupakan hal yang sangat sulit dilakukan oleh mahasiswa rata-rata seperti saya. Sungguh. Hal ini ditekankan ketika mengajarkan bahasa fungsional, dan rekursif, dimana perilaku program sulit sekali dilacak. Tapi bukan masalah bisa dilacak atau tidak, toh ada debugger. Namun hal ini merupakan pendekatan bahwa program yang ditulis akan benar, adalah jika secara skematik formal benar, bukan jika dijalankan benar. Oleh karena itu penggunaan flowchart benar-benar dilarang dalam kuliah beliau.
Seingat saya beliau terkadang juga tidak konsisten mengenai hal ini, mengingat tidak semua mahasiswa mampu mencerna dan membuat abstraksi dan meyakini kebenaran program dengan hanya membacanya. Sehingga terkadang perlu menjalankan dengan tangan atau bahkan mengkode di mesin. Ya kemampuan mahasiswa kan macam-macam dari berbagai daerah yang pendidikan dasarnya bervariasi, kalau saya ya tidak mampu dan tidak percaya suatu program benar kalau tidak mencoba, bahkan sampai sekarang ketika sudah mengajar.
Lebih lanjut EWD sangat melarang penggunaan "anthropomorphic terms", anggap saja personifikasi program. Menurut EWD analogi ini sangat dangkal, dan menyesatkan, karena akan menggiring pola berpikir menurut perilaku komputasi, bukan lagi kebenaran semantic operasi. Bagaimanapun perilaku program di mesin berbeda dengan manusia, dimana manusia terus ada dan terus beraksi, sementara program seharusnya dievaluasi berdasarkan kebenarannya bukan perilakunya, apalagi analogi perilakunya pada manusia? Saya perkirakan secara implikatif juga larangan penggunaan flow chart dalam pembuatan kode program juga berkaitan dengan teori ini, namun saya masih belum saya temukan referensinya.
Nah selanjutnya muncul lagi pertanyaan besar, bagaimana dengan Object Oriented yang biasanya menggunakan obyek manusia sebagai model?
Dalam pemahaman saya Kebenaran program D.E. Knuth dalam jilid 1 TAOCP nya menggunakan induksi matematika untuk membuktikan kebenaran program. Benar-benar suatu kekejaman dalam bidang pemograman.
jika
P(1) Benar
P(2),P(3), ..., P(n) Benar
maka
P(n+1) Benar
Benar-benar matematika yang bakal membuat mahasiswa pemrograman mabuk, apalagi yang asal-asalan kuliah kalkulus, atau bahkan tidak mendapat kuliah kalkulus. Dalam buku kalkulus purcell varberg edisi 8, topik ini malah cuma menjadi topik tambahan.
2. Bahasa Ketat Type
Ini merupakan kategori bahasa yang diajarkan untuk fresh man. Mengapa? saya belum temukan referensinya. Namun sedikit banyak dapat saya simpulkan bahwa bahasa ketat tipe akan membentuk pola pikir dan pola kerja yang baik, dimana operasi hanya bisa dilakukan atas data yang tipenya sama. Hal ini dapat dijarkan dengan menggunakan bahasa pascal, karangan Niklaus Wirth, atau bahasa ada. Sebagai programmer yang dibesarkan dengan paradigma ini saya merasa bahwa saya menjadi berhati-hati terhadap type. Pelacakan kesalahan yang cepat juga terbentuk dengan paradigma ini. Program yg ditulis dengan paradigma ini jauh lebih mudah dipahami, karena konsistensi tipenya.
Dalam "plea for lean software", Wirth mengemukakan bahwa abstraksi hanya bisa dilakukan pada suatu bahasa yang ketat type. Bahasa longgar yang memungkinkan semuanya bisa terjadi tidak dapat membuat abstraksi yang jelas. Misalnya casting dalam C, yang memungkin suatu parameter bertype char* bisa-bisa saja dipassing dengan matriks*.
Dalam hal kajian bahasa ketat type menurut Wirth, C telah gagal.
0. Bahasa Saya (Bahasa Algoritmik karangan Bu Inge), sebenarnya setahu bahasa ini tidak ada namanya, cuma saja beliau pernah bercerita ketika ada orang yang menanyakan bahasa apa yang diajarkan sebagai dosen pemrograman, terus beliau menjawab "bahasa saya".
Bahasa Saya oleh Bu Inge disarankan tidak dibuat kompilatornya. Mengapa? Tulisan Dijkstra pada EWD1036 menjelaskan bahwa pemrograman adalah penulisan dalam bahasa formal matematika, tidak ada kompilatornya sehingga mahasiswa tidak tergoda untuk mencoba program, tapi meyakini kebenarannya dari sketsa. Formula ini cocok untuk fresh man yang belum pernah belajar memprogram, karenanya Bu Inge menekankan untuk tidak mengulang kuliah dasar yang beliau ajarkan. Memang sih, pas mengulang rasanya rada aneh ketika diajar lagi dengan joke yang lebih kurang sama dengan tahun sebelumnya, tapi saya gak mengerti juga tuh. Tulisan ini lebih banyak saya sarikan dari pengambilan kuliah yang pertama daripada yang kedua. Mungkin pas ngambil yang kedua sudah mulai sombong jadi kurang memperhatikan, tapi dasar bego masih saja tidak dapat A.
Meskipun seharusnya menggunakan bahasa yang tidak dapat dikompilasi pada prakteknya bahasa pemrograman yang nyata juga diajarkan. Mungkin ini merupakan suatu bentuk kompromi atas kebutuhan dunia nyata dan kebutuhan kemampuan memprogram pada kuliah-kuliah lainnya. Pilihan sulit memang.
1. Perilaku Program.
Masih EWD1036. "we should reason about programs without even mentioning their possible behaviour". Ini merupakan hal yang sangat sulit dilakukan oleh mahasiswa rata-rata seperti saya. Sungguh. Hal ini ditekankan ketika mengajarkan bahasa fungsional, dan rekursif, dimana perilaku program sulit sekali dilacak. Tapi bukan masalah bisa dilacak atau tidak, toh ada debugger. Namun hal ini merupakan pendekatan bahwa program yang ditulis akan benar, adalah jika secara skematik formal benar, bukan jika dijalankan benar. Oleh karena itu penggunaan flowchart benar-benar dilarang dalam kuliah beliau.
Seingat saya beliau terkadang juga tidak konsisten mengenai hal ini, mengingat tidak semua mahasiswa mampu mencerna dan membuat abstraksi dan meyakini kebenaran program dengan hanya membacanya. Sehingga terkadang perlu menjalankan dengan tangan atau bahkan mengkode di mesin. Ya kemampuan mahasiswa kan macam-macam dari berbagai daerah yang pendidikan dasarnya bervariasi, kalau saya ya tidak mampu dan tidak percaya suatu program benar kalau tidak mencoba, bahkan sampai sekarang ketika sudah mengajar.
Lebih lanjut EWD sangat melarang penggunaan "anthropomorphic terms", anggap saja personifikasi program. Menurut EWD analogi ini sangat dangkal, dan menyesatkan, karena akan menggiring pola berpikir menurut perilaku komputasi, bukan lagi kebenaran semantic operasi. Bagaimanapun perilaku program di mesin berbeda dengan manusia, dimana manusia terus ada dan terus beraksi, sementara program seharusnya dievaluasi berdasarkan kebenarannya bukan perilakunya, apalagi analogi perilakunya pada manusia? Saya perkirakan secara implikatif juga larangan penggunaan flow chart dalam pembuatan kode program juga berkaitan dengan teori ini, namun saya masih belum saya temukan referensinya.
Nah selanjutnya muncul lagi pertanyaan besar, bagaimana dengan Object Oriented yang biasanya menggunakan obyek manusia sebagai model?
Dalam pemahaman saya Kebenaran program D.E. Knuth dalam jilid 1 TAOCP nya menggunakan induksi matematika untuk membuktikan kebenaran program. Benar-benar suatu kekejaman dalam bidang pemograman.
jika
P(1) Benar
P(2),P(3), ..., P(n) Benar
maka
P(n+1) Benar
Benar-benar matematika yang bakal membuat mahasiswa pemrograman mabuk, apalagi yang asal-asalan kuliah kalkulus, atau bahkan tidak mendapat kuliah kalkulus. Dalam buku kalkulus purcell varberg edisi 8, topik ini malah cuma menjadi topik tambahan.
2. Bahasa Ketat Type
Ini merupakan kategori bahasa yang diajarkan untuk fresh man. Mengapa? saya belum temukan referensinya. Namun sedikit banyak dapat saya simpulkan bahwa bahasa ketat tipe akan membentuk pola pikir dan pola kerja yang baik, dimana operasi hanya bisa dilakukan atas data yang tipenya sama. Hal ini dapat dijarkan dengan menggunakan bahasa pascal, karangan Niklaus Wirth, atau bahasa ada. Sebagai programmer yang dibesarkan dengan paradigma ini saya merasa bahwa saya menjadi berhati-hati terhadap type. Pelacakan kesalahan yang cepat juga terbentuk dengan paradigma ini. Program yg ditulis dengan paradigma ini jauh lebih mudah dipahami, karena konsistensi tipenya.
Dalam "plea for lean software", Wirth mengemukakan bahwa abstraksi hanya bisa dilakukan pada suatu bahasa yang ketat type. Bahasa longgar yang memungkinkan semuanya bisa terjadi tidak dapat membuat abstraksi yang jelas. Misalnya casting dalam C, yang memungkin suatu parameter bertype char* bisa-bisa saja dipassing dengan matriks*.
Dalam hal kajian bahasa ketat type menurut Wirth, C telah gagal.
Langganan:
Postingan (Atom)