mas n mbak sekalian apa sich kehebatan dan kelemahan delphi dibanding VB, C++ atau laennya makasih atas jawabannya

Sudah jelas dari panjang katanya, DELPHI adalah 6 huruf. VB adalah 2 huruf, C++ adalah 3 huruf. Kalau LAENNYA mungkin agak menang dikit karena 7 huruf. Jadi kesimpulannya: Delphi 3x lebih baik dari VB, 2x lebih baik dari C++, dan cuma kalah 14% dari laennya. Kembali ke topik yang lebih serius... Pertanyaan ini seharusnya diberi kualifikasi akan dipakai dalam bidang apa... Misal mau memprogram robot mungkin lebih baik pakai C atau Assembly, tapi kalau mau membuat aplikasi database mungkin lebih baik pakai delphi dst... dst...

@lmz: Sapa bilang mrogram robot lebih baik pake C atau assembler? :P Saya dulu bikin robot lengan dan beberapa alat elektronik lainnya, pake pascal (waktu itu pake Borland Pascal 7 dan Delphi 1) bisa dan bagus kok, gak sulit juga. Malah mrogram mikrokontroller juga pake pascal, ada kok pascal for embedded device (silakan googling untuk info lebih lanjut). Terlepas beberapa bagian tertentu pake inline assembler, tapi sebagian besar tetep pake pascal. Yg membatasi Delphi atau pascal adalah imajinasi kita sendiri. Memang dalam beberapa hal, mungkin ada batasan2 tertentu (seperti inline assembler), tapi tetep bukan berarti gak bisa. ;) Ah, jadi kangen dunia elektronika lagi, 8 tahun lebih gak nyentuh elektronika lagi. :D Tentang komparasi Delphi dan VB, udah teramat sering dibahas. Gak cuman disini, tapi hampir di seluruh komunitas Delphi dan VB seantero dunia. Kadang sampe bosen bahas itu, dan udah bukan jamannya lagi mengingat VB (for win32) udah dianggap mati sedang Delphi masih terus dikembangkan. Silakan search dan googling sendiri ya. :P

@simba: @lmz: Sapa bilang mrogram robot lebih baik pake C atau assembler? :P Saya dulu bikin robot lengan dan beberapa alat elektronik lainnya, pake pascal (waktu itu pake Borland Pascal 7 dan Delphi 1) bisa dan bagus kok, gak sulit juga. Malah mrogram mikrokontroller juga pake pascal, ada kok pascal for embedded device (silakan googling untuk info lebih lanjut). Terlepas beberapa bagian tertentu pake inline assembler, tapi sebagian besar tetep pake pascal. Yg membatasi Delphi atau pascal adalah imajinasi kita sendiri. Memang dalam beberapa hal, mungkin ada batasan2 tertentu (seperti inline assembler), tapi tetep bukan berarti gak bisa. ;) Ah, jadi kangen dunia elektronika lagi, 8 tahun lebih gak nyentuh elektronika lagi. :D

Saya yang bilang (atau mestinya ketik sih) :). Kalau kak simba membuat dengan pascal ya wajar saja lha wong dasarnya memang fanatik :). Meskipun saya gak pernah bikin robot, tapi setahu saya bukankah C dan Assembly memang lebih umum digunakan untuk kebutuhan itu (terutama u/ pemrograman mikrokontrolernya) daripada pascal? Lagipula kadang-kadang C lebih jelas bagaimana cara kerjanya. Contoh: Delphi syntax: procedure Move(const Source; var Dest; Count: Integer); C++ syntax: extern PACKAGE void __fastcall Move(const void Source, void Dest, int Count); Dalam syntax Delphi hal ini membingungkan (apa itu const Source, tipenya apa dsb.) sedangkan pada syntax C kelihatan bahwa source adalah alamat awal dari block memory asal. dest adalah alamat awal dari block memory tujuan. Misalnya ada pointer p1 dan p2 lalu mau dilakukan copy maka di C tinggal panggil saja. Kalau di Delphi mungkin caranya pakai Move(p1^, p2^, Count) (bener gak sih?) karena yang diambil adalah ALAMAT dari parameternya. Meskipun tipe dari p1^ apabila p1 adalah Pointer (void *) sendiri kurang jelas.

Kalau kak simba membuat dengan pascal ya wajar saja lha wong dasarnya memang fanatik

Hehehehe... fanatik sih jelas gak lah. Gak ada hal positif yg bisa diambil dari kefanatikan. ;) FYI, selain Delphi saya juga bikin program dalam bhs Java, yg secara sintaks masih satu keluarga dgn C. Saya cuman mencoba meluruskan anggapan bahwa Delphi atau pascal hanya bisa (bagusnya) untuk database, padahal kemampuan Delphi jauh lebih dari itu. Stereotip ini jadi ironi ketika yg ngomong justru programmer Delphi juga, sebuah indikasi jelas bahwa programmer tsb gak ngerti kemampuan tool yg dia gunakan. Andai anda bilang bahwa C gak bisa bikin aplikasi database, saya juga akan "memihak" C krn sebenarnya gak begitu juga.

bukankah C dan Assembly memang lebih umum digunakan untuk kebutuhan itu (terutama u/ pemrograman mikrokontrolernya) daripada pascal?

Memang, tapi "umum" bukan berarti yg paling baik atau paling bagus, apalagi sebagai satu2-nya yg bisa. Dan saya sendiri membuktikan hal tsb. Kemudahan dan kecepatan development meningkat jauh ketika saya bikinnya pake bhs tingkat tinggi (pascal) dgn output performance yg boleh dibilang sama. Faktor ketidaktahuan justru sering kali berpengaruh besar. Temen2 kuliah saya dulu banyakan pake C walaupun aslinya dia programmer pascal, bukan krn C lebih baik, tapi krn gak tau kalo ada compiler embeded device untuk pascal. Setelah diberi tau, banyak deh yg "balik" pake pascal. :D

Dalam syntax Delphi hal ini membingungkan (apa itu const Source, tipenya apa dsb.) sedangkan pada syntax C kelihatan bahwa source adalah alamat awal dari block memory asal. dest adalah alamat awal dari block memory tujuan.

Buat saya, untuk contoh di atas, dua2-nya sama2 jelasnya. Kecuali anda gak ngerti pascal, tentu saja sintak C di atas tampak lebih jelas, sebagaimana org yg gak ngerti C menilai sintak pascal lebih jelas. Tapi rasanya hampir semua programmer C sendiri bahkan mengakui bahwa sintak pascal lebih readable drpd C, hal ini jadi topik biasa di forum perbandingan bhs C dan pascal. Tapi biasanya programmer C membalasnya dgn argumen sintak pascal lebih panjang misal "begin" dgn "{", dlsb. ;) Jgn lupa, program2 di Macintosh terutama MacOS classic lebih banyak ditulis pake pascal loh, terlepas OS-nya dibuat pake C (*nix variant). So, saya setuju semua kembali pada pilihan masing2. Pilihan tertentu mungkin baik buat seseorang, tapi belum terbaik buat org lain. Sehingga jgn menganggap pilihan lain berarti tidak bisa, apalagi tidak mungkin. Bahkan, bisa jadi lebih baik, kalo anda lebih menguasainya. ;) FYI, menarik sekali jika kita simak pendapat Hoare (seorang profesor computer science dari Inggris yg menciptakan algoritma quick sort) tentang C berikut:

It is a matter of continuing regret that so few languages have ever been designed to meet that goal, or even to make significant concessions towards it. For example, the programming language C was designed to assist in writing a small single-user operating system (UNIX) for a real-time minicomputer (PDP 11), now thankfully obsolete. For this purpose, its low level of abstraction and plethora of machine-oriented features are entirely appropriate. For all other purposes, they are a nuisance. The successful propagation of the language can be explained by accidental, commercial, historical, and political factors; it is hardly due to any inherent quality as a tool for the reliable creation of sophisticated programs.

Intinya, C lebih dikenal tak lebih karena keterlanjuran daripada sebuah keunggulan. ;) BTW... kok diskusinya jadi pascal vs C ?? pdhal yg ditanyakan delphi vs VB. :D

@simba:

Kalau kak simba membuat dengan pascal ya wajar saja lha wong dasarnya memang fanatik

Hehehehe... fanatik sih jelas gak lah. Gak ada hal positif yg bisa diambil dari kefanatikan. ;) [/quote:747721b941] Lho, sampai memelintir ucapan si linus gitu kok... :).

[quote:747721b941]bukankah C dan Assembly memang lebih umum digunakan untuk kebutuhan itu (terutama u/ pemrograman mikrokontrolernya) daripada pascal?

Memang, tapi "umum" bukan berarti yg paling baik atau paling bagus, apalagi sebagai satu2-nya yg bisa. Dan saya sendiri membuktikan hal tsb. Kemudahan dan kecepatan development meningkat jauh ketika saya bikinnya pake bhs tingkat tinggi (pascal) dgn output performance yg boleh dibilang sama. Faktor ketidaktahuan justru sering kali berpengaruh besar. Temen2 kuliah saya dulu banyakan pake C walaupun aslinya dia programmer pascal, bukan krn C lebih baik, tapi krn gak tau kalo ada compiler embeded device untuk pascal. Setelah diberi tau, banyak deh yg "balik" pake pascal. :D [/quote:747721b941] Terus terang saya gak tau untuk pemrograman microcontroller apa untungnya menggunakan pascal vs. C (selain mungkin familiarity dan syntax yang dianggap lebih jelas) karena toh feature yang dipakai tidak jauh beda (function, variabel, array, struct). Kalau feature yang levelnya lebih tinggi misal scanf() versus ReadLn() jelas pascal menang (saya pernah ikut lomba pemrograman, kalau saya harus mikir caranya membaca angka dari text file berisi data pakai C pasti repot). Tapi biasanya yang diprogram u/ embedded bukan yang begituan kan?

[quote:747721b941]Dalam syntax Delphi hal ini membingungkan (apa itu const Source, tipenya apa dsb.) sedangkan pada syntax C kelihatan bahwa source adalah alamat awal dari block memory asal. dest adalah alamat awal dari block memory tujuan.

Buat saya, untuk contoh di atas, dua2-nya sama2 jelasnya. Kecuali anda gak ngerti pascal, tentu saja sintak C di atas tampak lebih jelas, sebagaimana org yg gak ngerti C menilai sintak pascal lebih jelas. Tapi rasanya hampir semua programmer C sendiri bahkan mengakui bahwa sintak pascal lebih readable drpd C, hal ini jadi topik biasa di forum perbandingan bhs C dan pascal. Tapi biasanya programmer C membalasnya dgn argumen sintak pascal lebih panjang misal "begin" dgn "{", dlsb. ;) Jgn lupa, program2 di Macintosh terutama MacOS classic lebih banyak ditulis pake pascal loh, terlepas OS-nya dibuat pake C (*nix variant). [/quote:747721b941] syntax Delphi sih menurut saya agak kurang jelas karena compiler secara implicit mengambil alamat dari parameter. Sedangkan kalau yang kita punya itu alamatnya, maka kita harus meng-undo kerja compiler ini dengan tanda ^ meskipun tidak jelas apa arti p1^ apabila p1 adalah untyped pointer. Bagaimana kalau tanda ^ nya lupa di Move(p1^, p2^, Count).

So, saya setuju semua kembali pada pilihan masing2. Pilihan tertentu mungkin baik buat seseorang, tapi belum terbaik buat org lain. Sehingga jgn menganggap pilihan lain berarti tidak bisa, apalagi tidak mungkin. Bahkan, bisa jadi lebih baik, kalo anda lebih menguasainya. ;)

But debat gini kan fun... :) Buktinya si bogem posting seperti itu sementara yang terakhir kali thread Delphi v VB sampai 6 page :).

FYI, menarik sekali jika kita simak pendapat Hoare (seorang profesor computer science dari Inggris yg menciptakan algoritma quick sort) tentang C berikut: [quote:747721b941]It is a matter of continuing regret that so few languages have ever been designed to meet that goal, or even to make significant concessions towards it. For example, the programming language C was designed to assist in writing a small single-user operating system (UNIX) for a real-time minicomputer (PDP 11), now thankfully obsolete. For this purpose, its low level of abstraction and plethora of machine-oriented features are entirely appropriate. For all other purposes, they are a nuisance. The successful propagation of the language can be explained by accidental, commercial, historical, and political factors; it is hardly due to any inherent quality as a tool for the reliable creation of sophisticated programs.

Intinya, C lebih dikenal tak lebih karena keterlanjuran daripada sebuah keunggulan. ;) BTW... kok diskusinya jadi pascal vs C ?? pdhal yg ditanyakan delphi vs VB. :D

Sudah baca ini: The Rise of "Worse is Better"? Di situ C vs LISP tapi ada beberapa argumen kenapa C menyebar begitu luasnya meskipun mungkin kurang baik/optimal (juga menurut C.A.R. Hoare).

Unix and C are the ultimate computer viruses.

:)

Lho, sampai memelintir ucapan si linus gitu kok.

Kerjaan iseng gitu kok dianggap fanatisme. It's just for fun, it's just for laugh, kata Tukul. :lol:

(selain mungkin familiarity dan syntax yang dianggap lebih jelas)

Untuk seorang yg udah terbiasa, kesamaan sintaks jelas berdampak sangat besar. Apalagi jika sebelumnya kita udah punya koleksi2 code pascal yg bisa kita implementasikan juga di embeded device. ;)

Bagaimana kalau tanda ^ nya lupa di Move(p1^, p2^, Count).

Ah, kesalahan seperti ini bisa terjadi dimana aja, gak cuman di pascal atau C. Soalnya kita "bicara" pake bhs mesin yg bener2 kaku. Jgn lupa bahwa kesalahan2 seperti ini justru lebih mudah terjadi di C dgn sintaks-nya yg penuh dgn simbol2, misalnya tanda * untuk pointer. Java berusaha mengatasi kelemahan sintaks di C, walaupun buat saya masih tetep kurang readable. :D

But debat gini kan fun.

Selalu asik diskusi kalo lawan diskusi bisa menanggapi dgn fun, instead of emotion. ;)

Di situ C vs LISP tapi ada beberapa argumen kenapa C menyebar begitu luasnya meskipun mungkin kurang baik/optimal (juga menurut C.A.R. Hoare).

Betul. Itu pula yg berusaha disampaikan oleh Linus dalam komentar yg kemudian saya pelintir itu. Tapi saya kurang sependapat. IMO, segala sesuatu yg bertujuan baik seharusnya menggunakan cara yg baik pula. Mungkin cara2 kurang baik bisa lebih cepat menyelesaikan masalah, tapi dampaknya kita akan terbiasa dgn cara2 yg kurang baik tsb. Dan saya pribadi, kurang suka penyelesaian spt itu. Itu sebabnya saya suka pascal, dan mungkin juga Java (terlepas saya kurang suka sintaksnya). Pascal "memaksa" programmer untuk menggunakan cara2 yg baik untuk tujuan yg baik. Walaupun begitu, dgn perkembangan bhs object pascal saat ini, rasanya kita hampir bisa melakukan semua hal seperti yg mampu dilakukan di C, termasuk kekurangannya juga. :P Secara pribadi, saya juga kurang suka melihat perkembangan ini sebab semakin menghilangkan karakteristik bhs pascal itu sendiri. Bahkan developer2 FPC seringkali silang pendapat ttg fitur2 bhs pascal modern yg justru not-pascalish. :D

Nambahin lagi... Terkait artikel "worse is better"... ekstrimisme (bener gak sih bahasanya? :D) sebagaimana fanatisme, juga gak ada untungnya. Apalagi kalo dipadukan ekstrimisme dan fanatisme, wah jadi kacau deh dunia! :lol: Dalam segala hal, aku percaya pasti ada titik tengah. Mungkin gak selalu win-win solution ya, tapi setidaknya gak sampe lose-win solution banget lah. :D Setuju sekali bahwa proses merancang aplikasi yg bener2 bagus akan sangat takes time (tapi gak sampe forever :P) apalagi kalo parameter2 rancangan seringkali berubah berdasarkan fungsi waktu. Solusi tengah antara MIT dan New Jersey (NJ) adalah membuat rancangan yg adaptif terhadap perubahan, tapi tetap menggunakan metode/cara yg benar. Dgn demikian, kita masih bisa develop dgn cepat tanpa harus terlalu mengorbankan desain yg sifatnya "asal jadi dan jalan dulu". Memaksakan desain yg "asal jadi dan jalan dulu" mungkin development-nya bisa lebih cepat. Tapi ingat, seperti yg sering saya bilang, software development seharusnya gak hanya berorientasi produk jadi kemudian selesai. Ada faktor support, maintenance, dan enhancement untuk waktu2 selanjutnya. Kalo desain awal udah ala kadarnya, nanti saat maintenance dan enhancement akan terjadi tambal sulam. Ujung2-nya adalah totally redesign dan rewrite aplikasi. Untuk software2 open source, mungkin ini gak masalah krn developer gak punya kewajiban to deliver product on time. Deadline waktunya bisa loosy banget, makanya gak akan terlalu terasa dampak negatifnya. Tapi untuk sebuah software komersil yg profesional, keterlambatan deadline adalah suatu yg memalukan dan sekaligus merugikan. Lebih baik sedikit melambatkan delivery time daripada kita develop cepat tapi hasilnya unmaintanable. Satu contoh sederhana bagaimana sebuah desain yg adaptif, saya ambil dari desain table aja ya. Misal, kita perlu table untuk menyimpan transaksi pembayaran. Kebutuhan awal hanya ada 3 jenis transaksi saja. Kebanyakan developer yg ingin cepet selesai, mendesain table tsb dgn menjadikan 3 jenis transaksi sbg kolom. Di awal gak ada masalah dan semuanya lancar2 aja. Masalah akan muncul ketika beberapa waktu kemudian client minta ada 7 jenis transaksi dimana ada beberapa jenis transaksi yg berbeda perlakuannya dgn transaksi yg ada sebelumnya. Hal ini tentu gak bisa diselesaikan dgn sekedar menambah kolom jenis transaksi dari 3 jadi 7. Gimana mau membedakan perilakunya, sementara jenis transaksi di desain awal bersifat sbg flag? Mengubah desain seperti itu membutuhkan proses migrasi data krn perbedaan struktur database. Juga perlu mengubah coding yg semula bersifat flag menjadi identifier. Nah lo? :D Desain yg adaptif seharusnya memperlakukan 3 jenis transaksi sejak awal sbg row dgn ID bersifat unique. Development di awal, untuk mempercepat development, ID2 tsb bisa di-hardcode langsung, toh cuman 3. Ketika permintaan client bertambah, desain ini bisa dikembangkan dgn menambah tabel baru sebagai lookup dari ID jenis transaksi dan tabel baru sbg definisi perilaku untuk tiap jenis transaksi. So, struktur database mengalami penambahan tabel, bukan perubahan field tabel. Kita gak perlu repot2 migrasi data ke struktur yg baru. Di sisi coding pun, kita hanya perlu mengubah bagian (class?) yg menerjemahkan ID jenis transaksi dari hardcoded menjadi structured. Pergantian sistem pun bisa seamless dan butuh waktu singkat. ;) Tapi ini sekedar contoh saja. :D Beda kasus beda juga pendekatan desain adaptifnya. Untuk aplikasi2 kecil hingga menengah, kebutuhan desain yg adaptif mungkin kurang terasa. Tapi ketika kita membangun aplikasi2 besar, hal2 seperti ini sangat perlu dipertimbangkan. ;)

Satu lagi perkembangan di masa kini yang membenarkan worse-is-better: PHP dan MySQL :) Dari yang dulunya berkata kalau transaction tidak perlu, tidak ada foreign key karena integrity checking bisa dilakukan di aplikasi, dll. Tapi banyak orang pakai karena dia lebih mudah dari yang lainnya...

The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.

no comment.. :D