Memilih Bahasa Pemrograman Secara sistematis [ditutup]

Saya mencari metodologi untuk memilih bahasa. Saya tidak meminta pendapat tentang bahasa. Saya telah diberi tugas untuk membandingkan bahasa toko kami saat ini dengan bahasa lain yang tersedia. Kami adalah toko pengembangan web btw.

CEO kami ingin laporan lengkap tentang semua bahasa berbasis web yang tersedia, Bahasa induk apa yang merupakan turunannya (mis. Jsp berasal dari java yang berasal dari c / c ++). Saya perlu membuat matriks dengan semua faktor kunci dari bahasa tertentu juga dan kedatangan singkat dari bahasa yang diberikan. Apakah bahasa dibatasi oleh platform, apakah ia dirancang untuk pemrograman fungsional, prosedural atau OO atau dapatkah digunakan dengan paradigma pemrograman apa pun?

Saya juga perlu memiliki informasi yang kurang teknis, seperti ukuran kumpulan talenta untuk bahasa tertentu dan gaji median di kumpulan itu. Bagaimana pasar melihat pilihan kita?

Kami mulai mencari konsultan untuk membantu kami memahami semua hal ini tetapi apa yang kami temukan adalah bahwa sebagian besar konsultan berasal dari latar belakang pembangunan dan sering kali jawabannya adalah " xxx adalah bahasa terbaik karena itu adalah bahasa yang saya gunakan." telah menggunakan paling banyak selama n tahun terakhir dan tidak pernah mengecewakan saya. Anda bisa menambahkannya dengan yyy untuk front end dan menggunakan perpustakaan zzz "

Saya merasa kewalahan dengan tugas ini dan saya merasa seperti tindakan terbaik, mengingat apa yang dicari CEO kami, adalah mencari di dunia akademis dan mempekerjakan seorang profesor tanpa pengalaman pengembangan aktual untuk masuk dan "mengajar" kami tentang semua bahasa yang memungkinkan.

Adakah orang lain yang harus menjalani latihan ini? Jika sudah, bisakah Anda membagikan langkah-langkah dan / atau metodologi yang Anda gunakan untuk menjalani proses tersebut?

@FrustratedWithFormsDesigner mengisyaratkan ini di atas, saya akan lebih tumpul: Anda telah dibebankan tugas yang mahal tapi tidak berguna.

Saya menduga CEO sedang mencari bukti objektif yang tak terbantahkan yang akan mendukung pilihan bahasanya. Masalahnya adalah bahwa preferensi bahasa dimuat dengan terlalu banyak faktor subyektif dan ekstrinsik untuk kertas putih menjadi bermakna apalagi berguna.

Dengan kata lain, jika ada bahasa yang ideal, semua orang akan menggunakannya alih-alih bahasa yang cacat "secara objektif". Ini juga menunjukkan tingkat manajemen mikro yang seharusnya menjadi provinsi para insinyur yang harus membuatnya bekerja. Erlang mungkin menjadi "yang terbaik secara objektif" tetapi jika tidak ada yang mengetahuinya, tambahkan 6 bulan / insinyur memulai biaya dan 6 bulan lagi / insinyur untuk mendapatkan kompetensi.

Karena saya tidak memiliki pekerjaan Anda, saya tidak khawatir kehilangan itu, meskipun Anda mungkin. Saya akan memberikan CEO sebuah makalah tentang Tesis Turing Gereja Fisik. Saya kemudian akan bertemu dengan para insinyur senior dan mendapatkan pendapat mereka yang tidak ketat dan tidak objektif tentang apa yang harus digunakan dan memberi tahu CEO bahwa itulah yang akan Anda gunakan. Sebagai gantinya Anda akan berjanji para insinyur akan keluar dari rapat dewan, CFO, Metode Akuntansi, pemilihan VP dan sebagainya. Ada alasan kami berspesialisasi, dan ia tidak memiliki tempat lebih banyak dalam preferensi teknik daripada yang Anda lakukan di domainnya.

Beberapa sapuan kuas yang luas untuk dipertimbangkan:

Popularitas bahasa

Ini seharusnya tidak menjadi masalah, karena popularitas tidak selalu menyamakan dengan produktivitas, ekspresif atau kualitas bahasa lainnya yang lebih penting, tetapi pertimbangan ini sering mengalahkan semua pertimbangan lain karena:

1. Lebih mudah menemukan pengembang perangkat lunak dalam bahasa populer.
2. Lebih mudah untuk menemukan alat dan perpustakaan dalam bahasa yang populer.
3. Pembuat keputusan tidak mengerti pertukaran bahasa, jadi mereka akan membuat keputusan yang aman ("banyak perusahaan menggunakan bahasa ini, jadi pasti bagus").

Penerapan pada domain masalah

Setiap program dapat ditulis dalam bahasa pemrograman Turing-complete, tetapi beberapa bahasa lebih cocok untuk domain masalah tertentu daripada yang lain. Jika Anda menulis aplikasi web, Anda mungkin akan tertarik ke bahasa dan alat yang sangat cocok untuk itu, dan kemungkinan besar akan bahasa berorientasi objek.

Di sisi lain, jika Anda akan menulis perangkat lunak yang terutama berbasis penelitian atau berbasis matematika, Anda mungkin akan tertarik pada bahasa yang merangkul paradigma fungsional .

Dan, tentu saja, ada segalanya di antaranya. Banyak bahasa mendukung banyak paradigma, dan beberapa pola perangkat lunak ada hanya untuk mengatasi keterbatasan dalam bahasa yang tidak memiliki fitur atau paradigma tertentu.

Keekspresifan dan produktivitas

Beberapa bahasa lebih ekspresif daripada yang lain. Apa yang dapat ditulis dalam satu bahasa menggunakan seribu baris kode dapat ditulis dalam bahasa yang lebih ekspresif menggunakan seratus baris kode. Imbalannya adalah bahwa seratus baris kode mungkin ditulis dalam bahasa yang kurang populer, oleh orang-orang dengan keahlian yang lebih besar.

Banyak baris kode hadir dalam bahasa berorientasi objek yang digunakan untuk menulis aplikasi lini bisnis adalah upacara. Upacara ini, meski menghabiskan waktu dan upaya untuk berkembang, juga menyediakan struktur yang terlihat yang tidak akan mudah terlihat dalam bahasa yang lebih ekspresif. Ini memungkinkan orang dengan keahlian yang lebih sedikit dari yang seharusnya mereka perlu mengerjakan kode dengan jumlah risiko yang berkurang.

Era berbagai bahasa

Saya akan menyimpulkan dengan menyatakan bahwa keinginan untuk memutuskan satu bahasa mungkin merupakan dilema yang salah. Aplikasi saat ini sering ditulis, bukan dalam satu, tetapi dalam banyak bahasa. Setiap bahasa memiliki kekuatannya sendiri, dan (secara teori) dirancang khusus untuk tugas yang sedang digunakan. Beberapa domain masalah (seperti logika peramban web atau akses basis data) memerlukan bahasa tertentu.

Ada alasan bisnis untuk memilih bahasa, dan ada alasan teknis untuk memilih bahasa, dan keduanya tidak selalu bertemu. Melempar dengan alasan akademis kemungkinan akan memperburuk keadaan. Saya ragu seorang profesor akan dapat membantu Anda dengan cara yang Anda butuhkan.

Fakta-fakta tentang leluhur dan fitur bahasa cukup mudah ditemukan. Anda mungkin bisa menghabiskan satu hari di wikipedia untuk mengisi sebagian besar dari itu. Ukuran talenta dan gaji lebih sulit, karena kebanyakan orang tidak menganggap diri mereka pemrogram tunggal. Perusahaan yang menggunakan bahasa yang kurang populer seperti Scala berharap dapat mempekerjakan programmer umum yang baik yang tidak memiliki pengalaman spesifik bahasa. Menilai dari beberapa presentasi yang saya lihat, strategi itu tampaknya berhasil dengan baik.

Bahkan mengetahui fakta masih membuat Anda memiliki pilihan yang cukup subjektif. CEO Anda akan menginginkannya dirubah menjadi metrik kasar seperti dolar per fitur. Untuk mendapatkan gambaran yang akurat, Anda harus melakukan beberapa prototipe, kemudian berbicara tentang betapa mudahnya untuk belajar, seberapa cepat menulis prototipe setelah Anda mempelajari dasar-dasarnya, betapa mudahnya Anda berpikir untuk mempertahankannya , dan seberapa luas Anda menerapkannya pada jenis pekerjaan yang biasanya Anda lakukan.

Daripada mencoba untuk mencakup semua bahasa, saya akan berusaha untuk mendapatkan perwakilan dari paradigma pemrograman yang berbeda dan jenis kerangka kerja, dan mengimplementasikan prototipe di masing-masing.

Berikut adalah daftar kasar dari kategori back end:

• Microsoft (Mungkin memiliki subkategori. Saya tidak tahu tentang mereka.)
• OOP kelas berat, seperti Drupal.
• OOP ringan, seperti botol python.
• Mainkan / angkat / skalatra menggunakan Scala.
• Mainkan / angkat menggunakan Java.
• Seperti musim semi.
• Seperti struts.
• Seperti rel.
• Berbasis Haskell.
• Node.js

Di ujung depan:

• JavaScript bergaya OOP
• JavaScript gaya fungsional, seperti dengan Garis Bawah
• JavaScript gaya reaktif, seperti dengan Bacon
• Google Web Toolkit
• Elm

Menghabiskan satu atau dua hari di setiap kategori, menerapkan prototipe sederhana, akan membawa Anda beberapa bulan, setelah itu Anda akan memiliki gagasan yang jauh lebih baik tentang kekuatan dan kelemahan masing-masing. Mungkin Anda bisa mengesampingkan beberapa lebih cepat berdasarkan budaya atau pengalaman perusahaan Anda.

Karena ini adalah laporan bisnis, saya juga akan meluangkan waktu mencari hal-hal seperti "Bahasa apa yang digunakan <perusahaan>," menggantikan berbagai perusahaan yang Anda kagumi. Banyak dari mereka telah menulis whitepaper sendiri tentang mengapa mereka membuat pilihan bahasa tertentu, yang akan membuat referensi yang sangat baik untuk Anda sertakan.

Identifikasi dan biaya kelemahan yang melekat pada proses pengembangan yang ada sebagai $ A. Identifikasi biaya untuk beralih ke proses pengembangan lainnya sebagai $ B.

Jika $ A kurang dari $ B, hentikan.

Jika kekurangan Anda diketahui lebih besar daripada biaya perubahan (dan itu adalah besar jika!) Kemudian menganalisis kekurangan secara rinci dan mulai mencari perubahan lingkungan bahasa / pengembangan / proses pengembangan yang mengatasinya, salah satu yang tidak akan memperkenalkan masalah lain yang lebih mahal.

Sejujurnya, kecuali jika Anda saat ini mencoba mengembangkan aplikasi web di Fortran, maka satu-satunya dampak bahasa yang Anda gunakan adalah pada biaya kontraktor yang Anda gunakan untuk mengisi kesenjangan. Aliran utama dan proses / alat / proses pengembangan dewasa telah menyelesaikan sebagian besar masalah yang mungkin Anda hadapi di mana sebagai alat terpanas, terbaru dan terseksi datang dengan pelatih dan kontraktor paling mahal, tetapi solusi yang paling tidak matang. Dan jika Anda memiliki kekurangan yang memerlukan perubahan seperti itu, kecil kemungkinan pilihan bahasa Anda akan mengatasinya sepenuhnya.

Namun, jika profitabilitas bukan tujuan utama di sini, maka Anda perlu mempertimbangkan stigma dianggap kuno terhadap pujian sebagai yang terdepan. Minta atasan Anda untuk nilai dolar yang digunakan untuk bagian persamaan ini.