Bahasa Pemrograman Visual

Sebagian besar dari kita belajar pemrograman menggunakan bahasa pemrograman "tekstual" seperti Basic, C / C ++, dan Java. Saya percaya itu lebih alami dan efisien bagi manusia untuk berpikir secara visual. Pemrograman visual memungkinkan pengembang untuk menulis program dengan memanipulasi elemen grafis. Saya kira menggunakan pemrograman visual harus meningkatkan kualitas kode dan mengurangi bug pemrograman. Saya mengetahui beberapa bahasa visual seperti App Inventor , Scratch , dan LabView .

Mengapa tidak ada bahasa visual utama yang bertujuan umum untuk pengembang? Apa kelebihan dan kekurangan pemrograman visual?

Secara umum, ada trade-off dalam desain bahasa pemrograman antara kemudahan penggunaan dan ekspresif (kekuatan). Menulis program "Halo, dunia" sederhana dalam bahasa pemula, seperti Scratch atau App Inventor, umumnya lebih mudah daripada menulisnya dalam bahasa pemrograman tujuan umum seperti Java atau C ++, di mana Anda mungkin memiliki beberapa pilihan aliran untuk output ke, set karakter yang berbeda, kesempatan untuk mengubah sintaks, tipe dinamis, dll.

Selama pembuatan App Inventor (yang merupakan bagian dari saya), filosofi desain kami adalah membuat pemrograman menjadi mudah bagi pemula. Contoh sepele mendasarkan indeks array kami pada 1, bukan 0, meskipun itu membuat perhitungan cenderung dilakukan oleh programmer maju sedikit lebih kompleks.

Namun, cara utama bahwa bahasa pemrograman visual cenderung dirancang untuk pemula adalah dengan menghilangkan kemungkinan kesalahan sintaksis dengan membuatnya tidak mungkin untuk membuat program yang secara sintaksis tidak valid. Misalnya, bahasa blok tidak membiarkan Anda menilai tujuan tujuan penugasan. Filosofi ini cenderung menghasilkan tata bahasa dan bahasa yang lebih sederhana.

Saat pengguna mulai membuat program yang lebih kompleks dalam bahasa blok, mereka menemukan bahwa menyeret dan menjatuhkan blok lebih lambat daripada mengetik. Apakah Anda lebih suka mengetik "a * x ^ 2 + b * x + c" atau membuatnya dengan blok?

Keadilan tidak dapat diberikan pada topik ini (setidaknya oleh saya) dalam beberapa paragraf, tetapi beberapa alasan utama adalah:

1. Bahasa blok cenderung dirancang untuk pemula sehingga tidak sekuat desain.
2. Tidak ada cara visual yang bagus untuk mengekspresikan beberapa konsep kompleks, seperti sistem tipe, yang Anda temukan dalam bahasa pemrograman untuk tujuan umum.
3. Menggunakan blok sangat sulit untuk program yang kompleks.

Mengapa tidak ada bahasa visual utama yang bertujuan umum untuk pengembang? Apa kelebihan dan kekurangan pemrograman visual?

Bahasa visual cenderung memecahnya tiga kategori besar:

1. Alat non-programmer untuk melakukan tugas-tugas otomatisasi dasar. Pikirkan Automator di Mac.
2. Belajar lingkungan di mana tidak praktis untuk memiliki banyak pengetikan, atau di mana struktur program yang menunjukkan aliran logis adalah penting. Think Scratch, Alice, dll.
3. Masalah yang sedang ditangani adalah masalah aliran data, dan solusi untuk masalah tersebut dimodelkan dengan baik oleh semacam aliran data antara kotak mandiri yang meniru dunia fisik. LabView dan Ableton keduanya muncul dalam pikiran.

Keuntungan pemrograman visual adalah Anda mendapatkan gambaran umum tingkat tinggi dari struktur sistem. Ini mengarah ke masalah langsung bahwa ketika Anda mendapatkan detail, kode spageti Anda benar-benar terlihat seperti spageti . Komponen umum bahasa visual adalah semacam blok kode atau komponen konfigurasi untuk elemen visual. Masalahnya adalah bahwa pemrogram perlu memahami blok kode terputus yang mungkin saling terkait dengan cara yang aneh.

Meskipun tidak ada yang salah dengan pemrograman visual, ini mungkin bukan pendekatan yang baik untuk sebagian besar tugas.

Ada banyak bahasa pemrograman visual, seperti yang akan ditunjukkan oleh dua bibliografi berikut: vlib.org dan oregonstate.edu .

IMHO mereka gagal mendapatkan traksi, karena walaupun mereka bagus untuk contoh mainan, mereka gagal mengelola berbagai tingkat abstraksi, representasi, dan rincian yang dibutuhkan proyek besar. Anda perlu melihat sistem seperti AutoDesk Revit (sistem manajemen informasi bangunan yang digunakan oleh arsitek dan insinyur) untuk melihat bagaimana rumitnya mengelola informasi visual dapat menjadi.

Daripada melihat pemrograman tujuan umum, pemrograman visual kemungkinan besar akan berhasil sebagai alat konfigurasi di domain khusus.

Teks itu visual.

Kami menggunakan semua jenis isyarat visual dalam kode kami. Setiap penggunaan spasi putih (indentasi, baris baru, baris kosong, spasi intraline) diarahkan untuk memberikan isyarat visual untuk fungsionalitas kode. Kami menggunakan semua jenis sintaks yang berbeda untuk memberikan informasi visual tentang apa yang dilakukan kode. Editor kami mewarnai kode kami untuk membuatnya menonjol.

Matematika bersifat tekstual. Ada semua jenis notasi, tetapi pada akhirnya sampai pada dasarnya teks. Mereka telah melakukannya selama ratusan tahun.

Maksud saya: representasi tekstual dari kode memanfaatkan kemampuan visual yang dimiliki manusia. Kita mungkin dapat memanfaatkannya dengan lebih baik, tetapi tidak dengan meninggalkan teks.

[Untuk versi PDF dari balasan ini , angka atau diagram bersifat interaktif dan dinamis.]

Elemen dan Anotasi Bersih: Bahasa Pemrograman Visual Tujuan Umum

Saya menggunakan grafik untuk mengatur program JavaScript ™ yang menggunakan Acrobat® / JavaScript API. Setiap objek grafik mewakili elemen Petri Net (tempat, transisi, input atau output) atau mewakili lebih dari satu elemen Petri Net. Setiap objek grafik sebenarnya merupakan anotasi dari elemen bersih yang sesuai. Namun, jika setiap objek grafik memetakan ke satu dan hanya satu elemen bersih itu dapat digunakan untuk menghasilkan elemen bersih. Dan jika objek grafik memetakan ke lebih dari satu elemen bersih dan pemetaannya didefinisikan dengan baik maka itu juga dapat digunakan untuk menghasilkan elemen bersih. Elemen Petri Net standar diwakili oleh jenis grafik tertentu: lingkaran adalah tempat, persegi atau persegi panjang atau garis adalah transisi, panah dari lingkaran ke persegi adalah input dan panah dari persegi ke lingkaran adalah keluaran. Selanjutnya,

[Jenis anotasi dalam "Standar Petri Net" ditemukan dalam versi PDF dari balasan ini.]

Carl Adam Petri menggambarkan sebagian besar gagasan ini (termasuk jenis anotasi dalam "Standar Petri Net" dalam disertasi doktoralnya (Petri, 1966). Ia juga menerapkan elemen bersih dan anotasi pada deskripsi beberapa rangkaian logika, seperti Gambar 6.

Manfaat dan Tantangan

Bahasa pemrograman visual dapat membantu programmer komputer mengembangkan program komputer (Menzies, 2002).

Saya memiliki setidaknya tiga alasan mengapa saya menemukan elemen bersih dan anotasi bermanfaat (keuntungan?).

Alasan pertama. Logika proses dapat dibuat satu elemen pada satu waktu. Ini berarti bahwa jaring dapat diperpanjang dengan menambahkan elemen ke jaring yang ada (Petri, 1966). Misalnya, model pengontrol dapat dibagi menjadi komponen internal dan eksternal. Komponen internal mengatur sistem. Komponen eksternal berinteraksi dengan lingkungan dengan menerima input dari lingkungan. Gambar 1 adalah model Petri Net dari komponen internal. Dimungkinkan untuk menambahkan model Petri Net dari komponen eksternal ke model Petri Net dari komponen internal dengan menambahkan tempat dan transisi yang sesuai (Gambar 2).

Gambar 1 Model Petri Net dari Komponen Internal Pengontrol (Halloway, Krogh dan Giua, 1997)

Gambar 2 Model Petri Net dari Komponen Internal dan Eksternal Pengendali (Halloway, Krogh dan Giua, 1997)

Alasan kedua Kode yang terkait dengan setiap elemen bersih dapat berasal dari lebih dari satu "bahasa pemrograman" (Petri, 1973). Mereka dapat berasal dari bahasa komputer seperti JavaScript, COBOL, ADA dan bahasa assembly. Mereka dapat berasal dari bahasa matematika seperti simbol aljabar. Mereka dapat berasal dari prosa yang disandikan dalam bahasa Inggris, Jerman, Prancis, Yunani, Tagalog, Cina, dll. Dengan demikian, ini dapat digunakan sebagai dasar untuk komunikasi dan kolaborasi di seluruh siklus hidup pengembangan perangkat lunak atau sistem; dan di antara pengguna, pengembang, dan pemangku kepentingan yang berbeda (Petri, 1973).

Alasan ketiga. Dimungkinkan untuk fokus pada objek grafis tertentu di internet dan untuk menulis kode atau anotasi logika untuk objek grafik terkait. Pertimbangkan model Petri Net dari permainan kartu pada Gambar 3. Jika panah untuk input P7  T4 adalah grafik standar untuk input di Jaringan Tempat / Transisi dan jika m_7 adalah tanda untuk tempat P7 maka anotasi logika untuk memperbarui tanda tempat input adalah m_7 = m_7-1. Jika s_9 ^ - adalah status input maka penjelasan logis untuk memperbarui status input adalah s_9 ^ - = ((m_7 <1)? False: true).

Gambar 3 Model permainan kartu Petri Net

Saya memiliki setidaknya tiga alasan mengapa saya merasa aplikasi Petri Nets menantang (kerugian?)

Jika ada terlalu banyak objek grafis maka akan sulit untuk membuat atau membaca internet. Kesulitan dapat dikurangi dengan mengambil subset dari grafik dan mewakili mereka menggunakan satu, dua atau tiga simbol grafik (Noe, 1973; Petri, 1966). Misalnya, jika model Petri Net dari permainan kartu pada Gambar 3 dianggap memiliki terlalu banyak objek grafik dalam diagram, dimungkinkan untuk menggabungkan beberapa grafik dan masih mempertahankan informasi yang cukup untuk memetakan diagram ke dalam program komputer. Pertimbangkan Gambar 4, model Petri Net dari game yang sama yang ditemukan pada Gambar 3 dengan grafik tingkat tinggi (Chionglo, 2016a).

Gambar 4 Model Petri Net dari Permainan Kartu menggunakan Grafis Tingkat Tinggi (Chionglo, 2016a)

Dalam contoh lain, komponen eksternal dari pengontrol pada Gambar 2 dapat dikombinasikan untuk membuat representasi grafis yang lebih ringkas seperti yang ditunjukkan pada Gambar 5.

Gambar 5 Model Pengendali Petri Net dengan Grafis Tingkat Tinggi untuk Komponen Eksternal

Akhirnya, satu set tempat yang saling eksklusif atau satu set transisi yang saling eksklusif juga dapat diwakili menggunakan objek grafis tingkat tinggi (Chionglo, 2015).

Alasan kedua Bahkan dengan grafik standar, sulit untuk menggambar dan memposisikan grafik terutama jika seseorang berharap diagram akhir ramah-pengguna atau ramah-pembaca. Beberapa keputusan untuk membuat diagram yang ramah pengguna atau pembaca meliputi: tata letak yang tepat dari objek grafis, dimensi kanvas dan bentuk yang sesuai, kelengkungan panah, jenis kepala panah, ukuran dan font teks, dan pilihan warna untuk grafik dan teks.

Alasan ketiga. Sangat mudah untuk membuat anotasi elemen bersih secara teratur karena setiap anotasi terkait langsung atau tidak langsung dengan elemen bersih. Namun, menampilkan setiap anotasi bersama dengan grafis dari setiap elemen bersih mungkin bukan ide yang baik karena mungkin ada terlalu banyak informasi yang disajikan dalam diagram. Sebagai contoh, perhatikan diagram model Petri Net dari rangkaian logika yang menyertakan referensi ke semua properti dan penjelasan logika (Gambar 6). [Model asli termasuk kondisi pengujian untuk status untuk setiap output (gambar 31 pada halaman 78 dari (Petri, 1966)); kondisi pengujian dihilangkan di sini karena ini setara dengan model asli untuk pemberian awal yang diberikan. Jadi setiap output memiliki satu anotasi logika untuk menghitung tanda tempat output.]

Gambar 6 A Place / Transition Net dengan anotasi - berdasarkan gambar 31 halaman 78 dari terjemahan disertasi Petri (1966)

Salah satu cara untuk mengurangi tantangan ini adalah dengan mengidentifikasi jenis-jenis anotasi yang digunakan dalam model, dan untuk menentukan objek-objek grafik yang menyertakan anotasi dari tipe-tipe ini (Petri, 1966). Jadi ketika diagram Petri Net terdiri dari objek grafis dari definisi, interpretasi objek-objek ini harus mencakup anotasi “tidak terlihat”. Gambar 7 harus ditafsirkan sebagai Standar Petri Net (lihat Anotasi dari Net Petri Standar untuk definisi); Oleh karena itu, penjelasan logika dapat dihilangkan dari diagram.

Gambar 7 A Place / Transition Net - berdasarkan gambar 31 halaman 78 dari terjemahan disertasi Petri (1966)

Cara lain untuk mengurangi tantangan ini adalah dengan menggunakan tampilan formulir anotasi untuk melengkapi atau melengkapi diagram (Chionglo, 2016b; 2014). Tampilan lebih lanjut dapat dibagi menjadi tampilan yang lebih kecil, dan setiap tampilan dapat ditampilkan dan disembunyikan.

Referensi

Chionglo, JF (2016a). Jawaban untuk "Bagaimana merancang aliran negara untuk permainan flashcard react / redux?" Di Stack Overflow. Tersedia di https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .

Chionglo, JF (2016b). Dua bentuk tampilan dari Petri Net. Tersedia di http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Chionglo, JF (2015). Mengurangi jumlah grafik elemen bersih dalam diagram Petri Net menggunakan grafik tingkat tinggi. Tersedia di http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Chionglo, JF (2014). Elemen dan Anotasi Bersih untuk Pemrograman Komputer: Komputasi dan Interaksi dalam PDF. Tersedia di https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Halloway, LE; Krogh, BH dan Giua, A. (1997). Survei metode Petri Net untuk sistem acara diskrit yang dikendalikan [versi elektronik]. Sistem Dinamik Acara Diskrit: Teori dan Aplikasi, Vol. 7. Boston: Penerbit Akademik Kluwer, hlm. 151 - 190.

Menzies, T. (2002). Masalah evaluasi untuk bahasa pemrograman visual. Di SK Chang (Ed). Buku Pegangan Rekayasa Perangkat Lunak & Teknik Pengetahuan, Vol. 2 Teknologi Baru. World Scientific Publishing co. Pte. Ltd., hlm. 93 - 101.

Noe, JD dan Nutt, GJ (1973). "Makro E-Nets untuk Representasi Sistem Paralel", Transaksi IEEE pada Komputer, vol. C-22, No. 8, Agustus 1973, hlm. 718 - 727.

Petri, CA (1973). Konsep Teori Bersih. Dalam Yayasan Matematika Ilmu Komputer: Proc. dari Simposium dan Sekolah Musim Panas, Tatras Tinggi, 3 - 8 September 1973, halaman 137 - 146. Matematika. Inst. dari Slovad Acad. Ilmu Pengetahuan, 1973.

Petri, CA (1966). Komunikasi dengan Automota [trans. CF Greene, Jr]. Tambahan I untuk Laporan Teknis RADC-TR-65-377 (Volume I). Pangkalan Angkatan Udara Griffiss, NY: Pusat Pengembangan Udara Roma, Divisi Penelitian dan Teknologi, Komando Sistem Angkatan Udara, Pangkalan Angkatan Udara Griffiss. Diperoleh 31 Agustus 2011 dari http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .

Johne Percival Hackworth :

Meskipun tidak ada yang salah dengan pemrograman visual, ini mungkin bukan pendekatan yang baik untuk sebagian besar tugas.

Mungkin, bahasa pemrograman visual sampai saat ini terlalu tidak matang? Gagasan bahwa visualisasi canggih tidak dapat diterapkan pada artefak perangkat lunak dan bahwa mereka sepenuhnya bergantung pada 'imajinasi' masing-masing pengembang untuk menggulirkannya sendiri mungkin merupakan asumsi yang salah. Menaikkan level abstraksi dengan cara yang seragam dan otomatis tampak jelas, sehingga selama kemampuan untuk melakukan abstraksi tingkat rendah dan kinerja eksekusi yang tinggi tidak dikorbankan. Hal ini pada akhirnya dapat mengarah pada 'pemrograman' pakar domain, tidak jauh berbeda dari cara spreadsheet mengotomatiskan tugas programmer COBOL untuk memanipulasi angka. Perbedaan utama di sini adalah mengganti angka dengan manipulasi 'sistem umum.'

Anda dapat melihat Pemrograman Tanpa Teknologi Pengodean (PWCT)

PWCT adalah bahasa pemrograman visual tujuan umum yang memungkinkan pengembangan sistem dan aplikasi dengan menghasilkan langkah-langkah interaktif alih-alih menulis kode.

Ini adalah tempat yang baik untuk memulai dan open source .

pertanyaan sulit. pemrograman berbasis visual atau aliran memang menjadi lebih banyak digunakan tetapi tidak banyak digunakan dibandingkan dengan semua bahasa pemrograman. faktor signifikan adalah pemeliharaan dan standardisasi. kode komputer dapat dicetak pada halaman. tidak selalu begitu jelas bagaimana cara mencetak program visual.

berbeda dengan jawaban teratas saat ini saya berpendapat tidak ada batasan teoritis yang melekat pada kekuatan pemrograman visual vs bahasa tekstual. sebenarnya pemrograman visual dapat dilihat sebagai lebih mudah untuk dipertahankan suatu hari nanti berdasarkan pada konseptualisasi manusia yang lebih cepat dari banyak lapisan abstraksi . jadi tampaknya ada unsur yang keliru dari inersia sosial / budaya / konservatisme dalam upayanya.

editor visual mungkin jauh lebih kompleks dalam kode mereka, dan ini sangat sulit mengingat bahwa bahkan hanya IDE berbasis teks dapat menjadi sangat kompleks misalnya Eclipse , perhatikan ada plugin berorientasi pemrograman visual ke beberapa IDE seperti eciplse misalnya untuk bangunan GUI. pemrograman visual untuk bangunan GUI cukup luas sekarang.

Tampak bagi saya bahwa penggunaan pemrograman visual meningkat di daerah-daerah tertentu dan yang lama dari sekarang mungkin menjadi lebih umum.

jangan lupa bahwa pemrograman visual melekat pada desain chip EE selama beberapa dekade di mana itu bukan abstraksi dan (sub) sistem diletakkan dalam desain 2d persis seperti yang dimaksudkan.

kit mindstorms Lego , sekarang tersebar luas & berusia lebih dari satu dekade, selalu memiliki perangkat lunak pengembangan berdasarkan pemrograman visual, sekarang disederhanakan secara signifikan pada banyak versi.

di sini adalah artikel terbaru yang menarik menganalisis sejarah dan prospek dan menyarankan itu mungkin menjadi lebih umum untuk pemrograman berbasis web. Secara dinamis meletakkan kontrol / widget pada halaman adalah varian dari pemrograman berbasis visual.

kunci lain / bidang yang muncul di mana ia digunakan secara luas di banyak alat adalah BPM, pemodelan proses bisnis.

• Bagaimana Metode Pengodean Arcane Dari Perangkat Lunak Perbankan 1970-an Dapat Menghemat Sanitas Pengembang Web Di Mana Saja (Perusahaan Cepat)

• BPM, pemodelan proses bisnis wikipedia

Saya kira alasan mengapa solusi ini tidak begitu populer, karena dalam banyak kasus mereka bisa tidak dapat dikelola dan menjadi berantakan.

Hampir semua alat pemrograman visual yang tersedia di luar sana saat ini adalah bagian dari aplikasi yang lebih besar dan digunakan untuk tujuan tertentu (mis: Cetak Biru di UE4).

Pokoknya yang baru saya temui baru-baru ini untuk pemrograman umum adalah Korduene yang sebenarnya bukan tujuan umum, karena lebih untuk membuat aplikasi windows.

Saya pikir @Raphael dan lainnya salah ketika mereka mengatakan sebuah program adalah teks. Bukan itu. Banyak hal. Ia memberi tahu komputer apa yang harus dilakukan, atau bagaimana melakukannya. (imperactive, declarative programming) Asosiasi pemrograman dengan pengeditan teks adalah dogma historis dan berlawanan dengan intuisi. Yang dibuat oleh input / output tekstual terbatas dari komputer awal. Orang-orang bukan pengurai teks!

Sementara saya berpikir bahwa orang-orang benar bahwa bahasa yang sepenuhnya visual (di mana Anda melakukan apa pun secara visual, dengan menghubungkan elemen melalui mouse dan semacamnya) tidak praktis untuk bahasa tujuan umum, saya pikir semua bahasa saat ini dapat dan harus dipindahkan ke perantara. tingkat. Di mana elemen bahasa memiliki representasi visual, yang disimpan dalam file bahasa biner. Programmer tidak akan mengetik teks seperti orang gila, atau hidup di bawah mantra garis dan lekukan.

Tapi memasukkan elemen melalui kombinasi hotkey / command / UI yang paling produktif. Dan hanya mengetikkan string dan data serta pengidentifikasi lainnya. Ini akan membuat kesalahan sintaks tidak mungkin dan membuat bahasa dengan keselamatan dan kebenaran dalam pikiran (misalnya: ADA) jauh lebih produktif. Dan juga akan membuat orang lain lebih aman dan kurang buggy, dengan membuat seluruh kelas kesalahan umum menjadi tidak mungkin. (Seperti yang ADA cegah dengan tidak praktis)

Untuk beberapa hal segala sesuatunya menuju ke sini. Dengan lekukan otomatis dan pewarnaan sintaks. Sayangnya tidak ada yang menyadari (atau cukup peduli) bahwa itu adalah konsep inti dari "pengurai teks manusia" adalah apa yang salah. Argumen emacs vs vim lucu karena keduanya salah. Mereka adalah "solusi" untuk masalah yang diciptakan secara artifisial.