ООП майбутнього: Барух Садогурський і Єгор Бугаєнко про те, як ми будемо програмувати через 20 років

Концепція об'єктно-орієнтованого програмування сприймається розробниками по-різному: хтось каже, що їй вже пора на смітник історії; хтось кодит і не замислюється про те, що, як і чому він робить; а хтось намагається працювати в «pure OOP» парадигмі, перевертаючи класичні патерни з ніг на голову.

Напередодні Joker 2016 ми попросили Баруха Садогурского обговорити долю Java і ООП з Єгором Бугаєнко. Що з цього вийшло, слухайте в аудіоформаті або дивіться у відео:



А під катом лежить повна розшифровка інтерв'ю з усіма посиланнями.

Барух jbaruch Садогурський: Всім привіт. Мене звуть Барух, я developer advocate у компанії JFrog, провідний подкасту «Розбір Польотів», спікер на конференціях на зразок Joker JPoint, ну і всякої лабуде типу JavaOne, Devoxx та іншого. І сьогодні в сонячному Маунтін-В'ю ми сидимо з відомим в певних колах Єгором Бугаєнко, зустрілися поговорити за життя.

Єгор yegor256 Бугаєнко: За життя? А я думав, про ООП, Java…

Барух: Наше життя — це і є ООП, Java. Для початку розкажи про себе для тих, хто не чув.

Єгор: Java-програміст, архітектор. Програмувати почав 20 років тому, ще в школі — спочатку це був PASCAL, потім асемблер, потім C, потім C++, потім Java. Останні два з половиною роки веду блог, завдяки якому з'явилася якась популярність. Пишу книжки, зараз пишу другий том. Намагаюся трохи поправити об'єктно-орієнтовані підходи, які використовуються в Java. Де-то виходить, десь менше, але намагаюся цю ідею донести в маси, завдяки чому ці маси…

Барух: Вирують!

Єгор: Вирують і реагують по-різному, так. Комусь це подобається, комусь ні, але це справляє ефект, до когось якісь думки доходять. Хтось проти, і я не можу сказати, що сам впевнений у всіх своїх думках на поточний момент, але процес йде. Так, чим я заробляю на життя: у мене невелика розподілена команда в Пало-Альто, близько 50 чоловік, так сказати, працюють, а сумарно 100. Ми пишемо софт на замовлення на Java. Замовники у нас тут, в Силіконовій долині, я керую цими процесами з кількома проджект-менеджерів. Програмісти з різних країн, звідусіль. Ось цим заробляю, ну ікнижка трошки грошей дає.

Барух: У мене до тебе маса питань. По-перше, поставлю гостре питання: звідки ти такий узявся? Ти з'явився на поверхні російськомовного Java-ком'юніті рік тому, вихором пройшовся по конференціям на пострадянському просторі, і я так розумію, що зав'язав. Що це, Беррімор?



Єгор: Не зав'язав, у мене ще 7 конференцій попереду — мене запрошують, я не відмовляюся. Але тепер не так активно. Я виступив за останні півроку на 25 конференціях, трошки забагато.

Барух: Так от, як так вийшло, навіщо це тобі треба? Це досить важка робота, я зі свого досвіду знаю. Програміст, архітектор, CTO раптово вирішує: «А чи не провести мені півроку, роз'їжджаючи по конференціям».

Єгор: Хороший питання, у мене немає на нього відповіді. Але в якийсь момент я зрозумів, що хочеться розширити аудиторію. Блог мене на це підбив.

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

Єгор: Ти розумієш, я вже не контролюю цей процес, я став заручником процесу, який сам створив. Я завів блог, з'явилося ком'юніті, люди дають свій фідбек і починають мене витягувати, щоб я з ними поговорив. Це двонаправлений процес. З одного боку, я хотів виступити на декількох ключових конференціях: JPoint у Москві, в Києві JEEConf, в Білорусії той же JET. А інші місця з'явилися самі, тому що люди мене стали бачити і говорити «Давай і сюди теж».

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

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

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

Єгор: Чому не створити якусь нову парадигму, ти питаєш?

Барух: Ну вона і є нова парадигма ж. У слів є свої значення. ООП — це класи, об'єкти, посилка меседжів об'єктів з певними параметрами для отримання назад якогось значення. Це поліморфізм, спадкування, якісь речі, які ми знаємо, любимо і так далі. Тепер ти приходиш і кажеш: «Ні, объекто-орієнтоване програмування — це не це». Навіщо?

Єгор: Ну, швидше не «навіщо», а «чому». У мене немає відповіді на питання «навіщо?», тому що для цього повинна бути якась мета, у мене такої чіткої мети немає. Ні грошової, ні якийсь інший. Це питання, скоріше, «чому?», чому я так роблю. Тому що мені сильно не подобається те, з чим я працював протягом багатьох років… Мені не подобається ні той код, який я писав, ні та Java, яку я бачив, ні бібліотеки, з якими я стикався, мені неприємно з ними працювати. Не тільки мені, а людям, які навколо мене, програмістам. Я бачу код, який вони пишуть, як важко потім цей код розуміти, підтримувати, як взагалі неприємно програмувати.


Мені не подобається ні той код, який я писав, ні та Java, яку я бачив, ні бібліотеки, з якими я стикався, мені неприємно з ними працювати.


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

Барух: Ну це все зрозуміло, але це нормальне явище…

Єгор: Я думаю, що ненормальне.

Барух: Ну я до того, що це відоме явище, і рішення цього теж невідомо, наприклад візьми всіх, хто сьогодні використовує функціональне програмування, вони кажуть «нам не подобається об'єктно-орієнтоване програмування, і ми пішли в іншу парадигму тому, що нам було гидко від цієї вашої Джави». І вони взяли і пішли в іншу парадигму.

Єгор: Але вони і там нагадят. Якщо вони не зрозуміли ООП і просто від нього відвернулися, сказали, що воно погане в цілому, всі ООП… Як ось нещодавно в блозі я зібрав цитати відомих людей про об'єктно-орієнтованому програмуванні. Вони всі говорять гидоти. Починаючи з Дейкстри, закінчуючи сьогоднішнім днем. Люди кажуть, що це противна концепція в принципі, давайте її не використовувати, тому що вона допомагає створювати «spaghetti code».

Барух: Ну так, вони стверджують, що індустрія переросла об'єктно-орієнтоване програмування — так само, як вона переросла процедуральное програмування. І тут я знову повертаюся до того ж питання. Природний відповідь була б: «ОК, ось нова парадигма, ось «ООП 2.0». А ти кажеш: «Ні, те, що вам не подобається, насправді називається по-іншому». І замість того, щоб предствавить свою нову парадигму (що саме по собі непростий шлях), ти додаєш до цього ще опір того, що люди не розуміють, навіщо ти намагаєшся назвати це чимось іншим.


Весь мейнстрім неправильний, 95% ви робите неправильно


Єгор: Ну щоб носом ткнути їх. Це такий елемент провокації, який необхідний, щоб люди замислилися. Якщо я їм запропоную «ООП 2.0», як ти кажеш, ну шанують кілька людей, скажуть: «Ну добре, ще одна ідея якась, відкладемо її, подумаємо. У нас є Java, вона прекрасна, вона йде вперед, вона мейнстрім, на ній всі пишуть, по ній проводяться величезні конференції, на ній величезні фреймворки, усе чудово». Є якась інша, нова парадима? Ну добре, у нього пів-фреймворку, вісім програмістів, ну от нехай вони там сидять і копаються. Коли ж я приходжу в цей центральний мейнстрім і кажу: «Хлопці, весь ваш мейнстрім неправильний, 95% ви робите неправильно», народ починає ворушитися, соватися на стільці і розуміє, що йому не пропонують щось третє (куди він може піти, а може проігнорувати), а пояснюють, що сьогодні ти шкодиш всім. Звичайно, це викликає великі емоції. У мене багато мейлів є, мені люди пишуть: «Я зрозумів, що десять років поспіль робив не те, твоя така-то стаття відкрила мені очі, тепер я все зрозумів, я буду робити так», а інший пише: «Та замовкни ти, припиняй це розповідати, ми знаємо, що робити». Така різнополярних реакція говорить про те, що людей це зачіпає, що їм це байдуже, а це добре. А якщо робити щось стоїть в стороні, це мало кому здасться цікавим.

Барух: тобто ти спеціально виходиш на лінію вогню для того, щоб змусити людей замислитися.

Єгор: Так вийшло. Коли я починав писати статті, у мене була перша стаття про те, що null reference — це погано. Вона не дуже провокаційна, тому що багато хто про це знають і говорять. Я написав трохи більш різким тоном: більшість статей говорить про те, що намагайтеся його уникати, а я написав, що це в принципі погано, це evil, не чіпайте його. Потім пішов трохи далі і написав про геттери і сетери. Тобто я не хотів нікого провокувати, я просто писав, виходячи з свого досвіду. Потім відстежив реакцію і зрозумів, що багатьох людей це чіпляє за живе, і вони згодні з цим, побачив багато фоловерів, не хейтеров. А потім підключилися хейтеры. Але я їх ігнорував, бо бачив, що кому-то це в касу, хто з цим згоден. Я пішов трохи далі. Але я не спеціально, не було такого завдання: давай ми зараз спровокуємо натовп, побачимо, на що у них буде реакція і почнемо збирати трафік. Такої мети не було. Я просто написав спочатку кілька статей з свого нескольколетнего досвіду.



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

Єгор: Причому хейтеры — це в основному люди, які мало читають, які мало чули, чули дзвін — ну ти сам це бачив на «Розборі польотів» 109-му випуску, коли Женя EvgenyBorisov Борисов прийшов і таврував мене, особливо не прочитавши нічого. Я все хочу послати йому книжку. Я б дуже хотів, щоб він прочитав все цілком і зібрав все до купи, ти ж читав книжку, ти розумієш це. А він прочитав щось, почув: «А, він говорить, що ось це погано і це погано, так він дурень».

І більшість негативних реакцій саме таке. Люди дізналися, що за пів-слова і сформували думку. Це не збиває мене, тому що є люди, які згодні. Якщо б були всі незгодні, я б сильно задумався, чи не даремно провокую натовп. А так зробили нещодавно на Gitter-чат, там набралося за півтора місяця 120 чоловік, і люди обговорюють, часто вже в стороні від мене. Часто буває ідея якась, один запитує: «Як би ви це зробили?» а інші йому відповідають: «Ми б зробили це так» і дають посилання на мій блог. Це дуже прикольно спостерігати, коли думки вже не мої, вони вже там живуть, люди цим користуються. Це приємно. Хоча є в цьому ж чатике хейтеры, ми систематично намагаємось гасити, а вони піднімають флейм. І там часто задають це твоє запитання: «Навіщо ти змінюєш ООП, у нас все добре, у нас є Java… Ну назви це по-своєму і відчепись від нас».

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


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


Єгор: Так, ти правий, це погано відбивається на бізнесі. По-перше, з прийомом на роботу проблема, по-друге, з пошуком клієнтів. Коли клієнт приходить і чує, що ми робимо щось сильно інакше, ніж інші, то виникає питання «а чи не помиляються вони». Ми вам все замовимо, а через півроку будемо шукати нову команду, яка все це викине, бо розуміє тільки ця. Це є. З набором на роботу теж проблема — хоча є люди, які дуже хочуть саме до нас, поки що таких небагато. Але мені цікавіше не бути ще однією компанією у великому ряду інших, а бути компанією, яка робить щось інакше і краще. Може, я помиляюся.

Барух: Женя Борисов просив дізнатися, наскільки часто буває, що на інтерв'ю ти даєш претенденту тестове завдання, показуєш шматок коду, а він перевертає стіл і каже «що це за фігня, я не буду писати».

Єгор: Я теж чув, як Женя Борисов сказав в якомусь «Розборі польотів», що у нього в Ізраїлі була знайома команда, де люди робили щось по-своєму, і всі інші компанії банили людей з цієї команди. Тобто, якщо ти приходиш з тієї компанії, то все, ніяких інтерв'ю, тому що у тебе мозок зламаний і ти пишеш по-іншому. Я розумію, у нас теж є така штука. Коли ми приймаємо Java-програмістів на роботу, ми часто даємо шматок коду на Java, який, на мій погляд, написаний з великою кількістю помилок. І просимо показати помилки. Що би ви виправили? І багатьом цей шматок коду здається правильним, а там сетери, геттери, null… Все, про що я виступаю, там представлено. І ті, хто не звертає на це уваги, просто рефакторит і вважає, що все нормально. Ми таких людей відхиляємо. Але є люди, їх не так багато, але й немало, які знаходять і кажуть: «Та ось тут у вас ці сетери, геттери — це що за фігня, це нісенітниця… треба переписати по-іншому». Ось таких людей ми відразу: вп, заходь. І вони знаходяться, у місяць одного-двох непоганих хлопців маємо.

Барух: Це хороший темп.

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

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

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

Барух: Твоя концепція розвивається, в ній є суперечливі моменти, це якийсь ментальний work in progress, коли картинка ще не повністю склалася. Що вимагає якогось переосмислення того, що було написано. Ось цей другий том є переосмисленням першого, або ти перший відкладаєш і кажеш «що було, то було»?

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

Барух: Ось це я шукаю: де буде написано, що ти був неправий?


immutability зараз дуже активно обговорюється в нашому чаті і не можемо до кінця зрозуміти, що таке immutable object...


Єгор: Ну у мене це буває. Я пишу, що я був неправий, уточнюю. Припустимо, immutability зараз дуже активно обговорюється в нашому чаті і не можемо до кінця зрозуміти, що таке immutable object… І це обговорення дуже живе, у мене є в блозі чотири штуки, і в книжці ціла глава про… Якщо все це скласти, то там є речі, які один одному суперечать. Але я відкритий цього, немає проблем сказати, що я був неправий.

Барух: Сказати «я був неправий» в теоретичних роздумах — почесно, круто, але легко. Повертаючись до бізнесу: що робити з кодом, який пішов у продакшн, і ти розумієш, що там ой…

Єгор: гарне Питання. Але навіть якщо там були якісь помилки, вони не такі серйозні. Там немає таких фундаментальних помилок, які потрібно було б переписати цілком. Є якісь моменти, які трохи лівіше, трохи правіше, але в цілому немає. Концепція — я не сказав би «струнка», але складається одне з іншим. Я не просто пишу про ідеї, я ще і код пишу також. І є деякі продукти, яким три роки, два роки, один рік. Можна їх переглянути і побачити, що в продуктах, яким три роки, два роки, безліч речей, до яких я дійшов ось недавно, не було. Сеттерів не було, але в деяких місцях є й null pointer, і ORM використовується десь. Тобто деякі речі можна відкрити в опенсорсе і побачити, що теоретична думка була там ще в зародку. А свіжі продукти більш цікаві, в них вже використовується вся краса ООП.

Барух: Ну ось це цікаве розкриття інформації про те, що насправді концепція ООП від Єгора — вона work in progress. Я не впевнений, що багато хто з твоєї концепцією познайомився, це розуміють. В основному з-за книжки. Тому що зазвичай, коли людина пише книжку, оскільки воно на папері і автор не може додати апдейт «ось тут мені написали в коментах, що я був неправий», воно сприймається закінченим. Immutable, так сказати. Мені здається, багато людей не в курсі, що це все живе, розвивається, тече. І насправді ти готовий не тільки слухати, але і приймати критику, і вона дійсно може якось змінювати концепцію.


Клас — це взагалі помилка. Не повинно бути класів.


Єгор: Наведу приклад. Ну ось наприклад в книжці у мене написано, що клас — це певна концепція, яка потрібна і важлива. Я разговораривал Девідом Вестом. І він мені говорив, що клас — це взагалі помилка. Не повинно бути класів. Я думаю, я поки не впевнений, прав він чи що він має на увазі.

Барух: Концепція, що клас — це помилка, це з JavaScript. Об'єктно-орієнтоване програмування через prototype. І є дуже серйозний диспут на дуже високому рівні, який триває вже двадцять років, про те, потрібен клас чи ні. І є аргументи за і проти. Аргумент за: в об'єктно-орієнтованому програмуванні клас — це дійсно абсолютно зайва сутність. Вона не додає нічого. Ти створюєш об'єкт, як його вважаєш потрібно створити, і потім створюєш ще скільки-то таких же. Але тут, з іншого боку, є маса проблем типу immutability: об'єкт може змінитися, що відбувається з тими, хто створений до цього? Вони повинні змінитися, повинні відповідати новим чи старим? І чому начебто однакові об'єкти, створені з різницею в кілька рядків коду ведуть себе по різному? Тому що в якомусь іншому місці змінився prototype. Ну, приїхали, класно тепер. Ось ця концепція blueprint як класу, з якого ти клепаешь об'єкти, це питання вирішує, тому що клас — це щось незмінне, а об'єкти від нього потім отпочкуются і живуть своїм життям. А з прототипами це не так зрозуміло. Тому тут безумовно є, про що подумати.

Єгор: Є, так. І що, якщо я зміню свою думку?

Барух: Ну, якщо ти ще й від класів відмовишся, то це взагалі буде армагедон.

Єгор: Я поки не відмовляюся від них, але Девід сказав мені: «Хто це взагалі придумав, навіщо вони потрібні?»

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

Єгор: — Так.

Барух: Що ти будеш робити, якщо ти вирішиш, що клас — ворожа ООП структура?

Єгор: Я сподіваюся, що я так не вирішу, хоча… Розумієш, у мене є деякі статті, де сказано «як погано робити ось це», але не запропоновано жодної альтернативи Java, я так їх і закінчую: якщо Java покращиться, і це буде якийсь новий мову, тоді ми зможемо робити те-то і те-то.


я пропоную управління пам'яттю: кажу, що диски і пам'ять повинні бути чимось одним. Ми ж даємо програмісту в Java управляти файлом на диску — відкрили, закрили. Чому те ж саме не можна робити з пам'яттю?


Наприклад, я пропоную управління пам'яттю: кажу, що диски і пам'ять повинні бути чимось одним. Ми ж даємо програмісту в Java управляти файлом на диску — відкрили, закрили. Чому те ж саме не можна робити з пам'яттю? Ось такий концептуальний питання. Java цього не дає, а мені здається, що правильна мова повинна давати можливість керувати пам'яттю. Як у C/C++, але в якомусь зручному вигляді. Але Java я не поміняю.

Барух: Це підводить мене до наступного питання: чому ти мертвою хваткою вчепився в Java? Ти вже прийшов до висновку, що істинного ООП-мови не існує. У нас є платформа JVM, що дозволяє відносно малою кров'ю написати будь синтаксис мови, в якому будуть всі карткові ігри і всі дівчата легкої поведінки істинного ООП, які ти тільки захочеш. Тобі не приходило в голову таке?

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

Барух: Я, напевно, тобі відповім, що це чудова бібліотека, але не обов'язково функція мови. Існує підхід, що в принципі мови повинні бути минимализированы, а все інше підключається за допомогою необхідних бібліотек. І тобі є діло до історії твоїх комітів в Git'е, а мені ні, наприклад. Тобі потрібна ця фіча — ти підключаєш бібліотеку, і вона у тебе є.

Єгор: А її неможливо зробити бібліотеку, вона повинна бути в мові.

Барух: Ось це цікаве питання. Чому?


Тому що ця бібліотека буде виглядати криво, як AOP в Java, приклеєна збоку, як AspectJ


Єгор: Тому що ця бібліотека буде виглядати криво, як AOP в Java, приклеєна збоку, як AspectJ. Прикольна ідея класна, але немає її підтримки в мові. Є анотації, які з'явилися пізніше. У четвертій Java взагалі не було ніякої підтримки AOP, і все це було наліплено через нерідні технології. Оскільки вони нерідні, все незручно, негарно. Java, або будь-яку мову, повинен давати AOP by definition, він повинен бути by default, вбудований в мову. І так само доступ до Git. Це історія наша — хто коммитит, скільки коммитит — це вже частина мови.

Барух: Але сьогодні це Git, а завтра — Mercurial.

Єгор: Це проблема, так.

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

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

Барух: З тим, що для мови може бути корисно більшу кількість SPI я, можливо, погоджуся.

Єгор: Ось штук 40 таких фіч, які повинні з'явитися. Припустимо, Continuous Integration. Вона абсолютно ніяк не приклеєна до мови. Або build automation. У нас є всі ці мавены і грейдлы, які до Java ніякого відношення нативно не мають. Сам код на Java не знає, що його будуть билдить. Я всередині коду не можу отримати доступ до цієї інформації. Або, припустимо, юніт-тести. Вони існують на Java як просто клас, але які це класи? Які це об'єкти? У мене є об'єкт book, що таке об'єкт bookTest? Це дивно. І ці методи — це не методи, це процедури в чистому вигляді, микроскрипты. Воно повинно бути зроблено якось інакше. Зроблено так, тому що тести зробили після Java. Потрібні вам юніт-тести — ну ось так ліпіть. Це не нативно, не клеїться одне до іншого. Цим користуються, але повинні бути більш зручні засоби всередині мови. Я думаю, що ми до цього йдемо. Такі plain мови типу C, де просто можете скомпілювати бінарники — це двадцятирічної давності, а зараз потрібно щось нове.

Барух: Це Java двадцятирічної давності, а з вже сорокап'ятирічної.

Єгор: Тим більше, повинно бути щось нове. Я думаю, з'явиться. Може бути, я щось зроблю, не знаю. Це вимагає часу і, головне, має бути ком'юніті. Створюючи під себе, отримаю чисто моє рішення. Ось ти кажеш «не Git, а щось інше», а мені таке і в голову не прийде, для мене Git стандарт фе-факто. Ти скажеш «у нас ціла команда на Mercurial або Subversion», а у мене вже не ліпиться, цілий шматок ринку моє рішення не буде підтримувати. Тут має бути гетерогенне ком'юніті, де різні люди.

Барух: Скажи, а що ти думаєш про нових мовах? Два приклади — Kotlin і, може бути, Ceylon, якщо ти на нього дивився.

Єгор: Ceylon мало дивився, Kotlin — був на презентаціях на конференціях. Я тут не можу бути експертом, але, на жаль, мені здається, що загальний напрямок в індустрії не в бік чистого ООП, а, навпаки, в бік його коммодизации. Вам потрібні геттери і сетери — так ось вони by definition. У Котлине вам не потрібно писати, вони там є! Мова придуманий і розвивається як design pattern — люди накодили, а потім інші приходили і говорили «це назвемо сінглтоном, а це ось так». А має бути з зворотного боку, люди повинні приходити і говорити «давайте використовувати такий design pattern, таке рішення». І потім всі практики за ними повинні йти. А ми йдемо від практики до теорії.


Java EE, практично покійний порівняно з технологією, яка народжується з best practices, порівняно зі Spring.


Барух: Ти пропонуєш вежу зі слонової кістки. У нас в Java коммьюніті така є. І вона на наших очах розсипається. Я кажу про Java EE, практично покійний порівняно з технологією, яка народжується з best practices, порівняно зі Spring. Дивись: Java EE розвивався як раз так, як ти вважаєш правильним. Сиділи розумні хлопці, які думали, які best practices повинні бути, назвали їх офіційним стандартом. Більш того, цей стандарт просувався найсильнішим на ринку Java-гравцем — самим Sun, а потім Oracle, у тебе є стандарт from the source, що може бути краще. І ось.

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


У Kotlin і їм подібних напрямок, по-моєму, неправильне. Практика повинна йти з теорією, і теорія повинна коригувати практику.


Як Ruby. Мова начебто створювався правильно, але там така величезна кількість статики, така величезна кількість процедур, що вся мова… Мова хороший, але з бібліотеками виглядає як якась каша. Їм дуже важко користуватися, принаймні, мені. Я пишу на Ruby, але це якийсь кошмар, Java краще. У Kotlin і їм подібних напрямок, по-моєму, неправильне. Практика повинна йти з теорією, і теорія повинна коригувати практику.

Барух: тобто ти вважаєш, що за мовою повинні стояти якісь візіонери.

Єгор: Звичайно. Повинні говорити «Хлопці, ви йдете трошки не туди, тепер підемо туди». А не «Всі йдуть туди, побіжимо вперед і встанемо з прапором». До чого це призведе? Це тимчасові мови, вони помруть через кілька років.

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

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



Барух: Чому Java успадкувала стільки хвороб C? Тому що повинно було бути схоже,, щоби програмісти могли це взяти і почати фігачити код.

Єгор: Саме. Але я не намагаюся змінити ситуацію з сьогоднішнього дня, щоб ми завтра стали писати інакше. Я намагаюся міняти на крок вперед, через рік, два. Якщо зараз ми почнемо голови програмістам вставляти ідею про те, що геттери і сетери — погана ідея, то через три-чотири роки, коли ці люди, які зараз навчаються, почнуть створювати свої фреймворки та покращувати щось, врахують ці думки.


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


Барух: Ось тут у мене є для тебе цікава рефлексія. Ось те, що ти намагаєшся зробити, і ці твої блог-пости, кожен поодинці, переслідують цю мету. Ти пояснив, чому null — це погано, що повинно бути N параметрів у методі, чому в конструкторі можна писати бізнес-логіку. Кожен з цих ходів, напевно, трішки покращує сьогоднішнього Java-програміста. А потім я беру твою книжку, і, як я написав в рев'ю, я бачу зовсім іншу, нову концепцію, в порівнянні з сьогоднішньою Джавою. За сукупністю всього разом взятого. Коли я читаю один пост, можу трошки поліпшити свій код, залишивши все інше так само. Коли я читаю твою книжку, це геометрія Лобачевского. У мене починають перетинатися паралельні лінії. Це неможливо поєднувати з тим, що я роблю зараз. Або робиш так, чи по-іншому. І твій код — він теж зовсім інший. Він не поступова зміна існуючого. Коли я дивлюся на твій код і порівнюю з моїм, вирішальним ті ж завдання, це не просто «у тебе немає null, а у мене є». Твій код взагалі нічим не схожий на мій, крім скобочек і крапок з комою. І тут у мене виходить деякий дисонанс з твоєю ідеєю інкрементальних змін.

Єгор: Розумію, про що ти говориш. Але я не досягну результату м'якими діями. У блозі я в рамках однієї статті вкидаю, людина читає, трішки змінюється. Книжка робить кидок далеко вперед. Вона каже: «Ви тут, а правильно — ось там, через 20 кілометрів. Як ви туди доберетеся, я не знаю». Як в анекдоті: «Моя справа — стратегія, а з тактикою ви самі вирішуйте». А блог дає якісь кроки — тут трошки так, тут так. Книжка закидає далеко вперед і писалася з таким завданням, не на один рік — вкидання в майбутнє. Ну і вона повинна бути різкою. Важко людини зрушити. Маса була статей про null про геттери-сетери. Ти можеш погуглити, не один я це пишу. Чому мої викликають такий флейм, у мене про геттери-сетери триста коментів за півроку, а у шановного Аллена Холуба за десять років пару коментів? Тому що він говорить м'якше. Він каже «Намагайтеся триматися від них подалі, не використати їх». А я кажу «Якщо ти використовуєш їх, то ти дурень». Природно, це викликає реакцію і спонукає до змін.

Барух: Ти зараз ставиш дві суперечливі цілі. З одного боку, ти говориш про инкрементальном зміну людей, а з іншого, про кидок на 20 кілометрів… Ось дивись — Мій особистий фідбек — я прочитав, насолодився уявним експериментом і забув, бо так писати зараз я точно не буду. Мені дуже сподобалось, було дуже цікаво, я розім'яв мізки, але що я прийду на роботу і почну писати так, не виникло думки ані разу — на відміну від того, як я прочитав твій пост про null'и і подумав: «треба мені ось цього постаратися менше тепер робити». Тому що я працюю в команді, мій код повинні читати, і якщо я зараз закоммичу в Git код «Yegor Style», то після code review мені нічим буде годувати сім'ю. А якщо я приберу null'и, мене тільки похвалять. І тут у тебе, наскільки я бачу, є конфлікт цих двох цілей — щось реальне, що можна зробити завтра, і концепція, з якої не можна нічого зробити завтра, якщо тільки не займаєшся опенсорсом собі в задоволення.

Єгор: Це твоя позиція, а ось, наприклад, Антон antonarhipov Архипов написав рев'ю, що задумався над тим, як його власний код виправити.

Барух: Ха, ну ти навів приклад, «код Антона Архипова»! Антон на даний момент — провідний продакт-менеджер в ZeroTurnaround, і він не пише код в продукт. Він не штатний програміст. Він пише багато коду в опенсорсе, він робить кодревью, але це не той чоловік, який прийшов, надів навушники, хряпнул кави, і до вечора у нього вісім годин онучі коду виходять, який потім потрібно тестувати, интегрейтить, ревьюить, підтримувати…

Єгор: Ти начебто теж не такий.

Барух: Я теж не такий, але я ставлю себе на місце програмістів в команді, і я розумію, що ні, я ніколи цього не зроблю. Те, що я прочитав у книжці, це не просто прикольно, це супер-круто, причому, як на мене, найкрутіше — це настільки несхоже на все, що ми робимо і, тим не менш, має сенс. Але я почитав, я закрив і мене це звичайно збагатило, але нічого такого, що завтра я можу піти і написати там немає, тому що книжка натякає, що це одна концепція, що це все має працювати разом, на відміну від розрізнених блог-постів. В цьому є краса, тому що ти побудував загальну концепцію, і в цьому є недолік, тому що я не відчуваю себе вправі взяти один шматок, і проігнорувати інше, я таким чином порушую концепцію, це неправильно! У блозі в тебе все це окремо, я захотів — погодився з null'ами, захотів — не погодився з сетером. Книжка — це концепція. З концепцією я чи погоджуюся цілком, чи ні.



Єгор: Згоден, є така проблема. Але в блозі все розпорошено, і були люди, які говорили прямо протилежні речі: от ти нам розповідаєш про тут якийсь шматок, тут якийсь, а воно все кудись зведеться у тебе? Що ти взагалі думаєш про ООП, як повинен виглядати об'єкт, ти можеш хоч раз написати цілий код? Тобто люди шукали якоїсь цілісності. Тому книжка підсумовує.

Барух: цілісності є безумовний плюс — з книжки ми розуміємо, що таке «ООП від Єгора». Але повертаючись до твоєї мети змінити розробників one step at a time — воно не там. І може бути потрібно і те, і інше. І здається в процесі цієї розмови у мене з'явилося деяке розуміння, що для встановлення твоєї credibility потрібно, щоб з одного боку, люди дізналися, що у людини є концепція, книжку, врешті-решт написав, не пройдисвіт, а з іншого боку, практичні кроки, які можна зробити зараз, якщо конкретно ці кроки вам підходять і подобаються… Ось тобі порада: береш цю книжку, яка концепція, і в кінці кожного параграфа у тебе буде щось типу: «Хлопці, я розумію, що у вас зараз вибухне мозок, і я розумію, що ви не зможете використовувати завтра, а ось це ось те, що буде написано далі — ось це зможете застосувати у коді без небезпеки бути вбитим стільцем на код рев'ю». Не просто посилання на блог, а сформулированый practical advice на основі прочитаної голови. І тоді виходить деяка комбінація і цілісної картини, і якихось маленьких кроків, які можна зробити сьогодні.

Єгор: Це гарна думка, може бути, дійсно так зроблю.

Барух: І ось тоді це, напевно, зводить дві протилежні концепції.

Єгор: Я згоден, я спробую це зробити. Може бути, не прямо в книжці, але думка хороша. У мене було багато коментів до книжки, люди кажуть «мало практичних прикладів про те, як нам жити». Ти ось взяв і показав нам два класу, це цікаво, але у нас клас на дві тисячі рядків, як шістнадцять рядків твого класу перенести на наші величезні онучі коду. Є такий concern.

Барух: Мені було б цікаво бачити не тільки другої, але й другий revision першого. Які будуть зроблені висновки з першого тому, як це буде представлено. Ось ці практичні поради — це те, чого мені дуже не вистачало в книжці: для мене вона була абстрактним конем у вакуумі і абсолютно уявним експериментом. І побачити, як revision цієї книжки змінить саме це, було б цікаво.

Єгор: Буду працювати.

Барух: Що ми ще не обговорили? Які плани на майбутнє?

Єгор: Я буду на Java Day в Києві, там будуть два моїх доповіді, не стосуються моєї книжки, що не стосуються ООП, і discussion board як раз про ООП з вищезазначеним Женею Борисовим. Я думаю, цієї дискусії багато чекають. На JPoint'е вийшло щось спонтанне, але була реакція досить агресивна, і я був недостатньо підготовлений.

Барух: Ось так, це правильно, доповіді по «твоєму ООП» і по книжці повинні бути дискусійними, круглими столами. Я дуже радий, що в Києві якраз такий формат вибрали.

Єгор: Так в будь-якому доповіді вони починають зі мною дискутувати на четвертій хвилині доповіді!

Барух: Вооот. А тут у тебе як раз і буде «п'ять слайдів, а тепер давайте рубатися». І все буде культурно, модератори мікрофони носять, а не зоопарк.


Люди не розуміють фундаментальних речей, а без цього складно щось будувати.


Єгор: Мені ще складно презентувати на конференціях, тому що, коли читаєш всю книжку, то все добре, а коли починаєш шматок якоїсь видавати, то у мене не завжди добре виходить. Перед тим, як навчити чогось, потрібно навчити чогось ще. Я намагаюся розповісти про ORM, але для цього потрібно розповісти ось це і ось це, а часу немає. Люди не розуміють фундаментальних речей, а без цього складно щось будувати. Тому я не знаю точно аудиторію, наскільки вони готові. Непоганий у мене доповідь, єдиний, яким я був задоволений — це було на Java Day в Мінську, де я розповідав про ООП в цілому і наводив приклади. У ньому було все гладко, і питання були в тему, але це був останній мій доповідь того турне. Коли кажу про практичні речі, про ORM, це біда вже.

Барух: Це так, тому що під це у тебе немає часу підвести теоретичну базу, а теоретична база в твоєму випадку значно цікавіше, ніж конкретно твоя думка про те чи іншому фреймворку. Тобі потрібно давати теоретичні доповіді з прикладами. Що ще у тебе зараз?

Єгор: Ще у мене буде виступ на конференції Oredev в Швеції. Подивимося, що Європа скаже, що у мене ще не було такого досвіду. Я спробую підготуватися, це буде та ж тема, що і на JPoint'е, але я спробую її зробити у форматі дискусії або коротше. Але ти знаєш, європейська публіка більш пасивна, ніж наша.

Барух: Північна Європа — тим більше. У Швеції у тебе буде все дуже спокійно.

Єгор: У нас прямо шквал питань, що так і повинно бути, так?

Барух: — Звичайно.

Єгор: Для мене це було відкриття. Ну і пишу другий том, не знаю, коли його закінчу, але до нового року він точно вийде. Там буде про ORM багато, там буде про MVC — точніше, проти них. Там буде про анотації, про монади, про іменування змінних і ще про щось. По главам пишу, зараз ORM закінчую.

Барух: Спасибі величезне, побачимося.
Джерело: Хабрахабр

0 коментарів

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