Здравствуйте, BulatZiganshin, Вы писали:
BZ>поскольку каждый архитектор должен построить дом, подписать письмо четырёх и решить задачу К, я тоже не выдержал. см. http://www.haskell.org/haskellwiki/Ru/Problem_K
Здравствуйте, BulatZiganshin, Вы писали:
BZ>поскольку каждый архитектор должен построить дом, подписать письмо четырёх и решить задачу К, я тоже не выдержал. см. http://www.haskell.org/haskellwiki/Ru/Problem_K
А в каком месте кода зарыто вычисление выражения согласно приоритетам операций +,-,*,/ ?
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>поскольку каждый архитектор должен построить дом, подписать письмо четырёх и решить задачу К, я тоже не выдержал. см. http://www.haskell.org/haskellwiki/Ru/Problem_K
NGG>А в каком месте кода зарыто вычисление выражения согласно приоритетам операций +,-,*,/ ?
согласно поставноке приоритеты всех операций одинаковы, в частности обрати внимание на вычисление ячейки A2 в примере. если бы постановка была с приоритетамим, я бы разбил строку с выражением сначала на группы по младшим операциям, затем по старшим внутри каждой группы
Здравствуйте, BulatZiganshin, Вы писали:
BZ>поскольку каждый архитектор должен построить дом, подписать письмо четырёх и решить задачу К, я тоже не выдержал. см. http://www.haskell.org/haskellwiki/Ru/Problem_K
Ну что, дружище, чисто как архитектор архитектору, а также как автор задачи К, предназначенной для отбора Людей К, прокомментирую тебе твое решение.
1) Во вводной части жжошь. Еще пиши.
2) Хорошо что ты расшырил тестовий кейс. Предполагалось, правда, что при решении автор должен разработать набор тестов, дабы показать, как он то умеет делать, ну да ладно, мы, Люди К, слишком ленивы, чтобы делать тупую работу.
3) В целом, ты почти все технические грабли обошел. Остались уже нюансы для Людей К с чорным поясом. Проверь на своей программе вот такой пример:
'Text 25
=a1 =a2 =a1+a3
где клетка а1 — пуста. Что выведет твоя программа, и что, по твоему, она должна вывести (внимательно проанализируй ТЗ).
4) Где в твоем решении дизайн, мать его? Или на Хаскеле так и надо писать большие программы — вот будешь ты, допустим, писать взрослый excel с объемным ТЗ — ты тоже все в один модуль свалишь, и сделаешь все на функциях и вариантах?
Здравствуйте, Gaperton, Вы писали:
G>3) В целом, ты почти все технические грабли обошел. Остались уже нюансы для Людей К с чорным поясом. Проверь на своей программе вот такой пример: G> 'Text 25 G>=a1 =a2 =a1+a3
G>где клетка а1 — пуста. Что выведет твоя программа, и что, по твоему, она должна вывести (внимательно проанализируй ТЗ).
во-первых, ТЗ несколько неудобно с точки зрения тестирования, обмена тесатми и т.д. я изменил его — ячейки разделяются любым кол-вом пробелов/табуляций, а пустая ячейка записывается как "". вот рез-т:
Text 25 ""
#EVAL #EVAL #EVAL
всё верно, хотя сообщения об ошибке и маловразумительны. вообще, я не забыл ввести отдельные типы для ошибок/пустых ячеек/строк и сделал универсальную систему отлова ошибок — по исключениям
G>4) Где в твоем решении дизайн, мать его? Или на Хаскеле так и надо писать большие программы — вот будешь ты, допустим, писать взрослый excel с объемным ТЗ — ты тоже все в один модуль свалишь, и сделаешь все на функциях и вариантах?
во-первых, дизайн != разделению на отдельные файлы модули в моей программе обозначены либо секциями (библиотека, типы данных), либо глобальными функциями. далее, задача сформулирована в чисто функциональном стиле — это некое преобразование данных, и архитектура её решения в функциональном стиле — это декомпозиция сложного преобразования на более прочтые, используя стандартные комбинаторы типа (.) и map
мне имхается, что разобраться в устройстве программы несложно, а это и есть признак хорошего дизайна (а не следование каким-то стандартам, тем более выработанным для других стилей программирования). т.е. если читателю понятно каждое отдельное преобразование и понятно, как их комбинация позволяет получить требуемый результат — значит, цель достигнута
и собственно, я замахнулся на публикацию в вики именно потому, что посчитал это наглядной демонстарцией использования именно функционального подхода к решению задач — даже тех, которые большинство программитсов считает чисто императивными (отслеживание цикличных ссылок). кстати, опять же моё решение этой проблемы лучше в том плане, что оно не слито с другими модулями — вычисление значения выражения, как у thesz/geniepro, или возврата значения ячейки, как у тебя
множество простых, независимых друг от друга модулей, каждый из которых решает простую, ясно очерченную задачу — это и есть хороший дизайн
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Gaperton, Вы писали:
G>>3) В целом, ты почти все технические грабли обошел. Остались уже нюансы для Людей К с чорным поясом. Проверь на своей программе вот такой пример: G>> 'Text 25 G>>=a1 =a2 =a1+a3
G>>где клетка а1 — пуста. Что выведет твоя программа, и что, по твоему, она должна вывести (внимательно проанализируй ТЗ).
BZ>во-первых, ТЗ несколько неудобно с точки зрения тестирования, обмена тесатми и т.д. я изменил его — ячейки разделяются любым кол-вом пробелов/табуляций, а пустая ячейка записывается как "". вот рез-т:
Стоп.
1) Пустая ячейка должна записываться как пустая ячейка, то есть две табуляции подряд. Твоя программа это обрабатывает? Если нет (уверен что нет) — это ошибка в трактовке ТЗ.
2) В ТЗ не сказано, что пробел может являться разделителем ячеек. Там сказано, что разделителем является табуляция. Одна. Ты расширил ТЗ, что привело к неверной трактовке пустой ячейки.
Ай-ай. Если ты читал комменты к задаче в блоге Зефирова, там акцентруется внимание на то, что задача проверяет умение работать с ТЗ. Это трактуется как ошибка. Нефатальная, впрочем.
BZ>Text 25 "" BZ>#EVAL #EVAL #EVAL
BZ>всё верно, хотя сообщения об ошибке и маловразумительны. вообще, я не забыл ввести отдельные типы для ошибок/пустых ячеек/строк и сделал универсальную систему отлова ошибок — по исключениям
Это я заметил, это перечисленное у тебя сделано грамотно. Я этот тест тебе дал по другой причине. Правильный результат такого теста —
"tab Text tab 25" либо "tab Text tab #EVAL"
Почему так. Операции над строками запрещены, это верно. Однако в выражении =a2 нет никаких операций.
Что касается выражения =а1 — здесь нет ни строк, ни операций. Почему error? Обоснуй.
Третий пункт — неполнота ТЗ. В ТЗ не указано, как трактовать пустую ячейку. Предполагается, что на это человек должен обратить на неполноту внимание (либо описать этот case в сопроводиловке, что он трактует эту операцию как ошибку, либо, что гораздо интереснее, приводить пустую ячейку к 0 при арифметических операциях, как это делает взрослый excel).
В принципе, при отборе Людей К это ошибками не считали — просто обращали внимание на это при беседе, и спрашивали, как человек будет учитывать этот факт в своей программе.
G>>4) Где в твоем решении дизайн, мать его? Или на Хаскеле так и надо писать большие программы — вот будешь ты, допустим, писать взрослый excel с объемным ТЗ — ты тоже все в один модуль свалишь, и сделаешь все на функциях и вариантах?
BZ>во-первых, дизайн != разделению на отдельные файлы модули в моей программе обозначены либо секциями (библиотека, типы данных), либо глобальными функциями. далее, задача сформулирована в чисто функциональном стиле — это некое преобразование данных, и архитектура её решения в функциональном стиле — это декомпозиция сложного преобразования на более прочтые, используя стандартные комбинаторы типа (.) и map
Не разделению на файлы, а на модули и ADT. Модуль != файл. У модуля интерфейс есть. Дизайн — это составные блоки систем с четко прописанными функциями и интерфейсами. Просто представь, что объем функциональности разросся раз в 10, и покажи явно, как ты разделишь код на модули и какие будут интерфейсы, с объяснением простым человеческим языкм, почему сделал именно так — и все. Представь, что тебе надо ТЗ на эти модули выдавать разным разработчикам, а потом стыковать результат. Какой информацией ты их снабдишь? Не будешь же ты в один модуль все сваливать на большой задаче — так?
BZ>мне имхается, что разобраться в устройстве программы несложно, а это и есть признак хорошего дизайна (а не следование каким-то стандартам, тем более выработанным для других стилей программирования). т.е. если читателю понятно каждое отдельное преобразование и понятно, как их комбинация позволяет получить требуемый результат — значит, цель достигнута
+1, ты прав. Только у хорошего дизайна есть еще свойства помимо этого — независимые от языков и парадигм.
2) Для понимания одной составной части программы ("модуля", "компонента", класса, whatever) не должно требоваться понимать весь дизайн (требуется минимум знаний об остальной системе). Сформулировав решение таким образом, ты эффективно борешься со сложностью проблемы, декомпозировав ее на набор оносительно независимых мелких проблем, которые ты можешь поручить разным людям/командам, откуда следует пункт...
3) Хороший дизайн приводит к плану разработки с набором относительно независимых задач, который хорошо параллелится. И...
4) Цена внесения изменений в хороший дизайн низка (следствие п 2) — ведь при нем человеку не надо понимать всю твою программу, чтобы внести правку. Правка локальна для модуля ("компонента", класса, whatever).
BZ>и собственно, я замахнулся на публикацию в вики именно потому, что посчитал это наглядной демонстарцией использования именно функционального подхода к решению задач — даже тех, которые большинство программитсов считает чисто императивными (отслеживание цикличных ссылок). кстати, опять же моё решение этой проблемы лучше в том плане, что оно не слито с другими модулями — вычисление значения выражения, как у thesz/geniepro, или возврата значения ячейки, как у тебя
BZ>множество простых, независимых друг от друга модулей, каждый из которых решает простую, ясно очерченную задачу — это и есть хороший дизайн
Согласен. Тока есть design, и detailed design (по классификации PSP/TSP — описано в моем первом посте в блоге по проблеме К), которые лучше не путать. Последний у тебя хорош. Вот и выдели модули явно, с прописыванием интерфейсов, штоб видно было компоненты и их контракты друг перед другом. Хороший design можно показать "с птичьего полета".
Правда, там тоже нет явного разбиения на кучу малюсеньких модулей, всё в одном файле...
Но в принципе, программу визуально вполне можно разделить на четыре части, которые, впрочем, довольно тесно связаны друг с другом...
На Ваш тест
2 3
'Text 25
=A1 =A2 =A1+A3
программа даёт такой ответ:
Text 25
#Expr
Правда, расширенный пример Булата всё ещё приводит к переполнению стека, я над этим думаю.
Хочется решить это в рамках стандартного Хаскелла, а библиотека графов к стандартной вряд ли относится...
я потом этот приницп и в C++ использовал, только заменил type classes на templates, которые образовывали целую сеть с взаимодействующими интерфейсами, в т.ч. цикличными
Я повторюсь снова, но вот разве нет каких-либо внятных статей/книжек посвящённых именно правильному дизайну программных систем, про возможные подходы и т.п.?
В голову приходят только всякие Бучи да банды четырёх, но это лишь конкретные техники, они ведь особо не поясняют, к примеру, где именно лучше провести границы между классами и т.п.
Насколько я понимаю, по сути этот дизайн и должен быть одной из основных задач архитектора программных систем.
Здравствуйте, Курилка, Вы писали:
К>Я повторюсь снова, но вот разве нет каких-либо внятных статей/книжек посвящённых именно правильному дизайну программных систем, про возможные подходы и т.п.?
Самая внятная статья на эту тему написана Дэвидом Парнасом 35 лет назад.
"On the Criteria To Be Used in Decomposing Systems into Modules"
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, BulatZiganshin, Вы писали:
BZ>>Здравствуйте, Gaperton, Вы писали:
BZ>>хочешь хорошего дизайна — посмотри на http://haskell.org/haskellwiki/Library/Streams
К>Я повторюсь снова, но вот разве нет каких-либо внятных статей/книжек посвящённых именно правильному дизайну программных систем, про возможные подходы и т.п.? К>В голову приходят только всякие Бучи да банды четырёх, но это лишь конкретные техники, они ведь особо не поясняют, к примеру, где именно лучше провести границы между классами и т.п.
Паттерны — идут лесом сразу. Проектировать они не учат.
По концепции АТД — лучшая книга "Использование абстракций и спецификаций при разработке программ", основанная на курсе лекций самой Барбары Лисков в MIT в конце 70 годов. Переведена на русский. Идею использовать электронную таблицу в качестве задачи на дизайн я взял оттуда — там она проходит как семестровая практическая работа для группы из 5 человек, и существенно более наворочена и функциональна. Кроме дизайна — эта книга также учит процессу разработки, и спецификациям программ. Великолепная книга.
По ОО проектированию — лучшая книга из тех что я видел — Object Modeling Technique, Rumbaugh. Появилась задолго до UML, OMT была самой популярной методологией моделирования до UML, книга — the best of the best of the best, единственная книга, которая реально учит дизайну. Там в конце каждой главы офигенный список задач на проектирование и моделирование. Хороших задач, непростых. Rumbaugh — гений и гуру. Чего стоят одни только его статьи — по сравнению с ним труды Буча — это младенческий лепет и научно-популярная литература.
На русский не переводилась.
Также любопытен подход CRC Cards — обязателен к изучению для любого проектировщика и архитектора. Это единственный подход, который позволяет описать объектную систему с высоты "птичьего полета" — пренебрегая несущественными деталями, и оставляя суть. Набор CRC-карт для вашей системы — это квинтэссенция ее дизайна. Это выше уровнем, чем модели UML и OMT. Мы ее применяли как для языка, описывающего дизайн на раннем этапе, так и как лучшее средство документирования кода (CRC-карты писались в коде в комментариях к основным классам — единственно возможный подход не потерять информацию о дизайне при эволюции системы).
Но это на все — основное в проектировании на самом деле, это анализ сценариев использования системы — use cases. Это главное, если вы его не выполняете, то вы не в состоянии верифицировать ваш дизайн. Книг на эту тему порекомендовать не могу, но классический автор по этой теме вроде как Якобсон.
К>Насколько я понимаю, по сути этот дизайн и должен быть одной из основных задач архитектора программных систем.
Архитектор обязан уметь кодировать лучше остальных, дизайнить лучше остальных, ловить ошибки лучше остальных, просчитывать последствия архитектурурных решений лучше остальных, знать предметную область и ее проблематику лучше остальных, а также владеть основами управления проектами и управления требованиями. Его основная задача — технически обчеспечить успешное выполнение проекта большой группой людей.
Здравствуйте, Gaperton, Вы писали:
G>По концепции АТД — лучшая книга "Использование абстракций и спецификаций при разработке программ", основанная на курсе лекций самой Барбары Лисков в MIT в конце 70 годов.
оп-па. вот так и оказывается, что я просто читал правильные книги в детстве, а не сам такой умный
G>Архитектор обязан уметь кодировать лучше остальных, дизайнить лучше остальных, ловить ошибки лучше остальных, просчитывать последствия архитектурурных решений лучше остальных, знать предметную область и ее проблематику лучше остальных, а также владеть основами управления проектами и управления требованиями. Его основная задача — технически обчеспечить успешное выполнение проекта большой группой людей.
а если в группе есть девушки, он должен лучше остальных ... ?
Здравствуйте, Gaperton, Вы писали:
G>По концепции АТД — лучшая книга "Использование абстракций и спецификаций при разработке программ", основанная на курсе лекций самой Барбары Лисков в MIT в конце 70 годов. Переведена на русский. Идею использовать электронную таблицу в качестве задачи на дизайн я взял оттуда — там она проходит как семестровая практическая работа для группы из 5 человек, и существенно более наворочена и функциональна. Кроме дизайна — эта книга также учит процессу разработки, и спецификациям программ. Великолепная книга.
Ага, видал такое, кстати у неё недавно книжка с явой вышла.
Из отзывов:
..."development in Java" means that Java is the vehicle, not the topic being taught
Здравствуйте, Gaperton, Вы писали:
G>Идею использовать электронную таблицу в качестве задачи на дизайн я взял оттуда
А я как раз спросить хотел, а не оотуда ли задачка?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
G>>Идею использовать электронную таблицу в качестве задачи на дизайн я взял оттуда Т>А я как раз спросить хотел, а не оотуда ли задачка?
Дык! Задачка строго говоря не оттуда — я два дня условие составлял, чтобы убрать по максимуму кодирование и оставить проблемы дизайна, и сократить время решения задачи до 2-3 дней (в оригинале там задача на семестр на группу из 5 людей), а вот тема задачки и идея использовать для проверки дизайна электронную таблицу — безусловно взята оттуда. Лисков дурного не посоветует.
Я вот тут подумал, а что если ввести в эту электронную таблицу логические операции && || и операции сравнения > < >= <= == /= ... Что это даст? Можно ли будет с их помощью вычислить такие вещи, фибоначчи, факториал. аккермана и простые числа? Ведь макросов нету, циклов нету, циклические ссылки отбраковываются... Как их вычислять-то в таких условиях? А как вычислить их в Экселе, не пользуясь макросами?
G>Также любопытен подход CRC Cards — обязателен к изучению для любого проектировщика и архитектора. Это единственный подход, который позволяет описать объектную систему с высоты "птичьего полета" — пренебрегая несущественными деталями, и оставляя суть. Набор CRC-карт для вашей системы — это квинтэссенция ее дизайна. Это выше уровнем, чем модели UML и OMT. Мы ее применяли как для языка, описывающего дизайн на раннем этапе, так и как лучшее средство документирования кода (CRC-карты писались в коде в комментариях к основным классам — единственно возможный подход не потерять информацию о дизайне при эволюции системы).
