Экстремальное программирование [Re: Случайное программирование]
(Если я тебя правильно понял)
Да, наиболее вероятно, что хаос станет самоорганизовываться похожим путём с реальным. И возникнут гены.
Да, наиболее вероятно, что хаос станет самоорганизовываться похожим путём с реальным. И возникнут гены.
Утверждение неверно.
Для возникновения самоорганизации тебе нужна отрицательная обратная связь,
очень маловероятно что ты сможешь создать аналог природной обратной связи,
а значит и аналогии у тебя появятся только общие
Для возникновения самоорганизации тебе нужна отрицательная обратная связь,
очень маловероятно что ты сможешь создать аналог природной обратной связи,
а значит и аналогии у тебя появятся только общие
Нужна не связь, а большая вычислительная мощь и большое кол-во элементов (бит) в системе. Чем больше элементов, тем больше вероятность (отсюда скорость) самопоявления заданной структуры.
Заданная структура не была описана.
Выделить интересующую тебя структуру (такая есть, я надеюсь) нетривиально,
пока она сильно не размножится. Для размножения нужна стабильность, иначе она постоянно будет
мутировать.
Вот эта стабильность и задается отрицательной обратной связью.
Выделить интересующую тебя структуру (такая есть, я надеюсь) нетривиально,
пока она сильно не размножится. Для размножения нужна стабильность, иначе она постоянно будет
мутировать.
Вот эта стабильность и задается отрицательной обратной связью.
Слово я неудачное употребил. Лучше не "заданная", а "некоторая". Имелась ввиду любая структура, которую тебе захочется найти.
Да, вобщем-то по любому сравнением нужно её находить. Размножаться эти "совокупности атомов" пускай сами учатся.
Да, вобщем-то по любому сравнением нужно её находить. Размножаться эти "совокупности атомов" пускай сами учатся.
Итак, понятно, что для этой задачи нужно использовать виртуальный процессор ВП.
Как лучше организовать в ВП обработку вызова прерываний из этого хаоса? (Ваши идеи на русском / код на Си)
Как лучше организовать в ВП обработку вызова прерываний из этого хаоса? (Ваши идеи на русском / код на Си)
и как ты будешь эту структуру выявлять? на глазок? 
вспоминаются кадры из Матрицы, где Нео показывают на экране падающие зелёненькие символы а чувак ему втирает, что он уже научился их распознавать...
вспоминаются кадры из Матрицы, где Нео показывают на экране падающие зелёненькие символы а чувак ему втирает, что он уже научился их распознавать...> Итак, понятно, что для этой задачи нужно использовать виртуальный процессор ВП.
Чо? Чо?
Программки у тя должны быть короткие, различных инструкций мало, поэтому чистый интерпретатор может даже быстрее работать чем исполняемый код - за счёт отсутствия разнообразных оверхедов на всё.
Вообще мой тебе совет - посиди, подумай, всё такое. Трезво оцени обстановку. Напиши что-нибудь совсем простое.
А то щаз твои идеи какие-то космические как по масштабу, так и по глупости.
"Размножаться эти "совокупности атомов" пускай сами учатся" - знаешь, при такой постановке задачи даже отрицательный результат ничего тебе не даст, потому как предсказуем с еденичной вероятностью.
Чо? Чо?
Программки у тя должны быть короткие, различных инструкций мало, поэтому чистый интерпретатор может даже быстрее работать чем исполняемый код - за счёт отсутствия разнообразных оверхедов на всё.
Вообще мой тебе совет - посиди, подумай, всё такое. Трезво оцени обстановку. Напиши что-нибудь совсем простое.
А то щаз твои идеи какие-то космические как по масштабу, так и по глупости.
"Размножаться эти "совокупности атомов" пускай сами учатся" - знаешь, при такой постановке задачи даже отрицательный результат ничего тебе не даст, потому как предсказуем с еденичной вероятностью.
Твои примеры касались генетического программирования. Это близкое понятие к этой теме.
Я отлично понимаю, что, используя готовые механизмы мутации и отсеивания, некий результат, который ты ожидаешь от системы, появится в порядки раз быстрее.
Понимаешь, от системы нужно получить не столько что-то ожидающееся, сколько нечто совершенно неожиданное.
Насчёт отрицательного результата - почему ты так уверен? Ведь ни ты, ни я ещё не оценивали вероятное время достижения результата.
Идея глупая? А я не знаю, как идеи оценивать. Скорее эта идея маловероятно приведёт к хоть какому-нибудь результату...
Да, наверно, стоит придумать свой набор команд и поток-интерпретатор.
Я отлично понимаю, что, используя готовые механизмы мутации и отсеивания, некий результат, который ты ожидаешь от системы, появится в порядки раз быстрее.
Понимаешь, от системы нужно получить не столько что-то ожидающееся, сколько нечто совершенно неожиданное.
Насчёт отрицательного результата - почему ты так уверен? Ведь ни ты, ни я ещё не оценивали вероятное время достижения результата.
Идея глупая? А я не знаю, как идеи оценивать. Скорее эта идея маловероятно приведёт к хоть какому-нибудь результату...
Да, наверно, стоит придумать свой набор команд и поток-интерпретатор.
нечто совершенно неожиданное.Говори за себя. Прог, которые тебе нужны - мало. Это очевидно. Всего количество прог растёт экспоненциально от длины. Если у тебя 10 различных безоперандных(!) инструкций, то всего прог длины 20 - 10^20 (десять с двадцатью нулями) штук.
Насчёт отрицательного результата - почему ты так уверен? Ведь ни ты, ни я ещё не оценивали вероятное время достижения результата.
С другой стороны, если мы говорим об х86, то в ней почти любая последовательность байтов является программой (0xFF, конечно, мешает, но не сильно поэтому, скажем, прог занимающих 20 байтов уже 2^160 ~ 10^54. Это уже где-то больше чем возраст вселенной в секундах, наверное.
Хотя ты можешь верить, что вторая же прога выведет тебе "matrix has you neo". Типа "неожиданность" и всё такое.
Я лично сомневаюсь, что тебе удастся хотя бы убить винт (ты там чего-то про прерывания говорил, да? но попробовать стоит, ага.
Со своей стороны могу предложить даже более интеллектуальное развлечение: вместо создания проги с нуля, пиши случайные байты в уже готовую. В интернет эксплорер! Вдруг он превратится в крякер интернета?
И ты прав (не считая иронии во втором и третьем абзацах).
С другой стороны я ещё не накладывал никаких ограничений на размер моего "винта" и мощь моего "проца".
Про прерывания мне нужен был ответ, если я буду иполнять проги сразу на проце. Пожалуй, сначала нужно опробовать интерпретаторный подход.
С другой стороны я ещё не накладывал никаких ограничений на размер моего "винта" и мощь моего "проца".
Про прерывания мне нужен был ответ, если я буду иполнять проги сразу на проце. Пожалуй, сначала нужно опробовать интерпретаторный подход.
Есть игра C.O.R.E WAR, где игроки-программисты создают программы на внутреннем языке RED CODE, которые потом борются за выживание на закольцованном адресном пространстве, где все ссылки относительные.
А еще есть продвинутое направление генетического программирования "эволюционное программирование". Оно реализовано (и очень неплохо, по заявлению разработчиков в одном из самых мощных в мире приложений, решающих задачу классификации, распознавания и прогнозирования - polyanalyst.
Подробнее - здесь:
http://www.megaputer.ru
А еще есть продвинутое направление генетического программирования "эволюционное программирование". Оно реализовано (и очень неплохо, по заявлению разработчиков в одном из самых мощных в мире приложений, решающих задачу классификации, распознавания и прогнозирования - polyanalyst.
Подробнее - здесь:
http://www.megaputer.ru
Классический пример - экстремальное программированиеГлебиус, а что ты понимаешь под экстремальным программированием?
Я-то в курсе, что такое ХР.
Поэтому мне и показалось. что ты привёл неудачный пример. Исправь меня, если я что-то не так понимаю.
Поэтому мне и показалось. что ты привёл неудачный пример. Исправь меня, если я что-то не так понимаю.
По-моему пример очень удачный. Ниибёт архитертура, пока программа выполняет все unit-тесты. Как следствие, внутри программы может быть всё, что угодно.
А как это сочетается с парным кодированием, обменом задачами и знаниями и т. д.?
Я это к тому, что как раз никакого хаоса внутри проги быть в принципе не может, если это тру ХР, а не не пойми что.
Мудаки могут написать говнопрогу следуя абсолютно любой методике.
> Ниибёт архитертура, пока программа выполняет все unit-тесты
Этой фразы в книжке про экстремальное программирование я что-то не встречал. Ты её сам придумал, наверное, глядя на каких-нибудь мудаков.
> Ниибёт архитертура, пока программа выполняет все unit-тесты
Этой фразы в книжке про экстремальное программирование я что-то не встречал. Ты её сам придумал, наверное, глядя на каких-нибудь мудаков.
> Этой фразы в книжке про экстремальное программирование я что-то не встречал.
В книжке она звучит как: "дави в себе архитектора"
В книжке она звучит как: "дави в себе архитектора"
> А как это сочетается с парным кодированием, обменом задачами и знаниями и т. д.?
Так и сочетается. Пишут копролит вдвоем.
Так и сочетается. Пишут копролит вдвоем.
> Я это к тому, что как раз никакого хаоса внутри проги быть в принципе не может, если это тру ХР, а не не пойми что.
Ахх... То есть лепим-лепим пожарного, а всё получается милиционер? Пожалуйста покажи пример программы, где тру XP таки удалось.
Ахх... То есть лепим-лепим пожарного, а всё получается милиционер? Пожалуйста покажи пример программы, где тру XP таки удалось.
В _моей_ книжке такого не было.
Там была фраза про "самое простое решение - самое лучшее" и ещё про "достоинства архитектуры практически невозможно оценить пока она не в коде".
По-моему очевидно, что если постоянно рефакторить код с целью равномерного распределения простоты по всем уровням (и об этом в книжке сказано - про устранение повторяющегося кода то есть превращая хаки в детали системы, то получится прекрасный дизайн.
Естественно изначальный дизайн должен быть достаточно расширяем для этого. В грамотный скалябельный дизайн можно органично внести вообще что угодно, я так думаю.
В книжке протестуют против _избыточного_ обдумывания дизайна - когда через 18 месяцев работы есть двадцать томов документации и ни строчки кода.
То, что дизайн нужен - имхо очевидно. ХР (как его понимаю я) утверждает, что от дизайна требуется только хорошая расширяемость.
Если кто-то понимает ХР не так, он вполне может писать говнокод, я не спорю.
Там была фраза про "самое простое решение - самое лучшее" и ещё про "достоинства архитектуры практически невозможно оценить пока она не в коде".
По-моему очевидно, что если постоянно рефакторить код с целью равномерного распределения простоты по всем уровням (и об этом в книжке сказано - про устранение повторяющегося кода то есть превращая хаки в детали системы, то получится прекрасный дизайн.
Естественно изначальный дизайн должен быть достаточно расширяем для этого. В грамотный скалябельный дизайн можно органично внести вообще что угодно, я так думаю.
В книжке протестуют против _избыточного_ обдумывания дизайна - когда через 18 месяцев работы есть двадцать томов документации и ни строчки кода.
То, что дизайн нужен - имхо очевидно. ХР (как его понимаю я) утверждает, что от дизайна требуется только хорошая расширяемость.
Если кто-то понимает ХР не так, он вполне может писать говнокод, я не спорю.
> В книжке она звучит как: "дави в себе архитектора"
Почти во всех классических книжках по XP написано:
как только код заработал (начали проходить тесты) -> отрефактори его, чтобы он не только работал (проходил тесты но и имел понятную архитектуру.
ps
простая архитектура - это один из тестов
Почти во всех классических книжках по XP написано:
как только код заработал (начали проходить тесты) -> отрефактори его, чтобы он не только работал (проходил тесты но и имел понятную архитектуру.
ps
простая архитектура - это один из тестов
> "достоинства архитектуры практически невозможно оценить пока она не в коде"
Не согласен, хотя это вне контекста обсуждения.
> если постоянно рефакторить код с целью равномерного распределения простоты по всем уровням
Это конечно хорошо. То, что написал тоже хорошо. Наверное в "тру XP" так и делают. Но обычно в коммерческих конторах (а именно там фанатеют от XP) этот момент опускается, потому как задание уже выполнено и значит можно преступать к следующему. Если же постоянно возвращаться к тому, что уже сделано для того, что бы это отрефакторить, то основное преимущество XP - скорость, будет утеряно.
Теперь мне интересны живые примеры "тру XP", где получился хороший код и действительно он был написан с помощью XP.
Не согласен, хотя это вне контекста обсуждения.
> если постоянно рефакторить код с целью равномерного распределения простоты по всем уровням
Это конечно хорошо. То, что написал тоже хорошо. Наверное в "тру XP" так и делают. Но обычно в коммерческих конторах (а именно там фанатеют от XP) этот момент опускается, потому как задание уже выполнено и значит можно преступать к следующему. Если же постоянно возвращаться к тому, что уже сделано для того, что бы это отрефакторить, то основное преимущество XP - скорость, будет утеряно.
Теперь мне интересны живые примеры "тру XP", где получился хороший код и действительно он был написан с помощью XP.
> Теперь мне интересны живые примеры "тру XP", где получился хороший код ...
Кто ж тебе его покажет?
Кто ж тебе его покажет?
> Но обычно в коммерческих конторах (а именно там фанатеют от XP) этот момент опускается, потому как задание уже выполнено
Тоже самое происходит и при обычным подходом.
Программа с изначальной красивой задумкой и стройной архитектурой - через несколько месяцев кодирования, добавления расширений и столкновений с реальностью - превращается в жуткую помойку.
ps
Серебряных пуль не бывает, но бывают методики/технологии, которые при грамотном применении дают более лучший результат, чем без них.
Тоже самое происходит и при обычным подходом.
Программа с изначальной красивой задумкой и стройной архитектурой - через несколько месяцев кодирования, добавления расширений и столкновений с реальностью - превращается в жуткую помойку.
ps
Серебряных пуль не бывает, но бывают методики/технологии, которые при грамотном применении дают более лучший результат, чем без них.
> Тоже самое происходит и при обычным подходом.
При обычном подходе программист, если он хочет, всегда может аппелировать к тому, что написание программы это не рубка дров, что иногда нужно остановиться и подумать.
При обычном подходе программист, если он хочет, всегда может аппелировать к тому, что написание программы это не рубка дров, что иногда нужно остановиться и подумать.
>При обычном подходе программист, если он хочет, всегда может аппелировать к тому, что написание
>программы это не рубка дров, что иногда нужно остановиться и подумать.
Где ж ты про ХР читал-то, интересно?
>программы это не рубка дров, что иногда нужно остановиться и подумать.
Где ж ты про ХР читал-то, интересно?
Между прочим постоянная работа над архитектурой - тоже часть ХР 
Сами авторы говорят о возможности использовать только часть методологий ХР, но о желательности как можно более полного использования всех методологий ХР.
А если ты имеешь в виду только unit-тесты - так это само по себе не есть ХР
Сами авторы говорят о возможности использовать только часть методологий ХР, но о желательности как можно более полного использования всех методологий ХР.
А если ты имеешь в виду только unit-тесты - так это само по себе не есть ХР
> Где ж ты про ХР читал-то, интересно?
Я давал ссылки.
Я давал ссылки.
> Между прочим постоянная работа над архитектурой - тоже часть ХР
Да, меня уже убедили, что я не видел "тру XP". Так вот я прошу показать мне примеры "тру XP", где получалось бы и быстро и код нормальный.
Да, меня уже убедили, что я не видел "тру XP". Так вот я прошу показать мне примеры "тру XP", где получалось бы и быстро и код нормальный.
Посмотри на том же Sourceforge, часть успешных проектов как раз пишется с тем или иным применением XP.
из c# - вроде NUnit и Nant пишутся с подмножеством правил из XP.
из c# - вроде NUnit и Nant пишутся с подмножеством правил из XP.
> Посмотри на том же Sourceforge, часть успешных проектов как раз пишется с тем или иным применением XP.
Ну какие именно?
> из c# - вроде NUnit и Nant пишутся с подмножеством правил из XP.
Подмножество правил не канает. Тогда можно сказать, что FreeBSD пишется с применением XP, т.к. regression tests есть.
Ну какие именно?
> из c# - вроде NUnit и Nant пишутся с подмножеством правил из XP.
Подмножество правил не канает. Тогда можно сказать, что FreeBSD пишется с применением XP, т.к. regression tests есть.
Зайди да посмотри
вот, например, цитата из правил NUnit-а
вот, например, цитата из правил NUnit-а
PhilosophyЭто достаточно XP-ишно?
First and foremost, we have done our best to insure that this program was developed test-first. As such we will accept no code changes without associated tests. As for bug fixes we plan to follow the procedure that we write a failing unit test first and then fix it. In this fashion, the number of tests that we have will grow over time. Lastly, if a change breaks an existing test it is the responsibility of the person making the change to first understand the ramification of the change and either fix the test or alter the modification that caused the problem. That said, if you are interested, so are we, please help make NUnit the best xUnit tool in any language.
> Это достаточно XP-ишно?
Нет. Что же тут экстремального?
Я ж не говорю, что тесты это плохо. Я говорю, что плохо когда они являются основным критерием работоспособности.
Нет. Что же тут экстремального?
Я ж не говорю, что тесты это плохо. Я говорю, что плохо когда они являются основным критерием работоспособности.
Я ж не говорю, что тесты это плохо. Я говорю, что плохо когда они являются основным критерием работоспособности.А что же тогда считается основным критерием? Жалобы недовольных пользователей релизов?
Хотелось бы хоть иногда использовать старые наработки в новых проектах. А как использовать, если в исходном коде сам чёрт не разберётся?
А это правда, что ХР предполагает, что прогеры работают парами над одним и тем же кодом?
это лишь рекомендация, но имхо дебильная... плохо представляю себе этот процесс
Это не рекомендация - это одна из практик.
Причем это не панацея - есть список рекомендаций, когда его использовать не стоит.
И нечего тут представлять - это пробовать надо
Я когда-то пробовал, но еще не знал, что оно так называется.
Интересная штука, но важен соответствующий настрой в команде разработчиков.
Причем это не панацея - есть список рекомендаций, когда его использовать не стоит.
И нечего тут представлять - это пробовать надо
Я когда-то пробовал, но еще не знал, что оно так называется.
Интересная штука, но важен соответствующий настрой в команде разработчиков.
имхо, это наиболее правильное правило XP
Я последнее время только так и прогаю - в паре то есть.
Код пишется почти с той же скоростью (то есть почти с суммарной скоростью двух кодеров, за счёт отсутствия перерывов на поффтыкать - наблюдающий успевает разрабатывать стратегию on the fly и несравнимо более высокого качества - как в смысле отсутствия ошибок, так и в смысле дизайна.
Словами про это говорить неинтересно, это надо попробовать.
Код пишется почти с той же скоростью (то есть почти с суммарной скоростью двух кодеров, за счёт отсутствия перерывов на поффтыкать - наблюдающий успевает разрабатывать стратегию on the fly и несравнимо более высокого качества - как в смысле отсутствия ошибок, так и в смысле дизайна.
Словами про это говорить неинтересно, это надо попробовать.
Просто там где я про это слышал чел говорил, что парность позволяет новым людям быстрее в проект включаться и приносить отдачу.
Ну да, потому что происходит постоянная передача знаний между программистами в паре
ни разу не пробовал писать в паре ... но ведь у разных людей разный стиль программирования, вы там не ссоритесь ,когда пишите 
у разных людей разный стиль программированияВообще-то нормальные кодеры должны соблюдать что-то типа Coding Technique Guidelines, а не хреначить креативы, типа как на удаве
Через некоторое время стиль становится абсолютно одинаковым, и это хорошо.
Так ты из Oilspace.
То-то все XP грязью поливаешь
То-то все XP грязью поливаешь
а какая связь ?
> А это правда, что ХР предполагает, что прогеры работают парами над одним и тем же кодом?
Это одна из рекомендаций.
Польза есть, но при внедрений имеет очень много подводных камней.
Это одна из рекомендаций.
Польза есть, но при внедрений имеет очень много подводных камней.
Если кого ещё не достал цитатами из Б. Эккеля (Thinking in Java)...
TIJ:
The value of pair programming is that one person is actually doing the coding while the other is thinking about it. The thinker keeps the big picture in mind—not only the picture of the problem at hand, but the guidelines of XP. If two people are working, it’s less likely that one of them will get away with saying, “I don’t want to write the tests first,” for example. And if the coder gets stuck, they can swap places.
Да, меня уже убедили, что я не видел "тру XP". Так вот я прошу показать мне примеры "тру XP", где получалось бы и быстро и код нормальный.9-я версия ACD/SpecManager (будет) написана XP командой из 10-ти человек.
Оставить комментарий
sergey_m
> Классический пример - игра ЖизньКлассический пример - экстремальное программирование. Пока не сбоят unit-тесты можно делать всё что угодно, наплевав на архитектуру программного продукта. В итоге получается работающий копролит. И чем дольше его возраст, тем больше экстремальное программирование становится похожим на генетическое.