Як готувати системних програмістів

Терехов Андрій Миколайович, професор, завідувач кафедрою системного програмування математико-механічного факультету СПбГУ

Професійним викладачем Університету я став майже випадково. У принципі, я читав спецкурси, будучи ще студентом мат-хутра, керував дипломними роботами, 9 людина захистило кандидатські дисертації під моїм керівництвом, але все це було швидше фоновою, ніж основний. Ще в молоді роки я почав керувати лабораторією системного програмування НДІ математики і механіки мат-хутра, і був цілком задоволений цією роботою. Але питання про те, щоб забезпечити приплив нових молодих фахівців, у мене не виникало. Ми займаємося наукою, трохи допомагаємо у підготовці студентів, отримуємо молодих фахівців, і все. Коли поїхав працювати до Франції зав. кафедрою мат. забезпечення ЕОМ А.О. Слісенко (зараз він завідує кафедрою в університеті Париж-12), наш декан вирішив, що я буду гарною кандидатурою на цю посаду. Організували збори кафедри, попросили мене розповісти про свою програму. Вона була дуже коротка, всього з двох пунктів. Перша теза: кожен викладач має бути спочатку дослідником, а вже потім викладачем. Я готовий пробачити деякі недоробки, але не готовий пробачити начотництво, коли викладач сьогодні шанує книжку, а завтра розповість. Треба, щоб викладачі в основному розповідали про свої роботи або про ті, в яких вони брали участь. І друга теза була в тому, що треба відповідати міжнародним програмам. Кожні два роки друкуються стандарти, ми відслідковували ці стандарти з 1992 року.

За кожним з цих тез була моя позиція вистраждана. Не люблю я "начотчиків". Страждав від таких викладачів, коли сам навчався, і, природно, не хочу підтримувати їх зараз. А щодо міжнародних стандартів бували жахливі історії. Саме так хочу сказати - жахливі.

Наприклад, ми по родом своєї діяльності багато контактували з групою молодих людей з Академмістечка, з Новосибірська, які під керівництвом доктора наук Котова робили нову машину, "Кронос". А ми в цей час робили свою машину, "Самсон", тому дуже цікаво було поговорити, поспілкуватися, обмінятися результатами, і хлопці справили на мене незабутнє враження. Вони часто приїжджали до нас, жили у мене вдома. Багатьох з них я добре пам'ятаю сих пір. Двоє з них наприкінці 80-х років пробували вступити до аспірантури американського університету. У них була дуже потужна підтримка. Керівником їх лабораторії був А. Марчук, а його батько був президентом Академії наук. Тому співробітники А. Марчука мали додаткові можливості, отримували доступ до матеріалів, пов'язаних з аспірантурою в Америці, яких молодші наукові співробітники інших організацій не мали. Коротше кажучи, вони надходили в аспірантуру в американському університеті. Вони обоє були дуже розумними, я мріяв би мати таких працівників. І не надійшли. Не тому що погано говорять по-англійському або з якоїсь ще формальної причини. Вони просто на половину питань не знали відповідей.

На мене це приголомшуючий справило враження, тому що я звик думати, що ми, за Принаймні в галузі програмування, "попереду планети всієї". У деяких областях це дійсно так. В області техніки трансляції, в області теоретичних питань програмування, теорії оптимізації. Але виявилося, що програмування за цей час розрослося, і ми у своїх роботах, в основному на оборону, дуже багато аспектів просто упустили. І в 1992 році, за моїми підрахунками, ми не накривали навіть 40% міжнародного стандарту за фахом computer science and software engineering. Тому я і сказав співробітникам кафедри, що нема чого спочивати на лаврах, засучівать рукави і займайтеся, будемо наздоганяти світову цивілізацію. На що отримав абсолютно негативну реакцію: не треба перебільшувати, наша кафедра підготувала таких хороших фахівців, та й ти закінчив цю кафедру, що тобі ще треба?

Наш декан, Г.А. Леонов, молодий, енергійний чоловік, вирішив, що він це так не залишить, і вирішив створити ще одну кафедру. Була маса проблем, були дискусії на Вченій Раді, що мат-хутро і так скорочується, а тут вводять нову кафедру ... Коротше, були неприємні і навіть болючі ситуації, але великий дипломат Леонов все подолав, змусив мене написати купу паперів, і в результаті сформувалася нова кафедра. Моєї заслуги в цьому майже що і немає. Я всього лише запропонував декілька ідей.

Так 6 років тому я став завідувачем кафедри системного програмування. Я почав чесно втілювати власну ж програму, розвивати дослідження, яких у нас раніше не було. Думаю, що зараз ми накриваємо відсотків 80 міжнародного стандарту, але не можу обіцяти, що скоро ми накриємо всі 100%. Дійсно, світова наука розвивається стрімкими темпами, і в дуже різноманітних напрямках. Початкові мені дали 3,5 ставки, але в перший же рік на кафедрі працював 21 чоловік. Тобто працювали співробітники нашого підприємства, практично завжди безкоштовно, і аргумент мій був тільки один: якщо вам потрібні молоді співробітники, якщо вам потрібен зворотний зв'язок - вперед, в аудиторії!

Ми домоглися певних успіхів, 3 роки тому у нас був такий незабутній епізод, коли закінчував кафедру один з перших випусків, 12 чоловік, і всі 12 отримали червоні дипломи. Причому без всяких "натягування", вони самі цього домоглися.

Саме співробітники нашої кафедри керують командами нашого Університету на міжнародних змаганнях. Ми двічі стали чемпіонами, але для мене ще важливіше, що протягом 5 років поспіль ми були в призовий "десятці" з 2500 команд. Помітна стабільність результату. Я вважаю, що кафедра системного програмування, незважаючи на свою молодість, розвивається досить успішно.

У даний момент я хочу зосередитися не на успіхах (я чітко розумію - сьогодні є успіх, а завтра тебе ніхто не згадає), а на проблемах, які заважають нам розвиватися далі. Їх кілька, і я не знаю, чи зумію я зв'язно про них розповісти в цьому інтерв'ю. Але спробую.

Почну я, як не дивно це, можливо, з боку здається, з практики. Студенти повинні мати практику. Програмування - це така спеціальність, якої не навчиш у дошки з крейдою в руках. Для того, щоб краще зрозуміти можливі шляхи організації практики, подумки перенесемося до Оксфордського університету, де мені доводилося читати лекції, і я спеціально вивчав місцеву постановку освіти. Звичайно, там іноді віддає деякої "замшілість", але, тим не менше, співробітники університету свято дотримуються традиції і з великим небажанням розлучаються з чимось старим. Іноді їм це можна поставити в мінус. Наприклад, зараз Оксфордський університет дещо відстав у галузі природничих наук від Кембриджу, і фахівці кажуть, що одна з причин цього в тому, що в Оксфорді на 60 років пізніше скасували обов'язкове навчання латині. У Кембриджі скасували у 20-х роках, а в Оксфорді тільки в 80-х. І ці 60 років багатьох молодих людей відлякувала необхідність вчити мертва мова тільки тому, що так робили 800 років тому.

Але зазвичай вірність традиціям гідна поваги. Наприклад, в Оксфорді для кожного предмета є теоретичний курс, тобто лекції, практичний курс, коли викладач зі студентами вирішує завдання в аудиторії, біля дошки, біля комп'ютера, але при цьому стоїть поруч, і практикум - з кожного курсу студент повинен виконати деяку роботу самостійно. Причому не раз на півроку, як наша курсова робота, один на весь семестр, а з кожного предмета кожні два тижні. Є величезні аудиторії, сотні вільних обчислювальних машин. Приходиш, сідаєш, вирішуєш, і потім свій результат показуєш тьютор. Це ще одна особливість -- персональне навчання. По кожному предмету годину на тиждень студент працює з своїм тьютором - таким викладачем, який за нього відповідає. Було п'ять предметів на тиждень - значить, п'ять часов студент з викладачами проведе один на один. Причому тьютор складає основу викладання. Саме тьютор веде вступні іспити, саме тьютор відбирає собі студентів, а не коледж або університет в цілому. Саме тьютор може сказати своєму колезі: "Знаєш, я вже набрав собі потрібну кількість студентів, є ще такий-то студент, візьми його собі в інший коледж ".

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

У нас з цим слабкіше. Курсові роботи - раз на семестр, і часто перетворюються на фікцію. І важко змінити цю ситуацію на краще, тому що немає відповідних матеріальних ресурсів. Як зобов'язати всіх студентів з кожного предмета зробити самостійну роботу, якщо ми не можемо їм забезпечити повноцінний доступ до обчислювальних машин? Класи завжди перевантажені. Так, щоб студент, займався без викладача, у нас не прийнято. Обов'язково подумають, що і вірус занесуть, і що-небудь вкрадуть, і що-небудь зламають. Самостійну роботу дуже важко налагодити. Про тьюторстве я просто не мрію. Це перш за все питання грошей. У нас, напевно, знайшлося б багато хороших викладачів, але для того, щоб забезпечити індивідуальне навчання - скільки треба викладачів і яке буде потрібно фінансування? Хоча ще з середніх віків відомо, що навчання - це завжди робота майстра з підмайстром з безпосередньою передачею досвіду. Так що єдина "жива" практика в нас - на п'ятому курсі, піврічна переддипломна практика. І тут теж є свої проблеми. Добре, якщо практика була, якщо ми говоримо про програмування, певною фірмі, яка успішно і продуктивно на сучасному технологічному рівні займається програмуванням. Але так буває не завжди.

Перша теза -- сьогодні треба практику реально поєднати з теорією. Формально кажучи, все у нас є. П'ятий курс півроку проходить переддипломну практику. І чим це закінчується? Ось у мене товста пачка звітів з практики (шелест паперу). Люди просто пристроюються працювати (наприклад, програмістами) в якусь маловідому контору, частіше за все я навіть назви такого не знаю. Вони працюють. З одного сторони, які можуть бути претензії? Людина півроку пропрацював, отримував гроші, кому-то був корисний. Питаю, чи я, завкафедри: "Чого ти там навчився? "." Ось, отримав практичний досвід програмування на Java або C + + "." Як була організована робота? "." Ніяк. Начальник дав завдання, я написав програму "." Як був організований колектив? Які були стосунки? Як велося планування, звітність? Чи були щотижневі зборів? Чи була регулярна перевірка якості? Чи були перехресні читання? "." Не було "." То чого ти, милий, там навчився? "." Програмуванню "." Чому тоді треба говорити, що ти закінчуєш мат-мех факультет найстарішого університету Росії? ". Тут явна невідповідність теорії і практики.

Наведу приклад з іншого боку. У нас декілька чоловік проходив практику у закордонній фірмі тут, в Санкт-Петербурзі. У цій фірмі все добре організовано, але є інша крайність: скрізь завіса секретності. Навіть якщо дипломну роботу написав там, її в Університеті захистити не можна. Треба захищати у фірмі, організовувати ДЕК. Це ціла проблема. Гаразд, врешті-решт, навіть на військових працювали, могли всі організувати. Але ж людина відривається від колективу, нічого не може обговорити. Найголовніше в навчанні - це бесіда, розмова. А тут кілька чоловік проходять практику, і навіть зі своїми однокурсниками не спілкуються. Заборонено. Зовсім інша крайність. Дуже високий рівень роботи, але дуже індивідуальний. Люди з цієї фірми, можливо, скажуть, що я не прав, що у них є і семінари, і регулярне навчання. Але я кажу про те, що бачу за результатами роботи наших студентів.

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

І ще раз повторю, оскільки для мене ця теза важливий, що практика - це не просто робота "від паркана до обіду", переробив готову програму або спаяний електронну схему. Практика має на увазі деяке дослідження, навчання організаційних форм, сучасним методам. Практика повинна бути різноманітною. Наприклад, електронщик повинен не тільки спаяти, а й спроектувати схему, спроектувати кристали, які всередині. Він повинен брати участь у налагодженні, і не просто брати участь, а зробити тестове оточення. Електронники повинні програмувати. Це все тісно пов'язано.

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

Теза друга -- чому вчимо? Ось переді мною лежить програма 35.15. За цією програмою навчається відділення інформатики математико-механічного факультету. Ми із співробітниками нашої кафедри брали участь у її розробці. Для порівняння скажу: у нас відділення прикладної математики навчається по 01.02. Мат. статистика, моделювання, теоретична кібернетика - це все чудово. В дипломі написано: "Математик. Системний програміст". Я прошу авторів це програми: "Покажіть, де тут програмування". На першому курсі вчать програмуванню мовою С, і все. Я ж не кажу, що в програму включили зайвий матеріал. Всі потрібні речі: і моделювання треба, і кібернетику треба, і розпізнавання образів, і питання оптимізації. Але навіщо пишуть в дипломі "Системний програміст"? Ось я завідую кафедрою системного програмування. Сподіваюся, що я знаю, що таке системне програмування. Давайте я теж буду вчити програмування, а писати в дипломі "спеціаліст за методом Монте-Карло ". Кому це сподобається? Звичайно, всі розуміють, що треба залучити людей, звучить назва спеціальності добре, але не зовсім відповідає змісту курсу.

Повернемося до тому, що я дійсно вважаю хорошим. Наприклад, спеціалізації 35.15: математичні основи інформатики, інформаційні системи, технології програмування, архітектури обчислювальних систем, мережі. Далі: експертні системи, теорія оптимізації баз даних, Інтернет та інтранет, інструментальні системи для C + +, Java-технології, інструментальні засоби візуального програмування, інструментальні засоби логічного програмування, технологія трансляції, мови й системи програмування, технологія програмування, архітектура ЕОМ, програмно-апаратні комплекси, операційні системи реального часу, телекомунікації, і так далі.

Ми на кафедрі підрахували годинник цієї програми, все одно 50% - це "чиста математика ". Самий головний недолік навіть не в цьому, а в тому, що та половина часу, яка нам відведена на спеціальність, віднесена на кінець. На перших трьох семестрах - тільки 4 години на тиждень. Уявляєте собі, людина вчинила на відділення інформатики, не на відділення "чистої математики", не на відділення астрономії або механіки. І вчиться півтора року, три семестри, маючи 4 години програмування на тиждень! У самих різних видах, все про все. Как можно його навчити? Найцінніше час іде. Я навіть зустрічався із заступником міністра освіти, обговорював це все у нас в Університеті, в УМО. Сценарій розмови завжди був таким: "На кого скаржитеся, ви ж самі професор, член УМО! От і вносите пропозицію, скоротіть те, додайте це, для чого і створено УМО ". Добре. Коли я тільки намагаюся це робити, мені відразу говорять: "Як? Ти що? На факультеті працюють старі професори, які і тебе вчили мат. аналізу, алгебри, вищої геометрії ... Якщо ти зменшиш навантаження, їх треба буде скорочувати. Невже ти хочеш звільнить?? старих професорів-математиків? "Звичайно, не хочу. Але є правила, встановлені Міністерством, що кількість викладачів пов'язано з кількістю студентів. Якщо число студентів зменшилося, відповідно зменшується кількість викладачів. Тобто така проста річ, як перерозподіл годин, вже стикається з міністерськими правилами, і ніякої Університет, ніяке УМО змінити це не може.

У нашій програмі є федеральний компонент, вузівський компонент (регіональний) і по вибором. Федеральний компонент: математичний аналіз, 4 семестру, кількість годин на тиждень: 8, 4, 6, 6. Алгебра та теорія чисел, три семестри, годинники: 4, 4, 4. Геометрія і топологія, три семестри, годинники: 4, 4, 4. Диференціальні рівняння, два семестри, по 4 години. Функціональний аналіз, один семестр, 4 години. Коли я був студентом, було два семестри. Рівняння мат. фізики: одна семестр, але 6 годин. Теорія ймовірностей і математична статистика: дві семестру, 7 годин.

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

Є обчислювальний практикум, три семестри по 2 години, і є програмування, три семестру, 3, 2, 2 години. А тут повинні бути общепрофессіональние дисципліни (федеральний компонент): архітектура обчислювальних систем комп'ютерної мережі, операційна система оболонки, структура алгоритму комп'ютерної обробки даних, бази даних і СУБД, комп'ютерне моделювання, комп'ютерна графіка, теорія формальних мов і трансляцій, спецкурси за вибором, спецсемінари. Але проти всього цього - порожні клітини.

Далі, розглянемо третій курс (п'ятий-шостий семестр). Десять годин на тиждень. Как можно навчити студентів? І лише на 4-5 курсі починають вчити "по спеціальності ". Але на п'ятому курсі вже переддипломна практика, там тільки спецкурси, і то потрошку. Тобто ми можемо навчати практично тільки четвертий курс. Хіба так можна? Ось де проблема. Причому не можу сказати, що в мене є рішення.

Теза третя -- необхідність теорії. Один мій колишній однокурсник зараз професор Західно-Берлінського технічного університету. Я бував у нього, і він у нас побував кілька разів. Я одного разу його запитав, чого навчають у них в університеті. З'ясувалося, що вивчають і логіку, і все інше, але тільки формулювання теорем. Я його запитав: "Скажи чесно, якщо я зараз піду до краю якомусь вашому студенту і запитаю, що таке теорема Геделя про неповноту, він відповість? "" Ні, - каже, - навіть не згадає "." Тоді навіщо так вчити? "-" Ну, належить. А навіщо вам теорема Геделя? " "Хоча б для того, - кажу, - щоб молодий спеціаліст мав уявлення про межі застосовності. Теорема Геделя говорить про те, що коректність арифметики не перевірити засобами самої арифметики, і дає теоретичні обмеження, що треба шукати якісь метатеоріі, залучати додаткові можливості. Якщо людина про це навіть не підозрює, він буде в якихось місцях даремно витрачати час. У мене був випадок, коли один випускник кафедри мат. фізики, що працює у нас, повинен був реалізувати аналіз потоків даних у програмі. Він досить швидко все реалізував. Сама потужна машина тоді була 486-я, і він на ній 4 часа тест з 20 рядків ганяв. Я подивився програму -- простий перебір шляхів у графі. Я його питаю: "Ти хіба не знаєш, що число шляхів у графі зростає експоненціально щодо числа вершин? "-- "Не знаю. Подумаєш, експонента! Машина залізна, все порахує". Я йому довго читав лекцію про актуальну нескінченність, про те, що якщо в програмуванні бачиш експоненту, то треба шукати інше рішення. Це не означає, що треба здаватися. Я часто студентам наводжу такий приклад. На конференції, присвяченій 1000-річчю алгоритму, в Ургенчі (на батьківщині Аль-Хорезмі), була представлена стаття Ю.В. Матіясевіча "Що нам робити з експоненціально складними завданнями? "Це мені подобається, це конструктивний підхід. Не просто "Все, здаюсь, більше нічого зробити не можемо". Завжди можна знайти окремі випадки. Є й інша протилежність "теоретичного" сприйняття завдання. Інший не менш відомий учений мене мучив, коли я здавав кандидатський мінімум: Що є теорема Геделя про неповноту? І змушував мене на іспиті (за два тижні до захисту дисертації!) визнати, що з цього випливає, що машина не все може. Але це не так! Ні загального підходу - знайдемо приватні.

Наприклад, знаєте, на чому заснована шифрация? Зводять завдання до якої-небудь важкою (наприклад, розкладання числа на множники). Мої колеги, практики, зробили систему шифрування. Популярна система, продається добре. Вони мене попросили показати кому-небудь з колег - наскільки їхня робота теоретично обгрунтована. Я попросив Ю.В. Матіясевіча подивитися їх статті. Він хвилин 10 дивився, відразу вказує мені фразу: "Оскільки ніякого іншого способу обчислити, крім як простий перебір, ні, це трудноразрешимая завдання ". Мені навіть образливо стало, що сам не роздивився. Раптом знайдеться якийсь інший метод, який для даного конкретного класу задач знайде гарний алгоритм? Тоді все це розсиплеться як картковий будиночок. Можливо, такого методу і не знайдеться, але математика відрізняється тим, що все треба доводити. Вони не довели, що іншого методу, крім прямого перебору, немає. Я трохи в бік пішов від основної теми, але ніякого протиріччя в порівнянні з тим, що я почав говорити, немає.

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

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

Все-таки це знання становить меншу частину нашої професії, 5-10%. Просто є речі, які треба знати. Якщо ти їх взагалі не знаєш, можеш налетіти на такі граблі, що лоб собі расшібешь.

"Нам потрібні НЕ прилади в принципі, а прилади в корпусі ". Давайте, все-таки, поговоримо про програмування. Я багато разів читав лекції в Гамбурзі, і в Класичному університеті, і в Технічному університеті, там навіть поговорити про програмуванні часто не з ким. Дві крайнощі: або "коробочнікі", які вміють користуватися стандартними програмами, або теоретики, які займаються чимось таким, що невідомо коли на практиці здійсниться. А людей, що займаються нормальним програмуванням, часто і не зустріти.

Я наведу ще один приклад. Приблизно в 1975 році ми отримали першу ЄС ЕОМ 1030 серед цивільних організацій СРСР, про це навіть у газетах писали. Перші ЄС ЕОМ йшли тільки на оборону. І ось ленінградський мат-мех отримав за рахунок того, що ми робили багато програм для ЄС ЕОМ, саму першу машину. Приклад полягає в наступному. Машина часто ламалася, а ми сиділи вечорами, ночами. Робити було нічого, всі теми були обговорені, весь чай випитий. І ось я почав одну дівчину-оператора вчити своєму улюбленому мові АЛГОЛ-68. Такий складний мова програмування, і рідко який студент міг його освоїти в повному обсязі. Але часу було багато, дівчина була симпатична, треба було про щось говорити. І за тривалий час, кілька місяців, я навчив її так, що не кожен студент міг з нею зрівнятися. Кажу їй: "Тепер тобі треба переходити працювати програмістом. І зарплата вище, і робота цікава. Адже що таке робота оператора? Поставить диск, завантажити машину ". І тут я з жахом зрозумів, що вона не знає, що програмувати. Вона не знає, як можна Ітеративний обчислити квадратний корінь, вона не знає, як влаштований транслятор. Вона знає мову програмування, іспит здати може, а програмувати не може. На мене цей епізод справив дуже сильне враження.

Минуло 25 років, начебто багато що змінилося. Але подивіться, ми з вами тут сидимо, кожні 10 хвилин двері відкриваються. Кожен третій приходить з питанням: "Андрій Миколайович, я хочу у Вас працювати. Я чув, що у Вас багато людей займається цікавою роботою "." Дуже добре, що ти знаєш? "" Я вмію програмувати на Паскалі "." А що ти знаєш-то? "." Ну як, я ж навчусь "." Подивись на список спецкурсів кафедри. Що з цього ти знаєш? "." Нічого "." І як ти будеш працювати? Я тебе визначу до групи "Телефонія". Ти знаєш, що як влаштовано? Що ти там будеш програмувати? Ти вмієш писати a: = b, a: = b + c, але ж це не програмування. Треба знати, що програмувати ".

Результатом таких розмов може бути одне з двох. Хтось все життя мене після цього ненавидить за те, що він хотів займатися цікавою справою, а злобний Терехов на нього відро холодної води вилив, а бувають такі уперті, які кажуть: "Нічого, я навчуся". Добре, перші три місяці стажування, і якщо з'ясується, що людина працювати не може, йому просто ввічливо скажуть: "Вибач, друже, нам треба рухатися далі". Це не означає, що людина пропаде, може бути, він до іншої групи потрапить. Буває, що люди з третьою спроби своє місце знаходять. Буває так, що людина навчиться в процесі роботи, але це швидше виняток, ніж правило. Правда, це обходиться великими зусиллями, ніж у студента в процесі навчання, але зате закріплення зовсім інше, і мотивація інша.

Отже, третій теза була приблизно такий. Між собою взаємопов'язані практика, межі між теорією і практикою, межі застосування теорії, деякі особисті знання. Студент вчив теорію, навчав, куди не треба ходити, але я не хочу, щоб це перетворювалося в основу науки. Я вважаю, що все-таки основа науки в тому, як треба робити. Я пояснюю своїм студентам, що системний програміст - це сфера обслуговування. Ми не робимо кінцевих продуктів. Наприклад, людина виробляє розрахунки. У нього є якийсь результат. При цьому він користується трансляторами, операційними системами, обчислювальними машинами, які придумали інші люди. І системщики - саме ті люди, які роблять транслятори, інструментальні засоби, розробляють методології щодо їх використання. А потім вже прикладні програмісти цими коштами і методологіями користуються і отримують кінцевий результат. Дуже часто, до речі, люди бачать тільки кінцевий результат, особливо коли йдеться про розподіл грошей, і зовсім не бачать тієї дороги, тих труднощів, які були витрачені, щоб цей результат одержати. Системне програмування - це досить стара назва. По-русски ми добре знаємо, що таке системне програмування. Але були проблеми, як перекласти це словосполучення на англійську мову. Є наука computer science, вона більше теоретична. А є наука software engineering. Ось я завідувач кафедрою software engineering. Еngineering - це розробка програмного забезпечення. І мені здається, що це досить чітко зараз визначилося.

Тепер наступна теза, наступна проблема. Ось захищається мій аспірант у нас на Раді. Я сам член Вченої Ради. І щоразу трапляється який-небудь, м'яко сказати, недоброзичливець, який, оскільки на Вченій Раді може виступати хто завгодно, говорить: "Ви знаєте, я не розумію, чому це математика. Ні теорем, немає доказів збіжності, чому ця дисертація захищається на математичному факультеті? "У реальній дійсності найкращу відповідь - Сказати: "Ви нічого не розумієте в цій області". Часи, коли математика була тільки в теореми, скінчилися, як мінімум, 100 років тому, а, може бути, і більше. У середині XIX століття Ч. Беббідж придумав обчислювальну машину, в якій були всі основні елементи (процесор, пам'ять, програма, що зберігається в пам'яті). Дочка Байрона, Ада серпня леді Лавлейс, пятістранічний доповідь на італійській мові цього Ч. Беббіджа перетворила у 100-сторінковий англійський текст, де вперше ввела слова "Переадресація", "Процедура", "Цикл" - це що, не математика? Це було зроблено більше 150 років тому. Була розроблена нова модель.

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

Чому виникли потреби в суворої формалізації? Тому що прийшло розуміння того, що деякі завдання в принципі не можна вирішити, потрібна була алгоритмічна формалізація, і за допомогою цих формальних методів вдалося довести нерозв'язність декількох проблем. Перші такі докази були коректно отримані в 30-х роках XX століття. Чому це, коли я довів, що цього немає і бути не може, це математика, а коли я побудував формальну модель і по ній зробив алгоритм, який працює - це вже не математика? Ніхто не сказав, що тільки негативні результати є математичними. У нашій країні такий консерватизм особливо сильний. Коли в 1953 році з'явилася БЕСМ, відразу з'явилися дисертації, наприклад, такого змісту: "Розрахунок скоса залізничного полотна ". ВАК ухвалила рішення про недопущення до захисту робіт, що носять чисто розрахунковий характер. Це було правильне рішення, але разом з водою виплеснули і дитини. Добре, чистий розрахунок за формулами - це не наука, всі визнають. Але, наприклад, як зробити систему програмування для БЕСМ? Коли БЕСМ-6 з'явилася, в 1966 році, 6 колективів робили операційну систему. І перемогли не самі відомі академіки країни. Я пам'ятаю всі прізвища, але не хотів би їх нагадувати, щоб нікого не образити. Це справді важке завдання.

Межа між "наукою" і "не наукою" в даному випадку достатньо зрозуміла, професіонал її знає, але досить важко формалiзуються,, і тому викликає масу проблем у нашій науці. І постійно на Вченій Раді хто-небудь починає пояснювати, що це "не наука". Важливо створити нову модель, новий мова, новий метод, новий алгоритм, показати, що він відрізняється від інших. Я вже багато разів був опонентом, а не тільки керівником дисертації. Для новачка, для людини з боку це, можливо, буде навіть дивно. У завдання опонента входить не тільки оцінити, хороша дисертація або погана. Головна завдання - оцінити співвідношення цієї роботи з іншими відомими роботами. Чи не забув дисертант, що це вже зроблено? Він порівнював свою роботу з іншими? Чи не забув він якийсь важливий результат, який був отриманий іншим, а в нього навіть не згадується? І друге - наскільки коректно проведено порівняння власної роботи з іншими відомими роботами? У вимогах ВАК чітко вказані завдання двох опонентів: наскільки повно дисертант висвітлив інші роботи в цій області і наскільки коректно порівняв свою роботу з ними. Якщо відомий результат, який перекриває результат дисертанта, а дисертант про це не згадав, то завдання опонента - про це згадати.

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

Наприклад, зараз у нас час захисту дипломних робіт. У мене захищається в цьому році 19 чоловік. Отже, приходить студент V курсу, який провів півроку десь на практиці. Показує свою програму. Я кажу: "Добре, давай ПОСМотрим, наскільки наукова твоя робота. Що тут найголовніше? По-перше, наскільки це новий результат? Чи писав хто-небудь про це раніше? "." Не знаю ". "Ти робив огляд літератури?". "Ні" ... Чим відрізняється дослідник від практика в гіршому розумінні цього слова? Дослідник зрозуміє, що не треба винаходити велосипед. У наші часи, коли є Інтернет, інші канали отримання інформації, є сенс подивитися, що зробили інші. З цього треба починати. Далеко не всім це спадає на думку. Друге. Знайшов, що такого результату немає, і ти його сам отримуєш. Але є схожі результати. Проведи порівняльну характеристику. Мене дратує така ситуація: люди працювали, писали дипломи, писали дисертації. Питаєш: "Чим ваша технологія краще, ніж інші? "І йдуть аргументи:" З одного боку не можна не визнати, з іншого боку не можна не погодитися ... " Питаю: "Хлопці, ви витратили на цю роботу стільки сил і часу. Ми інтуїтивно розуміємо, що це добре. Але хіба так важко все це чітко сформулювати? У багатьох програм є демо-версії, і порівняння їх з вашим варіантом входить в роботу ". Нинішня молодь з працею розуміє, що просто зробити щось, що працює, це менше половини справи. Справжній дослідник повинен дивитися, як працюють інші, викачувати демо-версії, читати інструкції - як у них запускається програма, навчитися запускати, подивитися, попрацювати, зрозуміти, що добре, що погано, може бути, запозичувати якісь ідеї. Необхідно чітко сформулювати, в чому твоя заслуга. Що ти такого зробив, чого в інших немає? Зараз цим займаються тільки бідні дисертанти, і то, на жаль, є така десятиліттями склалася практика, що вони займаються цим в останній момент, коли вже "цеглину" пишуть. Покладено мати огляд літератури з теми, вони і сидять у бібліотеці за 3 місяці самому кінці. І, між іншим, на моїх очах була ситуація, коли аспірант захищається з налагодження, а його на Раді запитують: "Як це співвідноситься з такими-то методами налагодження? "Виявилося, що він у бібліотеці Академії Наук порівнював свій метод з американськими роботами, а те, що в СРСР є такі роботи, і не знав ...

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

Отже, важливо уміння сформулювати завдання, вміння подивитися на неї з боку "що є в світі ", вміння чітко пояснити, що у тебе нового.

Я в черговий раз відволікся, але все-таки закінчу. Отже, приходить студент або студентка з дрібної фі