Allegro CL 9.0 Free Express Edition стал доступен для загрузки

Слушай, да ты просто мастер вброса! Уже третий годный только в этом треде!

//я тебя запомнил

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

Макросы схемы - это та же схема. Не говори того, о чем не знаешь.

макрос развернётся в лисп код

И его результат обработан не будет. То есть ошибка.

в лисп-2 ничего не будет.

Хорошо, переопределен flet'ом.

это не кодволкер, если даже макры раскрыть не может.

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

Все гораздо проще. Вот смотри:

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

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

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

Математика - язык науки, а не наука. В вышеупомянутой лингвистике (гуманитарной науке) используется он же.

Извиняюсь за задержку с ответом. Погрузился в работу с головой.

Есть. Третий элемент struct-info и есть этот предикат.

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

Еще момент - если хотите в паттерне стрелочки и двоеточия, то в define-simple-macro надо окружать их ~datum: (~datum ->) например.

Спасибо, работает. А в syntax-case подобное можно делать или же тут уже syntax-parse понадобится?

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

т.е. если ломать гигиену простым способом (с datum->syntax или defmacro), то с композабельностью всё хреново становится. И если я хочу делать простые макросы-кирпичики, то я обречён обходить гигиену при помощи относительно тяжеловесных способов.

Теперь я понимаю вашу фразу: «Вообще написание дслей через \„кирпичики\“ хоть и дает определенные преимущества, но и значительно повышает сложность написания». Очевидно, что с таким подходом оверхед от гигиены становится более ощутимым.

Вообще, кстати, можно написать что-нибудь типа такого:

(begin-for-syntax (define-syntax-class unmarked (pattern x:expr #:with v (syntax-local-introduce #'x))))

(define-simple-macro (test (values ...) body ...) #:with (id:unmarked ...) #'(a b c) (let ([id.v values] ...) body ...))

(test (1 2 3) (list a b c)) -> '(1 2 3)

то есть соответствующий syntax-class автоматом из-под гигиены выводит. Можно и для datum->syntax аналогичный написать.

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

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

Потому что вы так привыкли :) Концептуально проще связывание по месту определения, т.к. так связываются _функции_. Чем концептуально проще тот факт, что макросы имеют какие-то свои, особенные, правила связывания? :)

Функции и defmacro — предельно простые штуки. Как отвёртка и молоток. При этом семантика у них настолько разная, что я не вижу смысла делать их похожими друг на друга. Это простые инструменты, использование которых несложно совмещать.

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

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

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

Я вот тоже часто _знаю_, что всё будет хорошо и при использовании простого defmacro, т.к. доверяю своей интуиции, вижу, что на практике проблем не возникнет. Например, with-all-cxrs — очень простой макрос, по поводу надёжности которого я бы не волновался. Об этом ещё подробнее напишу.

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

Аппаратная поддержка для сложных, замороченных языков общего назначения типа C++ или перла вырабатывается только с годами активного использования и только у очень особенных людей (типа моего олимпиадного друга, который больше 10 лет решает контесты на плюсах, и у которого часто программы просто «работают, если компилируются»).

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

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

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

Соответственно, с практикой неудобство пройдет.

Не факт.

Есть подходы и инструменты, неудобство которых я так и не преодолел. Например, трансформеры монад в Хаскелле, использование шаблонов C++ в стиле Александреску, суровое энтерпрайз-ООП, пестрящее модными паттернами. Всё это не работает для меня, сколько бы времени я в это не вкладывал и сколько бы не слушал адептов этих подходов, твердящих, что с практикой всё будет хорошо и просто получаться.

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

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

По поводу простейшего макроса with-all-cxrs:

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

И вот возникает вопрос - что будет если у нас некоторый макрос раскрывается в cadadadr?

Ничего не будет. Меня устроит, если c(a|d)+r будут генериться только для того кода, который я глазами вижу в текстовом редакторе внутри with-all-cxrs. Не нужно внутри такого макроса делать дополнительных макроэкспандов, он по дизайну такой.

Или cadadadar не стоит в expr-позиции?

Пофиг. Мы тупо делаем flatten для всего кода и рассматриваем сразу все символы. Если пара функций лишних сгенерится — не страшно.

Или переопределен let'ом? Кодеволкер этого не заметит, нужный биндинг не введет, hur-dur, жопу разорвало.

Ну и зачем кому-то может понадобится биндить что-то на c(a|d)+r, если оно не будет работать как c(a|d)+r? Мы уже большие мальчики и можем, подумав головой, взять на себя ответственность за использование на практике такого макроса (пусть он в теории и ни на что не годится). Это же _очевидно_, что такой проблемы на практике не возникнет и никакая гигиена или система типов меня не переубедит.

Как сказал по радио Кими Райкконен, побеждая в недавнем Гран-при Формулы 1: «Just leave me alone, I know what I'm doing».

Вообще, да, именно вот такая схема (когда внутри макроса может быть произвольный биндинг, который ВНЕЗАПНО надо как-то раскрыть в зависимости от контекста, при чем конкретное имя неизвестно) вызывает некоторые проблемы. Ну в racket можно выебнуться, переопределив #%app или #%top, что снимет большинство проблем, но не будет работать тогда, когда соответствующий идентификатор уже определен.

А с defmacro всё будет работать. Ещё раз — на практике _не будет_ никаких проблем с перекрывающимися биндингами, т.к. любой c(a|d)+r будет работать как c(a|d)+r, независимо от места определения.

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

Хотя бывает и так, что программист сначала один раз основательно головой подумает над решением задачи, а потом ему приходится ещё в 10 раз дольше думать над тем, как обойти ограничения, навязываемые инструментом. Мне с Delphi7 таким образом регулярно трахаться приходится. И, поверьте мне, это не синдром утёнка.

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

Худо-бедная высокоуровневость, скорость и наличие килотонн готовых структур данных делают свое дело.

Плюсы используются олимпиадниками потому, что на финале ACM ICPC можно использовать только Java и C++. Когда можно было использовать Паскаль, очень многие российские олимпиадники использовали Паскаль.

Впрочем, один из сильнейших олимпиадных программистов современности, беларусский школьник Геннадий Короткевич, висящий на 1 месте в куче рейтингов, использует Delphi всегда, когда есть такая возможность. И все нужные структуры и алгоритмы на коленке по надобности кодит. Даже всякие дебильные сортировки, которых в Делфи встроенных нет :-)

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

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

Мой друг способен закодить и объяснить почти всё из этого списка: http://e-maxx.ru/algo/ и многое из этого на моих глазах кодил, причём узким местом была скорость печати. Типичный выпускник CS-специальности российского вуза вряд ли краем уха слышал и про десятую часть этих вещей.

К сожалению, в работе всё это моему другу не помогает. Он кодит тупые прикладные модули на Делфи7 и ковыряет легаси. Надо его в в какой-нибудь Google пропихнуть :-)

спасибо, за ссылку, зопейсал, прорешаю все на ракетке.

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

Так и самих полей ведь нет :)

А в syntax-case подобное можно делать или же тут уже syntax-parse понадобится?

В syntax-case можно добавить нужные символы в скобки перед паттернами:

(syntax-case stx (-> :) ...), проблема только в том, что это не аналог ~datum а аналог ~literal в syntax-parse, то есть проверка на равенство идет как сравнение _идентификаторов_ а не символов.

т.е. если ломать гигиену простым способом (с datum->syntax или defmacro), то с композабельностью всё хреново становится.

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

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

Ну, я бы не назвал применение syntax-local-introduce более тяжеловесным :) Скорее, наоборот. Ну и это надо только для анафорических макросов (которые встречаются редко, вообще говоря).

Теперь я понимаю вашу фразу: «Вообще написание дслей через \„кирпичики\“ хоть и дает определенные преимущества, но и значительно повышает сложность написания». Очевидно, что с таким подходом оверхед от гигиены становится более ощутимым.

Неправильно :)

На «кирпичиках» выше оверхед от того, что мы работаем с макросами (макросы - штука менее композабельная, чем функции, by-design). И от отсутствия гигиены тоже оверхед выше.

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

А зачем все усложнять и делать семантику дефмакро сильно отличной от семантики defun? :)

Прочитав инструкцию, можно понять, что при помощи неё реально вбить гвоздь: для этого нужно слегка придавить кнопку X, удерживая которую повернуть на 18 градусов рычажок Y и, установив прибор параллельно уровню моря (антенной на юг), нежным вращательным движением против часовой стрелки погрузить специально подготовленный гвоздь в отверстие Z (шляпкой вниз).

практика показывает, что 99% гвоздей вбиваются, как минимум, не сложнее чем при помощи дефмакро :)

Я вот тоже часто _знаю_, что всё будет хорошо и при использовании простого defmacro, т.к. доверяю своей интуиции, вижу, что на практике проблем не возникнет. Например, with-all-cxrs — очень простой макрос, по поводу надёжности которого я бы не волновался.

Но этот макрос некорректен. Вот вам пример того, как ваша интуиция дает сбой.

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

Как я и говорил - дело привычки.

Ничего не будет. Меня устроит, если c(a|d)+r будут генериться только для того кода, который я глазами вижу в текстовом редакторе внутри with-all-cxrs. Не нужно внутри такого макроса делать дополнительных макроэкспандов, он по дизайну такой.

А если, опять же, у вас некоторый макрос раскрывается в with-all-cxrs? Объявлять баг фичей - это не слишком правильно. Баг он и есть баг. В любом случае, если такие использования макроса некорректны, то в их случае макрос должен давать соответствующую ошибку типа «не могу использоваться внутри макроса» или «идентификатор пришел из макроса» и т.п.

Пофиг. Мы тупо делаем flatten для всего кода и рассматриваем сразу все символы. Если пара функций лишних сгенерится — не страшно.

Так этот макрос переопределит нам этот символ, хотя не должен был переопределять.

Это же _очевидно_, что такой проблемы на практике не возникнет

сказал сишник перед тем как словить сегфаулт :)

А с defmacro всё будет работать.

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

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

В том и проблема что у программиста без гигиены НЕТ НИКАКОГО КОНТРОЛЯ. Дебил он , не дебил - он просто не знает, что в макросе Х происходит одна хуйня (макрос раскрывается в with-all-cxrs), а в макросе Y - другая, в результате чего вместе использовать эти макросы нельзя. Или у вас какой-нибудь макрос with-all-logged, который врапает стоящие в head-позиции идентификаторы кодом логгирования, например, а ваш макрос хуяк - и переопределяет все внутри. А еще вы забываете про такую банальную вещь, что вам макрос могут передать в макрос. И тут вообще начинается полная пизда.

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

Я просто не знаю где и какие вы нашли ограничения. Во всех примерах из этого треда гигиена обходилась применением одной единственной функции - либо datum->syntax, либо syntax-local-introduce. И решение было длиннее дефмакровского ровно на применение этой ф-и. Я, право, не считаю применение одной ф-и на сотню строк кода каким-то хоть сколько-нибудь значимым ограничением или усложнением.

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

Как я и говорил - дело привычки.

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

Я просто не знаю где и какие вы нашли ограничения. Во всех примерах из этого треда гигиена обходилась применением одной единственной функции - либо datum->syntax, либо syntax-local-introduce. И решение было длиннее дефмакровского ровно на применение этой ф-и. Я, право, не считаю применение одной ф-и на сотню строк кода каким-то хоть сколько-нибудь значимым ограничением или усложнением.

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

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

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

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

Хотя, возможно, это один из тех случаев, когда сложная проблема требует сложного решения. Я не видел системы метапрограммирования, в которой решались бы проще проблемы, решаемые макросами Racket. Другой вопрос — стоит ли овчинка выделки? И на этот вопрос мне даст ответ только личный опыт.

Ничего не будет. Меня устроит, если c(a|d)+r будут генериться только для того кода, который я глазами вижу в текстовом редакторе внутри with-all-cxrs. Не нужно внутри такого макроса делать дополнительных макроэкспандов, он по дизайну такой.

А если, опять же, у вас некоторый макрос раскрывается в with-all-cxrs? Объявлять баг фичей - это не слишком правильно. Баг он и есть баг. В любом случае, если такие использования макроса некорректны, то в их случае макрос должен давать соответствующую ошибку типа «не могу использоваться внутри макроса» или «идентификатор пришел из макроса» и т.п.

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

Пофиг. Мы тупо делаем flatten для всего кода и рассматриваем сразу все символы. Если пара функций лишних сгенерится — не страшно.

Так этот макрос переопределит нам этот символ, хотя не должен был переопределять.

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

Примеры вида "(flet ((cadadar () nil)) (with-all-cxrs ...))" прошу не приводить, т.к. случай с программистом-дебилом меня не интересует.

Это же _очевидно_, что такой проблемы на практике не возникнет

сказал сишник перед тем как словить сегфаулт :)

В том и проблема что у программиста без гигиены НЕТ НИКАКОГО КОНТРОЛЯ. Дебил он , не дебил - он просто не знает, что в макросе Х происходит одна хуйня (макрос раскрывается в with-all-cxrs), а в макросе Y - другая, в результате чего вместе использовать эти макросы нельзя. Или у вас какой-нибудь макрос with-all-logged, который врапает стоящие в head-позиции идентификаторы кодом логгирования, например, а ваш макрос хуяк - и переопределяет все внутри. А еще вы забываете про такую банальную вещь, что вам макрос могут передать в макрос. И тут вообще начинается полная пизда.

«В динамическом языке наша функция ожидала получить на вход корову, а получает письменный стол. Hur-dur, жопу разорвало».

«В Хаскелле мы всё православно пропихнём через монады, а в Окамле ваша хеш-таблица хуяк — и изменится в самый неподходящий момент».

«Говоря про безопасность на дорогах, вы забываете про такую банальную вещь, что могут разверзнуться хляби небесные и случится армагеддон. Не успеете перейти через дорогу, как раз — и вы уже горите в геене огненной. И тут вообще начинается полная пизда» :-)

Люди совершают ошибки с любым инструментом. Напишите вы хоть на Coq вашу программу, грош будет ей цена в случае грубых ошибок в спецификации. Разные подходы и инструменты предоставляют большое количество способов для совершения ошибок. Только опыт, практический опыт использования при решении конкретных задач может показать конкретному человеку, какие подходы для него работают, а какие — нет; есть или нет в конкретных случаях польза от бондажа и дисциплины. И в первую очередь многое зависит от методологии.

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

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

спасибо, за ссылку, зопейсал, прорешаю все на ракетке.

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

А сами задачи нужно решать на специальных сайтах, позволяющих проверять решения в автоматическом режиме (прогоном невидимых тестов). Racket сейчас ни на одном из таких сайтов не поддерживается (есть только R5RS Scheme на spoj.pl). Впрочем, специфика типичных задач такова, что инструмент большого значения не имеет и даже на всяких Питонах и Руби можно сдавать задачи, если додуматься до алгоритма.

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

Есть замечательное ежегодное соревнование Google Code Jam (http://code.google.com/codejam/), в котором можно использовать вообще любые инструменты (в этом году я использовал OCaml и со скрежетом дошёл до второго тура, что является типичным результатом середнячка-любителя на фоне прочих машин формулы1, среди которых и школьников немало).

Вот пара очень сложных (и очень интересных) задач, каждую из которых я в течение нескольких дней по вечерам решал:

http://code.google.com/codejam/contest/1835486/dashboard#s=p3

http://code.google.com/codejam/contest/1842485/dashboard#s=p3

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

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

А с чего вы взяли что инструмент более сложен? Он проще, вобщем-то.

Первый признак таких «проблемных» для меня подходов — интуитивная непонятность.

Так с какой стати вы решили, что ваши интуитивные представления об одном инструменте имеют что-то общее с совершенно другим инструментом? Естественно, что когда вы пытаетесь использовать новый инструмент, все ваши «интуитивные представления» должны быть забыты. Пока они не будут забыты вы новый инструмент использовать не сможете.

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

Но вы ведь не делали попытки в них разобраться. Вот смотрите - я уже вам прямо заявил, что для того чтобы знать как где обходить гигиену и вообще чтобы понимать что происходит - вам надо узнать как работает в Racket алгоритм гигиены, а точнее - узнать как он влияет на установку биндингов. Вы прочитали эти пол страницы описания? Нет. А между тем алгоритм элементарен, и зная его вы знаете ровно все о поведении гигиены, всех хитрых трансформеров, мелких фич и всего прочего. Вам тогда станет понятно, что те ли иные особенности поведения - это не мелкие фичи, это просто результат того, что алгоритм вот именно такой и не другой. И зная алгоритм вам даже не надо читать доки - вы и так будете знать что там за фичи как они работают и почему. Вы прочитали, что syntax-local-introduce применяет к объекту синтаксическую метку текущего трансформера - и все, вы теперь знаете как что и когда будет перекрываться, в каком и где оно будет контексте и т.п.

«В динамическом языке наша функция ожидала получить на вход корову, а получает письменный стол. Hur-dur, жопу разорвало».

В динамическом языке у нас как раз есть контроль - например, мы можем написать код, который проверит входные данные на корректность и бросит исключение если что-то не так. А речь идет как раз об отсутствии контроля. Представьте, что вы пишите программу для решения квадратного уравнения, и у вас нет возможности сравнить с нулем коэффициент при x^2. Или нет, представьте, что это _для вас_ кто-то пишет такую программу, у него соответствующей возможности нету и в ответ на ваше закономерное недовольство (программа-то глючная выходит), вы в ответ слышите, что «ну просто она писалась не для идиотов, да» :)

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

да, отличная проверка.

А речь идет как раз об отсутствии контроля.

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

К слову, макросы CL могут принимать environment, только это никому не нужно. Доп. биндинги макросов, равно как кондишины или сайд эффекты форм должны быть просто отражены в документации. А полубредовые припарки схемы, которые естественно даже близко не решают указанные проблемы никому не нужны, поэтому схемовскими макросами никто не пользуется. Это из разряда монад и стрелок - тонны говнотеории, тонны говнокода и море ошибок.

схема - тупиковая ветвь развития.

Дебил он , не дебил - он просто не знает

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

в результате чего вместе использовать эти макросы нельзя

складывать строку со списком тоже нельзя, причём тут макросы?

А еще вы забываете про такую банальную вещь, что вам макрос могут передать в макрос

уже десятую страницу всех пугаешь. ну будет макрос внутри макроса и что? макроэкспард CL рекурсивно все раскроет. нет макросов схемы - нет и проблем.

контроля что ли схемовскими обфускационными макросами?

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

ну, это не ошибки, а проблемы неполноценных макросов схемы, ведь семантика всегда полностью на совести автора

Вот именно. Гигиеническая система оставляет семантику на совесть автора - как автор захочет так и будет. А негигиеническое общеговно делает так как оно само захочет.

К слову, макросы CL могут принимать environment, только это никому не нужно.

Это нужно. Просто передача environment'a в CL сделана предельно уебищно. Да и функционала там никакого в этом environment'е.

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

То есть в документации надо всегда перечислять, например, какие анафорические макрос использовались при реализации? Охуенная идея, чо. Очень удобно, когда какой-нибудь макрос тебе вводит it - и не потому, что это надо, а просто потому что макросистема - говно, и иначе нельзя.

поэтому схемовскими макросами никто не пользуется.

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

схема - тупиковая ветвь развития.

Даже если считать это правдой - лучше тупик, чем деградация в стиле CL с контрамортами в качестве авторов стандарта.

макросы меняют семантику

Правильно. Макросы меняют семантику - в соответствии с документацией, в рамках своего функционала.

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

складывать строку со списком тоже нельзя, причём тут макросы?

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

уже десятую страницу всех пугаешь. ну будет макрос внутри макроса и что? макроэкспард CL рекурсивно все раскроет.

И это будет ошибка. Заебись.

хватит уже кормить этого говно(жуя&плюя&еда)

Гигиеническая система оставляет семантику на совесть автора - как автор захочет так и будет. А негигиеническое общеговно делает так как оно само захочет.

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

чем деградация в стиле CL с контрамортами в качестве авторов стандарта

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

Просто передача environment'a в CL сделана предельно уебищно. Да и функционала там никакого в этом environment'е.

тоже самое что в схеме.

Чем эта мемаматематика отличается от обычной беседы математиков на философские темы в LSD-трипе, тоже сходу не поймешь.

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

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

или вот метаматематический результат:

Оказалось, что существует непротиворечивая модель анализа, в которой бесконечно малые — корректно определённые числа, и с ними можно производить арифметические действия в духе Лейбница, без привлечения понятия предела. Тем самым была решена старая проблема: почему математики XVIII века, выполняя незаконные с точки зрения классической теории действия, тем не менее получали верные результаты.

И поэтому, в частности, математика выступает предметом ее (лингвистики) изучения.

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

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

Э-ка тебя батхертом распи$#сило :D

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

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

И поэтому, в частности, математика выступает предметом ее (лингвистики) изучения.

математику было бы весьма полезно поизучать почти-гуманитарно-лингвистически (т.е. грубо говоря, в аспекте понимания формул/формулировок человеком)

Безграмотность так и прет, не позорься - сходи просветись, чем лингвистика занимается.

но к метаматематике это никакого отношения не имеет

Что *это*, придурок? Объясняю просто - для дебилов: лингвистика изучает языки - математика это язык (набор языков, набор DSL).

на самом деле, конечно, оно может иметь отношение, но не на уровне разговора с тобой

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

математика это язык (набор языков, набор DSL)

Как с этим коррелирует то, что большая часть математики - это алгоритмы?

Может ты еще точно в процентах скажешь?

74.0300236517643716376%. Считай это сообщение пруфом.

логика - формальная, булева, жегалкина

Жж0ш.

Как с этим коррелирует то, что большая часть математики - это алгоритмы?

man определение «алгоритма», алгоритм - это описание порядка... блаблабла. Алгоритм - это описание.

Толку-то с такого определения.

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

По сути, чем отличается создание алгоритма решения квадратного уравнения от решения задачи создания динамита (не конкретной шашки, а технологии, которая позволяет делать динамитные шашки миллионами)? И там и там есть исходные данные в виде знаний, и там и там в качестве результата получаем алгоритм.

P.S. А что насчёт интегрального исчисления и решения Кеплером задачи измерения объёма «винной бочки» по её формальным параметрам (высоте, диаметру и т.п.), без применения физического эксперимента? Разве это не решение самой насущной естественной проблемы с помощью математики?

Описание порядка чего-то. Алгоритм - это формальная запись

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

Суть не в значках, суть в том, что значки обозначают.

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

Разве это не решение самой насущной естественной проблемы с помощью математики?

Все науки *используют* логику (какую-нибудь из них) и математику (мат.аппарат - какой-нибудь из них). Но ни математика, ни логика науками не являются.

Толку-то с такого определения.

Приведи Ъ-определение, несводимое к данному.

Жж0ш.

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

Описание порядка чего-то.

Порядка действий, событий, процессов. Алгоритм - по сути ОБС о том, как правильно варить борщ. Можем выразить борщ в математической нотации, а хочешь - через кузькину мать и улюлюканья. Рецепт борща = алгоритм по его приготовлению. Математики (которую ты подразумеваешь) там не видать.

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

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

Математики (которую ты подразумеваешь) там не видать.

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

Второе, если ты утверждаешь, что такая «наука» не наука вовсе, то чем она принципиально отличается от химии, которая так же должна описывать хим. элементы, их взаимодействия и давать понимание, как синтезировать новые хим. элементы?

Э-ка тебя батхертом распи$#сило

бугага!

картина маслом: alienclaster в комменте, полном эмоциональных слов и безуспешных, но отчаянных попыток эмоционально задеть www_linux_org_ru, убеждает окружающих, что баттхерт не у alienclaster-а, а именно у аккуратно выражающегося www_linux_org_ru :-)

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

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

что общепринято называется логической системой четко описано в википедии: A logical system or, for short, logic, is a formal system together with a form of semantics, usually in the form of model-theoretic interpretation, which assigns truth values to sentences of the formal language, that is, formulae that contain no free variables.

теперь твоя очередь — давай ссылку на общепринятое определение «логики жегалкина»

к остальным твоим смехотворным попыткам казаться умным или грамотным мы перейдем позднее — будем растягивать удовльствие :-)

А тебе зачем? Всякое определение/аксиоматика приводится не ради выпендрёжу, а для достижения определённой цели. И я ума не приложу для чего может понадобиться декларация «алгоритм это описание».

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

Че?

Формальная логика, булевская и «логика» Жегалкина - это три названия одной и той же логики. Не с твоим уровнем знаний троллить о математике.

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

математика не подходит под это определение

объективных знаний о действительности.

Вот здесь основная засада. Математика --- это язык:

а) на котором можно описать любые объекты, в том числе не имеющие с нашей дествительностью ничего общего;

б) никаких знаний не вырабатывает. Совсем.

тебе сбора фактов

2 + 2 будет 4? Площадь квадрата будет равна произведению его строн? Произведение a на b будет суммой b чисел a? Что ты скажешь о наблюдении о том, что диагональ квадрата есть число иррациональное? Чем это тебе не изучение «действительности»?

Понимаешь, ты и «с помощью» русского языка познаешь реальность, от этого наукой он не становится, ага.

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

Математика --- это язык

Я с этим не согласен. Соотв. все дальнейшие постулаты могут быть не верны.

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

P.S. В качестве примера подумай, как ты опишешь кучу зерна не имея чисел (задача в том, чтобы измерить её и понять, к примеру, на сколько её хватит, чтобы не сдохнуть с голоду).

С алгеброй Жегалкина мог бы ознакомиться самостоятельно либо в районе 1-го курса любой схемотехнической / математической кафедры.

напомню, ты писал о некой «логике жегалкина»; сейчас выясняется, что ты имел в виду алгебру жегалкина

идем дальше: под «булевой логикой» ты имел в виду булеву логику или же булеву алгебру?

Формальная логика, булевская и «логика» Жегалкина - это три названия одной и той же логики.

Не пори чушь, формальная логика - не обязательно бинарная. У алгебры Жегалкина в базисе только две операции - коньюнкция и xor, «обычной» дизъюнкции нет. Может уже хватит выставлять свою некомпетентность на показ?

Опять забыл про этот тред :-( Надеюсь, анонимный схемщик сюда ещё заглянет.

А с чего вы взяли что инструмент более сложен? Он проще, вобщем-то.

Вы сейчас говорите о том, что _вам_ легко _пользоваться_ этим инструментом :-)

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

Замечу, что никогда не говорил, что «гигиена — сложное говно, ну её нафиг, обойдусь как-нибудь». Я говорил, что это сложная штука, которую я пытаюсь освоить, несмотря на крайне негативные первые впечатления, т.к. есть шанс, что на практике от этого механизма и вправду будет толк (о чём много лет твердят разработчики Racket, которые кажутся вполне адекватными людьми).

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

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

Так с какой стати вы решили, что ваши интуитивные представления об одном инструменте имеют что-то общее с совершенно другим инструментом? Естественно, что когда вы пытаетесь использовать новый инструмент, все ваши «интуитивные представления» должны быть забыты. Пока они не будут забыты вы новый инструмент использовать не сможете.

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

Языки программирования — интерфейс для людей. Они должны по максимуму использовать те «интуитивные представления», которые вы предлагаете выкинуть и без которых предлагаете начать с чистого листа. Потому что язык изменить гораздо проще, чем изменить человека.

Но вы ведь не делали попытки в них разобраться.

Опять домыслы. Конечно, если гигиена кажется кому-то сложной, то это обязательно или лентяй или дебил.

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

Я полностью прочитал и большей частью понял вот это: http://docs.racket-lang.org/reference/syntax-model.html. И мельком просмотрел вот это: http://docs.racket-lang.org/reference/Macros.html.

И всё это, безусловно (говорю про себя, не про вас), сложнее макросов Лиспа, сложнее Форта, сложнее Пролога. Мне крайне сложно мысленно представлять работу этого механизма. С опытом, конечно, станет легче, но я знаю, что сильно легче не станет.

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

«Монады — элементарный механизм, и понимая его вы знаете ровно все о поведении монад, всех хитрых трансформеров, мелких фич и всего прочего. Вам тогда станет понятно, что те ли иные особенности поведения - это не мелкие фичи, это просто результат того, что механизм вот именно такой и не другой. И понимая механизм вам даже не надо читать доки — вы и так будете знать что там за фичи как они работают и почему. Вы прочитали, что Control.Monad.Trans.RWS комбинирует монады ReaderT, WriterT и StateT — и все, вы теперь знаете как что и когда будет лифтиться, биндиться, как будут вести себя монады в сочетании и т.п.» :-)

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

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

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

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

Хочу — динамическую типизацию использую. Не хочу, возникают ошибки — использую статическую.

Хочу — изменяемые состояния. Не хочу — пишу в функциональном стиле.

Хочу — глобальные переменные. Не хочу — не использую.

Хочу — использую goto. Хочу — computed goto.

Хочу defmacro — использую defmacro.

Хочу гигиену — использую гигиену.

Хочу препроцессор — использую препроцессор.

Программа работает — отлично. Не работает — делаю выводы.

В чём проблема вообще? :-)

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

Я писал выше:

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

А весь разговор, напомню, был о том, нужно ли выкидывать на свалку defmacro и полностью переходить на гигиенические системы. Напомню свою позицию — нет, нахрена себе что-то запрещать, если оно помогает решать задачу? Хочу defmacro — использую defmacro. Хочу забить гвоздь молотком — забиваю. Problem?

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

Объясняю просто - для дебилов: лингвистика изучает языки - математика это язык (набор языков, набор DSL).

правильно, для дебилов — ибо только дебилы согласятся, что метаматематика сводится к лингвистике

лингвистика изучает (за очень немногими исключениями) то, каким образом можно строить высказывания (sentences); однако как математика, так и метаматематика рассматривают *дополнительно* к этому model-theoretic interpretation, which assigns truth values to sentences of the formal language

именно model-theoretic interpretation лежит за пределами лингвистики; более того, теорему геделя о неполноте можно трактовать как утверждение о нелингвистичности математики

я это пишу не столько для тебя, сколько для тех, кто будет эту ветку читать — ибо тебе все метаматематические доказательства, включая теорему геделя, кажутся lsd-трипом

короче — лечись, чувак!

2 + 2 будет 4?

В какой системе исчисления? :D Это не факт еще раз, ку-ку

Площадь квадрата будет равна произведению его строн? Произведение a на b будет суммой b чисел a? Что ты скажешь о наблюдении о том, что диагональ квадрата есть число иррациональное? Чем это тебе не изучение «действительности»?

Смешно читать

Похоже ты банально не понимаешь

Дооо, конечно

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

Символы без контекста и определения *нихрена* не значит, это как азбука ацтеков. Т.е. математика - это именно такие символы и закорючки + их семантика.

Идея целых чисел, идея рациональных чисел, идея отрицательных чисел, конплексных, уравнений и т.д.

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

А символы... символы это лишь форма записи

Что в твоей математике есть кроме символов, отражающих неведомые незнакомому с ними абстракции, и логики?

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

Ну, то есть математика - это такой удобный язык (для) описания науки. Мм-окей.

Ну, то есть математика - это такой удобный язык (для) описания науки. Мм-окей.

А языки изучает лингвистика. Значит, лингвистика изучает математику. Типичный ГСМ :)

Знаешь, я бы с удовольствием подискутировал на тему отличий логики от алгебры, но «но не на уровне разговора с тобой» (с) - ты слишком тупой, сори.