усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
Голые короли IT
усы2
tonsky

Моя программистская карьера началась бесхитростно — там, куда взяли. Взяли делать бэкенд на Джаве. Ладно. Все равно я не знал, о чем надо мечтать. Потом немножно Питона. Распределенные системы. Erlang. Щепотка Perl-а. Последние два года программирую интерфейсы. Расчет был, конечно, что я приду на все готовое — разберусь и пойду дальше. Как бы не так. Готового, на самом деле, нигде не было. Всегда превозмогание. Молодая индустрия. Ладно. Но вот странно, как люди этого не ощущают. Есть метания. Мода. И люди прям всей головой и сердцем отдаются. Может, это только у самых шумных, конечно, но каждое новое веяние как последнее. Не хватает какой-то скромности, умеренного энтузиазма.

Я помню энтузиазм по поводу XML-я. Потом тот же энтузиазм по поводу Java-аннотаций. Я еще думал: окей, мы пишем по-другому, но пишем-то то же самое. Неужели это может чью-то жизнь изменить? Верили, что может.

Hibernate помню, и эти убойные аргументы: а что если мы базу данных захотим поменять? И все верили, и шли на поводу, и полностью всё приложение переписывали, лишь бы не было SQL-я. Да, трудно становилось через какое-то время, и начиналась борьба не за код, а за выживание, с самим Хибернейтом. Но никто трезво на это не смотрел, казалось, что если проблемы, это мы недопонимаем и надо еще бороться. Естественно, консультанты, рекомендации, best practices.

Помню, как мечтали о JavaEE, и я тоже мечтал. Оказалось, что это тот же Хибернейт, только нужно еще раз все переделать. Переделать, чтобы получилось так же. Наивные были, молодые. О чем больше всего говорят, то и используем. Смешно — где сейчас Хибернейт, а где SQL, да?

Помню безумие вокруг Inversion of Control, помню как читал гайд к Guice, в котором писали: «сейчас мы вам объясним, как надо писать программы. Скорее всего, вы обнаружите во время рефакторинга, что одно тянет за собой другое, и чтобы внедрить IoC, вам понадобится переписать весь код. This is a good thing». Это this is a good thing очень въелось мне в память, я отчетливо в тот момент почувствовал, что нас всех дурят. Но где было мое смутное ощущение, и где лидеры индустрии. Оказалось, лидеры тоже бывают голые.

Помню нездоровый энтузиазм по поводу ООП. Были долгие внутриконторские споры, как правильно делать иерархию классов. Какой паттерн применить. Оказалось, паттерны нужны пару штук на всю архитектуру, а пишу я сейчас на языке без иерархий вообще. Тогда это было немыслимо.

Или вот: в ООП меня очень смущал вопрос «Paper.writeWith(Pen) или Pen.writeOn(Paper)». Тогда мне казалось, что ООП пригодно для всего, пóлно, следовательно правильный ответ существует, просто я не до конца разобрался, и нужно напрячься. Сейчас я расслабился, вижу, что у каждой концепции есть границы, когда что-то в нее не лезет, это проблемы концепции, а не того, что в нее запихивают. Это нормально. Даже если очень хочется быть адвокатом какой-то идеи, честность, хотя бы перед собой, важнее. Не надо мутить воду. Если функция удобнее класса — берите функцию. В этом больше честности и смысла, чем в следовании OOP-way. Нет никакого OOP-way. Нет никакого Java-way, Ruby-way, NodeJS-way, FP-way, microservice-way, Docker-way, не надо приносить им жертвы. Концепция это инструмент, а не религия или образ мысли. И не надо доставать ключи из словарей через Promise.

Но крестовый поход длится и по сей день. Концепции новые, адвокаты все такие же. Читал на днях:

How do you approach this problem with Rx? Well, to start with, (almost) everything can be a stream. That’s the Rx mantra.

Then we will have created a beast called “metastream”: a stream of streams. Don’t panic yet. A metastream is a stream where each emitted value is yet another stream.

Flatmap is not a “fix” and metastreams are not a bug, these are really the tools for dealing with asynchronous responses in Rx.

Сравните с гораздо более адекватным:

Note: It is usually best to use signals as little as possible. When it comes to writing nice modular code, you should primarily use normal functions and values. If you find yourself stuck with a signal of signals, ask yourself “how can I model this explicitly with functions and values?”

Вот человек тоже адекватно пишет (лучше всю статью прочитать) про то, что если вы придумали асинхронный IO, то как его не маскируй, получится не очень:

People in the Node community have realized that callbacks are a pain for a long time, and have looked around for solutions. One technique that gets a bunch of people excited is promises, which you may also know by their rapper name “futures”.

But, honestly, it’s like the difference between being punched in the gut versus punched in the privates. Less painful, yes, but I don’t think anyone should really get thrilled about the value proposition.

Такой трезвый взгляд очень важен, но важность понимаешь не сразу, нужен опыт в пять-десять лет, чтобы видеть, как работает общественное мнение и мода. Люди склонны путать новый способ делать вещи с деланием новых вещей. Я только рад, когда новые концепции помогают решать новые проблемы. Но, пожалуйста, давайте не искать проблем там, где их нет, и не усложнять то, что мы решать уже умеем. С аскетичным арсеналом можно сделать многое, а проблемы, когда понадобятся, сами нас найдут.


Новых концепций меньше, чем новых инструментов. Но какие-то инструменты полезнее в каких-то случаях. Скажем, если надо подправить код так, чтобы лучше выходили unit tests, то IoC вполне удобная концепция; а переписывать код под IoC просто потому что так модно? Странно.

Почему просто модно? Верили, что да, тестирование будет, мм, конфигурация через XML, что-то еще, наверное. Но я вот пишу безо всякого IoC и в принципе нормально, и тестируется, и конфигурируется, и всё такое

Все же культура тестов весьма полезная практика. В разумных пределах.

Полезные практики тоже бывают, конечно. Правда, бывает, что хорошая и полезная практика превращается в религию и уже в таком виде завоевывает ума людей. С тестами так было, кажется, с Ruby началось

(Удалённый комментарий)
Вполне возможно. Беда, что рассказывают громче всего те, кто рассказывает, а не те кто умный

без темы (Анонимно) Развернуть
Как мне кажется, ценить простоту начинаешь в проектах, которые нужно хоть как-то закончить из-за технических ли проблем, или из-за предметных.

Весь пост напоминает мне метания в последнем проекте: flux->reflux->попытки использовать cljs->выпиливание иммутабельности и переход на тупой и понятный mobx.

Если есть типовые, несколько раз решенные задачи - хочется привнести пикантную нотку чего-то нового. Иногда это приводит к догматизму, и желанию все делать так как велят текущие веяния (и никак иначе!).

upd. А по поводу Rx - все это хорошо, пока ты не начинаешь пытаться сделать динамические подписки/отписки вкупе с COM (или еще каким интеропом). Вот там веселье начинается.

Edited at 2016-09-02 12:52 (UTC)

Эксперименты это хорошо, но обычно плохо совместимы со «сделать». Или нужно что-то получить минимальными усилиями (и тогда надо брать самые скучные технологии, какие есть), или хочется поиграться, но не все сразу.

Всё правильно замечено. Короли-то голые. И это проблема.

Интерфейсы значит. Два года. Интерфейсы. Два года. Дай-ка я тебе немножко будущее предскажу. Обойдемся даже без картинки со Стивеном Фраем )

2 года - это мелочи, это даже не начало, это вводная часть достаточно опасного для психики пути. Как только человек по фидбеку понимает, что он буквально двумя пикселями может влиять на других людей, тут и начинается ) Заносить может по разному. Обычно вначале начинается "имею мнение, хрен оспоришь", потом сильно пухнет ЧСВ. А чего ему не расти, короли-то голые: при чтении даже самых понтовых западных патриархов голова гудит от фейспалмов. Устав от неидеальности материального мира, в особо запущенных случаях, люди начинают сочинять жизнь в фотошопе: сначала несуществующие сайты-визитки, потом мебель, интерьеры, потом рендеры концептов машин, телефонов и прочая виртуальщина. Особо упоротые сбиваются в стаи (см. например у лебедева) и начинаю гнать эту пургу коллективно, называя её промдизайном. У некоторых, впрочем, проходит. Я например, излечился после попытки написать книгу о дизайне. Одной главы хватило, отпустило.

Морали не будет, это просто взор в даль.

без темы (Анонимно) Развернуть
У меня так программистом не получилось стать. В самом начале прочитал про ООП, написал немного ООП кода, и так и не понял что именно упрощает группировка переменных и функций по классам с учетом явного усложнения. Все что нашел в книжках это "это правильно", "ооп упрощает" и т.п. Та же беда с паттернами, смарт пойнтерами, декораторами и тому подобными "упрощающими" штуками.

Вот кстати да, когда убеждают аргументом «так правильно» вместо настоящих причин — беда

(Анонимно)
А кто одет?

(Анонимно)
Трезвый взгляд. Готов подписаться под каждой буквой этого текста.

Ну да-ну да-ну да.
Но вообще недурно бы еще и задумтаться, отчего все ходит по кругу. Явно ж неспроста.

Ну люди-то хоть и каждый раз новые, но устроены одинаково. Вот и ходят

Помню-помню, всё было. Почти всё вышеперечисленное более-менее безболезненно удалось избежать. Ещё к списку можно добавить REST и микросервисы. Такая же безапеляционная хрень.
А ещё помнишь, эпопею с общей шиной: COM, COM+, Corba, .NET сборки... И люди мучались, переписывали с одного на другое.

С Corb-ой меня пронесло: в универе еще рассказывали, на работе я её уже не видел.

Сейчас к Вам набегут поклонники функционального программирования, и объяснят, что сегодня без монады - никак нельзя. Потом они передерутся на тему "что такое монада".

Стало быть,
write(on=Paper, with=Pen)

Бывает, узнаешь, какие ГОВНА работают внутри успешных швейцарских банков, или что бюджет корпораций рассчитывается vba-макросами в Экселе, или как вообще зарабатывают капиталы - и сразу две мысли:

1. Как страшно жить
2. "Правильного" софта почти не бывает

Но это всё не важно, мир как-то работает, в целом.

Утверждение - "это говно" по сути кстати тоже самое, что и утверждение - "эта новая технология вас спасет" Только с обратным знаком.

(Анонимно)
Тема близка к сердцу, но мне кажется статья освещает проблему односторонне. Для того что бы было честно, и не казалось что есть плохие и хорошие, давайте добавим примеров:

- Нам статическая типизация не нужна.

- Вот функции, макросы, вот namespaces и immutable структуры - теперь вы будете писать проще код.

- У нас все immutable, есть REPL, нам тесты особо не нужны.

- IoC зло, это вам в вашей Java нужно, а нам - нет. Мы притворимся что проблемы нет.

- Вот Componnet, смотрите, теперь можно писать систему модульно. Так это же вы DI и IoC переизобретаете ? Нееее, DI это у вас в Java.

- Вот макросы, смотрите как прикольно. Ничего что код становится сложно тестировать и понимать.

> У нас все immutable, есть REPL, нам тесты особо не нужны.

Нам — нужны

> Вот Componnet, смотрите, теперь можно писать систему модульно. Так это же вы DI и IoC переизобретаете ? Нееее, DI это у вас в Java.

Кто-то притворяется, что Component это не IoC?

> Вот макросы, смотрите как прикольно. Ничего что код становится сложно тестировать и понимать.

Почему сложно? Кто-то жаловался? Вроде все спокойно к ним относятся

Вирт был прав хотя бы потому, что почти про всё модное говорил 'не нужно'. Но у людей сейчас другие гуру.

(Анонимно)
Какая разница, что писал Спольски?! Он же гей.

без темы (Анонимно) Развернуть
классный пост. таких просто надо побольше и от большего количества людей.

+ the key idea here is: "но важность понимаешь не сразу, нужен опыт".

по собственному опыту, IT индустрия не сильно отличается от "просто жизни", и просто людей, отношений, ощущения и понимания действительности, которые прям сильно меняются каждые лет пять, иногда даже кардинально.

еще есть элемент выпендрежа: если я сделал Rx, я крут: "слушайте сюда..".. и таки слушают :)

плюс элемент надменности: я работаю в Когнитекте: садись, сведи коленки, положи на них ручки.. ничего страшного что ты херово все пишешь, давай я тебе расскажу как надо правильно писать программы на Clojure.

когда гремела Spring, на конференциях Rod Johnson был таким же надменным, но идеи были классные (на тот момент), и сами Interface 21 люди тоже (тогда) были very down to earth и easy to talk to.

когда доходишь до вершины горы на которой сидит мудрец и вот вот он сейчас тебе наконец то скажет в чем смысл твоей жизни, я думаю он говорит: "вот молодец какой, пока лез на гору столькому научился, столько понял. посмотри на всех этих крутых специалистов с вершины горы, зафиксируй этот image, запомни его. теперь слезай, ты готов улыбаться им в лицо, брать их за носик и так делать: "ути пути мой маленький, ну конечно ты прав, не волнуйся так, попей еще водички"..."

Действительно, столько потерянного времени. Понятно же что программистам ничего этого не нужно, никаких ваших классов. Что им действительно нужно - это анимация. И шрифты с ретиной. А писать можно и на ассемблере.

Edited at 2016-09-03 07:37 (UTC)

А где написано что ненужно? Написано, что ничто из этого не манна небесная и не ответ на все вопросы жизни, мироздания и всего такого. Нужно, только в гомеопатических дозах. Пару классов на проект как не написать?

На фронтенде все сейчас намного хуже. За отрицание реакта сжигают на костре пуканов.

а чтобы Вы сказали, юным, начинающим программистам, только начинающим свой путь?

Слушать не кого-то одного, а нескольких: языков, авторитетов, парадигм. Собирать кругозор

> Помню нездоровый энтузиазм по поводу ООП.

эм. а сколько тебе лет? а то ведь это чуть ли не в 1991 году было.

http://tonsky.me/about

Java конкретно была в 2005–2010, но вот с мест пишут, что воз и ныне там https://www.facebook.com/olegchir/posts/1198952403461098

С одной стороны - нет плохих технологий, есть неподходящие под проект.

С другой - концепция "сейчас все по моде переделаем и за пять минут долетим" - у меня вызывает рефлекс выставления таких любитей рефакторинга из команды на мороз гораздо быстрее, чем за пять минут.

Киберпанк - он и есть киберпанк...

Бесплатный сыр бывает только в мышеловке, это же просто альтернативная модель продаж в киберпанке. Если материальные товары тебе впаривают что бы ты их купил, то технологии тебе впаривают бесплатно (тиражировать-то их, в отличие от материальных товаров, можно простым копированием), но что бы ты становился их бетатестером и коммитером-багфиксером.

Ну вот представь - мегакорпорация "X" в рамках одного из своих ключевых проектов столкнулась с некоторыми побочными проблемами и для их решения разработала уникальный фреймворк, при помощи которого идеально эти проблемы решила и проект выстрелил. Затем проект руководство постепенно ужимает в бюджете, но поддерживать-то его нужно - он же ключевой! И принимается решение - фреймворк этот сделать open-source`ным, что бы баги в нём фиксить не самим, а их бы бесплатно для них фиксило большое комьюнити. Для этого нужно желательно как можно большему кол-ву компаний по-меньше (у которых всё равно не те бюджеты, что бы прицельно под свои проблемы с нуля фреймворки разрабатывать), заменить те фреймворки, что они юзали до этого, на фреймворк мегакорпорации "X". Это легко сделать, поскольку все их фреймворки такой же путь прошли и писались тоже не под комьюнити, а под какие-то решения конкретных корпораций, соответственно, у них можно найти массу неудобных моментов и сказать, что мы их решим. Дальше включается сарафанное радио - каждый, кто заюзал у себя этот фреймворк, оказывается кровно заинтересован в том, что бы комьюнити выросло, поскольку чем больше комьюнити - тем больше по сути бета-тестеров и коммитеров, которые исправляют баги и делают новые фичи. Так что все члены комьюнити быстро начинают PR`ить этот фреймворк как панацею от всех бед - даже от тех, которые ещё не случились, а только могут случиться. Но кто бы какие бы фичи не дописывал, как бы не форкался, всё равно не могут изменить базовые вещи, заложенные во фреймворк изначально - т.е. того, что он в первую очередь решает проблемы мегакорпорации "X", и лишь потом уже - всех остальных, по остаточному принципу.
И вывод очень простой - кто технологию ужинает, тот её и танцует. ЛЮБАЯ ТЕХНОЛОГИЯ и даже более того - ЛЮБОЙ ЯЗЫК изначально заточен не под твои задачи и проблемы, а под проблемы того, кто её изначально разработал в рамках своих проектов. Любая новая революционная рас-PR`еная технология лишь постольку-поскольку решает проблемы старых концепций/технологий/фреймворков/языков/библиотек, которые пытается заменить - реальный интерес - это перетянуть коммьюнити под себя, что бы заиметь в лице тебя очередного бесплатного бетатестера, коммитера-багфиксера и т.д. Да, есть отдельные фрики, типа Линуса Торвальдса, Ричарда Столлмана и некоторых других, которые искренне работают на комьюнити, но это - скорее исключение, чем правило (да и то - это ещё большой вопрос, насколько интересы комьюнити в целом совпадают с интересами именно на твоём проекте). А в остальном, никто просто так под твои задачи персонально писать что-то не будет - пишут всегда под свои задачи и по остаточному принципу - под задачи остальных, но PR`ить - будут и ещё как будут, что бы сбросить на тебя support.

Всегда плохо быть в модели догоняющего развития, плохо пользоваться чужими разработками, ощущать себя эдакой рыбой-прилипалой при акулах, гораздо лучше сидеть где-нибудь в MIT или Кремниевой Долине и разрабатывать что-то передовое, что уже у тебя потом подхватывает большое комьюнити... Но этот мир всё-таки лучше, чем какой-нибудь индустриальный, при котором люди не передовых стран голодали и умирали от болезней и в бесконечных локальных конфликтах, при помощи которых передовые страны выясняли между собой отношения...

Re: Киберпанк - он и есть киберпанк...

(Анонимно)
Да, все так, как вы описываете. А Цукерберг - рептилоид, поэтому у него все так просто получается.

(Анонимно)
Очевидно же Person.write(Paper, Pen)

В очередной раз по "молоток и гвозди кругом"? Вам критикуемый вами автор ответил еще до того как вы написали статью -
http://staltz.com/everywhereness-as-a-foundation.html
Неужто не вы не замечали что некотрые концепции становятся резко менее полезными(теряются очень-очень полезные свойства и гарантии) при переходе от использования их в ~100% случаев к использованию в 90% случаев? Вы наверно скажите что это проблема концепций - но ведь без этих концепций нам не достичь требуемых свойств. Создает ли это какие либо проблемы - да создает. Весь вопрос как всегда в том насколько на конкретном проекте мешаются эти проблемы и важны эти свойства. Вообщем это обычный выбор между удобством(отсутвие проблем и удобством написания кода) и корректностью(полезные свойства и гарантии). Как сделать так чтоб и проблем не огребать и свойства полезные иметь - это еще вопрос очень и очень неисследованный. Вот то что вместо решения этого вопрос программисты продолжают холивары удобных штук(императивность и impure, динамическая типизация, макросы) против штук корректных(чистота, строгая стат типизация) - вот это грустно действительно. К слову Elm это одна из удачных попыток сделать решение и удобным и корректным. Но эльм к сожалению или счастью это не язык а DSL, так что эта попытка мало помогает 95% программистов.

Про 100% это сразу вспоминаются адепты юнит-тестирования. А 100% использование технологии оно только в вакууме на уровне хэллоу-ворлдов, и красивая абстракция живет до первого столкновения с реальностью где куча условностей и деталей раскорячивают костылями и подпорками эту самую технологию.

?

Log in