1. О станции
2. Платформы
3. Капитан
4. Стек

О станции

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

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

Её название подчёркивает исследовательские цели проекта, влияющие на саморазвитие экипажа:

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

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

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

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

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

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

Отсутствие монетизации делает станцию независимым проектом, с которым невозможно никакое экономическое сотрудничество:

• Станция не размещает у себя заказную рекламу, не занимается никакими заказными обзорами.
• Станция не принимает бесплатные подарки любого рода, технические или иные.
• Станция использует ровно те технологии, которые подходят к её текущим задачам, не продвигая, не хваля и не рекламируя их, а равно никакие другие. Меняются задачи - меняются инструменты их решения.

Чужеродную и вставляемую рекламу со стороны самих социальных сетей и платформ станция контролировать никак не может, но никак и ничем с ней не связана. В случае нарастания проблем и жалоб станция может покинуть такие ресурсы, как дискредитирующие саму станцию.

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

Платформы

КСА - распределённая система, бортовые журналы которой копируются в разные соцсети.

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

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

На сегодняшний день станция работает над генераторами контента, создавая себе исследовательские инструменты, лишь зарождаясь как техноблог, тестируя при этом разные соцсети, появляясь в них и покидая.

Этот сайт появился первым, теперь он служит хранилищем сложных и объёмных техноотчётов, которые выходят редко в силу их трудоёмкости, обычно подводя итоги эксперимента или исследования.

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

Цель - активное использование видеоконтента, имеющего много преимуществ в сравнении с текстовым, особенно по экономии времени. Но видео пока ещё очень мало и Youtube канал постепенно наполняется наиболее качественными, отборными видеозаписями из девлогов, подготавливаясь к своему запуску.

Список активных платформ продублирован в правой панели сайта, которая смещается (должна) в самый низ на небольших экранах.

Капитан

Мой путь в IT начался в далёком 2011 году. На дальнейшую эволюцию и формирование моего технологического стека - набора используемых IT-инструментов и языков программирования, повлияло множество самых различных факторов.

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

Основная проблематика IT-отрасли, как и любой другой - сложный баланс между широтой и глубиной знаний, что противоречиво в своей сути: широкая общая квалификация ведёт к ошибкам в тонких нюансах, которые она не покрывает, а глубокая специализированная упирается в комплексность задач, требуя множества знаний из других наук и областей. Равноценное же сочетание обоих стратегий управления знаниями очень проблематично как в силу огромного объёма информации, так и из-за ограничений по времени, памяти и прочим ресурсам человека, упираясь в очень неприятное свойство психики - забывание.

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

Поскольку любая система в IT - сложная система, то в ней начинают проявляться самые разные системные эффекты. От взаимодействия простых частей друг с другом появляется новая сложность - эмерджентность, затрудняя соблюдение универсальных принципов навроде SOLID и GRASP: распределение ответственности, сохранение малой взаимосвязанности, высокой специализации компонентов системы. Это вступает в конфликт с сохранением архитектурной простоты, а в случайных местах начинает накапливаться непредсказуемость и хаос - энтропия, также требуя её компенсации в виде усложнения какого-то другого участка системы, либо уже системы с ней связанной, создавая замкнутый круг.

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

Всё это создаёт трудноразрешимые проблемы от тесно связанных друг с другом:

1. Фундаментальной диалектической противоречивости любого технического решения: если решается одна проблема, то обязательно добавляется какая-то другая, обычно не одна.
2. Системных эффектов внутри сложных систем.
3. Конфликтов с другими системами, особенно экономической.
4. Недостатков той или иной стратегии управления знаниями.
5. Ограничений и особенностей человека.
   и т.д. и т.п.

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

Усугубляется всё и цикличным характером развития любых систем: за этапом подъёма и развития неминуемо следует спад и деградация, отчего множество компаний со временем теряют былое качество своих IT-продуктов, деградация которых неотрывно следует за деградацией самой компании как сложной системы в силу различных системных, психологических, экономических и прочих эффектов.

В итоге мы получаем IT-инструменты с хаотичным распределением энтропии в многочисленных сложных подсистемах, что повышает непредсказуемость и нестабильность их управления с работой, повсеместно создавая множество справедливых жалоб на IT со стороны пользователей и не только: крайне низкое качество части IT-инструментов раздражает и самих разработчиков, меня в том числе. Причём из-за постоянного хаотичного наслоения абстракций друг на друга с годами всё будет становиться ещё хуже и хуже.

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

В случае использования сложной системы создаётся перенос всех проблем на конечное звено в цепи его использования: если команда А создала язык программирования, Б написала на нём библиотеку, В сделала на этой библиотеке фреймворк, а Г построила приложение, то все ошибки суммируются и переносятся по цепочке на последнюю: A->Б->В->Г. На практике длина такой цепочки намного и намного больше, а чем она сложнее и длиннее - тем больше проблем.

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

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

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

Такие нестыковки всячески стараются маскировать маркетингом, спамя огромным количеством материалов об успешно решённых задачах, преимуществах оригинальных решений и технической силе команд. Однако практика вскрывает обратное: ресурсов очень много, да вот только результат получается несравнимо слабый, целиком попадающий в закон Парето 80/20, где всё внимание уделяется миллиону несущественных мелочей, а самое важное упускается либо реализуется максимально кривым образом.

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

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

Или же IT-продукт работает на задачах, требующих высокой производительности, но из-за сложности и наслоения абстракций достичь её невозможно. Мелкие оптимизации не помогают, а значительные не позволяет ни язык, ни фреймворк. Если же продукт очень хорошо оптимизирован, то он может затруднять расширение или кастомизацию, которая должна следовать многочисленных ограничениям. Или же продукт имеет огромное количество настроек, которыми из-за их количества и сложности невозможно пользоваться, либо же не имеет настроек вообще, а должен. И т.д. и т.п.

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

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

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

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

Как и в IT, масштабирование системы знаний под более высокие нагрузки требует различных тонких оптимизаций и совершенно других алгоритмов.

Стек

Так, мой стек (набор используемых IT-инструментов) прошёл несколько эволюционных этапов, на каждом из которых я не учитывал какой-то важный фактор:

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

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

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

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

5. Поддержка знаний постоянной практикой в виде пет-проектов для уменьшения забывания, повышения роста квалификации и поддержки IT-областей, которые в повседневной работе мало или вообще не используются. Однако проблем добавилось ещё больше: каждый язык программирования очень трудоёмок и содержит в себе огромнейшее количество нюансов, которые нужно помнить и практиковать.

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

7. Принятие разброса знаний по разным наукам и областям, причём часть из них находятся в гуманитарных. Эффект Даннинга - Крюгера суров: чем ниже в чём-то квалификация, тем болезненней ошибки в т.ч. в связанных науках и областях. Так, обучающий материал, да и готовый продукт, инструмент, что угодно может быть очень высокого технического качества с учётом малоизвестных другим деталей и нюансов, но не делать поправок, например, на какой-то простейший наивный системный или психологический эффект. Эта грубая ошибка снижает практическую ценность до нуля или даже с заходом в отрицательный диапазон полезности: "гладко было на бумаге, да забыли про овраги", создавая классическое расхождения теории с практикой. Однако потери времени на другие науки еще больше осложняют управление знаниями и тайм-менеджмент, делая оптимизации в п.6 смешными, примитивными и, что самое главное - недостаточными.

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

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

По итогам этих экспериментов мой стек со временем эволюционировал в классическую слоистую структуру, чем-то напоминающую "луковую" архитектуру (Onion architecture) Палермо, как и любые схожие "слоистые" системы в т.ч. и в физическом мире. Языки программирования очень тщательно подогнаны друг к другу с поиском синергий, а каждый выполняет строго определённый круг задач.

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

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

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

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

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

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

Часто мы становимся теми, с кем находимся рядом, подравниваясь под других: будучи в окружении сильных, становимся сильнее, а находясь рядом со слабыми - слабее, ибо сильные тянут вверх, а слабые - вниз. Отсюда и мой особый интерес к наиболее сильным коммьюнити в IT, чья квалификация порождается выживанием, формируясь в суровой борьбе за своё существование на фоне многочисленных проблем и ограничений в ресурсах - финансовых, людских и прочих. Выживая, они доказывают свою квалификацию делом и результатом, а не маркетинговым булшитом, популярным в IT и не только в нём.

В-четвёртых, язык должен быть схож с синтаксисом С-семейства для переиспользования между языками идей и кода, так и уменьшения проблем от переключения между разными синтаксисами и возникающих из-за этого ошибок в коде. В более сложных проектах нужно собирать код по всему IT, портируя его с C, C++, Java, C#, JavaScript и прочих языков, накопивших за долгие годы огромные кодовые базы. Нейросети уже более-менее могут переписывать код с одного языка на другой, но не всегда и не весь.

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

Также в сложных ООП-иерархиях с внедрением зависимостей из-за высокого расслоения кода и делегации может быстро теряться контроль за жизненным циклом объектов, требуя сборщик мусора либо его аналога, но с возможностью отключения. В процедурном низкоуровневом коде мне нужна высокая совместимость с С, но и возможность улучшать безопасность и не только, добавляя срезы массивов с проверкой границ, контроль за временем жизни в областях видимости, перегрузки операторов для реализации умных указателей и прочего, перевод части расчётов в compile-time и т.д. и т.п.

На данный момент всем моим требованиям наиболее полно отвечает D (Dlang), в котором я также вижу попытки решения многих технических проблем, в которые я упирался.

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

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

Или же, например, очень популярная архитектурная проблема - иммутабельность. Советы по изначальному проектированию иммутабельных структур не выдерживают особой критики из-за уничтожения гибкости API, которым сложнее пользоваться и расширять. Мутабельные структуры, в свою очередь, не любят многопоточность, что склонна внезапно появляться из-за смены требований, достижения потолка производительности и прочего, отчего её нельзя предсказать и нормально спроектировать сразу. Корректная синхронизация же сложного и зрелого мутабельного кода очень проблемна.

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

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

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

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

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

Здесь мне интересна богатая инфраструктура Java и очень большим бонусом в виде Groovy. Эта выгодная связка с Groovy дала мне возможность быстро решать некоторые задачи, максимально уменьшив время на сопровождение, что критично при наличии в стеке сложного системного языка.

Наличие JavaFX позволило заполучить достаточно мощный десктопный фреймворк, не отставая от наиболее технологически продвинутых конкурентов из мира C#. GUI-тулкиты крайне универсальны и способны улучшить практически любой класс задач, начиная от экономии времени в быту и заканчивая рабочими инструментами. Без JavaFX всё могло сложиться совершенно иначе, ибо GUI-тулкит с юзабилити контролов старой школы, отделением вью от кода и GUI-билдером для меня очень полезен.

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

Так, в последние годы меня заинтересовал Dart: легковесный и мощный тулчейн, JIT\AOT из коробки, а относительно высокая схожесть синтаксиса с С-семейством сильно понижает затраты времени на поддержку языка в стеке, облегчая обмен кодом между другими моими С-подобными языками. К сожалению, любое добавление языка в стек приводит к уменьшению времени на какой-то другой, иного пути здесь не усматривается. Поскольку я не могу жертвовать системными языками, то это время было снято с Java, что привело к сворачиванию части проектов и экспериментов с ещё большим урезанием времени.

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

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

Много проблем создаёт подверженность рассуждений и выводов различным когнитивным искажениям, коих бесконечное количество. В IT знаменит "синдром утёнка", от которого очень сложно избавиться, а может быть и вообще невозможно. Но его, как и другие искажения, можно стараться ослабить, например, рассматривая предмет диалектически - в противоречиях.

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

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

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

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

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

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

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

В таких условиях очень и очень легкомысленно быть уверенным в своих силах и знаниях: крайне проблематично учесть все изощрённые требования разных наук, как из-за их количества, так и из-за сложного взаимодействия между собой.

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

Поэтому снова напоминаю, что станция - исследовательский проект, не более. Ну а теперь вперёд, к самым ярким звёздам!