Jika suatu bahasa berubah dengan cepat, apakah ini dianggap sebagai hal yang baik?

Saya telah melihat beberapa bahasa yang berubah dengan cepat (maksud saya mereka ditingkatkan setiap tahun misalnya) dan beberapa yang lainnya ditingkatkan secara perlahan.

Pertanyaan saya, apakah suatu bahasa berubah dengan cepat apakah ini hal yang baik atau buruk bagi programmer? Apakah programmer suka mempelajari hal baru dalam bahasa atau mereka lebih suka tetap dengan apa yang sudah mereka ketahui?

jika suatu bahasa berubah dengan cepat apakah ini hal yang baik atau buruk bagi programmer?

Baik

• Perubahan mungkin menambahkan beberapa gula sintaksis bagus membuat kode di masa depan lebih mudah untuk ditulis dengan bug lebih sedikit
• Perubahan dapat menstandarkan idiom / pola desain umum yang harus diterapkan oleh programmer atau bergantung pada pihak ke-3.
• Perubahan tersebut dapat membuatnya lebih mudah untuk diintegrasikan dengan teknologi yang biasanya digunakan bahasa tersebut
• Perubahan dapat membantu mencegah kesalahan umum
• Perubahan dapat mencela atau menghilangkan praktik pemrograman berbahaya
• Perubahan mungkin memiliki tambahan yang berguna untuk perpustakaan standar bahasa untuk hal-hal yang saya harus laksanakan sendiri atau mengandalkan pihak ke-3 untuk.

Buruk

• Bahasa telah menambah kerumitan - fitur baru mungkin tidak selalu cocok dengan fitur lawas (yaitu hubungan C ++ dengan C)
• Kode lama mungkin kedaluwarsa dan tidak lagi berfungsi dalam versi baru bahasa tanpa pembaruan (Python 2.x -> 3.x)
• Kompiler dan alat lain untuk bahasa perlu diperbarui. Sekarang berpotensi ada beberapa versi.
• Perpustakaan pihak ke-3 mungkin tidak mendukung versi bahasa yang lebih baru
• Meskipun ada standar, mungkin butuh waktu untuk menemukan standar / cara normal untuk mengimplementasikan fitur baru dan mendefinisikan beberapa kasus perilaku mereka yang lebih tidak jelas.

Apakah programmer suka mempelajari hal baru dalam bahasa atau mereka lebih suka tetap dengan apa yang sudah mereka ketahui?

Banyak programmer senang memuaskan keingintahuan mereka dengan bermain dengan fitur-fitur baru. Namun ini tidak berarti bahwa fitur baru selalu sesuai dalam kode produksi. Ini adalah keputusan kasus per kasus yang harus mempertimbangkan manfaat dari fitur baru vs biaya upgrade dalam situasi spesifik seseorang.

Saya mungkin bersenang-senang atau menikmati belajar tentang fitur-fitur baru, tetapi pada akhirnya yang benar-benar saya pedulikan adalah memberikan produk yang bermanfaat kepada seseorang. Saya harus memilih toolset yang akan menjadi cukup modern untuk memiliki dukungan dan stabilitas yang masuk akal tetapi tidak terlalu kuno sehingga saya tidak bisa cukup produktif.

Perbaikan sangat bagus ... jika mereka kompatibel ke belakang .

C # melakukan ini dengan baik. Mereka menambahkan hal-hal ekspresi lamdba, dukungan yang lebih baik untuk multithreading, LINQ, ... Tapi program C # 2.0 lima tahun Anda masih akan bekerja dengan baik tanpa perlu perubahan dan dapat dengan mudah ditingkatkan ke C # 4.0 tanpa perlu perubahan.

Mempelajari hal-hal baru itu bagus jika memungkinkan Anda melakukan tugas-tugas Anda dengan cara yang lebih mudah, lebih cepat. Jika menghabiskan satu jam belajar berarti menghemat waktu Anda dalam waktu pengembangan, itu sangat berharga.

Saya ingin perbaikan reguler, tetapi saya tidak ingin itu memecahkan basis kode 500 kloc & memicu "proyek peningkatan" besar-besaran hanya untuk membuat kode bekerja seperti yang dilakukannya dengan versi sebelumnya.

Stabilitas bahasa adalah suatu keharusan bagi bisnis dan untuk pengembang. Perubahan bahasa disambut jika mereka memecahkan masalah atau memperkenalkan fitur yang tidak terjawab dalam rilis sebelumnya, tetapi mengubah bahasa sehingga trendi atau hanya karena Anda ingin mengejar ketinggalan dengan pesaing tidak begitu baik.

Ketika bahasa stabil, seiring waktu, pengembang berhenti memfokuskan upaya mempelajari bahasa karena mereka akan menguasainya dan mulai memfokuskan upaya mereka pada melayani bisnis dengan apa yang mereka ketahui. Hasilnya adalah proyek yang lebih singkat, pengguna akhir yang senang dan pengembang yang lebih bangga!

Perubahan juga disertai dengan biaya dan waktu belajar. Tidak semua pengusaha bersedia mendidik pengembang dalam fitur baru. Ini menambah beban yang signifikan pada pengembang untuk melatih diri mereka sendiri atau yang lain - Ini tidak sepele, kursus khusus dapat masing-masing $ 1500- $ 3500!

Perubahan berkelanjutan dapat mengunci pengembang di perangkat lunak 'lawas'. Ambil kasus pengembang ASP yang tidak menangkap dengan MVVM dalam 2 tahun dari sekarang atau kasus pengembang Windows Forms yang tidak belajar WPF. Penguncian ini dapat merusak karier pengembang secara signifikan.

Lembur, arsitektur perangkat lunak dalam bisnis menjadi terlihat seperti salad taman. Semua jenis alat dan versi dan Anda menemukan proyek mulai tidak melakukan apa-apa selain memutakhirkan perangkat lunak dari satu versi ke versi berikutnya tanpa keuntungan bisnis.

Saya tidak berpikir ada satu jawaban yang benar.

Secara umum, ketika suatu bahasa relatif muda, ada lebih banyak kebebasan untuk melakukan perubahan yang relatif besar secara relatif cepat. Tidak ada basis besar kode yang ada untuk dipecah, sehingga orang umumnya jauh lebih terbuka untuk eksperimen.

Seiring bertambahnya usia bahasa, dengan asumsi itu menjadi pengguna yang cukup luas bagi siapa pun untuk benar-benar peduli, basis kode yang ada mulai menempatkan pembatasan yang lebih ketat dan lebih ketat pada perubahan apa yang dapat dilakukan. Tidak hanya ada lebih banyak kode yang menggunakan lebih banyak fitur sehingga lebih sulit untuk menebak perubahan apa yang mungkin merusak kode, tetapi harapan orang berubah.

Sebagai contoh, mari kita asumsikan ada jumlah orang yang menulis Ruby dan Fortran sama. Selanjutnya, mari kita asumsikan ada sekitar jumlah kode yang sama di keduanya. Saya akan mengatakan peluangnya cukup bagus bahwa perubahan yang memecahkan persentase yang persis sama dari masing-masing (dan dengan cara yang membutuhkan pekerjaan yang sama untuk diperbaiki) akan jauh lebih dapat diterima oleh pengguna Ruby daripada pengguna Fortran sebagai aturan umum (setidaknya dengan asumsi mereka melihatnya sebagai peningkatan).

Saya pikir banyak juga tergantung pada persepsi orang tentang bahasa untuk memulai. Orang yang memilih bahasa karena "canggih" jauh lebih mungkin untuk bertahan dengan perubahan besar yang memecahkan banyak kode yang ada, jika itu yang diperlukan untuk tetap berada di ujung tombak.

Faktor lain adalah ukuran dan usia harapan hidup dari proyek yang dimaksudkan untuk bahasa tersebut. Bahasa yang melayani proyek-proyek yang relatif kecil atau yang kita tahu di muka memiliki harapan hidup yang pendek (misalnya, UI web) dapat lolos dengan memecahkan hal-hal yang relatif sering, karena tidak mungkin banyak orang akan terus menggunakan basis kode yang sama untuk, katakanlah, 10 tahun dengan cara apa pun. Bahasa (misalnya, C ++ atau Java) yang melayani lebih banyak untuk proyek-proyek yang lebih besar dan berumur panjang yang mungkin memakan waktu, katakanlah, 5 tahun untuk sampai ke rilis awal, mungkin digunakan secara teratur (dan pengembangan berkelanjutan) selama tiga atau empat dekade jelas menuntut a great stabilitas kesepakatan lebih.

Saya memiliki seorang pria yang mengatakan bahwa dia menyukai C ++ dan itu akan tetap seperti itu. Dia tidak peduli atau tertarik pada D, dia tidak ingin tahu atau menggunakan C #. Dia belajar java karena dia harus ke banyak proyek yang perlu dia lakukan dan dia tampaknya melakukan pekerjaan dengan baik dalam bahasa yang dia tahu

Lain suka C # dan tidak tahu setiap kata kunci atau tahu perpustakaan .NET 4 (async dan semua) dan belum menggunakan kata kunci abstrak atau atribut yang digunakan.

Saya hanya mengatakan kebanyakan orang JANGAN PERAWATAN

Sekarang dari efek peningkatan melanggar (untuk lib atau kode yang dikompilasi) orang AKAN peduli.

Saya akan menjawab untuk C # (tetapi analisis ini juga berlaku untuk Scala):

Perubahan fitur ini menyebabkan beberapa masalah saat Anda mendekati "gaya" bahasa:

Pada 2011, C # dapat melakukan banyak hal berbeda, dan ini bagus. Sayangnya ia memiliki dua paradigma yang berbeda (jika tidak lebih):

• OOP
• Fungsional (pikirkan fungsi lambda dan LINQ)

Berbagai jenis gaya pemeriksaan

• Mengetik Dinamis
• Mengetik Statis

Tidak selalu jelas kapan Anda ingin menggunakan satu atau yang lain.

Saya pikir itu benar-benar tergantung pada bahasa dan mengikuti bahasa yang dimiliki. Sebagai contoh, saya berpikir bahwa jika C # dan Java mulai mengeluarkan perubahan dalam kecepatan yang lebih cepat, maka itu akan diterima (selama mereka kompatibel ke belakang seperti kata Carra ). Namun, jika bahasanya belum mendapatkan daya tarik dan masih berubah dengan cepat, saya tahu saya tidak akan repot-repot dengan itu karena ada kemungkinan apa yang saya coba pelajari hari ini akan sangat berbeda dari apa yang keluar dalam 6 bulan dan karena bahasanya baru / tidak populer itu tidak akan merugikan saya (baca: karier saya) untuk saya sampaikan saja.