Ответ на »сообщение 3139« (Jack Of Shadows)
___________________________

А вот тулзы для рефакторинга - вешь искусственная и нужная только вам, ОО программистам.
Мы запросто меняем (то есть рефакторим) код просто ручками, легко и естественно.

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

Является ли модульное программирование императивным? В подходе Вирта -- вроде, да. Но и в его подходе модули (и их отношения) -- декларативны. Их содержимое императивно. Что из этого следует? Правильно -- модульное программирование может быть и императивным, и декларативным. Что касается ООП -- ситуация аналогична.

А что отличает императив от декларатива? Правильно -- синхрон в первом случае и асинхрон во втором.

К чему это я? К тому, что неплохо бы по-иному взглянуть на стереотипы. Вреда от них становится больше, чем пользы.

Ответ на »сообщение 3140« (Jack Of Shadows)
___________________________

Так что я не понимаю что вы имеете в виду под "архитектурным рефакторингом" ? Что это ? Новые версии программы ? Кодогенерация ?


В общем-то я ссылку чуть ниже приводил: http://www.citforum.ru/SE/project/refactor/

Ответ на »сообщение 3136« (Руслан Богатырев)
___________________________
Что Вы можете сказать по поводу рефакторинга архитектурного в ФП
ПО моему "архитектурный рефакторинг" это оксюморон. Так любое изменение программы можно обозвать рефакторингом. :))
Рефакторинг по определению должен менять код, но не поведение программы.
Так что я не понимаю что вы имеете в виду под "архитектурным рефакторингом" ? Что это ? Новые версии программы ? Кодогенерация ?

Ответ на »сообщение 3136« (Руслан Богатырев)
___________________________
Руслан, рефакторинг как процес - вешь естественная и необходимая всем.
А вот тулзы для рефакторинга - вешь искусственная и нужная только вам, ОО программистам.
Мы запросто меняем (то есть рефакторим) код просто ручками, легко и естественно.
У вас же это настолько трудная работа что без поддержки IDE руки просто опускаются.

Ответ на »сообщение 3136« (Руслан Богатырев)
___________________________

Здесь на форуме я неоднократно встречал примеры, которые тут же другими участниками рефакторились. Причем весьма заметно. Для меня это сигнал о том, что в ФП рефакторинг не просто менее востребован, а вполне вероятно, что даже более, чем в ИП.

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

Что Вы можете сказать по поводу рефакторинга архитектурного в ФП (или в конкретном ФЯ)?

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

Ответ на »сообщение 3133« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3121« (Илья Ермаков)
___________________________
Ну а если серьезно, то очень показательно какой вывод делает Илья - Если необученный человек не может пользоваться инженерным инструментом то ...виноват инструмент, надо его "исправить". Речи о том что надо бы обучить этого "студента" даже просто не ведется.

Нет, я такой вывод не делаю... И речь именно о том, чтобы "обучить". Просто наблюдаю я за студентами, не обученными алгоритмизации, обычно как посторонний, поскольку в рамках основной сетки часов я в ВУЗе не веду. А обучаю отдельным спецкурсом желающих, тех, кому надо, а не кто за корочкой пришёл :-)

В остальном, в общем и абстрактно, согласен :-)

Ответ на »сообщение 3135« (Jack Of Shadows)
___________________________

А вот в ФП рефакторинг, так же как и design patterns - соврешенно не прижился, не нужен. Ведь функции чистые, ни к чему не привязанные. Их реорганизовать, перегруппировать, перебросить из модуля в модуль, легче легкого. Они ничего за собой не тянут, ни к чему не привязаны. Их не нужно ни от чего отрывать.

Здесь на форуме я неоднократно встречал примеры, которые тут же другими участниками рефакторились. Причем весьма заметно. Для меня это сигнал о том, что в ФП рефакторинг не просто менее востребован, а вполне вероятно, что даже более, чем в ИП. Что Вы можете сказать по поводу рефакторинга архитектурного в ФП (или в конкретном ФЯ)?

Ответ на »сообщение 3131« (Руслан Богатырев)
___________________________
Под рефакторингом в индустрии программирования понимают только лишь те изменения кода, которые направлены на его реструктуризацию, без изменения функциональности или каких либо runtimе качеств программы.

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

А вот в ФП рефакторинг, так же как и design patterns - соврешенно не прижился, не нужен. Ведь функции чистые, ни к чему не привязанные. Их реорганизовать, перегруппировать, перебросить из модуля в модуль, легче легкого. Они ничего за собой не тянут, ни к чему не привязаны. Их не нужно ни от чего отрывать.

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

И оставьте вы им в конце концов этот break Илья! Не забывайте для кого созданны эти языки. ИМ нужен break!
Вы пытаетесь совместить несовместимые вещи. Инструмент ПРЕДНАЗНАЧЕННЫЙ для необученных масс, с грамотным программированием. В то время как вам давно пора осознать, что придется делать выбор и либо остаться там с ними, либо уходить туда, где проблем с неграмотным программированием просто нет. Если можно была бы ВСЕХ дешево и быстро обучить, не сомневайтесь, и без вас давно бы это сделали.
Ну а поскольку это сделать нельзя - то вы боретесь с естественным ходом вещей, и никогда ничего не добьетесь.
Это я про ваши до смешного беспомощные попытки в образовании этих самых "необученных алгоритмизации" студентов.

Учите инженеров.

Ответ на »сообщение 3121« (Илья Ермаков)
___________________________
Почему я столь агрессивно настроен на break - потому что многократно наблюдал, как программируют студенты, не обученные алгоритмизации.
Ну вот вам господа и акцент, который ставит как индустрия так и наши уважаемые оберонисты. Язык предназначается для кого ? Правильно, для "студентов, не обученных алгоритмизации", лохов по простому.
Кто то очень правильно сказал, создай инструмент для дураков, и только дураки будут им пользоваться.
Отсюда и наплыв :))
Ну а если серьезно, то очень показательно какой вывод делает Илья - Если необученный человек не может пользоваться инженерным инструментом то ...виноват инструмент, надо его "исправить". Речи о том что надо бы обучить этого "студента" даже просто не ведется.
Можно было бы посмеяться над таким подходом, если бы не одно но. Именно этот подход и выгоден индустрии в целом. Потому что обучение очень дорого, требует много времени и полезный выход очень мал. А нужна АРМИЯ программистов, а не группа спецназа.
Вот именно поэтому языки в которых обхаживают "студентов, не обученных алгоритмизации" всегда будут в фаворе.
Инструменты же для инженеров, так и останутся узкоспециализированной нишей.
Потому что они "заумные" эти нинструменты. Потому что в них нет видите ли операторов цикла (соответственно и проблемы break :)) )

Что получится если студенту не обученному алгоритмизации дать в руки скажем хаскель ? А ничего не получится. Он просто не сможет воспользоваться этим инструментом до тех пор пока не будет этой самой алгоритимизации обучен. Своеобразный предохранитель.
Что получится если студенту не обученному алгоритмизации, дать в руки дельфи, java? да тот же самый оберон ? Получится ...ПРОГРАММА!! Пусть кривенькая, пусть нечитабельная, пусть с ошибками, но черт возьми эта программа будет выполнять полезную работу, будет приносить деньги.
И в конце концов это и есть самый важный и определящий критерий.
Да здравствуют языки для лохов!!