Обсуждение

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

Я думал о термине "транслятор" (и даже "переводчик"), но намеренно не употребил его. Отнюдь не все понимают транслятор как обобщение интерпретатора и компилятора. "Нас", например, учили не так, как "вас" ;)

"Диван был транслятором. Он создавал вокруг себя поле, преобразующее, говоря просто, реальность действительную в реальность сказочную." (с) Аркадий и Борис Стругацкие. "Понедельник начинается в субботу"

Я пишу программы с 1975 года, когда слова "компилятор" еще не было, а "транслятор" уже было... ;)

начал писать комментарий, получился не очень складный но большой текст. вынес в http://matfuck.livejournal.com/602.html

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

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

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

Обобщу тезисно свой опыт моделирования, применительно к задачам тестирования: 1. Понятно, что тесты писать рукам лень, надо их генерировать. Ибо если их тупо писать руками, то получается огромная масса кода (на порядок больше нежели тестируемый код), которую на порядок труднее сопровождать. 2. Следовательно нужны модели - т.е. какие-то компактные и понятные человеку (пусть и не всякому) описания, из которых можно генерить тесты. Ну и при изменениях обстановки, подправить модель и перегенерить всю массу тестов. 3. Генерить тесты из модели большой проблемы не составляет, есть куча тулзов и подходов, нетрудно самому генерировать. Проблема состоит в задании моделей. Еще есть проблема с прогоном этих тестов и донесением результатов до остальных - но будем считать, что это мелочи (грубо говоря, цели тестирования достигнуты, а это уже проблемы другого рода). 4. Одна из основных проблем при моделировании - императивность современных Си-подобных языков. Императивные модели - это полная жопа. Модели должны быть декларативными, иначе ими невозможно манипулировать/преобразовывать из-за наличия сайд-эффектов. Программист относительно легко учитывает последствия сайд-эффектов (не всегда корректно правда :)), компьютер пока их учитывает с трудом. 5. Лучше всего если модели не просто декларативные, а логические - т.е. вычисления идут в две стороны: и по параметрам вычисляем результат, и по результатам вычисляем параметры. Еще лучше, если модели задаются в ограничениях - это, по видимому, наиболее естественные для человека способ задания моделей. Ибо ограничения аддитивны. 6. Другая проблема моделирования - перво-порядковость. Если "язык" моделирования основывается на перво-порядковой концепции, то реализация очень сильно упрощается, следовательно, это должно быть желательное свойство таких моделей. К сожалению, это сильно затруднят жизнь программерам. Поэтому, практичные языки моделирования по большей части высокопорядковые. Иначе замучаешься работать. Ученого в борьбе за истину это конечно не остановит. Но инженер рано или поздно задолбается, и начнет вводить высокпорядковость так или иначе, путем генерации моделей и прочей меты-. 7. Вылезает другая проблема: у высокопорядковых языков имеются серьезные проблемы с реализацией/анализом. Частично они решаются путем устранения высокопорядковости, но это возможно не всегда. 8. В тестировании, вообще говоря, полный анализ, не нужен, достаточно протестировать просто очень много "разумных" случаев. Так что тут можно реализовать компромисс. Т.е. иметь с одной стороны высоко-порядковые описания, а с другой методы их анализа/перебора на определенную глубину, которые будут давать покрытие в районе 95-99%. За счет хитрых эвристик, можно исключать эквивалентные тестовые случаи, и сильно облегчать перебор таким образом. Теоретически, набор таких эвристик велик. На практике, они разрозненны и их нужно свести в единую систему (в данном случае, систему тестирования). Тут промышленно-применимых систем пока мало, но какие-то есть (взять тот же Coq).

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

Ну, я пишу сейчас много про непрограммистские модели. В современных САПР к ним сейчас приписываются некие "правила" (например, "два бензинопровода не могут быть ближе друг ко другу, чем на расстоянии 1м") и эти правила обычно даются во вполне логическом языке.

Да, конечно. Я вот смотрю презентации, и виду там примерно те же проблемы :). Только это не совсем корректно называть непрограммисткие модели. Ибо работа с ним все равно программирование, как ни крути. Просто это неимперативное программирование, декларативное.

Работа с ними -- это и не программирование, и не моделирование. Люди называют это "проектирование" и "конструирование" ;)

Это видимо от бэкграунда зависит :). Я как программер, работаю с ними используя программерские навыки :). Тем не менее, действительно, такие модели допускают работу с ними не только программерскими методами, но и более понятными простым смертным. Что вроде как и есть цель :). Но я довольно скептично отношусь к перспективам. Скажем, показывать эти модели непрограммистам можно, может они их даже создавать могут, или там ревьюить. Но как только начинается генерация и интеграция, тут уже начинается суровое программерство :). Ибо компьютер не так умен как хотелось бы. А значит модели надо делать исполнимыми. Точнее скептически не совсем точное слово. Скажем, у работы с моделями непрограммерскими методами есть ограничения :). Жызнь, как говорится, искусство возможного.

там в тексте что-то сказано про "суперкомпиляцию". непонимаю до конца что это такое. но вроде с её применением само понятие "тестирования" потеряет смысл. и это хорошо и правильно. в идеале должно быть так что программу не нужно тыкать туда-сюда чтоб убедиться что она шевелится как надо. будет возможен какой-то почти доказательный уровень надёжности на всем множестве возможных входных данных. а языки типа си, я считаю скоро уже уйдут в прошлое (не решусь срок определить, гдето через 200 лет точно:)). кстати к вопросу про уровни и проблеммы "тестирования". такой пример. sql. это же более высокий уровень, в сравнении если писать алгоритмы конкретных выборок-переборов на том же си. но если эта машина бд доказательно проработана на всех внутренних уровнях реляционных алгебр и пр. то это будет несопоставимо надёжней подход чем самодельная сишная программка.

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

Тут правильно говорить, что модели должны быть "исполнимыми в некотором особом смысле" -- и этот смысл необязательно "императивное исполнение". Это вполне традиционный разговор людей, долго занимающихся изготовлением разных мета-программ (типа компиляторов, интерпретаторов, оптимизаторов, компиляторов компиляторов и т.д.). Я бы еще заметил, что по факту модельеры данных любят заметить, что они из айтишников уже вышли, а вот в предметные эксперты еще не вошли, а "болтаются где-то посередине". Мне кажется, что это то самое место, где искусство программирования становится общим искусством описания (а описания -- планами будущего, т.е. проектами). Так что я бы не заморачивался терминологией, а сосредоточился на сути: а суть одна и та же -- составление описаний (являющихся планами/проектами), "исполнимых в некотором смысле".

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

Насколько я понимаю текущий тренд, то в language workbenches принято следующее разделение: формулирование проблем "компиляции" из одного языка в другой -- это программистская работа. А вот формулирование проблем предметной области "из жизни" -- это работа уже непрограммистская. Тем самым "программирование" определяется как предмет преобразования описаний и обеспечения их "исполняемости" (т.е. написание компилятора или редактора -- это программирование, а написание "программы" вычисления какой-нибудь особо кривой системы дифуров -- не программирование, и не работа программиста, независимо от используемого языка, будь он Fortran или Modelica).

У меня основная линия для флейма здесь в категорическом неприятии предлагаемого подхода к "языкам" (применительно к основной предметной области, состоящей из "программирования" и "организации производства", ну и немного с переходом к человеческим языкам "пользователей"). Суть моего отношения в том, что в языке бешенно сложные вещи происходят, на то он и язык. И простым подходом сопоставления синтаксических закономерностей и предположением, что они как-то коррелируют с глубинной синтаксической шайтан-машиной никуда не попасть. Чтоб уточнить своё понимание. У меня оно очень близко к Витгенштейну. Тут небольшой текстик с основными идеями http://matfuck.livejournal.com/1786.html