Працюю над проектами, що об'єднують книгу і інтерактив »кей Хорстманн про книгах і не тільки

Є гігантське безліч книг про Java - а є кілька «тих самих» книг про Java. У їх число входить «Core Java» (в українському виданні «Java. Бібліотека професіонала») Кея Хорстманн і Гері Корнелла. Вона з'явилася лише через рік самої мови, відразу ставши одним з головних джерел інформації по темі. А за наступні двадцять років витримала цілих десять видань, скрупульозно поповнюючись інформацією про нові версії Java, так що на ній виросло вже не одне покоління Java-розробників.

Кей і раніше уважно стежить за нововведеннями Java, і восени на Харківській конференції Joker розповість. що в Java 9 хорошого. А в очікуванні його приїзду ми розпитали його про що: і про роботу над книгами, і про те, чи можуть їх витіснити онлайн-курси, і про відмінності академічного світу від індустрії, і про майбутнє Java.

- Працювати над однією книгою десятиліттями - як це? Чи виникає «Легасі», коли якийсь фрагмент відчувається застарілим, але просто «взяти і викинути» неможливо? Чи схоже оновлення книги на рефакторинг коду? І викликало чи щось, написане роки тому, відчуття «яку дурість я написав»?

І так, робота над новим виданням відчувається як рефакторинг. У багатьох випадках новий спосіб робити щось робить інші підходи застарілими, і мені треба розбиратися з сотнями прикладів коду. Я люблю використовувати нові можливості у всіх прикладах, де вони підходять, щоб Новомосковсктелі не надавалися спантеличені сумішшю старого і нового. Простий випадок - diamond operator, там потрібно просто знайти вирази виду «new ... <.>(.) ». Але коли додали лямбда-вирази, мені довелося переписати більше половини програм-прикладів, часом сильно їх реорганізовуючи.

Ми не хотіли, щоб «Core Java» погладшала до трьох томів, так що в кожному виданні якісь речі виявляються віддалені. У числі таких - інформація про баги в старих версіях, які вже нікого не хвилюють, «обхідні шляхи», які застаріли через поліпшень в мові, і масштабні «викосили» API. Колись у нас було дуже докладний опис CORBA, і позбутися від цього було досить легким рішенням. Коли видалили опис RMI, деякі Новомосковсктелі засмутилися, але слухайте, коли в останній раз хто-небудь використав це не в іграшковому прикладі? А тепер підбирається наступне складне рішення: що робити зі Swing?

Часом в текст пробирається технічна помилка, і я веду список помічених помилок, так що Новомосковсктелі можуть про них повідомляти. Я дуже серйозно підходжу до цих «баг-репорт», щоб помилки не проживали довше одного видання. На щастя, ситуація «яким дурним я був» виникає нечасто, але часом моя точка зору з часом розвивається. Наприклад, коли з'явилися вкладені класи, я дуже докладно пояснив, як працював захоплення локальних змінних, наводячи результати декомпіляцію через javap. Пізніше я задумався про це. Чи пояснював я в таких же подробицях, наприклад, як технічно працює виклик методів? Ні, і Новомосковсктелі не вимагали таких деталей. На практиці програмісти повністю готові довіряти компілятору в тому, що він здатний розібратися і з викликом методом, і з захопленням локальних змінних, так що я прибрав непотрібні деталі.

- У той час як деякі книги звертаються до вузької аудиторії, «Core Java» відкривають різні люди, у яких знання і досвід дуже різняться. Чи виникають складнощі, коли пишеш «для всіх»? Що допомагає з ними справлятися?

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

У наш час мало хто Новомосковскет книгу з програмування від кірки до кірки. Багато моїх Новомосковсктелі використовують Safari Books, де просто відкривають сторінки, присвячені конкретній темі. І я структурував книги серії «Impatient» так, щоб матеріал був легко зрозумілий в цій формі, без постійних відсилань до інших місць тієї ж книги.

- Коли пишеш про Java протягом багатьох років і вдаёшься в деталі, виникає відчуття «як багато в Java зроблено абсолютно неправильно»? Чи пробували щось поліпшити?

- Зрозуміло, коли мова про таку велику і складну платформі, як Java, є безліч речей, з якими щось не так. Але тільки в рідкісних випадках щось страшенно не так: наприклад, це існування примітивних типів, яким слід було бути внутрішньою справою віртуальної машини. (І я сподіваюся, що в майбутньому нова версія Java це виправить.)

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

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

Як приклад: я одного разу запропонував, що потрібна можливість запустити програму, викликавши конструктор (з параметром String [] або без аргументів) класу, зазначеного в командному рядку, якщо цей клас не містить методу main. Я навіть імплементований це - код запуску в VM не такий вже складний. Чому мені взагалі було до цього справа? Тому що це було б манною небесною для студентів і преподателей, яким не довелося б мати справу з public static void main в першій же лекції. «Hello, World!» Виглядав би так:

Друга пробна програма могла б відразу ж пірнати в об'єкти, не турбуючись про «static».

Не було ніякого ризику помилок зворотної сумісності, тому що раніше такий клас просто не міг би бути запущений.

Чи було моє скромне пропозицію схвалено? Ні в якому разі. Воно було відкинуто як «занадто складне» і «здатне загрожувати зворотної сумісності».

Але як би там не було, з часом багато дратівливі особливості API виявляються виправлені. Можливо, через те, що людей в Oracle вони дратують так само, як і нас.

- Чи доводилося вам чути від Java-розробників, що ваші книги не тільки навчили їх Java, а й вплинули на їх стиль програмування?

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

В цьому небезпека книги з особистою думкою. Якщо воно не настільки вірне і переконливе, що стає думкою більшості, то ви обмежуєте власну аудиторію. У випадку з книгами «Core Java» я говорю Новомосковсктелю, як використовувати Java ефективно, але крім цього, не проповідую ніякі конкретні методології.

- У вас на сайті в розділі «memorable quotes» є цитата, підколювати Герберта Шілдт. Оскільки ваші книги про Java конкурують, хочеться дізнатися - це просто жарт, або у вас суперництво. )

- З Гербом - немає. Я ніколи його не зустрічав. Я навіть не знаю, чи існує він. Може, це кодове ім'я для програми зі штучним інтелектом. Жартую, Герб :-) Мені просто сподобалася цитата.

- Ви брали участь у створенні курсу Intro to Java Programming на Udacity. Чи відчуваєте ви, що майбутнє навчання програмуванню за онлайн-курсами? Чи стають книги менш актуальні? Що б ви порадили в першу чергу людині, яка хоче стати розробником: книгу або MOOC?

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

- Тут криється поширене непорозуміння. Студенти часто запитують щось на кшталт: «Чому мені треба вчити теорію автоматів? Що мені дійсно потрібно, так це курс по AngularJS ».

Я не сперечаюся з тим, що якщо студенту для конкретного проекту потрібен AngularJS, то йому варто вчити AngularJS. Але як університетського курсу. Університет хороший для того, щоб навчити речам, які будуть як і раніше актуальні через 20 років. І навчити вчитися. Так що через 20 років, коли колишньому студенту буде потрібно вивчити фреймворк XYZ, у нього буде бекграунд і навички, щоб швидко освоїти його самостійно.

Деякі люди вважають, що університети заходять занадто далеко з викладанням марного матеріалу, і їм з їх чотирирічний програмами не вистачає гнучкості. Ось тому з'являються всі ці «хакерські академії» та «nanodegree». Мені самому приходять в голову деякі способи модернізувати навчальну програму в computer science, і я також визнаю, що деякі з цих способів не будуть впроваджені через інституціональних бар'єрів. Але нетрадиційні освітні програми йдуть в іншу крайність, котрі дають досить фундаментальних знань. Вони також відрізняються від університетів в іншому відношенні: їм потрібно фокусуватися тільки на самих мотивованих людей, здатних заповнити багато прогалини самостійно.

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

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

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

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

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

- Ви викладали CS у всьому світі - в США, Швейцарії, В'єтнамі та Макау. Чим викликаний такий розкид?

- Мені просто подобається подорожувати.

- А з точки зору вашої роботи була якась значна різниця між цими країнами, або computer science і в Макау computer science?

- Всюди одне і те ж. Скрізь у мене були і видатні студенти, і не дуже видатні. Ну, в'єтнамські студенти не були привчені спиратися на власну думку. Вони постійно задавали мені найдрібніші питання про те, як їм слід діяти, а я постійно відповідав, що вони дуже розумні (вони дійсно були такими, їх відібрали з 1% за результатами шкільного іспиту), і їм потрібно сформувати власну думку. Думаю, це їх навчило більшого, ніж будь-яка технічна інформація, яку я давав в лекціях.

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

- У Вікіпедії зазначено, що протягом декількох років ви використовували в книгах власний стиль відступів, а потім відмовилися від цього. Чому почали, і чому припинили?

Історія така. У випадку з C у нас є стиль KR і стиль Олма:

Що ми хочемо - заощадити місце, або вирівняти фігурні дужки? А що, якщо хочемо відразу і те, і інше? Ось тут і вступає в справу «стиль Хорстманн»:

Людям він не сподобався. Для цього не було жодної помітної раціональної причини; писати так просто здавалося дивним. У підсумку я здався, бо у стилю не було підтримки з боку тулінга. Гра не варта свічок.

- Ви пишете про Java вже десятиліттями і бачили, як все змінювалося з часом. Що ви думаєте про майбутнє Java? Вона пройшла свій пік і буде повільно втрачати в популярності? Або все ще попереду, а молоді JVM-мови на зразок Scala і Kotlin допоможуть всій екосистемі?

Я також бачу багато ентузіазму навколо Python в областях на кшталт data science. Немає ніякої причини, по якій відповідні бібліотеки не могли б бути написані на Java, але вони написані не на ній. І на Kotlin їх теж не пишуть. У Scala є свої помітні території, особливо Spark.