Здравствуйте, pgregory, Вы писали:
P>Или ты не разделяешь мое мнение, что «коммутативное кольцо с единицей» — на пару порядков более сложное понятие, чем «целое число»?
Наверное потому, что оно более общее?
У меня есть знакомый, который вполне так искренне спрашивает, а зачем какие-то объекты? Он данные через функции гоняет и всё нормально. Человек без опыта.
Чтобы ему понять, зачем ему нужно ООП, надо будет втирать про полиморфизм и наследование. А так совершенно неясно ведь, чем some_foo(x) хуже x.foo().
Кстати, как на пальцах наследование с полиморфизмом рассказать?
Либо у меня не такие знакомые, но я не видел интуитивного понимания ООП, просто это то, чему сейчас учат всех. Если ты про то ООП, где ящики сообщениями обмениваются, то тут ещё сложнее объяснить, зачем оно вообще всё нужно.
Здравствуйте, pgregory, Вы писали:
P>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!»
P>Если так, то что же, я с этим не согласен. Если не очевидно, почему, могу попытаться обосновать.
Здравствуйте, thesz, Вы писали:
T>Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями?
А нужно ли чтобы в языке было такое подмножество? Почему во многом близкий к питону Smalltalk в котором это возможно, менее популярен?
В мейнстрим почему-то попадают более корявые и не имеющие теоретической базы языки.
Вон тому же Немерли даже мимикрирование под мейнстрим ничем ни помогло.
N>>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне? T>>Насколько мне известно, в её реализации используется ленивость. BZ>afair, во второй версии darcs они сделали type-safe описание патчей с помощью GADT. типа того, что если патчи применять в неправильном порядке — то это обнаружит type checker
Во дают!
Это уж точно на Питоне замучаешься реализовывать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
P>>>>Я целиком за использование хороших яп вместо плохих яп. Вопрос в том, что же такое хороший яп? Хороший яп — это тот, который позволяет тебе мыслить на более высоком уровне, чем до этого, будучи сам по себе простым до очевидности. Сорри за курсив :-) Хороший яп должен «fit my mind». Он не должен требовать огромного багажа знаний, чтобы начать его использовать. Пример однозначно хорошего языка — питон. Или С. T>>>Перевод: "хороший яп — тот, что я знаю прямо сейчас." P>>Чушь. P>>Можешь читать мои слова буквально, без переводов?
T>Да у тебя именно это и написано. Открытым текстом.
thesz, извини конечно, но тут я уже бессилен. Можешь, конечно, считать, что я туп настолько, что сам не понимаю, что я пишу — дело твое.
P>>У меня есть точка зрения, что такое хороший яп, а что — нет. Основная мысль в том, что реально хороший язык реально прост. Я ее высказал и попытался обосновать. Того, что ты усмотрел, в ней и близко нет. Замечания по сути есть?
T>"Реально прост" чем определяется?
Реально прост определяется тем, что я его реально просто смогу объяснить ребенку или старику. Нет, я не докажу это утверждение.
T>Хаскель реально прост теоретически. У него внутре неонка, то есть, ЛИ с нормальным порядком упрощений. Все его конструкции могут быть записаны на этом ЛИ. Да даже типы у него функции: T>
T>instance Monad m where-- m - параметр
T> return :: m a -- из этого следует, что m - функция из типа в тип.
T> ...
T>
T>С помощью ЛИ можно сделать всё, что есть внутри Хаскеля. if-then-else, if-then, циклы. Даже сравнение с образцом. Type safe pattern matching combinators
Ты чего в ответ на эту тираду ждешь? Что с помощью асма можно сделать все, что ты можешь придумать на хаскеле вообще?
T>Coq/Agda2 ещё проще в теоретическом плане. В Coq товарищи ради прикола сделали реализацию типов классов, не выходя за рамки языка. То же самое я сделал для Agda2 после небольшого количества экспериментов.
А теперь заметь забавную закономерность. Чем проще язык по твоему определению, тем меньше людей им пользуется.
T>Теперь смотрим на Питон. Можно ли выделить минимальное подмножество Питона, на котором можно выразить всё остальное в Питоне? Можем ли мы расширить язык новыми управляющими конструкциями?
1) Думаю, да. Но мне лень, поэтому будем считать, что нет.
2) А оно реально надо? Какая именно управляющая конструкция так помогла darcs? (Тут говорили, что у него вообще какой-то type safe patch application — вот круто! Правда, еще тут говорили, что он падает при перемещении 100 мб файлов в репозитории. Надеюсь, скоро у него будет type-safe file movement, или типа того :-)
thesz, в твоих постах я, недалекий интеллектуальный трус, по твоей характеристике, вижу сквозящую в бэкграунде мысль о том, что хаскель способствует написанию хороших программ. Так ли это? Если да — примеры в студию. Ведь, цитируя тебя самого в похожей ситуации, «ЭТО. НАДО. ДОКАЗЫВАТЬ.». Чтобы тебе было полегче, я, со своей стороны, буду приводить примеры хорошего софта на самом ужасном из существующих языков — на плюсах. Идет?
T>Смотрим на Си, C++, C# или Java. Система типов совершенно не связана с моделью вычислений. В C++ этот отрыв ещё сильней.
Прекрасно. Я что, защищал здесь плюсы?
T>Кто оказывается "реально прост"?
Питон и си. Я много раз уже это писал. Еще CL. Если выкинуть мусор всякой обратной совместимости.
T>Тот, что ты знаешь прямо сейчас и похож на уже знакомое, или то, что ты можешь прогнуть под себя с минимумом усилий после изучения?
T>Синяя и красная пилюли. От того, что ты выберешь, зависит твоя карьера программиста.
Ох как образно! А что выбрал Кнут — хаскель или схему? Блин, забыл!
T>Перечисли стереотипы, которыми я руководствуюсь.
Если человеку не нравиться хаскель, то причина в том, что этот человек слишком туп и труслив, чтобы по-настоящему оценить Язык. Похоже?
T>Мне, что-то, начали надоедать наезды ad hominem.
Отвечай аккуратнее, в таком случае. Я не бросаюсь на людей :-)
P>>>>Проблема хаскеля в том, что он, с одной стороны, высокоуровневый (что хорошо), а с другой — взрывает мозг при попытке хотя бы освоить хороший учебник вроде «Real World Haskell». Потому, что он реально сложен. И это плохо. Конечно, возможно, проблема в моей личной глупости. Но, честно говоря, я, как и все :-) считаю себя above average. T>>>Я считаю себя above average, у меня взрывает мозг при изучении теории типов и я её намеренно изучаю: за взрывом мозга и за расширением сознания. P>>Рад за тебя. Это как-то противоречит моей мысли о том, что такому не место в мейнстриме?
T>Да. Моя мысль вот какая: интеллектуальной трусости не место в мейнстриме.
Отвечай аккуратнее, еще раз. Ты не на митинге, все же :-)
T>В этом нет ничего страшного. Являться тебе в снах и хохотать "ХА-ХА-ХА-ХАСКЕЛЬ!!!" над застывшим в ужасе тобой я не буду.
Жаль, это было бы весело.
T>Поскольку ты уже выбрал свою синюю пилюлю, то и жалеть не о чем.
О Гуру! Научи меня хоть толике своей легендарной чуткости и прозорливости!
pgregory wrote:
> То есть, ты считаешь, что везде о монадах пишут просто для красоты > изложения? Здесь наши взгляды серьезно расходятся.
Не совсем. Просто это не только красивая вещь, но и очень мощная. Чем раньше взорвётся мозг, тем раньше появится пониманипе как это использовать.
Скажем, шаблоны при изучении С++ можно и не рассказывать. Просто сказать, что массив строк будет vector<string>, а массив чисел будет vector<int>. И всё. Но если человеку рассказать о шаблонах, то он сможет применять эту абстракцию в своём коде для облегчения своего труда.
>> > Заодно, сказал раз, скажи и два. Haskell for Dummies, где нет упоминаний >> > о монадах — в студию! > .>А ты мне C for Dummies где нет этой злобной арифметики указателей, о > которую столько копий сломали. > 1) Арифметика указателей злобная, но простая. Она — арифметика.
Не скажи... Далеко не все сразу понимают почему [] и * — почти то же самое и зачем оно нужно так.
> 2) Я первый спросил
Честно говоря — не знаю, я много литературы не читал, не копенгаген.
На самом деле я совершенно не знаю хаскелл, но то что видел — очень впечатляет. Красиво и элегантно. А трудности изучения — лишь следствие традиций и популярности. А так если повспоминать себя давным давно, как, скажем, в школе я осознавал понятие файловой системы (банальное понимание дерева каталогов), или система контроля версий... Вроде простые очевидные понятия сейчас, но ведь и это я когда-то не знал и казалось сложным и непонятным.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, thesz, Вы писали:
T>>>Популярность git определяется Линусом Торвальдсом и ничем другим. P>>Чушь. T>За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом.
Его подхватили, так как его использование в разработке Линукса _автоматически_ означает, что git имеет достаточно неплохой уровень.
На момент создания git'а не было _никаких_ равных ему по скорости систем контроля версий. Т.е. СОВСЕМ никаких, даже Mercurial тогда не мог работать достаточно быстро. Ну и хвалёная алгебра патчей с экспоненциально-тормозным алгоритмом merge'а на практике не особо лучше git'овского merge'а, который just works.
А использование sha-1 указателей для адресации контента и отслеживание изменений между файлами — так это вообще был гениальный штрих в git'е.
T>А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки. T>Популярность git и его язык реализации определяется популярностью Линуса Торвальдса и ничем больше.
А ещё тем, что git работает.
T>"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности. T>Cherry picking, anyone?
Какие проблемы? http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html
T>http://darcs.net/ — багтрекер есть T>http://git-scm.com/ — багтрекера нет. T>Почему так, я не знаю. Но быстро сравнить серьёзность и количество открытых ошибок я не могу.
У них работа идёт в mailing list'ах, так как Линус ненавидит Багзиллу в частности и багтрекеры вообще. http://marc.info/?l=git&w=2&r=1&s=unresolved+issues&q=b — как пример http://marc.info/?l=git&m=120580287718636&w=2
Здравствуйте, pgregory, Вы писали:
P>Чтобы тебе было полегче, я, со своей стороны, буду приводить примеры хорошего софта на самом ужасном из существующих языков — на плюсах. Идет?
Кстати о птичках. Меня как-то человек, изучающий плюсы, спросил, что значит "std::cout << 1". Вот как это на двух пальцах? Без упоминания namespace std, потоков, перегрузки операторов. И ничего, он просто запомнил и пишет.
Уж с do { x <- getLine; putStrLn $ show 1 } я думаю он справится?
И вон на плюсах сколько всего строчат, а такая сложность никого не спугнула. Тут какая-то не та сложность или что-то не сходится?
В общем, я твой пойнт понял, но очень сомневаюсь, что он верен. Надо проверять на неопытных программистах, насколько сложно им будет писать с использованием do Про монады им ни-ни, разумеется.
Здравствуйте, pgregory, Вы писали: P>Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
ООП — это инкапсуляция + наследование + полиморфизм.
А то что ты описал, это АТД.
И когда объясняют на примере яблок и коробок, оно всё на пальцах вроде как понятно, но когда начинают программировать сразу встаёт вопрос что от чего порождать прамоугольник от квадрата или наоборот.
После чего возникают совершенно монструозные леса наследований.
T>>Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо. T>>ЭТО. НАДО. ДОКАЗЫВАТЬ. T>>Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров. T>Пример подойдёт? T>В рабочей папке darcs переместил 8 файлов (~100мб) в другой подкаталог. T>darcs не смог гафиксировать изменения — вывалился по переполнению памяти. T>На борту 2гб, darcs 2.2.1 (release), Win Vista Home.
Отлично.
Что по этому поводу говорят другие системы? Им плохо?
Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, pgregory, Вы писали:
P>>Или ты реально считаешь, что FP так же интуитивно, как и ООП? (Чувствую, как люди с горящими глазами бросились писать «Да! Да! Да!!!» :-) EC>Можно раскрыть тему интуитивности ООП? EC>А то у меня такое ощущение, что его почти никто не понимает (уж пользоваться точно не умеет). EC>Об интуитивности даже речь не идёт.
«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
Side note: я не утверждаю, что ООП сколько-нибудь хорошо аппроксимирует реальность. На этот счет у меня самого к ООП большие претензии. Я утверждаю, что ООП — это просто и на пальцах. Это яблоки и кнопочки.»
Могу даже попытаться немного развить тему. Если все кошки имеют четыре лапы, то и сиамские — тоже. Это наследование. У представителей разных народностей разные способы приветствовать друг друга при встрече, но я могу от этого абстрагироваться, и написать что-то типа: поприветствуйте_друг_друга(человек1, человек2). В зависимости от того, что это за люди, они поприветствуют друг-друга по-разному. Это полиморфизм.
И, разумеется, наследование реализации — зло :-), а инкапсуляция и полиморфизм — отнюдь не уникальная фича ООП.
Здравствуйте, pgregory, Вы писали:
P>«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
Нипаняяяятна. Что такое "у человека есть метод"? Это значит, что человек это умеет делать? А если два человека здороваются, это чей именно метод? Первого или второго? А если десять человек танцуют общий танец?
А кнопку нажали, это метод кнопки, или Человек.НажалКнопкаБыстра? Кнопка ж сама не нажимается, правда?
P>Могу даже попытаться немного развить тему. Если все кошки имеют четыре лапы, то и сиамские — тоже. Это наследование. У представителей разных народностей разные способы приветствовать друг друга при встрече, но я могу от этого абстрагироваться, и написать что-то типа: поприветствуйте_друг_друга(человек1, человек2). В зависимости от того, что это за люди, они поприветствуют друг-друга по-разному. Это полиморфизм.
А почему сиамские наследуются о кошек? Они же просто их подмножество? Что такое наследование, я не понял. Это специализация? Только?
Очень хочу посмотреть на реализацию функции "поприветствуйте_друг_друга(человек_народности_1, человек_народности_2)"
Заодно про мультиметоды расскажешь Тоже на пальцах, конечно.
P>Так вот я думаю. Hope this helps.
Nope
Здравствуйте, pgregory, Вы писали:
P>«Попытаюсь объяснить. ООП — это объекты + сообщения/методы. Простейший способ ООП декомпозиции системы — написать текст, потом заменить существительные на объекты, а глаголы — на методы. (Все, конечно, сложнее, но идею, надеюсь, ты понял). Яблоко — объект. Человек — объект. У человека есть метод «спеть песню». У человека есть состояние. И у яблока есть состояние.
P>Лично я не могу привести таких же аналогий для фп. Можешь попробовать, я буду рад, если это возможно.
P>Side note: я не утверждаю, что ООП сколько-нибудь хорошо аппроксимирует реальность. На этот счет у меня самого к ООП большие претензии. Я утверждаю, что ООП — это просто и на пальцах. Это яблоки и кнопочки.»
P>Могу даже попытаться немного развить тему. Если все кошки имеют четыре лапы, то и сиамские — тоже. Это наследование. У представителей разных народностей разные способы приветствовать друг друга при встрече, но я могу от этого абстрагироваться, и написать что-то типа: поприветствуйте_друг_друга(человек1, человек2). В зависимости от того, что это за люди, они поприветствуют друг-друга по-разному. Это полиморфизм.
Предположим ты это всё рассказал человеку пишущем на C.
Я не понимаю, что он должен извлечь из этого объяснения.
Как это должно повлиять на его способы решения задач?
Здравствуйте, thesz, Вы писали:
T>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других.
Э! Не передергивай! Обсуждается совсем не это. Обсуждается то, что в теории хаскель просто распрекрасен и на голову выше большинства, но на практике мы этого не видим. (Я не утверждаю, что не существует успешных проектов на хаскеле, нет, или областей, где его особенности очень удобны. Я о другом — о том, что (мне) не видно связи между хорошестью хаскеля и хорошестью софта на нем).
Черт побери, если эта связь есть — неужели она загадочна и необъяснима на человеческом языке (и реальных примерах)?
Сотый раз: если это не так — примеры в студию! Только не какие-нибудь упрощалки символьных вычислений. Я слишком глуп для этого, ты же понимаешь. Да и еще, не дай бог, скажу, что там Mathematica куда лучше справляется (зачеркнуто :-). Даже реально хороший музыкальный плейер меня вполне устроит. Или они _все_ покрыты мраком строжайшего секрета и коммерческой тайны?
Здравствуйте, pgregory, Вы писали:
P>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
Я — дилетант в Хаскелле. Хотя монады понял. Про перегруженный оператор ; — очень понятное объяснение, но я понял раньше.
При этом, первые программы на Хаскелл я начал писать не имея НИКАКОГО понимания что такое монада. Написал примитивненький grep под виндой. На проблемы с именами файлов не наткнулся. Теоркатегор и по сей день не знаю.
Как так получилось? Мне крупно повезло, да? А всем остальным обязательно понимать монады и теоркат, чтобы написать на Хаскеле grep?
P>Это моя позиция, и я ее аргументировал. Ясно?
Это — Ваше _убеждение_. До сих пор не заметно, что оно основано на практике. Моя практика этому противоречит. Ясно?
Здравствуйте, Code Digger, Вы писали:
CD>Здравствуйте, pgregory, Вы писали:
P>>Для программирования простых вещей на хаскеле необходимо знать сложное понятие монада. (Посмотри оглавление Real World Haskell, прежде чем возражать, ок?) Это плохо. Ни в одном сколько-нибудь распространенном языке, чтобы оперировать числами, не требуется знать, что такое коммутативное кольцо. (Прежде чем возражать, раздобудь ссылку, это опровергающую, ок?)
CD>Я — дилетант в Хаскелле. Хотя монады понял. Про перегруженный оператор ; — очень понятное объяснение, но я понял раньше.
Это хорошо.
CD>При этом, первые программы на Хаскелл я начал писать не имея НИКАКОГО понимания что такое монада. Написал примитивненький grep под виндой. На проблемы с именами файлов не наткнулся. Теоркатегор и по сей день не знаю.
И это хорошо.
CD>Как так получилось? Мне крупно повезло, да? А всем остальным обязательно понимать монады и теоркат, чтобы написать на Хаскеле grep?
Всем остальным, видимо, монады сэкономили столько времени при написании хорошего софта, что теперь они от нечего делать пишут монадные туториалы :-) А у людей, их прочитавших, тут же загораются глаза, и они кидаются искать у себя в коде монады. Ведь код без монад — не код. Ты сколько нашел, кроме стандартных? Не поделишься результатами применения этого мощнейшего механизма абстракции?
P>>Это моя позиция, и я ее аргументировал. Ясно? CD>Это — Ваше _убеждение_. До сих пор не заметно, что оно основано на практике. Моя практика этому противоречит. Ясно?
Рад, что твоя практика противоречит моей. Когда динозавры вроде меня вымрут, Чистых Функциональных Программистов, наконец-то, никто не будет смущать подобными глупостями. И это хорошо. Я за прогресс!
P>Как приятно отвечать, когда точно знаешь, что оппонент не прав!
О, да. Различать нюансы, рассматривать необычные взгляды — это слишком сложно. Слишком старомодно. Soo 1990ish.
P>>>В этой презентации (от 24 сентября 2005 года) утверждается, что у darcs — 91 контрибьютор, у git — 79. На тот момент. Вот только, согласно википедии, разработка darcs началась на 3 года раньше, чем git'а. На момент презентации git'у было 4-5 месяцев. T>>Это какого darcs? Что на плюсах или на что Хаскеле? P>У тебя, извини, википедия перестала открываться? P>«Darcs evolved out of David Roundy's efforts to design a new patch format for GNU arch in June 2002. These discussions didn't lead to any code being committed to arch, but did lead to his theory of patches. After writing an initial version of darcs in C++, the Haskell version was written in Autumn 2002 and released to the public in April 2003.»
Никому не известный David Roundy с никому не известным Хаскелем выкатился, и приобрёл за два с половиной года 91-го контрибутора. Мегапопулярный Линус с гитом за полгода 79.
Смотрим на сегодняшнюю ситуацию: 652 и 222. Разница в три раза. Приращение в 4,3 раза больше. Знающих Си в десятки, если не в сотни раз больше, чем знающих Хаскель.
Участвующих в развитии не в 10 раз больше, а всего в три-четыре.
Это при мегапопулярности Линуса, Линукса и Си.
P>«The development of Git began on 3 April 2005.[33] The project was announced on 6 April,[34] and became self-hosting as of 7 April.[33] The first merge of multiple branches was done on 18 April.[35] Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second.[36] On 16 June, the kernel 2.6.12 release was managed by Git.[37]» P>И да, если то, что ты писал, оказалось неверным, мне было бы очень приятно, если бы ты не просто скипал это при ответах, а писал что-то типа «да, был не прав» Со своей стороны подобное обещаю.
Пожалуй, я буду вести дискуссию как мне удобней. Со своей стороны гарантирую тебе свободу ведения дискуссии как удобней тебе.
Как сторонник северной этической системы, я не делаю по отношению к другим того, что они не делают по отношению ко мне. И могу делать по отношению к другим то, что они делают по отношению ко мне. Вот, как сейчас.
T>>За три месяца его бы не подхватило такое количество народу, не будь он написан Линусом. P>Возможно. И?
Популярность git определяется популярностью Линуса Торвальдса.
T>>А если кто-то, кроме Линуса, написал бы такое на простых Сях, как написан git, то его бы съели без разделки тушки. P>а) спорно P>б) ни о чем
1) бесспорно. ни один "трезвомыслящий" специалист не будет сегодня связываться с Си в большом и экспериментальном проекте.
2) непосредственно относится к дискуссии. язык реализации "продавлен" авторитетом Линуса и ничем иным.
T>>"Практические по всем" параметрам, как я понимаю, включает в себя и разнообразные возможности. T>>Cherry picking, anyone? T>>Я с него не слезу. P>Зря, очень зря — это заранее проигрышная позиция. P>Для начала, cherry-pick есть и в git, и в hg. Да, безо всяких алгебр. Тупее некуда. P>Но. Цитирую свой первый пост в теме: P>«Уважаемые защитники ФП! Здоровы ли вы? Работали ли вы когда-нибудь с исходным кодом программ? Известно ли вам, что между патчами существуют и _более_ сложные зависимости, чем то, что два патча один за другим модифицируют одно и то же место кода? (И, более того, эти более сложные, неявные, зависимости — правило, а не исключение?) P>До тех пор, пока эта мега-алгебра не сможет разрешать такие зависимости (а этого она не сможет никогда — к слову, она хоть компилируемость программы (хоть на хаскелле) гарантирует при существующем авто-черри-пике?), она будет практически бесполезна. Черри-пик всегда будет операцией, при выполнении которой надо 7 раз подумать. И никакая алгебра тут не спасет.» P>Не согласен?
Самое первое — авточеррипик есть оксиморон. Не бывает авточеррипика, он только ручной.
Второе. Алгебра патчей как раз сделана для того, чтобы была возможность высказывать как можно более общие зависимости между изменениями программы.
Третье, вытекающее из первых двух, и последнее: не согласен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
