Dalam artikel saya sebelumnya saya berbicara tentang bagaimana metafora digunakan untuk menyajikan masalah, mengatur panggung untuk bagaimana kita akan berbicara tentang masalah tersebut. Mereka memberikan kerangka pemikiran kita, di satu sisi membantu kita menyelesaikannya, dan di sisi lain mereka membatasi solusi yang kita temukan.
Saya mengakhiri artikel tersebut dengan mengatakan bahwa kami begitu terbiasa untuk menyebut Bahasa Pemrograman “bahasa” yang kami bahkan tidak berhenti sedetik pun untuk memikirkan implikasi yang terbawa (metaferein) ketika kami mempersamakannya dengan bahasa alami.
Tentu saja memperlakukan bahasa pemrograman seperti bahasa alami, sangat membantu. Ini memungkinkan kita untuk berpikir tentang sintaks mereka dan aturan tata bahasa mereka, semantik ekspresi tertentu, dan seterusnya.
Baru-baru ini saya menemukan beberapa kasus di mana dari sudut pandang saya, komunitas PLT terlalu terbawa oleh metafora bahasa sehingga mereka menghilangkan beberapa karakteristik dari bahasa alami ke bahasa pemrograman yang menurut saya tidak berlaku 100% bagi mereka. Seperti yang selalu terjadi dengan metafora, seseorang harus berhati-hati ketika menggunakannya, karena menurut definisi mereka bukan 1 hingga 1 peta dari domain sumber ke domain target.
Dalam artikel A Programmable Programming Language oleh Felleisen et al [4]. penulis mengatakan sesuatu yang menarik perhatian saya berkenaan dengan bagaimana mereka berbicara tentang bahasa pemrograman. Berikut adalah bagian tempat mereka menyajikan prinsip-prinsip apa yang memandu Pemrograman Berorientasi Bahasa (topik artikel mereka).
Dengan cara yang sangat mudah, kita dapat mengatakan bahwa meskipun nama baru, LOP seperti pemrograman dengan DSL yang disematkan, tetapi dalam hal ini mereka mengusulkan bahasa (Raket) yang tujuannya adalah untuk menghilangkan friksi antara eDSL dan bahasa host (lihat artikel mereka untuk definisi lengkap LOP). Saya pikir LOP adalah ide yang sangat menarik dan berkat artikel ini saya pasti ingin mencoba Racket.
Mereka mendefinisikan salah satu pedoman untuk LOP sebagai: Mengubah mekanisme ekstra-linguistik menjadi konstruksi linguistik, dan mereka memperluas:
Seorang programmer LOP yang menggunakan mekanisme ekstra-linguistik secara efektif mengakui bahwa bahasa yang dipilih tidak memiliki kekuatan ekspresif. Berbagai bahasa eksternal yang diperlukan untuk menangani proyek-proyek Java - bahasa konfigurasi, bahasa deskripsi proyek, dan bahasa makefile-mewakili gejala masalah ini. Kami memperlakukan celah tersebut sebagai tantangan di bagian selanjutnya artikel.
Ini adalah hal yang sangat menarik yang mengingatkan kita pada semua hal ini! saat-saat para perancang berbicara tentang, ketika mereka muncul dengan ide baru yang mengubah kehidupan orang-orang, di mana kita berpikir "ini selalu seperti ini, tetapi saya tidak tahu itu bisa menjadi lebih baik". Setelah membaca paragraf itu, saya bertanya-tanya mengapa proyek Java (tetap berada dalam contoh mereka), dibangun dengan berbagai bahasa. Apakah kita benar-benar membutuhkan semua bahasa itu untuk membangun proyek perangkat lunak?
Di sisi lain, setelah melihat apa yang terjadi dengan Scala dan SBT, di mana terkadang proyek membangun deskripsi berakhir dengan ditulis langsung di Scala, saya tidak yakin memiliki satu bahasa yang mencakup semuanya adalah sesuatu yang saya inginkan. Erlang menderita masalah yang sama. RabbitMQ - seperti banyak alat lain yang dibangun di Erlang - memaparkan konfigurasi mereka di Erlang. Itu adalah sumber dari banyak masalah bagi orang yang mencoba menggunakan RabbitMQ tapi itu asing bagi Erlang. Apakah layak untuk memaparkan pengguna ke format konfigurasi alien, hanya agar para pengembang proyek dapat memprogram hanya dalam satu bahasa?
Juga ketika mereka mengacu pada "mekanisme ekstra-linguistik" apakah itu berarti kode yang berbeda seperti dalam semiotika? Dalam artikel sebelumnya saya berbicara bagaimana kode yang berbeda digunakan dalam film. Pikirkan misalnya film yang menunjukkan tokoh protagonis yang sedih, dengan hujan di latar belakang dan bagaimana yang menyatu dengan musik latar belakang dan kadang-kadang bahkan liriknya. Di sana kode yang berbeda bekerja sama untuk menambah makna yang disampaikan oleh adegan itu. Juga memiliki kode yang berbeda, dapat memungkinkan satu komunitas (musik) untuk berevolusi secara independen dari yang lain (film), jadi ketika mereka digunakan dalam persekutuan nanti, kita mendapatkan pengalaman yang lebih kaya. Hal yang sama bisa dikatakan tentang alat-alat membangun vs alat pemrograman, tapi saya ngelantur ...
Kembali ke topik artikel ini, saya ingin melihat kapan metafora bahasa tidak berlaku. Biarkan saya membawa kembali kalimat dari paragraf yang saya kutip di atas:
Seorang programmer LOP yang menggunakan mekanisme ekstra-linguistik secara efektif mengakui bahwa bahasa yang dipilih tidak memiliki kekuatan ekspresif.
Ketika mereka mengatakan kekuatan ekspresif, penulis melampirkan catatan kaki yang berbunyi:
Seperti banyak peneliti bahasa pemrograman, kami berlangganan bentuk lemah dari hipotesis Sapir-Whorf
Jadi apa hipotesis Sapir-Whorf. Hipotesis ini cukup populer di bidang linguistik, karena menjadi semacam legenda urban. Pernahkah Anda mendengar semi-mitos bahwa bahasa Eskimo memiliki banyak kata untuk konsep salju? Ini terkait dengan hipotesis Sapir-Whorf atau hipotesis Relativitas Linguistik. Seperti yang Anda lihat dari teks yang dikutip di atas, penulis berlangganan bentuk yang lemah dari hipotesis. Jadi, apakah dua bentuk ini? Mengutip Wikipedia:
Versi yang kuat mengatakan bahwa bahasa menentukan pemikiran dan bahwa kategori linguistik membatasi dan menentukan kategori kognitif.
Versi yang lemah mengatakan bahwa kategori dan penggunaan bahasa hanya mempengaruhi pemikiran dan keputusan.
Versi yang kuat pada umumnya disepakati salah, sementara ada beberapa eksperimen yang menunjukkan bahwa bahasa ibu kami membentuk cara kami melihat dunia, yaitu cara kami mengkategorikannya. Jika Anda ingin mempelajari lebih lanjut tentang hipotesis ini, saya merekomendasikan membaca bab My Language Limits My Thoughts, dari buku Women Talk More daripada Men… dan Mitos Lain tentang Bahasa yang Dijelaskan [6].
Jadi, sementara saya tidak tahu apa yang penulis maksudkan ketika mereka mengatakan "kami berlangganan bentuk lemah dari hipotesis Sapir-Whorf", saya tidak yakin hipotesis ini berlaku untuk bahasa pemrograman. Atau dengan kata lain, ini adalah peregangan metafora bahasa. Mari kita lihat mengapa.
Sementara dunia adalah sebuah kontinum, kita potong kecil-kecil, kita diskritasikan dengan kata-kata. Kami mengkategorikan dunia dan kategorisasi ini dinyatakan dalam kata-kata dari bahasa kita:
Bahasa membuat pengalaman teratur dengan menciptakan objek diskrit dan stabil dari fluktuasi sensorik yang relatif tidak terdiferensiasi; benda-benda ini diinternalisasi sebagai konsep. [2]
Dan inilah mengapa saya tidak berpikir hipotesis Sapir-Whorf sepenuhnya berlaku untuk bahasa pemrograman. Ketika kami memprogram kami mengkategorikan dunia dalam bahasa Inggris (atau Spanyol, atau bahasa alami lainnya), dan kemudian kami mengkodekannya menjadi sebuah program. Jadi bahasa pemrograman yang saya gunakan, tidak membatasi cara saya melihat dunia. Seperti kata Umberto Eco dalam The Search for The Perfect Language [3]:
Bahasa komputer seperti BASIC atau Pascal, sebenarnya adalah bahasa priori. Mereka tidak bahasa penuh karena sintaks mereka, meskipun ketat, disederhanakan dan terbatas, dan mereka tetap parasit pada bahasa alami yang melampirkan makna ke simbol kosong mereka [...]
Apakah ada metafora lain yang bisa kita gunakan untuk berpikir tentang bahasa pemrograman, selain bahasa. Saya pikir ada: alat. Ini dikemukakan oleh Kenneth Iverson dalam kuliah Turing Award 1979: Notasi sebagai Alat Pikiran [5].
Jika kita berpikir tentang bahasa pemrograman sebagai alat, maka itu menjadi jelas bagaimana beberapa bahasa pemrograman meminjamkan diri secara alami ke masalah yang dalam bahasa lain mungkin - sementara bukan tidak mungkin - sulit untuk dipecahkan. Lihat misalnya Erlang, bahasa yang dirancang untuk pemrograman Concurrency Oriented dan Message Passing, atau Raket itu sendiri, bahasa yang disesuaikan untuk LOP.
Relativitas Linguistik Relatif
Di atas saya berkata, “Saya tidak berpikir hipotesis Sapir-Whorf sepenuhnya berlaku”. Mari jelaskan mengapa saya menulis "sepenuhnya berlaku". Kata-kata membantu kita mengkategorikan dunia di sekitar kita. Mereka membantu kami mendefinisikan konsep. Etimologi kata mendefinisikan sangat menarik, karena membawa gagasan "untuk mengikat, membatasi" (istilah kata juga memiliki etimologi yang sama).
Jadi jika suatu bahasa memengaruhi cara kita mendefinisikan sesuatu, saya dapat melihat bagaimana manifest ini dalam bagaimana programmer dengan latar belakang dalam paradigma bahasa yang berbeda menentukan unit-unit dalam kode mereka. Untuk memberikan contoh: A for loop, sesuatu yang sangat umum dalam bahasa imperatif seperti Java atau C, biasanya diabstraksikan dalam bahasa pemrograman fungsional dengan konstruksi seperti peta dan lipatan. Seorang programmer fungsional yang melihat kode Java, mungkin segera melihat bahwa loop for harus diekstrak ke dalam fungsinya sendiri. Seorang programmer Java mungkin bertanya-tanya mengapa sekelompok fungsi yang tersebar di file dan tampaknya beroperasi pada data yang sama, tidak diabstraksikan ke dalam kelas.
Akan menarik untuk melihat apakah ini benar benar: bahwa paradigma bahasa yang berbeda mempengaruhi apa yang orang-orang tentukan sebagai unit dalam kode mereka, misalnya, ketika mereka memutuskan untuk menerapkan refactoring ekstrak-metode, untuk menyebutkan satu contoh. Sangat menarik untuk dicatat bahwa Forth menyebut unit-unit ini "kata-kata", dan proses refactoring, hanya memfaktorkan [1].
Kesimpulan
Karena metafora sangat umum dalam pembicaraan kita sehari-hari, kita kehilangan jejak ketika kita menggunakannya, yang menghasilkan kita membingkai masalah dalam apa yang mungkin bisa menjadi pengaturan yang salah, seperti yang dijelaskan dalam artikel saya sebelumnya.
Jika kita ingin memikirkan masalah apa yang bisa dipecahkan oleh bahasa pemrograman, dan mana yang mereka buat lebih sulit, saya akan mengatakan lebih baik menggunakan metafora alat, dan melihat di mana bingkai itu dapat membawa kita.
Berkenaan dengan hipotesis Sapir-Whorf, saya pikir itu mungkin berlaku untuk bahasa pemrograman jika kita berpikir tentang apa yang setiap komunitas bahasa umumnya mendefinisikan sebagai unit kode, yaitu: sesuatu yang dapat dibungkus di dalam fungsi / metode dan dengan demikian dinamai , dan tidak dilewatkan dalam diam.