Bahasa bertipe dinamis versus bahasa bertipe statis

Apa kelebihan dan keterbatasan bahasa tipe dinamis dibandingkan dengan bahasa tipe statis?

Lihat juga : ada apa dengan cinta bahasa dinamis (utas yang jauh lebih argumentatif ...)

Kemampuan interpreter untuk menyimpulkan konversi tipe dan tipe membuat waktu pengembangan lebih cepat, tetapi juga dapat memicu kegagalan runtime yang Anda tidak bisa dapatkan dalam bahasa yang diketik secara statis di mana Anda menangkapnya pada waktu kompilasi. Tetapi yang mana yang lebih baik (atau bahkan jika itu selalu benar) sedang hangat dibicarakan di masyarakat akhir-akhir ini (dan sejak lama).

Cara yang baik untuk masalah ini adalah dari Pengetikan Statis Bila Mungkin, Pengetikan Dinamik Saat Dibutuhkan: Akhir Perang Dingin Antara Bahasa Pemrograman oleh Erik Meijer dan Peter Drayton di Microsoft:

Pendukung pengetikan statis berpendapat bahwa keuntungan pengetikan statis meliputi deteksi kesalahan pemrograman lebih awal (misalnya mencegah penambahan bilangan bulat ke boolean), dokumentasi yang lebih baik dalam bentuk tanda tangan jenis (misalnya memasukkan jumlah dan jenis argumen saat menyelesaikan nama), lebih lanjut peluang untuk optimisasi kompiler (misalnya mengganti panggilan virtual dengan panggilan langsung ketika tipe persis penerima dikenal secara statis), peningkatan efisiensi runtime (mis. tidak semua nilai perlu membawa tipe dinamis), dan pengalaman pengembang waktu desain yang lebih baik (misalnya mengetahui jenis penerima, IDE dapat menyajikan menu drop-down dari semua anggota yang berlaku). Fanatik pengetikan statis mencoba membuat kami percaya bahwa "program yang diketik dengan baik tidak dapat salah". Meskipun ini tentu terdengar mengesankan, itu adalah pernyataan yang agak kosong. Pengecekan tipe statis adalah abstraksi waktu kompilasi dari perilaku runtime program Anda, dan karenanya hanya sebagian suara dan tidak lengkap. Ini berarti bahwa program-program masih dapat salah karena properti yang tidak dilacak oleh pemeriksa tipe, dan bahwa ada program-program yang sementara mereka tidak dapat salah tidak dapat diperiksa jenisnya. Dorongan untuk membuat pengetikan statis menjadi kurang parsial dan lebih lengkap menyebabkan sistem tipe menjadi terlalu rumit dan eksotik seperti yang disaksikan oleh konsep seperti "tipe hantu" [11] dan "tipe goyah" [10]. Ini seperti mencoba lari maraton dengan bola dan rantai yang diikatkan ke kaki Anda dan dengan penuh kemenangan berteriak bahwa Anda hampir berhasil meskipun Anda keluar dengan jaminan setelah mil pertama. Pengecekan tipe statis adalah abstraksi waktu kompilasi dari perilaku runtime program Anda, dan karenanya hanya sebagian suara dan tidak lengkap. Ini berarti bahwa program-program masih dapat salah karena properti yang tidak dilacak oleh pemeriksa tipe, dan bahwa ada program-program yang sementara mereka tidak dapat salah tidak dapat diperiksa jenisnya. Dorongan untuk membuat pengetikan statis kurang parsial dan lebih lengkap menyebabkan sistem tipe menjadi terlalu rumit dan eksotik seperti yang disaksikan oleh konsep seperti "tipe hantu" [11] dan "tipe goyah" [10]. Ini seperti mencoba lari maraton dengan bola dan rantai yang diikatkan ke kaki Anda dan dengan penuh kemenangan berteriak bahwa Anda hampir berhasil meskipun Anda keluar dengan jaminan setelah mil pertama. Pengecekan tipe statis adalah abstraksi waktu kompilasi dari perilaku runtime program Anda, dan karenanya hanya sebagian suara dan tidak lengkap. Ini berarti bahwa program-program masih dapat salah karena properti yang tidak dilacak oleh pemeriksa tipe, dan bahwa ada program-program yang sementara mereka tidak dapat salah tidak dapat diperiksa jenisnya. Dorongan untuk membuat pengetikan statis kurang parsial dan lebih lengkap menyebabkan sistem tipe menjadi terlalu rumit dan eksotik seperti yang disaksikan oleh konsep seperti "tipe hantu" [11] dan "tipe goyah" [10]. Ini seperti mencoba lari maraton dengan bola dan rantai yang diikatkan ke kaki Anda dan dengan penuh kemenangan berteriak bahwa Anda hampir berhasil meskipun Anda keluar dengan jaminan setelah mil pertama. dan karenanya hanya sebagian suara dan tidak lengkap. Ini berarti bahwa program-program masih dapat salah karena properti yang tidak dilacak oleh pemeriksa tipe, dan bahwa ada program-program yang sementara mereka tidak dapat salah tidak dapat diperiksa jenisnya. Dorongan untuk membuat pengetikan statis menjadi kurang parsial dan lebih lengkap menyebabkan sistem tipe menjadi terlalu rumit dan eksotik seperti yang disaksikan oleh konsep seperti "tipe hantu" [11] dan "tipe goyah" [10]. Ini seperti mencoba lari maraton dengan bola dan rantai yang diikatkan ke kaki Anda dan dengan penuh kemenangan berteriak bahwa Anda hampir berhasil meskipun Anda keluar dengan jaminan setelah mil pertama. dan karenanya hanya sebagian suara dan tidak lengkap. Ini berarti bahwa program-program masih dapat salah karena properti yang tidak dilacak oleh pemeriksa tipe, dan bahwa ada program-program yang sementara mereka tidak dapat salah tidak dapat diperiksa jenisnya. Dorongan untuk membuat pengetikan statis menjadi kurang parsial dan lebih lengkap menyebabkan sistem tipe menjadi terlalu rumit dan eksotik seperti yang disaksikan oleh konsep seperti "tipe hantu" [11] dan "tipe goyah" [10]. Ini seperti mencoba lari maraton dengan bola dan rantai yang diikatkan ke kaki Anda dan dengan penuh kemenangan berteriak bahwa Anda hampir berhasil meskipun Anda keluar dengan jaminan setelah mil pertama. dan bahwa ada program-program yang walaupun tidak bisa salah tidak dapat diperiksa jenisnya. Dorongan untuk membuat pengetikan statis menjadi kurang parsial dan lebih lengkap menyebabkan sistem tipe menjadi terlalu rumit dan eksotik seperti yang disaksikan oleh konsep seperti "tipe hantu" [11] dan "tipe goyah" [10]. Ini seperti mencoba lari maraton dengan bola dan rantai yang diikatkan ke kaki Anda dan dengan penuh kemenangan berteriak bahwa Anda hampir berhasil meskipun Anda keluar dengan jaminan setelah mil pertama. dan bahwa ada program-program yang walaupun tidak bisa salah tidak dapat diperiksa jenisnya. Dorongan untuk membuat pengetikan statis menjadi kurang parsial dan lebih lengkap menyebabkan sistem tipe menjadi terlalu rumit dan eksotik seperti yang disaksikan oleh konsep seperti "tipe hantu" [11] dan "tipe goyah" [10]. Ini seperti mencoba lari maraton dengan bola dan rantai yang diikatkan ke kaki Anda dan dengan penuh kemenangan berteriak bahwa Anda hampir berhasil meskipun Anda keluar dengan jaminan setelah mil pertama.

Pendukung bahasa yang diketik secara dinamis berpendapat bahwa pengetikan statis terlalu kaku, dan kelembutan bahasa yang dinamis membuat mereka cocok untuk membuat prototipe sistem dengan perubahan atau persyaratan yang tidak diketahui, atau yang berinteraksi dengan sistem lain yang berubah secara tak terduga (integrasi data dan aplikasi). Tentu saja, bahasa yang diketik secara dinamis sangat diperlukan untuk berurusan dengan perilaku program yang benar-benar dinamis seperti intersepsi metode, pemuatan dinamis, kode seluler, refleksi runtime, dll. Dalam induk semua makalah tentang skrip [16], John Ousterhout berpendapat bahwa sistem yang diketik secara statis bahasa pemrograman membuat kode kurang dapat digunakan kembali, lebih bertele-tele, tidak lebih aman, dan kurang ekspresif daripada bahasa scripting yang diketik secara dinamis. Argumen ini secara parroted oleh banyak pendukung bahasa scripting yang diketik secara dinamis. Kami berpendapat bahwa ini adalah kesalahan dan jatuh ke dalam kategori yang sama dengan berargumen bahwa esensi dari pemrograman deklaratif adalah menghilangkan tugas. Atau seperti yang dikatakan John Hughes [8], adalah mustahil secara logis untuk membuat bahasa lebih kuat dengan menghilangkan fitur. Mempertahankan fakta bahwa menunda semua pengecekan tipe untuk runtime adalah hal yang baik, memainkan taktik burung unta dengan fakta bahwa kesalahan harus ditangkap sedini mungkin dalam proses pengembangan. itu adalah ketidakmungkinan logis untuk membuat bahasa lebih kuat dengan menghilangkan fitur. Mempertahankan fakta bahwa menunda semua pengecekan tipe untuk runtime adalah hal yang baik, memainkan taktik burung unta dengan fakta bahwa kesalahan harus ditangkap sedini mungkin dalam proses pengembangan. itu adalah ketidakmungkinan logis untuk membuat bahasa lebih kuat dengan menghilangkan fitur. Mempertahankan fakta bahwa menunda semua pengecekan tipe untuk runtime adalah hal yang baik, memainkan taktik burung unta dengan fakta bahwa kesalahan harus ditangkap sedini mungkin dalam proses pengembangan.

Sistem tipe statis berupaya menghilangkan kesalahan tertentu secara statis, memeriksa program tanpa menjalankannya, dan berusaha membuktikan kesehatannya dalam beberapa hal. Beberapa jenis sistem dapat menangkap lebih banyak kesalahan daripada yang lain. Sebagai contoh, C # dapat menghilangkan pengecualian null pointer ketika digunakan dengan benar, sedangkan Java tidak memiliki kekuatan seperti itu. Twelf memiliki sistem tipe yang benar-benar menjamin bahwa bukti akan berakhir , "menyelesaikan" masalah yang terputus - putus .

Namun, tidak ada sistem tipe yang sempurna. Untuk mengeliminasi kelas kesalahan tertentu, mereka juga harus menolak program tertentu yang benar-benar valid yang melanggar aturan. Inilah sebabnya mengapa Twelf tidak benar-benar menyelesaikan masalah penghentian, itu hanya menghindarinya dengan membuang sejumlah besar bukti valid sempurna yang kebetulan berakhir dengan cara yang aneh. Demikian juga, sistem tipe Java menolak PersistentVectorimplementasi Clojure karena penggunaan array yang heterogen. Ini bekerja saat runtime, tetapi sistem tipe tidak dapat memverifikasinya.

Karena alasan itu, kebanyakan sistem tipe menyediakan "lolos", cara untuk menimpa pemeriksa statis. Untuk sebagian besar bahasa, ini mengambil bentuk casting, meskipun beberapa (seperti C # dan Haskell) memiliki seluruh mode yang ditandai sebagai "tidak aman".

Secara subyektif, saya suka mengetik statis. Diterapkan dengan benar (petunjuk: bukan Java), sistem tipe statis dapat sangat membantu dalam menghilangkan kesalahan sebelum mereka merusak sistem produksi. Bahasa yang diketik secara dinamis cenderung memerlukan lebih banyak pengujian unit, yang membosankan di saat terbaik. Juga, bahasa yang diketik secara statis dapat memiliki fitur tertentu yang tidak mungkin atau tidak aman dalam sistem tipe dinamis ( konversi implisit muncul dalam pikiran). Ini semua masalah persyaratan dan selera subjektif. Saya tidak akan lagi membangun Eclipse berikutnya di Ruby daripada saya akan mencoba untuk menulis skrip cadangan di Majelis atau menambal kernel menggunakan Java.

Oh, dan orang-orang yang mengatakan bahwa " x mengetik adalah 10 kali lebih produktif daripada y mengetik" hanya meniup asap. Mengetik dinamis mungkin "terasa" lebih cepat dalam banyak kasus, tetapi kehilangan kekuatan begitu Anda benar-benar mencoba untuk membuat aplikasi mewah Anda berjalan . Demikian juga, pengetikan statis mungkin tampak sebagai jaring pengaman yang sempurna, tetapi dengan melihat beberapa definisi tipe generik yang lebih rumit di Jawa membuat sebagian besar pengembang bergegas mencari penutup mata. Bahkan dengan sistem tipe dan produktivitas, tidak ada peluru perak.

Catatan akhir: jangan khawatir tentang kinerja saat membandingkan statis dengan pengetikan dinamis. JIT modern seperti V8 dan TraceMonkey semakin mendekati kinerja bahasa statis. Juga, fakta bahwa Java benar-benar mengkompilasi ke bahasa perantara yang secara inheren dinamis harus menjadi petunjuk bahwa untuk sebagian besar kasus, pengetikan dinamis bukanlah pembunuh kinerja besar yang dilakukan sebagian orang.

Yah, keduanya sangat, sangat sangat sangat disalahpahami dan juga dua hal yang sama sekali berbeda. yang tidak saling eksklusif .

Tipe statis adalah batasan tata bahasa. Bahasa yang diketik secara statis bisa dikatakan bebas konteks. Kebenaran yang sederhana adalah bahwa menjadi tidak nyaman untuk mengekspresikan bahasa secara waras dalam konteks tata bahasa gratis yang tidak memperlakukan semua datanya hanya sebagai vektor bit. Sistem tipe statis adalah bagian dari tata bahasa bahasa jika ada, mereka hanya membatasi itu lebih dari konteks tata bahasa bebas bisa, dengan demikian pemeriksaan tata bahasa terjadi dalam dua lintasan lebih dari sumbernya. Tipe statis sesuai dengan gagasan matematika tentang teori tipe, teori tipe dalam matematika hanya membatasi legalitas beberapa ekspresi. Seperti, saya tidak bisa mengatakan 3 + [4,7]dalam matematika, ini karena teori tipe itu.

Tipe statis dengan demikian bukan cara untuk 'mencegah kesalahan' dari perspektif teoritis, mereka adalah batasan tata bahasa. Memang, asalkan +, 3 dan interval memiliki definisi teoritis set yang biasa, jika kita menghapus tipe sistem 3 + [4,7]memiliki hasil yang didefinisikan dengan cukup baik itu adalah set. 'runtime type error' secara teoritis tidak ada, penggunaan praktis sistem tipe ini adalah untuk mencegah operasi yang bagi manusia tidak masuk akal. Operasi masih hanya pergeseran dan manipulasi bit saja.

Yang menarik dari hal ini adalah bahwa sistem tipe tidak dapat memutuskan apakah operasi seperti itu akan terjadi atau tidak apakah itu akan diizinkan untuk dijalankan. Seperti di, tepatnya mempartisi himpunan semua program yang mungkin pada mereka yang akan memiliki 'kesalahan ketik', dan yang tidak. Itu hanya dapat melakukan dua hal:

1: buktikan bahwa kesalahan tipe akan terjadi dalam suatu program
2: buktikan bahwa mereka tidak akan terjadi dalam suatu program

Ini mungkin terlihat seperti saya menentang diri saya sendiri. Tetapi apa yang dilakukan oleh pemeriksa tipe C atau Java adalah ia menolak sebuah program sebagai 'ungrammatical', atau seperti yang disebutnya 'type error' jika tidak dapat berhasil pada 2. Itu tidak dapat membuktikan mereka tidak akan terjadi, itu tidak berarti bahwa mereka tidak akan terjadi, itu hanya berarti tidak dapat membuktikannya. Mungkin saja suatu program yang tidak memiliki kesalahan ketik ditolak hanya karena tidak dapat dibuktikan oleh kompiler. Contoh sederhana adalahif(1) a = 3; else a = "string";, tentu saja karena selalu benar, cabang-lain tidak akan pernah dieksekusi dalam program, dan tidak akan terjadi kesalahan tipe. Tapi itu tidak bisa membuktikan kasus ini secara umum, jadi itu ditolak. Ini adalah kelemahan utama dari banyak bahasa yang diketik secara statis, dalam melindungi Anda dari diri Anda sendiri, Anda tentu juga dilindungi jika Anda tidak membutuhkannya.

Tetapi, bertentangan dengan kepercayaan umum, ada juga bahasa yang diketik secara statis yang bekerja berdasarkan prinsip 1. Mereka hanya menolak semua program yang mereka dapat membuktikannya akan menyebabkan kesalahan ketik, dan melewati semua program yang mereka tidak bisa. Jadi mungkin saja mereka memungkinkan program yang memiliki kesalahan ketik di dalamnya, contoh yang baik adalah Typed Racket, ini hibrida antara pengetikan dinamis dan statis. Dan beberapa orang akan berpendapat bahwa Anda mendapatkan yang terbaik dari kedua dunia dalam sistem ini.

Keuntungan lain dari pengetikan statis adalah bahwa tipe diketahui pada waktu kompilasi, dan dengan demikian kompiler dapat menggunakannya. Jika kita di Jawa melakukan "string" + "string"atau 3 + 3, kedua +token dalam teks pada akhirnya mewakili operasi dan datum yang sama sekali berbeda, kompiler tahu mana yang harus dipilih dari jenisnya saja.

Sekarang, saya akan membuat pernyataan yang sangat kontroversial di sini, tetapi ingatlah: 'pengetikan dinamis' tidak ada .

Suara yang sangat kontroversial, tapi itu benar, bahasa dinamis diketik adalah dari perspektif teoritis untyped . Mereka hanya bahasa yang diketik secara statis dengan hanya satu jenis. Atau sederhananya, mereka adalah bahasa yang memang secara tata bahasa dihasilkan oleh konteks tata bahasa gratis dalam praktiknya.

Mengapa mereka tidak memiliki tipe? Karena setiap operasi didefinisikan dan diizinkan pada setiap operan, apa sebenarnya 'kesalahan tipe runtime'? Ini dari contoh teoretis murni efek samping . Jika melakukan print("string")yang mencetak string adalah operasi, maka begitu juga length(3), yang pertama memiliki efek samping dari penulisan stringke output standar, yang terakhir hanya error: function 'length' expects array as argument., itu saja. Dari sudut pandang teoretis tidak ada bahasa yang diketik secara dinamis. Mereka tidak diketik

Baiklah, keuntungan nyata dari bahasa 'yang diketik secara dinamis' adalah kekuatan ekspresif, sistem tipe tidak lain adalah batasan kekuatan ekspresif. Dan secara umum, bahasa dengan sistem tipe memang akan memiliki hasil yang pasti untuk semua operasi yang tidak diizinkan jika sistem tipe hanya diabaikan, hasilnya tidak akan masuk akal bagi manusia. Banyak bahasa kehilangan kelengkapan Turing mereka setelah menerapkan sistem tipe.

Kerugian yang jelas adalah kenyataan bahwa operasi dapat terjadi yang akan menghasilkan hasil yang tidak masuk akal bagi manusia. Untuk mencegah hal ini, bahasa yang diketik secara dinamis biasanya mendefinisikan ulang operasi-operasi itu, daripada menghasilkan hasil yang tidak masuk akal itu mereka mendefinisikannya kembali untuk memiliki efek samping dari menulis kesalahan, dan mungkin menghentikan program sama sekali. Ini bukan 'kesalahan' sama sekali, pada kenyataannya, spesifikasi bahasa biasanya menyiratkan ini, ini adalah perilaku bahasa sebanyak mencetak string dari perspektif teoritis. Ketik sistem dengan demikian memaksa pemrogram untuk alasan tentang aliran kode untuk memastikan bahwa ini tidak terjadi. Atau memang, alasan sehingga tidakterjadi juga bisa berguna di beberapa titik untuk debugging, menunjukkan bahwa itu sama sekali bukan 'kesalahan' tetapi properti bahasa yang didefinisikan dengan baik. Akibatnya, satu-satunya sisa 'pengetikan dinamis' yang dimiliki sebagian besar bahasa adalah menjaga terhadap pembagian dengan nol. Inilah yang dimaksud dengan pengetikan dinamis, tidak ada tipe, tidak ada tipe lebih dari nol adalah tipe yang berbeda dari semua angka lainnya. Apa yang orang sebut 'tipe' hanyalah properti lain dari datum, seperti panjang array, atau karakter pertama string. Dan banyak bahasa yang diketik secara dinamis juga memungkinkan Anda untuk menulis hal-hal seperti "error: the first character of this string should be a 'z'".

Hal lain adalah bahwa bahasa yang diketik secara dinamis memiliki tipe yang tersedia saat runtime dan biasanya dapat memeriksa dan mengatasinya serta memutuskan darinya. Tentu saja, secara teori itu tidak berbeda dengan mengakses karakter pertama dari array dan melihat apa itu. Bahkan, Anda dapat membuat C dinamis Anda sendiri, cukup gunakan hanya satu jenis seperti long panjang int dan gunakan 8 bit pertama untuk menyimpan 'tipe' Anda dan tulis fungsi yang sesuai yang memeriksa dan melakukan penambahan float atau integer. Anda memiliki bahasa yang diketik secara statis dengan satu jenis, atau bahasa yang dinamis.

Dalam praktiknya semua ini menunjukkan, bahasa yang diketik secara statis umumnya digunakan dalam konteks penulisan perangkat lunak komersial, sedangkan bahasa yang diketik secara dinamis cenderung digunakan dalam konteks memecahkan beberapa masalah dan mengotomatisasi beberapa tugas. Menulis kode dalam bahasa yang diketik secara statis hanya memakan waktu lama dan rumit karena Anda tidak dapat melakukan hal-hal yang Anda tahu akan baik-baik saja tetapi sistem tipe masih melindungi Anda dari kesalahan yang tidak Anda lakukan. Banyak coders bahkan tidak menyadari bahwa mereka melakukan ini karena itu ada di sistem mereka tetapi ketika Anda membuat kode dalam bahasa statis, Anda sering mengatasi kenyataan bahwa sistem tipe tidak akan membiarkan Anda melakukan hal-hal yang tidak dapat salah, karena itu tidak dapat membuktikan bahwa itu tidak akan salah.

Seperti yang saya perhatikan, 'diketik secara statis' secara umum berarti kasus 2, bersalah sampai terbukti tidak bersalah. Tetapi beberapa bahasa, yang tidak mendapatkan sistem tipenya dari teori tipe sama sekali menggunakan aturan 1: Innocent sampai terbukti bersalah, yang mungkin merupakan hibrida ideal. Jadi, mungkin Typed Racket adalah untuk Anda.

Juga, well, untuk contoh yang lebih absurd dan ekstrem, saya saat ini menerapkan bahasa di mana 'tipe' benar-benar karakter pertama dari array, mereka adalah data, data dari 'tipe', 'tipe', yang merupakan dirinya sendiri. tipe dan datum, satu-satunya datum yang memiliki dirinya sebagai tipe. Tipe tidak terbatas atau dibatasi secara statis tetapi tipe baru dapat dihasilkan berdasarkan informasi runtime.

Mungkin "manfaat" tunggal terbesar dari pengetikan dinamis adalah kurva pembelajaran yang lebih dangkal. Tidak ada sistem tipe untuk dipelajari dan tidak ada sintaksis non-sepele untuk kasus sudut seperti batasan tipe. Hal itu membuat pengetikan dinamis dapat diakses oleh lebih banyak orang dan layak bagi banyak orang yang tidak terjangkau oleh sistem tipe statis. Akibatnya, pengetikan dinamis telah menarik dalam konteks pendidikan (misalnya Skema / Python di MIT) dan bahasa khusus domain untuk non-programer (misalnya Mathematica ). Bahasa-bahasa yang dinamis juga tertangkap di ceruk-ceruk di mana mereka memiliki sedikit atau tidak ada persaingan (misalnya Javascript).

Bahasa yang diketik secara dinamis paling ringkas (mis. Perl, APL, J, K, Mathematica ) adalah spesifik domain dan dapat secara signifikan lebih ringkas daripada bahasa yang diketik secara umum untuk tujuan statis yang paling singkat (mis. OCaml ) di ceruk tempat mereka dirancang untuk .

Kerugian utama dari pengetikan dinamis adalah:

• Jenis kesalahan run-time.

• Bisa sangat sulit atau bahkan secara praktis tidak mungkin untuk mencapai tingkat kebenaran yang sama dan membutuhkan pengujian yang jauh lebih banyak.

• Tidak ada dokumentasi yang diverifikasi oleh kompiler.

• Kinerja buruk (biasanya pada saat run-time tetapi kadang-kadang pada waktu kompilasi sebagai gantinya, misalnya Skema Stalin) dan kinerja yang tidak dapat diprediksi karena bergantung pada optimisasi canggih.

Secara pribadi, saya dibesarkan dalam bahasa yang dinamis tetapi tidak akan menyentuh mereka dengan tiang 40 'sebagai profesional kecuali tidak ada pilihan lain yang layak.

Dari Artima's Typing: Strong vs Weak, Static vs Dynamic article:

pengetikan yang kuat mencegah operasi pencampuran antara tipe yang tidak cocok. Untuk mencampur jenis, Anda harus menggunakan konversi eksplisit

pengetikan lemah berarti Anda dapat mencampur jenis tanpa konversi eksplisit

Dalam makalah Pascal Costanza, Pengetikan Dinamis vs Statis - Analisis Berbasis Pola (PDF), ia mengklaim bahwa dalam beberapa kasus, pengetikan statis lebih rentan kesalahan daripada pengetikan dinamis. Beberapa bahasa yang diketik secara statis memaksa Anda untuk meniru secara manual pengetikan dinamis untuk melakukan "Hal yang Benar". Ini dibahas di Lambda the Ultimate .

Itu tergantung pada konteksnya. Ada banyak manfaat yang sesuai untuk sistem mengetik dinamis serta untuk mengetik kuat. Saya berpendapat bahwa aliran bahasa jenis dinamis lebih cepat. Bahasa dinamis tidak dibatasi dengan atribut kelas dan pemikiran kompilator tentang apa yang terjadi dalam kode. Anda memiliki sedikit kebebasan. Selain itu, bahasa dinamis biasanya lebih ekspresif dan menghasilkan lebih sedikit kode yang baik. Meskipun demikian, ini lebih rawan kesalahan yang juga dipertanyakan dan lebih tergantung pada penutup unit test. Ini prototipe mudah dengan bahasa dinamis tetapi pemeliharaan dapat menjadi mimpi buruk.

Keuntungan utama dari sistem yang diketik statis adalah dukungan IDE dan tentunya penganalisa kode statis. Anda menjadi lebih percaya diri terhadap kode setelah setiap perubahan kode. Pemeliharaannya tenang dengan alat-alat seperti itu.

Ada banyak hal berbeda tentang bahasa statis dan dinamis. Bagi saya, perbedaan utama adalah bahwa dalam bahasa dinamis variabel tidak memiliki tipe tetap; sebagai gantinya, tipe terkait dengan nilai. Karena itu, kode pasti yang dijalankan tidak ditentukan hingga runtime.

Pada implementasi awal atau naif ini adalah hambatan kinerja yang sangat besar, tetapi JIT modern mendekati dengan yang terbaik yang bisa Anda dapatkan dengan mengoptimalkan kompiler statis. (dalam beberapa kasus pinggiran, bahkan lebih baik dari itu).

Ini semua tentang alat yang tepat untuk pekerjaan itu. Tidak ada yang lebih baik 100% dari waktu. Kedua sistem diciptakan oleh manusia dan memiliki kekurangan. Maaf, tapi kami payah dan membuat barang yang sempurna.

Saya suka pengetikan dinamis karena itu keluar dari jalan saya, tapi ya kesalahan runtime dapat muncul yang tidak saya rencanakan. Sedangkan pengetikan statis dapat memperbaiki kesalahan yang disebutkan di atas, tetapi menggerakkan programmer pemula (dalam bahasa yang diketik) gila mencoba untuk melemparkan antara char konstan dan string.

Pengetikan Statis: Bahasa seperti Java dan Scala diketik secara statis.

Variabel harus didefinisikan dan diinisialisasi sebelum digunakan dalam kode.

misalnya int x; x = 10;

System.out.println (x);

Pengetikan Dinamis: Perl adalah bahasa pengetik dinamis.

Variabel tidak perlu diinisialisasi sebelum digunakan dalam kode.

y = 10; gunakan variabel ini di bagian akhir kode