Dapatkah bahasa yang diketik secara statis dan dinamis dilihat sebagai alat yang berbeda untuk jenis pekerjaan yang berbeda?

9

Ya, pertanyaan serupa telah diajukan tetapi selalu dengan tujuan mencari tahu 'mana yang lebih baik.'

Saya bertanya karena saya muncul sebagai dev terutama dalam JavaScript dan tidak benar-benar memiliki pengalaman menulis dalam bahasa yang diketik secara statis.

Terlepas dari ini, saya pasti melihat nilai dalam belajar C untuk menangani operasi yang menuntut pada tingkat kode yang lebih rendah (yang saya asumsikan memiliki banyak kaitan dengan statis vs dinamis pada tingkat kompiler), tetapi apa yang saya coba untuk membungkus kepala saya sekitar apakah ada konteks proyek tertentu (mungkin jenis operasi dinamis data intensif tertentu?) yang melibatkan hal-hal selain kinerja di mana lebih masuk akal untuk menggunakan Java atau C # vs. sesuatu seperti Python.

dynamic-typing static-typing Erik Reppen
sumber
5
Jawabannya iya". Setiap jenis bahasa - bahkan masing-masing bahasa - memiliki kekuatan dan kelemahannya sehingga lebih cocok untuk beberapa tugas daripada yang lain.
ChrisF
Sangat menarik bahwa Anda menggunakan C sebagai contoh, karena ini adalah jenis bahasa yang diketik paling lemah yang dapat Anda buat dan masih menyebutnya dengan mengetik secara statis. C tidak cepat karena sistem tipe, pemeriksaan tipe terjadi pada waktu kompilasi. C cepat karena ada sedikit atau tidak ada langkah-langkah keamanan dan pemeriksaan untuk mencegah Anda menembak diri sendiri. dan karena itu dikompilasi ke binari asli.
sara

Jawaban:

10

Iya tentu saja.
Pengetikan dinamis memiliki keunggulan yang pasti dalam kasus di mana Anda ingin dapat memperlakukan semuanya sebagai satu jenis tunggal. Serialisasi / deserialisasi adalah salah satu contoh klasik. Inilah sebabnya mengapa begitu banyak pemrograman Web dilakukan dalam bahasa scripting yang diketik secara dinamis: mereka sangat cocok untuk tugas yang melibatkan banyak konversi semua jenis data ke dan dari string.

Untuk pemrograman aplikasi, di sisi lain, bahasa statis bekerja jauh lebih baik karena mencoba memperlakukan segala sesuatu sebagai satu jenis tunggal tidak sering menjadi persyaratan. Anda sering ingin memiliki struktur data yang efisien dengan data direpresentasikan sebagai dirinya sendiri dan tidak sering dikonversi ke tipe lain. Ini membuat fitur pengetikan dinamis menjadi kelemahan alih-alih manfaat, itulah sebabnya aplikasi hampir secara eksklusif ditulis dalam bahasa yang diketik secara statis.

Mason Wheeler
sumber
3
@Erik: Saya tidak yakin saya akan mengatakan itu. Banyak hal berubah selama pengembangan. Persyaratan dapat berubah, atau Anda menemukan bahwa Anda tidak menerapkan persyaratan dengan benar, dan kode perlu diperbarui. Mampu mengubah satu hal dan menggunakan kesalahan kompiler yang dihasilkan untuk menunjukkan kepada Anda di mana menemukan hal lain yang perlu diubah memberikan dorongan besar untuk kenyamanan dan kecepatan pengembangan yang Anda kehilangan dalam bahasa di mana teknik itu tidak tersedia. Itulah salah satu alasan mengapa Anda tidak melihat aplikasi rumit yang dikembangkan dalam bahasa dinamis.
Mason Wheeler
9
@Mason Wheeler: Jawaban yang sangat bagus. +1 Saya akan menambahkan bahwa pengecekan tipe statis juga membantu menemukan bug lebih awal dengan meminta kebenaran jenis pemeriksaan kompiler. Misalnya saya men-debug program Ruby 200-line kemarin dan ada dua bug yang terkait dengan tipe yang hanya bisa saya deteksi dengan menjalankan program. Saya tidak ingin memikirkan apa yang terjadi dalam proyek 100000-line. Pengetikan dinamis memberi Anda lebih banyak fleksibilitas, yang bagus dalam konteks yang telah Anda jelaskan, dengan harga yang Anda tidak dapat menemukan bug tertentu pada waktu kompilasi. Jadi mengetik secara statis tidak hanya terkait dengan efisiensi, tetapi juga untuk kebenaran.
Giorgio
1
@MasonWheeler Dua tahun dan lebih banyak C # dan Java daripada yang saya tawar kemudian saya tidak akan setuju dengan beberapa hal. Aplikasi web yang rumit dilakukan sepenuhnya dengan bahasa yang dinamis. Kompilasi vs waktu berjalan tidak ada artinya ketika Anda dapat membuat perubahan yang langsung terlihat. Dan saya telah mengembangkan pendapat bahwa semua jenis rewel lebih masuk akal dalam bahasa prosedural daripada dalam bahasa yang seharusnya didorong oleh OOP di mana data tidak boleh berpindah tangan secara konstan.
Erik Reppen
1
@Erik: * meringis * Pertama, menilai pengetikan statis sebagai konsep oleh Java sama seperti menilai mobil sebagai konsep oleh Pinto. Dan kedua, apa pun di mana perubahan dapat "segera terlihat" adalah, menurut definisi, bukan program yang sangat kompleks, karena bahkan dengan perangkat keras modern, program kompleks membutuhkan cukup banyak waktu untuk menyiapkan kode, apakah itu kompiler atau juru bahasa ( atau kompiler JIT) melakukan persiapan. Bahkan aplikasi web yang paling mengesankan cenderung merupakan program yang sangat sederhana yang didukung oleh database yang sangat kompleks, yang merupakan masalah yang sangat berbeda.
Mason Wheeler
1
Kemampuan untuk membuat abstraksi yang kompleks adalah ortogonal untuk memiliki sistem tipe statis vs dinamis, dan juga ortogonal terhadap kecepatan. Ada sistem tipe statis di luar sana yang memungkinkan untuk abstraksi yang sangat kuat (meskipun kadang-kadang misterius). Memiliki perubahan yang muncul secara instan juga tidak tergantung pada sistem tipe: Anda tentu dapat membangun penerjemah untuk bahasa yang diketik secara statis.
Rufflewind
4

Cara saya melihatnya adalah, jika Anda dapat bekerja secara alami dalam bahasa yang diketik secara statis, maka mengetik statis adalah cara yang harus dilakukan. Secara umum, tujuan dari sistem tipe adalah untuk mencegah Anda melakukan operasi dengan semantik yang tidak ditentukan - seperti (string) "hello" + (bool) true. Memiliki tingkat keamanan ekstra yang mencegah Anda melakukan operasi ini dapat menjadi cara yang baik untuk mencegah bug dalam kode Anda, bahkan tanpa tes unit yang ekstensif. Yaitu, tipe-safety memberikan tingkat kepercayaan lain pada kebenaran semantik dari kode Anda.

Tetapi sistem tipe sangat sulit untuk diperbaiki. Saya tidak percaya ada adalah sistem jenis yang sempurna di alam pada saat penulisan ini. (Dengan "sistem tipe sempurna", maksud saya sistem tipe ketat, yang tidak memerlukan anotasi kode verbose, yang tidak menghasilkan kesalahan tipe positif palsu, dan kesalahan jenisnya mudah dipahami oleh pemrogram.) Selanjutnya, dapat sulit untuk memahami sistem tipe yang benar-benar baik yang ada. Ketika saya belajar Haskell, saya tidak bisa memberi tahu Anda jumlah kesalahan jenis tidak jelas yang saya dapatkan ketika mencoba untuk menulis apa yang tampak (bagi saya) seperti kode yang benar. Biasanya kode itu sebenarnya tidak benar (yang merupakan titik yang mendukung sistem tipe), tetapi butuh banyakpekerjaan untuk memahami pesan kesalahan dari kompiler, sehingga saya bisa memperbaiki masalah yang mendasarinya. Dalam bahasa OO, Anda mungkin akhirnya berpikir "argumen ini harus bertentangan dengan tipe input, bukan kovarian!", Atau (lebih mungkin) kembali ke typecast untuk melarikan diri dari batasan sistem tipe. Sistem tipe bisa menjadi jauh lebih rumit daripada yang Anda pikirkan.

Untuk apa nilainya, menurut pemahaman saya bahwa kesulitan dalam menghasilkan sistem tipe yang baik adalah bagian dari apa yang memotivasi Gilad Bracha untuk memasukkan dukungan sistem tipe pluggable di Newspeak.

Aidan Cully
sumber
Tes unit WRT, saya sepenuhnya setuju. Anda selalu melihat orang mengatakan "jika Anda memiliki unit test yang baik, mereka dapat memverifikasi ketepatan jenis untuk Anda." Itu selalu mengingatkan saya tentang bagaimana Paul Graham (yang sangat percaya bahwa pengetikan dinamis selalu merupakan hal yang baik) mengatakan bahwa bahasa membuat Anda melakukan pekerjaan kompiler secara manual karena itu adalah bahasa yang cacat. Sorta membuat Anda berhenti dan berpikir ...
Mason Wheeler
Saya pikir banyak kekhawatiran tentang 'bahaya' dari bahasa yang diketik secara dinamis gagal memperhitungkan bagaimana kita menulis hal ini. Banyak Python dan JS dapat ditulis bergaya konsol. Kompilasi sekrup vs run-time, saya dapat mencobanya sekarang dan melihat apa yang terjadi. Saya pikir Anda berada pada satu poin yang sangat bagus. Tidak ada yang membuat saya lebih gila dalam pengembangan web sisi-klien daripada ketika semua vendor browser yang dianggap baik memberikan kode membingungkan yang membingungkan sementara IE6 atau 7 melakukan hal yang tidak terduga, yaitu membuang-buang waktu yang seharusnya bukan hanya, yah ... mengisap dengan cara yang lebih khas.
Erik Reppen
@ tipe ketidakcocokan mason-wheeler adalah kesalahan trival, dan itu bukan bahasa yang dinamis tidak memeriksa jenis, itu hanya saat runtime. Saya pengalaman saya bahasa yang paling statis memiliki tingkat cakupan yang sama dari tes unit, mereka tidak kehilangan tes dari memiliki kompiler memeriksa jenis yang ada sebelumnya, dan bahasa yang dinamis tidak harus menambahkan tes khusus untuk memeriksa jenis , sistem runtime memeriksa tipe Anda, jika pengujian unit Anda mencakup metode Anda, ia akan menangkapnya.
jbtule
4

Mereka adalah alat yang berbeda, tetapi tidak berdasarkan kinerja. Ini semua tentang kompleksitas .

Bahasa dinamis biasanya bertujuan fleksibilitas maksimum, dan itu membawa kurang validasi dan semacam jaminan. Kemudian, ini sangat kuat dalam program skala kecil, tetapi menjadi hampir tidak mungkin untuk mempertahankan program skala besar (kompleksitas).

Bahasa statis biasanya bertujuan validasi maksimum. Tujuan pertama mereka biasanya menangkap kesalahan (atau bug) sedini mungkin. Banyak jaminan dibuat untuk validasi. Maka lebih sulit untuk belajar dan memulai, tetapi ketika program semakin besar, ini memberikan validasi program yang lebih baik dengan biaya yang jauh lebih rendah (upaya pengkodean).

Akibatnya, bahasa dinamis biasanya cocok untuk program kecil (maksud saya sangat kecil) seperti halaman web dinamis, DSL browser web (bukan untuk aplikasi browser!) Atau skrip shell. Bahasa statis lebih cocok untuk program sistem atau hal lainnya.

Deskripsi di atas adalah sesuatu tentang bahasa yang sangat murni dinamis atau statis. Sebagian besar bahasa kehidupan nyata ada di antaranya, dan menunjukkan berbagai karakteristik.

Lihat di sini untuk detail lebih lanjut: https://softwareengineering.stackexchange.com/a/105417/17428

Eonil
sumber
1
"bahasa dinamis biasanya cocok untuk program kecil (maksud saya sangat kecil)": Dalam pengalaman saya, Anda dapat menggunakan bahasa dinamis juga untuk aplikasi berukuran sedang (dan, tentu saja, ada orang yang menggunakannya dengan sukses untuk aplikasi besar). Saya setuju bahwa semakin besar basis kode, semakin banyak Anda dapat untung dari pemeriksaan statis yang disediakan oleh bahasa statis.
Giorgio
2
@Iorgio Yah, itu mungkin karena saya kecanduan barang validasi statis. Ini sangat manis bagi saya, dan saya benar-benar tidak dapat hidup tanpanya bahkan dalam skala kecil: p
Eonil
Saya melihat kelebihan dari bahasa statis (dan saya telah meningkatkan jawaban Anda). Baru-baru ini saya telah menggunakan Python dan Common Lisp dan saya mengakui bahwa dalam praktiknya Anda mendapatkan hasil yang baik jika Anda menggunakan desain yang bersih dan, terutama dalam Python, jika Anda menulis tes yang cukup. Bahasa-bahasa ini bisa sangat efektif untuk membangun prototipe yang kemudian dapat dengan mudah diubah menjadi kode produksi Anda. Tapi, ya, untuk proyek yang lebih kompleks, saya ingin mendapat bantuan sebanyak mungkin, jadi saya lebih suka bahasa statis.
Giorgio
1

Saat ini saya memprogram dalam bahasa jenis statis (C # dan F #), tetapi saya menikmati pemrograman dalam bahasa dinamis (Smalltalk, Ruby). Ada banyak pro dan kontra yang diasosiasikan orang dengan satu jenis vs jenis lain yang lebih banyak tentang bahasa daripada saat Anda menerapkan jenis. Sebagai contoh, bahasa dinamis biasanya memiliki sintaksis yang lebih bersih dan lebih ringkas, namun F # dan OCaml dengan sistem inferensi tipenya memiliki sintaks sebersih bahasa dinamis apa pun. Dan dengan pengetikan statis, Anda memiliki refactor otomatis nyata dan autocomplete, tetapi Smalltalk, dengan seluruh kode sumbernya dalam database dan setiap metode dikompilasi secara terpisah, adalah bahasa pertama yang benar-benar memiliki refactoring otomatis yang serius, dan itu bekerja dengan baik. Pada akhirnya, bahasa modern yang dinamis dan statis saat ini adalah tipe aman, yang merupakan aspek paling penting dari sistem tipe Anda,

jbtule
sumber
Kadang-kadang saya curiga bahwa pengetikan statis hanya sebagian kecil dari persamaan yang membuat bahasa menjadi lebih atau kurang fleksibel. Saya pikir apa yang saya juga mulai sadari adalah bahwa banyak devs lebih suka seperangkat rel yang nyaman untuk membimbing mereka daripada memiliki pemerintahan bebas untuk melakukan hal-hal berbahaya yang tidak masuk akal seperti operator yang kelebihan muatan. VS membuat saya ingin menendang anak-anak anjing kadang-kadang tetapi saya pasti ingin tahu tentang F # dan apa yang Anda katakan tentang hal itu membuat saya semakin penasaran. Saya berasumsi ini adalah sesuatu yang lebih dari sekedar hal C # di mana Anda dapat menggunakan tipe yang lebih inklusif secara implisit.
Erik Reppen
@ erik, Oh ya lebih dari mengetik secara implisit dan var: F # Ketik inferensi
jbtule
-1

Sekarang tahun 2015, yang menambahkan beberapa cuplikan menarik ke percakapan:

  1. Bagian signifikan dari dunia backend perusahaan sedang mempertimbangkan atau mulai menggunakan Python (dinamis) sebagai pengganti Jawa (statis ketat)
  2. Dunia frontend perusahaan melihat hal-hal seperti AngularJS v2, berdasarkan pada TypeScipt: ekstensi yang diketik dari Javascript.

Jadi para backend bosan dengan jaket lurus pengetikan yang tidak perlu, sementara frontend bosan dengan kekacauan pengetikan dinamis.

Cukup ironis: Saya ingin tahu apakah mereka akan bertemu di tengah, atau bergegas melewati satu sama lain dengan ledakan sonik dari tenggat waktu yang berlalu ...? ;)

Cornel Masson
sumber
Kecuali jika Anda memberikan bukti, saya akan mengklaim bahwa dalam kasus terburuk dunia backend beralih ke Go, tetapi Tuhan melarang segala sesuatu yang dinamis tentang naskah. Mitos bahwa bahasa pemrograman statis selalu memiliki banyak upacara telah lama dibantah dengan sistem inferensi yang lebih kuat dan implementasi REPL yang solid
Den
Ada banyak ujung belakang yang diketik secara dinamis digunakan pada skala besar. Django khususnya sangat populer dalam jurnalisme dan menjalankan ujung belakang untuk NYT, Guardian, dan Washington Post. Walmart berjalan di Node. Satu-satunya mitos adalah gagasan bahwa Anda tidak dapat menulis untuk skala tanpa tipe statis. Dan setelah menghabiskan beberapa waktu memikirkan beberapa bencana basis kode Java legacy yang saya temui, saya pikir orang-orang yang merasa nyaman melakukannya lebih baik untuk itu apakah mereka bekerja dengan statis atau dinamis.
Erik Reppen
Memang, saya lebih suka memiliki tim Python yang terampil pada proyek perusahaan besar saya, daripada yang Jawa miskin. Hanya untuk memperjelas posisi saya: Saya memposting jawaban di atas sebagai penilaian
Cornel Masson
Memang, saya lebih suka memiliki tim Python yang terampil pada proyek perusahaan besar saya, daripada yang buruk di Jawa. Hanya untuk mengklarifikasi: Saya memposting jawaban di atas sebagai pengamatan pada tren yang saya lihat di basis klien saya, jaringan industri dan penelitian umum. Backend yang ketat secara tradisional mencakup kurang ketat, frontend tradisional lebih longgar, lebih. Bahkan bukan pendapat yang "benar" (jika ada) - tidak yakin mengapa saya downvoted. Mungkin ironi itu hilang ...
Cornel Masson