Мысли об извращениях в сфере десктопа

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

А ничё, что уже лет 40 вбухиваются сотни тыщ чел-часов в разработку средств разработки?

(это так, вопросы к Илюшеньке) (С) Зоркий Сокол

Как-то не очень я понимаю, что Вы пишете. Судя по ряду утверждений типа такого:

Жаба с нет - развитие тех мусорных технологий что принесли плюсы.

или такого:

Это всё корявые внешние зависимости - что-то выкорчевать из них можно только с большим куском «почвы»

это взаимно. Вы хотя бы знаете, чем отличаются статические и динамические библиотеки?

GAC - это инструмент централизованного хранения разных версий библиотек одновременно. Судя по тому, как Ubuntu или Mint любят сыпаться при обновлениях, их пакетный менеджер такого не умеет: обновили один пакет, он потянул за собой обновление какой-то зависимости, которое несовместимо с каким-нибудь важным компонентом системы и ага. В случае правильного использования GAC или аналогичного инструмента такое невозможно: новая версия добавится в GAC, ничего не перезатирая, а любая программа может требовать строго определённой версии библиотеки, и в таком случае она будет работать как работала.

С флатпаком не сталкивался, судя по тому, что я прочитал, это какой-то статический монолит.

Ну, если просто хочется писать interface вместо class, достаточно написать так:

#define interface class

Но это же не позволит избавиться от неоднозначностей, которые вносит множественное наследование классов в C++. В том-то и дело, что сейчас производительность железа стоит дёшево, а вот неоднозначности, приводящие к проблемам со стабильностью, куда дороже. Из-за громоздкого синтаксиса, стирания обобщённых типов, отсутствия передачи параметров по ссылке и перегрузки операторов я считаю Java менее комфортным языком для, чем C++. Но высокая строгость и минималистичность этого языка приводит к тому, что программы на Java отличаются более высокой надёжностью, за которую при необходимости можно пожертвовать производительностью. Робины Гуды, которые гонятся за производительностью в ущерб конъюнктуры рынка, не нужны.

Кроме того, более низкая производительность Java по сравнению с C++ вовсе не повод отказываться от эффективных алгоритмов. Если говорить именно о реализации, то этот язык мне ещё не нравится тем, что он злоупотребляет динамической памятью, в результате чего проблема остановки мира при сборке мусора в Java начинает проявляться гораздо при меньших нагрузках, чем в C#, где работа с памятью сделана по тому же принципу, но несколько более гибко. На моей памяти был случай, когда одна программа после переписывания с C++ на C# стала работать быстрее, потому что на C++ более эффективный алгоритм никто не мог отладить, а на C# это удалось. В результате и программисту хорошо, и пользователю.

Однако Visual C++ разрешает такое, не выстреливая в ногу. И gcc при задании опции -fno-strict-aliasing такое позволяет. Так что не всё так однозначно

Ну, в данном случае мы просто считаем, что алиасинг используется не слишком часто, поэтому его можно не оптимизировать. Следовательно, если эта оптимизация отсутствует (MSVC) или отключена (GCC), поведение программы будет однозначным. Но вообще говоря, если в стандарте предусмотрена данная оптимизация, значит, программа, в которой указатели на существенно разные типы ссылаются на одну и ту же область памяти, является ошибочной.

А в си этого не сделали, понятно, из-за большого объёма легаси. И это тоже логично.

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

По крайней мере лучше, чем в питоне, где для разных скриптов приходится одновременно держать разные версии, постоянно путаясь в них, а когда старая версия перестанет поддерживаться — срочно всё переписывать

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

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

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

Про ромбовидное наследование слышали? Если есть ромбовидное наследование классов, мы рискуем нарваться на неопределённое поведение. Если в языке множественное наследование сделано через интерфейсы, это исключено. По сути, интерфейс - это такой тип данных, в котором возможны только абстракнтые методы, всё остальное - ошибка компиляции. Да, в C++ можно следить за этим самостоятельно (правда, в C# есть ещё такая фича, как явная реализация интерфейсов, не представляю, как такое можно сделать в C++; есть ли такое в Java, не знаю), но в случае более новых языков программиста страхует от ошибок непосредственно компилятор.

Понаписал заумных абстрактных терминов каких то

Каких бы это? Может, вам просто правда глаза колет?

программа где классы используются умеренно проще понять и отладить

Вот с этим соглашусь. Даже если язык не поддерживает просто функции (как Java или C#), можно наворачивать витиеватые конструкции с кучей паттернов ООП, а можно использовать более простую и плоскую объектную модель. Принцип KISS никто не отменял.

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

Я просто не буду решать реальные задачи на C++. Критичные по производительности места я напишу на C или Fortran, а где мне нужно ООП, буду использовать C#. Ситуацию, где нужно то и другое в тесной связке, чтобы не сожрать все ресурсы на p/invoke, я не очень себе представляю. C++ меня интересует только постольку поскольку его приходится преподавать.

или такого:

Это всё корявые внешние зависимости - что-то выкорчевать из них можно только с большим куском «почвы»

А разве не так?

Вы хотя бы знаете, чем отличаются статические и динамические библиотеки?

Постоянно пользуюсь и теми и другими.

Судя по тому, как Ubuntu или Mint любят сыпаться при обновлениях, их пакетный менеджер такого не умеет: обновили один пакет, он потянул за собой обновление какой-то зависимости, которое несовместимо с каким-нибудь важным компонентом системы и ага. В случае правильного использования GAC или аналогичного инструмента такое невозможно: новая версия добавится в GAC, ничего не перезатирая, а любая программа может требовать строго определённой версии библиотеки, и в таком случае она будет работать как работала.

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

С флатпаком не сталкивался, судя по тому, что я прочитал, это какой-то статический монолит.

А я попытался вкорячить его в дистрибутив где его нет, и версия glib-2 маловата. В итоге накатил на корень запасной образ системы и забил. Сам пакетный менеджер флатпак ни сколько не статический и любит номера версий библиотек повыше. Это слабое место в технологии, но для красной шляпы сойдёт, она выстроит дистрибутив вокруг зависимостей флатпака и у неё точно заработают новые пользовательские приложения:) Собственно, всем новым десктопным дистрам это делать придётся - выстраиваться вокруг модных программ, без которых не обойтись. Хвост виляет собакой.

Судя по тому, как Ubuntu или Mint любят сыпаться при обновлениях, их пакетный менеджер такого не умеет: обновили один пакет, он потянул за собой обновление какой-то зависимости, которое несовместимо с каким-нибудь важным компонентом системы и ага. В случае правильного использования GAC или аналогичного инструмента такое невозможно

Для этого не нужен GAC или что-то ещё. Достаточно отказаться от глючных дистрибутивов. Пользуйесь Debian stable, и будет вам счастье. :-) Пакеты, правда, зачастую устаревшие, но в большинстве случаев это не важно. А когда важно, можно бакпортировать или воспользоваться готовым бакпортом. А уязвимости они фиксят оперативно.

Однако Visual C++ разрешает такое, не выстреливая в ногу. И gcc при задании опции -fno-strict-aliasing такое позволяет. Так что не всё так однозначно

Ну, в данном случае мы просто считаем, что алиасинг используется не слишком часто, поэтому его можно не оптимизировать.

В ядре Linux как раз наоборот алиасинг используется очень часто. В том моём топике, на который я давал ссылку, приводятся выдержки об этом из письма Линуса Торвальдса в рассылке в моём переводе и в оригинале.

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

Проблема в том, что возможность свободного обращения к любой доступной процессу части памяти любым способом является одной из основных фич языка си, делающей его «ассемблером высокого уровня». Если мы уберём эту и ещё пару других фич, то получим язык со всеми недостатками, присущими си, но не обладающий никакими присущими ему достоинствами. Т. е. что-то ненужное. Оптимизации же не так умны, как хотелось бы. В большинстве случаев они делают то, что по хорошему должен был бы делать программист, если бы подумал. Взять ту же инструкцию inline. Она как бы есть, но как бы совсем не нужна, потому что оптимизаторы обычно сами решают, инлайнить им ту или иную функцию или нет, не обращая на этот модификатор внимания. А почему бы не переложить эту работу на программиста? И такого много.

А в си этого не сделали, понятно, из-за большого объёма легаси. И это тоже логично.

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

Тоже верно. Но для таких конструкций существуют предупреждения, особенно если включить опцию -Wall в gcc. С другой стороны, некоторые конструкции признаны устаревшими, например такое объявление функций:

myfunc(a, b)
int a, b
{
  /* body */
}

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

Да, форматирование в качестве операторных скобок - интересная и вполне здравая идея

А мне она наоборот очень не нравится. Но тут, как говорится, на вкус и цвет. :-)

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

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

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

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

Вот это я не понял, о чём речь.

я не понимаю почему так сложно не использовать возможность языка которая кажется опасной.

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

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

Пользуйесь Debian stable, и будет вам счастье

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

Не нравится Java - не используй программы, на ней написанные. А если тебе они нужны, перепиши их на быстром C++ и выложи на радость общественности. От наездов на самый популярный язык программирования в мире он не перестанет быть таковым.

я не понимаю почему так сложно не использовать возможность языка которая кажется опасной.

Проблема в том, что безопасность и производительность зачастую плохо совместимы или совсем несовместимы. Почему ява такая медленная? Одна из причин (хотя, конечно, не единственная) заключается в том, что при каждом чтении и записи в массив производится проверка допустимости индекса и в случае чего выбрасывается исключение. Т. е. любая элементарная операция типа n=a[i] выливается в генерацию и исполнение дополнительного кода, не менее (а скорее более) тяжёлого, чем сама операция. Зато безопасно. А в си всё наоборот: в ран-тайме по умолчанию абсолютно ничего не проверяется, если сам не проверишь, зато быстро. Аналогично с необходимостью освобождать память самому в си/си++ против сборщика мусора в яве. Существуют и компромиссы типа умных указателей и т. д. Но всегда (или почти всегда) увеличивая безопасность языка или библиотеки, мы снижаем производительность, и наоборот.

ну не используйте прямое обращение к памяти, используйте контейнеры из standard template library для высокоуровневого кода.

Эти контейнеры — обычная обёртка над указателями, которая кое-что упрощает, но далеко не всё. Например, строгой проверки выхода за границы вектора или строки там тоже нет. А если её реализовать, то будет так же медленно, как в яве. С другой стороны, stl ограничивает возможности программиста, что приводит порой к менее эффективному коду в пользу простоты использования, удобства и относительной безопасности. Т. е. снова мы возвращаемся к дилемме безопасность и удобство vs гибкость и эффективность. Наконец, шаблонный код гораздо сложнее отлаживать, что тоже является серьёзным минусом. А при использовании классов, любой из них, находящийся у основания иерархии, может неожиданно выстрелить в ногу. Поэтому некоторые проектировщики считают, что традиционный процедурный код безопаснее, при всех своих недостатках.

Последние годы на мой взгляд наметилась тенденция отхода от этой разумной линии в сторону хипстерства.

Вот это я не понял, о чём речь.

Ну, это я всё о том же: об алиасинге, объявленном ub в c99 (до принятия этого стандарта он был абсолютно законным и считался одной из основных фич языка) и т. д. :-)

Ну а в си++ вообще каждые 3 года новый стандарт принимают, один революционнее другого, в результате имеем

void *$() {[&](...){$:[](){({$:;_:[](){},""[+-(&&$<&&_)];});}();}([=](){});}

Это компилируется g++ -std=c++11.

Дальше будет только хуже.

источник :-)

сделаю новую попытку поставить Debian, сейчас я уже вроде знаю, как не наступить на грабли

Там по-моему из грабель только то, что несвободные и не полностью свободные ветки репозитория nonfree и contrib изначально закомментированы в source.list, из-за чего вай-фай и другие дрова при установке могут не взлететь. Но лечится просто: после установки всё, что нужно, раскомментируется, делается apt-get update от рута и устанавливается всё, что надо. Хотя сейчас у меня arch, последнюю стабильную ветку так и не посмотрел.

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

Кстати, в C# оптимизатор умеет пропускать эти проверки, если переменная, по которой идёт обращение к массиву, перед этим сравнивается с его длиной. Я не вижу причин, по которым нельзя было бы так же сделать в Java (а доподлинно не знаю). Так что в данном случае можно сказать, что использование шаблона в C++ по соотношению безопасности и производительности будет даже хуже. Другое дело, что оптимизатор, работающий в рантайме, явно не может быть слишком сложным, иначе время, затраченное на оптимизацию, превысит выигрыш от этой оптимизации. В C++ этой проблемы действительно нет.

Аналогично с необходимостью освобождать память самому в си/си++ против сборщика мусора в яве.

А вот тут не совсем соглашусь. Мы сами тестировали выделение памяти в C++ и C#, и в C# выделение памяти работало быстрее. Другое дело, что тут речь только об операции выделения памяти - она вполне предсказуемо быстрее в C#, поскольку там не происходит поиска ранее освобождённых блоков. В отличие от C++, освобождение памяти в Java / C# будет происходить не в тот момент, когда мы вызвали специальную операцию, а когда запас памяти, который был выделен у ОС, закончится. И тут уже происходят довольно сложные вещи - поиск неиспользуемых блоков, дефрагментация занятой памяти и перезаписывание всех указателей на занятые блоки. И проблема не только в том, что освобождение памяти становится долгим, но и в том, что оно может запуститься в любой момент, вследствие чего управляемые языки не годятся для разработки систем реального времени. Ну и вторая особенность управляемого менеджера памяти - это то, что он заранее запрашивает у операционной системы некоторый запас памяти, чтобы распределять его для нужд приложения, поэтому-то helloworld на Java сразу и занимает много памяти. Но ведь если мы в C будем писать свой аллокатор памяти для борьбы с её фрагментацией, мы сделаем то же самое. Чудес не бывает.

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

Да не только отлаживать, иногда просто хрен поймёшь, на что ругается компилятор, выдавая ошибку в каком-нибудь совершенно левом месте.

вай-фай и другие дрова при установке могут не взлететь

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

А что это тогда?

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

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

Кстати, в C# оптимизатор умеет пропускать эти проверки, если переменная, по которой идёт обращение к массиву, перед этим сравнивается с его длиной. Я не вижу причин, по которым нельзя было бы так же сделать в Java (а доподлинно не знаю).

Я тоже не специалист по яве. Писал на ней давно и недолго, ещё на яве-2. Поэтому могу ошибаться. Вот кто здесь спец по ней, так это stevejobs. Может прояснит чего.

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

Вот и я о том же. И речь даже не о системах реального времени. Для них и стандартный диспетчер памяти си не очень-то годится, потому что не гарантирует выделения/отказа за одинаковое время в любой ситуации (ну, с учётом +/-, конечно). Но сборщик мусора, начинающий активную генеральную уборку в самый неподходящий момент, кого угодно может достать, имхо, даже если требования к скорости отклика не так уж и велики.

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

Так абсолютно все менеджеры памяти поступают, и си с си++ — не исключение, т. к. запрос памяти у системы — довольно дорогая операция. Другое дело, что и тут могут быть нюансы: кто-то может сразу запрашивать довольно скромно, а кто-то совсем бессовестно. Но если слишком много запросить без надобности, то это может сказаться на производительности других программ, что тоже нехорошо.

у меня вообще не загрузилась система после установки.

Такие вопросы лучше в соответствующих разделах форума задавать с максимумом конкретики и разных диагностических сообщений и логов (при их наличии). Уверен, что на подобный вопрос, заданный грамотно, довольно быстро дадут адекватный ответ, и проблема будет решена.

void *$() {[&](...){$:[](){({$:;_:[](){},""[+-(&&$<&&_)];});}();}([=](){});}

Это компилируется g++ -std=c++11.

brainfuck нервно курит в сторонке 8-O

Никто же не говорит, что давайте в машину поставим ещё один мотор, чтобы получит 120 л.с.?

Ещё как говорят, и более того - делают! В суперкар LaFerrari ставят электромотор, который ПОМОГАЕТ работе ДВС.

Тем не менее, в 2000 году пользоваться на десктопе железом 10-летней давности было невозможно, а сейчас вполне 10-15-более лет сгодится.

Во-первых, тогда «для интернета» как раз можно было приспособить какой-нибудь первопень или 486, а не как сейчас. Во-вторых, за последние 10 лет железо практически не прогрессировало, в отличие от двухтысячных, и кроме SSD никаких революций не произошло. Процы на 5% за поколение прирастали. Ну и стало в типовом офисном компе не 2, а 4 ядра (иногда с гипертридом, но иногда и «атомных»...)

ведро современного штеуда в 4раза превосходит по скорости 2.7ГГц ядро Атлона Х2 (64) брисбан и более ранние.

так что да, за 10 лет ничегошеньки не поменялося...

самим ссд-ям уже лет и лет, пусть будет эталоном OCZ Vertex4 (2012), который честно в попугаях показывал свои 400/360МБ/с при линейных скоростях.

а не стрындел ли я про 4 раза?
вот облом лезть бенчмарки смотреть.

Утюги от трехбуквенных - не были процами уже тогда, это были затычки для нищебродов. Так что с синими их сравнивать не надо, тем более с нынешними. Рязань - да, процы, спору нет (и долгожданный реальный пендаль синим, для решительного шага вперед). Насчет 4 раз - брехня, одно ядро E6850 медленнее ядра i5-6500 менее чем в двое.

SSD до юзабельности еще расти и расти. SSD за $100 живут по 3 месяца, за $2K живут подольше, но они уже адски дорогие и под pcie. Для сервера скрипя зубами под bcache еще возьмёшь, а под десктоп как небыло нифига так и нет :(

SSD за $100 живут по 3 месяца

Да ты что!!! А я, дурак, за 60 бачков у китайца взял две недели назад! Видать, до лета не дотянет, хнык-хнык. А серьезно - как раз в десктопе живут норм, из купленных на работу более 50 штук отстрелился пока один, и тот из-за глючного контроллера от Sandforce. Да и в серверах вроде живут, если не задрачивать, и не покупать всякие адаты и смартбаи. Но у нас и не прям хайлоад, так, для БД стоят несколько all-flash СХДшек.

самим ссд-ям уже лет и лет, пусть будет эталоном OCZ Vertex4 (2012), который честно в попугаях показывал свои 400/360МБ/с при линейных скоростях.

Не вижу противоречия. 2012 год - аккурат середина последних 10 лет. ИМХО, это и есть единственное революционное изменение за указанный период. Всё остальное - просто эволюция, и тупо экстенсивное развитие.

Даже в D есть странное решение - вместо угловых скобок для работы с шаблонами, как в любом из его предшественников (C++, Java, C#) сделали обычные скобки с восклицательным знаком.

На самом деле очень удобно и логично. В D коммьюнити даже было предложение не использовать термин «шаблон» поскольку есть люди, которых он пугает после их знакомства с шаблонами в плюсах. И предлагают использовать термин аргументы времени компиляции. Они также как и обычные аргументы в круглых скобках. Повторюсь - очень логично и удобно:

auto foo(T1, T2, Rest...)(T1 t1, T2 t2, Rest rest)
{
    // ...
}

    A a;
    B b;
    C c;
    D d;

    ...

    auto result = foo(a, b, c, d); // Компилятор сам выведет
                                   // что T1 == A, T2 == B, a
                                   // Rest = AliasSeq!(C, D),
                                   // т.е. два типа

    // А если компилятор не может вывести типы (бывает, 
    // хоть и редко, можно ему их явно указать,
    // и это намного проще чем в плюсах
    auto result = foo!(A, B, C, D)(a, b, c, d);

Я для bcache использую в билд-сервере, все дохнут по истощению ресурса хнык-хнык, пришлось брать durable на pcie.

Может, всё таки памяти лучше докупить в сервер и на tmpfs компилять? Мозги вроде так не истираются. Или «сервер» на обычной ПКшной матери собран?

и это намного проще чем в плюсах

Да чем особенно проще?

foo!(A, B, C, D)(a, b, c, d);

или

foo<A, B, C, D>(a, b, c, d);

В C++ даже на один символ меньше получается. Вот AliasSeq - да, дополнительный инструмент. Не знаю ничего подобного в C++.

Насколько я знаю, слабое место D - это оптимизатор. Ну и ещё отсутствие платформы.

Выглядит как код на rust.

даже было предложение не использовать термин «шаблон» поскольку есть люди, которых он пугает после их знакомства с шаблонами в плюсах

Ну, если уж на то пошло, в C# и Java это называется «обобщения». Хотя, строго говоря, в C++, C# и Java это всё немного разные вещи, аналогичные конструкции для аналогичных задач, но работает несколько по-разному (причём в Java откровенно кривовато), и я не знаю, к чему ближе всего то, что используется в D.

void *$() {[&](...){$:[](){({$:;_:[](){},«»[+-(&&$<&&_)];});}();}([=](){});}

Выглядит как код на rust.

Но на gcc с опцией -std=c++11 реально компилируется. :-)

Однако, если на rust так выглядит реальный, а не пародийный код, то я им не завидую.

Ну, если уж на то пошло, в C# и Java это называется «обобщения»

Так generic'и так обозвали, чтобы подчеркнуть что они не такие как шаблоны. Они собственно ограниченный вариант шаблонов. Это, в принципе тоже попытка решить проблему и уменьшить сложность работы с шаблонами. Просто они пошли путем упрощения самих шаблонов за счет их примитивизации. А в D пошли более (ИМХО, конечно же) правильным путем - просто шаблоны сделаны продуманно, с учетом опыта С++, причем шаблоны еще более мощные чем в плюсах. Например, параметром шаблона может быть строка. Если честно, я на D легко напишу код, который бы на плюсах писать не стал. Просто действительно, D заметно более выразительный и продуктивный. Тот же Rust в определенных задачах, где требуется маниакальная безопасность, например, более подходящий выбор чем D, но в остальных случаях он сильно уступает из-за той же продуктивности. Я пишу код для того чтобы решить конкретную задачу, а не для того, чтобы лайфтаймы проставлять. Питон явное подтверждение тому, что людям нужна продуктивность.

Питон явное подтверждение тому, что людям нужна продуктивность

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

Просто они пошли путем упрощения самих шаблонов за счет их примитивизации.

Да не сказал бы. Единственное, чего нет в C# и есть в C++ - это использование в качестве параметра шаблона скалярного значения, в C# это как бы всегда неявно typename. А как насчёт механизма ограничений, который явно надёжнее, чем принцип «утиного следа» в C++, хотя и несколько сложнее? Как насчёт covariance / contravariance? Как насчёт метасимволов в Java? Разве в C++ есть подобные возможности? Просто тут есть такой момент, что всё это возможно при использовании JIT. А в C++ всё сразу компилируется в нативный код. С одной стороны, это позволяет оптимизатору сначала попыхтеть, но потом выдать хорошо оптимизированный код, а в случае JIT приходится довольствоваться теми оптимизациями, которые можно сделать быстро. С другой стороны, такой надёжности и в то же время гибкости, как в обобщениях, в шаблонах нет.

Например, параметром шаблона может быть строка.

Приведите пример задачи, где это нужно. Почему может быть недостаточно обычных параметров?

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

Есть много задач где хватает производительности питона. На нем даже игры пишут - Eve Online например. Зато человек может легко выразить свои мысли и решить задачу. А на плюсах этот же человек эту задачу решить не может. Ну и зачем тогда быстрый, но не работающий алгоритм? Динамическая типизация мне тоже не особо по душе, но в некоторых случаях она крута - именно крута. В частности для explorative задач, repl. Вот человеку нужно исследовать свойства датасета, он там экспериментирует, то одну фичу попробует, другую. И тут питон очень даже удобен, это сложно отрицать.

Генерики ограничены тем, что они подставляются в рантайме. Да, меньше code bloat, но и недостатки очевидны. Недостатки дженериков в шарпе по сравнению с плюсами приведены в документации на шарп.

Про механизм ограничений не могу ничего сказать, не уверен что вы имеете в виду. Про ненадежность утиной типизации неясно о какой надежности идет речь? Насчет covariance / contravariance в плюсах не знаю, честно скажу. В D это точно есть. Также есть ограничения, но не уверен, что мы об одном говорим. И все это без JIT. Опять же в плюсах есть enable_if - про этот механизм ограничений идет речь? И уж кто гибче, так это плюсовые шаблоны.

Приведите пример задачи, где это нужно. Почему может быть недостаточно обычных параметров?

Т.е. то что можно передать скалярное значение - это круто, а строка - не нужна?)) Немного отдает предвзятостью. Была бы возможность, а воспользоваться ей всегда можно. На самом деле это просто пример продуманности и согласованности решений в D по сравнению с плюсами (на самом деле это все опыт, полученный в тех плюсах). Если уж смотреть возможности метапрограммирования в D, нужно смотреть их все в совокупности. По отдельности они вроде и ничего особого, в том или ином виде есть в других языках. Но вот их сочетание в D просто впечатляет. Я регулярно пишу код, который по последовательности переданных в него типов генерирует кучу кода - структуры данных, функции и т.д., освобождая меня от рутинной работы. За счет этого я могу на этапе прототипирования просто добавлять/убавлять какое-то тип и весь код будет сгенерирован автоматически. Это реально впечатляет. Тот же static foreach и static if - просто песня в сочетании с интроспекцией. Понятие boilerplate в D просто отсутствует. Бывает, что документирующие комментарии и юниттесты в дишном проекте занимают больше строк чем собственно код.

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

Когда я покупал мироковолновку, я специально искал такую, где весь интерфейс - две ручки-крутилки: мощность и время. Получилось найти только какую-то бюджетную хрень.

Ага-ага. Вот мне, например, чтобы разогреть картошку с котлетами, нужно выставить ровно 40 секунд. Да, 4 раза жму на одну кнопку и один раз - на вторую. Получаю чёткий предсказуемый результат.

Теперь расскажи, как я эти 40 секунд могу получить на бюджетной хрени с двумя крутилками. Я как-то пытался, результат мне сильно не понравился. Допускаю, что в результате долгих и усердных тренировок это возможно. Но 5 нажатий на 2 кнопки (4 раза по 10 секунд и 1 раз на СТАРТ), по-моему, куда проще и логичнее.

нужно выставить ровно 40 секунд

А если выставишь 50 или 60 секунд - вселенная схлопнется или умрёшь от голода?

Собственно, даже крутилка мощности - излишество, достаточно переключателя разморозка/полная мощность. Подогреваю я на полной мощности, просто повернув ручку времени до первого деления, это 1 минута. Заметь, ничего больше не нажимаю и не верчу, просто: поставил тарелку внутрь, повернул ручку до первого деления, всё. Ещё бы я с микроволновкой игрался как с вимом каким-то, ога.

вы оба правы.
в этом то и беда :-( современных интерфейсов.

/ме владелец м/в самсунг 10 летней давности, с кнопочками, крутилок нет.
не самая удобная штука, так ёё еще и ресетить надо при загрузке %-) идиоты с часами там, где хронометр не нужен от слова совсем.

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

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

И вот эти вот кнопочки взыгрывают новыми красками.
Воткнул вилку в розетку - овнище начинает блымать индикаторами - раздражают - 2 раза нажать на Стоп - потом несколько раз нажать на выбор мощности - выбор времени - Старт.
Это реальнэ технодрючево!

Должно быть так: воткнул вилку в розетку, загорелись 000 на индикаторе, всё, крути меня полностью.

Нет, у меня всё проще. Ничего из розетки выдёргивать и обратно втыкать не надо, мощность по дефолту самая большая, обычно она и используется, за редкими исключениями. Остаётся только выставить время и включить. Хотя, если бы был простенький интерфейс по ssh, я бы не отказался, — в отдельных ситуациях оно могло бы быть очень удобно.

Лучше всего так

http://prolog-plc.ru/sites/default/files/mkp20.gif

управляется путем ввода программы в машинном коде с вот этой вот клавиатуры.