Мови, які ми втратили
Кріс Касперски
Позаду
нас залишилося ціле кладовище мов, не прижилися парадигм, вимерлих
концепцій, ідей, що випередили свій час. Для майбутнього не залишилося нічого. Все,
що тільки можна було придумати, - вже придумано, реалізовано, випробувано і ...
Викинуто на звалище через непотрібність. Епоха великих відкриттів давно пройшла, і
нам залишилося лише мавпувати, рухаючись від золотого століття в деградуючих темряву
жахливих лінгвістичних рішень. Назад вороття немає. А все тому, що ...
Мова
визначає мислення, а мислення формує мову, в результаті чого мова починає
стрімко розвиватися, набуваючи нових, раніше не властиві йому риси, не
тільки що дозволяють програмісту висловлювати інженерну думку у всій її повноті,
але і породжують зовсім нові думки, що випливають з властивостей мови.
Поява
абстрактних типів змінних (що не мають прямого машинного втілення)-досить
наочний тому приклад. Програмісти кам'яної ери, висікали програми долотом
(долотом в прямому розумінні-на перфокартах), мислили в конкретній
площини-включити мотор дисковода, прочитати сектор, покласти дані в клітинку
розмірів в N-слів "у пам'яті за адресою Р. .. Сучасні мови
відійшли від заліза і мислять категоріями абстрактних концепцій, дозволяючи
порівнювати змінні А і В, один з яких представляє файл на диску, а
інша-мережевий локатор. Добре це чи погано?! Все набагато гірше, ніж ви
Вам здається. Абстрактне мислення смертоносних, бо провокує програміста
на вирішення завдання в загальному вигляді на сто тисяч рядків вихідного коду, в той час
як приватна рішення (що відповідає ТЗ) вклалося б і в десяток. Але це ще не
найстрашніше, істина в тому, що ...
Явище Сі + + народу
Мова
Сі + + (а разом з ним і його численні «спадкоємці») вже давно не є
об'єктно-орієнтованою мовою та доеволюціоніровал до метапрограмування,
більш відомого як програмування з використанням шаблонів (хоча шаблони --
всього лише один із засобів його реалізації). Кінцева мета
метапрограмування-створення програм, що створюють інші програми як
результат своєї роботи, тобто, іншими словами, мова престаєт бути сутністю,
повністю підпорядкованої авторського задуму, і набуває певної
самостійність, значно спрощує рішення поставленого завдання, але
разом з тим вносить велику частку невизначеності та некерованості.
Наприклад, замість того, щоб писати десяток функцій, порівнюють змінні
різних типів, досить запрограмувати один-єдиний шаблон. Правда,
тут же виникає питання: а як він себе поведе, якщо йому «згодувати» нечислових
змінні? Відповідь-шаблон взагалі нічого не знає ні про типи, ні про розмірностях.
Він просто звертається до методів відповідних класів, які можуть бути
реалізовані як завгодно або ж не реалізовані зовсім, і тоді програма дасть
збій. До тих пір поки використовувалися тільки статичні абстрактні типи,
«Перекладаємо» на машинне подання ще на стадії компіляції,
транслятор легко відловлювали подібні помилки, але з появою динамічних
типів, що обробляються в реальному часі, мова стала взагалі неконтрольованим і
програми почали падати в випадкове час.
І
адже ніхто не винен! Програміст, який реалізує шаблон, тут, природно, не
причому, адже він написав, щось на кшталт: IF (a> b) THEN RETURN A; ELSE RETURN
В, переклавши реалізацію процедури порівняння на розробників класів, яким,
можливо, і в голову не могло прийти, що їх класи комусь знадобиться
порівнювати. Взяти хоча б клас shape, який реалізує різні геометричні
фігури: відрізки, кола. трикутники ... Чи можна порівнювати два примірники
класу shape один з одним? А чому б і ні! Це може відповідати довжині
відрізків і площами фігур. Але ж ... може і не відповідати! Проблема
об'єктного-і метапрограмування в тому, що абстрагуючись від «непотрібних»
технічних подробиць, вони приховують інформацію про свою поведінку від
програміста. Програміст кам'яної ери, дивлячись на запис А = А + В, міг однозначно
сказати, що вона поверне за будь-яких значеннях А і В (навіть з урахуванням переповнення
змінних). А зараз? Візьмемо дві змінні типу «символ» і спробуємо їх
скласти. Питання: як поведе себе реалізує їх клас? Чи буде він додавати
код одного символу до іншого, оперуючи з ними як з цілочисельними змінними
(поведінка за замовчуванням), або скомбінуйте їх у двохсимвольного рядок? А якщо
взяти екземпляри класу share, то це взагалі кінець визначеності.
Математично можна складати лише відрізки (та й то з тією лише застереженням,
що задано їх напрямок, тобто ми оперуємо з відрізком, як з вектором), але
складання квадрата з трикутником-безглуздо. Зате в графічному аспекті
складання може бути уподібнене накладення, що, до речі кажучи, відразу порушить
комутативність властивість, тобто А + В зовсім не те ж саме, що В + А! От і
спробуй після цього вносити до програми зміни ... У програмістів кам'яної
епохи подібних проблем просто не виникало, оскільки мова не давав можливості
оперувати абстрактними концепціями і в кожній точці програми доводилося
висловлювати закінчену технічну думку. Звичайно, це призводило до дублювання
коду, знижувало наочність лістингу, але зате виключало неоднозначності його
інтерпретації. Якщо абстрагуватися від базових концепцій, ми підсилюємо лексичну
міць мови (там де раніше доводилося писати тисячі команд, зараз досить
одній), але разом з нею збільшуємо кількість взаємодій між різними
компонентами, які як-то потрібно враховувати ... У результаті за здається
легкість програмування доводиться розплачуватися багаторазово збільшеної
складністю проектування. Мова неможливо освоювати послідовно, крок за
кроком, як це було раніше. Якщо на Бейсіку перша програма складалася всього з
одного рядка «PRINT 'hello'», то тепер навіть мінімально працює програма (з
шаблонами, природно) цих рядків налічує десятки! Створюючи новий
екземпляр класу, ми повинні обробити ситуацію з нестачею пам'яті, встановити
обробники винятків (ну або хоча б «заглушки») і завчасно
передбачити реакцію програми на ситуації, які в рамках стародавнього
процедурного програмування просто не виникали. До речі, той, хто вважає,
метапрограмування досягненням останніх десятиліть, - жорстоко помиляється.
Так, у мові Сі + + воно з'явилося зовсім недавно і в повному обсязі (описаному в
останніх редакціях Стандарту) не реалізовано ні в одному реально існуючому
компіляторі, a Nemerle і R # (мови програмування для платформи. Net зі
вбудованою підтримкою метапрограмування)-взагалі немовлята, але насправді
концепція метапрограмування виникла ще за часів палеоліту. Lisp,
що з'явився в далекому 1958 р.,-хороший приклад мови, природним чином підтримує
метапрограмування, одним із завдань якого є створення програми,
виводить точну копію свого власного вихідного тексту-так званий Куин
(англ, quine). На Lisp'e він записується так:
(funcall (lambda (x)
(append x (list (list 'quote x ))))
'(funcall (lambda (x)
(append x (list (list 'quote x ))))))
На Сі
так:
# include
char * i = "tinclude ", n = '
n ', q ="",* p =
«% s% cchar * i =% c% c% s% c, n = '% cn', q = '% c', * p =
% c% c% s% c, * m =% c% c% s% c% c;% s% c ", * m =
«int main () (returnIprintf
(p, i + l, n, q, * i, i, q, * i, q, n, q, p, q, n, q, m, q, n, m, n );}"
; int
main () (return! printf (p, i + l, n, q, * i, i, q, * i, q, n, q, p, q, n, q, m, q, n, m, n );}
Атеперь
спробуйте реалізувати теж саме на Сі + + з використанням шаблонів і
подивіться, наскільки сильно вони вам «допоможуть». Парадигма метапрограмування,
красиво реалізована в Lisp'e, була закинута на півстоліття саме через втрату
керованості мовою, але потім повстала з попелу у жахливій реінкарнації,
що йде своїм корінням в директиви препроцесора мови Сі ... Але це вже зовсім
інша історія.
Мова
Сі + + зробив величезний вплив як на мислення програмістів, так і на розвиток
всіх наступних мов, став стандартом де-факто. Ніхто, звісно, не
говорить, що ООП-і метапрограмування-це погано. Чому обов'язково погано?!
Дуже навіть добре! Місцями. Але ось думка про те, що ООП - єдино
правильний підхід-жахлива. Літаки та космічні кораблі мирно співіснують з
велосипедами і автомобілями. Адже нікому і в голову не прийде літати за
сигаретами на ракеті, особливо якщо сигарети продаються в кіоску на сусідньому
кутку.
Але
це ж неправильно! Поява ракет повинно перевернути наше мислення!
Тому-будуємо кіоск за орбітою Плутона і кожному даємо по ракеті, щоб туди
літати, а пальне купуємо за гроші, виручені від будівництва космодромів і
продаж ракет. Хто не може будувати ракети - нехай вчить інших, як на них
літати. Скільки створюється нових робочих місць і головне, що все в бізнесі. Ось
тут уже справді, повернення в минуле немає ... Сигарети коштують мільярди
доларів, і гроші в індустрію обертаються просто величезні. Хто ж захоче від них
відмовлятися?! Навпаки, ракети будуть стрімко «вдосконалюватися», щоб
за сигаретами можна було літати навіть на Альфу Центавра. Кажете, що це
нелогічно і неможливо? Але ж саме така ситуація склалася з Сі + +. Судіть
самі-реалізація компіляторів мови Сі + + дуже складна і дорога задача, а
сама мова настільки великий і об'ємний, що його вивчення вимагає неймовірних
зусиль. Щоб окупити кошти, вкладені в розробку компіляторів, фірми
змушені «підсаджувати» на нього мільйони програмістів, які, пройшовши
тривалий (і страшенно болісний) шлях навчання Сі + +, просто не можуть
зізнатися собі в тому, що даремно вбили десять років свого життя (даної
людині лише один раз!) і що стоять передніми завдання з анітрохи не меншою
ефективністю реалізуються на чистому Сі та інших процедурних мовах, легко
освоюваних на ходу без відриву від виробництва. Ось вони і починають переконувати
інших, що процедурні мови давно мертві. Складність ради складності.
Втім,
серед цієї темряви є і світлі плями. При прийомі в нормальну фірму за
спробу вирішити завдання із застосуванням шаблонів, там, де вони не потрібні, за
голівці не погладять і програму швидше за все не зарахують. Один з відомих
«Подколов»-написати програму, що виводять суму перших 100 натуральних чисел на
екран, int а, Ь = 0; for (a = 1; a <101; a + +) b + = a; printf ( «% dn», b); - незалік,
printf ( «5050n»)-залік. Ключове слово тут-«виводять», а не «обчислює».
Трохи більше жорстокий варіант-вивід першої сотні простих чисел. Зрозуміло,
суму членів арифметичної прогресії можна обчислити і в розумі, а знайти прості
числа без комп'ютера не те, щоб нереально, просто ... навіщо мучитися, коли
комп'ютер під рукою? Однак, програміст-це перш за все інженер, а інженер
повинен не тільки уважно читати ТЗ, але й обирати адекватні засоби для
рішення задачі. В даному випадку-написати програму, що генерує програму,
виводять прості числа на екран, тобто щось на кшталт: рг::: 1,5,7 ... n »), після
чого першу програму можна сміливо стерти. Дійсно, який сенс
обраховувати одні й ті ж дані при кожному запуску програми, коли це
достатньо зробити всього один раз?! Важливо зрозуміти, що мова-це всього лише
засіб вираження думок. Не варто фетішізіровать його. Розумні думки можна висловити
і в машинному коді (там, де це виправдано), якщо ж думок немає-не допоможе
ніякої мову. Проблема, однак, у тому, що програмування машини (тобто
завдання послідовності операцій, яка вона повинна виконувати) все більше
перетворюється в діалог з нею. Програмісти перестали обдумувати рішення
поставлених завдань далеко від машини. Комп'ютер перетворився в калькулятор, а
програми-в «записки мисливця». Саме тому, коли сучасний програміст
чує «сума ряду», він рефлекторно уявляє собі цикл і машинально тягнеться
до клавіатури ... Він втратив розуміння того, що мова (машинний) тут і поряд не
валявся. Це чисто математична задача, а від машини потрібні лише кошти
введення/виводу для друку результату.
ООП в ретроспективі
Багато
мови, що виникли задовго до появи терміну ООП (наприклад, вже згаданий
Лісп), цілком відповідають його критеріям, можливо, навіть більшою мірою, ніж
«Чистокровні» представники ООП, такі як Сі + + або його прямі попередники
Симула (Simula) і Смолток (Smalltalk), створені в 1967 і 1980
відповідно. До речі, про попередників. Мова Сі + + часто критикують за те,
що звернення до методу класу в ньому реалізовано як виклик функції, в той час
як Симула і Смолток об'єктів дозволяли обмінюватися повідомленнями. Прихильники
Сі + + стверджують, що конкретний спосіб виклику методу класу - внутрішня кухня
мови, прихована від програміста і що посилка повідомлення є окремим випадком
виклику функції, тільки прямий виклик набагато ефективніший в плані накладних
витрат і машинних витрат на такти і оперативну пам'ять.
Всі
це так, але ... Симула і Смолток природним чином підтримують
багатозадачність, багатопоточність і распараллелівают обчислення на рівні мови.
Здійснення повідомлень може бути як синхронної (об'єкт посилає повідомлення і чекає
результату), так і асинхронної (об'єкт посилає повідомлення і продовжує
займатися своїми справами). Це дозволяє транслятору в кооперації з
операційною системою рівномірно розкидати об'єкти по процесорах або навіть по
цілого кластеру. Звичайно, сприяння з боку програміста вкрай бажано
(не всі алгоритми допускають ефективне розпаралелювання), але в будь-якому випадку,
програма, написана на Симула або Смолтоке, автоматично збільшує свою
продуктивність при додаванні нових процесорів.
Прямий
виклик функції, навпаки, завжди синхронний. Звертаючись до методу класу, поточний
код передає йому кермо влади і отримує їх тільки після явного повернення,
який може взагалі ніколи не відбутися! Распараллелівать програму
припадає на етапі її створення, причому, реалізувати динамічний алгоритм,
підтримує довільну кількість процесорів, в загальному випадку неможливо
або вкрай важко, оскільки для цього фактично буде потрібно вручну
реалізувати Симула/Смолток-подібний «движок», натягнувши його поверх Сі + +, витративши
купу зусиль і отримавши у результаті гіршу продуктивність ніж на чистій Симула
(Смолтоке). Аж до теперішнього часу цей недолік Сі + + нікого не
турбував, оскільки багатопроцесорні комп'ютери зустрічалися вкрай рідко, та
і то переважно на серверах, одночасно обробних безліч запитів
від користувачів і розпаралелювання велося саме в цьому напрямку - одна і
Того ж Сі + + код виконувався на декількох процесорах одночасно, кожен
примірник якого обслуговував «свого» користувача і всі були задоволені. Але з
появою багатоядерних процесорів в робочих станціях і домашніх комп'ютерів
програмістам довелося заново вчитися распараллелівать програми, що без
підтримки з боку мови зробити досить важко, так що поява
нових мов (або доробка вже існуючих) в історичній перспективі
неминуча, оскільки кількість процесорних ядер буде тільки збільшуватися,
причому за деякими прогнозами дуже стрімко.
Корисні посилання по темі
Why Pascal is Not My Favorite
Programming Language
Аналітична
стаття Брайна Керігана - одного з творців мови Сі - критикує
недоліки Паскаля, усунуті в Сі, але заново відроджені в Сі + + та його
нащадках (англійською мовою): www.lysator.liu.se/c/bwk-on-pascal.html
433
Examples in 132 (or 162 *) programming languages
Вихідні
коди 433 простих програм ( «hello, world», факторіал, пошук максимуму,
бульбашкова сортування, etc) на 162 різних мовах програмування, як
існуючих, так і давно померлих, - дуже корисна штука для розширення
кругозору (англійською мовою):
www.ntecs.de/old-hp/uu9r/lanq/html/lanq.en.html
List of hello world programs
Тексти програм «hello, world» програм на 190 мовах програмування: http://en.wikibooks.Org/wiki/Transwiki:List
of hello world programs
Еволюція
програмістів і мов програмування (жарт) www.ariel.com.au/iokes/The
Evolution of a Programmer.html
Самомодіфікація в законі
В
Лісп (Lisp) і Форте (Forth), створених у 1958 і 1970 роках відповідно,
самомодіфікація була винесена на рівні мови, що давало змогу реалізовувати
високоефективні програми, побудовані на динамічних алгоритмах.
Унікальною особливістю Форту (не реалізована ні в якому іншому мовою)
була і залишається можливість «чесною», модифікації Форт-машини, то є
безпосередньо самого транслятора, який при бажанні з боку програміста
можна взагалі повністю переписати штатними засобами самої мови!
В
Фортране, Алгол, Паскалі, Сі/Сі + + та інших «хороших і?? азних », клонах (включаючи
Бейсік) самомодіфікація можлива лише теоретично - шляхом варварської редагування
машинного коду в оперативній пам'яті. Чому «варварської».? Та тому, що мова
до цього не має ніякого відношення, більше того, самомодіфікація спирається на
недокументовані можливості мови, закладаючи на логіку конкретних
трансляторів, що загрожує розвалом програми при переході на інший компілятор,
не кажучи вже про те, що машинний код - штука зрозуміла лише невеликому колу
обраних, але навіть Великий Гуру не зможе написати самомодіфіцірующуюся
програму, що працює більш ніж на одному процесорі. Зрештою,
самомодіфікація потрапила в чорний список поганих прийомів програмування, а самі
програми «розпалися», на код і дані, що обробляються цим кодом, інваріантні
по відношенню до самих даних. Іншими словами - один і той же код обробляє
різні дані, що не є правильно. Машина Тьюринга взагалі не мала таких
понять. У ній код був невіддільний від оброблюваних їм даних. Вірніше, що надходять
дані задавали методи їх обробки (природно, в рамках закладених в машину
алгоритмів).
До
щастя, останнім часом зроблено кілька спроб реабілітації
самомодіфікаціі. По-перше, це Java зі своєю віртуальною машиною, байт-код
якої не змінюється від процесора до процесора, а, значить, самомодіфікація НЕ
погіршує переносимість програми (правда, якщо бути чесним, Java не
надає для самомодіфікаціі ніяких мовних засобів і програмісту
доводиться працювати з низькорівневими командами читання/запису пам'яті).
По-друге, Сі + +, Nemerle і RW підтримують (і активно просувають) парадигму
метапрограмування, дозволяючи писати програми, що створюють інші програми,
які в свою чергу створюють третій ... Це, звичайно, не зовсім самомодіфікація,
але щось на неї схоже. Проте, реалізація метапрограмування вкрай
ваговито, логіка і синтаксис - заплутані, складні для розуміння і абсолютно
непрозорі, а можливості істотно поступаються Форту і Лісп. Загалом, муть і
морок.
Вавілонське стовпотворіння
Всякий
раз, коли з'являється черговий нову мову, про який говорять, як про
«Остаточне і безальтернативного», передрікаючи швидку смерть всіх інших,
мені стає смішно.
Сам
по собі мова у відриві від середовища програмування-цікавить мало, та й всі мови
крутяться навколо одного і того ж набору концепцій і парадигм, просто різні
мови змішують цей коктейль в різних комбінаціях. Популярність Сі + +
частково викликана тим, що він увібрав в себе всі існуючі парадигми,
що допускають ефективну реалізацію. Інші мови або неефективні, або
являють собою підмножина Сі + +. Так, є зовсім інші класи мов, у
зокрема логічні мови (яскравим прикладом яких є Prolog), засновані
на виведення нових фактів із закладених в них даних відповідно до встановленої
системі логічних правил, що працює в замкнутому світі фактів. Іншими словами,
якщо визначити об'єкти «вода», «чайник», «газ», «вогонь», то Prolog'y
достатньо дати завдання «закип'ятити воду», щоб він поставив чайник на вогонь.
Але ... наскільки ж повільно він це зробить! І скільки часу піде на
формування «бази знань» про об'єкти навколишнього світу. На відміну від Сі + +,
дотримується парадигм декларативного програмування, що описують процес
обчислення у вигляді інструкцій, що змінюють стан програми, функціональні
мови (найпопулярніший з яких Haskell) не представляють собою
послідовність інструкцій і не мають глобального стану, натомість
вони визначають, що потрібно вираховувати, а як це робити-турбота транслятора. Ось
тільки ефективних трансляторів декларативних мов наполегливо не спостерігається.
На жаль, машина не може мислити, а відповідь на питання «як це зробити?» Припускає
активну творчу діяльність. Таким чином, благополуччя Сі + + нічого не
загрожує. Хоч би скільки мов ні створювалося і які б зусилля не робилися
для просування їх на ринок, ми отримаємо або урізаний варіант Сі + +, або
страшний гальмо. Ні те, ні інше програмістам даром не потрібно. Зрозуміло, це
не означає, що Сі + + - вінець еволюції. Скоріше, це звалище всіх ідей,
демонструють гарну ерудицію його творців, але які порушують цілісність
мови, через що, власне, із завидною регулярністю з'являються «претенденти
на престол », що намагаються відібрати найкращі з конструкцій Сі + +, скомпонував їх у
гармонійний «букет», але ... нові мови приходять і йдуть, а Сі + + вбирає в себе
всі вдалі рішення своїх конкурентів, стаючи цілим світом. І навряд чи
знайдеться хоч один нормальний програміст, який наважиться стверджувати, що він
володіє цим світом у всій його повноті. Максимум на що він може претендувати --
на ту малу частину, яку вміщує розум окремо взятого індивідуума.
***
Висновок або чи є світло в кінці тунелю?
Перші
мови програмування були вкрай простими, вивчалися вони швидко і легко, а
тому при навчанні основна увага приділялась концептуальним поняттями --
архітектурі, алгоритмів і т. д., однак мовні засоби того часу були
недостатньо виразними для запису думок в наочній зрозумілій формі і
код швидко перетворювався в «спагетті», яке було неможливо ні налагоджувати, ні
супроводжувати, ні розвивати. При досягненні певних розмірів програми
буквально «падали» під власною вагою і простіше було переписати їх
заново, ніж додати пару рядків у вже існуючий код, що, природно, не
влаштовувало ні користувачів, ні програмістів. Мови наступних поколінь
зробили якісний ривок уперед, позбувшись багатьох недоліків своїх
попередників, але ... при цьому вони так ускладнилися, що мова з інструменту
для вирішення проблем сам по собі перетворився на проблему, утворивши предметну
область шириною по всі дні. Алгоритми відтіснили на задній план, і вузи
стали випускати молодих людей з кашею в голові і програмують на Сі + + ще
гірше, ніж на Бейсіку-з купою глобальних змінних і десятками класів, там де
і трьох функцій вистачило б з надлишком. .. Програмування ускладнилося так, що
стало долею обраних. З'явилися консультанти з мови (не вміють
програмувати взагалі, але обізнані Стандарт як отче наш, це щось на зразок
мистецтвознавців, не намалював жодної картини, але з розумним видом що думають
про правила композиції, підіймаються та спускаються мажорних і мінорних лініях і т.
д.) При цьому ні Сі + +, ні його послідовники не вирішили поставлених перед ними
проблем. Навпаки, вони відкрили безліч нових можливостей зіпсувати дизайн
програми так, що потім його ніякими засобами вже не виправити. Якщо
програму, написану на процедурному мовою, можна переписувати по частинах,
виправляючи її структуру шляхом декомпозиції, то з Сі + + цей номер так просто не
пройде. Ієрархія класів жорстко задається на етапі проектування та
закладається в програму точно залізобетонний каркас, розширюваний тільки в
одному напрямку - у напрямку нашарування нового коду. У результаті нас
оточують програми-монстри, а програмісти втрачають можливість розуміти одне
одного. Достаток мовних засобів призводить до того, що використання всіх
конструкцій мови одночасно стає важко і невиправдано. Даєш
кожному програмісту по парадигмі! Ну і що з того, що решта ні рядка не
розуміють! Ніхто ж ж і не обіцяв, що програмувати-легко! А чому,
власне, програмувати має бути важко?! Чому ми посилаємося на
авторитети кожного разу, коли відчуваємо себе недостатньо компетентними?! Звідки
взагалі взялася сліпа віра в те, що професійний програміст повинен іти в
ногу з прогресом, освоюючи нові бібліотеки, мови і т. д.? І вже зовсім не
зрозуміло, чому програмування перетворюється на змагання, хто напише саму
незрозумілу програму з використанням новітніх мовних засобів.
Програмування йде по шляху безперервного нарощування складності, і ця гонка
«Озброєнь» нічого хорошого в собі не несе. У світі є тільки одна причина,
здатна підтримувати рух цієї машини-гроші. Програмне забезпечення
неймовірно дорого, і розробникам хочеться, щоб воно було ще дорожче.
Програмувати швидко, красиво й ефективно стає просто невигідно, ось
індустрія і рухається до власного краху величезними стрибками.
Зупинити
цей суїцид дуже просто-достатньо на законодавчому рівні вимагати від
виробників відповідати за свій продукт, виплачуючи неустойку за кожну
критичну помилку. Програмісти миттєво одумаються і викинуть з програми всі
зайві вузли, а що залишилися перепишуть з використанням «легких» мовних засобів,
викинувши «незрозумілі» та «важкі» в топку.
Втім,
процес спрощення мов пішов вже й без того. При всій моїй нелюбові до С #, я
все-таки змушений визнати, що це великий крок вперед, оскільки з нього
викинули купу конструкцій Сі + +, які були занадто складні для рядових
програмістів. У результаті на С # набагато менше шансів написати потворну
програму, і це вселяє надію, що світло в кінці тунелю все-таки є. Або
це всього лише зустрічний? Питання риторичне, а значить, без взаємності.
Список літератури
IT
спец № 07 ЛИПЕНЬ 2007
