[Haskell] Проектирование.

Чем проектирование программ на Haskell отличается от проектирования программ на всём остальном?

>Чем проектирование программ на Haskell отличается от проектирования программ на всём остальном?

неусыпным врачебным контролем в режиме 24/7 над программирующем на Хаскеле пациентом

Первый выпуск fprog, было что-то.

«Проектировать»... Задумался, как я проектирую программы на Java. Да никак. А вообще бывает такое: «проектирование» применительно к софту? Мне кажется слово проектирование, да и ТЗ, придумали маразматичные старые дядьки эпохи ссср. Есть какие-то хотелки пользователей. Есть какое-то первичное приближение видения архитектуры. После N итераций (включающих взаимную еблю мозга между разрабами, манагерами и заказчиками) рождается нечто. Вот у этого нечно уже и есть некий дизайн.

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

Я думаю тоже самое и с хаскелем. Пиши вначале как нибудь. Потом рефакторь. С опытом выробатается вкус к тому как должна выглядеть прога на хаскеле. Потом нам расскажешь =)

>Задумался, как я проектирую программы на Java. Да никак. А вообще бывает такое: «проектирование» применительно к софту? Мне кажется слово проектирование, да и ТЗ, придумали маразматичные старые дядьки эпохи ссср. Есть какие-то хотелки пользователей. Есть какое-то первичное приближение видения архитектуры. После N итераций (включающих взаимную еблю мозга между разрабами, манагерами и заказчиками) рождается нечто. Вот у этого нечно уже и есть некий дизайн.

Скажи мне, где ты работаешь, и я буду обходить это место стороной

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

Весьма и весьма частично.

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

>проектирование, да и ТЗ, придумали маразматичные старые дядьки эпохи ссср

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

Bjarne Stroustrup в своей книге «The C++ Programming Language, Third Edition» в разделе 23.3 пишет

the development of a system involving hundreds of designers and programmers may require books of specifications carefully written using formal or semi-formal notations

Кто же так плохо повлиял на товарища Бьярна, научив его бюрократическому звездецу?

>Ну расказал бы что такое проктирование

Проктирование? Я не знаю что это. Им проктологи занимаются, да?

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

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

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

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

Ну страуструп, скажем, сам еще тот звездец.

Сколько читал про Scrum, TDD, там что-то вообще нету никаких «проектов».

Да и пофиг что пишут. Мало ли, марозматиков, действительно хвататет. А все эти Agile тоже теоретики по-хорошему.

Я кажется понял что имел ввиду ТС, он имел ввиду паттерны Хаскеля. «Как принято делать?» Меня тоже этот вопрос интересует. Прелагаю прекратить проектирование-срач

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

«I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.»

Не хочу затевать очередной ООП срач. Но Степанов прав как ни крути.

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

Рефактринг без тестов - это не рефакторинг

Не хочу затевать очередной ООП срач. Но Степанов прав как ни крути.

Ты затеял, так как Степанов не прав. Но предлагаю остановиться на том что мы просто не согласны.

Не хочется срачей, так как очень интересную тему начал ТС

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

Ок. По теме: паттерны зло. Для хаскеля тоже.

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

самое полезное, что я на этот счёт видел - это раздел RWH, посвящённый инкапсуляции с помощью монад

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

Паттерны не зло. Надо быть достаточно хорошим программистом чтобы придумать, оформить и озвучить концепцию в теории, в чистом виде: стек, блокирующая очередь, пул обьектов (или потоков), синглтон, адаптер, очередь с приоритетами, семафор, ReadWriteLock, фабрика, MVC.

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

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

>всегда может прийти требование, которое заставить все перефигачить

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

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

А если твой код используется десятками твоих коллег-программистов через утверждённые ранее интерфейсы?

А не хрен утверждать интерфейсы как истину. Ты вообще про Agile слышал?

Такое «перефигячивание» потребует долгих согласований со всеми ими + начальство + планы и т.п. с четким описанием «перефигячивания» в письменном виде, то есть бюрократии.

Вот и я говорю, что бюрократия.

>Ты вообще про Agile слышал?

Ну я слышал, и работаю по нему. Но всё же ломать устоявшиеся интерфейсы не вижу приемлемым

А не хрен утверждать интерфейсы как истину. Ты вообще про Agile слышал?

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

А причем здесь место, где я работаю? Я работаю в 2-х местах. Еще в 2-х работал до этого. Слабо привести нормальные аргументы? Выключи школо в стиле, а у меня все работает, ЧЯДНТ?

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

Ну я слышал, и работаю по нему. Но всё же ломать устоявшиеся интерфейсы не вижу приемлемым

Ну конечно какое-то время все пытаются налепить костылей. Потом их просто втыкать некуда. Ломают и делают как надо. Это и есть «проектирование» =)

А причем здесь место, где я работаю?

я там выше пояснил, вообще говоря

>Ну конечно какое-то время все пытаются налепить костылей. Потом их просто втыкать некуда. Ломают и делают как надо.

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

я там выше пояснил, вообще говоря

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

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

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

>Его нужно было ломать чуть чаще.

Вот с этим, пожалуй, согласен - но тут имеет место прокрастинация и нестыковки с менеджментом :)

где-то есть священные программисты, котороые генерируют безошибочную архитектуру ДО написания кода

часто с зеркалом разговариваешь?

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

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

строить грамотную архитектуру под текущий вариант требований

Существует бесконечное множество вариантов архитектуры под данные требования. Просто какие-то решения выживают, а какие-то нет. Эволюционные процесс. Главное, что бы поколения (итерации) быстро происходили.

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

что строить грамотную архитектуру под текущий вариант требований

Весь фокус в том, что все требования (от себя, как от разрабочика в первую очередь) ты получаешь, когда код уже написан. Процесс можно повторять. Пишеш, код - новые требования, пишешь код - опять новые требования. Чем дальше, тем дороже. «Лучшее - враг хорошего». Так что мера во всем нужна.

АХТУНГ! Водопадники в треде!

здесь утверждали что код должен эволюционировать и его не надо проектировать

15-ть страниц...

Мда. Кстати, справедливости ради, расскажу, что бывают вырожденные случаи. Я вот недавно спроектировал и реализовал протокол. За одну итерацию. Как показала практика - угадал. А вот другой свой проект средних размеров уже вот 3-й раз почти с нуля перефигачил, уже на что-то похоже. Думаю еще косметический рефакторинг сделать.

Задумался, как я проектирую программы на Java. Да никак. А вообще бывает такое: «проектирование» применительно к софту? Мне кажется слово проектирование, да и ТЗ, придумали маразматичные старые дядьки эпохи ссср. Есть какие-то хотелки пользователей. Есть какое-то первичное приближение видения архитектуры. После N итераций (включающих взаимную еблю мозга между разрабами, манагерами и заказчиками) рождается нечто. Вот у этого нечно уже и есть некий дизайн.

Скажи мне, где ты работаешь, и я буду обходить это место стороной

И зря. Этот подход называется «экстремальное программирование» и считается более перспективным, чем классический. Приведу очень простой пример: ядро Linux=)

Без этого «бюрократического звездеца» потом и выходят всякие кривые лялехи в которых исправления в usb'стеке нахер ломают видеоподсистему.

> самое полезное, что я на этот счёт видел - это раздел RWH, посвящённый инкапсуляции с помощью монад

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

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

Черт возьми, как-то не подумал о TMR даже. Полезно, спасибо.

Толсто

Ладно, видимо, здесь бессмысленно этот вопрос задавать.

На http://haskell.org/haskellwiki/Learning_Haskell был?

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

>АХТУНГ! Водопадники в треде!

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

Я вот удивляюсь способности людей всё возносить в абсолют.

>Хренасе «перефигачить». А если твой код используется десятками твоих коллег-программистов через утверждённые ранее интерфейсы?

Кстати забыл сказать. Внутренняя архитектура != внешняя архитектура. Если происходят серьезные изменения во внутренней архитектуре одного из программных компонентов, то это ещё не означает, что это как-то затронет других. Либо может затронуть, но не достаточно значительно чтобы делать из этого трагедию. Правда если ПО изначально имеет архитектуру типа «Вермишель», то да, любое изменения будет затрагивать всех и причем весьма трагично.

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

Скорее как на лиспе, т.е. восходящий.

Применимо и то, и другое.

> На http://haskell.org/haskellwiki/Learning_Haskell был?

Какая тонкая и острая шутка, браво. Ха, ха, ха.