Lua di Moskow 2019: Wawancara dengan Roberto Ierusalimschy



Beberapa waktu lalu, pencipta bahasa pemrograman Lua, Roberto Ierusalimschy, mengunjungi kantor kami di Moskow. Kami menanyakan beberapa pertanyaan yang kami siapkan dengan partisipasi pengguna Habr.com juga. Dan akhirnya, kami ingin berbagi versi teks lengkap dari wawancara ini.

- Mari kita mulai dengan beberapa masalah filosofis. Bayangkan, jika Anda menciptakan Lua dari awal, tiga hal manakah yang akan Anda ubah di Lua?

- Wow! Itu pertanyaan yang sulit. Ada begitu banyak sejarah yang tertanam dalam penciptaan dan pengembangan bahasa. Itu tidak seperti keputusan besar sekaligus. Ada beberapa penyesalan, beberapa di antaranya saya punya kesempatan untuk memperbaiki selama bertahun-tahun. Orang-orang mengeluh tentang itu sepanjang waktu karena kompatibilitas. Kami melakukannya beberapa kali. Saya hanya memikirkan hal-hal kecil.

- Global-oleh-default? Apakah Anda pikir ini jalannya?

- Mungkin. Tetapi sangat sulit untuk bahasa yang dinamis. Mungkin solusinya adalah tidak memiliki default sama sekali, tetapi akan sulit untuk menggunakan variabel itu.

Misalnya, Anda harus mendeklarasikan semua pustaka standar. Anda menginginkan one-liner, print(sin(x)) , dan kemudian Anda harus mendeklarasikan 'print' dan juga menyatakan 'sin'. Jadi agak aneh memiliki deklarasi untuk skrip yang sangat pendek.

Apa pun yang lebih besar seharusnya tidak memiliki standar, saya pikir. Local-by-default bukan solusinya, itu tidak ada. Ini hanya untuk tugas, bukan untuk penggunaan. Sesuatu yang kami tetapkan, lalu kami gunakan dan kemudian tetapkan, dan ada beberapa kesalahan - sepenuhnya membingungkan.

Mungkin global-by-default tidak sempurna, tetapi yang pasti local-by-default bukanlah solusi. Saya pikir semacam deklarasi, mungkin deklarasi opsional ... Kami sering mengajukan proposal ini - semacam deklarasi global. Tetapi pada akhirnya, saya pikir masalahnya adalah orang mulai meminta lebih dan lebih dan kita menyerah.

(sarkastik) Ya, kita akan menaruh beberapa deklarasi global - tambahkan itu dan itu dan itu, keluarkan itu, dan pada akhirnya kita memahami kesimpulan akhir tidak akan memuaskan kebanyakan orang dan kita tidak akan menempatkan semua opsi yang diinginkan semua orang, jadi kami tidak menaruh apapun. Pada akhirnya, mode ketat adalah kompromi yang masuk akal.

Ada masalah ini: lebih sering daripada tidak kita menggunakan bidang di dalam modul misalnya, maka Anda memiliki masalah yang sama lagi. Ini hanya satu kasus kesalahan yang sangat spesifik yang harus dimasukkan oleh solusi umum. Jadi saya pikir jika Anda benar-benar menginginkannya, Anda harus menggunakan bahasa yang diketik secara statis.

- Global-by-default juga bagus untuk file konfigurasi kecil.

- Ya, tepatnya, untuk skrip kecil dan sebagainya.

- Tidak ada pengorbanan di sini?

- Tidak, selalu ada pengorbanan. Ada kompromi antara skrip kecil dan program nyata atau sesuatu seperti itu.

- Jadi, kita kembali ke pertanyaan besar pertama: tiga hal yang akan Anda ubah jika Anda punya kesempatan. Seperti yang saya lihat, Anda cukup senang dengan apa yang kita miliki sekarang, benarkah itu?

- Yah, itu bukan perubahan besar, tapi masih ... Utang buruk kita yang menjadi perubahan besar adalah nol dalam tabel. Itu sesuatu yang sangat saya sesali. Saya melakukan implementasi semacam itu, semacam peretasan ... Apakah Anda melihat apa yang saya lakukan? Saya mengirim versi Lua sekitar enam bulan atau setahun yang lalu yang memiliki nil dalam tabel.

- Nilai nol?

- Tepat. Saya pikir itu disebut nils di tabel - apa yang disebut null. Kami melakukan beberapa peretasan dalam tata bahasa untuk membuatnya agak kompatibel.

- Mengapa itu dibutuhkan?

- Saya benar-benar yakin bahwa ini adalah masalah lubang keseluruhan ... Saya pikir sebagian besar masalah nil dalam array akan hilang, jika kita dapat memiliki [nil dalam tabel] ... Karena masalah sebenarnya bukan nil dalam array. Orang mengatakan kita tidak bisa memiliki nil dalam array, jadi kita harus memisahkan array dari tabel. Tetapi masalah sebenarnya adalah bahwa kita tidak dapat memiliki nils di tabel! Jadi masalahnya adalah dengan tabel, bukan cara kita mewakili array. Jika kita bisa memiliki nil dalam tabel, maka kita akan memiliki nil dalam array tanpa yang lain. Jadi ini adalah sesuatu yang saya sesali, dan banyak orang tidak mengerti bagaimana keadaan akan berubah jika Lua mengizinkan nil dalam tabel.

- Bolehkah saya bercerita tentang Tarantool? Kami sebenarnya memiliki implementasi nol kami sendiri, yang merupakan CDATA ke null-pointer. Kami menggunakannya di mana celah dalam memori diperlukan. Untuk mengisi argumen posisi ketika kita melakukan panggilan jarak jauh dan sebagainya. Tetapi kami biasanya menderita karena CDATA selalu dikonversi menjadi 'benar'. Jadi nils dalam array akan menyelesaikan banyak masalah kita.

- Ya saya tahu. Itulah tepatnya poin saya - ini akan memecahkan banyak masalah bagi banyak orang, tetapi ada masalah kompatibilitas yang besar. Kami tidak memiliki energi untuk merilis versi yang sangat tidak kompatibel dan kemudian memecah komunitas dan memiliki dokumentasi yang berbeda untuk Lua 5 dan Lua 6 dll. Tapi mungkin suatu hari kita akan merilisnya. Tapi itu perubahan yang sangat besar. Saya pikir seharusnya sudah seperti itu sejak awal - jika itu, itu akan menjadi perubahan sepele dalam bahasa, kecuali untuk kompatibilitas. Ini merusak banyak program, dengan cara yang sangat halus.

- Apa kerugiannya kecuali untuk kompatibilitas?

- Selain kompatibilitas, downside adalah bahwa kita akan membutuhkan dua operasi baru, dua fungsi baru. Seperti 'hapus kunci', karena menetapkan nil tidak akan menghapus kunci, jadi kami akan memiliki semacam operasi primitif untuk menghapus kunci dan benar-benar menghapusnya dari tabel. Dan 'tes' untuk memeriksa di mana tepatnya untuk membedakan antara nol dan tidak ada. Jadi kita membutuhkan dua fungsi primitif.

- Sudahkah Anda menganalisis dampaknya terhadap implementasi nyata?

- Ya, kami merilis versi Lua dengan itu. Dan seperti yang saya katakan, kode rusak dalam banyak cara yang halus. Ada orang yang melakukan table.insert (f (x)) - panggilan ke suatu fungsi. Dan itu disengaja, itu dirancang bahwa ketika suatu fungsi tidak ingin memasukkan apa pun, ia mengembalikan nol. Jadi, bukannya cek terpisah "apakah saya ingin memasukkan?", Lalu saya memanggil table.insert, dan mengetahui bahwa jika nihil, itu tidak akan dimasukkan. Seperti segala sesuatu dalam setiap bahasa, bug menjadi fitur, dan orang-orang menggunakan fitur - tetapi jika Anda mengubahnya, Anda memecahkan kode.

- Bagaimana dengan tipe void baru? Seperti nihil, tapi batal?

- Oh tidak, ini mimpi buruk. Anda hanya menunda masalah, jika Anda menempatkan yang lain, maka Anda membutuhkan yang lain dan yang lainnya. Itu bukan solusinya. Masalah utama - baik, bukan utama, tetapi salah satu masalah - adalah bahwa nihil sudah tertanam di banyak tempat dalam bahasa. Misalnya, contoh yang sangat khas. Kami katakan: Anda harus menghindari nil dalam array, lubang. Tapi kemudian kita memiliki fungsi yang mengembalikan nol dan sesuatu setelah nol, jadi kita mendapatkan kode kesalahan. Jadi konstruksi itu sendiri mengasumsikan nil mewakili ... Misalnya, jika saya ingin membuat daftar pengembalian fungsi itu, hanya untuk menangkap semua pengembalian ini.

- Itu sebabnya Anda harus meretasnya. :)

- Tepat, tetapi Anda tidak harus menggunakan peretasan untuk [masalah] yang primitif dan jelas. Tetapi cara perpustakaan dibangun ... Saya pernah memikirkan hal itu - mungkin perpustakaan harus mengembalikan false bukannya nihil - tapi ini adalah solusi setengah matang, itu hanya memecahkan sebagian kecil dari masalah. Masalah sebenarnya, seperti yang saya katakan, adalah kita harus memiliki nil dalam tabel. Jika tidak, mungkin kita sebaiknya tidak menggunakan nils sesering yang kita lakukan sekarang. Semuanya agak berantakan. Jadi jika Anda membuat void, fungsi-fungsi ini masih akan mengembalikan nol, dan kami masih akan memiliki masalah ini kecuali kami membuat tipe baru dan fungsi-fungsi akan mengembalikan void daripada nihil.

- Void dapat digunakan untuk secara eksplisit mengatakan bahwa kunci harus disimpan dalam tabel - kunci dengan nilai void. Dan nihil bisa bertindak seperti sebelumnya.

- Ya, itulah yang saya maksud. Semua fungsi di perpustakaan harus mengembalikan void atau nil.

- Mereka masih bisa kembali nihil, kenapa tidak?

- Karena kita masih memiliki masalah sehingga Anda tidak dapat menangkap beberapa fungsi.

- Tapi tidak akan ada kunci pertama, hanya kunci kedua.

- Tidak, tidak akan ada kunci kedua, karena penghitungan akan salah dan Anda akan memiliki lubang di array.

- Ya, jadi Anda mengatakan bahwa Anda memerlukan metametode palsu?

- Ya. Mimpi saya adalah seperti itu:

{f(x)}

Anda harus menangkap semua pengembalian fungsi f(x) . Dan kemudian saya bisa melakukan %x atau #x , dan itu akan memberi saya jumlah pengembalian fungsi. Itulah yang harus dilakukan oleh bahasa yang masuk akal. Jadi membuat kekosongan tidak akan menyelesaikan itu, kecuali kita memiliki aturan yang sangat kuat bahwa fungsi tidak boleh mengembalikan nol, tetapi lalu mengapa kita perlu nol? Mungkin kita harus menghindarinya.

- Roberto, akankah ada dukungan analisis statis yang lebih kuat untuk Lua? Seperti "Lua Periksa steroid." Saya tahu itu tidak akan menyelesaikan semua masalah, tentu saja. Anda mengatakan ini adalah fitur untuk 6.0, jika pernah, kan? Jadi jika dalam 5.x akan ada alat analisis statis yang kuat - jika man-jam dan man-tahun diinvestasikan - akankah ini membantu?

- Tidak, saya pikir alat analisis statis yang sangat kuat disebut ... sistem tipe! Jika Anda menginginkan alat yang sangat kuat, Anda harus menggunakan bahasa yang diketik secara statis, sesuatu seperti Haskell atau bahkan sesuatu dengan tipe dependen. Maka Anda akan memiliki alat analisis yang sangat kuat.

- Tapi kamu tidak punya Lua.

- Tepat, Lua adalah untuk ...

- Tidak tepat? Saya sangat menikmati gambar jerapah Anda pada tipe statis dan dinamis.

- Ya, slide terakhir saya.


Slide terakhir dari ceramah Roberto Ierusalimschy "Mengapa (dan mengapa tidak) Lua?"
di Lua di konferensi Moskow 2019

- Untuk pertanyaan siap berikutnya, mari kita kembali ke gambar itu. Jika saya melakukannya dengan benar, posisi Anda adalah bahwa Lua adalah alat praktis kecil yang bagus untuk menyelesaikan tugas yang tidak terlalu besar.

- Tidak, saya pikir Anda dapat melakukan beberapa tugas besar, tetapi tidak dengan analisis statis. Saya sangat percaya pada tes. Ngomong-ngomong, saya tidak setuju dengan Anda tentang cakupan, pendapat Anda adalah kita seharusnya tidak mengejar cakupan ... Maksud saya, saya sepenuhnya setuju bahwa cakupan tidak menyiratkan tes penuh, tetapi non-cakupan menyiratkan tes nol persen. Jadi saya memberi ceramah tentang ruang pengujian - Anda ada di Stockholm. Jadi saya memulai tes saya dengan beberapa bug - itu hal yang paling aneh - salah satunya terkenal, yang lain sama sekali tidak terkenal. Ini adalah sesuatu yang benar-benar rusak di file header dari Microsoft, C dan C ++. Jadi saya mencari di web dan tidak ada yang peduli atau bahkan menyadarinya.

Misalnya, ada fungsi matematika, modf () , di mana Anda harus meneruskan pointer ke ganda karena mengembalikan dua ganda. Kami menerjemahkan bagian bilangan bulat dari angka atau bagian fraksional. Jadi ini adalah bagian dari perpustakaan standar untuk waktu yang lama sekarang. Kemudian datang C 99, dan Anda membutuhkan fungsi ini untuk mengapung. Dan file header dari Microsoft hanya menyimpan fungsi ini dan menyatakan yang lain sebagai makro. Jadi, ini menjadi tipe pemain. Jadi itu melemparkan ganda untuk mengapung, ok, dan kemudian itu melemparkan penunjuk untuk menggandakan penunjuk untuk melayang!

- Ada yang salah dalam gambar ini.

- Ini adalah file header dari Visual C ++ dan Visual C 2007. Maksud saya, jika Anda memanggil fungsi ini sekali, dengan parameter apa pun, dan memeriksa hasilnya - itu akan salah kecuali nol. Jika tidak, nilai lain apa pun akan salah. Anda tidak akan pernah menggunakan fungsi ini. Tanpa cakupan. Dan kemudian ada banyak diskusi tentang pengujian ... Maksud saya, panggil fungsi sekali saja, periksa hasilnya! Jadi itu ada di sana, sudah ada di sana untuk waktu yang lama, selama bertahun-tahun tidak ada yang peduli. Salah satu yang sangat terkenal adalah di Apple. Sesuatu seperti " if… what… goto… ok ", itu adalah sesuatu seperti itu. Seseorang menaruh pernyataan lain di sini. Dan kemudian semuanya akan beres. Dan ada banyak diskusi bahwa Anda harus memiliki aturan, tanda kurung harus sesuai dengan gaya Anda, dll., Dll. Tidak ada yang menyebutkan bahwa ada banyak seandainya ada di sini. Itu belum pernah dieksekusi ...

- Ada juga masalah keamanan sejauh yang saya ingat.

- Ya persis. Karena mereka hanya menguji kasus yang disetujui. Mereka tidak menguji apa pun, karena semuanya akan disetujui. Itu berarti tidak ada satu kasus uji dalam aplikasi keamanan yang memeriksa apakah ia menolak beberapa koneksi atau apa pun yang harus ditolak. Jadi semua orang berdiskusi dan mengatakan mereka harus memiliki tanda kurung ... Mereka harus memiliki tes, tes minimum! Karena tidak ada yang pernah menguji itu, itulah yang saya maksud dengan liputan. Sulit dipercaya bagaimana orang tidak melakukan tes dasar. Karena jika mereka melakukan semua tes dasar, maka tentu saja, itu adalah mimpi buruk untuk melakukan semua liputan dan menjalankan semua jalur, dll. Orang-orang bahkan mengabaikan tes dasar, sehingga cakupan setidaknya tentang minimum. Ini adalah cara untuk menarik perhatian ke beberapa bagian dari program yang Anda lupakan. Ini adalah semacam panduan tentang cara meningkatkan tes Anda sedikit.

- Apa cakupan tes di Tarantool? 83%! Roberto, apa cakupan tes Lua?

- Tentang 99.6. Berapa banyak baris kode yang Anda miliki? Satu juta, ratusan ribu? Ini adalah jumlah yang sangat besar. Satu persen dari seratus ribu adalah seribu baris kode yang tidak pernah diuji. Anda tidak menjalankannya sama sekali. Pengguna Anda tidak menguji apa pun.

- Jadi ada seperti 17 persen fitur Tarantool yang saat ini tidak digunakan?

- Saya tidak yakin apakah Anda ingin menghapus semuanya kembali ke tempat kami berada ... Saya pikir salah satu masalah dengan bahasa dinamis (dan bahasa statis dalam hal ini) adalah bahwa orang tidak menguji hal-hal. Bahkan jika Anda memiliki bahasa statis, kecuali jika Anda memiliki sesuatu - tidak seperti Haskell, tetapi Coq, - beberapa sistem bukti, Anda mengubahnya untuk itu atau itu. Tidak ada alat analisis statis yang dapat mendeteksi kesalahan ini, jadi Anda memang perlu pengujian. Dan jika Anda memiliki tes, Anda mendeteksi masalah global, mengganti nama kesalahan ejaan, dll. Semua jenis kesalahan ini. Anda harus memiliki tes ini, mungkin kadang-kadang sedikit lebih sulit untuk di-debug, kadang-kadang tidak - tergantung pada bahasa dan jenis bug. Tetapi masalahnya adalah bahwa tidak ada alat analisis statis yang memungkinkan Anda untuk menghindari tes. Tes, di sisi lain ... yah, mereka tidak pernah membuktikan tidak adanya kesalahan, tapi saya merasa jauh lebih aman setelah semua tes.

- Kami memiliki pertanyaan tentang pengujian modul Lua. Sebagai pengembang, saya ingin menguji beberapa fungsi lokal yang dapat digunakan nanti. Pertanyaannya adalah: kami ingin memiliki cakupan sekitar 99 persen, tetapi untuk API modul ini menghasilkan, jumlah kasus fungsional yang harus dihasilkan jauh lebih rendah daripada fungsionalitas yang didukungnya secara internal.

- Kenapa begitu, maaf?

- Ada beberapa fungsi yang tidak dapat dijangkau oleh antarmuka publik.

- Jika ada fungsi yang tidak dapat dijangkau oleh antarmuka publik, seharusnya tidak ada di sana, cukup hapus saja. Hapus kode itu.

- Bunuh saja?

- Ya, kadang saya melakukannya di Lua. Ada beberapa cakupan kode, saya tidak bisa sampai di sana atau di sana atau di sana, jadi saya pikir itu tidak mungkin dan hanya menghapus kode. Itu tidak biasa, tetapi terjadi lebih dari satu kali. Kasus-kasus itu tidak mungkin terjadi, Anda hanya perlu menegaskan mengapa hal itu tidak bisa terjadi. Jika Anda tidak bisa masuk ke dalam fungsi Anda dari API publik, itu tidak seharusnya ada di sana. Kita harus memberi kode pada API publik dengan input yang salah, itu penting untuk pengujian.

- Hapus kode, penghapusan itu baik, itu mengurangi kompleksitas. Berkurangnya kompleksitas meningkatkan pemeliharaan dan stabilitas. Tetap sederhana.

- Ya, pemrograman ekstrim memiliki aturan ini. Jika tidak dalam tes, maka itu tidak ada.

- Bahasa apa yang menginspirasi Anda saat Anda membuat Lua? Paradigma atau spesialisasi fungsional mana yang Anda sukai?

- Saya merancang Lua untuk tujuan yang sangat spesifik, itu bukan proyek akademik. Itu sebabnya ketika Anda bertanya kepada saya apakah saya akan membuatnya lagi, saya katakan ada banyak hal bersejarah tentang bahasa tersebut. Saya tidak memulai dengan 'Biarkan saya membuat bahasa yang saya inginkan atau ingin gunakan atau semua orang perlu dll. Masalah saya adalah 'Program ini di sini membutuhkan bahasa konfigurasi untuk ahli geologi dan insinyur, dan saya perlu membuat beberapa bahasa kecil yang bisa mereka gunakan dengan antarmuka yang mudah. Itu sebabnya API selalu menjadi bagian integral dari bahasa, karena lebih mudah diintegrasikan. Itulah tujuannya. Apa yang saya miliki di latar belakang saya, banyak bahasa yang berbeda pada waktu itu ... sekitar sepuluh. Jika Anda ingin semua latar belakang ...

- Saya tertarik pada bahasa yang ingin Anda sertakan dalam Lua.

- Saya mendapatkan banyak hal dari berbagai bahasa, apa pun yang sesuai dengan masalah yang saya miliki. Satu-satunya inspirasi terbesar adalah bahasa Modula untuk sintaksis, tetapi sebaliknya, sulit untuk mengatakan karena ada begitu banyak bahasa. Beberapa hal datang dari AWK, itu adalah inspirasi kecil lainnya. Tentu saja, Skema dan Lisp ... Saya selalu terpesona dengan Lisp sejak saya mulai pemrograman.

- Dan masih tidak ada makro di Lua!

- Ya, ada banyak perbedaan dalam sintaksis. Fortran, saya pikir, adalah bahasa pertama ... tidak, bahasa pertama yang saya pelajari adalah Assembly, kemudian datang Fortran. Saya belajar, tetapi tidak pernah menggunakan CLU. Saya melakukan banyak pemrograman dengan Smalltalk, SNOBOL. Saya juga belajar, tetapi tidak pernah menggunakan Icon, itu juga sangat menarik. Banyak yang datang dari Pascal dan C. Pada saat saya membuat Lua, C ++ sudah terlalu kompleks bagi saya - dan itu sebelum template, dll. Itu tahun 1991, dan pada tahun 1993 Lua dimulai.

- Uni Soviet jatuh dan Anda mulai menciptakan Lua. :) Apakah Anda bosan dengan titik koma dan objek ketika Anda mulai bekerja pada Lua? Saya berharap bahwa Lua akan memiliki sintaksis yang mirip dengan C, karena terintegrasi ke C. Tapi ...

- Ya, saya pikir itu alasan bagus untuk tidak memiliki sintaksis yang sama - jadi Anda tidak mencampurnya, ini adalah dua bahasa yang berbeda.

Ini sesuatu yang sangat lucu dan terhubung dengan jawaban yang Anda tidak izinkan saya [di konferensi] untuk memberikan pada array mulai dari 1. Jawaban saya terlalu lama.

Ketika kami memulai Lua, dunia berbeda, tidak semuanya seperti C. Java dan JavaScript tidak ada, Python masih dalam masa pertumbuhan dan memiliki versi lebih rendah dari 1.0. Jadi tidak ada hal ini ketika semua bahasa seharusnya seperti-C. C hanyalah salah satu dari banyak sintaksis yang ada.

Dan susunannya persis sama. Sangat lucu bahwa kebanyakan orang tidak menyadarinya. Ada hal-hal baik tentang array berbasis nol serta array berbasis satu.

Faktanya adalah bahwa sebagian besar bahasa populer saat ini berbasis nol karena C. Mereka agak terinspirasi oleh C. Dan yang lucu adalah bahwa C tidak memiliki pengindeksan. Jadi Anda tidak bisa mengatakan bahwa indeks C array dari nol, karena tidak ada operasi pengindeksan. C memiliki pointer aritmatika, jadi nol dalam C bukan indeks, ini offset. Dan sebagai penyeimbang, itu harus nol - bukan karena memiliki sifat matematika yang lebih baik atau karena lebih alami, apa pun.

Dan semua bahasa yang menyalin C, mereka memiliki indeks dan tidak memiliki aritmatika pointer. Java, JavaScript, dll., Dll. - tidak ada dari mereka yang memiliki pointer aritmatika. Jadi mereka hanya menyalin nol, tetapi operasi yang sama sekali berbeda. Mereka memberi nol tanpa alasan sama sekali - itu seperti kultus kargo.

- Anda mengatakan itu logis jika Anda memiliki bahasa yang tertanam dalam C untuk membuatnya dengan sintaks seperti C. Tetapi jika Anda memiliki bahasa C-embedded, saya berasumsi Anda memiliki programmer C yang ingin kode berada dalam C dan bukan bahasa lain, yang terlihat seperti C, tetapi bukan C. Jadi pengguna Lua tidak pernah seharusnya menggunakan C setiap hari? Mengapa

- Siapa yang menggunakan C setiap hari?

- Pemrogram sistem.

- Tepat. Itulah masalahnya, terlalu banyak orang menggunakan C, tetapi seharusnya tidak diizinkan menggunakannya. Pemrogram harus disertifikasi untuk menggunakan C. Mengapa perangkat lunak begitu rusak? Semua peretasan yang menyerang dunia, semua masalah keamanan itu. Setidaknya setengah dari mereka adalah karena C. Sangat sulit untuk memprogram dalam C.

- Tapi Lua ada di C.

- Ya, dan itulah bagaimana kami belajar betapa sulitnya memprogram dalam C. Anda memiliki buffer overflows, Anda memiliki integer overflow yang menyebabkan buffer overflow nomor mana saja dan semuanya diperiksa. Kemudian lagi, masalah portabilitas nyata - mungkin kadang-kadang dalam satu CPU berfungsi, tetapi kemudian sampai ke CPU lain ... Ini gila.

Sebagai contoh, baru-baru ini kami memiliki masalah. Bagaimana Anda tahu program C Anda tidak melakukan stack overflow? Maksud saya stack depth, bukan stack overflow karena Anda menyerbu ... Berapa banyak panggilan yang berhak Anda lakukan dalam program C?

- Tergantung pada ukuran tumpukan.

- Tepat. Apa yang dikatakan standar tentang itu? Jika Anda kode dalam C dan kemudian Anda melakukan fungsi ini yang memanggil fungsi ini yang memanggil fungsi ini ... berapa banyak panggilan yang dapat Anda lakukan?

- 16 ribu?

- Saya mungkin salah, tapi saya pikir standar tidak mengatakan apa-apa tentang itu.

- Saya pikir tidak ada yang standar karena terlalu tergantung pada ukuran.

- Tentu saja, itu tergantung pada ukuran masing-masing fungsi. Mungkin besar, array otomatis dalam bingkai fungsi ... Jadi standar tidak mengatakan apa-apa dan tidak ada cara untuk memeriksa apakah panggilan akan valid. Jadi Anda mungkin memiliki masalah tunggal jika Anda memiliki tiga panggilan langkah, itu bisa crash dan masih menjadi program C yang valid. Sesuai dengan standar - meskipun tidak benar karena macet. Jadi sangat sulit untuk memprogram dalam C, karena ada begitu banyak ... Contoh bagus lainnya: apa hasilnya ketika Anda mengurangi dua petunjuk? Tidak ada orang di sini yang bekerja dengan C?

- Tidak, jadi jangan panggangan mereka. Tetapi C ++ mendukung berbagai jenis.

- Tidak, C ++ memiliki masalah yang sama.

- Apa jenis deklarasi? ptrdiff_t ?

- Tepat, ptrdiff_t adalah tipe bertanda tangan. Jadi biasanya, jika Anda memiliki memori standar ukuran kata Anda dan Anda mengurangi dua petunjuk dalam ruang ini, Anda tidak dapat mewakili semua ukuran dalam tipe yang ditandatangani. Jadi, apa yang dikatakan standar tentang itu?

Ketika Anda mengurangi dua petunjuk, jika jawabannya cocok dengan pointer berbeda, maka itulah jawabannya. Jika tidak, Anda memiliki perilaku yang tidak jelas. Dan bagaimana Anda tahu kalau itu cocok? Kamu tidak. Jadi, setiap kali Anda mengurangi dua pointer, biasanya Anda tahu itu di luar standar, bahwa jika Anda menunjuk sesuatu yang lebih besar dari minimal 2 byte, maka ukuran yang lebih besar akan menjadi setengah ukuran memori, jadi semuanya baik-baik saja.

Jadi Anda hanya mengalami masalah jika Anda menunjuk ke byte atau karakter. Tetapi ketika Anda melakukan itu, Anda memiliki masalah nyata, Anda tidak dapat melakukan aritmatika pointer tanpa khawatir bahwa Anda memiliki string yang lebih besar dari setengah memori. Dan kemudian saya tidak bisa hanya menghitung ukuran dan menyimpan dalam jenis pointer diff karena itu salah.

Itulah yang saya maksud tentang memiliki program C atau C ++ aman yang benar-benar aman.

- Sudahkah Anda mempertimbangkan untuk mengimplementasikan Lua dalam bahasa yang berbeda? Ubah dari C ke yang lain?

- Ketika kami mulai, saya menganggap C ++, tetapi seperti yang saya katakan saya menyerah menggunakannya karena kerumitan - Saya tidak bisa mempelajari seluruh bahasa. Seharusnya berguna untuk memiliki beberapa hal dari C ++ tetapi ... bahkan hari ini saya tidak melihat bahasa apa pun yang bisa digunakan.

- Bisakah Anda menjelaskan mengapa?

- Karena saya tidak punya alternatif. Saya hanya bisa menjelaskan mengapa terhadap bahasa lain. Saya tidak mengatakan C sempurna atau bahkan baik, tapi itu yang terbaik. Untuk menjelaskan alasannya, saya perlu membandingkannya dengan bahasa lain.

- Bagaimana dengan JVM?

- Oh, JVM. Ayolah, itu tidak muat di setengah perangkat keras ... Portabilitas adalah alasan utama, tetapi kinerja juga. Dalam JVM ini sedikit lebih baik daripada .NET, tetapi tidak jauh berbeda. Banyak hal yang Lua lakukan tidak dapat kita lakukan dengan JVM. Misalnya, Anda tidak dapat mengontrol pemulung. Anda harus menggunakan pengumpul sampah JVM karena Anda tidak dapat memiliki pengumpul sampah yang berbeda diimplementasikan di atas JVM. JVM juga konsumen memori yang besar. Ketika program Java mulai menyapa, kira-kira 10 MB atau lebih. Portabilitas adalah masalah bukan karena itu tidak porting, tetapi karena itu tidak bisa porting.

- Bagaimana dengan modifikasi JVM seperti Mobile JVM?

- Itu bukan JVM, itu lelucon. Ini seperti edisi mikro Java, bukan Java.

- Bagaimana dengan bahasa statis lainnya seperti Go atau Oberon? Bisakah mereka menjadi dasar untuk Lua jika Anda membuatnya hari ini?

- Oberon ... mungkin, itu tergantung ... Pergi, sekali lagi, memiliki pengumpul sampah dan memiliki runtime yang terlalu besar untuk Lua. Oberon akan menjadi pilihan, tetapi Oberon memiliki beberapa hal yang sangat aneh, seperti Anda hampir tidak memiliki konstanta, jika saya ingat dengan benar. Ya, saya pikir mereka memindahkan const dari Pascal ke Oberon. Saya punya buku tentang Oberon dan mencintai Oberon. Sistemnya luar biasa, benar-benar sesuatu.

Saya ingat bahwa pada tahun 1994 saya melihat demonstrasi Oberon dan Self. Apakah Anda kenal diri? Ini adalah bahasa dinamis yang sangat menarik dengan kompiler jit dll ... Saya melihat demo ini terpisah satu minggu, dan Self sangat cerdas, mereka menggunakan beberapa teknik dari kartun untuk menyamarkan kelambatan operasi. Karena ketika Anda membuka sesuatu, rasanya seperti 'celetuk!' - pertama mengurangi sedikit, kemudian mengembang dengan beberapa efek. Itu diterapkan dengan sangat baik, teknik ini mereka gunakan untuk mensimulasikan gerakan ...

Kemudian seminggu kemudian kami melihat demo Oberon, itu berjalan pada seperti 1/10 perangkat keras untuk Self - ada mesin kecil yang sangat tua ini. Di Oberon Anda mengklik dan kemudian boom, semuanya bekerja segera, seluruh sistem terasa sangat ringan.

Tetapi bagi saya itu terlalu minimalis, mereka menghilangkan konstanta dan tipe varian.

- Haskell?

- Saya tidak tahu Haskell atau bagaimana menerapkan Lua di Haskell.

- Dan apa sikap Anda terhadap bahasa seperti Python atau R atau Julia sebagai dasar untuk implementasi Lua di masa depan?

- Saya pikir semua ini memiliki kegunaannya.

R tampaknya bagus untuk statistik. Ini sangat spesifik domain, dilakukan oleh orang-orang di daerah ini, jadi ini adalah kekuatan.

Python itu bagus, tapi saya punya masalah pribadi dengannya. Saya pikir saya menyebutkannya dalam pembicaraan atau wawancara saya. Hal tentang tidak mengetahui seluruh bahasa atau tidak menggunakannya, kesalahan subset.

Kami menggunakan Python dalam kursus kami, mengajar pemrograman dasar - hanya sebagian kecil, loop dan integer. Semua orang senang, dan kemudian mereka berkata akan menyenangkan jika memiliki beberapa aplikasi grafis, jadi kami membutuhkan beberapa perpustakaan grafis. Dan hampir semua pustaka grafis, Anda mendapatkan API ... Tapi saya tidak tahu cukup Python, ini adalah hal yang jauh lebih maju. Ia memiliki ilusi itu mudah dan saya memiliki semua perpustakaan ini untuk semuanya, tetapi itu mudah atau Anda memiliki segalanya.

Jadi ketika Anda mulai menggunakan bahasa, maka Anda mulai: oh, saya harus belajar OOP, pewarisan, apa pun. Setiap perpustakaan. Sepertinya penulis bangga menggunakan fitur bahasa yang lebih maju di API mereka untuk menunjukkan saya tidak tahu apa. Panggilan fungsi, tipe standar, dll. Anda memiliki objek ini, dan kemudian jika Anda menginginkan hal lain maka Anda harus membuat objek lain ...

Bahkan dengan pencocokan pola, Anda dapat melakukan beberapa hal sederhana, tetapi biasanya pencocokan pola standar bukanlah sesuatu yang Anda lakukan. Anda melakukan pencocokan, suatu objek mengembalikan hasil dan kemudian Anda memanggil metode pada hasil objek itu untuk mendapatkan hasil nyata dari pertandingan. Kadang-kadang ada cara yang lebih sederhana untuk digunakan tetapi tidak jelas, itu bukan cara yang digunakan kebanyakan orang.

Contoh lain: Saya mengajar kursus tentang pencocokan pola dan ingin menggunakan sintaks seperti Perl, dan saya tidak bisa menggunakan Lua karena sintaks yang sama sekali berbeda. Jadi saya pikir Python akan menjadi contoh sempurna. Tetapi dalam Python ada beberapa fungsi langsung untuk beberapa hal dasar tetapi untuk hal yang lebih kompleks Anda harus tahu objek dan metode dll. Saya hanya ingin melakukan sesuatu dan mendapatkan hasilnya.

- Apa yang akhirnya Anda gunakan?

- Saya menggunakan Python dan menjelaskan kepada mereka. Tetapi bahkan Perl jauh lebih sederhana, Anda melakukan pertandingan dan hasilnya adalah $ 1, $ 2, $ 3, itu jauh lebih mudah, tetapi saya tidak memiliki keberanian untuk menggunakan Perl, jadi ...

- Saya menggunakan Python selama dua tahun sebelum saya perhatikan ada dekorator. (pertanyaan oleh Yaroslav Dynnikov dari tim Tarantool)

- Ya, dan ketika Anda ingin menggunakan perpustakaan, maka Anda harus mempelajari hal ini dan Anda tidak mengerti API dll. Python memberikan ilusi bahwa itu mudah tetapi cukup rumit.

... Dan Julia, saya tidak tahu banyak tentang Julia, tetapi itu mengingatkan saya pada LuaJIT dalam arti bahwa kadang-kadang terlihat seperti kebanggaan pengguna. Anda dapat memiliki hasil yang sangat baik tetapi Anda harus benar-benar memahami apa yang terjadi. Ini tidak seperti Anda menulis kode dan mendapatkan hasil yang baik. Tidak, Anda menulis kode dan terkadang hasilnya bagus, kadang-kadang mengerikan. Dan ketika hasilnya mengerikan, Anda memiliki banyak alat bagus yang menunjukkan kepada Anda bahasa perantara yang pernah dihasilkan, Anda memeriksanya dan kemudian Anda menjalani semua kode yang hampir perakitan ini. Kemudian Anda menyadari: oh, itu tidak mengoptimalkan itu karena itu. Itu masalah programmer, mereka suka game dan kadang-kadang mereka suka barang karena itu sulit, bukan karena itu mudah.

Saya tidak tahu banyak tentang Julia, tetapi saya pernah melihat pembicaraan tentang itu. Dan orang yang berbicara, dia adalah orang yang memiliki sudut pandang ini: lihat betapa menyenangkannya, kami menulis program ini dan itu sempurna. Saya tidak ingat banyak, sesuatu tentang perkalian matriks saya kira. Dan kemudian mengapung itu sempurna, lalu ganda itu sempurna, dan kemudian mereka menempatkan [angka] yang rumit ... dan itu adalah sebuah tragedi. Seperti seratus kali lebih lambat.

(Sarkastik) 'Lihat betapa menyenangkannya, kami memiliki alat ini, kita dapat melihat seluruh [daftar] perakitan, dan kemudian Anda pergi dan mengubah itu dan itu dan itu. Lihat seberapa efisien ini '. Ya, saya mengerti, saya bisa memprogram secara langsung.

Tapi itu hanya satu pembicaraan. Saya mempelajari sedikit R dan memiliki pengalaman pengguna dengan Python untuk hal-hal kecil.

- Apa pendapatmu tentang Erlang?

- Erlang adalah bahasa yang lucu. Ini memiliki beberapa kegunaan yang sangat baik, toleransi kesalahan sangat menarik. Tetapi mereka mengklaim itu bahasa fungsional dan seluruh gagasan bahasa fungsional adalah bahwa Anda tidak memiliki status.

Dan Erlang memiliki status tersembunyi yang sangat besar dalam pesan yang dikirim dan belum diterima. Jadi setiap proses kecil benar-benar fungsional tetapi program itu sendiri sepenuhnya tidak berfungsi.

Ini berantakan data tersembunyi yang jauh lebih buruk daripada variabel global karena jika itu adalah variabel global, Anda akan mencetaknya. Pesan yang merupakan kondisi sebenarnya dari sistem Anda. Setiap saat, bagaimana keadaan sistem? Ada semua pesan yang dikirim ke sana-sini. Sama sekali tidak berfungsi sama sekali.

- Jadi Erlang berbohong tentang fungsional dan kebohongan Python tentang menjadi sederhana. Apa yang dibohongi Lua?

- Lua sedikit berbohong tentang menjadi kecil. Ini masih lebih kecil dari kebanyakan bahasa lain, tetapi jika Anda ingin bahasa yang sangat kecil maka Lua lebih besar dari yang Anda inginkan.

- Bahasa apa itu?

- Keempat, aku suka Keempat.

- Apakah ada ruang untuk versi Lua yang lebih kecil?

- Mungkin, tapi sulit. Saya suka meja tapi meja tidak terlalu kecil. Jika Anda ingin merepresentasikan hal-hal kecil, seluruh ide di balik tabel tidak cocok untuk Anda. Itu akan menjadi sintaks Lua, kita akan menyebutnya Lua tetapi itu bukan Lua.

Ini akan seperti edisi mikro Java. Anda menyebutnya Java tetapi apakah memiliki multi-threading? Tidak, tidak. Apakah ada refleksi? Tidak, tidak. Jadi mengapa menggunakannya? Ini memiliki sintaks Java, sistem tipe yang sama tetapi bukan Java sama sekali. Ini adalah bahasa yang berbeda yang lebih mudah dipelajari jika Anda tahu Java tetapi bukan Java.

Jika Anda ingin membuat bahasa kecil yang terlihat seperti Lua tetapi Lua tanpa tabel bukanlah ... Mungkin Anda harus mendeklarasikan tabel, sesuatu seperti FFI untuk menjadi kecil.

- Apakah ada adaptasi Lua yang lebih kecil?

- Mungkin saya tidak tahu.

- Apakah Lua siap untuk pemrograman fungsional murni? Bisakah kamu melakukannya dengan Lua?

- Tentu saja kamu bisa. Ini tidak terlalu efisien tetapi hanya Haskell yang benar-benar efisien untuk itu. Jika Anda mulai menggunakan monad dan hal-hal seperti itu, buat fungsi baru, susun fungsi dll ... Anda dapat melakukannya [dengan] Lua, ini berjalan cukup masuk akal, tetapi Anda memerlukan teknik implementasi yang berbeda dari bahasa imperatif normal untuk melakukan sesuatu yang sangat efisien.

— Actually, there is a library for functional programming in Lua.

— Yes, it's reasonable and usable, if you do really need performance; you can do a lot of stuff with it. I love functional stuff and I do it all the time.

— My question is more about the garbage collector, because we only have only mutable objects and we have to use them efficiently. Will Lua be good for that?

— I think a new incarnation of garbage collector will help a lot, but again…

— Young die young? The one that seems to work with young objects?

— Exactly, yes. But as I said even with the standard garbage collector we don't have optimal performance but it can be reasonable. More often you don't even need that performance for most actions unless you are writing servers and having big operations.

— What functional programming tasks do you perform in Lua?

— A simple example. My book, I'm writing my own format and I have a formatter that transforms that in LaTex or DocBook. It's completely functional, it has a big pattern matching… It's slightly inspired by LaTex but much more uniformed. There's @ symbol instead of backslash, a name of a macro and one single argument in curly brackets. So I have gsub that recognizes this kind of stuff and then it calls a function, the function does something and returns something. It's all functional, just functions on top of functions on top of functions, and the final function gives a big result.

— Why don't you program with LaTeX?

— Plain LaTeX? First, it's too tricky for a lot of stuff and so difficult. I have several things that I don't know how to do in LaTex. For example, I want to put a piece of inline code inside a text. Then there is a slash verb, standard stuff. But slash verb gives fixed space. And the space between stuff is never right. All real spaces are variable, it depends on how the line is adjusted, so it expands in some spaces and compacts in others depending on a lot of stuff. And those spaces are fixed, so sometimes they look too large, sometimes too small. It also depends on what you put in code.

— But you still render your own format to LaTeX?

— Yes, but with a lot of preprocessing. I write my own verb but then it changes and becomes not a verb but a lot of stuff. For example, when I write 3+1 I write a very small space here. In verb, if I don't put any space here, it shrinks, and if I do, it's too large. So I do the preprocessing, inserting a variable space. It's very small but can be a little larger if it needs to adjust. But if I put 'and' after 1 then I put a larger space. This function here does all that. This is a small example but there are other things…

— Do you have a source?

— I do have the source, it is in the git . The program's called 2html . The current version only generates HTML… Sorry, that's a kind of a mess. I created it for a book but also another one for the manual. The one in the git is for the manual. But the other one is more complicated and not public, I can't make it public. But the main problem is that TeX is not there. It's almost impossible to process TeX files without TeX itself.

— Is it not machine-readable?

— Yes, it's not machine-readable. I mean, it is readable because TeX reads it. It's so hard to test, so many strange rules etc. So this is much more uniformed and as I said I generate DocBook format, sometimes I need it. That started when I had this contract for a book.

— So you use 2html to generate DocBook?

— Yes, it generates DocBook directly.

- Ok, terima kasih banyak untuk wawancaranya!



Jika Anda memiliki pertanyaan lain, Anda dapat menanyakannya di Lua Mailing List . Sampai ketemu lagi!

Source: https://habr.com/ru/post/id459466/


All Articles