Здравствуйте, FR, Вы писали:

FR>Угу еще можно долго вести бессмысленный терминологический спор.

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

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

Здравствуйте, VladD2, Вы писали:

VD>Да, как бы список возражающих то повесомее будет. Да и аргументация есть, а путания в том, что есть/чего нет нету. Так что...

А можно в одном месте собрать всю аргументацию? Если действительно охота по-людски закончить спор.

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

Какие аргументы интересуют:
1. Что имено надо изучать, будь такой отдельный курс: "парадигмы программирования"? Сколько и какого качества дополнительной информации он даст в сравнении с изучением вычислительных моделей?

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

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

4. Методы проектирования теперь следует изучать в рамках парадигм, или же "по-старинке"? Не пострадает ли такая вещь как универсальность и применимость получаемых знаний и навыков?

5. Как быть с классификацией подходов к разработке? Теперь это переименовано в "парадигмы"?


-------------------
Не уверен, что кто-либо сможет четко и правдоподобно ответить даже на эти первые вопросы. Практически везде будут уместны такие вещи как ИМХО, "обычно", "чаще всего", "эмпирически установлено" и т.д.

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

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

"Взгляд на проблему", "видение" — да близко, но немного не то. "Взгляд на проблему" подразумевает бесчисленное множества оттенков серого, типа как раньше свет считали непрерывным волновым излучением. Ан нет, все разбито на вполне конкретные кванты, м/у которыми значения порций энергии существовать не могут. Т.е., не так уж мы вольны в выборе парадигм, ибо как ограничения идут инструменты (автоматизированная поддержка методов и ограничений, составляющих парадигму), наработанные практики (главное достоинство парадигм, ИМХО) и оценочные критерии, по большей части эмпирические, как следствие пред. пункта.



Что я для себя вынес из всей информации, раздобытой и изученной во время обсуждения:

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

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

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

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

— Роль инструментария для формирования "парадигмы"? К инструментарию относятся сами ср-ва выражения (языки) и ср-ва разработки (либо в одном флаконе в случае визуальных редакторов, для визуальных парадигм) + базовые программные платформы, реализующие наиболее встречающиеся сценарии по правилам используемой парадигмы.

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

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


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

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

Здравствуйте, VladD2, Вы писали:


VD>Если в твоем арсенале нет метапрограммирования (с которого и зародился весь спор, ведь Г.В. исходно оспаривал утверждение, что МП — это еще одна парадигма),

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

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

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

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


VD>В качестве же примера лучше взять клонирование или сериализацию объекта. Вот эта задача может быть решена крайне по разному в зависимости от выбора парадигмы. В ООП они будет решена совсем неуклюже. В ФП тоже. КОП даст красивое, но не самое быстрое решение (аналогичное дотнетной сериализации через пометку атрибутом Serializeble). А вот метапрограммирование позволит сделать решение и локоничным, и максимально эффективным.

Да не мета-программирование это. Или же мы должны признать, что построение компиляторов — это тоже метапрограммирование (Ахо с Ульманов перевернулись на другй бок). У тебя есть компилятор в Nemerle, который выполнен как конструктор. Ты программируешь собственный компилятор.

VD>Определившись с подходящей парадигмой можно выбрать и конкретный метод.

Вот что меня смущает. Алгоритм процесса "определения с подходящей парадигмой" существует? Я, например, знаю методы: объектная (она же — системная) декомпозиция, и декомпозиции более низкого уровня (больше ограничений) — функциональные и структурные. Если в какой-то подсистеме будет явно преобладать, например, функциональная декомпозиция, то я могу попробовать использовать функциональную парадигму для ее реализации, т.е. наработанный опыт решения через ФП. Повторюсь: мне по прежнему кажется, что требования в состоянии продиктовать ход решения. А произвольный выбор "способа видения" позволит равновероятно выбрать любой из ошибочных путей.

VD>Например, можно воспользоваться XmlSerializer, а можно встроенной в язык подсистемой метапрограммированния или основанной на ней библиотекой (как, например, в Немерле).

Ты по-сути, встявляешь в компилятор задачи прикладного уровня. При таком подходе тебе в run-time уже практически не нужна метаинформация, потому мне и кажется, что МП — неудачное определение. Ведь в компилятор можно закладывать задачи не только из области доступа к структуре объектов, но и из области алгоритмов и еще бог его знает чего. Т.е. термин DSL-подход мне бы казался более удачным, т.к. более общий. А то тут говорят слишком много об сериализации или ORM (та же сериализация — вид сбоку), типа других задач не бывает...

Здравствуйте, Sinclair, Вы писали:

S>Обрати внимание на термин "интуитивно вычислимая функция".

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

S>Он очевидно субъектно-ориентированный, т.к. никакой "объективной" интуиции не существует. Что, тезис тоже глупостью считать прикажете?

В конце дано определение, которое вполне понятно:

Физический тезис Чёрча—Тьюринга гласит: Любая функция, которая может быть вычислена физическим устройством, может быть вычислена машиной Тьюринга.

Где тут "субъективность"?

И что должна была доказать эта ссылка?

Здравствуйте, VladD2, Вы писали:


VD>2 лекции это такой же перебор как несколько симестров. Общие введение в парадигмы и их перчисление — это действительно пара-тройка занятий. А вот обучение конкретным приемам парадикм могут вестись и дольше. ООП, ФП, МП... все подразумевают изучения конкретных подходов, паттернов, ... и естественно практическое программирование. Ну, а там уже имеет смысл обучать выбирать более подходящие средства решения задач на основе прменения разных образов осмысления задачь.

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

VD>Это и позволит превратить то что есть у едениц благодоря интуиции в четкие начучные принципы.


Угу, количество, само по себе переходящее в качество.

Здравствуйте, last_hardcoder, Вы писали:

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

AVK>>Т.е. предполагается что институт готовит программистов, которые не архитекторы?

_>Я считаю, что институт готовит в основном программистов.

Если взять мою выписку из диплома, то там часов на подготовку меня как программиста — дай бог 5-10% от профилирующих (историю, философию, физкультуру и пр. вычеркиваем, иначе совсем маленький процент получим).

Остальные — подготовка как инженера, т.е. конкструктора программных систем.

_>Но какой-то процент из них впоследствии дорастут до архитекторов.

С 3-го курса их только архитектуре ПО, сетей, БД, БЗ и т.д. и учат... Значит, ты ведешь речь о выпускниках, которые отучились лишь первые 2 курса.

Здравствуйте, AndrewVK, Вы писали:

AVK>Еще одни спор о терминах, бессмысленный и беспощадный.

С терминов начинается любой раздел науки. Прикладной — в первую очередь.

Здравствуйте, vdimas, Вы писали:

AVK>>Еще одни спор о терминах, бессмысленный и беспощадный.

V>С терминов начинается любой раздел науки. Прикладной — в первую очередь.

Ради бога. Только это не умаляет бессмысленности и беспощадности спора о них.

Здравствуйте, vdimas, Вы писали:

V>Что означает этот термин??? Я так и не понял, о чем речь.
Вижу. Плохо. Вот у тебя есть интуитивное понятие о том, что такое "вычислимость"?

V>Хотя, предполагаю, что речь о способности мозга рассуждать логически.
Нет. Речь идет о способности мозга воспринимать чуть более абстрактные понятия, чем "стол" и "стул".
Вот возьмем к примеру термин "температура". Что он обозначает? Абсолютное большинство людей имеют вполне смутные интуитивные представления о том, что это такое, на уровне "горячо-холодно". Тот, кто изучает физику, знает, к примеру, что "температура есть мера средней кинетической энергии". Мы резко сузили понятие температуры. После этого мы можем делать о ней всякие строго доказуемые заключения (ну, к примеру, мы можем сказать, что температуры ниже абсолютного нуля не существует. Это, очевидно, невозможно постулировать для "интуитивной температуры"). Естественно, опираясь на достаточно точное понимание того, что такое кинетическая энергия. При
этом мы не исключаем возможности иметь альтернативные определения термина "температура", но вряд ли они дадут нам что-то принципиально новое. При этом совершенно четко можно различить интуитивное представление о температуре и научное представление о том, что это такое.

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

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

V>Если рассуждения не ошибочны, то их можно воспроизвести с помощью машины Тьюринга, разумеется.
Проблема в том, что никто не знает, что такое "рассуждения". Человек в состоянии воспроизвести машину Тьюринга, или следовать методам формальных доказательств. Однако непонятно, работает ли это в обратную сторону. Лично я уверен в том, что таки да, но удовлетворительного доказательства нет и быть пока не может, ибо методика прямого наблюдения за мышлением не создана.

S>>Он очевидно субъектно-ориентированный, т.к. никакой "объективной" интуиции не существует. Что, тезис тоже глупостью считать прикажете?

V>В конце дано определение, которое вполне понятно:
Ну так это другой тезис!
V>Где тут "субъективность"?
Вот здесь уже нету. Равно как и в тезисе об эквивалентности вычислимости в терминах МТ и вычислимости в терминах общерекурсивных функций.

V>И что должна была доказать эта ссылка?
Что существуют неформализуемые, (пока что неформализованные/слабо формализованные) понятия, которые тем не менее не являются глупостями. Пренебрегать ими как раз и есть глупость.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Только это не умаляет бессмысленности и беспощадности спора о них.

Беспощадность спора — ладно. А вот почему — бессмысленность?

Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Только это не умаляет бессмысленности и беспощадности спора о них.

ГВ>Беспощадность спора — ладно. А вот почему — бессмысленность?

Потому что результат этих споров всегда один и тот же.

Здравствуйте, AndrewVK, Вы писали:

ГВ>>Беспощадность спора — ладно. А вот почему — бессмысленность?
AVK>Потому что результат этих споров всегда один и тот же.

Какой?

Здравствуйте, VladD2, Вы писали:

ГВ>>Ну если это субъективный и неформальный термин, то и дорога ему только в факультативный курс. Тогда возвращаемся на круги своя — нет такой штуки, как "парадигма программирования", если она не определима вне субъекта программирования.

VD>Задача учебного заведения учить людей думать. И парадигма это как раз способ думать, так что все ОК. Ведь учатся субъекты и мыслят тоже они.

Ой, как всё запущено...

Здравствуйте, Sinclair, Вы писали:

S>... в рамках курса "философские основы информатики" представляю себе достаточно хорошо.

Это ещё что такое? Семестр талдыченья ни о чём?

Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Потому что результат этих споров всегда один и тот же.

ГВ>Какой?

Такой же как и в текущем случае — никакой.

Здравствуйте, Трурль, Вы писали:

Т>А вот еще одна трактовка:Robert W. Floyd, The Paradigms of Programming.

ИМХО, приведённая статья есть пример того, как слишком объёмный для осмысления предмет приводит неподготовленного наблюдателя в изменённое состояние сознания. Если вернее — то побуждает подменить совокупность сущностями. Ну, бывает...

Здравствуйте, Sinclair, Вы писали:

V>>И что должна была доказать эта ссылка?
S>Что существуют неформализуемые, (пока что неформализованные/слабо формализованные) понятия, которые тем не менее не являются глупостями. Пренебрегать ими как раз и есть глупость.

А что слабоформализованного в ТЧТ? "Интуитивно вычислимая" легко разворачивается в "которую, кажется, возможно вычислить". Ссылка на роль субъекта здесь очевидна, но ни о каких "способах обеспечения кажимости", "методах кажения" и "классификации показалостей" речи там не идёт.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Потому что результат этих споров всегда один и тот же.
ГВ>>Какой?
AVK>Такой же как и в текущем случае — никакой.

Для кого?

Здравствуйте, Геннадий Васильев, Вы писали:

AVK>>Такой же как и в текущем случае — никакой.

ГВ>Для кого?

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

Здравствуйте, VladD2, Вы писали:

ГВ>>Ну если это субъективный и неформальный термин, то и дорога ему только в факультативный курс. Тогда возвращаемся на круги своя — нет такой штуки, как "парадигма программирования", если она не определима вне субъекта программирования.

VD>Задача учебного заведения учить людей думать. И парадигма это как раз способ думать, так что все ОК. Ведь учатся субъекты и мыслят тоже они.

Э... наиважнейшим среди способов думания стоит полагать способ "не думать о белой обезъяне". Всё прочее — пустота и тлен.