Perbedaan arsitektur antara bahasa dinamis dan statis


22

Apakah ada perbedaan arsitektur utama ketika merancang aplikasi yang akan dibangun pada bahasa statis (seperti C # atau Java) dan bahasa dinamis (seperti Ruby atau Python)?

Apa saja kemungkinan desain yang mungkin menjadi pilihan yang baik untuk satu jenis yang buruk untuk yang lain? Adakah fitur berguna yang dapat dicapai dengan satu jenis yang tidak sama dengan yang lain (dalam desain dan arsitektur, tentu saja)?

Juga, apakah ada pola desain khusus dinamis?


1
Apa pun perbedaan arsitekturalnya, bahasa dinamis - IronRuby dan IronPython - dengan mudah memuji bahasa statis .Net.
IAbstract

3
Saya tidak yakin, tetapi jika metaprogramming lebih mudah dalam bahasa yang dinamis (itu jelas terlihat lebih mudah di Ruby daripada Jawa, terakhir kali saya melihat), yang mungkin memiliki pengaruh pada keputusan arsitektur. Saya tidak yakin pengaruh macam apa karena saya tidak pernah benar-benar mengerjakan sesuatu yang sebesar ini dalam bahasa yang dinamis ini.
FrustratedWithFormsDesigner

Jawaban:


14

Mari kita luruskan beberapa hal:

  1. Scripting interaktif dan bahasa statis tidak saling eksklusif. F # dan Haskell keduanya memiliki antarmuka REPL.
  2. Bahasa yang dinamis dan kinerja tinggi tidak eksklusif satu sama lain, meskipun ada beberapa optimasi. JavaScript berjalan sangat cepat di sebagian besar browser saat ini.
  3. Bahkan dalam bahasa yang dinamis, Anda masih perlu mendokumentasikan, mengingat, dan memikirkan jenis.
  4. Karena semakin populernya inferensi jenis, banyak bahasa statis tidak perlu terlalu sering mencatat jenis. Dalam bahasa statis dengan inferensi tipe yang kuat, kompiler mengetahui apa tipe dari kode Anda sehingga sebagian besar waktu, dan memberi tahu Anda jika Anda pernah melakukan sesuatu yang melanggar definisi tipe. Sejauh menyangkut sintaksis, ini memberikan yang terbaik dari kedua dunia.
  5. OOP dan bahasa dinamis tidak saling eksklusif. PHP sekarang mendukung kelas dan bahkan warisan.

Selain semua kesamaan yang mengejutkan itu, ada beberapa perbedaan praktis yang mempengaruhi proses pengembangan:

  1. Bahasa dinamis memungkinkan cara-cara menarik untuk menyampaikan data di dalam ruang kecil .
  2. Bahasa statis memungkinkan Anda mengurangi jumlah pengujian yang harus Anda lakukan dengan membuat banyak jenis bug menjadi tidak mungkin.
  3. Dalam nada yang sama, bahasa statis memungkinkan validasi yang menarik dan fitur konversi otomatis, seperti satuan ukuran dalam F # .
  4. Dibawa ke ekstrim, bahasa statis memungkinkan untuk kontrak kode dan verifikasi formal, yang dapat mendokumentasikan dan menyamakan mencegah hal-hal seperti potensi pembagian-oleh-nol, loop tak terbatas, referensi nol, ukuran atau indeks daftar tidak valid, kesalahan rentang dan keadaan logis lainnya tidak valid Anda mungkin mendefinisikan.
  5. Mengambil ekstrim itu lebih jauh, optimasi CPU dapat dibuat berdasarkan kendala statis ini, yang menghasilkan kinerja yang lebih baik.

Ada juga satu jenis program yang tidak akan pernah bisa dibuat tanpa pengetikan statis: Singularity , sebuah OS tanpa batas proses perangkat keras. Itu ditulis dalam sejumlah kecil C, beberapa C #, dan dialek dari C # disebut Spec #, yang mendukung kontrak kode.

Meskipun ditulis dalam bahasa yang dikumpulkan dari sampah, kinerja multitasking dan komunikasi antar proses pada OS ini sebenarnya lebih baik daripada yang lain di luar sana, karena semua proses berjalan dalam satu ruang memori, dan karena optimalisasi verifikasi formal, saya disebutkan di atas. Anda tidak dapat melakukan ini tanpa mengetik statis, karena agar program tidak dapat kompromi dengan sisa sistem, objek komunikasi perlu diverifikasi secara statis.

Namun, sebagian besar waktu, arsitektur harus terlihat sangat sama. Bahasa statis dapat membuat program lebih mudah untuk dipertimbangkan dalam banyak kasus karena jenisnya terdefinisi dengan baik, tetapi program bahasa dinamis yang ditulis dengan baik juga akan memiliki jenis yang, paling tidak, terdefinisi dengan baik dalam pikiran pengembang.


Dapatkah Singularity memberikan jaminan latensi maksimum yang sadar-waktu?
Eonil

@Eonil Tidak benar-benar bidang saya, tapi saya pikir Anda bertanya apakah itu bisa dilakukan secara real-time Saya rasa tidak, karena menggunakan pengumpulan sampah di semua tempat. Singularity belum diperbarui untuk sementara waktu sejauh yang saya tahu, tapi mungkin seseorang telah membuat sesuatu yang mirip dengan pengumpul sampah real-time.
Rei Miyasaka

Terima kasih. Saya hanya ingin memeriksa. Saya telah mendengar ada beberapa implementasi GC waktu nyata, tetapi saya belum pernah mendengar bagaimana mereka digunakan secara praktis dalam industri ini ...
Eonil

2

Ada perbedaan arsitektur yang signifikan. Performa.

Bergantung pada anggaran perangkat keras Anda, beban kerja yang diharapkan, dan perjanjian tingkat layanan, mungkin tidak mungkin memenuhi persyaratan dengan bahasa yang dinamis.

Paling sering kecepatan pengembangan dan fleksibilitas yang diberikan oleh bahasa dinamis mengimbangi waktu respons yang lebih lambat dengan konsumsi CPU dan memori yang lebih tinggi. Tetapi untuk sistem yang lebih besar dengan kendala anggaran atau kinerja, overhead bahasa yang dinamis dapat menjadi tinggi.


1

Saya tidak pernah berpikir seperti ini. Jadi ketika melakukan Google, blog Peter Norvig adalah salah satu hit teratas. Dikatakan beberapa pola desain lebih mudah diimplementasikan dalam bahasa dinamis daripada bahasa berorientasi objek tradisional seperti C ++. Saya pikir harus ada perbedaan pada desain / arsitektur juga karena ia mencatat bahwa implementasi lebih mudah dalam bahasa yang dinamis. Saya akan mencoba menambahkan lebih banyak ke jawabannya ketika saya belajar lebih lanjut.


1

Apakah ada perbedaan arsitektur utama ketika merancang aplikasi yang akan dibangun pada bahasa statis (seperti C # atau Java) dan bahasa dinamis (seperti Ruby atau Python)?

Tidak.

Sedikit lebih mudah untuk menulis kerangka kerja mewah untuk bahasa dinamis. Tapi itu bukan hal aplikasi.

Apa saja kemungkinan desain yang mungkin menjadi pilihan yang baik untuk satu jenis yang buruk untuk yang lain?

Tidak ada, sungguh.

Anda dapat menulis hal-hal baik dalam bahasa apa pun.

Adakah fitur berguna yang dapat dicapai dengan satu jenis yang tidak sama dengan yang lain (dalam desain dan arsitektur, tentu saja)?

Tidak.

Perbedaannya adalah bahwa bahasa dinamis adalah "tulis, jalankan, perbaiki". Anda dapat bereksperimen dan memperbaiki dengan cepat.

Bahasa statis adalah "tulis, kompilasi, bangun, jalankan, perbaiki". Anda tidak dapat bereksperimen dengan mudah.

Selain itu, kemampuan mereka hampir identik.

Apakah ada pola desain spesifik dinamis?

Mungkin. Python eval()dan execfile()fungsinya - dengan cara - menunjukkan fitur bahasa dinamis yang sulit (tapi jauh dari mustahil) untuk ditangani dalam bahasa statis. Akan lebih banyak baris kode untuk mengkompilasi dan mengeksekusi kode dalam ruang proses yang sama.

Ini tidak spesifik bahasa dinamis. Itu lebih mudah.


2
"Anda tidak dapat bereksperimen dengan mudah." - Benar, pengorbanannya adalah bahwa kompiler membantu Anda menemukan kesalahan sedangkan dengan bahasa yang ditafsirkan Anda mungkin tidak menemukan kesalahan sampai pengguna mengeksekusi baris kode itu.
Doug T.

4
@ Doug T .: "compiler membantu Anda menemukan kesalahan". Terkadang. Tidak cukup sering. Kesalahan yang menarik tidak dapat ditemukan oleh kompiler sama sekali. Untuk itulah pengujian unit dilakukan.
S.Lott

2
@ S.Lott Saya menemukan bahwa API yang ditulis dalam bahasa dinamis memerlukan sedikit lebih banyak dokumentasi. Dalam bahasa statis, tanda tangan metode memberi tahu Anda jenis argumen apa yang diperlukan. Dalam bahasa yang dinamis, Anda tidak bisa mengatakan dengan mudah - dokumentasi API harus memberi tahu Anda objek apa yang diharapkan.
quanticle

1
@quanticle: Itu bukan arsitektur, kan?
S.Lott

2
"Kamu tidak bisa bereksperimen dengan mudah." - F # dan Haskell keduanya bahasa statis, dan mereka memiliki REPL lengkap, dan jarang menanyakan jenis pengenal atau ekspresi.
Rei Miyasaka
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.