Этот пост посвящён памяти Никлауса Вирта, первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software, и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО.

Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков, а простые продукты импортируют 1600 зависимостей неизвестного происхождения. Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно.

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

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

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

Что такое полиморфизм?

В чём разница между List и Set? Когда стоит использовать первое, а когда второе?

Где можно столкнуться со взаимной блокировкой (deadlock)?

В чём разница между строгой и слабой типизацией?

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

Что мне больше всего нравится в gamedev, так это что большая часть игр и каждый первый кастомный игровой движок бросают вызов устоявшимися стереотипам разработки. Иначе зачем начинать разработку такого сложного и комплексного софта, когда десятки похожих софтин есть вокруг. Конечно такие монстры как Unreal и Unity и десяток монстриков калибром поменьше существенно упростили разработку во многих отношениях, привлекли тысячи разработчиков к созданию множества великолепных игр с использованием готовых технологий, освободив их от ямы отчаяния пустого уровня. Но также не оставляет мысль, что еще больше игр они похоронили. Невзирая на весь функционал и мощь U/U люди часто застревают в рамках, о которых они даже не подозревали. На протяжении многих лет наблюдаю как оригинальный контент в большинстве случаев убивается ассетсторами, если там есть что-то близкое или похожее к нужному объекту, функционалу и виду. Не поймите мои слова неправильно, я обеими руками за магазины ассетов и любых других ресурсов, скриптов и технологий, но беря что-то в магазине за доллар, вы уже с большой вероятностью не сделаете свое. Или сделаете конечно, но позже, но до этого "позже" еще надо дожить, а пока что у вас будет всё как у всех: одинаковые паттерны, одинаковые текстуры, одинаковое поведение, одинаковые модели... и одинаковые игры? Что тогда остается своего - уникальные механики и впечатления. В другом случае не было бы игры, вот только проблема, что сначала люди видят картинку. Хорошо если игрок через полчаса-час доберется до уникальных механик, одинаковая картинка вызывает в памяти игры в которые вы уже играли, а уникальная механика так никогда может быть и не увидена в игре.

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

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

В этой статье будут вещи, с которыми вы можете не согласиться. Это нормально. Это просто моё мнение, а так как я уже вышел на пенсию, то больше не представляю опасности ни для интервьюеров, ни для инженеров Google при принятии решений о найме! ;-)

Добрый день всем, дорогие читатели!

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

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

Как сказал мой добрый друг-программист про Factorio: "Эту игру создали программисты для программистов" и эти слова плотно въелись в мою память. И реально игра в эту игру очень сильно напоминает процесс разработки ПО: можно просто строить как попало и прийти к полностью запутанной и сложнообслуживаемой системе, а можно подойти к вопросу с умом изначально и в итоге получить производительную и легкую в обслуживании систему (Прям как в жизни!)

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

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

Как знают мои постоянные читатели, кроме основного блога я веду на Хабре ещё один, где публикую переводы с английского, посвящённые строгим IT-темам. 21 января я вывесил там материал об игре «Жизнь» Джона Конвея, рассказывающий о создании минимальной жизнеспособной единицы по правилам этой игры. Активное обсуждение статьи, в котором поучаствовал даже уважаемый Павел Гранковский @Pavgran, коммиттер игры, упоминаемый в посте, вернуло меня к мыслям о сборке минимально жизнеспособного биологического генома. Очевидно, что современные возможности секвенирования ДНК и амплификации генов переводят такую задачу в разряд решаемых. На пути к созданию полностью синтетических организмов следовало бы освоить создание полусинтетических, основой для которых мог бы послужить именно такой минимальный геном. Ниже я расскажу о перепрограммировании геномов, искусственном и естественном редуцировании геномов, а также о перспективах таких исследований.

Любое приложение, которое можно написать на JavaScript, будет в итоге написано на JavaScript.

Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp. — Десятое правило Гринспена

1. Это очень мощное средство для «непосредственного программирования», то есть указания компьютеру, что делать.
2. Большая часть однострочника посвящена grep/awk/cut/tr, которые каким-то образом выковыривают и приводят в человеческий вид вывод предыдущих утилит.

1. Неэргономичной консолью виндов (Shift-PgUp где, а? говорят, Ctrl-PdUp в новых версиях)
2. предложением пойти и выучить .net для того, чтобы нормально с методами работать.
3. Отсутствием под большинство операционных систем

Идея

1. Утилиты, которые примут типовые форматы на вход и сконвертируют их в json.
2. Утилиты, которые позволят в pipe'е манипулировать с json'ом.
3. Утилиты, которые приведут json в „обычный“ формат.

Для затравки

Привет, Хабр! Представляю вашему вниманию перевод статьи "Learning Parser Combinators With Rust".

Эта статья учит основам комбинаторных парсеров людей, которые уже знакомы с Rust. Предполагается, что никаких других знаний не требуется, а всё, что не имеет прямого отношения к Rust, а также некоторые неожиданные аспекты его использования, будут объяснены. Эта статья не поможет вам выучить Rust, если вы его ещё не знаете, и в этом случае, вы, вероятнее всего, не поймёте комбинаторные парсеры хорошо. Если вы хотите изучить Rust, я рекомендую книгу "Язык программирования Rust".