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

Что нужно учитывать, используя std::vector?

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

std::vector имеет:

• [+] Доступ к произвольному элементу за O(1).

• [-] Проблема: При превышении capacity - долгая вставка нового элемента (даже в конец), тербующая поэлементного копирования.
  
  Решение: С этим можно побороться, если зарезервировать заранее всю нужную память под все элементы, но мы редко знаем каким будет максимальное количество элементов. И памяти на все процессы так не напасёшься, даже учитывая оптимизацию современных ОС: когда ОС физически выделяет память только когда процесс начинает её использовать.

• Хороший cache coherence:

  • [+] В общем случае это означает более быстрый обход контейнера vector по сравнению с контейнерами а-ля list (map, set, forward_list etc.).

  • [-] Проблема: В частности, нужно разбиратсья с cache sharing.
    Если vector параллельно обходят два потока и каждый из них модифицирует его содержимое, то вероятно кэши этих потоков будет смотеть на смежную область памяти vector-а. Тогда каждая из записей будет инвалидировать содержимое кеша ядра другого потока, тем самым приводя к регулярному refetch-у. В некоторых корнер кейсах замена vector на list может внезапно привести к улучшению перфоманса.
    
    Решение: Лечится такая проблема обычно увеличением размера элемента до размера кэшлайна. Либо же выдачей каждому потоку по N элементов, где (N * sizeof(ElementT)) == cacheline size.

Накрутка опыта и обман на собесах: подстроиться или остаться аутсайдером

Сейчас почти везде первый этап собеседований в FAANG-компании автономный, без интервьюера. То есть у тебя запускается таймер на несколько часов, на котором нельзя поставить паузу. И ты за это время решаешь 2-4 задачи в стиле LeetCode. Можно гуглить без проблем, но это не особо поможет, если не знаешь базу алгоритмов и не решил пару сотен задач с LeetCode. 

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

Та же тема с накруткой опыта. Все поголовно поднимают себе опыт с 0 до 3 лет, с 2 лет до 5 лет и так далее. И я сижу со своими честно выстраданными 7 годами коммерческого опыта и жду когда меня вчерашние джуны обгонят по годам. Это привело к тому, что некоторые вакансии требуют 10 лет опыта, что просто неприлично много и часто даже невозможно, потому что часто программисты перестают кодить к этому времени, если по-честному. 

Что в итоге выбрать? Подстроиться под систему и быть на справедливом своем месте в этом рейтинге. Или быть честным с самим собой и надеяться что система сама выфильтрует лже-программистов ?

***

Подписывайтесь на мой телеграм-канал Вайтишная: пишу честно про IT и про свой опыт

Знаете, что такое Планкалкюль (Plankalkül)? Это один из первых языков программирования: на нём работал первый компьютер в Европе Z4.

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

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

В 1944 г. в качестве смелой идеи из области прикладной математики немецкий инженер Конрад Эрнест Отто Цузе написал первый универсальный язык программирования — Планкалкюль (Plankalkül), что в переводе означает «планируемые вычисления».

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

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

Это первый пост из новой рубрики #ИЯП — история языков программирования.

Навскидку:

options
attributes
parameters
properties
configuration
initials
data

Вот и кто его знает, что когда применять...

TIOBE Software опубликовала январский рейтинг популярности языков программирования, в котором по сравнению с январём 2023 года выделяется перемещение языка JavaScript с седьмого на шестое место, языка PHP с 10 на 7 место, Scratch с 20 на 10 место (рост популярности на 0.83%), Go — c 12 на 11, Fortran — с 27 на 12 (+0.64%), Object Pascal — c 17 на 13, MatLab — с 15 на 14, Kotlin — с 25 на 17 и Cobol — с 31 на 20.

Языком года назван C#, который сохранил 5 место, но стал лидером по росту популярности (+1.43%).

За год снизилась позиция в рейтинге языков: Visual Basic — с 6 на 8 место, SQL — с 8 на 9, Ассемблер — с 9 на 15, Swift — c 11 на 16, Ruby — с 16 на 18, Rust — c 18 на 19 (при этом популярность Rust выросла на 0.18%).

Рейтинг продолжает возглавлять язык Python, но за год его популярность снизилась на 2.39%. Популярность языка C снизилась на 4.81%, C++ — на 2.95%, а Java — 4.34%.

Индекс популярности TIOBE строит свои выводы на основе анализа статистики поисковых запросов в таких системах, как Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube и Baidu.

В январском рейтинге PYPL, в котором используется Google Trends, тройка лидеров за год не изменилась: первое место занимает язык Python, далее следуют Java и JavaScript. Языки С/C++ поднялись на 4 место, вытеснив язык С# (год назад произошла обратная ротация). По сравнению с январём прошлого года выросла популярность R (+1), Rust (+1), Ada (+2), Dart (+2), Lua (+2), Perl (+1), Haskell (+1).

9999999999999999.0 - 9999999999999998.0 в 20 языках программирования:

Ruby: irb(main):001:0> 9999999999999999.0 - 9999999999999998.0
2.0

Java: public class Foo{public static void main(String args[]){System.out.println(9999999999999999.0-9999999999999998.0);}}
2.0

Python: >>> 9999999999999999.0 - 9999999999999998.0
2.0

Rebol: >> 9999999999999999.0 - 9999999999999998.0
== 2.0

Haskell: Prelude> 9999999999999999.0 - 9999999999999998.0
2.0

TCL: % expr "9999999999999999.0-9999999999999998.0"
0.0

Emacs Lisp: ELISP> (- 9999999999999999.0 9999999999999998.0)
2.0

Common–Lisp: [1]> (- 9999999999999999.0 9999999999999998.0)
0.0

Maxima: (%i1) 9999999999999999.0-9999999999999998.0; (%o1) 2.0

Google: 0

K/Q: q)9999999999999999.0-9999999999999998.0
2f

R: > 9999999999999999.0-9999999999999998.0
[1] 2

Erlang: 1> 9999999999999999.0-9999999999999998.0 .
2.0

C: main(){printf("%lf\n",(double)9999999999999999.0-9999999999999998.0);}
2.000000

AWK: $ awk 'END{print 9999999999999999.0-9999999999999998.0}'</dev/null
2

GoLang: var a = 9999999999999999.0; var b = 9999999999999998.0; fmt.Printf("%f\n", a-b)
2.000000

Perl: $ perl -e 'print 9999999999999999.0-9999999999999998.0;print "\n";'
2.0

Perl6: $ perl6 -e 'print 9999999999999999.0-9999999999999998.0;print "\n";'
1

Wolfram: 1

soup: 9999999999999999.0-9999999999999998.0
1

Вышел исследовательский проект Vcc (Vulkan Clang Compiler), нацеленный на создание компилятора, способного транслировать код на языке С++ в представление, выполняемое на GPU, поддерживающих графический API Vulkan. В отличие от моделей программирования GPU на базе языков шейдеров GLSL и HLSL в Vcc развивается идея полного отказа от использования отдельных языков шейдеров и предоставляется возможность прямой компиляции кода C/C++ для Vulkan. Наработки проекта Vcc распространяются под лицензией MIT.

Для компиляции кода в Vcc задействованы компоненты проекта LLVM и Clang в качестве фронтенда. Для выполнения на GPU развивается собственное промежуточное представление шейдеров Shady и компилятор для преобразования кода в это представление. По возможности поддерживается компиляция обычного стандартного кода C/C++, а для поддержки специфичных для GPU возможностей предоставляются дополнительные встроенные функции.

В Vcc применяются штатные возможности C/C++ для управления ходом выполнения программы, включая возможность использования оператора goto. Допускается вызов функций, рекурсивное выполнение функций, использование физических указателей, теггированных указателей и указателей на функции, выполнение арифметических операций над указателями, а также определение раскладки типов в памяти. Из ограничений реализации упоминается отсутствие поддержки исключений C++, недоступность функций malloc/free и непереносимость функций и указателей между хост-системой и GPU.

Источник: OpenNET.

Вышла версия 0.4.4 статически типизированного языка программирования V (vlang).

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

Изменения в версии V 0.4.4:

• атрибуты переведены на использование нового синтаксиса;

• для структур и объединений реализованы атрибуты "@[aligned]" и "@[aligned:8]";

• присвоение нулевого значения полям со ссылками теперь может выполняться только в блоках unsafe;

• добавлены флаги "r" и "R" повтора строк;

• подготовлена экспериментальная версия модуля x.vweb с реализацией простого, но мощного веб-сервера со встроенной маршрутизацией, обработкой параметров, шаблонами и прочими возможностями. В стандартной библиотеке языка есть как многопоточный и блокирующий веб-сервер (vweb), так и однопоточный неблокирующий (x.vweb) по типу Node.js;

• реализована библиотека для работы с ssh — vssh;

• добавлен модуль для работы с одноразовыми паролями (HOTP и POTP) — votp;

• возобновилась разработка простой операционной системы на V — vinix.

Источник: OpenNET.

https://console.dev/

Добрая некоммерческая инициатива. Каталог инструментов разработчика. Независимые ревью. Контента ещё мало, но уже достаточно для раскрутки.

Вышла вторая редакция проекта PLB (Programming Language Benchmark) по тестированию производительности решения типовых задач на различных языках программирования. В ней измеряется производительность кода для умножения матриц и решения задачи расстановки 15-ферзей, а также дополнительно оценивает поиск решений в игре Судоку и определение пересечений двух массивов.

Код для тестирования PLB написан на 20 языках программирования. Наиболее высокую производительность показала реализация тестовых приложений на языке C (при компиляции в clang). На втором месте оказался язык Zig, на третьем Nim, на четвёртом Mojo. Далее примерно на одном уровне следуют D, Java, JavaScript-платформа Bun и Rust, а после них Go, Crystal и V.

Высокие результаты показали Node.js, Dart, Lua и C#. Хорошие показатели у Java и C# объясняются использованием отдельной стадии JIT-компиляции, в то время как в Dart, Bun, Node.js, Julia, LuaJIT, PHP, PyPy и Ruby3 (YJIT) JIT-компиляция выполняется на лету и затрагивает только часто выполняемый код. JavaScript-платформа Bun заметно обогнала Node.js. Относительно медленными оказались результаты у Julia и Swift.

Наихудшие показатели производительности выявлены у PHP, Ruby, Perl и CPython, при этом производительность PHP оказалась примерно в 4 раза выше, чем CPython.

Дополнение: В реализации на языках Rust, D и Julia внесены оптимизации, которые позволили Rust занять второе место, D - третье, Julia - 7, а V показал лучший результат в nqueen+matmul.

Источник: OpenNET.

Найм в IT превращается в полный бред. И причина очень проста. Этот бред разводится только из за того, что мы используем неправильные инструменты. Так же как и во всём секторе IT.

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

А потом Вася Пупкин, Яваскрипт джун, тащит всё это добро к себе в репозиторий, потому что так делают ведущие компании. Бред! Он делает магазин для автозапчастей!

Тот же ужас творится и в найме. Задача Netflix не нанять человека. У них на каждую вакансию в день приходит по 84 резюме. Их задача - избавиться от кандидатов. Так же как и MS и FB избавляются от кандидатов, а кандидаты безбожно врут, для того, чтобы откусить "запретный плод" "хорошей зарплаты" и "отличной корпоративной культуры", а потом сваливают оттуда через годик-другой.

И какой-нибудь Сергей Константинович, HR менеджер среднего звена, пытается понять, почему это после 200 резюме он не нанял ни одного программиста.

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

Почему ChatGPT не заменит разработчиков

Часто слышу беспокойство по поводу ИИ, типа «программисты будут не нужны».

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

Я посмотрел на исходный код и ужаснулся: 

❗️Код представлял из себя портянку одного React компонента на тысячу строк

❗️GhatGPT взял топовые технологии: Next.js, TypeScript, Tailwind, Versel. Но Tailwind выглядел жестко – это были длинные портянки классов, которые невозможно разобрать

❗️Я уже молчу про нормальный дизайн и UX. ChatGPT делает корявенько, мягко говоря

Создание хорошего продукта – это не просто написать N строчек кода. Часто нужно интегрировать продукт с другими сервисами, продумывать архитектуру, а самое главное – писать масштабируемый поддерживаемый код для людей. Все это не может делать ChatGPT.

Программист нашелся, но вместо двух фич он получил вагон техдолга на старте. 

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

***

Подписывайтесь на мой телеграм-канал Вайтишная: пишу честно про IT и про свой опыт

Учим терминал Linux

Три подкаста про frontend на YouTube-канале Cloud.ru Tech 🎧

Всем привет! Сделали небольшую подборку подкастов для frontend-разработчиков (и не только) с нашего YouTube-канала Cloud.ru Tech. 

🎤 Каков frontend в 2023? 

С Артемом Шовкиным — senior frontend-разработчиком СБОЛ.про обсудили, с чего начать знакомство с WebAssembly, что закидывать в Def Dependencies, может ли ChatGPT заменить разработчика и как правильно готовиться к собеседованиям.

🎤 Почему нужно учить алгоритмы? Правильный frontend

С руководителем группы в Яндекс Маркет Семеном Левенсоном поговорили про то, как поддерживать хороший код на проекте, действительно ли вечный рефакторинг — это плохо, как не надо писать storybook и нужны ли микрофронты.

🎤 Про frontend-разработку и проблемы open source 

Владислав Кибенко — веб-разработчик Yandex Search, рассказал про опыт перехода с backend на frontend, что больше всего бесит в open source, почему курсы — плохой способ попасть в IT, и как бороться со страхом публичных выступлений. 

Подписывайтесь на YouTube-канал Cloud.ru Tech, чтобы быть в курсе IT-трендов.

Что еще полезного есть в блоге:

• Frontend Talks: как упростить создание контекста с помощью Constate

• Frontend Talks: усиливаем TypeScript с помощью switch + notReachable

• Бесплатный курс по работе с облачными сервисами: осваивайте облака на платформе Cloud.ru Advanced

typing.Annotated

Annotated из модуля typing в Python предназначен для добавления метаданных к аннотации. Метаданные, добавленные с помощью Annotated, могут быть использованы инструментами статического анализа или во время выполнения. Во время выполнения метаданные хранятся в атрибуте __metadata__.

from typing import Annotated 

# Синтаксис: Annotated[тип_данных, метаданные]
def say_hello(name: Annotated[str, "this is just metadata"]) -> str:
    return f"Hello {name}"

Логика обработка метаданных зависит от фреймворка или библиотек, в которых используется Annotated. Если логики для обработки метаданных нет, то метаданные игнорируются.

Например, Annotated используется в Pydantic:

from typing import Annotated
from pydantic import Field, TypeAdapter

# Функция Field используется для настройки и добавления метаданных 
# к полям моделей. Field(gt=0) - значит greater than т.е. больше чем 0
PositiveInt = Annotated[int, Field(gt=0)]

# TypeAdapter предоставляет часть функциональности методов экземпляра
# BaseModel в т.ч. валидацию с использованием метаданных из Annotated
ta = TypeAdapter(PositiveInt)


print(ta.validate_python(1))
#> 1
print(ta.validate_python(-1))
#> pydantic_core._pydantic_core.ValidationError:

В первом случае вернёт 1, во втором ошибку валидации т.к. значение должно быть > 0.

Также Annotated используется в FastAPI.

Состоялся релиз отладчика GDB 14.1 (первый выпуск серии 14.x, ветка 14.0 использовалась для разработки). GDB поддерживает отладку на уровне исходных текстов для широкого спектра языков программирования (Ada, C, C++, D, Fortran, Go, Objective-C, Modula-2, Pascal, Rust и т.д.) на различных аппаратных (i386, amd64, ARM, Power, Sparc, RISC-V и т.д.) и программных платформах (GNU/Linux, *BSD, Unix, Windows, macOS).

Ключевые улучшения в проекте:

• кодовая база переведена на использование стандарта C++17. Для сборки GDB теперь необходим компилятор, поддерживающий C++17 (как минимум GCC 9);

• в индекс добавлена информация о функции main, что позволяет ускорить запуск при использовании с некоторыми большими исполняемыми файлами;

• прекращена поддержка ОС AIX 4.x, 5.x и 6.x (в качестве минимально поддерживаемой версии AIX заявлен выпуск 7.1);

• добавлена начальная встроенная поддержка протокола DAP (Debugger Adapter Protocol);

• добавлена поддержка переменной окружения NO_COLOR;

• добавлена начальная поддержка целочисленных типов размером больше 64 битов;

• внесены улучшения в Python API;

• добавлена поддержка точек остановки, привязанных к отдельным объектам отладки (при отладке нескольких процессов);

• добавлена функция "$_shell" для запуска команды в командной оболочке и возвращения результата;

• улучшена поддержка архитектуры AArch64. Добавлена поддержка расширений SME (Scalable Matrix Extension) и SME2;

• улучшена поддержка языка Ada и спецификации Ada 2022.

Источник: OpenNET.

Ролик для объяснения бумерам основы мема "только эвтаназия"

— Отрефакторим этот код?
— Его нужно его удалить
— Но я могу его переписать...
— Нет-нет, только эвтаназия!

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

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

Только Windows.
Лицензия MS-PL

Код на GitHub: https://github.com/Code52/carnac
Скачать с GitHub: https://github.com/Code52/carnac/releases

Яри Комппа уже давно жалуется, что графические API усложнились и что молодому разработчику будет тяжело в них разобраться.

Впрочем, кому как не ему об этом задумываться? Яри вошёл в мир программирования без высшего образования. Первую работу после армии ему помогла найти победа в конкурсе Assembly1998. (В Технологический университет Эспоо-Вантаа Комппа поступил куда позднее, лишь в 2004 году.)

На протяжении своей карьеры Комппа занимался разработкой 3D-движков, портированием игр, просто программным и аппаратным обеспечением. Разработчик по сей день принимает участие в исследованиях и читает лекции.

В сентябре этого года Unity Technologies сменила тарифы, испытала волну негодования от разработчиков и была вынуждена пойти на попятную. Но многие задумались: а нужен ли вообще кем-то написанный движок? Почему бы не написать движок самостоятельно?

Комппа достал из загашников одну свою старую картинку. На ней представлен код Hello Triangle, демонстрационной программы для вывода на экран треугольника, для различных спецификаций программных интерфейсов. Яри сравнил шесть API графики: OpenGL 1.x, OpenGL 3, Vulkan и DirectX трёх версий.

Комппа признаёт, что картинка сугубо развлекательная, но тенденция его всё равно пугает.

Полная версия этой картинки по длине выходит за 20 тысяч пикселей.

После прочтения статьи «Увядает ли ремесло программиста?» и комментариев к ней появилась несколько парадоксальная мысль на эту тему, которую я хотел бы обсудить.

Уже несколько лет назад в дисскуссии услышал хоть холиварную, но в чём-то справедливую фразу о том, что сейчас в этом нашем IT стало намного сложнее, кривая обучения задралась, начальная ступень стала выше и, цитирую, — «от джунов сейчас ожидают объёма знаний сравнимого с тем, что требовали от сеньоров лет 10 назад».

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

А теперь смотрим на рассуждения в статье из первого абзаца.

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

А вот джунам придётся несладко.
Начальные ступени становятся ещё выше.