1. О станции
2. Сотрудничество
3. Контакты
4. Платформы
5. Контент
6. Капитан
7. Стек капитана

О станции

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

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

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

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

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

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

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

Сотрудничество

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

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

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

Контакты

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

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

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

Платформы

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

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

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

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

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

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

Контент

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

1. Программирование. Станция - это IT-проект. Информация и её обработка критичны при усложнении структуры знаний. Программирование - основа, фундамент станции, определяющий её суть. Всё основное время уходит в него, оставшееся переходит в п.2.
2. Электроника. Из-за роста абстракций программирование местами теряет технико-инженерные черты, заставляя искать их в связанных областях, латая дыры в знаниях. Вне обработки информации программирование вообще ничего не может, лишаясь всякой самостоятельности при усложнении задач. Электроника - важный практический результат исследований станции, технически реализованное программирование. Остаток времени отдаётся в п.3.
3. Технические науки, не покрываемые предыдущими, а также биологические направления - важный источник аналогий, идей из архитектуры живой природы, которые можно переносить на технические. Наличие биоотсека делает станцию более комплексным и сложным проектом, оправдывая с гордостью носимое имя. Без него станция будет неполноценной.

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

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

1. Построение информационного отсека: исследовательские и обучающие инструменты.

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

2. (Ещё не разблокирован)
3. (Ещё не разблокирован)

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

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

Текущий этап - подготовительный, тренировочный.

Капитан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С противоречиями работают разные методологии, например, всем известная теория решения изобретательских задач (ТРИЗ) с алгоритмами (АРИЗ) Альтшуллера. Но в них самих тоже есть противоречия: вводя методичность и повышая эффективность решения, они следом резко повышают свою трудоёмкость, без каких-либо гарантий на потраченное время, иногда вырождаясь в классическое бумаготворчество без полезного результата. Либо же результат может создать новых проблем больше, чем решить старых: что-то выдумать достаточно легко, но, как говорится, есть нюанс. Не каждое выдуманное решение - решение.

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

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

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

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

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

Стек

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому здесь мне была интересна богатая инфраструктура Java с большим бонусом в виде Groovy. JavaFX позволил заполучить десктопный фреймворк, не отставая от наиболее технологичных конкурентов, что было необходимо мне при переходе на Linux. GUI-тулкиты универсальны и способны улучшить практически любую сферу деятельности, начиная от экономии времени в быту и заканчивая рабочими IT-инструментами.

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

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

Конечно же, снижение интереса привело меня к отказу от Java. Но если заменить Java-бэкенд достаточно легко, то заменить JavaFX оказалось немного тяжелее, ибо GUI-тулкитов очень мало и они более специализированные с уклоном в шаблонизацию или код, веб, мобайл или в то и другое, но очень посредственно. Немного иронично, поскольку в самом Java-комьюнити (особенно СНГ) JavaFX не особенно популярен. Это заставляет меня использовать JavaFX до сих пор.

Тоже самое с Groovy. Groovy соблюдает эдакий условный аналог подстановки Лисков - не замещает синтаксис и многие аспекты поведения базового языка - Java, а дополняет его. Groovy-код при желании можно использовать как Java-код, как и наоборот, балансируя между разными синтаксисами и возможностями. Это выглядит верным техническим решением по расширению одного языка другим и наблюдается повсеместно. Например, Dlang (как и С++) стараются сохранять множество совместимостей с С, при этом расширяя его, делая прототипирование с использованием кодобазы расширяемого языка очень быстрым и удобным, как и интеграцию туда-сюда в неё и обратно. Поэтому Groovy мне не так просто заменить, как кажется.

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

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

Изначально я ожидал очень высокой универсальности, но практика показала, что со временем экосистема переориентировалась на Flutter, не стараясь особо раскрыть свой потенциал в других областях, хотя могла. Произошло массовое вымирание веб-фреймворков (вспомним Angel, имя которого символично), как и смерть множества интересных мне проектов, например, Dartino. Перспективные специализированные проекты, например, легковесный движок 2D веб-рендеринга StageXL не особенно набирали популярность, несмотря на свои преимущества.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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