Ketika teman saya dan saya pergi ke sekolah dan hanya bermimpi menjadi pengembang, kami berpikir bagaimana membuat sesuatu bersama - permainan atau program yang sangat berguna.
Saya mulai belajar pro dan C #, ini JavaScript. Kami lulus dari sekolah menengah, belajar di universitas, bertugas di ketentaraan, mendapat pekerjaan. Kami penuh dengan perkembangan industri di sana-sini, dan ketika kami berdua bosan, kami ingat di mana kami memulai.
Setelah mengumpulkan pengembang yang sudah berpengalaman, kami akhirnya memutuskan untuk membuat proyek kami sendiri - permainan video dua dimensi. Karena teman itu front yang bersih, dan saya penuh, browser menjadi platform yang jelas bagi kami. Saya dulu hanya mengembangkan bagian depan pada TypeScript, dan kami pikir tidak masalah, TS hanyalah superset dari JavaScript. Ambillah dan semuanya berjalan lancar. Bagaimanapun caranya. Ketika kami mulai berdiskusi tentang pekerjaan, kami dihadapkan pada jurang kesalahpahaman yang luar biasa.
Jadi saya melihat tugas membuat game. Saya seperti itu - ya, kami memiliki jenis "permainan", jenis "inventaris", jenis "benda", jenis "peta", jenis "lokasi". Secara kasar saya bisa membayangkan bagaimana mereka bekerja bersama, menggambarkan mereka, menyusun proyek dan semuanya bekerja. Kompilator memeriksa saya, saya melakukan semuanya dengan benar. Selanjutnya, saya mulai menulis kode yang menggunakan jenis ini. Karena kenyataannya, itu jauh lebih mudah bagi saya. IDE memberi tahu saya dan memeriksa kesalahan. Jika proyek akan - kemungkinan besar itu berhasil. Saya menghabiskan banyak waktu pada deskripsi tipe, dan itu bagus. Ini pendekatan saya.
Teman saya ingin melakukan yang sebaliknya - segera menulis kode dan tidak menjelaskan jenis apa pun. Dia tidak siap untuk mendefinisikan masalah sebagai keluarga tipe. Saya tidak ingin membangun di atasnya, saya tidak melihat tugas sebagai satu set kelas, tipe, catatan, atau hal lain seperti itu. Bagiku itu tidak terpikirkan. Kami berdua benar dalam banyak hal, kebenaran masing-masing dari kami tidak termasuk yang lain.
Serius, kami berbicara selama berjam-jam, tetapi masing-masing berbicara sendiri, seolah-olah dalam bahasa yang berbeda. Dan Anda tidak dapat menulis bahwa otak kita tidak fleksibel. Hanya setahun yang lalu, tanpa rasa sakit saya pindah ke dunia fungsional dari berorientasi objek, dan sebaliknya. Selain itu, saya menghabiskan banyak waktu untuk belajar JS, dan dia belajar beberapa bahasa yang diketik secara statis.
Tetapi teknologi, yang menjadi teknologi "pertarungan" pertama bagi pengembang, mendefinisikan mereka dengan sangat kuat sehingga dua orang dewasa yang berpengalaman sama sekali tidak siap untuk saling mendengarkan. Selama bertahun-tahun mempelajari pengembangan, visi kami telah berkembang terlalu berbeda dan pendekatan untuk memecahkan masalah tidak bekerja sama sekali.
Akibatnya, kami meninggalkan gagasan untuk bekerja sama. Pikiran segera terlintas di benak kita bahwa masalahnya hanya ada pada kita berdua. Mungkin, tetapi saya telah melihat ini dengan orang lain di industri ini.
Pengetikan statis dan dinamis memiliki perbedaan mendasar yang tidak dapat didamaikan
Kode saya menjawab pertanyaan "Cara bekerja dengan ini", dan sebagai kode untuk pengembang yang terbiasa dengan pengetikan dinamis - "Cara kerjanya." Kedua pendekatan memiliki hak untuk hidup, dan ada alat untuk keduanya, tetapi hanya satu yang bisa berada di garis depan.
Statis baik untuk proyek-proyek besar yang telah melakukan pengembangan selama ratusan tahun, dan dinamis untuk tim kecil, untuk tugas-tugas di mana kode hanya menulis sering dibutuhkan. Dengan dinamis, Anda menghemat waktu dan usaha di awal pengembangan, dan dengan statis di akhir.
Gagasan menempatkan jenis di garis depan sangat mempengaruhi pemikiran saya tentang pengembang.
Memilih C # di awal perjalanan, saya memaku tipifikasi statis untuk pandangan dunia saya, yang sekarang saya derita. Setelah melihat masalah, saya mencoba menyajikan solusinya sebagai serangkaian jenis dan prinsip interaksi mereka. Ketika saya mengembangkan modul, saya pertama-tama menentukan jenis apa yang beroperasi dan yang berinteraksi dengan lingkungannya. Saya bahkan tidak ingat bagaimana saya mendekati pemecahan masalah sebelumnya.
Semua pelatihan pemrograman Java adalah pelatihan dalam desain dan penggunaan tipe. .NET CLR - C # runtime - dibangun pada tipe dan tipe. Pengetikan statis adalah pusat dari desain pemrograman berorientasi objek (halo, kelas dari JS, saya memutuskan Anda tidak diperlukan). Implementasi kanonik dari sebagian besar pola OOP penuh dengan Interface, yang sama sekali tidak berarti dalam bahasa yang diketik secara dinamis.
Pola itu sendiri adalah hal yang lintas bahasa, tetapi bisakah seseorang memberi tahu saya mengapa pola "keadaan" diperlukan dalam bahasa yang diketik secara dinamis? Bagaimana dengan pembangun? Pola-pola ini bukan tentang pembangunan, ini tentang jenis. Jenis dan OOP terkait erat.
Anda tidak dapat membangun logika bisnis Anda berdasarkan jenis, tetapi Anda tidak tahu apa-apa tentang mereka dalam proses pengembangan. Itulah mengapa ada vendor front-end yang menutupi kode mereka dengan jumlah unit test yang tidak terbayangkan, yang hanya memeriksa basis kode untuk tidak adanya kesalahan tipe.
Kita semua tahu betul bahwa keamanan melalui liputan adalah ilusi. Tes ditulis dengan tangan, mereka, menurut definisi, kurang dapat diandalkan dibandingkan sistem pemeriksaan tipe yang dibangun ke dalam bahasa.
Ini tidak berarti bahwa bahasa yang diketik secara dinamis tidak diperlukan (pada kenyataannya, saya benar-benar berpikir bahwa mereka tidak diperlukan). Ini berarti bahwa ketika menggunakannya, Anda harus meninggalkan OOP sebagai paradigma dominan. Semua kesatuan data dan operasi ini untuk mereka yang memiliki pemeriksaan statis.
Pengembang yang saya tangani tidak percaya bahwa kehadiran pengetikan statis mengubah pendekatan untuk pengembangan, dan mereka menulis kode yang sama seperti dalam bahasa dinamis, menambahkan pengecekan tipe. Saya pikir ini pada dasarnya salah. Dan ini paling jelas terlihat dalam kasus dengan front-end modern.
Saya tahu mengkritik front adalah hal yang tabu. Suatu hari, saya dan teman saya memulai AI, yang mengolok-olok semua orang di Twitter, dan Brendan Ike membentaknya. Serius, pencipta javascript bertarung dengan jaringan saraf kita di komentar.
Untuk beberapa alasan yang tidak diketahui, orang-orang ini sama sekali tidak siap untuk hidup di dunia di mana visi mereka mengandung kesenjangan serius. Karena itu, saya hanya mengkritik mereka yang terburu-buru ke proyek saya yang diketik dengan pasti, dan menempatkan pesanan mereka sendiri di sana.
Kami akan hidup di dunia kecil kami, tetapi TypeScript mendorong kami
Jadi saya menulis kode yang karena jenis tidak dapat digunakan dengan salah. Dalam proyek ini, saya berharap orang lain menggunakan tipe juga. Kemudian kode saya akan berfungsi seperti yang saya maksudkan. Dan saya tidak sengaja menutupi semua kasus penyalahgunaan kode ini (karena mengetik tidak termasuk ini). Tetapi nama panggilan JS masuk ke dalam proyek, mengambil jenis tambang ini, membungkusnya dengan apa saja, dan mulai menggunakannya secara tidak benar, yang mengarah pada bug yang halus.
Pengembang JavaScript diyakinkan bahwa Typecript masih JS yang sama, tetapi dengan kemampuan untuk terkadang menambahkan pengecekan tipe statis jika mereka membutuhkannya. Ini tidak benar. Skripnya seratus kali lebih kuat, dan mereka hanya tertarik pada tiga persen kemampuannya.
Argumen yang paling merusak adalah TypeScript hanyalah superset dari JS. Namun dalam praktiknya, Anda tidak bisa tidak menganggap Typefip sebagai bahasa independen, bahkan jika Anda adalah raja yang terdepan. Karena di sini kita memerlukan pendekatan yang berbeda - statis, tidak dinamis.
Keuntungan utama dari pengetikan statis adalah jaminan. Jika Anda menggunakannya dalam satu modul, tetapi tidak di modul lain, Anda hanya menghabiskan waktu dan energi untuk deskripsi dan pengembangan jenis, tetapi tidak menerima jaminan apa pun.
Tampaknya banyak yang TypeScript adalah kompromi antara sistem tipe antara JS dan Java. Dia bukan kompromi, sistem tipenya hanya khusus.
Semuanya diperparah oleh kenyataan bahwa hari ini setiap detik pekerjaan di depan membutuhkan pengetahuan tentang TS. Ini mengarah pada fakta bahwa para pengembang JS mempelajari secara dangkal kemampuan dari ScriptScript, dan mulai menulis kode di atasnya, menciptakan sejumlah besar praktik berbahaya. Suatu situasi muncul ketika mereka benar-benar tidak memerlukan pemeriksaan pengetikan statis, tetapi mereka memaksakannya pada mereka dan mereka merusaknya. Akhirnya harus diakui bahwa pendekatan pembangunan dengan pengetikan dinamis dan statis saling bertentangan, ini bukan hal yang dapat dicampur.
JavaScript, seperti yang saya lihat, adalah alat yang sangat baik untuk menulis kode yang memecahkan masalah tanpa menyoroti abstraksi yang tidak perlu. Kasus paling mengerikan di dalamnya adalah pola pabrik Es. Anda dapat memberi makan instance ini contoh Anda, dan itu mencakup mereka dengan kekebalan runtime. Jika saya memproses objek saya dengan pabrik ini, itu akan memberi saya hal yang sama, tetapi ketika saya mencoba mengubah nilai salah satu properti, saya akan mendapatkan pengecualian. Hanya WAT?!?
Pola muncul karena front membaca di suatu tempat tentang imutabilitas keren, dan memutuskan untuk menyeretnya ke dalam bahasa mereka sendiri, yang sama sekali tidak dimaksudkan untuk kekebalan. Dalam naskah, saya bisa membuat pabrik yang sama, tetapi dengan kompilasi waktu larangan mutasi, dan tanpa pengecualian.
Di sisi lain, ini tidak perlu, karena ada pemrograman fungsional murni. Ambil F #, Haskell, OCaml, saya akan katakan, ReasonML - ada mutasi yang dilarang di luar kotak. Tapi saya khawatir jika Anda memberikan front-end ke bahasa fungsional, itu akan segera mulai memodernisasi dan membuat perilaku terlihat seperti JS.
Karena pilihan mengetik adalah jalan tanpa kembali. Semua solusi kompromi hanya memberikan ilusi kompromi. Anda bisa meletakkan tipe di garis depan atau tidak. Saya tidak tahu bagaimana semuanya akan berubah, mulai belajar C # dan JavaScript secara bersamaan dan sejajar satu sama lain. Tetapi sekarang saya begitu terpaku pada pemikiran saya bahwa saya tidak melihat dan tidak ingin melihat keuntungan dari pengetikan dinamis. Mereka, tetapi di luar pandangan saya, dan yang tersisa bagi saya adalah menutup mata terhadap mereka, seperti manifestasi dari dunia yang asing bagi saya yang harus saya jalani. Saya mengerti bahwa saya salah, tetapi saya harus bekerja di sini dan sekarang, dan tidak ada anggaran yang membanjiri kedua kutub.
Karena itu, saya tidak ingin mencari kompromi, tetapi saya berbicara langsung. Jika Anda baru mulai mempelajari pengembangan, mulailah dengan mengetik statis.