Bagaimana pengetikan statis sangat membantu dalam proyek yang lebih besar?

Saat mencari di halaman utama situs bahasa pemrograman scripting, saya menemukan bagian ini:

Ketika sebuah sistem menjadi terlalu besar untuk diingat, Anda dapat menambahkan tipe statis.

Ini membuat saya ingat bahwa dalam banyak perang agama antara statis, bahasa yang dikompilasi (seperti Jawa) dan dinamis, bahasa yang ditafsirkan (terutama Python karena lebih banyak digunakan, tetapi ini merupakan "masalah" yang dibagikan di antara sebagian besar bahasa scripting), salah satu keluhan dari statis penggemar bahasa yang diketik di atas bahasa yang diketik secara dinamis adalah bahwa mereka tidak dapat mengukur dengan baik untuk proyek yang lebih besar karena "suatu hari, Anda akan melupakan jenis fungsi yang dikembalikan dan Anda harus mencarinya, sementara dengan bahasa yang diketik secara statis semuanya dinyatakan secara eksplisit ".

Saya tidak pernah mengerti pernyataan seperti ini. Sejujurnya, bahkan jika Anda mendeklarasikan tipe kembalinya suatu fungsi, Anda dapat dan akan melupakannya setelah Anda menulis banyak baris kode, dan Anda masih harus kembali ke baris di mana ia dinyatakan menggunakan fungsi pencarian dari editor teks Anda untuk memeriksanya.

Sebagai tambahan, sebagaimana fungsi dideklarasikan dengan type funcname()..., tanpa mengetahui typeAnda harus mencari di setiap baris di mana fungsi dipanggil, karena Anda hanya tahu funcname, sementara dalam Python dan sejenisnya Anda hanya dapat mencari def funcnameatau function funcnameyang hanya terjadi sekali, pada deklarasi.

Terlebih lagi, dengan REPL itu sepele untuk menguji fungsi untuk itu jenis kembali dengan input yang berbeda, sementara dengan bahasa yang diketik secara statis Anda akan perlu menambahkan beberapa baris kode dan mengkompilasi ulang semuanya hanya untuk mengetahui jenis yang dideklarasikan.

Jadi, selain untuk mengetahui tipe kembalinya suatu fungsi yang jelas bukan titik kekuatan dari bahasa yang diketik secara statis, bagaimana pengetikan statis sangat membantu dalam proyek yang lebih besar?

Terlebih lagi, dengan REPL itu sepele untuk menguji fungsi untuk itu tipe pengembalian dengan input yang berbeda

Itu tidak sepele. Sama sekali tidak sepele . Ini hanya sepele untuk melakukan ini untuk fungsi sepele.

Misalnya, Anda dapat dengan sepele mendefinisikan fungsi di mana tipe pengembalian sepenuhnya bergantung pada tipe input.

getAnswer(v) {
 return v.answer
}

Dalam hal ini, getAnswertidak benar - benar memiliki tipe pengembalian tunggal. Tidak ada tes yang dapat Anda tulis yang menyebutnya dengan input sampel untuk mempelajari apa tipe pengembaliannya. Itu akan selalu tergantung pada argumen yang sebenarnya. Saat runtime.

Dan ini bahkan tidak termasuk fungsi yang, misalnya, melakukan pencarian basis data. Atau melakukan hal-hal berdasarkan input pengguna. Atau cari variabel global, yang tentu saja tipe dinamis. Atau ubah jenis pengembaliannya dalam kasus acak. Belum lagi kebutuhan untuk menguji setiap fungsi individu secara manual setiap kali.

getAnswer(x, y) {
   if (x + y.answer == 13)
       return 1;
   return "1";
}

Pada dasarnya, membuktikan jenis pengembalian fungsi dalam kasus umum secara matematis tidak mungkin (Menghentikan Masalah). Satu- satunya cara untuk menjamin jenis pengembalian adalah dengan membatasi input sehingga menjawab pertanyaan ini tidak termasuk dalam domain dari Masalah Pemutusan dengan melarang program yang tidak dapat dibuktikan, dan inilah yang dilakukan pengetikan statis.

Sebagai tambahan, ketika fungsi dideklarasikan dengan tipe funcname () ..., tanpa mengetahui tipe Anda harus mencari di setiap baris di mana fungsi dipanggil, karena Anda hanya tahu funcname, sementara di Python dan sejenisnya Anda tidak dapat hanya mencari fungsi funcname atau fungsi yang hanya terjadi sekali, pada deklarasi.

Bahasa yang diketik secara statis memiliki hal-hal yang disebut "alat". Mereka adalah program yang membantu Anda melakukan sesuatu dengan kode sumber Anda. Dalam hal ini, saya cukup mengeklik kanan dan Ke Definisi, terima kasih kepada Resharper. Atau gunakan pintasan keyboard. Atau cukup arahkan mouse dan itu akan memberi tahu saya apa tipe yang terlibat. Saya tidak peduli sedikit pun tentang menjepret file. Editor teks sendiri adalah alat yang menyedihkan untuk mengedit kode sumber program.

Dari memori, def funcnametidak akan cukup dengan Python, karena fungsinya dapat ditugaskan kembali secara sewenang-wenang. Atau bisa dideklarasikan berulang kali dalam banyak modul. Atau di kelas. Dll

dan Anda masih harus kembali ke baris yang dinyatakan menggunakan fungsi pencarian editor teks Anda untuk memeriksanya.

Mencari file untuk nama fungsi adalah operasi primitif yang mengerikan yang seharusnya tidak diperlukan. Ini merupakan kegagalan mendasar dari lingkungan dan peralatan Anda. Fakta bahwa Anda bahkan akan mempertimbangkan membutuhkan pencarian teks dengan Python adalah titik besar terhadap Python.

Pikirkan proyek dengan banyak programmer, yang telah berubah selama bertahun-tahun. Anda harus mempertahankan ini. Ada sebuah fungsi

getAnswer(v) {
 return v.answer
}

Apa yang dilakukannya? Apa v? Dari mana elemen itu answerberasal?

getAnswer(v : AnswerBot) {
  return v.answer
}

Sekarang kami memiliki lebih banyak info -; perlu jenis AnswerBot.

Jika kita pergi ke bahasa berbasis kelas yang bisa kita katakan

class AnswerBot {
  var answer : String
  func getAnswer() -> String {
    return answer
  }
}

Sekarang kita dapat memiliki variabel tipe AnswerBotdan memanggil metode getAnswerdan semua orang tahu apa fungsinya. Setiap perubahan ditangkap oleh kompiler sebelum pengujian runtime dilakukan. Ada banyak contoh lain tetapi mungkin ini memberi Anda ide?

Anda tampaknya memiliki beberapa kesalahpahaman tentang bekerja dengan proyek statis besar yang mungkin mengaburkan penilaian Anda. Berikut ini beberapa petunjuknya:

bahkan jika Anda mendeklarasikan tipe pengembalian suatu fungsi, Anda dapat dan akan melupakannya setelah Anda menulis banyak baris kode, dan Anda masih harus kembali ke baris yang dideklarasikan menggunakan fungsi pencarian editor teks Anda untuk Periksa.

Sebagian besar orang yang bekerja dengan bahasa yang diketik secara statis menggunakan IDE untuk bahasa tersebut atau editor cerdas (seperti vim atau emacs) yang memiliki integrasi dengan alat khusus bahasa. Biasanya ada cara cepat untuk menemukan jenis fungsi di alat-alat tersebut. Misalnya, dengan Eclipse di proyek Java, ada dua cara yang biasanya Anda temukan jenis metode:

• Jika saya ingin menggunakan metode pada objek lain selain 'ini', saya mengetik referensi dan titik (misalnya someVariable.) dan Eclipse mencari tipe someVariabledan menyediakan daftar drop-down semua metode yang didefinisikan dalam tipe itu; ketika saya gulir ke bawah daftar jenis dan dokumentasi masing-masing ditampilkan saat itu dipilih. Perhatikan bahwa ini sangat sulit dicapai dengan bahasa yang dinamis, karena sulit (atau dalam beberapa kasus tidak mungkin) bagi editor untuk menentukan apa jenisnya someVariable, sehingga tidak dapat membuat daftar yang benar dengan mudah. Jika saya ingin menggunakan metode, thissaya cukup menekan ctrl + space untuk mendapatkan daftar yang sama (walaupun dalam hal ini tidak sulit untuk mencapai bahasa dinamis).
• Jika saya sudah memiliki referensi yang ditulis untuk metode tertentu, saya dapat memindahkan kursor mouse ke atasnya dan jenis dan dokumentasi untuk metode ini ditampilkan dalam tooltip.

Seperti yang Anda lihat, ini agak lebih baik daripada perkakas khas yang tersedia untuk bahasa dinamis (bukan berarti ini tidak mungkin dalam bahasa dinamis, karena beberapa memiliki fungsi IDE yang cukup bagus - smalltalk adalah salah satu yang terlintas dalam pikiran - tetapi lebih sulit untuk bahasa yang dinamis dan karenanya cenderung tidak tersedia).

Sebagai tambahan, ketika fungsi dideklarasikan dengan tipe funcname () ..., tanpa mengetahui tipe Anda harus mencari di setiap baris di mana fungsi dipanggil, karena Anda hanya tahu funcname, sementara di Python dan sejenisnya Anda tidak dapat hanya mencari fungsi funcname atau fungsi yang hanya terjadi sekali, pada deklarasi.

Alat bahasa statis biasanya memberikan kemampuan pencarian semantik, yaitu mereka dapat menemukan definisi dan referensi ke simbol tertentu secara tepat, tanpa perlu melakukan pencarian teks. Misalnya, menggunakan Eclipse untuk proyek Java, saya dapat menyorot simbol di editor teks dan klik kanan dan pilih 'pergi ke definisi' atau 'cari referensi' untuk melakukan salah satu dari operasi ini. Anda tidak perlu mencari teks definisi fungsi, karena editor Anda sudah tahu persis di mana itu.

Namun, kebalikannya adalah bahwa mencari definisi metode dengan teks benar-benar tidak berfungsi dengan baik dalam proyek dinamis besar seperti yang Anda sarankan, karena mungkin ada banyak metode dengan nama yang sama dalam proyek seperti itu, dan Anda mungkin tidak memiliki alat yang tersedia untuk membedakan mana yang Anda panggil (karena alat tersebut sulit untuk ditulis terbaik, atau tidak mungkin dalam kasus umum), jadi Anda harus melakukannya dengan tangan.

Terlebih lagi, dengan REPL itu sepele untuk menguji fungsi untuk itu tipe pengembalian dengan input yang berbeda

Bukan tidak mungkin memiliki REPL untuk bahasa yang diketik secara statis. Haskell adalah contoh yang muncul dalam pikiran, tetapi ada REPL untuk bahasa yang diketik secara statis juga. Tapi intinya adalah Anda tidak perlu mengeksekusi kode untuk menemukan tipe kembalinya suatu fungsi dalam bahasa statis - itu dapat ditentukan dengan pemeriksaan tanpa perlu menjalankan apa pun.

sementara dengan bahasa yang diketik secara statis, Anda perlu menambahkan beberapa baris kode dan mengkompilasi ulang semuanya hanya untuk mengetahui tipe yang dideklarasikan.

Kemungkinannya adalah jika Anda memang perlu melakukan ini, Anda tidak perlu mengkompilasi ulang semuanya . Sebagian besar bahasa statis modern memiliki kompiler tambahan yang hanya akan mengkompilasi sebagian kecil dari kode Anda yang telah berubah, sehingga Anda bisa mendapatkan umpan balik yang hampir seketika untuk kesalahan ketik jika Anda membuatnya. Eclipse / Java, misalnya, akan menyoroti kesalahan ketik saat Anda masih mengetiknya .

1. Karena checker statis lebih mudah untuk bahasa yang diketik secara statis.
   • Minimal, tanpa fitur bahasa dinamis, jika dikompilasi, maka pada saat runtime tidak ada fungsi yang tidak terselesaikan. Ini biasa terjadi pada proyek ADA dan C pada mikrokontroler. (Program mikrokontroler terkadang menjadi besar ... seperti ratusan kloc besar.)
2. Pemeriksaan referensi kompilasi statis adalah subset dari invarian fungsi, yang dalam bahasa statis juga dapat diperiksa pada waktu kompilasi.
3. Bahasa statis biasanya memiliki lebih banyak transparansi referensial. Hasilnya adalah bahwa pengembang baru dapat masuk ke satu file dan memahami beberapa apa yang terjadi, dan memperbaiki bug atau menambahkan fitur kecil tanpa harus mengetahui semua hal aneh dalam basis kode.

Bandingkan dengan katakanlah, javascript, Ruby atau Smalltalk, di mana pengembang melakukan redefinisi fungsionalitas bahasa inti pada waktu berjalan. Ini membuat memahami proyek besar lebih sulit.

Proyek yang lebih besar tidak hanya memiliki lebih banyak orang, mereka memiliki lebih banyak waktu. Cukup waktu bagi semua orang untuk melupakan, atau melanjutkan.

Secara anekdot, seorang kenalan saya memiliki pemrograman "Job For Life" yang aman di Lisp. Tidak seorang pun kecuali tim yang dapat memahami basis kode.

Saya tidak pernah mengerti pernyataan seperti ini. Sejujurnya, bahkan jika Anda mendeklarasikan tipe kembalinya suatu fungsi, Anda dapat dan akan melupakannya setelah Anda menulis banyak baris kode, dan Anda masih harus kembali ke baris di mana ia dinyatakan menggunakan fungsi pencarian dari editor teks Anda untuk memeriksanya.

Ini bukan tentang Anda lupa jenis pengembalian - ini akan selalu terjadi. Ini tentang alat yang dapat memberi tahu Anda bahwa Anda lupa jenis pengembalian.

Sebagai tambahan, karena fungsi dideklarasikan dengan tipe funcname()..., tipe whitout mengetahui Anda harus mencari di setiap baris di mana fungsi dipanggil, karena Anda hanya tahu funcname, sementara dalam Python dan sejenisnya Anda hanya bisa mencari def funcnameatau function funcnameyang hanya terjadi sekali , di deklarasi.

Ini adalah masalah sintaksis, yang sama sekali tidak terkait dengan pengetikan statis.

Sintaks keluarga C memang tidak ramah ketika Anda ingin mencari deklarasi tanpa memiliki alat khusus yang Anda inginkan. Bahasa lain tidak memiliki masalah ini. Lihat sintaks deklarasi Rust:

fn funcname(a: i32) -> i32

Terlebih lagi, dengan REPL itu sepele untuk menguji fungsi untuk itu jenis kembali dengan input yang berbeda, sementara dengan bahasa yang diketik secara statis Anda akan perlu menambahkan beberapa baris kode dan mengkompilasi ulang semuanya hanya untuk mengetahui jenis yang dideklarasikan.

Bahasa apa pun dapat diartikan dan bahasa apa pun dapat memiliki REPL.

Jadi, selain untuk mengetahui jenis pengembalian fungsi yang jelas bukan poin kuat dari bahasa yang diketik secara statis, bagaimana pengetikan statis sangat membantu dalam proyek yang lebih besar?

Saya akan menjawab secara abstrak.

Suatu program terdiri dari berbagai operasi dan operasi-operasi tersebut disusun sebagaimana adanya karena beberapa asumsi yang dibuat pengembang.

Beberapa asumsi implisit dan beberapa eksplisit. Beberapa asumsi menyangkut operasi di dekat mereka, beberapa menyangkut operasi jauh dari mereka. Suatu asumsi lebih mudah untuk diidentifikasi ketika diekspresikan secara eksplisit dan sedekat mungkin ke tempat-tempat di mana nilai kebenarannya penting.

Bug adalah manifestasi dari asumsi yang ada dalam program tetapi tidak berlaku untuk beberapa kasus. Untuk melacak bug, kita perlu mengidentifikasi asumsi yang salah. Untuk menghapus bug, kita harus menghapus asumsi itu dari program atau mengubah sesuatu sehingga asumsi itu benar-benar berlaku.

Saya ingin mengelompokkan asumsi menjadi dua jenis.

Jenis pertama adalah asumsi yang mungkin atau mungkin tidak berlaku, tergantung pada input program. Untuk mengidentifikasi asumsi yang salah dari jenis ini, kita perlu mencari di ruang semua kemungkinan input program. Dengan menggunakan tebakan dan pemikiran rasional, kita dapat mempersempit masalahnya dan mencari di ruang yang jauh lebih kecil. Tetapi tetap saja, ketika sebuah program tumbuh sedikit, ruang input awalnya tumbuh pada tingkat yang sangat besar - ke titik di mana ia dapat dianggap tak terbatas untuk semua tujuan praktis.

Jenis kedua adalah asumsi yang pasti berlaku untuk semua input, atau pasti salah untuk semua input. Ketika kami mengidentifikasi asumsi semacam ini sebagai salah, kita bahkan tidak perlu menjalankan program atau menguji input apa pun. Ketika kami mengidentifikasi asumsi semacam ini sebagai benar, kami memiliki satu tersangka yang kurang perlu dipedulikan ketika kami melacak bug ( apa pun bug ). Oleh karena itu, ada nilai dalam memiliki asumsi sebanyak mungkin milik jenis ini.

Untuk menempatkan asumsi dalam kategori kedua (selalu benar atau selalu salah, terlepas dari input), kami membutuhkan jumlah informasi minimum yang tersedia di tempat asumsi tersebut dibuat. Di seluruh kode sumber program, informasi menjadi basi cukup cepat (misalnya, banyak kompiler tidak melakukan analisis antar-prosedur, yang membuat panggilan apa pun menjadi batas keras bagi sebagian besar informasi). Kami membutuhkan cara agar informasi yang diperlukan tetap segar (valid dan terdekat).

Salah satu caranya adalah memiliki sumber informasi ini sedekat mungkin dengan tempat di mana itu akan dikonsumsi, tetapi itu tidak praktis untuk sebagian besar kasus penggunaan. Cara lain adalah dengan mengulangi informasi berulang kali, memperbarui relevansinya di seluruh kode sumber.

Seperti yang sudah bisa Anda tebak, tipe statis persis seperti itu - suar informasi jenis yang tersebar di seluruh kode sumber. Informasi itu dapat digunakan untuk menempatkan sebagian besar asumsi tentang ketepatan jenis dalam kategori kedua, yang berarti bahwa hampir semua operasi dapat diklasifikasikan sebagai selalu benar atau selalu salah sehubungan dengan kompatibilitas jenis.

Ketika jenis kami tidak benar, analisis menghemat waktu kami dengan membawa bug ke perhatian kami lebih awal daripada terlambat. Ketika jenis kami benar, analisis menghemat waktu kami dengan memastikan bahwa ketika bug terjadi, kami dapat segera mengesampingkan kesalahan jenis.

Anda ingat pepatah lama "sampah masuk, buang keluar", yah, ini yang mencegah pengetikan statis. Ini bukan obat mujarab universal tetapi ketatnya jenis data apa yang diterima dan dikembalikan secara rutin berarti Anda memiliki kepastian bahwa Anda bekerja dengan benar.

Jadi rutin getAnswer yang mengembalikan integer tidak akan berguna ketika Anda mencoba menggunakannya dalam panggilan berbasis string. Pengetikan statis sudah memberitahu Anda untuk berhati-hati, bahwa Anda mungkin melakukan kesalahan. (dan tentu saja, Anda dapat menimpanya, tetapi Anda harus tahu persis apa yang Anda lakukan, dan menetapkannya dalam kode menggunakan gips. Meskipun demikian, Anda tidak ingin melakukan ini - meretas dalam peg bulat menjadi lubang persegi tidak pernah bekerja dengan baik pada akhirnya)

Sekarang Anda dapat melangkah lebih jauh dengan menggunakan tipe yang kompleks, dengan membuat kelas yang memiliki fungsi bijih, Anda dapat mulai membagikannya dan tiba-tiba Anda mendapatkan lebih banyak struktur dalam program Anda. Program terstruktur adalah program yang jauh lebih mudah untuk membuat pekerjaan dengan benar, dan juga memelihara.