Rust vs C++

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

0

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

Ну вот тут не совсем. К примеру когда код пишу критичный к производительности - например операторы с векторами и матрицами то обязательно проверяю в выхлопе что их использование инлайнится. Да и вообще для того чтобы на мифы не вестись полезно. К примеру на миф что домножить вектор на 1/c будет быстее чем поделить на c. Именно по анализу асма можно сделать вывод что будет с точностью до наоборот - деление на коэффициент остановит конвейер до его завершения только потом будет умножение, а при делении же вектора все сделается одним AVX делением. Или к примеру мифа про то что ветвление по типу объекта быстрее чем virtual call.

0

Сообщение от Fulcrum_013 К примеру когда код пишу критичный к производительности

Если и тут пытаться анализировать "выхлоп", то можно придти к неправильным умозаключениям, т.к., авторы кодогенератора могут знать лучше вас.
Я, в таких случаях, пишу несколько тестовых вариантов и сравниваю время выполнения (что тоже нужно уметь делать правильно). Это и быстрее, и показывает настоящий результат, а не умозаключения.

0

Curry, Знать то могут. Только вот там есть ньюанс что если не развернулся цикл по элементам внутри оператора то и сам оператор не заинлайнится и обработка каждого элемента будет отдельной инструкцией. А если развернется то и заинлайнится и будет обрабатывать именно как вектора. а зависит это банально от того как обходятся элементы - через итератор или через индекс. через итератор он развернуть цикл не сможет даже при константном n, потому что значение указателя в компайлтайме не известно.

Добавлено через 12 минут

Сообщение от Curry Я, в таких случаях, пишу несколько тестовых вариантов и сравниваю время выполнения (что тоже нужно уметь делать правильно). Это и быстрее, и показывает настоящий результат, а не умозаключения.

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

0

Сообщение от Fulcrum_013 А все эти протестируем - не более чем метод антинаучного тыка.

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

0

Сообщение от Curry Но поглядывать и писать на асме большие разницы.

Не ну это да. Даже на вставки ассемблерные еще в 90-х забил глядя на то как оптимизатор оптимизит.

Добавлено через 2 минуты

Сообщение от Curry далее стало общепризнанным что эксперимент - способ научного познания

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

Добавлено через 2 минуты

Сообщение от Curry Это "критерий истины - практика".

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

0

Сообщение от Curry С++ не привязан к конкретной машине.

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

Сообщение от Curry Только если ваша личная классификация, но не общепринятая. Да и дело не в названии.

Согласен, дело не в названии. Смысла продолжать эту тему не вижу.

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

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

Сообщение от Fulcrum_013 Вообще всыско/низко уровневость программирования и высоко/низкоуровневость языка на котором оно осуществляется - ортогональные понятия.

Так, хорошо. Вот только мы обсуждали именно языки.

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

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

Сообщение от Fulcrum_013 С каких пор статистика популярности стала объективными данными?

Я ведь привел вам определение, что означает слово "объективно". Эти данные - есть в них корелляция с чем-то или нет - объективны. Ваши домыслы - нет. Именно поэтому все ваши высказывания про 99% и 1% отправляются в помойку без рассмотрения.
Вот данные по объему кода винды и линукса взяты не с потолка, а подкреплены источником. Они были рассмотрены и, как и следовало ожидать, опровергли ваши фантазии.
Так что пока не найдете доказательств ваша болтовня останется только болтовней.

Сообщение от Fulcrum_013 При разработке растет как и количество типов над которыми нужно обеспечить соблюдение правил алгебры, так и объем кода для которого это надо сделать. <???> А соответсвенно, поскольку в этом плане необходимо согласовывать зависимоси между разными строками, имеем сложность пропорицональную количеству m строк кода в степени n^2 правил.

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

Сообщение от Fulcrum_013 Еще раз для самых одаренных -языки не имеющие полноценного механизма шаблонов

Так вы еще и кодогенеративные костыли обязательными называете?!
Ладно авторы Си встроили язык макросов в свой язык - на то время вменяемых альтернатив такому костылю не было. Но называть подобное вершиной компьютерной мысли!

Сообщение от Fulcrum_013 Т.е. как результат не позволяют абстрагироваться ни от внутреннего устройства сущностей, ни от управления ресурсами и взаимосвязями, ни от низкоуровневых деталей в духе того каким образом живут в памяти обрабатываемые строки.

Хорошо, С++ не позволяет абстрагироваться от внутреннего устройства сущностей (приватные поля объектов обязательно надо описать в заголовочном файле), от управления зависимостями и взаимосвязями (аналогично), от представления строк (до сих пор используют унаследованные из Си строки ASCIIZ, плюс std:string, плюс юникодные версии (wchar_t / std:wstring)). А языки высокого уровня позволяют.
Что дальше?

Сообщение от Curry Если и тут пытаться анализировать "выхлоп", то можно придти к неправильным умозаключениям, т.к., авторы кодогенератора могут знать лучше вас.

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

Сообщение от Curry Мне приходится поглядывать в асм при написании программ под микроконтроллеры

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

0

Сообщение от COKPOWEHEU Размер стандартных типов данных хотя бы.

Каким образом он к какой то машине привязан если там указан диапазон значений?

Добавлено через 5 минут

Сообщение от COKPOWEHEU Да и набор стандартных библиотек во многом платформо-зависимый

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

Добавлено через 8 минут

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

Ошибки с индексами вообще на каждом шагу. А с указателем даже с сырым - ну это очень постараться надо не понять что это такое и что с ним нужно делать. Потому что два указателя сложить и получить чушь невозможно. С индексами массивов запросто. Указатели в плане арифметики и т.д. гораздо безопаснее - они типизированы по тому на какой объект указывают. Индексы нет. Ничто не мешает сунуть индекс предназначаемый для одного массива в другой. С указателем этот номер не пройдет. Так что это опять же из серии легенд безсовестных евангелистов. И построен этот весь вымысел про ужасные сегфаулты исключительно на том что неквалифицированному горе-кодеру что такое оут оф рэндж проще понять чем что такое сегфаулт. А вообще сегфаулт это очень большая редкость. Лично я ее видел только пару раз во время отладки сегментированного контейнера. А что поделаешь - на этом уровне без индексов массивов не обойтись а значит и без ошибок с ними. Отсюда и сегфаулты.

0

Сообщение от Fulcrum_013 Каким образом он к какой то машине привязан если там указан диапазон значений?

Так каков диапазон значений int'а?

Сообщение от Fulcrum_013 Вообщето платформощависимые библиотеки - это средство сокрытия разницы оси. Т.е. средство абстрагирования от платформы.

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

0

Сообщение от COKPOWEHEU Эти данные - есть в них корелляция с чем-то или нет - объективны.

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

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Так каков диапазон значений int'а?

не мене [-32768, 32767] и не более чем у long int. Сколько именно - решают производители компилятора.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU ы путаете платформозависимые библиотеки вроде winapi

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

Добавлено через 3 минуты

Сообщение от COKPOWEHEU . А языки высокого уровня позволяют.

Пруф этому вашему бреду будет? А то пока что только голословные утвержденияпро какие то возможности которыми эти ваши манаджеды и прочие обрубки не обладают и не более того.
Это при том что то что GC не способен управлять ресурсами и своевременно деинициализировать объекты, без чего автоматическое управление взаимосвязями не возможно - это англицким по монитору в мануале у оного GC написано.

Добавлено через 16 минут

Сообщение от COKPOWEHEU Вот только мы обсуждали именно языки.

Не пытайтесь вилять. Бред вы несете по обоим вопросам.

Добавлено через 6 минут

Сообщение от COKPOWEHEU Так вы еще и кодогенеративные костыли обязательными называете?!

А без этого о коде самостоятельно подстраивающимся к другому коду можете даже не мечтать. К примеру вы при помощи шаблонов декларируете систему взаимосвязей они генерируют код их поведения.
Так же как и о копайлтаймовых вычислениях. К примеру вы в шаблон декларативно грамматику задаете а он ее приводит к LL1 виду и рекурсивный спуск без возвратов генерирует.

Добавлено через 7 минут

Сообщение от COKPOWEHEU В месте, обозначенном <???> вы пропустили весь алгоритм доказательства. Возможно, вы считаете его очевидным, но я нет. Поэтому будьте добры привести его полностью.

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

0

Сообщение от Fulcrum_013 Следуя вашей логике из того что лярд индусов мотыгой мотыжничают трахтор в плане землепашества какой то отстой потому что не популярный

Вы хоть сами поняли что сказали? Подсказываю: "знаки препинания".

Сообщение от Fulcrum_013 Сколько именно - решают производители компилятора.

Именно об этом и речь.

Сообщение от Fulcrum_013 а каким боком вообще winapi относится к С++

Тем, что это пример платформо-зависимой библиотеки, естественно. Или вы увидели знакомое слово и напрочь забыли о контексте, в котором оно упоминалось?

Сообщение от Fulcrum_013 Именно такой подход изобретенный для С и похоронил концепцию специализированных языков окончательно.

Я вас разочарую: специализированные языки потому и специализированные, что используют терминологию предметной области, под которую специализированы, а вовсе не машину.
Более того, в низкоуровневых языках по-прежнему постоянно приходится использовать ОС-специфичные библиотеки чтобы добиться максимальной производительности или функциональности (под что они в общем-то и заточены). Зачастую эти библиотеки заворачиваются в более или менее переносимые обертки.
И даже в высокоуровневых языках вроде того же Питона бывает необходимость обратиться именно к функции конкретной ОС. Да хотя бы получить адрес домашнего каталога пользователя или переменные окружения.
Так что да, даже в высокоуровневых языках встречается платформо-зависимый код.

Сообщение от Fulcrum_013 . А языки высокого уровня позволяют. Пруф этому вашему бреду будет?

Это такая тактика борьбы? Заставлять меня лазить по ветке смотреть что же вы там пытались процитировать. Нет, так это не работает. Цитируйте и формулируйте свою мысль полностью.

Сообщение от Fulcrum_013 Это при том что то что GC

Да оставьте вы его в покое! Что ни фраза то какой-то словесный понос про GC. Откуда такая ненависть? У меня только два варианта: либо вы втайне завидуете программистам, которые этим пользуетесь и пытаетесь убедить сами себя что GC вот ну вообще бесполезен и никому не нужен. Либо вы уже когда-то пробовали им пользоваться, не сумели и теперь проецируете этот болезненный опыт на окружающих.

Сообщение от Fulcrum_013 Не пытайтесь вилять. Бред вы несете по обоим вопросам.

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

Сообщение от Fulcrum_013 А без этого о коде самостоятельно подстраивающимся к другому коду можете даже не мечтать.

Ну так код и не должен подстраиваться к другому коду. Слово "декомпозиция" вам совсем ни о чем не говорит?

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

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

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

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

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

...бессмысленную работу. Вы же сами утверждали, что задача программиста - описать готовую формулу терминами языка программирования. Все возможные взаимодействия различных параметров в формуле уже записаны и меняться не будут.
Если же вы пытаетесь притянуть за уши контроль ошибок сложения величин с различными единицами измерения, то разочарую: такие ошибки - чрезвычайная редкость, гораздо чаще встречается неправильный знак (+/-) или неправильный индекс одной из десятка переменных одинакового типа. Просто потому что в формуле они обозначаются одной и той же буквой. Более того, в некоторых эмпирических формулах приходится сознательно выполнять странные операции вроде взятия корня из мощности, которое дает размерность длины (расчет трансформатора) или и вовсе экспонента от физической величины (вот только где видел такое с ходе не вспомню). Нет, это можно, конечно, обойти костылями в виде спецтипов коэффициентов преобразования. Но они усложнят код, не давая реальных преимуществ.

0

Сообщение от COKPOWEHEU С момента появления, очевидно

Так таки C и C++ высокоуровневые или низкоуровневые? (гусары, молчать!)

Добавлено через 7 минут

Сообщение от Fulcrum_013 Шарашку где программисты до сих пор начерталку чертят

А я, например, нисколько не жалею - и, при случае, могу обойтись бумагой, линейкой и карандашом с циркулем, а они при отсутствии калькулятора на Core i9 таки станут беспомощными котятками.
Суть ведь в чём? В том, чтобы человек понимал суть математических построений, а не просто в одно поле вбил значение - в другом вылезло второе готовое. Вот для того начерталку и изучают.

0

Сообщение от NeoMatrix Так таки C и C++ высокоуровневые или низкоуровневые? (гусары, молчать!)

Я бы сказал нечто среднее. Жесткой привязки к машине, как в ассемблерах, нет, но слой абстракции уж больно тонкий. Собственно, именно поэтому Си и, реже, С++, используются в низкоуровневом программировании.

Сообщение от NeoMatrix А я, например, нисколько не жалею - и, при случае, могу обойтись бумагой, линейкой и карандашом с циркулем

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

0

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

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

Добавлено через 24 минуты

Сообщение от NeoMatrix А я, например, нисколько не жалею - и, при случае, могу обойтись бумагой, линейкой и карандашом с циркулем,

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

Сообщение от NeoMatrix а они при отсутствии калькулятора на Core i9 таки станут беспомощными котятками.

Тут одно из двух - или потом отдел расчетчиков на логарифмических линейках считает год-другой или Core-i9 секунду-другую. Точность пересечений, даваемая построением на бумаге, для промышленного производства крайне недостаточна. При этом и построение циркулем и т.д. давно себя изжило - это и непродуктивно и абсолютно бесполезно было еще в 60-70-ых. С 80-х же основным примитивом, используемым в инженерной деятельности, c подачи Боинга стали NURBS, построение которых без компьютера вообще нереально. При этом как ты не черти там чего, а в NURBS все равно все перестроить придется - станки с ЧПУ именно с NURBS работают, для чего собственно оные NURBS и создавались.

Добавлено через 14 минут
NeoMatrix, Т.е. Core-i9 в данном вопросе, в работе, к примеру, инженера-конструктора, заменяет отдел расчетчиков и отдел чертежников - т.е. то что делал не инженерный персонал. А задача программиста - таки научить Core i9 все это делать с нужной точностью. И начерталка в этом плане вообще ни к чему - у компутера глазов нету, он пересечения узреть может только путем решения систем уравнений описывающих тела, так же как и все остальное сделать исключительно путем решения систем уравнений/табуляции функций и т.д. Начерталка этих вопросов не касается от слова абсолютно.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Я бы сказал нечто среднее

Во первых среднего не бывает. Бывает либо низкий уровень - т.е. команд проца, либо высокий - т.е. исходник к конкретному процу не привязан.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU но слой абстракции уж больно тонкий

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

Добавлено через 3 минуты

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

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

Добавлено через 5 минут

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

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

Добавлено через 40 секунд

Сообщение от COKPOWEHEU Если же вы пытаетесь притянуть за уши контроль ошибок сложения величин с различными единицами измерения, то разочарую: такие ошибки - чрезвычайная редкость, гораздо чаще встречается неправильный знак (+/-) или неправильный индекс одной из десятка переменных одинакового типа.

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

Добавлено через 6 минут

Сообщение от COKPOWEHEU Ну так код и не должен подстраиваться к другому коду. Слово "декомпозиция" вам совсем ни о чем не говорит?

Слово абстракция вам о чем то говорит? Или слово композиция декомпозиций?

Добавлено через 8 минут

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

Ну вот именно это концепция универсального языка и похоронила концепцию специализированного. Она дала возможность добавления работы с сущностями предметной области библиотечными средствами. Т.е. еще раз для самых одаренных - гораздо проще сделать под предметную область библиотеку чем язык. При этом сам этот язык тоже надо на чем то делать. Библиотеку же можно изготовить на самом же этом универсальном языке, и в реалиях С++ это будет неотличимо от добавления всего этого в ядро даже синтаксически.
Именно поэтому концепция специализированных языков и умерла, как только процедурные языки дали возможность это делать хотя бы семантически эквивалентно добавлению в ядро. Это все банально композиция декомпозиций. И никакие языки тут за уши притягивать не надо. Достаточно высокоразвитых средств создания абстракций у универсального языка.
Именно поэтому они называются универсальными - годны и для создания библиотеки - т.е. по факту специализированного языка, и для решения с ее помощью задачи. Мало того таким способом достигается то что абсолютно недоступно для "специализированных" языков - а именно подключение сразу нескольких специализированных библиотек - т.е. работа на стыке множества предметных областей, для чего в случае использования "специализированных" языков пришлось бы разрабатывать одноразовый язык на каждую задачу.
Т.е. универсальные потому и универсальные что в плане возможностей специализации резко превзошли специализированные.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU ем, что это пример платформо-зависимой библиотеки, естественно

Еще раз для самых одаренных - каким боком эта библиотека относится к С++, окромя того что ее можно использовать из С++?

Добавлено через 9 минут

Сообщение от COKPOWEHEU Именно об этом и речь.

И каким боком то что диапазон не завист от того под какой проц он компилится, делает язык более зависимым от железа чем к примеру чем JаvaScript, у которого размер инта зависит от того на x32 или х64 оно запущено? Или у манаджед/скриптовых языков диапазон значений того или иного типа не производитель компилятора/интерпритатора определяет?
Т.е. еще раз для самых одаренных - если к примеру Microsoft решил что int будет иметь диапазон [-2,147,483,648, 2,147,483,647] и будет равен по диапазону long то он будет иметь этот диапазон под любой проц - хоть под x32 хоть под x64 хоть под Intel хоть под ARM. Если к примеру Intel для своего компилятора решит по другому, то у них будет по другому, но тоже под любой проц.
Где тут зависимость от архитектуры конкретного проца, как это наблюдается к примеру у JavaScript?

Добавлено через 5 минут

Сообщение от COKPOWEHEU Это такая тактика борьбы? Заставлять меня лазить по ветке смотреть что же вы там пытались процитировать. Нет, так это не работает. Цитируйте и формулируйте свою мысль полностью.

Еще раз - так пруф таки будет тому что куцие скриптообрубки в плане построения и использования высокуровневых абстракций могут предложить что то большее чем универсальные языки или нет?
Пока что видим что они тех средств которые есть для этого у С++ и частично у Ады они лишены напрочь.

0

Сообщение от Fulcrum_013 Во первых среднего не бывает.

Для фанатиков - конечно, у них либо черное, либо белое. В реальном же мире бывает и не такое.

Сообщение от Fulcrum_013 Что вы называете слоем абстракции?

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

Сообщение от Fulcrum_013 В каких единицах измерения все это измеряется и кто должен следить за тем чтобы сошлись едииницы измерения?

Тот, кто будет писать формулу, естественно. Кто же еще? Машина на это не способна, по крайней мере пока не изобретут ИИ.

Сообщение от Fulcrum_013 И т.д. Правда гораздо проще и безопасней в плане случайных ошибок?

"Безопаснее" - возможно, от редких ошибок это и спасет. Но усложнение кода этого явно не стоит. Вы же сами видите, насколько менее очевидной стала запись.
Ну и по вашему коду не очевидно сколько лишних типов придется прописать и насколько усложнится взаимодействие между ними. То есть то что "намного" - очевидно.
Вот, например, формула оценки КПД импульсного трансформатора (взято отсюда):

F - частота (кГц), P - мощность (Вт), результат - проценты
Формулька довольно простая, так что реализовать ее в виде кода не составит для вас труда.

Сообщение от Fulcrum_013 Или слово композиция декомпозиций?

Композиция происходит по интерфейсам, а не по исходному коду.

Сообщение от Fulcrum_013 Еще раз для самых одаренных - каким боком эта библиотека относится к С++

Никаким, насколько я знаю. А зачем вы к ней С++ приплели?

Сообщение от Fulcrum_013 Или у манаджед/скриптовых языков диапазон значений того или иного типа не производитель компилятора определяет?

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

0

Сообщение от COKPOWEHEU В данном случае скрываются конкретные ассемблерные команды и способ обращения к памяти, но ни размер регистра, ни структура памяти не скрываются.

Это как же он не скрывается если встроенные типы на любом железе будет предоставлять одинаковый диапазон? К примеру long будет 32 бита что на древних 16-битных компах что на x32 что на x64 что где угодно. Это как раз и есть отвязка от инструкций проца - на x16 компилятор сгенерирует длинную арифметику, на x32 работу с целым регистром, на x64 c половиной регистра, а диапазон представления отснется тем же. Где тут зависимость от размера регистра?
А к примеру в вашем "свервысокоуровневом" JavaScript он будет зависеть от проца на котором оно запущено.
И что по вашему означет не скрывается способ обращения к памяти?
вот написал я к примеру
Это обращение к памяти. Где тут по вашему что то может быть скрыто или не скрыто?

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Никаким, насколько я знаю. А зачем вы к ней С++ приплели?

НУ дак вы же зачем то про нее речь завели в контексте каких то выдуманных вами "уберязыков"/

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Тот, кто будет писать формулу, естественно. Кто же еще? Машина на это не способна, по крайней мере пока не изобретут ИИ.

Прекрасно способна еще с 80-х. Это всего лишь на всего тот же самый контроль совместимости типов. Для этого всего лишь нужно определить алгебру над сущностями предметной области - т.е. перегрузить операторы.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Но усложнение кода этого явно не стоит.

Это его упрощение и очень серьезное.

0

Сообщение от Fulcrum_013 Это как же он не скрывается если встроенные типы на любом железе будет предоставлять одинаковый диапазон?

Именно потому что на разном железе диапазоны будут разными. Хотите одинаковые - используйте int32_t, а обычный int изначально заточен под максимальную эффективность на конкретном железе.

Сообщение от Fulcrum_013 К примеру задачи развертывания софтин гораздо лучше решают инсталл-шиелды чем всякие баши и т.д.

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

Сообщение от Fulcrum_013 Прекрасно способна еще с 80-х.

То есть вы уже изобрели искусственный интеллект, определяющий что вот эти два расстояния складывать можно, а вон те - нельзя?

Сообщение от Fulcrum_013 Это его упрощение и очень серьезное.

Ну так продемонстрируйте!

0

Сообщение от COKPOWEHEU Композиция происходит по интерфейсам, а не по исходному коду.

Ну а подстраиваться под интерфейс связанного объекта, или под реалии окружения, тоже типа не надо от слова совсем? При этом интерфейс понятие растяжимое. К примеру в него может входить и то что связанный объект должен хранить интрузивно. А так же интерфейсом могут быть вообще метаданные обо объекте. Не забывайте что абстракция нужна только для того чтобы ее можно было конкретезировать как угодно.

0

Сообщение от Fulcrum_013 НУ дак вы же зачем то про нее речь завели в контексте каких то выдуманных вами "уберязыков"

Речь, вероятно, об этой цитате:

Сообщение от COKPOWEHEU Да и набор стандартных библиотек во многом платформо-зависимый.

Естественно, под "стандартными библиотеками" имелись в виду не только библиотеки языка, но и взаимодействия с ОС. Без этого довольно трудно написать мало-мальски полезную программу, а сделать кросс-платфероменную обертку с ходу тоже не выйдет. Собственно, я повторил то, что было сказано.

0

Сообщение от COKPOWEHEU Ну так продемонстрируйте!

А то так не понятно что типы достаточно определить один раз, а юзаться они будут в этой предметной области всегда? Т.е. на 200 строк дибы работы с наименованиями и 3 строки определения конкретных типов, а использования будет мульйоны строк?

Добавлено через 1 час 52 минуты

Сообщение от COKPOWEHEU То есть вы уже изобрели искусственный интеллект, определяющий что вот эти два расстояния складывать можно, а вон те - нельзя?

О чем вы вообще бредите то? Речь о чем шла? О том чтобы определить алгебру над сущностями. Если они не должны складываться - сделайте два типа расстояния не складываемые друг с другом. Какие проблемы то?

0

Сообщение от Fulcrum_013 А то так не понятно что типы достаточно определить один раз, а юзаться они будут в этой предметной области всегда? Т.е. на 200 строк дибы работы с наименованиями и 3 строки определения конкретных типов, а использования будет мульйоны строк?

То есть опять в кусты?

0