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

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

U>>Паттерн стратегия это еще очень примитивный пример, который имеет достаточно однозначное отражение в коде.

Q>Нет. Паттерн Стратегия выглядит точно так же (вплоть до UML-диаграммы), как и паттерн Состояние. И тем не менее, это разные паттерны.

Вообще-то нет. "Состояние" обычно имеет ссылку на объект, который обладает этим состоянием, а стратегия — нет.

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

К>>>Ну и утверждается, что мат. нотация всем неродная целиком, так?
LVV>>1. Есть конкретный опыт конкретных учителей.
G>Сколько? Один? Два? Десять? А они уверены что с другим языком было бы по-другому?
Сравнивали.
LVV>>2. Есть наш опыт обучения первокурсников
G>См выше.
Сравнивали
LVV>>3. Для начинающих математическая нотация — не родная. Даже факториал — многие ли знают определение?
G>Что за глупости? У нас в универе матан, дискретная математика и алгебра с геометрией были с самых первых занятий. А вот нотация паскаля была как раз "неродной" для многих.
Ну вот. Вы сами говорите, что паскаль — не родной. А русский — родной. Было б проще писать почти русский текст: пока a > 10 делать ... конец пока;

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

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

К>>>>Ну и утверждается, что мат. нотация всем неродная целиком, так?
LVV>>>1. Есть конкретный опыт конкретных учителей.
G>>Сколько? Один? Два? Десять? А они уверены что с другим языком было бы по-другому?
LVV>Сравнивали.
LVV>>>2. Есть наш опыт обучения первокурсников
G>>См выше.
LVV>Сравнивали

А количество?

LVV>>>3. Для начинающих математическая нотация — не родная. Даже факториал — многие ли знают определение?
G>>Что за глупости? У нас в универе матан, дискретная математика и алгебра с геометрией были с самых первых занятий. А вот нотация паскаля была как раз "неродной" для многих.
LVV>Ну вот. Вы сами говорите, что паскаль — не родной. А русский — родной. Было б проще писать почти русский текст: пока a > 10 делать ... конец пока;
ыыыыы... человеческий язык неформален. Многое в общении передается не только словами, но и паузами интонацией итд. Все равно на основе естественного языка будет разработана некоторая формальная нотация, которая будет формальная и её все равно надо учить. pascal — хороший пример, в нем пытались сделать нотацию близкой к естественному языку, но соотношение сигнала\шума получилось ниже чем у языков, в которых используются значки для управляющих конструкций, а не слова, это при одинаковом уровне понятности.

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

AC>Думаю собственно синтаксис это вторично(хотя несомненно важно), главное в ЯП это "модель программирования"

Думаю, что это те две вещи, которые стоят на первом месте.
Да и писать приходится реже чем читать и править. Иногда случается, что за неделю вообще ни одной строчки не напишешь, не смотря на упорную работу с иходниками. Читабельность синтаксиса не просто важная штука, а СУПЕР важная штука.

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

К>>>>>Ну и утверждается, что мат. нотация всем неродная целиком, так?
LVV>>>>1. Есть конкретный опыт конкретных учителей.
G>>>Сколько? Один? Два? Десять? А они уверены что с другим языком было бы по-другому?
LVV>>Сравнивали.
LVV>>>>2. Есть наш опыт обучения первокурсников
G>>>См выше.
LVV>>Сравнивали
G>А количество?
Группа — 30 человек.
LVV>>>>3. Для начинающих математическая нотация — не родная. Даже факториал — многие ли знают определение?
G>>>Что за глупости? У нас в универе матан, дискретная математика и алгебра с геометрией были с самых первых занятий. А вот нотация паскаля была как раз "неродной" для многих.
LVV>>Ну вот. Вы сами говорите, что паскаль — не родной. А русский — родной. Было б проще писать почти русский текст: пока a > 10 делать ... конец пока;
G>ыыыыы... человеческий язык неформален. Многое в общении передается не только словами, но и паузами интонацией итд. Все равно на основе естественного языка будет разработана некоторая формальная нотация, которая будет формальная и её все равно надо учить. pascal — хороший пример, в нем пытались сделать нотацию близкой к естественному языку, но соотношение сигнала\шума получилось ниже чем у языков, в которых используются значки для управляющих конструкций, а не слова, это при одинаковом уровне понятности.
1. пока a > 10 делать ... конец пока; — это учить не надо. Это читается и понятно без специальной учебы. Причем, даже третьекласснику.
2. Не приведете линки на исследования по "соотношение сигнала\шума"?. Многолетний и многообразный опыт программирования на разных языках и у разных людей показывает: то, что начинающему хорошо, опытному — плохо. Для этого достаточно посмотреть на пару: паскаль-С. Кто создавал и с какой целью — и сразу видать, что для профи, а что — для начинающего. Дык для начинающего нужно еще добавить родной язык — ему легче будет осваивать алгоритмизацию (что является основным камнем преткновения — а вовсе не лексика языка).

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

U>Что в этом описании математического? Что нам даст то, что мы начнем считать, что это описание является математическим?

Нет никаких проблем с формализацией

M>>Где здесь могут быть сложности с формализацией???

U>Что делать при невозможности прочитать файл? Что делать при отсутствии директории заданной в ini-файле? Что делать при отсутствии места на диске?

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


M>>>>Хорошее ТЗ тоже представляет собой формальное описание задачи.
U>И таких ТЗ в реальности никто не видел, т.к. написание такого ТЗ будет более трудозатратно, чем решение задачи.

Ты путаешь полноту с формальностью.

U>

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

U>Если математический подход более общий, то когда я завел речь о тестировании тебя как математика должно было интересовать подход покрывающий тестирование любой задачи. Вместо этого ты приводишь подход, который возможно применить только в самых примитивных случаях и невозможно в общем случае. А в общем случае тестирование сводится к подстановке набора входных параметров и сравнение эталонного значения с значением на выходе. Соответственно о поведении системы при произвольном значении входных параметров тесты ничего сказать не могут, т.к. эталона для этого случая нет.

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

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

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

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

U>И как на языке математики записывается, к примеру, интерфейс?
Несколько вариантов.
Традиционно, минимальный матаппарат в любом программировании — это описание грамматики языка.
Если интересно поговорить о семантике интерфейса, то читайте http://www.jot.fm/contents.html?query=theory+of+classification. Где там конкретно про интерфейс, я сходу не скажу, но теория построена довольно-таки полная. В какой-то из глав, посвящённых наследованию должно быть.

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

U>Вот мы разрабатываем пользовательский интерфейс приложения. Где мы здесь используем математику?
Вообще-то — много где. Например, у нас есть статистические данные про то, какие сценарии пользователи используют чаще, какие — реже.
Например, при проектировании интерфейса мы используем математику конечных автоматов для описания поведения UI.

U>Вот мы думаем какая структура данных хорошо подходит для решения задачи. Где мы здесь используем математику?
А тут мы вообще ничего, кроме математики, не используем. У Кнута, к примеру, очень подробно расписан матаппарат, который позволяет получить оценки производительности для тех или иных алгоритмов. А применимость алгоритмов напрямую зависит от использованных структур данных. А вы, простите, как-то по-другому что ли это делаете?

U>Для того, чтобы найти решение нужно думать. Математика может лишь предоставить ряд приемов, которые в некоторых случаях упрощают процесс мышления, но сам процесс мышления и соответственно поиска решения много сложнее, чем математика.

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

Просто та математика, которую преподают на первых двух курсах, выглядит какой-то отдалённой от практики из-за отсутствия внятных объяснений этого перехода. Ну, к примеру, все понимают, что Быстрое Преобразование Фурье построено на алгебре полей Галуа. А вот на чём построена модель наследования в C++, понимают не все — потому что нет такого курса "математические основы ООП". Это не значит, что нет математических основ ООП.

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

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

К>>>>>>Ну и утверждается, что мат. нотация всем неродная целиком, так?
LVV>>>>>1. Есть конкретный опыт конкретных учителей.
G>>>>Сколько? Один? Два? Десять? А они уверены что с другим языком было бы по-другому?
LVV>>>Сравнивали.
LVV>>>>>2. Есть наш опыт обучения первокурсников
G>>>>См выше.
LVV>>>Сравнивали
G>>А количество?
LVV>Группа — 30 человек.
То есть преподаватель один? Выборка нерепрезентативна.

LVV>1. пока a > 10 делать ... конец пока; — это учить не надо. Это читается и понятно без специальной учебы. Причем, даже третьекласснику.

Читаться может и читается, но не понимается смысла этого. В этом и разница естественного языка и формальной нотации.

LVV>2. Не приведете линки на исследования по "соотношение сигнала\шума"?
Я их не собираю, но можно провести простой эксперимент реализовав на pascal и c примерно одинковый функционал посчитать количество символов. В pascal будет больше за счет begin\end, procedure\function и array of.

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

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

LVV>>>>Сравнивали
G>>>А количество?
LVV>>Группа — 30 человек.
G>То есть преподаватель один? Выборка нерепрезентативна.
F мы и не собирались Заниматься наукой, а стремились получить опыт.
LVV>>1. пока a > 10 делать ... конец пока; — это учить не надо. Это читается и понятно без специальной учебы. Причем, даже третьекласснику.
G>Читаться может и читается, но не понимается смысла этого. В этом и разница естественного языка и формальной нотации.
Еще как понимается — см. выше "опыт"...
LVV>>2. Не приведете линки на исследования по "соотношение сигнала\шума"?
G>Я их не собираю, но можно провести простой эксперимент реализовав на pascal и c примерно одинковый функционал посчитать количество символов. В pascal будет больше за счет begin\end, procedure\function и array of.
То есть исследований тоже нет...
LVV>>Многолетний и многообразный опыт программирования на разных языках и у разных людей показывает: то, что начинающему хорошо, опытному — плохо. Для этого достаточно посмотреть на пару: паскаль-С. Кто создавал и с какой целью — и сразу видать, что для профи, а что — для начинающего. Дык для начинающего нужно еще добавить родной язык — ему легче будет осваивать алгоритмизацию (что является основным камнем преткновения — а вовсе не лексика языка).
G>А в чем тогда смысл обучения начинающих таким образом чтобы их знания стали "плохими" когда они дорастут до профи?
G>Уж лучше "тяжело в учении, легко в бою", чем наоборот. Только уровень абстракции надо подбирать так чтобы обучающиеся занимались написанием программ, а не борьбой с менеджерами памяти и особенностями ОС.
Вы забываете, что не язык является целью обучения, а программирование. Язык только инструмент обучения. Летчиков учат на кукурузнике, а летают они на совсем других самолетах. Водители новички и водители профи — ездят на разных машинах. Музыканты-новички и музыканты-профи byhf.n на разных инструментах. Спортсмены-новички и спортсмены-профи — просто в разных кроссовках бегают, не говоря уже о всяком другом инвентаре (например, стрелки или велосипедисты).
Так что инструменты для обучения и инструменты для профессиональной деятельности во всех сферах деятельности — РАЗНЫЕ!

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

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

Т.е. для тестирования черного ящика математика совершенно бесполезна.

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

U>>И таких ТЗ в реальности никто не видел, т.к. написание такого ТЗ будет более трудозатратно, чем решение задачи.
M>Ты путаешь полноту с формальностью.

Проблемы и с полнотой, и с формальностью. Требование — интерфейс программы должен быть удобным для пользователя. Где здесь формальность?

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

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

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

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

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

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

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

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

U>>Вот мы разрабатываем пользовательский интерфейс приложения. Где мы здесь используем математику?
S>Вообще-то — много где. Например, у нас есть статистические данные про то, какие сценарии пользователи используют чаще, какие — реже.
S>Например, при проектировании интерфейса мы используем математику конечных автоматов для описания поведения UI.

Я и не отрицаю, что математика как инструмент полезна в очень многих задачах программирования. Но в многих не значит во всех. Математика это один из инструментов, а не само программирование.

S>А тут мы вообще ничего, кроме математики, не используем. А вы, простите, как-то по-другому что ли это делаете?

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

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

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

S>У вас, мне кажется, какое-то неверное понимание того, что такое математика. Весь "ряд приёмов", предоставляемый математикой — это формализация. Как только вы что-то формализовали и построили абстрактную модель — вы получили математику.

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

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

S>У вас, мне кажется, какое-то неверное понимание того, что такое математика. Весь "ряд приёмов", предоставляемый математикой — это формализация. Как только вы что-то формализовали и построили абстрактную модель — вы получили математику.

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

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

U>Т.е. для тестирования черного ящика математика совершенно бесполезна.

Нет, это означает, что любое тестирование не может гарантировать корректность работы.

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

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

U>>>И таких ТЗ в реальности никто не видел, т.к. написание такого ТЗ будет более трудозатратно, чем решение задачи.
M>>Ты путаешь полноту с формальностью.

U>Проблемы и с полнотой, и с формальностью. Требование — интерфейс программы должен быть удобным для пользователя. Где здесь формальность?
Это пример неформального определения, но я его в ТЗ не встречал Варианты: удобство интерфейса на усмотрение разработчика.

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

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

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

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

Откуда это следует?

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

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

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

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

Ничего не понял, что такое математическая суть? Как узнать, суть математическая или нет?

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

U>Это вы откуда такое определение стратегии взяли и какая от него польза при написании программ?

U>Под паттерном стратегия я понимал это: http://ru.wikipedia.org/wiki/Стратегия_(шаблон_проектирования) И вот такая стратегия мне нужна, т.к. позволяет решать реальные задачи гораздо проще, а то что вы называете стратегией мне даром не надо.

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

Ставить программирование и паттерны GoF в один ряд нельзя. Это всего лишь описания некоторых типовых решений в неком множестве языков программирования. В первую очередь они призваны объяснить: с какой целью код был написан именно так.

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

Z>Паттерны были придуманы для того, чтобы программисты могли объяснять свои решения.

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

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

S>Традиционно, минимальный матаппарат в любом программировании — это описание грамматики языка.

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

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

Z>>Паттерны были придуманы для того, чтобы программисты могли объяснять свои решения.

U>Паттерн бридж позволяет заменить умножение числа вариантов на сложение числа вариантов. Ты серьезно считаешь, что это ерунда, нужная лишь для того, чтобы "программисты могли объяснять свои решения"?

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

Ты серьезно считаешь, что банда четырех что-то изобрела? Они сделали классификацию часто применяемых приемов программирования на некоторых языках. Множество паттернов я лично применял до прочтения этой книжки. Не все и не совсем в каноническом виде. Бридж/прокси/адаптер применял точно.