Apakah bahasa yang diketik secara dinamis layak menerima semua kritik? [Tutup]

35

Saya telah membaca beberapa artikel di Internet tentang pilihan bahasa pemrograman di perusahaan. Baru-baru ini banyak bahasa dinamis yang diketik telah populer, yaitu Ruby, Python, PHP dan Erlang. Tetapi banyak perusahaan masih tetap dengan bahasa yang diketik statis seperti C, C ++, C # dan Java.

Dan ya, salah satu manfaat dari bahasa yang diketik statis adalah bahwa kesalahan pemrograman ditangkap lebih awal, pada waktu kompilasi, bukan pada saat dijalankan. Tetapi ada juga keuntungan dengan bahasa yang diketik secara dinamis. ( lebih lanjut tentang Wikipedia )

Alasan utama mengapa perusahaan tidak mulai menggunakan bahasa seperti Erlang, Ruby dan Python, tampaknya menjadi fakta bahwa mereka diketik secara dinamis. Itu juga tampaknya menjadi alasan utama mengapa orang-orang di StackOverflow memutuskan menentang Erlang. Lihat Mengapa Anda memutuskan "menentang" Erlang .

Namun, tampaknya ada kritik yang kuat terhadap mengetik dinamis dalam perusahaan, tapi saya tidak benar-benar mengerti mengapa itu adalah bahwa yang kuat.

Sungguh, mengapa ada begitu banyak kritik terhadap pengetikan dinamis di perusahaan? Apakah itu benar-benar mempengaruhi biaya proyek yang banyak, atau apa? Tapi mungkin saya salah.

— Jonas
sumber

3

Saya pikir mengetik statis dengan inferensi tipe dan kemungkinan mengetik bebek adalah cara terbaik untuk melakukan sesuatu. Ini juga sangat rumit

— Casebash

2

Saya baru saja melihat bebek mengetik C # (saya tidak menggunakan bahasa), dan sementara tampaknya memenuhi definisi mengetik bebek, verbositas yang diperlukan tampaknya mengalahkan tujuan. Itu bukan untuk mengatakan bahwa itu kadang-kadang tidak berguna.

— Chinmay Kanchi

3

Apakah hanya saya atau ada lebih banyak kritik terhadap bahasa yang diketik secara statis daripada yang diketik secara dinamis? Juga, dalam pengalaman saya, pilihan bahasa / teknologi dari "perusahaan" besar tampaknya ditentukan oleh tren saat ini / pilihan yang aman daripada manfaat teknis yang sebenarnya.

— MAK

2

@ChinmayKanchi: Verbosity? Anda hanya mendeklarasikan sesuatu dynamicdan mulai menggunakannya. Tidak lebih dari panggilan metode normal atau kelebihan operator.

— Joey

4

Saya tidak dapat menghitung jumlah jam yang saya buang pada kesalahan debugging perusahaan saya saat ini di Groovy pada kode Grails, yang akan terdeteksi oleh kompiler segera setelah kami menggunakan Java.

— WKS

46

Ya, saya percaya mereka melakukannya.

Ada beberapa alasan yang perlu dipertimbangkan dalam pemilihan bahasa untuk proyek baru:

Kecepatan run-time. Dibandingkan dengan C / C ++ / Fortran, Perl dan Python sangat lambat itu lucu.
Kecepatan inisialisasi. Dibandingkan dengan bahasa cepat di atas, Java jatuh dan menangis karena JVM terus memuat dan memuat dan while(1).... ....
Kemampuan prototipe. Sangat teliti dan melakukan pekerjaan deklarasi / definisi yang diperlukan untuk C ++ atau Java meningkatkan LOC, yang merupakan satu - satunya metrik yang diketahui yang secara andal berkorelasi dengan bugcounts. Itu juga membutuhkan banyak waktu. Ini juga membutuhkan sedikit lebih banyak berpikir tentang jenis dan koneksi.
Fiddlability internal. Berantakan secara dinamis dengan internal Anda sangat bagus hingga Anda mulai men-debug kode modifikasi diri Anda . (Python, Lisp, Perl)
Verifikasi kebenaran. Kompiler dapat memberikan lulus cepat semi-kebenaran kode Anda di C ++, dan ini bisa sangat bagus.
Rincian analisis statis. C dan Java memiliki analisis statis yang cukup bagus. Perl tidak sepenuhnya dapat dianalisis secara statis pada tingkat teoritis (Kemungkinan juga Python). Saya cukup yakin Lisp juga tidak.
Platform aneh hanya mengambil C, secara umum.
Rantai pendukung. Jika Anda dapat memiliki kontrak yang akan mendapatkan bug Anda melihat dan bekerja pada, itu besar .

Jika Anda dapat menganggap bahwa organisasi yang bekerja sama dengan Anda memiliki prinsip "Maju" (Ada istilah akuntansi untuk ini), dan tidak akan secara acak memutuskan untuk tidak bekerja pada perangkat lunak, maka Anda memiliki kasus yang jauh lebih baik untuk menggunakan perangkat lunak. Karena tidak ada penjualan Bisnis Utama (membawa implikasi mengambil tanggung jawab untuk mempertahankannya) Python / Perl / $ dynamic_language, itu sangat mengurangi risiko.

Dalam pengalaman saya, pengelola open source sering memiliki masalah dengan sepenuhnya bertanggung jawab atas perbaikan bug dan merilis pembaruan. "Gratis, KAMU kerjakan!" adalah tidak jawaban yang dapat diterima oleh kebanyakan bisnis (bukan compentencies inti mereka, antara lain).

Tentu saja, saya tidak berbicara tentang dunia webapp / startup, yang cenderung bermain dengan risiko tinggi / aturan hadiah tinggi dan sangat terbuka untuk tetap berada di tepi teknologi yang berbusa.

— Paul Nathan
sumber

16

"Gratis, KAMU kerjakan!" <- Masalah terbesar dengan F / OSS secara umum, saya memberi +1 tapi saya tidak bisa memilih :(

— Billy ONeal

4

Ringkasan yang bagus. Saya akan menempel pada tipe yang dibangun dengan baik itu menyampaikan makna semantik (saya bisa melihat tipe dan mengerti apa fungsinya, bagaimana bisa digunakan) dan dapat digunakan untuk menegakkan kebenaran (saya bisa membangun tipe yang hanya menerima inpus yang dibatasi ), dan saya tidak mendapatkan kesalahan bodoh dari kesalahan ketik (Saya benci deklarasi variabel otomatis)

— smithco

4

Anda bisa mendapatkan dukungan komersial untuk proyek open-source utama. Perusahaan besar menggunakan PL yang diketik secara dinamis untuk sebagian besar (pasti yang cocok), Facebook menggunakan PHP (UI) dan Erlang (obrolan), Twitter menggunakan Ruby (UI), Google menggunakan Python (Saya tidak tahu untuk apa) dan Lisp dan Python adalah sedang digunakan dalam banyak proyek penelitian canggih. Catatan: Saya adalah pengembang C # Saya (hampir) tidak pernah menggunakan bahasa yang diketik secara dinamis; namun poin-poin ini tidak berlaku sampai batas tertentu.

— Kaveh Shahbazian

4

Saya suka jawaban Anda tetapi Java tidak diketik secara dinamis ...

— Mehrdad

2

@ PaulNathan: Anda berpikir terlalu keras. Pertanyaannya adalah bertanya tentang bahasa yang diketik secara dinamis, dan jawaban ini menyebutkan Java seolah-olah diketik secara dinamis.

— Mehrdad

24

Anda memberi terlalu banyak kredit teknis kepada pembuat keputusan Enterprise. Ada pepatah lama, "Tidak ada yang dipecat karena membeli IBM." Jika Anda menempuh rute yang berbeda dan keadaan menjadi berbatu (selalu demikian), tidak ada yang mau mengambil risiko disalahkan. Tetap berpegang pada standar dan menyalahkan orang lain.

Ada banyak perusahaan yang lebih muda yang pada akhirnya akan menjadi perusahaan masa depan dan akan menggunakan bahasa-bahasa tersebut.

Dan jangan lupa baris buggillion kode yang ditulis dalam VBA!

— JeffO
sumber

1

+1 untuk "... perusahaan masa depan [dan] akan menggunakan bahasa-bahasa itu."

— rdmueller

6

"Ada banyak perusahaan yang lebih muda yang pada akhirnya akan menjadi perusahaan di masa depan dan akan menggunakan bahasa-bahasa itu.": Anda tampaknya menyiratkan bahwa bahasa yang dinamis agak baru dan perlu waktu untuk diadopsi oleh lebih banyak perusahaan. Di sisi lain, bahasa dinamis sudah ada sejak lama.

— Giorgio

17

Alasan perusahaan menggunakan C, C ++, C # dan Java bukan karena mereka diketik secara statis (setidaknya tidak secara langsung). Pembuat keputusan perusahaan tidak membuat pilihan seperti ini berdasarkan perbandingan objektif dari sistem tipe, saya jamin.

Usaha melakukan peduli tentang:

Biaya pemeliharaan jangka panjang : dapatkah Anda mengharapkan hal-hal untuk terus bekerja dengan baik dalam waktu 10 tahun? Sebenarnya hal yang baik jika evolusi bahasa konservatif dan kompatibel dengan mundur (seperti halnya dengan Java). Pengetikan statis sangat membantu di sini karena menangkap jenis bug utama pada waktu kompilasi sebelum mereka masuk ke sistem produksi Anda .....
Ketersediaan bakat - apakah Anda dapat menemukan pengembang untuk mempertahankan sistem baru Anda yang mengkilap? bagaimana jika pengembang asli pergi, akankah orang lain memahami kode ini? Ini menempatkan rintangan besar dalam memperkenalkan bahasa "baru" apa pun (terutama jika itu juga menciptakan persyaratan baru untuk penempatan, membangun sistem, dukungan operasional, dll.). Ini memberikan keuntungan besar bagi bahasa yang banyak digunakan (C, C ++, C # dan Java)
Biaya integrasi : apakah mudah untuk terhubung / berintegrasi dengan teknologi lain yang sudah Anda miliki atau mungkin akan Anda dapatkan? Jika Anda sudah memiliki setumpuk sistem J2EE lawas maka Anda perlu mengintegrasikannya. Solusi Java EE baru kemungkinan akan jauh lebih praktis untuk ini daripada misalnya Python.
Prediktabilitas / risiko rendah : apakah platform / bahasa terbukti, dan dapatkah saya yakin itu akan berhasil? Ini biasanya lebih penting daripada produktivitas sederhana. Adalah jauh lebih mudah bagi seorang manajer untuk membujuk bosnya untuk memberinya anggaran besar bagi tenaga kerja untuk membangun sistem baru daripada baginya untuk kembali lagi nanti dan mengatakan bahwa itu tidak berhasil .....
Dukungan / dukungan Perusahaan - apakah organisasi internasional besar berkomitmen untuk mendukung bahasa dan platform? Apakah mereka akan menandatangani kontrak untuk mendukung saya sehingga saya memiliki seseorang untuk dihubungi jika ada masalah?
Netralitas vendor / independensi platform - apakah saya akan dikunci ke satu pemasok? Atau apakah saya memiliki berbagai pilihan pemasok / jalur transisi di masa depan yang tersedia? Anda tidak ingin terjebak dalam jalan buntu arsitektur, tidak dapat membuat kemajuan saat pesaing Anda makan siang Anda. Jika Anda melakukan pekerjaan dengan baik sebagai arsitek perusahaan, Anda harus memikirkan setidaknya 5-10 tahun ke depan tentang hal ini.

Secara pribadi, saya pikir jika Anda ingin menggunakan bahasa dinamis di Enterprise, maka peluang terbaik Anda sejauh ini adalah menggunakan sesuatu yang mendukung piggy back-on pada ekosistem perusahaan yang ada. Yang paling menonjol adalah bahasa JVM dinamis baru: mis. JRuby, Groovy, Clojure. Sejauh menyangkut manajemen TI, ini adalah pilihan bahasa dinamis "aman" karena mereka beroperasi di dalam dan bermain dengan baik dengan ekosistem perusahaan Java lainnya.

— mikera
sumber

1

Saya tidak percaya belum ada jawaban Anda yang terototasi.

— Sebastian N.

11

Alasan utama mengapa perusahaan tidak mulai menggunakan bahasa seperti Erlang, Ruby dan Python, tampaknya menjadi fakta bahwa mereka diketik secara dinamis.

Saya pikir ini hanya alasan utama mereka. Alasan sebenarnya adalah bahwa bisnis tidak benar-benar menganggapnya serius dan merasa bahwa mereka mungkin terlalu amatir. Java dan .NET adalah "nama bisnis besar", memiliki pemasaran komersial yang baik, dukungan pelanggan komersial, dan dengan demikian secara luas dianggap sangat serius.

Sangat disayangkan bahwa praktis tidak ada bahasa yang diketik secara statis yang mendekati sepopuler nama bisnis besar. Mengapa lingkungan pemrograman sumber terbuka / perangkat lunak bebas hampir selalu diketik secara dinamis? Ini mungkin mengindikasikan bahwa bahasa yang diketik secara statis sebenarnya tidak semudah itu dibuat, dan bahwa pengetikan dinamis adalah “hacky man's hack”. Jika itu masalahnya, bisnis yang memutuskan bahasa yang diketik secara dinamis mungkin benar.

— Timwi
sumber

8

Sangat? Terakhir saya melihat, Google telah memberikan cukup banyak bobot dan upaya pengembangan yang cukup besar di belakang Python, termasuk merekrut pencipta Python dan memungkinkannya menghabiskan 50% waktunya bekerja untuk bahasa tersebut. Google juga berkontribusi sejumlah besar kode ke Python, terutama sekarang unladen-walet telah digabungkan ke dalam pohon sumber Python 3. Itu membuat Python "nama bisnis besar" bagi saya.

— Chinmay Kanchi

13

@Chinmay Kanchi: Menarik bagaimana Anda menarik kesimpulan Anda dari statistik dengan ukuran sampel 1.

— Timwi

6

Sentuh. Namun, beberapa kesimpulan Anda juga cacat. Mengimplementasikan bahasa dinamis dengan benar jauh lebih sulit daripada menerapkan bahasa yang diketik secara statis. Mengetik secara dinamis tentu bukan "lazy man's hack" seperti yang Anda katakan. Ini memungkinkan pengembang untuk menjadi malas, tetapi bukan orang yang menulis kompiler / juru bahasa. Bahkan, mengoptimalkan bahasa yang diketik secara dinamis sangat sulit sehingga saya hanya bisa memikirkan satu bahasa yang, dalam beberapa kali, menerima perlakuan ini secara luas (JavaScript), meskipun ada proyek pengoptimalan / JITting untuk bahasa lain (Python, PHP).

— Chinmay Kanchi

2

Juga, jika Anda berpikir bahasa yang diketik secara dinamis adalah yang paling umum digunakan di lingkungan sumber terbuka, ini jauh dari jelas. Bergantung pada metrik yang Anda pilih, ini mungkin benar, tetapi seringkali tidak. Mengukur garis kode, C menang dengan tembakan panjang. Jika Anda mengukur bahasa apa yang digunakan dalam proyek-proyek sumber terbuka, termasuk yang multi-bahasa, bahasa yang paling populer adalah JavaScript, C, C ++ dan PHP dalam urutan itu. Jika Anda hanya mengukur bahasa utama, bahasa yang paling populer adalah Perl, Java, C # dan JavaScript. bit.ly/C6xTB

— Chinmay Kanchi

7

Tentu saja menulis pengoptimal untuk bahasa yang diketik secara dinamis itu sulit, tetapi bukan penerjemah : Anda dapat menghapus semua pemeriksaan jenis, dan sisanya sama. Tidak ada pembuat bahasa amatir yang berpikir untuk menulis pengoptimal. - Mengenai bit terakhir, saya tidak bermaksud mengatakan bahwa sebagian besar perangkat lunak open-source ditulis dalam bahasa pemrograman yang diketik secara dinamis, tetapi lebih pada sebagian besar bahasa pemrograman open-source (saya katakan "lingkungan" karena saya sedang berbicara tentang kompiler / juru bahasa, IDE, dll.) diketik secara dinamis.

— Timwi

9

Bahasa yang diketik secara dinamis cenderung lebih lambat daripada sepupu yang diketik secara statis.
Kesalahan lebih sulit ditangkap dan bisa lebih sulit untuk di-debug
Compiler / interpreter cenderung tidak terlalu cerewet tentang apa yang bisa dan tidak bisa Anda lakukan. yaitu, Anda cukup banyak hanya menangkap kesalahan sintaks pada tahap kompilasi
Jika Anda tidak sangat berhati-hati dengan desain bahasa dinamis diketik, Anda berakhir dengan Javascript, yang merupakan satu bahasa kode-bau

EDIT: Saya harus menyebutkan bahwa bahasa pemrograman utama saya saat ini adalah Python, yang diketik secara dinamis. Secara pribadi, saya suka kebebasan yang datang dengan tidak harus pra-mendeklarasikan variabel, tetapi kadang-kadang, akan lebih baik untuk menentukan (misalnya) seperti apa parameter fungsi yang diperlukan untuk menangkap kesalahan lebih awal daripada terlambat.

— Chinmay Kanchi
sumber

1

Meskipun benar bahwa kompiler tidak teliti, biasanya interpreternya adalah. Sebagian besar, juru bahasa mendeteksi situasi yang bermasalah dan menandakan kesalahan.

— Winston Ewert

17

Saya suka mengetik dinamis tetapi saya benci tidak harus variabel predeclare! Sering kali saya akhirnya secara tidak sengaja memperkenalkan variabel baru karena saya salah mengeja nama variabel.

— Frank Shearar

1

@ Frank: Saya sangat menyukai Perl yang memiliki pengaturan untuk memaksa deklarasi variabel. Itu salah satu kelebihan Perl, menurut saya.

— Paul Nathan

8

Bahasa yang diketik secara dinamis dianggap (oleh beberapa programmer / bos) untuk menghasilkan kode yang tidak berfungsi juga. Fakta bahwa program diketik secara dinamis mengkompilasi memberi tahu Anda sangat sedikit tentang kebenarannya. Fakta bahwa bahasa yang diketik secara statis mengkompilasi memberi tahu Anda lebih banyak. (Di sisi lain, masih ada jalan panjang antara kompilasi dan melakukan hal yang benar, jadi ini mungkin kurang berarti daripada tampaknya)

Bahasa yang diketik secara dinamis dianggap sebagai bahasa scripting. Anda tidak akan pernah menulis aplikasi dalam bash atau file batch. Semua bahasa yang diketik secara dinamis cenderung dilingkarkan ke dalam kategori itu (tidak adil).

Bahasa yang diketik secara dinamis lebih lambat dari pada bahasa yang diketik secara statis. (Tapi kita akan melihat seberapa baik bekerja pada perubahan JIT itu)

— Winston Ewert
sumber

2

"Dianggap oleh" beberapa programmer. Ketika saya memiliki argumen dengan programmer tentang pengetikan dinamis, mereka biasanya mengakui bahwa mereka tidak pernah benar-benar menggunakan bahasa semacam itu.

— Frank Shearar

1

@ Jujur, apakah Anda mengatakan bahwa orang yang berpendapat inferioritas pengetikan dinamis umumnya belum menggunakannya?

— Winston Ewert

2

@ Frank: Saya telah menggunakan bahasa semacam itu, dan sebagian besar waktu hasilnya adalah kekacauan yang tidak dapat dipelihara. (Agar adil, itu adalah PHP, dan PHP memiliki masalah lain selain pengetikan dinamis)

— Billy ONeal

@ Billy: Saya pikir ini biasa. Saya tidak bisa mengetik secara dinamis selama bertahun-tahun karena pengalaman saya dengan VB - ketika akhirnya saya menyadari bahwa penerapan pengetikan dinamis yang mengerikan dan skizofrenia ini tidak biasa, pendapat saya berubah secara dramatis.

— Shog9

@ Winston: Saya mengatakan bahwa orang-orang dengan siapa saya telah berdebat belum. Bagi saya, ini merupakan "pengetikan dinamis tidak mungkin berhasil" ... tetapi mereka dengan senang hati akan menggunakan banyak teknik yang pertama kali dikembangkan di, oleh dan untuk bahasa dinamis (IDE, refactoring, dari atas kepala saya). Juga, pertanyaan-pertanyaan seperti ini: stackoverflow.com/questions/2317579 menunjukkan bahwa walaupun mungkin tidak universal, kasus saya berdebat dengan itu-tidak-bisa-bekerja-tapi-saya-belum-coba programmer tidak terisolasi. (Saya, saya pikir kedua pendekatan memiliki nilai.)

— Frank Shearar

8

Catatan: ini sebagian besar subjektif dan berdasarkan pengalaman dan kesan saya.

Bahasa yang diketik secara dinamis sangat berbeda dari bahasa yang diketik secara statis. Perbedaan ini mungkin menjadi lebih penting dalam perangkat lunak perusahaan kelas berat daripada di sebagian besar aplikasi lainnya.

Bahasa yang diketik secara statis cenderung sangat preskriptif. Metode hanya akan mengambil input yang sama persis dengan tanda tangannya. Tingkat akses cenderung menjadi sangat penting dan antarmuka didefinisikan secara eksplisit, dengan pembatasan yang tegas tetapi tegas untuk menegakkan definisi tersebut.

Bahasa yang diketik secara dinamis di sisi lain sangat pragmatis. Jenis konversi sering terjadi secara implisit, fungsi bahkan dapat bermain bersama jika Anda memberikan jenis input yang salah asalkan berperilaku cukup mirip. Dalam bahasa seperti Python, bahkan tingkat akses akan didasarkan pada kontrak daripada pembatasan teknis (yaitu hanya privatekarena Anda diberitahu untuk tidak menggunakannya dan memiliki nama yang lucu).

Banyak programmer lebih suka bahasa yang dinamis karena mereka (bisa dibilang) memungkinkan prototyping cepat. Kode sering berakhir lebih pendek (jika hanya karena kurangnya jenis deklarasi) dan jika Anda ingin melanggar protokol yang tepat karena Anda memerlukan solusi cepat dan kotor atau ingin menguji sesuatu, itu mudah.

Sekarang, alasan bahwa perusahaan "enterprisey" sering lebih suka bahasa yang diketik secara statis adalah karena mereka lebih membatasi dan lebih eksplisit tentang pembatasan itu. Meskipun dalam prakteknya bahkan kode yang diketik secara statis dapat dipecah oleh orang idiot dengan kompiler, banyak masalah akan jauh lebih terlihat jauh lebih awal ke dalam proses (yaitu sebelum runtime). Ini berarti bahwa meskipun basis kode besar, monolitik dan kompleks, banyak kesalahan dapat ditangkap dengan mudah, tanpa harus menjalankan kode atau mengirimkannya ke departemen QA.

Alasan mengapa manfaat tidak lebih besar daripada kerugian bagi banyak programmer di luar lingkungan itu adalah bahwa ini adalah kesalahan yang akan sering dengan mudah ditangkap oleh pemeriksaan menyeluruh terhadap kode atau bahkan dengan mencoba menjalankannya. Terutama ketika mengikuti metodologi uji-didorong, kesalahan ini sering menjadi sepele untuk ditangkap dan mudah diperbaiki. Juga, dengan banyak perusahaan seperti itu memiliki siklus rilis yang lebih pendek, produktivitas seringkali lebih penting daripada kekakuan dan banyak pengujian (dasar) sedang dilakukan oleh pengembang sendiri.

Alasan lain bahwa banyak perusahaan tidak menggunakan bahasa yang diketik secara dinamis adalah kode warisan. Konyol, bagi perusahaan besar, seringkali perusahaan akan tetap berpegang pada solusi yang berhasil, bahkan jika mereka sudah melewati masa simpannya. Inilah sebabnya mengapa banyak perusahaan besar memberlakukan Internet Explorer 6 dan sangat lambat untuk memutakhirkan OS mereka. Ini juga sebabnya mereka akan sering menulis kode baru dalam bahasa "lama" (misalnya versi Jawa kuno): jauh lebih mudah untuk menambahkan beberapa baris kode ke perangkat lunak yang tidak hidup daripada untuk mendapatkan persetujuan untuk penulisan ulang lengkap dalam bahasa baru bahasa.

tl; dr: bahasa statis terasa lebih seperti birokrasi, sehingga manajer yang tegas lebih menyukainya.

— Alan Plum
sumber

3

Bahasa dengan aturan pengetikan yang longgar menciptakan banyak peluang untuk hal-hal yang salah untuk pekerjaan yang agak rumit. Dalam JavaScript, misalnya, meneruskan nomor ke kode yang mengharapkan string akan sering berperilaku seolah-olah seseorang telah melewati representasi string dari nomor itu, tetapi tidak selalu. Mencoba misalnya menambahkan 456 ke 123 tidak akan menghasilkan 123456, tetapi sebaliknya akan menghasilkan 579. Kecuali jelas siapa yang bertanggung jawab untuk konversi angka-ke-string, itu dapat dilakukan secara berlebihan atau gagal dilakukan sama sekali.

— supercat

1

@supercat, saya pikir PHP dan JavaScript adalah contoh yang baik untuk dua cara menangani masalah itu (berkaitan dengan operator): dalam operator PHP tidak ambigu - +mengambil angka dan menambahkannya, jika Anda ingin penggabungan, Anda perlu menggunakan .; di JS kedua operasi berbagi operator yang sama - jika Anda tidak tahu bagaimana nilai Anda akan berperilaku Anda diharapkan untuk mengubahnya secara eksplisit. Tentu saja ini juga ada hubungannya dengan pengetikan yang longgar vs pengetikan yang ketat (Python bahkan lebih ketat), tetapi pada dasarnya Anda harus memastikan nilai Anda memiliki tipe yang tepat atau membuat operasi Anda menegakkan tipe yang diharapkan.

— Alan Plum

1

Saya tidak terlalu terbiasa dengan PHP, tetapi sepertinya menggunakan apa yang saya sebut pendekatan "benar". Javascript adalah IMHO keji dalam banyak hal, tapi saya pikir perilaku "+" adalah salah satu yang terburuk. Sebenarnya, saya tidak yakin bahwa pengetikan dinamis loosy-goosy akan memiliki banyak keuntungan dibandingkan sistem tipe yang lebih kuat yang memungkinkan suatu antarmuka untuk menyatakan bahwa hal-hal dari beberapa kelas atau tipe antarmuka lain harus dianggap sebagai implementasi atau diturunkan dari itu, dengan aturan khusus tentang cara memprioritaskan klaim. Keterbatasan besar yang saya sadari dengan kerangka kerja yang diketik secara struktural saat ini adalah bahwa ...

— supercat

1

... jika dua orang secara mandiri mengembangkan antarmuka yang sama, tidak ada cara bagi pihak ketiga untuk menulis kode yang dapat menggunakannya secara bergantian. Jika pihak ketiga dapat mendefinisikan antarmuka baru dan menyatakan bahwa implementasi salah satu atau kedua yang sudah ada harus secara otomatis mengimplementasikan yang baru (menggunakan pembungkus yang disediakan di antarmuka baru jika diperlukan) Saya pikir itu akan menangani 99% dari apa yang secara semantik baik tentang pengetikan dinamis.

— supercat

3

Tidak, saya tidak berpikir bahasa yang diketik secara dinamis pantas menerima semua kritik. (Atau jika Anda lebih suka, mereka layak menerima kritik sebanyak bahasa yang diketik secara statis.)

Dalam pengalaman saya (dan saya tidak berusaha untuk menggeneralisasi pernyataan ini), programer yang mengkritik bahasa dinamis belum menggunakannya. Percakapan biasanya berjalan "tetapi dengan mengetik statis kompiler menangkap begitu banyak kesalahan!" dan saya katakan "baik, itu tidak masalah, dalam pengalaman saya". (Biasanya programmer lain dari Java, Delphi atau latar belakang serupa; Saya tidak tahu ada programmer Haskell atau ML.)

Satu-satunya hal yang benar-benar menggelisahkan saya adalah ketika seseorang mengklaim bahwa teknik Foo tidak mungkin dilakukan (atau mungkin sangat sulit dilakukan) dalam bahasa yang diketik secara dinamis ... ketika teknik itu ditemukan di, oleh dan untuk diketik secara dinamis bahasa. IDE? Smalltalk. Refactoring otomatis? Smalltalk. Penelepon / pelaksana-dari? Smalltalk.

— Frank Shearar
sumber

Saya tidak ingin mengacaukan jawaban saya dengan sikap pribadi saya, yaitu ini: alat yang tepat untuk pekerjaan yang tepat. Apapun jenis bahasa yang Anda gunakan lebih cocok untuk beberapa tugas, dan lebih buruk cocok untuk yang lain, daripada jenis bahasa lain.

— Frank Shearar

6

Ketika programmer lain berasal dari Haskell, dia sudah tahu itu adalah bahasa superior untuk Java dan bahasa dinamis;)

— Andres F.

0

Perusahaan tidak mengadopsi bahasa dan alat baru dengan cukup cepat dan ada alasan bagus untuk itu. Tetapi, ketika salah satu alat utama seperti C # menerapkan beberapa fitur ini, maka mereka akan masuk ke perusahaan utama ....

— aggietech
sumber

Saya tidak tahu mengapa ini diturunkan, tapi ini pernyataan yang berwawasan luas. Perusahaan lambat dan konservatif. Orang juga lebih suka perubahan bertahap (seperti kata kunci dinamis dalam C # yang memungkinkan Anda sesekali menggunakan pengetikan dinamis dalam bahasa yang diketik secara statis) daripada perubahan mendadak (seperti Ruby).

— Vaddadi Kartick