Хаха :). Не, я серьезно. Позвольте мне объяснить.

Хорошо. Что такое типизированный массив?

Это одна из тех языковых причуд, которые делают VBA таким... я бы сказал, восхитительным.

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

Можно ли на него ответить?

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

Одна из простых задач звучит так: «При переводе картинки из цветового пространства RGB в YUV мы выполняем прореживание, то есть выкидываем каждый четный столбец и каждую четную строку в компонентах U и V (все компоненты пикселя по 1 байту). Вопрос: во сколько раз меньше данных у нас стало?» Эта операция называется chroma subsampling и широко используется при сжатии видео, например.

Забавно, что когда-то давно, когда винчестеры были меньше, а дискеты больше, студенты реально отвечали на этот вопрос быстро. А в последние годы регулярно народ в ступор впадает. Приходится разбирать по частям: «Если выкинуть каждую четную строку и каждый четный столбец, во сколько раз меньше данных будет у компоненты?» Почти хором: «В четыре». Начинаю подкалывать: «Отлично! У нас было 3 яблока, первое осталось как есть, а от второго и третьего осталось по четвертинке. Во сколько раз меньше яблок у нас стало?» Народ ржет, но, наконец-то, дает правильный ответ (заметим, не все). 

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

И хорошо видно, как эта способность в широких массах студентов заметно плавно падает. Причем не только в нашей стране. Придуман даже специальный термин: «цифровое слабоумие» ("digital dementia") — снижение когнитивных способностей, достаточно серьезное, чтобы повлиять на повседневную деятельность человека. 

Кому интересно как теряют мозг студенты масштабы бедствия и что с этим делать — добро пожаловать под кат!

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

Представляю 50+ вопросов для подготовки к собеседованию C#, грейд — джуниор/мидл.

Вопросы разные: есть сложные/простые, с детальным объяснением и с ответом в пару предложений.
Anyway, должно быть полезно, поскольку я выбрал самые частотные вопросы

Вообще по поводу собеседований на C#/.Net разработчика, на Хабре статей хватает, вот две, где освещаются вопросы с собесов: тут и здесь.
Но в этих статьях не хватает детального разбора вопросов, что я и решил исправить.

Вообще, по моим и не только наблюдениям C# сейчас бурно развивается, в прошлом 2023 году TIOBE даже назвали C# языком года, что придаёт некоторую уверенность в завтрашнем дне для шарписта.

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

В общем, уверен эта статья будет полезна для подготовки, не будем уже тянуть, поехали!

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

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

В 2008 году я устроился ведущим инженером в НИИ Физических измерений, г. Пенза.

Для меня работа в этом НИИ была более чем знакома, я там работал с середины 80-х по середину 90-х. НИИФИ с момента своего создания было сосредоточено на создании датчиков и специализированной измерительной аппаратуры для космической отрасли.

Начало 2000-х характеризовалось тем, что цены на нефть поползли вверх, в государстве появились какие-то деньги, но одновременно стала происходить череда ярких и красочных неудач с нашими ракетами. И вопрос – а что же там происходит с нашими ракетами – создал на НИИФИ фокус ощутимого финансового потока.

Поскольку в этой организации работает куча людей, связанных между собой родственными связями, то, помимо официального молчания по всем щепетильным вопросам, организация была пронизана слухами, что у нас общий бюджет НИИ достиг сначала 0,7 (примерно 2008–2009), далее 0,9; потом 1,3; 2,1 и 2,7 (2012) миллиарда рублей.

Здесь можно задаться очень простым вопросом – а вот кто будет делать интеллектуальное наполнение проектов под эти в общем-то огромные финансовые потоки.

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

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

Кроме вакансий для стажёров я иногда случайно нажимал на объявления о вакансиях «сеньор-разработчика». Помню, больше всего меня поражало то, что первой строкой шло требование определённого количества лет работы: «Эта должность требует 5+ лет опыта».

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

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

• С опытом программирование не становится намного проще, о «проще пареной репы» можно только мечтать.

• Написание кода для множества «больших проектов» — это не только неинтересное, но и опасное занятие, гораздо менее увлекательное, чем решение алгоритмических задач в LeetCode.

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

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

Большинство из нас в повседневной жизни постоянно сталкивается с различными компьютерными системами: процессорами общего назначения (general-purpose, в основном x86) в ноутбуках и рабочих станциях, их мощными многоядерными версиями в датацентрах, мобильными процессорами в телефонах, многочисленными контроллерами в бытовой технике и на транспорте. Но помимо всех упомянутых вариантов есть ещё одно важное, хотя и редко упоминаемое семейство: цифровые сигнальные процессоры, чаще именуемые Digital Signal Processors или просто DSP.

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

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

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

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

Мне кажется, что если спросить 10 случайных разработчиков о том, как у них в командах устроена работа над кодом, то в 9 случаев ответ будет «Ну, как придётся. Как привыкли!».

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

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

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

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

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

Вступление

0. Перед прочтением статьи

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

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

Коротко обо мне. Меня зовут Макс, и так получилось, что я вот уже 10 лет, почти с самого начала своей карьеры, занимаюсь оптимизирующими компиляторами. Я начинал в Intel, потом перешёл в Azul Systems, год провёл в Cadence и вернулся обратно, всё это время занимаясь компиляторными оптимизациями для Java, C++ и нейросетевых моделей. На момент написания статьи у меня чуть за 900 патчей в LLVM, большинство из них посвящено цикловым оптимизациям.

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

Итак, поехали.