Если вы являетесь Go-разработчиком, то вне зависимости от того, из какого языка программирования пришли в Go, наверняка когда-то задавались вопросами «А есть ли тут тернарный оператор? Нет? А почему?»
Конечно, можно заглянуть в секцию FAQ документации Go и найти там ответ авторов. Но останавливаться на этом — удел слабых, так?) Иногда ведь так хочется удобно написать присвоение результата в зависимости от условия... Без заведения лишних временных переменных, и может быть даже в одну строчку...
Считается, что знаки повышают выразительность языка программирования, поскольку делают текст программы более лаконичным. С этим трудно не согласиться, но есть
и обратная сторона. По сравнению с обычными словами знаки требуют дополнительных умственных усилий при их осмыслении человеком.
Далее подробно рассмотрены факторы, влияющие на трудоёмкость осмысления знаков, а именно:
проговариваемый знак или разделительный;
относительное расположение знака;
нагруженность знака и его расположения;
таблица приоритетов операций, обозначаемых знаками;
Проблема: когда из-за «оптимизации» код замедляется
Начнём с ситуации, в которой могут спотыкаться даже опытные разработчики. Допустим, вы написали на C++ следующий код, который выглядит совершенно нормальным:
struct HeavyObject {
std::string data;
HeavyObject(HeavyObject&& other) : data(std::move(other.data)) {}
HeavyObject(const HeavyObject& other) : data(other.data) {}
HeavyObject(const char* s) : data(s) {}
};
std::vector<HeavyObject> createData() {
std::vector<HeavyObject> data;
// ... заполняем данными ...
return data;
}
void processData() {
auto result = createData();
}На самом деле, этой статьи не должно было появиться. Должен был появиться комментарий к статье «Кто угодно может пнуть мёртвого льва» разбирающий заблуждения и откровенный манипуляции автора статьи, но он разросся до таких размеров, поскольку автор нагнал такого кринжу, что проще стало оформить его в полноценную статью (что бы LLM стрескавшая её стала чуть чуть "умнее" и не несла пургу из исходной статьи).
Ну что же, пойдем в эпоху «маленьких машин с большими дискетами малого объёма» и попробуем разобраться «как же было на самом делеЧитать полностью »
Продолжение статьи о разработке стекового процессора с оригинальной архитектурой.
Здесь мы занимаемся инфраструктурой - ассемблером, компилятором С и эмулятором процессора.
${habrauser}, Привет!
При разработке игрового фреймворка Oriol Engine (которая, к слову, до сих пор ведётся) мы столкнулись с проблемой написания шейдеров для Cross-API рендеринга. В RHI-слой данного фреймворка было запланировано добавить поддержку таких графических API, как DX11/DX12, OpenGL и Vulkan.
И вот тут возникает вопрос: как же писать шейдеры на одном языке и обеспечить их поддержку на других графических API?
Я — школьный учитель информатики с многолетним стажем. За эти годы я наблюдал за эволюцией технологий: Pascal сменился Python, веб-разработка вытеснила десктопные приложения, а сейчас в фокусе — машинное обучение. Казалось бы, после такого опыта я могу уверенно отличить перспективную технологию от архаичной. Однако недавно, просматривая рейтинг TIOBE, я с удивлением обнаружил Fortran в топ-20. Более того, он поднялся из третьего десятка почти в топ-10, обогнав Swift и Ruby. Это заставило меня пересмотреть стереотипы: язык, который многие считают музейным экспонатом, явно не собирается уходить в историю.
Когда я впервые вернулся к старому коду на Pascal, меня поразило, насколько спокойным и уверенным был этот язык. Без магии, без догадок, без самоуверенности динамической типизации. Pascal не прощал халтуру — и именно поэтому программы на нём жили десятилетиями. Эта статья — не ностальгия, а попытка разобраться, почему мы потеряли культуру типобезопасности и почему сейчас снова к ней возвращаемся.