Якщо мова швидко змінюється, чи це вважається хорошою справою?

Я бачив деякі мови, які швидко змінюються (я маю на увазі, що вони вдосконалюються щороку), а також деякі інші, які вдосконалюються повільно.

Моє запитання, якщо мова швидко змінюється, це хороша справа чи погана річ для програміста? Чи люблять програмісти вивчати нову річ мовою чи вони вважають за краще дотримуватися того, що вони вже знають?

якщо мова швидко змінюється - це хороша справа чи погана річ для програміста?

Добре

• Зміни можуть додати симпатичний синтатичний цукор, що спрощує запис у майбутньому з меншою кількістю помилок
• Зміни можуть стандартизувати загальну схему ідіоми / дизайну, яку програмістам довелося реалізувати самостійно, або покладатися на третіх сторін.
• Ці зміни можуть полегшити інтеграцію з технологіями, з якими зазвичай використовується мова
• Зміни можуть допомогти запобігти поширеним помилкам
• Ці зміни можуть зневажити або усунути небезпечні практики програмування
• Ці зміни можуть мати корисні доповнення до стандартної бібліотеки мови для речей, які я раніше повинен був реалізовувати або покладатися на третіх сторін.

Поганий

• Мова додала складності - нові функції можуть не завжди добре поєднуватись із застарілими функціями (тобто відношення C ++ до C)
• Старий код може бути застарілим і більше не може працювати в новій версії мови без оновлень (Python 2.x -> 3.x)
• Компілятори та інші інструменти для мови потрібно оновлювати. Зараз існує потенційно кілька версій.
• Сторонні бібліотеки можуть не підтримувати новішу версію мови
• Незважаючи на існування стандарту, може знадобитися час, щоб знайти стандартний / нормальний спосіб впровадження нових функцій та визначити деякі більш незрозумілі випадки їх поведінки

Чи люблять програмісти вивчати нову річ мовою чи вони вважають за краще дотримуватися того, що вони вже знають?

Багато програмістів із задоволенням задовольняють свою цікавість, граючи з новими можливостями. Однак це не означає, що нові функції завжди доречні у виробничому коді. Це індивідуальне рішення, яке повинне зважувати переваги нових функцій та вартість модернізації у конкретній ситуації.

Я можу розважитися або насолоджуватися ознайомленням з новими можливостями, але наприкінці дня те, що мені дуже цікаво, - це доставити корисний товар комусь. Я повинен вибрати набір інструментів, який буде досить сучасним, щоб мати розумну підтримку та стабільність, але не настільки старовинний, що я не можу бути досить продуктивним.

Покращення чудові ... якщо вони сумісні з зворотним ходом .

C # робить це чудово. Вони додають виразів lamdba, кращу підтримку багатопотокових, linq, ... Але ваша п'ятирічна програма C # 2.0 все одно буде працювати чудово, не потребуючи жодних змін, і її можна легко оновити до C # 4.0, не потребуючи жодних змін.

Вивчення нових речей - це чудово, якщо це дозволяє виконувати завдання легшим та швидшим способом. Якщо витратити годину на навчання означає економію ваших годин на час розвитку, то це того варто.

Я хочу регулярні вдосконалення, але я не хочу, щоб він порушив кодову базу в 500 клоків і запустив масштабний "проект оновлення" лише для того, щоб код працював так, як це робиться з попередньою версією.

Мовна стабільність є необхідною для бізнесу та для розробників. Зміни мови вітаються, якщо вони вирішують проблеми або вводять функції, які були пропущені в попередніх випусках, але змінити мову так, щоб це було модно або просто тому, що ви хочете наздогнати конкурента - це не так добре.

Коли мова є стабільною, з часом розробники припиняють зосереджувати зусилля на вивченні мови, оскільки вони її засвоїли б і почали зосереджувати зусилля на обслуговуванні бізнесу тим, що вони знають. Результат - коротший проект, щасливі кінцеві користувачі та більш горді розробники!

Зміна також пов'язана з витратами та часом на навчання. Не всі роботодавці готові навчати розробників у нових функціях. Це додає значного навантаження розробникам навчати себе чи ще - Це не банально, спеціалізовані курси можуть становити від 1500 до 3500 доларів кожен!

Постійні зміни можуть заблокувати розробників у "застарілому" програмному забезпеченні. Візьмемо випадок розробника ASP, який не піймав MVVM через 2 роки, або ж розробника Windows Forms, який не вивчив WPF. Це блокування може істотно зашкодити кар'єрі розробника.

Понаднормово, архітектура програмного забезпечення в бізнесі стає схожою на садовий салат. Всілякі інструменти та версії, і ви виявляєте, що проекти починають робити нічого, окрім оновлення програмного забезпечення з однієї версії на іншу, не маючи жодного успіху в бізнесі.

Я не думаю, що є одна відповідь, яка є правильною.

Взагалі кажучи, коли мова є відносно молодою, існує набагато більше свободи відносно великих змін порівняно швидко. Існує не велика база існуючого коду, яку можна зламати, тому люди, як правило, набагато відкритіші до експериментів.

З віком мови, якщо припустити, що він стає достатньо широким користувачем, щоб когось по-справжньому не хвилювало, база існуючого коду починає встановлювати більш жорсткі обмеження щодо можливих змін. Мало того, що в коді використовується більше функцій, тому складніше здогадатися, які зміни можуть порушити код, але й очікування людей змінюються.

Наприклад, припустимо, що приблизно однакова кількість людей писала Рубі та Фортран. Крім того, припустимо, що в обох кодах було приблизно однакове. Я б сказав, що шанси досить хороші, що зміна, яка порушила точно такий же відсоток від кожного (і таким чином, щоб виправити приблизно таку саму роботу), буде набагато більш прийнятною для користувачів Ruby, ніж користувачів Fortran, як загальне правило (принаймні припускаючи, що вони бачили це як покращення).

Я думаю, що багато що також залежить від сприйняття людьми мови для початку. Люди, які обирають мову, тому що це "передній край", набагато більше шансів на те, що вони зміняться з серйозними змінами, які порушують багато існуючого коду, якщо саме це потрібно, щоб утримати його на передовій.

Ще один фактор - це розмір і тривалість життя проектів, для яких мова призначена. Мова, яка задовольняє відносно невеликі проекти чи ті, які ми знаємо наперед, має коротку тривалість життя (наприклад, веб-інтерфейс), може вникнути зламування речей порівняно часто, тому що навряд чи багато людей продовжують використовувати ту саму базу коду бо, скажімо, 10 років будь-яким способом. Мова (наприклад, C ++ або Java), яка більше задовольняє більш масштабні, триваліші проекти, які можуть зайняти, скажімо, 5 років, щоб дістатись до початкового випуску, можливо, будуть регулярно використовуватися (і постійно розвиватися) протягом трьох-чотирьох десятиліть, очевидно, вимагають великий набагато більше стабільності.

У мене хлопець сказав мені, що йому подобається його C ++, і він залишиться таким. Він не дбає і не цікавиться D, він не хоче знати і не використовувати C #. Він навчився Java, тому що він мав для багатьох проектів, які йому потрібно було зробити, і він, мабуть, добре справляється з мов, які він знає

Інший любить C # і не знає кожного ключового слова чи не знає бібліотеки .NET 4 (асинхронізація та всі) і не використовував абстрактні ключові слова або використовувані атрибути.

Я просто кажу, що більшість людей не доглядають

Тепер наслідки оновлення руйнуються (для libs або скомпільованого коду) люди будуть Дбати.

Я відповім за C # (але цей аналіз може бути застосований і до Scala):

Ця зміна функції викликає деякі проблеми, коли ви наближаєтесь до "стилю" мови:

У 2011 році C # може зробити багато різних справ, і це добре. На жаль, у нього є дві різні парадигми (якщо не більше):

• ООП
• Функціональний (подумайте про лямбда-функції та LINQ)

Різні стилі перевірки типів

• Динамічне введення тексту
• Статичне введення тексту

Не завжди зрозуміло, коли ви хочете використовувати те чи інше.

Я думаю, що це справді залежить від мови та наступних мов. Наприклад, я думаю, що якщо C # і Java почнуть вискакувати зміни більш швидкими темпами, це буде прийнято (до тих пір, поки вони будуть сумісні назад, як сказала Карра ). Однак, якщо мова ще не набрала тяги, і вона все ще швидко змінюється, я знаю, що я б не переймався цим, оскільки є шанс, що я намагаюся сьогодні вивчити, буде абсолютно іншим, ніж те, що виходить через 6 місяців і оскільки мова є новою / непопулярною, для мене це не зашкодить (читайте: моя кар'єра), щоб я просто передавав її.