Memilih Bahasa Pemrograman Secara sistematis [ditutup]


24

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?


21
Apakah CEO benar-benar berencana untuk menggunakan matriks ini untuk memutuskan hal-hal seperti "Kami akan menggunakan $ {bahasa} untuk membangun $ {nextBigProject}!" Untuk membangun sesuatu yang mungkin benar-benar berguna untuk ini (walaupun saya tidak yakin itu akan sangat berguna) mungkin akan membutuhkan banyak waktu, dan akan ada pemeliharaan yang berkelanjutan untuk itu.
FrustratedWithFormsDesigner

3
Saya pikir panduan umum untuk memilih bahasa / lingkungan untuk suatu proyek mungkin pertama - tama mencoba untuk mendapatkan pemahaman yang lebih dalam tentang masalah spesifik yang coba diselesaikan oleh proyek (dengan cara agnostik bahasa), mencari alat / perpustakaan yang bantuan terbaik menyelesaikannya pada waktu itu , lalu lihat bahasa apa yang perlu Anda ketahui untuk bekerja dengan alat / pustaka tersebut. Itu mungkin akan memberi Anda daftar bahasa, dan dari sana Anda dapat menampiknya berdasarkan keakraban Anda dengan mereka, dukungan vendor, anggaran, dll ...
FrustratedWithFormsDesigner

9
The pertama pertanyaan dengan jawaban adalah, "kita perlu perubahan sama sekali?" Masalah apa yang tidak terpecahkan oleh pilihan bahasa Anda saat ini?
John Bode

4
Bagaimana Stack Overflow dapat membantu pengembang mengevaluasi teknologi? "Pagi ini saya memiliki sekitar 8 kerangka kerja di depan saya, mencoba untuk memutuskan mana yang akan saya gunakan ..."
Agas

7
Dalam praktiknya Anda mungkin juga melempar panah. Di arena web (terutama JavaScript, dkk) ada lusinan (jika bukan ratusan) opsi, dengan berbagai macam kekuatan, kelemahan, afinitas, dan ketidakcocokan. Anda dapat menganalisisnya sampai mati, atau hanya membuat tebakan yang berpendidikan, maju, dan melakukan koreksi di tengah jalan jika diperlukan.
Daniel R Hicks

Jawaban:


53

@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.


6
Ha, saya suka antusiasme yang sembrono dari paragraf terakhir. Saya akan mengatakan itu adalah domain CEO karena 6 bulan sial yang Anda sebutkan, itulah yang Anda butuhkan untuk memberitahunya.
Nathan Cooper

1
"Tesis Gereja-Turing Fisik" Jangan pergi ke sana. Sangat sedikit bahasa pemrograman yang memiliki semantik formal, cukup banyak prasyarat untuk itu agar Turing lengkap. (Tanpa satu, itu bahkan bukan model perhitungan.)
Rhymoid

4
Cukup pilih Lisp dan selesai dengan itu.
Eric

1
By Lisp, maksud Anda ClojureScript tentu saja. :-)
Brian Knoblauch

1
+1. Adalah tugas Anda sebagai insinyur untuk menyampaikan kepada CEO mengapa ini bukan pendekatan yang baik. Ini mungkin sulit karena sepertinya pendekatan yang bagus, tetapi itu perlu.
djechlin

25

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.


7
Saya akan menambahkan ke poin terakhir bahwa jika Anda ingin menggunakan beberapa bahasa, mungkin berguna untuk mempertimbangkan platform yang mendukung interoperasi yang mudah di antara mereka (.Net CLR atau JVM).
svick

9
@NathanCooper: Maksud Anda, Anda belum pernah menulis aplikasi web? Bahkan yang kecil? Atau haruskah port aplikasi seluler ke berbagai platform? Atau bekerja di embedded? Atau mengambil data dari database SQL?
Robert Harvey

10
@ NPSF3000: Secara alami, Anda tidak repot-repot mengungkapkan metode sihir Anda. Saya menyebutnya shenanigans.
Robert Harvey

9
@ NPSF3000 Sementara C # mungkin merupakan pilihan yang baik untuk apa yang Anda lakukan (meskipun menggunakan Unity tentu merentangkan banyak hal karena itu dirancang secara eksplisit untuk mereka melakukan semua pengangkatan berat multi-bahasa untuk Anda), anekdot Anda tidak membantah intinya. Tentu saja sebagian besar proyek non-sepele adalah multi-bahasa dalam arti bahwa mereka menggunakan SQL dan teknologi lain, tetapi bahkan lebih dari itu, banyak menggunakan bahasa pemrograman yang berbeda secara paralel, atau menulis aplikasi mereka dalam satu bahasa dan alat-alat mereka dalam bahasa lain, dll. tidak menemukan pernyataan yang kontroversial sama sekali.
Chris Hayes

7
@ NPSF3000 Jika itu masalah Anda dengan itu, maka katakan itu . Jangan membuat kita melalui kesulitan mencoba untuk mencari tahu apa yang Anda maksud. Saya yakin Robert akan senang melakukan pengeditan jika Anda telah menyatakan "Saya tidak setuju bahwa beberapa domain bermasalah memerlukan bahasa tertentu". Yang mengatakan, saya tidak melihat implikasi sama sekali di sini bahwa bekerja dalam berbagai bahasa adalah "menguntungkan secara default".
Chris Hayes

5

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.


4

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.

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.