Привет, Хабр! Меня зовут Глеб, я Java-разработчик в Сбере. Сегодня я хочу рассказать про исторический контекст двух фундаментальных подходов к системе типов в программировании.

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

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

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

В конце лета 1955 года в колледже Дартмут под руководством доцента кафедры математики Джона МакКарти состоялся семинар, посвященный вопросам искусственного интеллекта. Результатом этого семинара стал запрос на проведение исследовательского проекта.

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

Это было начало истории появления языка Lisp.

Я стал большим сторонником DynamoDB за последние несколько лет. Эта база данных имеет много сильных сторон, которых нет у конкурентов, таких как гибкая ценовая модель, соединение без состояния (stateless), которое прекрасно работает для беcсерверных (serverless) вычислений, и постоянное время ответа, даже когда ваша база данных масштабируется до огромных размеров.

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

Привет, Хабр!

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

gRPC – высокопроизводительный и мощный инструмент для построения микросервисных систем.

Криптохомячкам посвящается ...

Алгоритм Гровера представляет собой обобщённый, независящей от конкретной задачи поиск, функция которого представляет "чёрный ящик" f: {0,1}^n to {0,1}^n, для которой известно, что EXISTS!w:f(w)=a, где a — заданное значение.

Считаем, что для f и заданного a можно построить оракул Uf: { |w> to |1>, |x> to |0> if |x> != |w> }

Алгоритм Гровера достаточно прост

1. Задаём в регистре (массиве кубитов) начальное значение H|0>
2. Повторяем несколько раз (исходя из оценки) пару трансформаций над регистром
   
   • Отражение от решения Uw: { |w> to -|w>, |x> to |x> if |x> != |w> } или Uw = I-2|w><w|
   • Отражение от s=H|0> Us = 2|s><s|-I
3. Забираем нужное решение из регистра (с большой долей вероятности, что оно правильное)

Применим этот алгоритм для решения задачи нахождения ключа шифра Цезаря ...

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

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

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

Мы в свое время настроили удаленный формат и работаем так уже почти семь лет. Продолжаем допиливать детали, но в общих чертах можем отчитаться о том, что “контроль без контроля” действительно работает. В этой статье рассказываем, как он устроен.

Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.

В статье я разберу, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложу «лекарства», которые помогут вам нивелировать проблемы.

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

Статья состоит из шести разделов:

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

Однако в 1969 году всё приняло не стандартный оборот: в прямом эфире по указу президента Ричарда Никсона была проведена лотерея, в которой победители получали не денежный чек, а возможный билет во Вьетнам.

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

Несколько лет назад я написал в Twitter/X заметку о лучшем программисте, которого я знаю, её стоит переписать в виде поста в блоге. Мне кажется справедливым, чтобы я рассказал и о самом плохом. Его зовут Тим Маккиннон. Я хочу, чтобы мир знал, насколько он измеряемо непродуктивен.

Продолжаем наш ретроспективный цикл о тех советских разработках, которые стали историей и за которые, как принято говорить — “не стыдно”. В предыдущих постах цикла мы уже затрагивали разработку языков программирования в СССР и в этом посте хотели остановиться на ней подробнее. Несмотря на достаточно скромные достижения в этой области, разработчики языков и трансляторов знали моменты триумфа, а фундаментальный вклад советских ученых в развитие программирования ощутим и сегодня. Под катом немного о языках и трансляторах, разработанных в Стране Советов в 50-е — 60-е годы, а также об их создателях. 

Импортозамещение в ИТ, локальный российский тренд последних лет. На протяжении последнего года — это слово многократно звучало из каждого “утюга”. Причины — крупные западные вендоры, в силу геополитических причин, ушли из России. Это болезненно отразилось на промышленности и крупных компаниях, они потеряли доступ к покупке лицензий, поддержке, обновлениям ect. Больно терять ERP, DSS, цифровая трансформация промышленности и бизнеса в России, очевидно, замедлится. Распространено мнение, что опыт цифровой трансформации и автоматизации, а также разработка систем управления процессами предприятий начались в России в девяностые, а 1С, Галактика и Монолит выросли на ровном месте, но это не совсем так...

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

1. Пролог

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

В изучении языка есть стандартные этапы отчаяния:
- «Мне поможет только погружение в языковую среду»;
- «Что-то идёт не так, нужен какой-то особый подход» [после малорезультативного «погружения»].

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

9 из 10 жалуются: я плохо воспринимаю речь на слух… что делать… У рекламщиков ответ уже готов: «Улучшить восприятие на слух? — Приходите! Поможем!» Заканчивается всё очередным разочарованием и ещё более глубокой убеждённостью в «уникальности» своего случая. В общем, давайте разберёмся, из чего состоит аудирование.

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

Реальные живые носители произносят не совсем те слова, которые мы читаем в субтитрах. Ни в одном словаре нет слова forya (ударение на первый слог), хотя оно и распространённое (в субтитрах пишут for you). Не менее распространено слово whaddaya (в субтитрах будет what do you). То же самое в скоростной русской речи: вместо «он говорит» в реальной жизни мы обычно используем слово «онгрьт» с невнятными «н» и «т». Очсомневаюсь, что оно есть в словаре. Носитель расшифровывает «онгрьт» через 3 канала одновременно:

«Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка». Эту фразу из несуществующих слов предложил в начале XX века академик Л.В. Щерба. Из неё ясно, что «будлану́ла» — действие, которое ку́здра (ж.р.) совершила в отношении бо́кра (м.р.); бокрёнок, скорее всего, детёныш бокра. Для русского это очевидно сразу. Иностранцу придётся сначала выучить русский. Фраза показывает, что язык — это НЕ СЛОВА. Слова легко переходят из одного языка в другой. Язык — это принципы, по которым слова связываются друг с другом.

В том, чтобы научиться говорить, ничего сложного нет — проблема это придуманная. А все неудачи от того, что люди, как говорится, put the cart before the horse, ставят телегу впереди лошади. Пытаются говорить, не понимая, как связываются слова в языке. Это как пытаться бегать, не научившись ходить.

Не будем обсуждать руссо туристо, объясняющихся знаками и инфинитивами. Выделим три уровня «говорения»:

1-й уровень: говорим по-простому, но плюс-минус грамматически правильно. Не знаешь, как будет «прикрой форточку»? Скажи проще: «закрой маленькое окно, но не до конца».

2-й уровень: говорим на конкретные темы именно теми фразами, которые используют носители языка («прикрой форточку»).

Есть реальная история про русского математика, который читал лекцию на английском в Оксфорде. Упоминал степени, корни, дроби и прочие математические штуки, которые не каждый переводчик сумеет правильно описать без подготовки. А после лекции к нему подошла студентка и попыталась заговорить. Математик улыбнулся: «Sorry, I don’t speak English». Лекцию он прочитал настоящими фразами носителей, но за пределами описания математических формул и действий едва говорил на 1-м уровне.