🥖 🏔️ 🐋 Transkrip wawancara saya dengan penulis Ruby ♌️ 📭 🈶

Selama konferensi musim gugur Ruby Russia I, tentang hak penyelenggara, tertangkap di sela-sela penulis dan Ruby memberinya wawancara ~~interogasi~~ selama satu jam . Saya mencoba memilih pertanyaan yang tidak letih sehingga jawaban akan bermanfaat bagi kami, dan tidak "untuk semua yang baik versus yang buruk". Dan kakek mengejutkan saya, pengembang tua plus! Di bawah potongan adalah transkrip wawancara, pendapat non-sepele dari Yukihiro Matsumoto tentang jenis-jenis pada umumnya dan peretasan pada khususnya, serta kesempatan untuk membahas semua ini dalam komentar. Saya berhubungan dengan tim Ruby Evrone . Kami mengundang Matsumoto ke Moskow secara teratur, ada kesempatan untuk mengajukan pertanyaan menarik terlebih dahulu untuk wawancara selanjutnya.

Sebagai pendiri bahasa, Anda mendapatkan banyak saran dan ide. Apa yang paling sering Anda tanyakan?

Orang sering bertanya, "Saya menggunakan bahasa X. Mengapa Anda tidak menambahkan fungsi dari X ke Ruby?" Dalam kebanyakan kasus, saya menjawab bahwa ini tidak mungkin. Kami memiliki desain bahasa dan kebijakan bahasa yang berbeda. Kami tidak bisa hanya mengambil beberapa fungsi dari X dan menambahkan ke Ruby. Namun terkadang kami masih meminjam ide bagus dari bahasa lain seperti Python, JS, atau Elixir.

Sekarang bahasa dinamis menambahkan kemampuan untuk secara eksplisit menentukan jenis. Ini sudah muncul dalam Python, PHP, dan JavaScript (TypeScript). Apa pendapat Anda tentang hal ini, bagaimana cara bekerja dengan tipe-tipe di Ruby versi ketiga?

Rust and Go adalah bahasa yang diketik secara statis. Dalam proyek besar, ratusan pengembang membuat dan memelihara banyak kode, jutaan baris. Dalam kasus seperti itu, pengecekan tipe itu mudah, ini memungkinkan Anda untuk mendeteksi kesalahan. Dalam kasus lain, kita harus menulis tes untuk memastikan jenis yang digunakan sudah benar. Volume uji meningkat seiring dengan pertumbuhan proyek. Dalam hal ini, saya melihat alasan popularitas pengetikan statis, karena penggunaannya mengurangi jumlah tes.

Pada saat yang sama, deklarasi tipe eksplisit adalah informasi yang berlebihan. Dalam kasus Ruby, bahasa itu sendiri dapat menangani jenis dan kode kami hanya akan berfungsi. Kami ingin manfaat pemeriksaan tipe, tetapi kami tidak ingin redundansi dari spesifikasi manual mereka. Sebagai komunitas Ruby, kami berupaya menyediakan semua fitur kepada pengembang. Kami akan menggunakan file dengan tipe independen dari program Ruby kami. Dengan demikian, program Ruby tidak akan berisi informasi jenis.

File informasi jenis terpisah, yang kami sebut "file tanda tangan ruby," akan berisi informasi tentang jenis yang digunakan di perpustakaan, permata, dan kode perpustakaan Anda. Kami juga akan menyediakan alat baru, "tipe profiler", yang akan mengumpulkan informasi tipe. Itu dapat mendeteksi konflik tipe atau konflik berdasarkan kode itu sendiri atau mengetik anotasi.

Menggunakan file tanda tangan, Anda dapat memperbaiki jenis yang Anda gunakan dan membantu profiler memverifikasi kode Anda. Setelah mengumpulkan semua informasi jenis di perpustakaan yang digunakan dan kode Anda, profiler memiliki informasi yang cukup untuk menemukan kesalahan potensial.

Versi Ruby selanjutnya akan dapat melakukan pengecekan tipe statis, sampai batas tertentu. Tetap saja, Ruby adalah bahasa yang dinamis, dan tipe utama memeriksa di dalamnya adalah kebiasaan untuk dilakukan selama eksekusi kode kita. Ketik memeriksa "tingkat pertama" menggunakan informasi tentang jenis dalam kode dan membantu pengembang untuk mendeteksi 40 hingga 80 persen kesalahan. Pengecekan tipe “level kedua” menghasilkan informasi tipe berdasarkan kode itu sendiri. Di masa depan, dengan bantuan alat-alat tersebut, kami akan dapat memberikan pemeriksaan tipe statis di Ruby tanpa perlu pengembang untuk secara eksplisit menentukannya ...

Saya menyukai ide ini dan saya menantikan versi Ruby yang akan datang untuk melihat seberapa bagus pendekatan ini nantinya. Sangat bagus bahwa Anda bereksperimen dengan bahasa tersebut. Di masa depan apa yang Anda lihat untuk Ruby, ke arah mana Anda mengembangkan bahasa?

Bahkan, saya tidak mengontrol bahasa atau komunitas. Saya hanya menyediakan teknologi, dan masyarakat memutuskan ke mana harus pergi. Kami memiliki teknologi yang cukup untuk hampir semua bidang untuk membuat Ruby fleksibel dan produktif. Misalnya, Ruby terutama digunakan untuk membangun aplikasi web. Tapi saya ingin Ruby diterapkan di bidang lain: penelitian dan komputasi, kecerdasan buatan, pembelajaran mesin, di bidang inovasi. Kami mencoba membuat teknologi yang sesuai untuk aplikasi yang lebih luas.

Kami pengembang suka menyebut hal-hal yang berbeda nama. "Ini adalah mobil sport," dan ini adalah "mobil keluarga." JavaScript adalah bahasa pengembangan web. C adalah bahasa sistem tingkat rendah. Apa yang Anda suka sebut Ruby, posisikan itu?

Saya akan menyebut Ruby "bahasa pemrograman yang produktif." Produktivitas adalah salah satu tujuan utama, tugas utama Ruby. Itu dirancang untuk orang, bukan mobil. Terkadang pengembang mengeluh tentang desain bahasa ketika beberapa sintaks sulit diimplementasikan secara efisien. Desain Ruby tidak berfokus pada produktivitas, tetapi pada produktivitas. Ini membebaskan pengembang untuk menyelesaikan tugas yang lebih kompleks terkait dengan proyek itu sendiri. Kami mencoba membuat Ruby seproduktif mungkin, dan seproduktif mungkin.

Python tidak memiliki fungsi anonim multiline karena kompleksitas pengembangan. Sangat menyenangkan untuk mendengar bahwa untuk Ruby, Anda dan pengembang inti berusaha untuk membuat hidup lebih mudah bagi para programmer, meskipun kerumitan implementasinya. Omong-omong, jika kita mulai berbicara tentang kompleksitas. Bayangkan Anda memiliki kesempatan untuk kembali ke masa lalu dan memberikan satu saran kepada diri Anda muda ketika Anda mulai mengembangkan Ruby. Apa sarannya?

Jangan meminjam terlalu banyak dari bahasa skrip lain. Bahasa pemrograman Anda akan menjadi bahasa tujuan umum terbaik. Fokus besar pada scripting akan menjadi semacam kelainan di masa depan.

Selama evolusi bahasa Ruby, Anda membuat banyak perubahan, melakukan banyak eksperimen. Beberapa dari mereka berhasil, beberapa tidak. Apa yang Anda anggap sebagai kesuksesan terbesar Anda dalam mengembangkan bahasa, apa yang paling Anda sukai?

Jika Anda perlu memilih satu hal, maka ini adalah blok. Blok di Ruby unik, ini adalah abstraksi yang berguna dari fungsi orde yang lebih tinggi. Mereka jauh lebih sederhana daripada di bahasa lain. Ini memberikan batasan dan kemudahan penggunaan.

Kebetulan, tetapi blok adalah yang paling saya sukai tentang Ruby. Dalam pidato dan wawancara saya sendiri, saya berbicara tentang Ruby sebagai bahasa dengan DSL, gula sintaksis, dan blok. Blok sangat keren.

Dalam bahasa lain, seperti Swift, jika fungsi lain ditentukan sebagai argumen terakhir ke suatu fungsi, maka fungsi argumen ini dapat berperilaku seperti blok di Ruby. Ada saran untuk gula sintaksis bahkan untuk JavaScript. Saya sangat bangga akan hal itu.

Ya, JavaScript, dengan sintaks panah tebal, sering menggunakan argumen terakhir dari fungsi sebagai "sesuatu seperti blok di Ruby". Saya tidak bisa membantu tetapi mengajukan pertanyaan sebaliknya. Apa yang dapat Anda sebut kesalahan terbesar dalam proyek yang perlu diperbaiki atau sudah diperbaiki?

Ada beberapa. Mari kita mulai dengan variabel global. Mereka berguna untuk bahasa scripting, tetapi sekarang mereka terlihat seperti kelainan. Saya juga menyesal menambahkan stream secara eksplisit - kita membutuhkan abstraksi yang lebih nyaman untuk konkurensi. Kesalahan desain saya yang lain adalah kurangnya kekebalan terhadap beberapa objek. Misalnya, sekarang Anda dapat mengubah zona waktu untuk objek waktu. Alih-alih hanya membuat objek abadi baru. Ini yang saya sesalkan.

Mutabilitas itu kompleks dan dapat dengan mudah menyebabkan kesalahan. Tapi cukup pertanyaan teknis! Kita manusia adalah makhluk sosial, dan akan menarik untuk belajar tentang hidup Anda, bagaimana Anda mengatur pekerjaan?

Saya seorang pengembang Ruby penuh waktu. Setengah dari waktu saya saya bekerja pada desain versi bahasa berikutnya. Sisa waktu saya sedang mengerjakan implementasi alternatif MRuby. Implementasi arus utama dibuat oleh pengembang inti, dan saya hanya membuat keputusan yang tercermin dalam kode.

Jumlah komit pada GitHub Anda sangat mengesankan, terutama komit pada hari Anda terbang ke Rusia. Baru-baru ini, pengembang telah banyak berbicara tentang burnout. Apakah Anda punya waktu luang, hobi, dan sesuatu yang melindungi Anda dari kehabisan tenaga?

Untungnya, saya menghabiskan seluruh waktu saya bekerja dengan open source. Saya tidak punya tekanan dari klien, saya tidak punya bos, saya mengatur sendiri tugas-tugas. Semua ini memungkinkan saya bekerja tanpa stres. Saya tidak memiliki tenggat waktu selain tanggal rilis Ruby berikutnya. Kebebasan ini membuat saya merasa rileks. Saya juga mencoba menghabiskan waktu tidak di depan komputer, memperhatikan kerabat, keluarga, membantu gereja setempat, menuntun anjing dan bermain dengan kucing saya.

Banyak pengembang Ruby Rusia menyukai Jepang sebagai negara, budayanya. Mereka menonton anime, membaca manga, datang ke Jepang sebagai turis. Sebagai orang Jepang asli dan pengembang perangkat lunak, tempat dan kegiatan apa yang dapat Anda rekomendasikan untuk sesama pengembang yang mengunjungi Jepang?

Jepang adalah negara yang beragam. Anda dapat mengunjungi Tokyo futuristik, di mana ada banyak budaya pop, seperti manga dan anime. Pada saat yang sama, kami memiliki gunung, hutan, dan situs bersejarah, seperti kuil tua dan kuil. Kami menghargai keindahan bunga sakura dan warna daun musim gugur. Jadi itu semua tergantung pada selera dan preferensi Anda, Anda dapat menikmati banyak hal: makanan, alam, teknologi. Anda dapat mengunjungi banyak tempat, terutama di Tokyo. Saya merekomendasikan agar rekan kerja memperhatikan keragaman negara kita dan mengandalkan hal ini dalam perjalanan wisata Anda.

Adakah sesuatu dalam budaya dan bahasa Jepang yang memengaruhi penciptaan Ruby?

Kami tidak memiliki kendali atas pengaruh budaya tersebut dan sulit untuk mengevaluasi. Misalnya, dalam bahasa Jepang, kalimat dilem bersama. Dengan cara yang sama "chaining metode" bekerja di Ruby. Mungkin ini pengaruh bahasa Jepang. Jepang adalah negara kaya dan kita tidak perlu kerja keras terus-menerus. Sumber terbuka tidak menghasilkan uang, tetapi dengan bekerja di pekerjaan utama saya atau mengandalkan uang sponsor, saya dan para kontributor dapat mendukung dan mengembangkan bahasa dan membuat teknologi yang lebih baik. Ini juga pengaruh Jepang dan peluang yang diberikannya.

Dan pertanyaan terakhir yang berbahaya. Orang sering membayangkan diri mereka di tempat orang lain, berpikir apa yang akan mereka lakukan, bagaimana mereka akan bertindak. Adakah sesuatu dalam posisi penulis bahasa pemrograman populer yang tidak jelas dari luar?

Membuat bahasa pemrograman bukanlah tugas teknis yang sangat sulit. Banyak siswa yang menghadiri kursus dalam mengembangkan bahasa pemrograman di universitas dapat membuat bahasa mereka sendiri dan tidak ada yang rumit. Kesulitannya adalah bahwa bahasa adalah cara mengekspresikan pikiran. Ini berlaku untuk bahasa pemrograman dan bahasa alami: Rusia, Inggris, Jepang. Memprogram bahasa seperti Ruby, Python, atau JavaScript - mereka membantu pikiran kita merumuskan pikiran. Ini adalah tugas utama dari bahasa pemrograman. Bahasa pemrograman yang baik menawarkan pendekatan untuk merumuskan pemikiran. Untuk Ruby, pendekatan ini adalah "pengembangan produktivitas dan kesenangan menulis kode." Untuk bahasa lain, itu bisa "kesederhanaan", "efisiensi", atau sesuatu yang lain. Setiap bahasa memiliki pendekatan sendiri. Dan jika Anda menyukainya,apa yang Ruby tawarkan untuk merumuskan pemikiran adalah bahasa Anda.

Transkrip wawancara saya dengan penulis Ruby

More articles: