Apakah ada korelasi antara skala proyek dan ketegasan bahasa?

Menjelaskan perbedaan antara ketatnya bahasa dan paradigma dengan seorang rekan saya, saya akhirnya menyatakan bahwa:

• Bahasa toleran, seperti bahasa yang dinamis dan ditafsirkan, digunakan terbaik untuk prototipe dan proyek kecil atau aplikasi web berukuran sedang. Saat memilih bahasa dinamis yang elegan seperti Python atau JavaScript dengan Node.js, manfaatnya adalah:

  1. Pengembangan cepat,

  2. Kode boilerplate berkurang,

  3. Kemampuan untuk menarik programmer muda dan kreatif yang melarikan diri dari "bahasa perusahaan"   seperti Jawa.

• Bahasa yang diketik / dikompilasi secara statis adalah yang terbaik untuk aplikasi yang membutuhkan keketatan yang lebih tinggi seperti aplikasi bisnis kritis atau aplikasi untuk aplikasi ukuran sedang hingga besar.

  1. Paradigma dan pola terkenal yang dikembangkan selama beberapa dekade,

  2. Kemudahan pemeriksaan statis,

  3. Kemampuan untuk menemukan banyak pengembang profesional dengan pengalaman puluhan tahun.

• Bahasa yang ketat seperti Haskell, Ada atau teknik seperti kontrak Kode dalam C # lebih baik untuk sistem yang lebih mengutamakan keamanan daripada fleksibilitas (bahkan jika Haskell bisa sangat fleksibel), seperti sistem dan sistem yang kritis kehidupan yang diharapkan sangat stabil. Manfaatnya adalah:

  1. Kemampuan untuk menangkap bug sebanyak mungkin pada waktu kompilasi,

  2. Kemudahan pemeriksaan statis,

  3. Kemudahan bukti formal.

Namun, dengan melihat bahasa dan teknologi yang digunakan untuk proyek skala besar oleh perusahaan besar, tampaknya pernyataan saya salah . Sebagai contoh, Python berhasil digunakan untuk sistem besar seperti YouTube atau aplikasi Google lainnya yang membutuhkan sejumlah besar keketatan.

Apakah masih ada korelasi antara skala proyek dan ketatnya bahasa / paradigma yang harus digunakan?

Apakah ada faktor ketiga yang saya lupa pertimbangkan?

Dimana saya salah

Sebuah studi kasus yang menarik tentang masalah-masalah proyek penskalaan yang menggunakan bahasa yang dinamis dan ditafsirkan dapat ditemukan dalam Beginning Scala oleh David Pollak.

Saya mulai mencari cara untuk mengekspresikan kode di otak saya dengan cara yang lebih sederhana dan lebih langsung. Saya menemukan Ruby dan Rails. Saya merasa terbebaskan. Ruby mengizinkan saya untuk mengekspresikan konsep dalam baris kode yang jauh lebih sedikit. Rails jauh lebih mudah digunakan daripada Spring MVC, Hibernate, dan kerangka kerja web Java "ramping" lainnya. Dengan Ruby dan Rails, saya harus mengekspresikan lebih banyak dari apa yang ada di kepala saya dalam periode waktu yang lebih singkat. Itu mirip dengan pembebasan yang saya rasakan ketika saya pindah dari C ++ ke Java ...

Ketika proyek Ruby dan Rails saya tumbuh melampaui beberapa ribu baris kode dan ketika saya menambahkan anggota tim ke proyek saya, tantangan bahasa dinamis menjadi jelas.

Kami menghabiskan lebih dari setengah tes penulisan waktu pengkodean, dan sebagian besar keuntungan produktivitas yang kami lihat hilang dalam penulisan tes . Sebagian besar pengujian tidak perlu dilakukan di Jawa karena kebanyakan dari mereka diarahkan untuk memastikan bahwa kami telah memperbarui penelepon ketika kami melakukan refactored kode dengan mengubah nama metode atau jumlah parameter. Juga, saya menemukan bahwa bekerja di tim di mana ada pikiran berbaur antara dua hingga empat anggota tim, semuanya berjalan dengan baik di Ruby, tetapi ketika kami mencoba untuk membawa anggota baru ke dalam tim, koneksi mental sulit untuk ditransmisikan ke anggota tim baru .

Saya mencari bahasa baru dan lingkungan pengembangan. Saya mencari bahasa yang ekspresif seperti Ruby tetapi seaman dan berkinerja tinggi seperti Java ...

Seperti yang Anda lihat, tantangan utama dalam penskalaan proyek untuk penulis ternyata adalah dalam pengembangan pengujian dan transfer pengetahuan.

Secara khusus, penulis membahas lebih rinci dalam menjelaskan perbedaan dalam penulisan tes antara bahasa yang diketik secara dinamis dan statis di Bab 7. Di bagian "Bunignily Killing Bunnies: Dwemthy's Stairs" penulis membahas Scala port dari contoh Ruby tertentu:

Why the Lucky Stiff ... memperkenalkan beberapa konsep pemrograman Ruby di Array Dwemthy's di mana seekor kelinci bertarung melawan berbagai makhluk. N8han14 memperbarui contoh untuk bekerja di Scala ...

Dibandingkan dengan kode Ruby, bagian perpustakaan dari kode Scala lebih kompleks. Kami harus melakukan banyak pekerjaan untuk memastikan jenis kami benar. Kami harus menulis ulang properti Creature secara manual di kelas DupMonster dan CreatureCons. Ini lebih banyak pekerjaan daripada method_missing. Kami juga harus melakukan sejumlah pekerjaan yang adil untuk mendukung kekekalan dalam Makhluk dan Senjata kami.

Di sisi lain, hasilnya jauh lebih kuat daripada versi Ruby. Jika kita harus menulis tes untuk kode Ruby kita untuk menguji apa yang meyakinkan kompiler Scala kita, kita akan membutuhkan lebih banyak baris kode. Sebagai contoh, kita dapat yakin bahwa Kelinci kita tidak dapat menggunakan Kapak. Untuk mendapatkan jaminan ini di Ruby, kami harus menulis tes yang memastikan bahwa memohon |^Kelinci tidak berhasil. Versi Scala kami memastikan bahwa hanya Senjata yang ditentukan untuk Makhluk tertentu yang dapat digunakan oleh Makhluk itu, sesuatu yang akan membutuhkan banyak refleksi runtime di Ruby ...

Membaca di atas dapat membuat orang berpikir bahwa ketika proyek tumbuh lebih besar, penulisan tes mungkin menjadi rumit. Alasan ini akan salah, sebagaimana dibuktikan oleh contoh-contoh proyek sangat besar yang berhasil disebutkan dalam pertanyaan ini ("Python berhasil digunakan untuk ... YouTube").

Masalahnya, penskalaan proyek tidak benar-benar mudah. Proyek yang sangat besar dan berumur panjang dapat "membeli" proses pengembangan pengujian yang berbeda, dengan ruang uji kualitas produksi, tim pengembang pengujian profesional, dan barang-barang kelas berat lainnya.

Suite tes Youtube atau Java Compatibility Kit tentu saja memiliki kehidupan yang berbeda dari tes dalam proyek tutorial kecil seperti Dwemthy's Array .

Pernyataan Anda tidak salah. Anda hanya perlu menggali sedikit lebih dalam.

Sederhananya, sistem besar menggunakan banyak bahasa, bukan hanya satu bahasa. Mungkin ada bagian yang dibangun menggunakan bahasa "ketat", dan mungkin ada bagian yang dibangun menggunakan bahasa dinamis.

Adapun contoh Google dan YouTube Anda, saya mendengar bahwa mereka menggunakan Python terutama sebagai "lem" antara berbagai sistem. Hanya Google yang tahu sistem apa yang dibangun, tetapi saya bertaruh bahwa banyak sistem kritis Google dibangun menggunakan bahasa yang ketat dan "korporat" seperti C ++ atau Java, atau mungkin sesuatu yang mereka ciptakan sendiri seperti Go.

Bukannya Anda tidak dapat menggunakan bahasa toleran untuk sistem skala besar. Banyak orang mengatakan Facebook menggunakan PHP, tetapi mereka lupa menyebutkan bahwa Facebook harus membuat pedoman pemrograman yang sangat ketat untuk menggunakannya secara efisien pada skala ini.

Jadi ya, beberapa tingkat keketatan diperlukan untuk proyek skala besar. Ini bisa berasal dari ketatnya bahasa atau kerangka kerja, atau dari pedoman pemrograman dan konvensi kode. Anda tidak bisa hanya meraih beberapa lulusan perguruan tinggi, memberi mereka Python / Ruby / JavaScript dan mengharapkan mereka untuk menulis perangkat lunak yang berskala jutaan pengguna.

Ada dua jenis kesalahan yang harus diperiksa: ketik kesalahan (menyatukan bilangan bulat + daftar float) dan kesalahan logika bisnis (mentransfer uang ke rekening bank, periksa apakah akun sumber punya uang).

Bagian "dinamis" dari bahasa pemrograman dinamis hanyalah tempat di mana pemeriksaan tipe dilakukan. Dalam bahasa pemrograman "diketik secara dinamis", pemeriksaan tipe dilakukan saat mengeksekusi setiap pernyataan, sedangkan dalam pemeriksaan tipe "bahasa yang diketik secara statis" dilakukan pada waktu kompilasi. Dan Anda dapat menulis penerjemah untuk bahasa pemrograman statis (seperti halnya emscriptem ), dan Anda juga dapat menulis kompiler statis untuk bahasa pemrograman dinamis (seperti gcc-python atau shed-skin ).

Dalam bahasa pemrograman dinamis seperti Python dan Javascript, Anda perlu menulis unit test tidak hanya untuk logika bisnis program tetapi juga untuk memeriksa apakah program Anda tidak memiliki kesalahan sintaks atau tipe. Misalnya, jika Anda menambahkan "+" integer ke daftar float (yang tidak masuk akal dan akan mengeluarkan kesalahan), dalam bahasa dinamis kesalahan akan dinaikkan saat runtime saat mencoba menjalankan pernyataan. Dalam bahasa pemrograman statis seperti C ++, Haskell dan Java, jenis kesalahan ini akan ditangkap oleh kompiler.

Basis kode kecil dalam bahasa pemrograman yang dicentang secara dinamis lebih mudah untuk mencari kesalahan tipe karena lebih mudah memiliki cakupan kode sumber 100% . Itu saja, Anda menjalankan kode dengan tangan beberapa kali dengan nilai yang berbeda dan Anda selesai. Memiliki cakupan 100% dari kode sumber memberi Anda petunjuk yang adil bahwa program Anda mungkin tidak memiliki kesalahan ketik .

Dengan basis kode besar dalam bahasa pemrograman yang dicentang secara dinamis, lebih sulit untuk menguji setiap pernyataan dengan setiap kombinasi jenis yang mungkin, khususnya jika Anda ceroboh dan menulis fungsi yang dapat mengembalikan string, daftar atau objek kustom tergantung pada argumennya.

Dalam bahasa pemrograman yang diperiksa secara statis, kompiler akan menangkap sebagian besar kesalahan tipe pada waktu kompilasi. Saya katakan paling karena pembagian dengan kesalahan nol, atau kesalahan array di luar batas juga jenis kesalahan.

Lebih sering daripada tidak diskusi sebenarnya bukan tentang bahasa pemrograman tetapi tentang orang-orang yang menggunakan bahasa tersebut. Dan ini benar karena, misalnya, bahasa rakitan sama kuatnya dengan bahasa pemrograman lainnya, namun kami sedang menulis kode pada JavaScript. Mengapa? Karena kita manusia. Pertama, kita semua membuat kesalahan dan lebih mudah dan lebih sedikit kesalahan cenderung menggunakan alat khusus untuk tugas tertentu. Kedua, ada kendala sumber daya. Waktu kami terbatas, dan menulis halaman web di pertemuan akan memakan waktu lama untuk selesai.

Pengalaman saya dengan sistem besar adalah bahwa mereka berdiri atau jatuh bukan karena pilihan bahasa, tetapi oleh masalah desain / arsitektur atau cakupan pengujian . Saya lebih suka memiliki tim Python yang berbakat di proyek perusahaan besar saya, daripada yang Jawa biasa-biasa saja.

Karena itu, bahasa apa pun yang memungkinkan Anda menulis kode secara signifikan lebih sedikit , harus diperhatikan (mis. Python vs Java). Mungkin masa depan adalah bahasa yang cerdas, diketik secara statis dengan inferensi jenis tingkat lanjut (misalnya dalam cetakan Scala). Atau hibrida, seperti C # yang mencoba dengan dynamickualifikasinya ...?

Dan jangan lupa manfaat mengetik statis "lainnya": penyelesaian kode / intellisense IDE yang tepat, yang menurut saya adalah fitur penting, bukan fitur yang bagus untuk dimiliki.

Pertimbangan lain adalah siapa di balik penulisan aplikasi skala besar. Saya telah bekerja di banyak tempat yang ingin menggunakan Ruby atau Python pada beberapa proyek gaya perusahaan besar, tetapi secara konsisten "ditembak jatuh" oleh manajer TI dan tim keamanan perusahaan justru karena sifat open source dari proyek tersebut.

Saya telah diberi tahu, "Kita tidak dapat menggunakan Ruby on Rails karena itu open source dan seseorang dapat meretas di sana yang mencuri informasi penting atau dilindungi." Maaf, tetapi begitu seseorang memiliki pola pikir bahwa open source == jahat, hampir tidak mungkin untuk mengubahnya. Garis pemikiran itu adalah penyakit korporat.

C # dan Java dipercaya bahasa dengan dipercaya platform. Ruby dan Python bukan bahasa tepercaya.