RubyRusia 2019. Nikita Shilnikov pada efek aljabar

Ada sangat sedikit waktu yang tersisa sebelum konferensi RubyRussia. Mereka yang tidak berhasil mendapatkan tiket masih memiliki kesempatan untuk mengambil salah satu tiket terakhir di situs . Nikita Shilnikov di konferensi akan berbicara tentang efek aljabar, tetapi untuk saat ini Anda dapat membaca wawancara tentang topik laporan.



Katakan apa yang Anda lakukan dan bagaimana cara terhubung dengan Ruby?

Saya bekerja untuk dua perusahaan yang proyeknya ditulis dalam Ruby. Dalam satu penagihan yang kami lakukan, kami dapat mengatakan bahwa ini adalah semi-perusahaan, dan yang lain kami membuat layanan SaaS. Kebetulan saya melakukan banyak open source. Empat tahun lalu, saya menjadi tertarik pada satu proyek, menemukan kekurangan fungsionalitas di dalamnya, memutuskan untuk memperbaikinya dan mematikannya. Sekarang saya adalah pengembang inti dari dua organisasi dan komunitas. Semuanya bisa dilihat di github saya. Satu bagian dari pekerjaan berhubungan dengan basis data rom-rb , dan yang lainnya kering-rb adalah satu set perpustakaan untuk berbagai kesempatan.

Laporan Anda tentang efek aljabar, beri tahu saya apa manfaatnya bagi pengembang.

Di sini Anda perlu wawancara kecil. Ekosistem dry-rb terinspirasi oleh pemrograman fungsional. Namun selama perkembangannya, sesuatu menghantui. Misalnya, Anda sedang mengembangkan layanan SaaS dan ada tugas sederhana untuk mengisolasi data. Semuanya tampak jelas, ada beberapa jenis layanan, perusahaan terdaftar di dalamnya, dan mereka tidak boleh memiliki akses ke data masing-masing. Anda bisa menyelesaikannya dengan banyak cara. Tetapi dari sudut pandang yang murni fungsional, saya tidak dapat menemukan jawaban untuk bagaimana melakukan ini, kecuali untuk transfer eksplisit argumen di seluruh kode. Dia datang dengan solusi "non-fungsional" dan tinggal bersamanya.

Pada akhir 2018, kait muncul di Bereaksi. Ketika saya pertama kali melihat API mereka, saya berpikir bahwa tidak mungkin melakukan hal-hal seperti itu secara sederhana. Saya punya ide bagus tentang cara kerja JavaScript dan memutuskan bahwa semuanya jelas tidak bersih di sini, variabel global digunakan atau yang lainnya. Dalam ide saya tentang cara kerja program, itu tidak mungkin, atau semacam hack kotor digunakan. Saya memutuskan untuk mempelajari masalah ini.

Ternyata saya bukan satu-satunya orang yang tertarik dengan topik ini. Saya menemukan informasi bahwa ada cara formalisasi, yaitu, menulis program yang tampaknya menggunakan variabel global atau keadaan umum. Namun, mereka tetap bersih. Masalahnya relevan dan saya mulai menggali lebih dalam. Akibatnya, efek yang sangat aljabar menjadi jawabannya. Saya menulis prototipe kecil di Ruby, dan, yang mengejutkan saya, itu berhasil. Diterapkan dalam produksi, diluncurkan dan dikendarai selama beberapa bulan, kemudian membuat keputusan untuk semua orang.

Anda tertarik saya langsung dengan React hooks. Saya pikir ada sesuatu yang sangat sederhana seperti panggilan stack, penutupan, ruang lingkup saat ini.

Memang benar. Masalahnya adalah bahwa Anda memiliki beberapa jenis artikel yang menjelaskan semantik dan bagaimana, dari sudut pandang ilmiah, ini harus bekerja. Jika Anda mengikuti spesifikasinya, maka tampaknya Anda dapat membuat perpustakaan. Dalam kasus Bereaksi, ini juga merupakan pustaka atau, katakanlah, kerangka kerja yang menyediakan semacam API. Jika Anda menggunakannya dengan benar, maka semuanya berfungsi dengan baik. Tetapi jika Anda ke kiri atau kanan, itu bisa berakhir buruk. Dalam Bereaksi, mereka hanya melarang penggunaan kait dalam kondisi. Mereka harus melakukannya. Ini adalah salah satu batasannya.

Apakah ini terkait dengan bukti matematis tentang kebenaran kode?

Tidak juga. Ini bukan pertanyaan tentang perlunya membuktikan sesuatu, pertanyaannya lebih ke arah verifikasi program. Semua efek aljabar hanyalah deskripsi dari semantik. Tidak ada yang terbukti di sana, tetapi ditunjukkan bagaimana seharusnya bekerja. Jika pustaka ini, yang menerapkan efek aljabar, tidak mengandung kesalahan sendiri, maka dengan menjelaskan semantiknya, Anda menjamin bahwa kode Anda akan berfungsi sebagaimana dimaksud.

Bagaimana perasaan Anda tentang jenis dan bahasa pemrograman yang diketik secara statis?

Sangat positif. Sebagai contoh, kami memiliki backend di Ruby, dan ujung depan pada hal seperti ReasonML. Ini adalah OCaml, tetapi dengan sintaks yang berbeda. Semua hal lain dianggap sama, saya membuat pilihan ke arah sistem tipe ini. Ini cukup sederhana dan ada sejumlah bahasa yang penerapannya mirip atau mirip. Semakin banyak jenis, semakin baik. Namun, saya menulis backend di Ruby dan semuanya baik-baik saja dengan saya. Saya adalah pengembang alat yang bekerja dengan saya dan selalu tentang jenis: tipe kering , struktur kering , skema kering , validasi kering , monad kering . Mereka menjelaskan tentang tipe yang berasal dari database, dari pengguna, dari sistem eksternal. Jadi, Anda selalu tahu apa kode Ruby berfungsi untuk Anda. Meskipun tidak diketik dengan sendirinya, Anda dapat memastikan jenis variabel yang Anda gunakan.

Ada rumor bahwa akan ada tipe di Ruby 3. Apa yang kamu katakan tentang ini?

Saya memiliki pengalaman dengan Python. Ketika jenis-jenis itu dibawa ke sana, tulingnya tidak terlalu berkembang dan saya tidak terkesan. Sekarang situasinya lebih baik di sana. Anda dapat pergi ke sana dan menjelaskan semuanya dengan tipe dan menerapkan semacam penyetelan, yang akan memverifikasi bahwa program Anda benar. Ini tentang semacam pengganti untuk kompiler, tentang apa yang sedang dilakukan sorbet sekarang. Ini memakan waktu beberapa tahun untuk Python. Saya selalu menyambut gerakan menuju tipe, tapi saya tidak punya ilusi.

Mencari sintaks baru yang akan Anda terapkan dalam hal kode Ruby?

Terutama tidak dimainkan, masuk ke obrolan, tampak. Tapi saya tidak punya pendapat tentang bagaimana ini layak diterapkan. Sintaksnya dapat ditingkatkan, perubahan dalam bahasa dan sebagainya. Sekarang mereka telah membuat sintaks yang kompatibel dengan Ruby. Saya tidak berpikir bahwa sintaks adalah batu sandungan di sini, batu sandungan sedang disetel dan, seperti yang saya katakan, ini adalah jalan yang sangat panjang.

Apa lagi yang ingin Anda lihat di Ruby, bagaimana Anda melihat perkembangannya?

Saya akan tertarik multitasking kooperatif. Kami sudah memiliki multitasking kooperatif dalam bentuk serat. Kami masih kekurangan kemampuan untuk menjalankannya di beberapa utas. Ada opsi untuk bagaimana hal ini akan dilakukan dan tidak jelas dalam bentuk apa. Mengingat bahwa Ruby, implementasi C memiliki warisan yang cukup solid, Matz tidak ingin memecah kompatibilitas. Saya cenderung kombinasi serat dan beberapa benang berjalan secara bersamaan. Mungkin sesuatu seperti Persekutuan akan bekerja.

Tahun ini, Yukihiro Matsumoto, penulis Ruby, datang ke konferensi. Apa yang ingin Anda diskusikan dengannya sambil minum kopi atau segelas sake di pesta sesudahnya?

Hal terbaik yang dapat kita lakukan dalam berkomunikasi dengan penulis bahasa atau bahkan perpustakaan adalah menunjukkan kepada mereka bagaimana kita menggunakan produk ini dalam kehidupan nyata. Apalagi, seperti yang tidak diharapkan penulis. Ini akan memberi penulis kesempatan untuk memperhitungkan pengalaman tersebut dan menerapkannya dalam pengembangan lebih lanjut. Saya ingin menunjukkan keseluruhan cerita dengan efek aljabar. Saya akan mengatakan - lihat, hal apa yang bisa dilakukan dalam bahasa ajaib yang Anda buat. Dan mungkin setelah itu dia akan datang dengan sesuatu yang lain untuk kita.

Sampai jumpa di RubyRussia!

Ingatlah bahwa konferensi sudah Sabtu ini, pendaftaran masih terbuka.

Tidak hanya akan ada laporan, tetapi juga stand dari perusahaan terbaik:

Penyelenggara - Evrone
Mitra Umum - Toptal
Mitra Emas - Gett
Mitra Perak - Valarm , JetBrains , Bookmate dan Cashwagon
Mitra Perunggu - InSales