Программирование *

Немножко истории

Начну с истории вопроса.

Очень давно я написал Fresh IDE – навороченнoe IDE для программирования на ассемблере, а точнее на FlatAssembler.

Fresh IDE долгие годы меня полностью устраивал, поэтому я с перерывами выпустил 2 главные версии и начал просто его использовать, время от времени внося какие-то исправления и изредка новые функции.

Когда перешел полностью на Linux, оказалось, что Fresh IDE прекрасно работает под WINE, и я продолжил им пользоваться без угрызений совести. В процессе даже удалось исправить несколько багов WINE (вот, вот и вот).

Как бы то ни было, но я начал писать библиотеку для переносимости ассемблерных программ между Linux и Windows (и KolibriOS). Одновременно с этим задумался и над тем, чтобы сделать Fresh IDE переносимым. Из-за архитектуры библиотеки, огромная часть кода уже и так была переносимой. А точнее все, что не касалось GUI. К сожалению, GUI был полностью написан на Win32 API и его нельзя просто так перенести на другие платформы.

Поэтому и пришлось начинать все сначала. И третья версия Fresh IDE писалась почти с нуля.

Носители языка — худшие коммуникаторы в мире

В комнате, полной людей, для которых язык не является родным, «нет никаких шансов на понимание». Возможно, это их язык, которым они владеют, но послание часто теряется.

Эта статья выросла из ответа на комментарии к статье Основные отличия PascalABC.NET, где возник традиционный спор про то, есть ли смысл в 2023 году изучать Pascal. Для комментов мой ответ слишком большой, так что оформлю в виде такого спонтанного поста.

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

Сразу уточню: речь, прежде всего, идёт о среднем звене "среднестатистических" школ, где информатика изучается строго по ФГОС - только с 7-9 классы, по 1 часу (уроку в 40-45 минут) в неделю. Если хотите изучить "единую министерскую" программу, можете скачать её с официального сайта Минпроса.

Конкретно на программирование эта программа отводит порядка 30 часов . По 1 часу в неделю, растянутых на конец 8 - начало 9 классов (с перерывом в 3 месяца, ага).

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

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

Все знают, что Россия — энергетическая сверхдержава, она же – «разорванная в клочья Обамой бензоколонка». Но не все знают, как это может отражаться в области развития математического моделирования. Расскажу одну жизненную историю. 

Начну с далекого 2007 года. Довелось мне в те времена поработать на крупном заводе, который «эффективные менеджеры» как раз делили на несколько отдельных предприятий, каждое из которых крутилось, как могло.  В том цеху, который и стал одним из таких предприятий, на токарных станках могла крутиться (и крутилась!) металлическая болванка размером с автобус. А в печку для нагрева металла можно было затолкать паровоз. Целиком.  Когда я в первый раз увидел токарный станок, на котором крутится и обтачивается деталь размером с автобус, моему восторгу не было предела. Гордость за страну переполняла до состояния «в зобу дыханье сперло». А потом старожилы показали ту часть цеха, где стояли фундаменты таких же станков и пояснили:

- А вот тут были станки для точной обработки. Их продали китайцам по цене металлолома.

- А почему вот другие не продали?

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

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

Недавно на Хабре вышел перевод статьи под названием: «Классическое программирование на грани вымирания» с постапокалиптической картинкой, где автор буквально пишет, что «Приближается конец эпохи классических компьютерных наук, и большинство из нас словно динозавры в ожидании падения метеорита». Если коротко, данная статья о том, что классические компьютерные науки становятся менее актуальными на фоне развития искусственного интеллекта и современных технологий. Автор рассказывает о своем опыте в области компьютерных наук, полученном в 80-х и 90-х годах, и подчеркивает, что, несмотря на то что классические подходы к программированию и алгоритмам всё еще актуальны, но в будущем (горизонт автор не указывает), скорее всего, ИИ с самообучаемыми системами заменит программистов. В будущем студентам факультетов компьютерных наук не нужно будет изучать традиционные навыки, такие как работа с двоичными деревьями или программирование на С++, обучение таким вещам станет неактуальным, потому что от инженеров будущего будет требоваться обучение и запуск генеративных моделей.

Я читаю Хабр довольно давно и очень люблю этот ресурс. При этом здесь регулярно возникают статьи, типа «Если хочешь программировать, начни с языка Си» или наоборот, «Python — это простой язык, с которым любой идиот может разобраться» (статьи такой направленности иногда нещадно минусуют). Есть также и третья категория статей о том, что программисты скоро станут попросту не нужны (как статья, которая недавно опубликована).

Когда я был маленький, то на меня снизошла милость божЫя и ниспослала мне две книжки. Одна книжка была про бейсик для студентов каких-то там ВУЗов, а вторая - «Паскаль в иллюстрациях». По одному из абзацев первой книжки я в принципе научился программировать в пятом классе - там был мозголомающий отрывок с программой, заставляющей нолик летать по экрану, отталкиваясь от стенок. Вторая книжка, отданная мне соседом-алкашом, познакомила с алгоритмами. На дворе стояли 90-е — начало компьютерной эры человечества. Компьютера у меня при этом не было — я видел его пару раз в неделю на компьютерном кружке, ведущей которого была вчерашняя или даже сегодняшняя студентка, отпирающая и запирающая дверь — большего от неё нам и не требовалось.

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

Была у нас тут история, когда легкий перфекционизм помог привести в порядок конструкторскую документацию и регулярно экономить инженерам кучу дней на прохождение бюрократических процедур. В ее основе – создание системы управления расчетными данными и переход от трудночитаемых и трудноинтегрируемых отчетов Mathcad к гибкой связке Jupyter Notebook с Python и Teamcenter. Но основной рассказ будет про то, как преобразовывать и экспортировать математические формулы, таблицы и другие элементы из Jupyter в красивый и удобный вид.

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

Многое изменилось за 20 лет. В 2003 году главный вопрос звучал так: «Что это за кодировка?». В 2023 году такой вопрос больше не стоит: с вероятностью в 98% это — UTF-8. Наконец то! Можно снова спрятать голову в песок!

Традиционное определение для операции возведения в натуральную степень (или целую положительную) вводится примерно следующим образом:

Возведе́ние в сте́пень — арифметическая операция, первоначально определяемая как результат многократного умножения числа на себя.

Но более точная формулировка всё же другая:

Возведение числа X в целочисленную степень N — арифметическая операция, определяемая как результат многократного [N по модулю раз] умножения либо деления единицы на число X.

В этой статье я поделюсь с вами долгой историей, которая начинается с op.read() opendal, а заканчивается неожиданным поворотом. Это путешествие оказалось для меня достаточно поучительным, надеюсь, и для вас оно будет таким же. Я постараюсь максимально точно воссоздать свой опыт и дополню его выводами, которые сделал в процессе.

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

Старые программы покрываются коркой сомнительных фич.