З днем народження, Эдсгер Вібе Дейкстраǃ

«Нехай тахорги в страху виють,
Видаючи вереск і писк!
Адже на них йде війною
Структуральнейший лінгвіст!»


image

  • Дуже жорсткий правдоруб.
  • Міг би стати фізиком-теоретиком (як Річард Фейнман, який теж народився 11 травня), але вибрав неіснуючої на той момент професію — програміст.
  • Носить ім'я алгоритму пошуку найкоротшого шляху. Алгоритм був створений при вирішенні железячной завдання Про знаходження оптимального шляху передачі електричного струму усіх істотних елементів ланцюга, мінімізуючи при цьому витрата міді».
  • Непримиренний ворог goto.
  • Ініціатор мема Considered harmful. «GOTO Statement Considered Harmful», "„GOTO Considered Harmful“ Considered Harmful", «„«GOTO Considered Harmful» Considered Harmful“ Considered Harmful?»
  • Автор концепції семафора.
  • Розробник операційної системи THETechnische Hogeschool Eindhoven).
  • Стояв біля витоків структурного програмування, розподілених обчислень.
  • Не написав жодної статті на комп'ютері.
У звичайному житті Е. В. Дейкстра був диваком: волів просту ручку комп'ютера, в його домі не було телевізора, він не користувався мобільним телефоном, не дивився кіно. Коли його колеги підготували і видали до 60-річного ювілею спеціальний збірник, Дейкстра відповів кожному з них особистим подячним листом, написаним від руки (61 адресат). Вченому його рівня і положення покладався секретар, але Дейкстра відмовився від цього привілею і все волів робити сам. Любив музику і був хорошим піаністом.

Під катом кілька цитат Дейкстри, пара скорочених есе і список статей російською мовою.
(Разом з компанією EDISON вітаємо Декстру і Фейнмана з днем народження.)

image

Цитати



У графі «професія» анкети, яку необхідно заповнювати при реєстрації шлюбу, він написав «програміст» — його змусили переписувати документи, заявивши, що такої професії не існує. У результаті, як писав Дейкстра: «Хочете — вірте, хочете — ні, але в графі «професія» мого свідоцтва про шлюб значиться забавна запис «фізик-теоретик»!».

«… мені треба було зробити вибір – або припинити програмувати і стати справжнім респектабельним теоретичним фізиком, або як формально завершити моє навчання теоретичної фізики з мінімальними зусиллями і стати… ким же? Програмістом? Але хіба це респектабельна професія? Врешті-решт, що таке програмування? У чому повинен був складатися той солідний обсяг знань, який дозволив би вважати програмування науковою дисципліною?»

Коли радянський уряд ухвалив рішення про перехід радянської промисловості до копіювання модельного ряду IBM/360, Дейкстра (який в той час працював в конкурировавшей з IBM фірмі Burroughs) назвав це рішення найбільшою перемогою Заходу в холодній війні, а обрану для клонування модель IBM/360 (прообраз радянської ЄС ЕОМ) — найбільшою диверсією Заходу проти СРСР.

«Якщо налагодження — процес видалення помилок, то програмування повинно бути процесом їх внесення.»

«Студентів, раніше вивчали Бейсік, практично неможливо навчити доброго програмування. Як потенційні програмісти вони зазнали незворотної розумової деградації.»

«Питання «чи вміє комп'ютер думати» має не більше сенсу, ніж питання «чи вміє підводний човен плавати».»

«Проекти, які пропонують програмування на природному мовою, згубні за своєю суттю.»

«Глибоко помиляється той, хто думає, що виробами програмістів є програми, які вони пишуть. Програміст зобов'язаний створювати заслуговують довіри рішення і представляти їх у формі переконливих доводів, а текст написаної програми є лише супровідним матеріалом, до якої ці докази застосовні.»

«Програмування на КОБОЛе калічить мозок, тому навчання повинно трактуватися як злочин.»

«На будь-якій мові можна написати фортрановскую програму.»

«Не винні в тому, що їх безграмотно використовують.»

«Тестування програми може досить ефективно продемонструвати наявність помилок, але безнадійно неадекватно для демонстрації їх відсутності.»

«Ми будемо краще справлятися з нашою роботою програмістів, якщо тільки ми будемо підходити до цієї роботи з повним усвідомленням її жахливою складності, якщо тільки ми будемо вірні скромним і елегантним мов програмування, якщо ми будемо враховувати природну обмеженість людського розуму і братися за цю роботу як Дуже Смиренні Програмісти»

«Різниця між «старою програмою» і «новою програмою» настільки ж сильно, наскільки глибока різниця між гіпотезою і доведеною теоремою або між математичним наглядом і твердженням, суворо виведеним з зводу постулатів."

«Програміст повинен доводити правильність програми одночасно з її написанням.»

image

Статті і книги



Архів робіт Декстры (англійською)

image
«Дисципліна програмування»



image
Колектив авторів «Структурного програмування»: Niklaus Wirth, Edsger W. Dijsktra, Tony and Jill Hoare

image
«Про шкоду оператора Go To»

Лист Дейкстри: чому навчання програмуванню потрібно починати з функціонального мови

Збірка статей в PDF.

  • Програмування як вид людської діяльності.
  • Назустріч коректним програмами.
  • Смиренний програміст.
  • Два погляди на програмування.
  • Чому програмне забезпечення таке дороге?
  • Про природу інформатики.
  • Наукова фантастика і наукова реальність в інформатиці.
  • Чому американська інформатика здається невиліковною.
  • Кінець Інформатики.
  • Відповіді на запитання студентів відділення програмного забезпечення.


image

Два есе, скорочені переклади яких вдалося знайти в мережі
«Я розповідав цю історію різним людям. Програмістам, як правило, вона подобалася, а їх начальники зазвичай сердилися все більше і більше по мірі її розвитку. Справжні математики, однак, не могли зрозуміти, в чому сіль.»
ПритчаВ незапам'ятні часи була організована залізнична компанія. Один з її керівників (ймовірно, комерційний директор) виявив, що можна заощадити багато грошей, якщо постачати туалетом не кожен залізничний вагон, а лише половину з них. Так і вирішено було зробити.

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

Щоб виправити становище, кожен вагон забезпечили написом, що говорить, чи є в ньому туалет, і сцепщикам було наказано складати поїзда так, щоб близько половини вагонів мали туалети. Хоча це і ускладнило роботу сцепщиков, незабаром вони з гордістю повідомили, що ретельно виконують нову інструкцію.

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

Але проблема на цьому не скінчилася. Оскільки туалети розташовуються в одному з кінців вагону, відстань між двома сусідніми туалетами в поїзді могло досягати трьох довжин вагонів і для пасажирів з дітьми, особливо якщо коридори були заставлені багажем — це було занадто далеко. Тоді вагони з туалетами були забезпечені стрілкою, і видано нові інструкції, розпорядчі, щоб всі стрілки були спрямовані в одну сторону. Не можна сказати, щоб ці інструкції були зустрінуті на сортувальних станціях з ентузіазмом — кількість поворотних кіл було недостатнім, але, напружившись, зчіплювачі навчилися робити і це.

Тепер, коли всі туалети знаходилися на рівних відстанях, компанія була впевнена в успіху, однак пасажири продовжували турбуватися: хоча до найближчого туалету було не більше одного вагона, але не було ясно, з якого боку він знаходиться. Щоб вирішити цю проблему, всередині вагонів були намальовані стрілки з написом «ТУАЛЕТ», зробили необхідним правильно орієнтувати і вагони без туалетів.

На сортувальних станціях нова інструкція викликала шок: зробити потрібне вчасно було неможливим. В критичний момент хтось, чиє ім'я зараз неможливо встановити, зауважив наступне. Якщо ми сцепим вагон з туалетом і без оного так, щоб туалет був посередині, і ніколи їх не будемо розчіплювати, то сортувальна станція буде мати справу замість N орієнтованих об'єктів з N/2 об'єктами, які можна у всіх відносинах і з усіх точок зору вважати симетричними. Це спостереження вирішило проблему ціною двох поступок. По-перше, поїзди могли тепер складатися лише з парного числа вагонів — відсутні вагони могли бути оплачені за рахунок економії від скорочення кількості туалетів, і, по-друге, туалети були розташовані на трохи нерівних відстанях. Але кого турбує зайвий метр?

Хоча в часи, до яких відноситься наша історія, людство не знало ЕОМ, невідомий, знайшов це рішення, був першим у світі компетентним програмістом.

Джерело


«Але, побратими, я запитую вас: хіба це чесно? Не підриває наше тривале мовчання єдності інформатики? Пристойно чи зберігати мовчання? Якщо ні, то як про це говорити?»
Як бути, якщо правда коле очіІноді ми виявляємо неприємні істини. І коли це відбувається, потрапляємо в скрутне становище, оскільки приховати їх — наукова нечесність, сказати ж правду — значить викликати вогонь на себе. Якщо ці істини достатньо неприйнятні, то ваші слухачі психологічно нездатні прийняти їх і ви будете ославлены як абсолютно позбавлений здорового глузду, небезпечно революційний, дурний, підступний чи ще якоюсь там людина. (Не кажучи вже про те, що, наполягаючи на таких істини, ви забезпечите собі непопулярність у багатьох колах і взагалі не обійдетеся без персонального ризику. Згадайте Галілео Галілея...)

Інформатика (computer science) виглядає важко хворий від такого протиріччя. В цілому вона зберігає мовчання і прагне уникнути конфлікту, перемикаючи увагу на інше (наприклад, щодо Коболу ви можете боротися з хворобою, або робити вигляд, що її не існує: багато факультети інформатики вибирають другий, більш простий шлях). Але, побратими, я запитую вас: хіба це чесно? Не підриває наше тривале мовчання єдності інформатики? Пристойно чи зберігати мовчання? Якщо ні, то як про це говорити?

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

Програмування — одна з найбільш важких галузей прикладної математики: слабким (poor) математикам краще залишатися чистими (pure) математиками.

Науково-технічні розрахунки — найпростіше застосування обчислювальної техніки.

Кошти, які ми застосовуємо, надають глибоке (і тонке) вплив на наші способи мислення і, отже, на нашу здатність мислити.

Фортран — «дитяче розлад» з двадцятирічним стажем — безнадійно неадекватний якого б то ні було застосування ЕОМ сьогодні: він занадто незграбний, занадто небезпечний і занадто дорогий, щоб його застосовувати.

ПЛ/1 — «фатальна хвороба» — належить скоріше до області проблем, ніж до області рішень.

Практично неможливо навчити добре програмувати студентів, орієнтованих спочатку на БЕЙСІК: як потенційні програмісти вони розумово затуркані без надії на зцілення.

Використання Коболу калічить розум. Його викладання, отже, повинно розглядатися як кримінальний злочин.

АПЛ — помилка, доведена до досконалості. Це мова майбутнього для программистской техніки минулого: він відкриває нову еру для любителів кодування.

Проблеми управління в цілому і базами даних зокрема надзвичайно складні для людей, які думають на суміші «ЄС-івського з нижегородським» (буквальний переклад: в термінах фірми IBM, змішаних з неохайним англійською).

Про використання мови: неможливо заточити олівець тупою сокирою. Настільки ж марно намагатися зробити це десятком тупих сокир.

Крім математичних здібностей, життєво важливою якістю програміста є виключно добре володіння рідною мовою.

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

Ні наукова дисципліна, ні міцна професія не можуть бути засновані на технічних помилках міністерства оборони і виробників ЕОМ.

Використання антропоморфної термінології стосовно обчислювальних систем — ознака професійної незрілості.

Проголошуючи себе працюючими в області програмного забезпечення (software), слабкі (soft) вчені роблять себе ще більш смішними (але не менш небезпечними). Всупереч своїй назві, software (буквально: м'яке обладнання) вимагає [жорстоко] твердої наукової дисципліни для своєї підтримки.

У старі добрі часи фізики повторювали досліди один одного, щоб бути впевненими в результатах. Зараз вони дотримуються Фортрану, переймаючи один в одного програми з помилками.

Проекти, що пропонують програмування на природному мовою, згубні за своєю суттю.

Хіба не достатній цей список, щоб дати привід для занепокоєння? Але що ми збираємося робити? Ймовірно, зайнятися повсякденними справами…

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

Джерело


Відео







P.S.

Пропоную бажаючим взяти участь у міні-флешмобі з перекладу цитат Дейкстри (цитати звідси або звідси).

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.