Гиллель Уэйн*, разработчик и консультант по формальной верификации, обратил внимание на статью «20 наиболее значимых языков программирования в истории», которую сам автор называет «нелепой, только что придуманной таблицей». По мнению Уэйна, эта характеристика вполне справедлива: автор таблицы называет Go «наиболее значимым», но не включает в список ALGOL, Smalltalk или ML. И не учитывает Pascal, потому что тот «почти мёртв». Абсурд! Это противоречит всей сути понятия «значимость в истории».

Так давайте обсудим некоторые «почти мёртвые» языки и причины их важности.

Дисклеймер: Да, не все из этих языков мертвы и забыты. Ведь большинство людей слышали о Smalltalk, правда? Также, скорее всего, в этой статье полно ошибок, ведь их легко допустить, когда вы анализируете 60-летнюю историю компьютерных вычислений. Не стесняйтесь возражать, если что-то заметите!

Дисклеймер 2: Да, некоторые из упомянутых здесь языков были «первыми изобретёнными», а другие — «первыми популярными». История — это сложно!

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

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

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

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

(По материалам внутреннего семинара компании МойОфис)

Разработчик под ником Ludic*, автор технического блога Ludicity, сэкономил своей компании полмиллиона долларов за пять минут. Это больше, чем он заработал для работодателей за всю его карьеру, поскольку сфера деятельности, о которой далее пойдёт речь, — обман. Он всего лишь нажал на пять кнопок.

Под катом Ludic рассказывает, как так получилось, и почему ему обидно, что произошедшая ситуация возможна в принципе.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

За два года с момента релиза GPT-3 эту языковую модель использовали в множестве интересных задач — например, для сочинения поэзии, написания футурологических эссе и подготовки научных статей. Но как алгоритм обработки естественного языка может быть полезен программистам?

На этот вопрос в своей новой статье отвечает британский разработчик Саймон Уиллисон* — директор по архитектуре Eventbrite и один из создателей веб-фреймворка Django. Среди различных вариантов применения языковой модели GPT-3 Уиллисон особенно подчеркивает ее способность объяснять, что делает код. По словам специалиста, в этом GPT-3 поразительно эффективна, поскольку явно обучалась на огромном количестве исходного кода.

Под катом — наш перевод материала, в котором автор демонстрирует недавние примеры из своей практики: объяснение кода на Python, JavaScript, SQL, а также работу в рамках GPT-3 с математическими формулами.

*Обращаем ваше внимание, что позиция автора не всегда может совпадать с мнением МойОфис.

В августе нашей компании исполнилось 9 лет. За это время МойОфис прошел путь от амбициозного стартапа до лидера рынка отечественного офисного ПО. Ежегодно мы выпускаем несколько крупных обновлений — только в 2022 году вышло уже три таких релиза с сотнями улучшений. А общее число нововведений, которые появились в наших продуктах за последнюю пару лет, измеряется тысячами.

Реализация новой функциональности практически всегда сопряжена с запросами наших клиентов. Мы проанализировали запросы, поступившие в нашу техподдержку за прошедшие 2 года, и отобрали для рассказа некоторые функции, которые были реализованы в редакторах «МойОфис Стандартный» после обращений клиентов. Подробнее читайте под катом.

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

В этой подборке — не только классические рекомендации книг для C++ программистов. Обычно советуют издания про паттерны, развитие стандарта или успехи большой компании. Но за всем этим изобилием «экспертных советов» и best practices теряется одна простая мысль: язык программирования — это средство выражения мысли от одного разработчика другому, а также средство описания пользовательского API в самом широком смысле.

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

Первые 5 книг этой подборки — в меньшей степени про технику, в большей степени об осознанности деятельности C++ программистов любого уровня. Остальные — «золотой фонд» классической литературы для C++ разработчиков.

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

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

Специально для своего блога Эрик попытался обобщить весь свой опыт в виде кратких советов, которые он хотел бы дать молодым программистам. Под катом — наиболее важные, на взгляд автора, уроки и выводы из его 20-летней карьеры.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

"Запатентовано" уже немало способов шахматного жульничества: кто-то использует телефоны, примотанные к ногам скотчем, и штуки вроде пультов от телевизора, другие просто выходят в туалет, чтобы подсмотреть варианты хода на телефоне. И это не говоря о случаях с неочевидным и лишь отчасти подтвержденным читерством, вроде недавнего скандала с гроссмейстером Хансом Ниманном.

Программист Джеймс Стэнли* придумал еще один способ выигрывать в шахматы. Миниатюрный компьютер Raspberry Pi Zero, лежащий у него в кармане, подключен к нескольким кнопкам и вибромоторам в его ботинках, так что он может тайком обмениваться данными с шахматным движком на базе Pi. Ноги идеально подходят для этой цели: это единственная часть тела, с помощью которой при известной степени ловкости можно проделывать сложные манипуляции незаметно для окружающих.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

Но, по сообщениям некоторых пользователей, у программ, написанных на Go, течёт память. Issue-трекер языка Go на github по запросам «high memory usage», «memory leak», «out of memory» выдаёт сотни и тысячи тикетов. А в самом популярном вопросе на stackoverflow по словосочетанию «golang memory» автор пытается разобраться, почему потребление оперативной памяти в рантайме в 4 раза превышает количество реально сделанных аллокаций. Обращения, в которых люди рапортуют о перерасходе оперативной памяти в Go, стали массовым явлением.

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

Программирование — это не только алгоритмы и логика, но и удивительное разнообразие синтаксиса языков. Работая над новым средством подсветки синтаксиса для llamafile, разработчик Justine Tunney* исследовала 42 языка программирования — от классического C и экзотического Tcl до мощного Ruby. 

Justine делится своими открытиями о том, насколько причудливым и непредсказуемым может быть лексический синтаксис. Например, триграфы в C — устаревший инструмент для поддержки клавиатур с ограниченными символами, фиксированные длины строк в FORTRAN, вложенные комментарии в Haskell или строки с двойными квадратными скобками в Lua. Ruby вообще оказался чуть ли не самым сложным языком для подсветки из-за его контекстно-зависимого синтаксиса.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис

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

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

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

Под катом рекомендуем 7 изданий о soft-skills, методологиях, управлении командами и проектами.

Насколько популярна сегодня тема атомарных данных, настолько же она обширна для одной статьи. Можно подробно останавливаться на разных аспектах атомарности: например, анализировать memory ordering, рассуждать о lock-free алгоритмах с использованием атомиков или исследовать производительность атомиков на разных платформах.

Под катом мы рассмотрим некоторые базовые принципы работы с атомарными типами данных в языке C++. А именно: осветим работу с атомарными данными, основные операции с ними в стандартной библиотеке C++, а также некоторые аспекты использования атомиков с пользовательскими типами данных.

В статье «Ускоряем анализ данных в 180 000 раз с помощью Rust» показано, как неоптимизированный код на Python, после переписывания и оптимизации на Rust, ускоряется в 180 000 раз. Автор отмечает: «есть множество способов сделать код на Python быстрее, но смысл этого поста не в том, чтобы сравнить высокооптимизированный Python с высокооптимизированным Rust. Смысл в том, чтобы сравнить "стандартный-Jupyter-notebook" Python с высокооптимизированным Rust».

Возникает вопрос: какого ускорения мы могли бы достичь, если бы остановились на Python?

Под катом разработчик Сидни Рэдклифф* проходит путь профилирования и итеративного ускорения кода на Python, чтобы выяснить это.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Разработчик веб-приложений и распределённых систем под псевдонимом chreke* убеждён: «малые языки», то есть специализированные языки, созданные для решения конкретных задач, являются будущим программирования. Это убеждение укрепилось в нём после прочтения статьи Габриэллы Гонсалес «Конец истории программирования» и просмотра лекции Алана Кея «Программирование и масштабирование».

Под катом автор объясняет, что подразумевает под «малыми языками», и почему они так важны.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

В последнее время появляется довольно много Fullstack-фреймворков, они становятся популярны, их обсуждают.

Если посмотреть на результаты The State of JS 2021 в разделе «Библиотеки — Бэкенд-фреймворки», то минимум 5 из них (возможно, больше) будут как раз FullStack. Отсортировав бэкенд-фреймворки по заинтересованности, в самом верху списка мы снова увидим именно FullStack. Это понятно — они востребованы и лежат в основе разных проектов.

Однако на наш взгляд, область их применимости несколько ограничена. Почему — объясняем под катом.

Значимость темы машинного обучения (machine learning) сегодня очевидна. Это огромный домен знаний в Computer Science, которому в России, в частности, посвящают конференции уровня недавней AI Journey. Существует множество способов применения ML в различных областях, среди самых исследованных: распознавание изображений/видео/голоса, процессинг текста. Однако есть и более любопытные задачи, с которыми справляется ML. Например, обучение с подкреплением, что позволяет ИИ играть в игры типа Го, идентификация людей по фотографии, распознавание жестов, движений и поз человека.

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

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

На прошлой неделе компания Monotype — владелец прав на популярные шрифты Times New Roman, Verdana, Arial, Helvetica и Tahoma — объявила об ограничении доступа из России к своей библиотеке и сообщила о приостановке взаимодействия с российскими организациями. Новость стала еще одним поводом обратить внимание на специфику использования проприетарных шрифтов в бизнес-среде – проблему, которая выходит далеко за рамки ситуации с Monotype. Речь о возможных сложностях при отображении существующих документов и шаблонов, особенно при работе с различными таблицами, формами и автоматически формируемыми файлами из информационных систем.

Для минимизации подобных проблем мы в МойОфис еще шесть лет назад представили свои шрифты XO_Fonts. Они свободно распространяются и доступны бесплатно. Сегодня этот набор состоит из 11 шрифтов и 24 начертаний. Их особенностью является метрическая совместимость с распространенными проприетарными шрифтами, которая позволяет сохранить оригинальное форматирование и верстку документов, ранее созданных с использованием популярных иностранных шрифтов.

Некоторое время назад на D-Russia была опубликована история создания XO_Fonts. Теперь мы предлагаем ознакомиться с ней и читателям Хабра.

Я лид команды – и хочу идти дальше вверх! Точнее, не уверен, что хочу, но в айтишке надо ведь расти и развиваться, значит, следующая позиция для меня — менеджмент на уровень выше. Или нет?

Как пробиться на новый уровень, если компания нанимает на руководящие позиции извне? На чём фокусироваться? Как перестать скучать по разработке? А может, к ней надо вернуться?

Знакомы такие рассуждения? Тогда эта статья для вас:)

Меня зовут Максим Шульга, я руководитель департамента разработки Документы Онлайн в МойОфис. Наша команда работает с современными стеками: высоконагруженные бэкенды на Java и Python, фронтенд на React и TypeScript и другие.

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