Saya cenderung berpikir dalam hal fitur:
Sintaksis:
Berbasis C atau apa pun yang Anda miliki. Java memiliki sintaks berbasis C. Saya sangat merekomendasikan mencoba sesuatu seperti Python atau Ruby untuk mengeluarkan Anda dari sintaks dan berpikir lebih dalam hal dasar-dasar tentang cara kerja bahasa yang diberikan. Saya berpendapat bahwa tidak ada sintaks yang perlu lebih besar daripada berbasis C dan tidak memiliki masalah blok bangunan di sekitar white-space.
Dikompilasi vs diinterpretasikan w. Build-Process vs. Interpreted / Console:
Saya memiliki sedikit keakraban dengan waktu kompilasi vs masalah run-time lingkungan tetapi saya mendapatkan bahwa ada banyak masalah di sana yang jarang saya pikirkan.
Demikian juga ada banyak bahasa yang ditafsirkan yang masih memiliki sesuatu dari proses kompilasi-ish untuk berjalan di dalam mesin virtual seperti Java. Anda masih harus membangun kembali untuk melihat perubahan pada beberapa hal.
Dan kemudian ada JavaScript dan Python yang dapat Anda jalankan dengan cepat, perintah demi perintah di konsol di lingkungan langsung. Ketiganya dapat mengarah pada cara penulisan kode yang sangat berbeda.
Pengetikan dinamis vs. Ketat:
Saya cenderung melihat keduanya sebagai tradeoffs desain. Saat Anda berada di level yang jauh lebih rendah dan kinerjanya sangat kritis, pengetikan statis sangat masuk akal. Saya tidak pernah mengerti gagasan tentang seseorang yang "lebih aman" daripada yang lain, tetapi saya muncul dalam bahasa yang sangat plastis / dinamis di mana Anda baru saja mempelajari cara kerja sistem pengetikan dan apa yang diharapkan, pada dasarnya. Ketik shenanigans jarang menjadi perhatian saya di JS. Dalam beberapa hal, fleksibilitas dapat membuat segalanya lebih kuat, meskipun diakui sentuhan yang lebih misterius untuk pengembang level Jr. lebih jika Anda tidak tahu tentang beberapa lubang pot dalam bahasa.
Lingkup Tingkat Blok vs. Lingkup Fungsi vs.?:
Block-Level adalah yang paling umum (apa pun di antara {} di sebagian besar bahasa sintaksis berbasis-c). Ruang lingkup JavaScript dibangun di sekitar fungsi (yang juga digunakan untuk membangun objek sehingga objek juga efektif). Ada juga banyak variasi dalam jenis akses apa yang Anda miliki dari lingkup dalam ke luar-lingkup. Saya tidak terbiasa dengan skema pelingkupan lain tapi saya yakin mereka ada.
OOP Klasik vs. Prototypal OOP vs Almost-OOP (struct in C?) Vs Non-OOP:
Bahkan dalam OOP berbasis kelas ada banyak ruang untuk variasi. Apakah Anda dapat melakukan banyak pewarisan (ew, terlalu banyak, ew), mendefinisikan antarmuka, dll ...
Dalam JavaScript kami memiliki semacam OOP prototipe hibrida terhambat di mana objek jauh lebih sederhana, sangat bisa berubah, tetapi kami masih memiliki kemampuan untuk memisahkan antarmuka dari masalah internal, yang IMO, adalah aspek penting dari enkapsulasi.
Hal tentang OOP adalah benar-benar ada banyak hal yang dapat Anda lakukan yang pada dasarnya berorientasi pada OOP tanpa secara teknis menjadi OOP. Ada puritan tentu saja tetapi pada akhirnya, Pola Desain adalah tentang mencapai abstraksi tertentu yang bekerja dengan baik dalam situasi tertentu. Jangan terlalu cepat untuk menganggap ide-ide dari bahasa berbasis OOP tidak digunakan dalam sesuatu yang lebih berorientasi pada prosedur. Dan saya tidak berbicara tentang JavaScript. Sama sekali tidak dibatasi oleh versi konyol dari paradigma OOP berbasis prototipe.
Fungsi Kelas Satu:
Tidak memiliki ini dalam bahasa adalah hal yang sulit bagi saya untuk menyerah. Anda dapat melewati fungsi sekitar seperti data untuk digunakan dalam konteks lain. Hal ini membuat skema penanganan acara sangat mudah diimplementasikan tetapi juga membuatnya sangat mudah untuk mengadaptasi bahasa untuk bekerja seperti yang Anda inginkan. Ini, lebih dari apa pun yang saya duga, hal yang telah menjadikan JavaScript sukses yang akhirnya telah dirancang meskipun dalam dua minggu dan membuat sintaksis perkiraan Java ditampar sebagai skema pemasaran.
Penutupan:
Saya tidak yakin di mana perdebatannya untuk Java, tapi saya tahu banyak devs Jawa berteriak-teriak untuk fitur ini satu atau dua tahun yang lalu. Dalam bahasa non-penutupan, ketika suatu fungsi ditutup, apa pun yang entah bagaimana bisa merujuk hal-hal dari dalam fungsi itu tidak akan dapat mengaksesnya karena itu adalah sampah yang dikumpulkan. Dalam penutupan, konteks eksekusi terikat sedemikian rupa sehingga jika Anda dapat mereferensikan hal-hal di dalam fungsi yang ditutup itu dari lingkup lain seperti pada objek atau fungsi yang dikembalikan, Anda pada dasarnya mendapatkan vars tersebut seperti ketika fungsi tersebut ditutup. Ini seperti macet kaki Anda di pintu pengumpulan sampah, meskipun saya menduga itu diterapkan lebih seperti salinan vars yang dibuat menjadi vars lokal dari entitas yang merujuk.
Kaku / Ketat / Aman vs. Memberi Anda Semua Tali yang Anda Inginkan:
JS devs dan Java devs cenderung tidak saling memahami sama sekali dan saya pikir ini ada hubungannya dengan dua bahasa yang berada di sisi yang berseberangan dengan spektrum desain khusus ini. Saya tidak ingin Anda melindungi saya dari diri saya sendiri atau dari para devs lain di tim saya. Saya ingin melakukan lebih banyak dalam kode yang lebih sedikit dan melakukan semuanya dengan cara yang sangat berbeda (tetapi konsisten untuk domain tertentu) tergantung pada situasinya. Ada pengorbanan mutlak untuk keduanya dan banyak bahasa cenderung lebih banyak jatuh di tengah.
