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

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

Слушай, ты комментом ниже приводишь выдуманный из воздуха пример:

А бывает и по-другому. Кто-то другой взялся за препроцессор, а ты потом скачиваешь программку из сети и ни сном ни духом не подозреваешь, что printf подменён на burn_this_computer.

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

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

Мне лень смотреть, протащил ли Вирт этот косяк сквозь другие свои проекты. Не помню.

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

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

Действие не должно возвращать результата, или же возвращать булевый результат - получилось или нет. Если же оно возвращает результатом то, что само и сделало - теоретически, можно сэкономить строчку кода (a=b=c), но практически в большинстве случаев это источник потенциальных проблем. В Паскале никто и не подумает, что возможен аналог С-шного if (a=0), даже если записать его как if a:=0 then… - мухи (присваивание) отдельно, котлеты (результат сравнения) отдельно.

Зато в Паскале возможен if (a=b), где a или b будет является вызовом функции с сайд эффектами.

Как ты сказал… «Действие не должно возвращать результата»? =))

Это не существенно. Все равно нужно знать что такое «a». Побочный результат при вычислении выражений это уже большая проблема. Но она существует в большинстве императивных языков.

Зато в Паскале возможен if (a=b), где a или b будет является вызовом функции с сайд эффектами.

Ну и в Си тоже такое возможно.

Это не существенно

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

Побочный результат при вычислении выражений

Это уже отдельная проблема.

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

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

То есть это плата за выразительность.

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

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

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

Ну я же не сишник…

Ну и в Си тоже такое возможно.

Правда что ли?

конечно. или в си уже создавать побочные эффекты в функциях?

В Си запись if (a==b) не содержит вызова функций.

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

if (a() == b())

А такое содержит. И как ты определишь наличие/отсутствие побочного эффекта.

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

А зачем синтаксическая однозначность там, где всё надо определять в нужном месте? Определили a как переменную - будет переменной, определили как функцию - будет функцией. Решение лишь за программистом. И то, и то имеет идентификатор. А ещё есть более сложные структуры (особенно в более поздних реализациях), и каждую из них надо правильно определять и использовать. Но в 99 % случаев при неправильном использовании будет ошибка. Попробуйте присвоить что-то той же функции вне её тела - получите ошибку сразу. Так что весь вопрос - определение идентификатора. Да, возможны проблемы, когда в зоне видимости более одного идентификатора с одинаковым названием, но это дело кривости рук программиста. Нужно что-то глобальное - называй понятно, а всякие локальные счётчики-буферы и прочие хламовники можно называть x, a, i и т.д. Макросы тут не совсем аналог. Они действительно могут менять что угодно. Вплоть до известного «хака» #define private public

Но это то, что сделано специально. А можно какой-нибудь символ поставить в макрос в начале или в конце - и его использование может поменять смысл выражения в корне. Не просто обращение к идентификатору, а выполнение действия. Скажем, в начале макроса поставить звёздочку - что это будет? Умножение, разыменование ссылки? Зависит от контекста.

А такое содержит.

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

Посмотрел в Ада. С вызовами функций та же шляпа.

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

Всё же сравнение ЯП - это больше инженерная вещь, чем математическая. Важны не столько максимально плохие возможные случаи, но мат.ожидание ущерба на 1000 строк кода в реальных проектах.

И какую это несет информацию если ты не знаешь что такое a и что такое b?

Я так понимаю, мне эти комменты всё пишут люди, которые с реальными большими кодовыми базами не работали. А я вот работал. Рефакторил. А ты вот пишешь:

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

Знаешь, о чем это говорит? О опыте создания write only кода. То есть иными словами, о малом опыте в принципе.

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

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

Это грабли иного вида.

У тебя обычно в коде есть foo(), который то ли функция, то ли макрос. Но в обоих случаях наличие скобок подразумевает передачу управления в другой кусок кода.

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

Всё же сравнение ЯП - это больше инженерная вещь, чем математическая. Важны не столько максимально плохие возможные случаи, но мат.ожидание ущерба на 1000 строк кода в реальных проектах.

Ну значит наши инженерные оценки разнятся.

Сайд-эффект - личное дело программиста. Он захотел написать функцию с явным сайд-эффектом - и написал (а потом «красиво» ими пользуется, но иногда сам «нарывается» на них там, где не ожидает). Не захотел - не написал, а написал функцию, всегда возвращающую один и тот же результат. Мог встроить в функцию действия, которые, вроде как, формально и являются сайд-эффектами, в логике программы таковых эффектов не дают (например, вызов Application.ProcessMessages). Программист - сам себе царь и бог. Или ССЗБ, его личное дело. Но проблема появляется именно от него, а не от встроенного синтаксиса.

Кстати, Вы ещё не дошли до свойств (property), которые выглядят как переменная (поле), ведут себя как переменные (только указатель взять нельзя, и как var-параметр не передать), а на деле вызывают процедуры и функции. Но тут именно задача программиста сделать так, чтобы «сайд-эффекты» не вредили, а помогали (например, при присвоении значения свойству ширины окна не просто поменять переменную, где она хранится, а за одно поменять сам размер окна). Но ещё раз - все эти сайд-эффекты - личное дело программиста. Любой вызов идентификатора, определённого как процедура или функция - это выполнение всех действий, туда заложенных. И получение результата, если это функция. Но подразумевается, что действия там будут сделаны для получения этого результата. А вот встроенные действия побочных результатов давать не должны. Математические действия - это математические действия (результат числовой соответствующего типа, и никак иначе, не булевый, не символьный), сравнение - это сравнение (и результат строго булевый), присвоение - это присвоение (и никакого результата тут нет, только действие).

которые с реальными большими кодовыми базами не работали.

А вот как раз для большой кодовой базы и существуют негласные правила: всё, что глобально, надо называть понятно. Да, их можно определить в проекте, например, начинать названия переменных с буквы v, функции с fun, типы с T и т.п. А проблемы простых идентификаторов будут исключительно в локальных процедурах/функциях/методах. Понятно, что если горе-программист назовёт в своём огромном коде глобальную функцию как a, ему же самому мало не покажется уже через пару недель. Но испортить себе жизнь, я думаю, возможно в любом языке программирования.

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

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

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

Кстати, возможность в Паскале сделать так, чтобы один и тот же идентификатор мог вызываться и как функция (и ~метод), и как переменная, и как постоянная, и как свойство - скорее, фича, а не баг. Понятно, что это всё должно быть в тему. Функция должна быть более или менее однозначна (если есть сайд-эффект - он должен быть просчитан). Пример - функция/свойство/(редко) поле Count. Число элементов в некоем классе/записи/объекте. Это вполне может быть в некоем стороннем наборе модулей. Причём в одной версии это может быть вообще запись с переменной Count, в которую просто бросают число элементов, в следующей это будет класс (да, конечно, превращать запись в класс не всегда просто, но не невозможно) с методом Count, который исходя из каких-то соображений рассчитывает число элементов, а в послеследующей - свойство, причём доступное и на запись - то есть, число элементов можно так увеличивать (автоматически добавляются пустые) или уменьшать (автоматически освобождаются лишние). При этом старый код вполне себе будет работать без изменений, хотя сначала была переменная, потом функция, а потом - свойство.

Реально расширение кругозора в студенческие мне дал Форт, хоть я на нём ни строчки не написал

А конкретнее, что он тебе дал? По мне так COBOL тоже очень интересный, особенно возможностью модифицировать свой код стандартными средствами языка, а отбив отступов учит прилежности, может его лучше паскаля?

Дал идею метапрограммирования. Если бы его не было, лисп бы так хорошо не зашёл, наверное. После чтения Форта, чтение заявлений типа «всё, что вам нужно - это классы в С++», сразу образовывало понимание, что меня пытаются развести. А так бы может быть стал и плюсовиком. Был этап увлечения этим языком. Потому и важно именно в студенческие годы учить разным парадигмам. Мне просто повезло, что эта книжка попалась в руки, а могла и не попасться.

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

Да вообще-то в сишном коде любое foo может тоже из-за препроцессора означать:

• вызов функции
• выражение
• просто какой-то кусок кода из нескольких строк
• открывающую фигурную скобку и кусок кода

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

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

Дал идею метапрограммирования.

Метапрограммирование ради метапрограммирования это ужасно, не зря автор форта к концу выпилил все подобные возможности. Где бы это можно было применить?

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

У C/C++ есть PGO. То что ты предлагаешь, звучит странно, что то там считать, и заменять imul rax, [param1] на imul rax, 10? Да больше тактов уйдет на такие замеры, чем выйдет с профитов на такие оптимизации.

Метапрограммирование ради метапрограммирования это ужасно,

Ужасно это или нет, только почему-то оно всем нужно и на практике без него не обойтись CMake, uic, configure, #define, шаблоны плюсов - это просто пять примеров метапрограммирования, которые ты используешь. Ужасно это или нет - ну сами там определитесь, в сишном мире.

То что ты предлагаешь, звучит странно,

Думай что хочешь, мне лень спорить. Хотя если бы ты подумал получше, то оптимизация использования константы - это совсем не то же самое, что PGO. Константные выражения вычисляются во время компиляции. Если в выражении почти все выражения константы, а где-то в глубине - не константа, то она препятствует вычислению всего выражения во время компиляции. Честно сказать, неясно, почему я должен это объяснять. Это просто, ты должен был сам додуматься.

Самое главное, из твоей реакции получается, что ты до сих пор жил без понятия о метапрограммировании. Т.е. у тебя за окном торчали из земли какие-то коряги. Но ты не знал, что все они обобщаются под понятием «деревья», а их совокупность представляет из себя «лес». Жду, как ты сейчас начнёшь доказывать, что это всё отдельные, не связанные между собой коряги, и что неестественно пытаться объединить их в какую-то общую категорию, потому что на одних есть иголки, а другие на зиму опадают, а у третьих веток нет по бокам. А можешь вместо этого просто заглянуть в словарь и посмотреть, что такое метапрограммирование.

Ужасно это или нет, только почему-то оно всем нужно и на практике без него не обойтись CMake, uic, configure, #define

Там используется по делу, а вот про неиспользование по делу читай ниже.

Если в выражении почти все выражения константы, а где-то в глубине - не константа, то она препятствует вычислению всего выражения во время компиляции.

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

А кто будет решать, где по делу, а где не по делу? Если твой язык не позволяет какое-то использование, то оно автоматически не по делу, потому что не могли же K&R со Страуструпом хрень сделать? Или как-то ещё будем определять? Я могу привести пример, программа Cakewalk. Когда были 486-е, она генерировала машинный код для сведения того числа дорожек, которые были в проекте. Тогда мощностей машин едва хватало на 6-8 аудиодорожек.

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

Какие проблемы приносит метапрограммирование думаю объяснять не нужно.

Ну т.е. мы сначала выбираем язык С++, где его нет, а потом с этим лозунгом оказывается, что метапрограммирование реализуется сложно и работает ненадёжно. Но виновато в этом метапрограммирование, а не выбор нами языка, так? А изучение Форта и Лиспа, где оно есть, работает надёжно и имеет кучу применений, мы запретим из религиозных соображений, чтобы мы не оказались дураками с нашим выбором.

Кеш просто оптимальнее, очень просто реализуется даже в лиспе, содержит в себе уже код для выявление частых значений, не зациклен на одном лишь значении, а может покрывать большее число, не теряется поддержка в IDE, код не отличается в редакторе и в программе, легко отлаживается, легко понимается. Согласен?

Да, GNU build tools и прочее действительно отвратительны в особенности. Но это из серии «Рабинович напел». То же самое можно делать по-нормальному.

Это зависит от частной задачи. Я уже писал о символьном вычислении производных, которое в лиспе легко делается макросом без потери надёжности. А в плюсах нужны отдельные костыли (отдельные целые программы) на Питоне, что увеличивает сложность системы и снижает надёжность. Кеш и PGO как помогут символически вычислить производную? Никак.

Лучше не повторять этот паттерн, что «то, что сложно делается в плюсах, не нужно», потому что он глупо выглядит. Кстати, SBCL тоже используется для числодробилок, хотя честно говоря, я не понимаю, как. Багов там море.

И кстати, для аудиодорожек ни кеш, ни PGO не годятся. Там жёсткое реальное время, надо сразу выйти на нужную скорость, без разогревов. Так что найти пример, где нужна именно осознанная генерация кода в рантайме, не так сложно. Весьма вероятно, что в этот код подставлялись:

• уровни громкости дорожек
• Master Volume
• адреса буферов в виде констант

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

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

Ты кстати уже много сообщений не по теме оставил, надо наверное прокомментировать. Где применять форт не знает даже его автор, я тоже не знаю, а я один из самых больших фанатов форта, у меня и свой компилятор есть, не просто какой то мусорный которых полно на гитхабе, у меня оптимизирующий, и свой ассемблер есть, с коммерческими все же не сравнить, там есть IDE и набор библиотек, поддержка разных платформ. Но ты видимо пишешь мне, и пишешь так, будто я программист на С++ который не хочет видеть ничего нового. Интересно было бы услышать, где в современном мире можно применять Forth.

Кеш явно быстрее запуска компилятора.

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

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

Никто не говорит про один тип уравнений. Вы вообще представляете объем вычислений необходимый для обработки полевых наблюдений сейсморазведки по небольшому месторождению? Что бы понять где там нефть/газ и сколько её? А как считаются новые газотурбинные двигатели? Ядерные реакторы? Маски для литографии при производстве чипов? Антенны? Поиск новых лекарств? И т.д. и т.п.

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

До появления ПК основными мощностями были кластеры в КБ и ВЦ общего пользования которые как раз считали промышленные задачи. Но тогда моделирование не было столь всеобьемлющим как сейчас, много считалось на бумаге и тогда царствовал фортран. Лет 30 назад ситуация начала меняться, сейчас основная суммарная мощность у геймеров, домохозяек которые смотрят сериалы на тытрубе и офисных клерков с вордом. Но если говорить про моделирование, именно по объёму расчётов, то матлаб и R там занимают мизерную долю - просто потому что матлаб дикий тормоз и там ничего серьёзного посчитать нельзя в принципе. А для R нет столько работы.

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

Во-вторых, я не знаю, где применять форт. Он дал мне идею метапрограммирования, и на этом наши пути разошлись.

Во-первых, как я могу проверить, что ты действительно столь крут в форте?

А разве есть темы по форту? Это мертвый язык, буквально первая тема которую я вижу появилась сегодня: Ещё один Форт (комментарий)

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

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

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

А вот если взять какой-нибудь инстаграм, то да. Он влияет на человечество. Или система видеонаблюдения во всех подъездах. Или сотовая связь.

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

Про форт принимается.

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

снижает надёжность.

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

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