Penafian : ya, pada hari Senin kami menerbitkan habrapost dengan hanya perbandingan bahasa. Tidak, kami tidak gila. Semuanya berjalan sesuai rencana.
Vitaly Bragilevsky menggabungkan pengetahuan ilmu komputer teoretis dan praktik pemrograman saat ini. Dia mengajar disiplin ilmu yang berkaitan dengan ilmu komputer teoretis, adalah anggota Komite Standardisasi Haskell dan merupakan anggota komite pengawas untuk pengembangan kompilator GHC Haskell.
Habrastatya ini adalah wawancara hebat dengan Vitaly mengenai topik-topik berikut:
- Mengajar dan mengenal JavaScript;
- Mengapa memilih Haskell;
- Tempat bahasa fungsional dalam kehidupan seorang programmer;
- Apa gunanya JavaScript dan bagaimana ia berkembang;
- Apa yang akan muncul dalam bahasa pemrograman dalam 10-15 tahun ke depan;
- Bahasa pemrograman mana yang kredibel dan mengapa;
- Apa perbedaan antara konferensi ilmiah dan konferensi pengembang. Mengapa seorang guru bahkan pergi ke mereka;
- Apakah penting untuk membaca kepada programmer, apakah buku sudah usang dan mana di antara mereka yang harus dibaca.
Wawancara dilakukan oleh anggota Komite Program konferensi
HolyJS 2019 Moskow , Alexei
Zolotikh dan Artyom Kobzar. Jika wawancara tidak cukup untuk Anda, maka segera, di HolyJS berikutnya, Vitaliy akan memberi tahu dan menunjukkan dengan contoh bagaimana menghubungkan JavaScript dengan teori algoritma.
Tentang Mengajar dan Mengenal JavaScript
Artyom : Di antara pendengar kami, terutama di antara komunitas JavaScript, Anda tidak dikenal luas, tolong beri tahu kami tentang diri Anda, apa yang Anda lakukan, apa hobi Anda - pekerja, profesional, mungkin tidak bekerja.
Vitaliy : Saya terutama mengajar, mengajar kursus di St. Petersburg State University dan secara berkala berpartisipasi dalam karya-karya lain. Karena saya seorang guru, saya harus belajar banyak topik berbeda. Seperti yang biasanya terjadi di universitas, ada kebutuhan untuk membaca kursus tertentu, dan untuk ini Anda perlu memahami semua ini.
Kebetulan saya mengajar banyak hal. Sebagai contoh, salah satu kursus khusus pertama saya, yang saya ditugaskan di tahun pertama kerja, ketika saya masih sangat muda, disebut "teknologi Web XML." Lalu ini adalah topik hangat, Ajax baru saja muncul di JavaScript, dan benar-benar tidak ada literatur. Saya menjelaskan cara menggunakan semua ini.
Sejak itu tidak ada yang benar-benar mengerti cara menggunakannya, semuanya terbatas pada contoh-contoh seperti ini: ada dua daftar drop-down, pengguna memilih item di salah satu daftar, permintaan dikirim ke server, dan Anda menerima data untuk mengisi daftar drop-down kedua. Itu adalah hal yang baru, ada beberapa situs di situs tersebut. Maka hanya pencarian Google yang muncul dalam mode beta, ketika, saat Anda mulai mengetikkan beberapa jenis pertanyaan, ia memberitahu Anda untuk melanjutkan. Barang-barang Ajax adalah barang baru, dan saya mengajar mereka.
Apa yang saya tidak ajarkan hanya setelah itu: hal-hal matematika dan programmer. Suatu ketika saya bertemu Haskell, dan sejak saat itu ia menjadi area utama daya tarik, yang saya lakukan. Selain mengajar, mempelajari segala sesuatu dalam ilmu komputer secara umum, untuk mengajar, saya mulai berkolaborasi dengan penerbit "DMK-press", menerjemahkan beberapa buku untuk mereka (dengan orang lain, saya mengedit sesuatu sendiri). Itu juga ada di sekitar Haskell. Mungkin kedua jenis kegiatan ini - mengajar dan apa yang terkait dengan menerjemahkan buku ke dalam bahasa Rusia - ini adalah hal utama yang saya lakukan.
Artyom : Yaitu, kami langsung memanggil veteran JavaScript untuk kami. Saya menemukan Ajax dan, mungkin, bahkan PHP.
Vitaliy : Ya, saya bahkan memprogram dalam PHP pada tahun-tahun awal, menulis beberapa situs.
Tentang alasan memilih Haskell
Artyom : Anda paling terkenal di komunitas Haskell. Mengapa Anda berhenti di Haskell dan ekosistem ini?
Vitaliy : Karena saya tidak pernah menganggap karier sebagai programmer untuk diri saya sendiri, saya bebas dalam apa yang saya sukai. Saya tidak perlu tertarik dengan apa yang mereka bayar lebih banyak. Ketika saya mengetahui tentang Haskell, saya sangat menyukainya. Ini tidak terlalu baik untuk dibicarakan, dan entah bagaimana saya bahkan membiarkan diri saya mengatakan sesuatu seperti "Haskell adalah bahasa untuk orang pintar di komunitas berbahasa Inggris, dan komunitas rata-rata lebih pintar." Orang Amerika mengalahkan saya untuk ini, dan mereka benar. Tapi itulah yang membuat saya tertarik.
Itu, pada suatu waktu, ketika saya masih belajar di universitas, saya terlibat dalam matematika yang agak ketat, jadi beralih ke topik pemrograman yang relatif keras sangat alami bagi saya. Secara umum, jelas bahwa sekarang, dari bahasa pemrograman yang digunakan dalam produksi, Haskell adalah salah satu yang paling intensif sains, atau sumber daya intensif. Semua abstraksi ini yang ada paling dekat dengan matematika. Karena itu, bagi saya itu adalah pilihan alami.
Tentang bahasa fungsional dan tempat mereka di dunia programmer
Alexei : Bagaimana perasaan Anda tentang bahasa yang dinamis dan fungsional? Bagaimana dengan hal-hal seperti Lisp?
Vitaliy : Saya suka memposisikan diri saya bukan sebagai Haskellist, tetapi sebagai pecinta bahasa pemrograman pada umumnya. Pertama, jelas bahwa semua bahasa memiliki hak untuk hidup. Saya percaya bahwa membandingkan bahasa pemrograman dengan basis "lebih baik-lebih buruk" adalah pekerjaan yang sepenuhnya bodoh. Sayangnya, ini sering dilakukan di jejaring sosial dan tidak hanya, tetapi ini tidak masuk akal.
Saya suka mempelajari fitur-fitur bahasa pemrograman dan entah bagaimana mengklasifikasikan bahasa pemrograman dengan fitur-fitur ini. Tetapi untuk mempertimbangkan bahwa ini adalah fitur yang baik, dan ini buruk adalah bodoh. Oleh karena itu, jelas bahwa bahasa dengan pengetikan dinamis tentu memiliki hak untuk hidup. Sebagai contoh, saya sekarang dalam kursus saya untuk mahasiswa baru mengambil bahasa pemrograman Julia sebagai dasar. Ini adalah bahasa yang dinamis, ada sistem tipe. Sangat menarik bagi saya untuk mengajarinya, pada saat yang sama melihat area penerapan ini.
Secara umum, bahasa fungsional pertama yang saya temui adalah Lisp. Ketika saya membaca buku
"Struktur dan Interpretasi Program Komputer" bertahun-tahun yang lalu, tentu saja, ini semua mengesankan. Karena itu, saya sangat tertarik dengan semua ini. Sebagai contoh, saya juga sangat menyukai JavaScript, karena saya tahu sejarahnya dengan baik.
Saya tahu bahwa ketika pertama kali muncul, itu seharusnya sesuatu seperti Lisp, karena pada awalnya sintaks aslinya mirip-Skema. Dan kemudian, alih-alih, untuk beberapa alasan pemasaran, itu diganti dengan yang seperti C, tapi, tentu saja, bahasa Lisp duduk di dalam, dan itu mengesankan saya.
Secara umum, saya merasa bahwa banyak pecinta JavaScript tidak mengetahui hal ini, dan mereka baik-baik saja, tetapi saya tahu, jadi saya bahkan lebih baik. Jadi semua bahasa bagus, dan menarik bagi saya untuk mempelajarinya, menarik untuk mempelajari bidang penerapan, menarik untuk melihat apa yang menjadi lebih mudah dan lebih nyaman. Dan secara umum, perbandingan bahasa seperti itu untuk tugas-tugas individu juga merupakan bidang menarik yang terpisah, yang ingin saya tangani.
Apa yang baik dalam javascript
Artyom : Ketika Anda sedang menyiapkan laporan, Anda telah berhubungan dengan versi baru JavaScript, dengan apa yang tertanam di dalamnya. Apa yang bisa Anda pilih baik, buruk, mungkin beberapa solusi menarik dari sudut pandang teori bahasa pemrograman?
Vitaliy : Mengevaluasi dari sudut pandang berbagai bahasa pemrograman, tentu saja, hal yang paling menarik dalam JavaScript adalah model objeknya. Inilah yang sejak awal. Model prototipe memiliki sejarah yang sangat kaya, sangat menarik karena praktis tidak ada bahasa modern yang memilikinya sekarang.
Dalam bahasa seperti C #, menggunakan metode ekstensi, mereka memecahkan masalah menambahkan metode ke objek yang ada. Inilah yang dilakukan JavaScript sejak awal, dan di sana terlihat jauh lebih alami. Artinya, kami memiliki prototipe yang kami tambahkan metode dan kemudian membuat objek baru berdasarkan itu. Dalam bahasa seperti C #, ini lebih artifisial, menurut saya.
Saya tertarik untuk melihat bagaimana modul ditambahkan ke JS. Dalam JavaScript, untuk waktu yang sangat lama telah ada masalah yang terkait dengan modul, selama beberapa dekade, Anda dapat mengatakan, dan saya bertanya-tanya bagaimana mereka mulai melakukan semua ini. Karena modul adalah topik teoretis yang mendalam, ada banyak pendekatan berbeda untuk implementasinya. Benar, saya tidak bisa mengatakan bahwa saya benar-benar mempelajari hal ini, tetapi bagi saya ini adalah kasus yang menarik di bidang pengembangan bahasa pemrograman. Yaitu, cara menambahkan fitur ke bahasa yang ada yang sebelumnya tidak ada.
Ini masih menarik karena beberapa tahun yang lalu di Haskell ada upaya untuk menambahkan, katakanlah, modul yang lebih tepat. Sekarang kita dapat mengatakan bahwa upaya ini gagal, tidak ada yang mulai menggunakannya. Ini adalah apa yang disebut proyek ransel, yaitu, tampaknya diimplementasikan, tetapi penggunaannya sangat tidak signifikan sehingga menjadi jelas bahwa mereka membuat sistem modular baru yang baik, tetapi tidak berhasil dengan baik.
Saya merasa dari berbicara dengan orang yang berbeda yang terlibat dalam JavaScript bahwa modul di JS ternyata lebih baik. Benar, saya tahu ini sangat dangkal. Saya pikir pendapat tentang JavaScript sangat dipengaruhi oleh fakta bahwa Anda dapat menulis kode yang sangat buruk di sana. Dan jika Anda dapat menulis kode yang sangat buruk, seseorang harus menulisnya dalam jumlah besar. Ini berdampak negatif pada penilaian bahasa. Dari sudut pandang teori bahasa pemrograman, ini, tentu saja, tidak terlalu baik.
Alexey : Apakah Anda berhasil melihat versi JavaScript terbaru? Apa yang mengejutkan selain sistem modul?
Vitaliy : Saya tidak bisa mengatakan bahwa saya berhasil. Saya membalik-balik sesuatu, tetapi tidak terlalu dalam. Saya tidak bisa daftar.
Apa yang akan muncul dalam bahasa pemrograman dalam waktu dekat
Artyom : Teori bahasa pemrograman adalah lingkungan yang agak akademis dan, pada prinsipnya, menarik. Apa saja fitur baru dalam bahasa yang akan muncul dalam 10-15 tahun? Penelitian apa yang saat ini sedang berlangsung di bidang ini?
Vitaliy : Saya akan mengatakan bahwa topik terpanas saat ini adalah pengetikan bertahap. Ini adalah ketika pada saat yang sama dalam program ada bagian yang diketik dan tidak diketik. Ini untuk Python, untuk JavaScript, ini dilakukan untuk bahasa mainan. Artinya, kita dapat, pertama, menggabungkan bagian yang diketik dan yang tidak diketik, dan kedua, kita memiliki cara sederhana untuk memperluas pengetikan.
Artinya, kami sedang melakukan implementasi prototipe dari sesuatu, karena selalu dilakukan dalam bahasa yang dinamis tanpa jenis apa pun, dan kemudian kami mulai menggantung jenis pada komponen individual, lebih dan lebih. Idealnya, kami mendapatkan program yang diketik dengan semua manfaatnya. Ada lebih sedikit kesalahan saat menjalankan dan sebagainya.
Ini mungkin salah satu perkembangan paling penting. Beberapa elemen sudah dalam bentuk perpustakaan, tetapi sejauh ini masih merupakan bidang penelitian. Jika kita menonton konferensi terkemuka tentang bahasa pemrograman, pasti ada beberapa bagian yang ditujukan untuk pengetikan bertahap, pengetikan. Ini adalah sesuatu yang hampir pasti akan dimasukkan dalam sebagian besar bahasa dinamis, karena sangat nyaman. Ternyata kombinasi dari dua dunia.
Selama sepuluh tahun, penelitian telah dilakukan pada tipe dependen, ketika tipe tergantung pada nilai-nilai. Masalah terbesar adalah bahwa ia menghapus garis antara tahap kompilasi dan tahap eksekusi, karena pada tahap kompilasi nilai-nilai spesifik belum diketahui, tetapi jenis perlu diperiksa. Artinya, nilai-nilai spesifik muncul dalam runtime, tetapi jenisnya harus sudah benar.
Dan di sana Anda sudah perlu menulis fungsi di mana, tergantung pada nilai yang diteruskan, jenis hasil berubah. Ini kabur batas antara runtime dan waktu kompilasi adalah hal yang sangat menarik, itu juga sedang dipelajari secara aktif dalam teori selama 10-15 tahun sekarang dan hampir pasti akan jatuh ke dalam banyak bahasa, terutama yang diketik secara statis, karena sistem tipe ekspresif karena perkembangan ini meningkat secara signifikan.
Benar, ada sisi buruknya. Ternyata program menulis bisa terlalu rumit. Tampaknya tipe-tipe itu mengendalikan segalanya, tetapi menulis itu sangat sulit, jadi kadang-kadang Anda berpikir bahwa persetan dengan tipe-tipe dependen ini, ambil beberapa tipe apa saja dan programkan.
Artyom : Mereka melakukannya di sini.
Vitaliy : Ini juga bisa dilakukan dengan keinginan besar, hanya kadang-kadang tidak ada tempat untuk pergi. Ketika Anda mendapatkan dari server, tidak mengerti apa, dan sampai Anda memulai program, Anda tidak tahu, Anda masih harus menggunakan hal-hal seperti itu, bahkan di Haskell, tidak ada tempat untuk dikunjungi.
Bagaimana Vitaly mengembangkan Haskell
Artyom : Lucu sekali. Kembali ke Haskell. Anda adalah anggota komite Haskell 2020. Di Podlodka, Anda mengatakan bahwa Anda tidak melakukan apa pun di sana, tetapi dalam satu wawancara Anda menyebutkan bahwa Anda masih bekerja pada keluarga fungsi yang sederhana dan terbatas. Apa hal spesifik lain yang Anda terapkan, awasi, atau berpartisipasi dalam implementasi, mungkin, standar Haskell yang baru?
Vitaliy : Ini adalah dua komite yang berbeda. Saya punya dua komite. Salah satunya adalah Haskell 2020, di mana tidak ada yang benar-benar terjadi, itu adalah komite mati. Tujuannya adalah untuk menulis standar bahasa, dan itu pasti tidak akan ditulis. Kedengarannya lebih baik - "Komite untuk pengembangan standar bahasa", tetapi tidak berhasil.
Komite kedua disebut "Komite Pengawas Kompilator GHC" - Glasgow Haskell Compiler. Saya telah berada di dalamnya selama lebih dari setahun, tugasnya jauh lebih tidak ambisius. Komite ini mempertimbangkan fitur, saran untuk mengubah kompiler dan versi bahasa yang diterapkan dalam kompiler ini. Ada Haskell standar, tetapi ada Haskell diimplementasikan oleh kompiler tertentu. Berikut adalah contoh ekstensi bahasa tersebut: “keluarga tipe sederhana”. Ini adalah upaya untuk memfasilitasi pemrograman level-type dengan menambahkan kontrol tambahan.
Benar, saya harus mengatakan bahwa ada lingkungan yang cukup bebas, yaitu, saya mungkin tidak mengikuti alat peraga sepanjang musim panas dan berutang banyak waktu kepada komite ini, saya berencana untuk kembali ke sini.
Tugas saya ada ini - shefed itu: ada proposal yang dijelaskan, saya perlu melihat, mungkin menyarankan penulis untuk menyelesaikan sesuatu dan akhirnya pergi ke komite dengan proposal baik untuk merekomendasikan dimasukkannya dalam kompiler, atau menolak. Setelah saya mengajukan proposal ini, panitia membahas dan membuat keputusan - semuanya diputuskan secara kolektif di sana.
Salah satu kalimat yang saya berhutang terkait dengan garis bawah dalam penjelasan standar. Ketika Anda tidak dapat menentukan jenis sepenuhnya, yaitu ada lubang di sana, dan ada proposal untuk mereformasi sistem ini agar entah bagaimana menganalisis semuanya secara seragam. Lubang dapat dalam anotasi standar, dalam implementasi fungsi. Suatu pendekatan terpadu tertentu diusulkan.
Komite ini mempertimbangkan perubahan kecil dalam kompiler.
Artyom : Kami juga memiliki komite standardisasi - TC39. Pada awalnya, seseorang datang dan dia mencari seorang juara. Seorang juara adalah orang dari komite yang siap untuk mengawasi situs ini. Kemudian, sejauh yang saya tahu, kita memiliki kelulusan berdasarkan tahapan. Ada 4 tahap di mana fitur bergerak. Nol adalah ketika hanya ada proposal, satu adalah ketika juara ditemukan dan API tingkat tinggi dijelaskan, dan seterusnya. Keempat sudah dimasukkan ke dalam bahasa. Orang yang melakukan persiapan, dan kurator berpartisipasi dalam pertemuan komite ini dan mempromosikan dalil ini. Bagaimana denganmu? Apakah hanya komite yang kemudian memutuskan secara internal?
Vitaliy : Semua aktivitas kami terbuka, dilakukan di GitHub dan sebagian di milis terbuka. Penulis proposal masuk - sementara kami mempertimbangkan proposal, implementasi tidak begitu menarik bagi kami. Mungkin, mungkin juga tidak, kami tidak menganalisisnya dengan cara apa pun, tidak ada yang bergantung padanya. Pertama, ada diskusi oleh komunitas luas, semua orang dapat mengomentari proposal ini.
Kemudian, ketika dia duduk, penulis menyerahkannya ke komite, yaitu, meminta komite untuk mempertimbangkannya. Sekretaris komite menunjuk seorang gembala yang akan mengawasinya. Dia melihat, menganalisis, mungkin menawarkan perbaikan atau, sebaliknya, mencoba untuk membenarkan mengapa ini tidak memiliki hak untuk hidup, setelah itu dia mengeluarkan proposal untuk menolak atau, mungkin, mengirim revisi, atau menerima. Komite membahas, membuat keputusan.
Dan ketika komite memutuskan bahwa kami setuju dengan pra-situs ini, dan masuk ke status diterima, pada prinsipnya, siapa pun dapat mengambil implementasinya. Hingga saat ini, mungkin tidak ada implementasi, kami hanya membuat keputusan - ya, akan menyenangkan untuk memiliki fitur seperti itu dalam bahasa atau kompiler, dan kami memiliki daftar sub-node yang diterima, tetapi tidak diimplementasikan.
Selanjutnya, ini bukan lagi tugas komite, maka siapa pun membuat permintaan tarikan ke kode sumber kompiler, ada insinyur, tim tumpang tindih sebagian dengan komite, mereka yang sudah memutuskan apakah permintaan tarikan ini diterima atau tidak.
Karena komite setuju untuk menerima ini, yaitu, pada prinsipnya, perlu untuk menerima permintaan penggabungan, tetapi ada pertanyaan teknik di sana, itu tidak disandikan di sana, beberapa masalah kinerja diselesaikan oleh tim yang secara langsung mengembangkan kompiler. Ini bukan lagi tugas kami.
Alexei : Ternyata Haskell sekarang memiliki standar yang cukup lama. Saya melihat ada Haskell 2010.
Vitaly : Ya, 2010, sangat tua. Ada beberapa upaya untuk menulis yang baru. Ada ide untuk mengeluarkan standar setiap tahun, tetapi, sayangnya, semuanya gagal. Pada 2016, sebuah komite 2020 bertemu, tetapi ia juga tidak melakukan apa pun. Ada beberapa alasan berbagai tingkat kesulitan, mengapa pekerjaan ini tidak berkelanjutan. Ya, standar terbaru 2010, tidak ada yang baru dan tidak terlihat akan muncul.
Tentang kursus dan proyek baru
Artyom : Mari kita kembali ke aktivitas utama Anda, ke mengajar. Saya pribadi bertemu Anda di jalannya teori kategori, yang sangat saya sukai. Anda mengatakan Anda tidak menyukainya. Kursus apa lagi yang Anda miliki yang mungkin Anda banggakan dan yang menurut Anda akan menyenangkan untuk ditemui? Sebagai contoh, kursus mungkin dengan tiang tembok, tetapi pada prinsipnya, program narasi itu sendiri sangat bagus.
Vitaly : Pertama,
saya telah mempublikasikan
di YouTube semua kursus yang saya miliki. Di sana saya memiliki kursus tentang Idris - ini adalah bahasa pemrograman dengan tipe dependen, dan bahkan dua versi, saya membacanya dua kali. Saya juga punya beberapa kursus tentang kompiler bahasa Haskell di sana. Yang satu dikhususkan untuk masalah model-teori. Saya tidak ingat persis namanya, tetapi ada tentang bagaimana teori jenis bekerja langsung di kompiler Haskell.
Idenya sederhana: semua kode Haskell dikompilasi menjadi beberapa λ-kalkulus yang cukup sederhana, yang disebut sistem F dengan ekstensi kecil. Ini sebenarnya dalam kode kompiler, dan kursus berfokus pada bagaimana elemen-elemen teori tipe ini digunakan secara langsung dalam kompiler.
Dan ada kursus di mana saya biasanya berbicara tentang sejarah inferensi tipe dan bagaimana inferensi tipe diatur di awal, ketika diciptakan pada tahun 60an, sebelum inferensi tipe diatur dalam bahasa Haskell, apa kesulitannya bagaimana cara kerjanya.
Ada kursus singkat yang saya ajarkan di sekolah matematika musim panas. Di sana, dari waktu ke waktu, seperti yang saya diberitahu, mereka mengambil kursus ilmu komputer sehingga anak-anak beristirahat. , , , , : . — — . , , , .
, , . - , , , , , , - . , - , . , , - - . .
. -, , , , , . , . , - , -, - , , . - , , - , . . , , .
, , , . , , , , , , .
: - ? , , . , , , , - .
: Computer Science Club. , , , . , .
10 . « GHC Haskell: ». GHC, , 40 , 10 . : .
, Haskell, , . , , . .
, 1-2 . . , ,
. , : , — , - , . , .
, , , . , , . , .
, , , , , . , .
: , JetBrains - , . ? , - ?
: JetBrains , Haskell , JetBrains Haskell- , .
: Haskell JetBrains?
: Haskell c JetBrains, . , .
: Haskell JetBrains?
: - Haskell JetBrains? , .
: , . ()
: . , Java, Haskell.
: , JetBrains?
: JetBrains Education. JetBrains Research — , Education — .
JavaScript-
: , , , JavaScript? , , , Elm, Haskell.
: -, . GHCJS , , , . Elm , Haskell, . , , - .
, , , . JavaScript .
, Idris — Idris PHP, JavaScript, . . , , JavaScript Haskell .
, - , — , — , .
— , , , , . , . ,
HolyJS , , , , , . — , .
, λ- , — λ-, , , . , λ-, , .
1936 , — . , .
: , ? Swift, , enum , Union, ?
: , , . : , , . , , Python , , .
, , Python, . , , , .
, , , , , . C#. C# : -, Microsoft Java, , ,
, Delphi, #, C# , Haskell, .
, . , JetBrains, Kotlin, . Kotlin, C#, Swift Apple, . , .
++ - , , , - , , , . , , , JavaScript , . , , .
, , .
: -, , , Mozilla Rust.
: , Mozilla — , , - open source-, . . , Rust , . , Rust , - , .
, Twitter — - Microsoft, , , C++ Microsoft Rust. , . , Rust. , , , , . , .
Rust , - , .
: ! , , , , , — , . , , , - , ?
: , , . , . -, , . . , , — . — , , . .
— , , -, , . , .
, , , . , , . . , , , , . - . . .
: ? , , , , , ?
: , . , , , , . , - , , , , . , . , — . , , .
, — .
: HolyJS ? , - ? , .
: , , , , , . , , . , .
, , AppsConf. . . , .
, , , . : « , ?». - , , : , , Twitter , Google . , .
. , , , , , , , .
, , , . — , .
Apakah programmer membutuhkan buku
Artyom : Satu pertanyaan lagi, mungkin kacau. Sudahkah Anda menulis buku tentang Haskell bernama
Haskell in Depth ?
Vitaliy : Sayangnya, buku itu tidak ditulis dalam proses. Ini disebut "program akses awal." Dan dia, sayangnya, melambat, dan saya perlahan-lahan kembali untuk mengerjakannya. Sekitar setengahnya ditulis di sana, dan setengah lainnya ditunda, yang mana saya sangat malu dengan mereka yang memperoleh akses awal ini.
Artyom : Ini adalah fakta yang menarik: ada pendapat di masyarakat bahwa buku tentang pemrograman, terutama jika mereka bukan tentang pengetahuan dasar, tidak terlalu baik, karena informasi dengan cepat menjadi usang. Bagaimana Anda, sebagai penulis buku, memiliki pengalaman seperti itu? Dan apakah Anda menganggap masalah sedemikian rupa sehingga informasi yang Anda berikan dalam sebuah buku dapat dengan cepat menjadi usang?
Vitaliy : Tentu saja, saya tidak mengerti bagaimana buku ditulis dalam JavaScript - menurut saya, ini adalah tugas yang mustahil. Dengan Haskell, dalam hal ini sedikit lebih mudah. Tapi inilah yang bisa saya katakan.
Ketika kita belajar matematika di sekolah, matematika ini juga umumnya sangat ketinggalan jaman. Ini adalah hal-hal yang muncul beberapa ribu tahun yang lalu, beberapa teorema Pythagoras. Mungkin ini masih sedang diterapkan, tetapi untuk mengatakan bahwa seseorang mengukur ketinggian piramida menggunakan teorema Pythagoras adalah sesuatu seperti ini, roulette laser biasanya digunakan atau sesuatu seperti itu.
Hampir sama di sini. Jika seseorang adalah seorang profesional hebat dalam sesuatu dan telah menggunakan beberapa teknologi untuk waktu yang lama, tentu saja, dia tidak membutuhkan buku. Nah, buku itu bukan untuknya dan ditulis, diperlukan untuk masuk ke dalam semacam teknologi, untuk mulai memahami ini. Dan ketika Anda sudah masuk, Anda memiliki sumber lain untuk pengembangan.
Karena itu, menurut saya buku-buku itu tidak akan pergi ke mana pun. Ketika Anda mulai belajar sesuatu, tentu saja, Anda bisa belajar bahasa pemrograman dengan artikel, tetapi dalam kebanyakan kasus hasilnya tidak akan berhasil dengan baik. Paling sering ini adalah transfer ide-ide mereka tentang bahasa pemrograman lain ke yang baru. Anda tidak mengenali konstruksi idiomatik untuk bahasa ini dan tidak tahu bagaimana menggunakannya dengan benar.
Jadi pada awalnya lebih baik untuk mengambil buku, mengatasinya, dapatkan pangkalannya. Biarkan itu menggambarkan bukan versi terbaru dari perpustakaan, biarkan sesuatu ditambahkan ke bahasa, itu semua mungkin untuk mengejar ketinggalan. Untuk mendapatkan pangkalan, menurut saya, Anda masih membutuhkan buku. Ini untuk semua bahasa pemrograman, bahkan untuk JavaScript. Bagaimanapun, kita memerlukan semacam stabilitas, titik referensi seperti itu, yang dapat Anda rujuk.
Kebetulan, ini adalah salah satu tujuan ketika menulis standar bahasa Haskell untuk menciptakan titik yang stabil dalam sejarah bahasa di mana Anda dapat menulis buku. Lebih lanjut, dengan satu atau lain cara, bahasa dapat berkembang, tetapi ada standar, dan setiap siswa dapat fokus padanya.
Sangat menarik bagaimana buku memainkan peran standar untuk banyak bahasa pemrograman. Sebagai contoh, Straustrup menulis buku tentang C ++, dan ini adalah hal yang selalu bisa Anda rujuk. C ++ telah melangkah jauh ke depan, tetapi ketika mempelajari bahasa, sangat mungkin untuk fokus pada versi ini, yang dijelaskan oleh Straustrup.
Artyom : Anda mengangkat topik menarik tentang sumber daya yang dibutuhkan orang, yang tidak belajar bahasa, tetapi ingin melangkah lebih dalam dan melanjutkan. Anda dapat menyarankan beberapa sumber daya yang Anda gunakan untuk belajar, dan sumber daya yang sebaiknya dipelajari untuk seorang insinyur untuk membenamkan diri dalam teori. ilmu komputer, ke teori tipe, atau, seperti yang Anda katakan, menghilangkan ketidaktahuan tertentu seorang insinyur?
Vitaliy : Sulit bagi saya untuk memberikan contoh, saya tidak dapat mengatakan sama sekali bahwa saya memiliki sumber informasi reguler. Mungkin sumber terpenting bagi saya adalah Twitter. Ternyata semuanya datang kepada saya melalui Twitter. Beberapa tautan menarik muncul pada saya, saya menyimpannya untuk saya sendiri dan membacanya secara berkala. Saya merasa bahwa setidaknya di Haskell tidak ada sumber seperti itu, tetapi ada banyak orang terhormat yang menulis hal-hal yang masuk akal.
Saya entah bagaimana mencoba menggunakan Reddit secara teratur untuk tujuan ini, tetapi entah bagaimana itu tidak berhasil bagi saya, saya hanya tidak punya cukup waktu untuk mengikutinya. Tetapi di Twitter, bagaimanapun, semua yang muncul cepat atau lambat datang kepada saya. Cepat melihat, menarik - disimpan, lalu baca.
Jadi, secara umum, untuk merekomendasikan sesuatu di bidang ilmu komputer atau TI, jujur saja, saya tidak siap, saya tidak tahu situs atau sumber daya semacam itu. Bagi mereka yang terlibat dalam bahasa pemrograman, sumber penting adalah situs
http://lambda-the-ultimate.org . Semua hal yang paling menarik muncul di sana dan diskusi sedang berlangsung. Ini adalah bacaan wajib bagi mereka yang tertarik dengan teori bahasa pemrograman.
Apa yang dibaca oleh programmer
Alexei : kamu bilang buku tidak kedaluwarsa. Apakah ada daftar hal-hal yang harus dimiliki untuk dibaca, atau hanya buku favorit Anda untuk direkomendasikan? Saya berbicara tentang teori pemrograman, tentang literasi teknik umum.
Vitaliy : Saya secara berkala diminta untuk membuat daftar, saya tidak melakukan pekerjaan seperti itu, ini adalah tugas yang sangat sulit.
Menurut teori bahasa pemrograman, untuk mulai bergerak ke dalamnya, ada buku Pierce
"Jenis dalam Bahasa Pemrograman." Ini umumnya adalah jenis primer untuk memulai. Mungkin, sepertiga pertamanya akan berguna untuk semua programmer.
Kolega saya dan saya menerjemahkan sebuah buku berjudul
Pengantar Teori Bahasa Pemrograman . Ini sangat kecil, dan itu menjelaskan semantik formal, tipe inferensi, hal-hal teoritis dari kompilasi. Pengantar yang berguna untuk bahasa pemrograman.
Ada sebuah buku karya Charles Petzold
"Annotated Turing" . Ini adalah genre yang luar biasa: penulis mengambil artikel Turing pada tahun 1936, di mana Turing menggambarkan apa yang kemudian dikenal sebagai mesin Turing, dan menulis sebuah buku tebal yang menjelaskan artikel ini. Dan artikel itu sendiri adalah halaman 15. Selain itu, ada kisah dari kehidupan Turing sendiri, latar belakang tugas ini, bagaimana semuanya terjadi. Bagian demi bagian, ia memberikan potongan artikel dan penjelasan tentang apa yang dimaksud di sana.
Jika kita membaca artikelnya sekarang, itu akan sangat sulit bagi kita. Tetapi buku ini oleh Petzold luar biasa, ia menciptakan kembali seluruh konteks dan menggambarkan artikel itu sendiri. Saya merekomendasikan ini kepada semua orang, ini adalah bacaan yang sangat menarik, memperluas pikiran. Ada juga tentang λ-calculus, karena semuanya dekat, dan pertanyaan filosofis muncul terkait dengan perhitungan.
Juga, tentu saja, dari sudut pandang teknologi, saya penggemar berat buku
McConnell "Kode Sempurna" . Bagiku ini juga bacaan yang penting. Anda tidak dapat membaca semuanya secara berurutan, tetapi cukup membukanya di halaman acak, membaca beberapa halaman dan menutupnya. Ini tentang cara menulis kode.
Benar, saya baru-baru ini berbicara dengan beberapa pekerja seluler, mereka mengatakan bahwa buku bodoh yang tidak ada yang berguna. Tapi ini tentang bagaimana menulis kode semacam itu sehingga ia hidup untuk waktu yang lama, sehingga dapat didukung, diubah. Mungkin mereka benar-benar tidak membutuhkannya.
Ya, dan tidak ada Swift, tidak Kotlin, semacam Jawa di sana, contoh berbeda dalam bahasa yang berbeda yang programmer modern tidak lagi benar-benar berbicara tentang apa pun. Buku itu dimulai dari dua per seribu. Tapi saya pikir untuk programmer mana pun bacaan ini sangat berguna. McConnell masih bagus karena dia mengkonfirmasi semuanya dengan penelitian, mengatakan: “Jadi, kami telah melakukan penelitian ini dan itu, namun ini dan itu, dan inilah hasilnya. Mari kita bahas bersama bagaimana menulis kode untuk membuatnya bagus. "
Di sini, mungkin, cukup bacaan seperti itu.
Artyom : Untuk yang lebih khusus, saya akan bertanya: Anda merekomendasikan "Implementasi Kompiler Modern", yang tersedia dalam tiga versi -
Java ,
C dan
ML .
Vitaliy : Ya, ini adalah buku tentang kompiler. Saya tidak tahu jika semua orang perlu membacanya, itu lebih cenderung bagi mereka yang tertarik pada kompiler. Tapi, ya, saya suka - ini kecil, dan bekerja dengannya, Anda benar-benar dapat menulis kompiler Anda sendiri. Saya tidak yakin bahwa semua programmer perlu menulis kompiler mereka sendiri, tetapi jika Anda tiba-tiba penasaran, buku-buku Appel benar-benar menarik, tetapi sudah menjadi sesuatu yang sempit.
Sekarang saya tidak bisa mengingat semuanya. Secara berkala, sesuatu muncul ke permukaan, karena pada suatu waktu saya banyak membaca. Misalnya,
"Struktur dan interpretasi program komputer" juga klasik yang bermanfaat untuk membaca dan melakukan latihan. Meskipun saya tidak setuju, tetapi bacaan itu sendiri sangat bermanfaat.
Vitaly Bragilevsky akan datang ke konferensi HolyJS 2019 Moskow pada 8-9 November 2019 dengan laporan "JavaScript dalam layanan informatika teoretis." Tiket dapat dibeli di situs resmi .