Программируете ли вы на Паскале?

Есть специальные техники символьного дифференцирования в плюсах основанные на перегрузке операций и спец.типах данных, которые принимают на вход КОД функции и реализуют её производную.

А можно пример? Сравню его с моей наколенной поделкой.

Так ты спрашивал про кругозор - я и ответил. Цппшник ты или нет, но ты защищаешь цпп и сводишь то, что в нём сложно или нельзя, к ненужному.

Я просто не люблю излишне сложные решения.

Так они в контексте плюсов сложные, а не вообще. А что, автор Форта реально выкинул компилирующие слова?

Если что-то генерит плюсовый код, то это уже не называется «программировать на плюсах». Ведь когда я (не приведи Бог, конечно, но мало ли, вдруг посадят в шарашку и заставят) пишу на плюсах, это же не называется «программировать в машинных кодах».

самая большая и бестолковая числодробилка мира это расчет хешей биткоина.

Опять бредите. У Вас что, непреодолимая страсть к публичном позору?!

даже течение дыма в дымоходе до сих пор посчитать не можете

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

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

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

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

У Вас ещё и дислексия ко всему… удивительно как Вы вообще программируете, нсли Вы простой коммент на лоре асилить не можете то уж ТЗ прочитать и понять точно не в состоянии.

принимают на вход КОД функции и реализуют её производную.

Где здесь хоть слово про хоть какую то кодогенерацию?!

Ну слушайте, тут вы зря полезли фыркать. Чем Вы больше пишете про моё ЧСВ, тем больше видно ваше раздутое ЧСВ. Я достаточно в теме расчётов аэродинамики. Т.е. считать не умею, но уровень сложности осознаю. Потоки в венткоробах считаются по инженерным формулами, взятым из справочника. Справочник написан задолго до вашего C++. Потоки по залу - ну в каком-то приближении может быть и умеете считать, но в реальности без мастерства и эксперимента всё равно у вас ничего не выйдет. Ваши расчёты - это только приложение к эксперименту, которое позволяет вместо комнаты 8x9, где можно откалибровать ваши методы на реальном объекте, посчитать комнату 9x10, условно говоря. Комнату 20x20 или 3x3 вы уже не посчитаете. Я говорю не про конкретные цифры, а про общую обстановку.

Хватит хамить. Все диагносты отправляются по пешеходному сексуальному маршруту.

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

Для символьного дифференцирования можно юзать CAS генерящие плюсовый код

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

считается это все. методом конечных элементов, частиц или еще чего. вся аэродинамика давно считается.

красивое https://www.youtube.com/watch?v=-MkRBeQkLk8

Красивое демо можно. Когда я сам попытался туда полезть, то там есть (было на тот момент) 5 общих методов обсчёта турбулентности, каждый со своими косяками, и в каждом нужно с потолка взять какие-то параметры, от которых результаты будут сильно зависеть. И типа надо 5 лет сидеть у ног учителя и внимать, а потом иметь аналогичные объекты для привязки. Тогда да, можно посчитать что-то. Т.е. если есть, допустим, двигатель, то можно похожий посчитать, обмеряв этот. После этого я оставил тему и даже не попытался заказать на аутсорс. Потом оказалось, что конкретно по моей задаче есть целая книга и что там возникают вещи, о которых я даже не подумал, что они возможны.

А что, автор Форта реально выкинул компилирующие слова?

Там все слова «компилирующие», в зависимости от режима (переменная STATE) слово либо тут же выполняется, либо помещается в машинный код (компилируется?). Метапрограммирование больше исходило от слов читающих исходный код, вместо текста в colorforth раскрашенный текст, слова PARSE нету, строк кстати тоже нету.

Так они в контексте плюсов сложные, а не вообще.

Компилятор это сложно, даже если бы в С++ был встроен так же компилятор как в лиспе, это все равно было бы сложно.

Но конечно, продаваны технологии будут говорить, что у них всё прекрасно, точность 95%

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

https://www.nncron.ru/book/sf/chapter11.htm - кажется, вот это как раз та книжка и понятие компилирующих слов я узнал именно оттуда. IF, THEN, BEGIN, REPEAT. Соответственно, механизм, позволяющий добавлять свои - это и есть метапрограммирование в минимальном объёме.

Конечно, в каких-то частных случаях можно. Я же не говорю, что МКЭ и прочее вообще бесполезны. Но это не «вся аэродинамика».

В ColorForth IF, THEN вшиты в компилятор. Есть IMMEDIATE слова, они могут записывать опкоды, и вмешиваться в процесс компиляции так. Есть еще слово LITERAL, не могу найти, но точно есть возможность вставить вызов другого слова.

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

собирается 10 минут.

cpp-монстры собираются час, два. полдня

Зато потом экономят время пользователям.

Понятно. Даже не знаю, что сказать, не живу в Форт-мире, поэтому не могу дать оценку. В целом, КМК, делать новые языки надо на более мощном языке, чем Форт. Лисп и Окамль - два варианта. Т.е. проще сделать на мощном языке новый компилятор Форта, чем на самом Форте. С этой точки зрения удаление слишком мощных метавозможностей именно из Форта выглядит разумным.

x := a;

Так и в математике так, какой-нибудь игрек есть и функция, и переменная. И даже константа - это тоже функция.

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

Форт проще будет реализовать на ассемблере, чем на этих мощных перегруженных языках, в моем случае так и было (linux amd64).

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

ANS Forth никто не обрезал, там все возможности сохранены.

То есть Вы не в состоянии осознать что речь идёт о двух разных подходах, причём во втором подходе (плюсовом) никакой кодогенерации нет?! Да Вы ещё тупее чем кажетесь…

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

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

Продолжайте позориться ежели хотите, лично мне Вы надоели. Бай.

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

Ну просто непонятно, куда реально люди хотят/хотели переделывать Форт. Смотря какая сложность задачи. Например, полносистемный оптимизатор вряд ли имеет смысл на Форте писать, там нужны как раз «тысяча малополезных функций».

Ну, раз Вы попрощались, значит убыли по указанному адресу :) Так-то не всякий может признать свой явный косяк. Для этого надо быть Мужиком.

Не сильно лучше, чем fpc/лазарус, например.
Ибо и в них есть оптимизация -O1,-O2,-O3,Os и т.п.

Пользователи больше теряют, когда сам алгоритм плох.

Какие ещё пользователи сейчас? Я для себя пишу.

Не сильно лучше, чем fpc/лазарус, например.

Смешно, там могут быть какие угодно флаги, но fpc, delphi сливает gcc, clang, cl.

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

Так-то не всякий может признать свой явный косяк. Для этого надо быть Мужиком.

Кем ты, собственно, и подавно не являешься, по описанной выше причине.

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

Смешно, что смешно.
Я согласился (не видите что ли?), что fpc может быть слабее в оптимизации бинарника.
Однако, на практике всё зависит от компетенции программиста.
Или он пользуется стандартными инструментами, например, qsort, или пишет свои быстрые алгоритмы сортировки.

А заниматься оптимизацией алгоритма на паскале значительно проще и быстрее.

Не сильно лучше, чем fpc/лазарус, например. Ибо и в них есть оптимизация -O1,-O2,-O3,Os и т.п.

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

Пользователи больше теряют, когда сам алгоритм плох.

+100500! И вот тут мы приходим к тому зачем нужны именно плюсы;-)

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

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

Опять таки, претензии к времени компиляции - ок, я написал шаблон который раскрутился в 100500 вариантов и это долго собирается. Но зато это работает быстро! Если это делать на фортане, то либо там будет пачка if которые убьют всю производительность, либо придется руками писать 100500 разных реализаций одной и той же функции (которая на шаблонах одна) и это будет так же долго собираться, но при этом се это будет совершенно нечитаемо (и ненаписуемо).

Какие ещё пользователи сейчас? Я для себя пишу.

Ну дык надо баланс искать. Минимизируется СУММАРНОЕ время написания и исполнения кода. Дальше, в зависмости от задачи, берется тот или иной алгоритм и ЯП;-)

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

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

Собственно, по этой причине в относительно новом курсе MIT по программированию используют питон, а не паскаль. Потому что выразительный живой язык, в отличие от.

такие алгоритмы можно гораздо быстрее написать на питоне.

Именно так. Более того, когда выразительности плюсов не хватает, то берется питон и… если хочется производительности, на нем генерится плюсовый код;-)

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

Чистый Паскаль использовал только как учебный язык на первом курсе первого семестра. Уже во втором семестре мы изучали С, а на втором курсе С++. Делфи как то пропустил, но на Borland C++ Builder пришлось покодить какое то время. Там были Дельфовские компоненты, так что прилось и их иногда разбирать по исходникам.

Вы ещё не дошли до свойств (property)

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

Как мило. Вот захотелось мне в два раза окошко увеличить: меняю ширину - оно херась в 2 раза по горизонтали разъехалось, тут же меняю высоту - херась и пришло в ожидаемое состояние. Могу привести примеры с гораздо более жёсткими последствиями чем «моргание» окошка. Спасибо - не надо нам такого счастья, по старинке лучше ручками правильные обработчики в правильный момент дёрнем. А properties свои засуньте сами знаете куда.

Затем что на ряде платформ были специальные инкрементные регистры и такой синтаксис мог там давать более оптимальный код без оптимизатора.

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

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

Вопрос разве не в наличии инструкции инкремента? При чём здесь адресация?

А заниматься оптимизацией алгоритма на паскале значительно проще и быстрее.

Ахаха! Да ладно.

Магия, наверное.

Вопрос разве не в наличии инструкции инкремента? При чём здесь адресация?

При том, что на некоторых архитектурах выражения вида a = *(p++) или даже *(p1++) = *(p2++) напрямую транслируются в машинный код вида «память-память».

Ходит байка, что Си был разработан как «полу-ассемблер для PDP-11» как раз с учётом этой возможности архитектуры.

Вот абзац в Википедии эту байку опровергает.

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

Я не думаю что само по себе это могло бы оправдать ++ (хотя и приятная плюшка если действительно где-то есть). А вот наличие инкремента и декремента как отдельных инструкций практически на всех платформах с которыми я сталкивался - факт.

вида a = *(p++) или даже *(p1++) = *(p2++)

ПыСы. Не мог не спросить - Вы действительно в () инкремент заворачиваете перед dereference? А зачем? Просто любопытно…

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

Тут не совсем верно. Нельзя объединить «С/C++» в одно понятие. Си – это максимально простой ЯП с минимумом выразительных средств. Си++ — монстр с классами, темплейтами, выводом типов и т.п.

Так вот если мы берём максимально простой неоптимизирующий компилятор в стиле 1985-го года (такие до сих пор во множестве пишут в качестве лабораторных или чисто из личного любопытства), то для Паскаля и Си суть будет примерно одинакова. Однако для машины из 80-х компилятор Си оказывался существенно медленнее по следующим причинам:

• Есть отдельная фаза прохода препроцессором.
• Механизм инклудов требует множества повторной работы при компиляции множества объектных файлов.
• Отдельные элементы парсера сложнее реализовать, например ту часть парсера, которая отвечает за разбор типов.

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

Однако если смотреть с современной перспективы, код на Си компилируется очень быстро. А если скорость конечного кода не важна, а важно только время компиляции, то -O0 делает это еще быстрее.

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

Уже «классический Си++» только на классах и с минимумом шаблонов по меркам 90-х был очень медленным. А компилировать современный Си++ еще намного сложнее.

Это цена за выразительность языка.

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

Википедия не могла прочитать в Википедии, например, про PDP-5 и другие мини-ЭВМ 1960-х?

https://en.wikipedia.org/wiki/PDP-5

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp5/F-55_PDP5Handbook_Feb64.pdf#page=28

AUTO-INDEXING: When a location between 10 and 17 in page 0 is specified as the address in an instruction, and bit 3 is a 1, the contents of that location are read, incremented by one rewritten in the same location, and then taken as the effective address of the instruction.

Ну значит наврали.

Я с этими архитектурами не знаком, читал только про систему команд PDP-11.

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

Как вариант, можно сгенерировать код на lua и исполнить его в luajit. luajit даёт впечатляющие результаты производительности для данной технологии (трассирующий JIT компилятор).

Правда насколько я помню, разработка luajit остановилась на 32-разрядной версии. Это может быть критично в каких-то областях.

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

Си и C++ и сейчас значительно медленнее, и оптимизатор тут не причем. В компиляторах D, Rust, Go и т.п. тоже продвинутый оптимизатор и они быстрее C++.

Да даже в AVR такое есть типа st X+, r16 или st -X, r16

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

На VAX были инструкции POLY, чтобы считать полином от одной переменной одной инструкцией:

https://documentation.help/VAX11/op_POLY.htm

Си и C++ и сейчас значительно медленнее, и оптимизатор тут не причем. В компиляторах D, Rust, Go и т.п. тоже продвинутый оптимизатор и они быстрее C++.

Вот показательный пример, как человек читает жопой. Простите.