Perhatian
Versi awal publikasi ini menerima tanggapan yang bagus tentang Reddit dalam bentuk lebih dari 300 komentar. Setelah itu, saya memutuskan untuk menambahkan pembaruan kecil untuk menjawab beberapa kritik dari banyak yang diterima.
Bahasa pemrograman visual adalah bahasa yang memungkinkan programmer membuat program dengan memanipulasi elemen grafis daripada mengetik perintah teks. Contoh terkenal adalah
Scratch , bahasa pemrograman visual yang berasal dari MIT yang digunakan untuk mendidik anak-anak. Keuntungannya adalah membuat pemrograman lebih mudah diakses oleh pemula dan non-programmer.
Pada 1990-an, ada gerakan yang sangat populer untuk memperkenalkan pemrograman visual ke dalam lingkungan perusahaan menggunakan apa yang disebut alat
CASE , di mana sistem perusahaan dapat didefinisikan menggunakan
UML dan menghasilkan [kode mereka] tanpa perlu menarik pengembang perangkat lunak yang terlatih. Ini disebabkan oleh konsep “round tripping”, di mana sistem dapat dimodelkan secara visual, kode program akan dihasilkan dari model yang dihasilkan, dan setiap perubahan kode dapat dikembalikan kembali ke model. Sayangnya, alat-alat tersebut belum dapat memenuhi misinya, dan sebagian besar percobaan [pada implementasinya] saat ini sebagian besar ditinggalkan.
Dengan demikian, pemrograman visual belum mendapatkan popularitas, kecuali untuk beberapa area yang sangat terbatas. Situasi ini sebagian besar disebabkan oleh kesalahpahaman berikut tentang pemrograman:
- Bahasa pemrograman teks membingungkan apa yang pada dasarnya adalah proses yang sederhana.
- Abstraksi dan decoupling ( decoupling, mengurangi konektivitas ) memainkan peran perangkat kecil dalam pemrograman.
- Alat yang dirancang untuk membantu pemrograman tidak penting.
Kesalahpahaman pertama menegaskan bahwa pengembangan perangkat lunak memiliki ambang batas yang tinggi untuk masuk, karena bahasa pemrograman teks memperumit sifat pemrograman yang sebenarnya. Popularitas Scratch di kalangan pendidik akademis bermain seiring dengan kesalahpahaman ini. Idenya adalah bahwa pemrograman sebenarnya cukup sederhana, dan jika kita hanya bisa menyajikannya dalam format grafik yang jelas, itu akan secara drastis mengurangi kurva belajar dan upaya mental yang diperlukan untuk membuat dan membaca kode program.
Saya berasumsi bahwa kesalahpahaman ini berasal dari ketidakmampuan untuk benar-benar membaca program khas yang ditulis dalam bahasa pemrograman teks standar dan membayangkan bagaimana hal itu diubah menjadi elemen grafis dari kubus dan panah. Jika Anda masih bisa membayangkan ini, maka akan segera menjadi jelas bahwa satu baris kode sering dicocokkan dengan beberapa "blok". Karena bahkan untuk program paling sederhana keberadaan ratusan atau dua baris kode bukanlah hal yang aneh, kodenya akan berubah menjadi ratusan atau bahkan ribuan elemen grafik. Upaya untuk mem-parsing gambaran kompleks seperti itu akan jauh lebih sulit daripada hanya membaca teks program yang setara.
Solusi untuk sebagian besar bahasa pemrograman visual adalah membuat "blok" lebih kompleks sehingga setiap elemen visual setara dengan blok besar kode teks. Alat visual alur kerja adalah batu sandungan segera.
Masalahnya adalah, kode tersebut masih harus didefinisikan di suatu tempat. Oleh karena itu, proses pengkodean [pada elemen visual yang besar] berubah menjadi “properti dialog pemrograman”. Elemen visual itu sendiri hanya mewakili level tertinggi pergerakan program selama eksekusi, dan sebagian besar pekerjaan sekarang dilakukan dalam kode teks standar yang disembunyikan dalam "kubus" visual. Akibatnya, kami mengambil yang terburuk dari kedua dunia dan mendapatkan pemrograman teks yang tidak didukung oleh alat modern.
Dialog properti biasanya lingkungan pengembangan non-standar dan memaksakan pilihan bahasa tertentu, biasanya bahasa scripting dari beberapa jenis. Elemen-elemen visual dasar itu sendiri hanya dapat dibuat oleh programmer yang berpengalaman, dan mereka dapat dipahami sepenuhnya hanya dengan membaca kode dasar mereka, sehingga sebagian besar manfaat yang diduga dari presentasi visual hilang di sini.
Ada ketidakcocokan impedansi antara "kode" visual dan kode teks (satu
set kesulitan konseptual dan teknis ), dan programmer harus menavigasi antarmuka di antara mereka, sering menghabiskan lebih banyak upaya untuk meningkatkan alat pemrograman grafis itu sendiri daripada menyelesaikan tugas asli [menulis program].
Dan sekarang kita sampai pada kesalahpahaman kedua bahwa abstraksi dan dekuplikasi memainkan peran kecil dalam pemrograman. Pemrograman visual didasarkan pada asumsi bahwa sebagian besar program adalah urutan prosedural sederhana, agak mirip dengan diagram alur. Sebagai aturan, sebagian besar programmer pemula berpikir bahwa perangkat lunak berfungsi seperti itu.
Namun, segera setelah program menjadi lebih dari contoh yang agak sepele, kompleksitasnya akan segera membanjiri programmer pemula. Pemula merasa sangat sulit untuk berbicara tentang basis kode prosedural yang besar dan sering macet dalam upaya untuk menciptakan perangkat lunak skala besar yang stabil dan efisien. Inovasi utama dalam bahasa pemrograman adalah upaya untuk mengendalikan kompleksitas, biasanya melalui abstraksi, enkapsulasi, dan konektivitas yang berkurang. Semua jenis sistem dan konstruksi berorientasi objek dan bahasa pemrograman fungsional sebenarnya hanyalah upaya untuk mengendalikan kompleksitas bahasa-bahasa ini.
Kebanyakan programmer profesional akan terus-menerus mengabstraksi dan memisahkan kode. Sebenarnya, perbedaan antara kode baik dan buruk pada dasarnya adalah seberapa banyak programmer berhasil melakukan ini. Alat pemrograman visual sangat jarang memiliki mekanisme yang efektif untuk hal-hal seperti itu, sebagai akibatnya, pengembang "visual" terperangkap dalam kemampuan yang tersedia, setara dengan BASIC tahun 1970-an.
Kesalahpahaman terakhir adalah bahwa programmer visual seharusnya dapat melakukannya tanpa semua alat pendukung pemrograman yang telah dikembangkan selama beberapa dekade. Lihatlah evolusi panjang editor kode dan IDE. Sebagai contoh, Visual Studio mendukung alat intellisense yang efektif yang memungkinkan Anda untuk mengintip ribuan API yang tersedia di perpustakaan kelas dasar saja. Kurangnya kontrol versi yang baik adalah kelemahan utama lainnya di sebagian besar alat pemrograman visual.
Bahkan jika mereka menyimpan tata letak mereka dalam format teks, "diff" tidak memiliki atau hampir tidak ada artinya. Sangat sulit untuk membuat 'kesalahan' (untuk menemukan komit dan bertanggung jawab untuk mengubah baris tertentu) di blok besar XML atau JSON. Hal-hal yang tidak memiliki arti untuk pelaksanaan fungsional suatu program, seperti posisi dan ukuran elemen grafis, terus-menerus menyebabkan perubahan metadata, yang membuat semakin sulit untuk melakukan parsing.
Bahasa pemrograman teks telah belajar untuk memisahkan blok struktural kode menjadi file sumber yang terpisah, sehingga mudah untuk menggabungkan perubahan di satu bagian sistem dengan perubahan di yang lain. Alat visual biasanya menyimpan hasilnya sesuai dengan prinsip "satu diagram per file", yang berarti penggabungan menjadi bermasalah, dan bahkan lebih sulit jika makna semantik dari "diff" sulit untuk dianalisis.
PerbaruiSaya mungkin salah ketika saya mengambil screenshot Scratch dan menggunakannya sebagai contoh utama dalam paragraf pertama saya. Saya bukan seorang guru dan saya tidak memiliki pendapat sendiri tentang efektivitas Scratch sebagai alat belajar. Banyak orang mengatakan bahwa ini sangat berguna dalam pengajaran pemrograman, terutama untuk anak-anak. Segala sesuatu yang membantu orang masuk ke dunia pemrograman yang indah dan menarik hanya harus dipuji. Saya benar-benar tidak berniat untuk mengkritik secara khusus Scratch sekarang, ini hanyalah contoh dari sistem pemrograman visual, yang, seperti yang menurut saya, sebagian besar pembaca saya seharusnya sudah mendengar setidaknya.
Contoh lain yang disediakan oleh Reddit adalah alat struktur statis seperti perancang UI, perancang skema basis data, atau perancang kelas. Saya setuju bahwa mereka bisa sangat membantu. Apa pun yang membantu memvisualisasikan struktur data atau struktur skala program adalah bonus. Tetapi mereka tidak pernah cukup. Ini dibuktikan dengan kegagalan total alat dari 90-an, seperti Power Builder, yang didasarkan pada visualisasi grafis untuk menciptakan lingkungan pengembangan tanpa perlu bekerja dengan kode.
Tentang penulis:
Catatan, pikiran keras, belajar di depan mata, kesalahpahaman, kesalahan, opini yang murni. Saya Mike Hadlow, pengembang pengabaran. Saya tinggal di dekat Brighton di pantai selatan Inggris.
Terjemahan didukung oleh EDISON Software, sebuah pengembangan perangkat lunak profesional dan perusahaan pengujian .