Здравствуйте, EvilChild, Вы писали:
E>>Очень мощно утверждать, что C++ "самый слабый ОО язык". Из более-менее мейнстримовых языков множественное наследование для классов поддерживается только в C++ и Eiffel. EC>А как множественное наследование классов связано с ОО? EC>Нследование ортогонально ОО, множественное в особенности.
Если под ОО рассматривать тройку из наследования, инкапсуляции и полиморфизма, то самым непосредственным. И, если нельзя унаследоваться сразу от нескольких классов, то это как раз ограничение для ОО.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
EC>>Наследование ортогонально ОО, множественное в особенности.
E>Если под ОО рассматривать тройку из наследования, инкапсуляции и полиморфизма, то самым непосредственным. И, если нельзя унаследоваться сразу от нескольких классов, то это как раз ограничение для ОО.
Смотри выделенное жирным.
Наследование — это артефакт реализации ОО в конкретных языках.
T>>Никому не известный David Roundy с никому не известным Хаскелем выкатился, и приобрёл за два с половиной года 91-го контрибутора. Мегапопулярный Линус с гитом за полгода 79. T>>Смотрим на сегодняшнюю ситуацию: 652 и 222. Разница в три раза. Приращение в 4,3 раза больше. Знающих Си в десятки, если не в сотни раз больше, чем знающих Хаскель. К>Для меня это звучит странно. Разве можно оценить качество продукта по количеству разработчиков? К>К примеру, знаю я C (haskell, python ... на выбор); что я забыл в исходниках git (darcs, mercurial)?
Я уже немного подустал, поэтому отвечу кратко. Количество разработчиков darcs/git/mercurial примерно позволяет оценить уровень вхождения в произвольный продукт, написанный на конкретной смеси языков.
Функциональность, кстати, почти совпадает, что добавляет остроты в соревнование.
И последнее замечание: количество разработчиков косвенно показывает популярность проекта.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>В рабочей папке darcs переместил 8 файлов (~100мб) в другой подкаталог. T>>>darcs не смог гафиксировать изменения — вывалился по переполнению памяти. T>>>На борту 2гб, darcs 2.2.1 (release), Win Vista Home. T>>Что по этому поводу говорят другие системы? Им плохо? T>SVN отработал без каких-нибудь нареканий и довольно быстро. T>По сети перекинулость только инфа о том, что файлы переместились. T>Hg тоже вполнее нормально отработал. T>При добавлении файлов предупредил меня, что файл >10мб может вызвать проблемы но проблем не было. T>Git был самый быстрый. T>Т.е. из 4х рассматриваемых систем darcs просто не смог выполнить ожидаемого действия.
Ну, что же. bug tracker darcs доступен с его главной страницы.
Признаю, что darcs подкачал.
T>>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других. T>Может быть обсуждаемый вопрос: на Хаскеле обязательно получится много лучше чем у других? T>Не верно, с моей точки зрения, пока не то не другое. T>Я, как бы сторонник Хаскеля, пытаюсь его учить и по маленьку использовать и подвигать. T>Но постоянно натыкаюсь не только на своё незнание/неумение, но и на глюки стандартной библиотеки. T>Всё это победимо и обходимо, можно написать свою работу с файлами как Булат, чуток подпачить регэксры, найти работу с кодировками и двигатся дальше... T>А вот объяснить кому-то что он будет вынужден это делать уже несколько сложнее.
(регэкспы неправильные, их надо по-своему писать, более типобезопасно)
Замечу, что это отнюдь не неподъёмная работа. Надо будет это прояснить как-нибудь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Со скоростью разобрались. T>>>>Оказалось, что "darcs практически убивает по скорости" только git. C>>>Mercurial тоже. T>>Это такое абсолютное утверждение? Исключений быть не может?
К>А в чём собственно состоит исключение? Человек пишет следующее:
Да, не дочитал.
Тем не менее, неужто не может быть исключений?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, EvilChild, Вы писали:
EC>>>Наследование ортогонально ОО, множественное в особенности.
E>>Если под ОО рассматривать тройку из наследования, инкапсуляции и полиморфизма, то самым непосредственным. И, если нельзя унаследоваться сразу от нескольких классов, то это как раз ограничение для ОО. EC>Смотри выделенное жирным.
Имхо, рассуждения об ОО без наследования лишены смысла.
EC>Наследование — это артефакт реализации ОО в конкретных языках.
Такая точка зрения, возможно, имеет право на жизнь. Но мне она не интересна. Для меня ОО это: наследования, инкапсуляции и полиморфизма. Все остальное теоритические изыски.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Это правила поведения в моём блоге внешних комментаторов. T>>Правила RSDN другие. Правил RSDN я, проде, придерживаюсь, нет? RD>Может и придерживаетесь. Только получается так: в своем блоге вы другим какать не разрешаете, а как удобрить RSDN, Вы — первый. Разве не так?
Дорогой друг. Есть такой закон Годвина. Фекальная тема в твоём исполнении вполне тянет на его слабый вариант. Следствие из этого закона очень простое, доступное по ссылке.
RD>>>Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит. T>>За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки. T>>Что изменилось-то? Не развернёшь? RD>Лень разворачивать Но в общих чертах: изменилось железо, улучшились оптимизирующие компиляторы. Впрочем, даже сейчас на C++ писать игры не всегда легко.
Что означает, конечно же, что с ФП это не произойдёт.
RD>>>1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти. T>>Что же это было за утверждение тогда? RD>Подумайте
Разворачивай.
А то мне в голову лезут только нехорошие мысли.
RD>>>1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться. T>>Прошу прощения, но эти проблемы проявляются в инструментах, специально заточенных под такие задачи. В программах на Эрланге, например. Про утечки памяти в C++ легенды ходят. В C# такие же проблемы. RD>Снова рвет мозг на фарш. Что Вы имеете в виду? RD>- То, что Хаскель непригоден для разработки большого софта? (Уж не ересь ли это, уважаемое собрание?) RD>- То, что Эрланг специально заточен так, чтобы в нем появлялись проблемы? (Для многих это будет интересная новость) RD>- Что-то другое?
Сперва хотел сказать "подумай".
Потом решил, что глупость должна быть разъяснена.
Вот разъяснение. Ошибки можно допустить в любом ЯП, где-то это проще, где-то сложней. Даже в Эрланге, заточенном на мощную параллельную обработку, можно создать (не подумав) систему, что на одном ядре работает великолепно, а на двух и более валится по переполнению памяти.
Это специализированный инструмент. Что говорить об инструментах общего назначения?
T>>Про Хаскель мы не уверены, что они не проявятся. А про другие инструменты знаем, что они могут проявится. T>>Другие инструменты — Эрланг, C++ и C#/Java, — можно использовать, а Хаскель нет. T>>Эта логика выше моего понимания. Наверное, в ней используют Maybe Bool вместо Bool. RD>Даже безупречная логика приведет к кривым выводам если она основана на заведомо ложных утверждениях. См. утверждение (2). У тебя там "Хаскель нельзя использовать". А разумнее будет "Не до конца известно, возможно ли использовать Хаскель в подобных по масштабу проектах". Разницу ощущаем? Нет? Go читать про Maybe.
Где же можно почитать про чудесную логику с Maybe Bool, за исключением твоих трёх строчек?
Дело в том, что мы всегда не до конца знаем, можем ли мы использовать тот или иной инструмент в нашем большом проекте. Для всего проекта целиком это, вообще, невозможно для любого инструмента, любой удачности.
Именно поэтому современные проекты представляют смесь целой кучи парадигм, языков и инструментов. Питон, C++, Java, SQL, you name it.
Поэтому твой аргумент супротив Хаскеля работает против любого другого инструмента.
За Хаскель работает аргумент, что если тебе понадобился новый инструмент, то на Хаскеле он реализуем проще.
RD>>>2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек. T>>Вы глупости на голубом глазу не утверждайте, и я тоже стану спокойным. RD>См. выше. Я не трогал Ваши глаза и глупости не утверждал. А вот Вы мои слова перекручиваете и действительно начинаете нести глупости.
"На голубом глазу" — это такое образное выражение.
T>>Утверждения типа "вы пишите такой код, что он ни с чем не интегрируется" и "вот с хаскелем системы на мегабайт пропускной способности не получится" как-то не добавляют конструктивности в беседу. RD>См. выше. И думайте, пожалуйста.
Я не обязан думать. Вообще. И уж никто не заставит меня додумывать за тебя аргументы в твою пользу.
Именно поэтому я всегда разъясняю глупость. Что кто чего лишнего не подумал.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Серебрянопулевость присутствует. Двухкратный прирост производительности наблюдается. FR>2 раза это в пределах колебаний при использовании одного и того же инструмента, мало.
Это консервативная оценка.
По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле.
Против 2 раз никто не поспорит.
ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности.
Ещё замечу, что серебренная пуля Брукса была выдумана в районе макроассемблера S/360 и PL/1. Разница между ними не так уж и высока, примерно два-три раза.
Но PL/1 тоже устранял класс ошибок — распределение регистров и передача параметров.
В историческом контексте "серебренная пуля" смотрится по-другому.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Будь добр, разверни. Я не понимаю, что ты хотел этим сказать. RD выдвинул совершенно бредовый тезис не потрудившись его обосновать. Ты его повторил. T>>Ты думаешь, что повторение глупости переведёт её в разряд истины? Это не совсем так. P>... T>>Поэтому, будь добр, перепиши свой ответ. Оба своих ответа. P>Как бы тебя послать помягче?
Какая интересная сюжетная линия!
P>3 (или уже больше?) человека говорят о том, что ты из поста RD высосал несусветно бредовую мысль, а потом приписал ее своим оппонентам. Ты там как, в порядке?
Мне говорят об этом ровно 2 человека: ты, да сам RD.
Всем остальным всё давно ясно.
P>На всякий случай, процитирую RD: P>
P>1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
Заявление RD по-другому истолковать нельзя. Мне, если честно, уж поднадоело его искать.
P>Герой, ты способен признать, что сказал глупость, а потом ее долго отстаивал?
Ты как-то неправильно переписываешь свои посты.
Вместо аргументации ты просто тиражируешь свою и чужую глупость.
Я не могу тебе этого запретить, но и не могу также толерантно пройти мимо.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Переубеждать у меня не очень получается, я срываюсь, но иногда мне это удаётся. Этим случаям я рад больше всего. P>Рад, что за образом фанатика скрывается что-то человеческое . В принципе, я так и думал. Как я уже писал, буду очень рад быть переубежденным. Только вот чтобы переубедить меня, надо на порядок меньше срываться. И перед ответом пытаться найти в сообщениях мысль автора, а не свою мысль об авторе. И не скипать основные аргументы оппонента при ответе. И... ладно, и это навряд ли сбудется.
Прошу прощения, но я буду отвечать так, как я намерен отвечать. Сорвусь или не сорвусь, это дело третье.
P>>>Не напрягайся так. К чему дурацкие фразы типа T>>>>Тут не сказали, падают ли другие системы. Пока я ответа не получил. P>>>Он не очевиден? Тебе что, факс прислать, где написано «смирись, джедай, darcs хуже git»? T>>Будь добр, ответить на простой вопрос: почему система на Хаскеле, проакчивающая мегабайт в секунду, с нетривиаьлным обновлением базы в 10-100 МБайт, будет работать значительно хуже, чем на других языках? P>«— Вы всегда отвечаете вопросом на вопрос? — Кто вам сказал?»
Видишь ли, другие товарищи потрудились и подтвердили фактами высказывание "darcs хуже git". По крайней мере, в перемещении больших файлов.
Но всё равно остаётся открытым техническое, а не ad hominem обоснование тезиса "система на Хаскеле, проакчивающая мегабайт в секунду, с нетривиаьлным обновлением базы в 10-100 МБайт, будет работать значительно хуже, чем на других языках".
Я отвечаю вопросом на вопрос в случае, когда считаю обращённый ко мне вопрос бессмысленным и когда мне надо вернуть оппонента на стезю обсуждения.
P>Собственно, есть простой тезис. Darcs серьезно уступает git, и его не спасает ни больший возраст, ни хаскель, ни алгебра патчей.
darcs уступает git в области скорости. Вопрос об индивидуальных патчах остаётся открыт.
P>Этот тезис неоднократно и подробно обосновывался. Для многих, этот тезис бросает серьезную тень на хаскель. И вовсе не потому, что, как ты пытаешься это выставить, оппоненты-идиоты отсюда сразу делают вывод о убогости хаскеля! P>А потому, что в ответ никто не говорит простое «на любом языке можно написать ерунду, вот и это тому пример». P>Все, напротив, (и ты в авангарде) стараются доказать, что darcs так же крут, как и хаскель, иначе и быть не может. Это, надеюсь, понятно?
Не совсем. Понятно, как твоё описание ООП. То есть, слова знакомые, фразы построены понятно, а общий смысл теряется.
Начну с того, что именно я говорил, что любой инструмент не совершенен. Что утверждение "на счёт Хаскеля не уверен" просто продолжение рассуждений о любом инструменте.
darcs имеет нечто уникальное, ту самую алгебру патчей, что тяжело реализовать на других ЯП и что всё же даёт ему преимущество в отдельных случаях. Тех самых, что встречаются чаще всего.
И на этом я остановлюсь, пока.
Прошу прощения, что не очень связно.
P>Далее, ты наезжал на каждое подобное обоснование, из чего напрашивается вывод, что ты не согласен, и с твоей точки зрения, darcs лучше git. Ни единого вменяемого аргумента, при этом, приведено не было.
Ты здесь путаешь обсуждение darcs и обсуждение Хаскеля вообще, как средства для больших проектов.
Здравствуйте, thesz, Вы писали:
T>По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле.
Угу, но примерно одинаково по тем же строкам с питоном или окамлом.
T>Против 2 раз никто не поспорит.
Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не
впечатляет.
T>ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности.
Да это преимущество по сравнению с тем же питоном, но с окамлом уже почти нет.
T>Хаскель во многом лучше других инструментов. Аргументы против слабы, так как применимы не только к Хаскелю. Проблемы Хаскеля окупаются высокой производительностью программиста на нём.
Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент.
Здравствуйте, BulatZiganshin, Вы писали:
FR>>Угу только Хаскель не единственный инструмент который повышает производительность программиста
BZ>а какие ещё (кроме утюга и паяльника)?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, BulatZiganshin, Вы писали:
FR>>>Угу только Хаскель не единственный инструмент который повышает производительность программиста
BZ>>а какие ещё (кроме утюга и паяльника)?
FR>Штанга и наркотические грибы.
Может, всё-таки, не грибы, а стимуляторы ЦНС? Кокаин, мета-амфетамин?
T>>По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле. FR>Угу, но примерно одинаково по тем же строкам с питоном или окамлом.
Плотность ошибок меньше?
Для питона надо тесты писать. Как для Лиспа. И это должно сказаться на количестве кода.
T>>Против 2 раз никто не поспорит. FR>Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не FR>впечатляет.
10-тикратном разбросе у одного программиста?
Позволю себе не поверить.
T>>ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности. FR>Да это преимущество по сравнению с тем же питоном, но с окамлом уже почти нет.
У Окамла система типов слабая.
Я думаю, что разница даст о себе знать в ближайшее время. Я тут попробовал на вкус это дело, впечатляет.
Matthias Blume [2] has derived a similar parameterization of arrays in SML, which can express such equality of size constraints. Matthias Blume however cautions one not to overstate the usefulness of the approach because the type system can express only fairly simple constraints: “There is still no type that, for example, would force two otherwise arbitrary arrays to di®er in size by exactly one.”
В статье по ссылке выше рассказывается, как в Хаскеле можно сделать то, что в SML нельзя.
С семействами типов это ещё проще.
Плотность ошибок ещё снизится.
T>>Хаскель во многом лучше других инструментов. Аргументы против слабы, так как применимы не только к Хаскелю. Проблемы Хаскеля окупаются высокой производительностью программиста на нём. FR>Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент.
А что ещё повышает?
А это — то, что повышает, — ортогонально ЯП, или нет?
А если ортогонально, то как же тогда аргумент за Хаскель тоже не аргумент?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>По строкам Java-vs-Haskell примерно 10 раз. Против C++ — 2-10 раз (вообще, в районе где-то 3-4-х, когда пишут не-продакшн код и по прототипу на Хаскеле. FR>>Угу, но примерно одинаково по тем же строкам с питоном или окамлом.
T>Плотность ошибок меньше?
У тебя есть доказательства что она меньше в Хаскеле?
T>Для питона надо тесты писать. Как для Лиспа. И это должно сказаться на количестве кода.
Конечно надо, но даже с тестами у него очень хорошая плотность кода.
К тому же есть подозрения что для Хаскеля тоже не обойтись без тестов в случай длительно
подерживаемого проекта.
T>>>Против 2 раз никто не поспорит. FR>>Угу, но при наблюдаемом 10 кратном разбросе при использовании одного и того же инструмента не FR>>впечатляет.
T>10-тикратном разбросе у одного программиста?
T>Позволю себе не поверить.
В разы запросто, например у меня.
T>>>ФЯ устраняет целый класс ошибок, что положительно сказывается на их плотности. FR>>Да это преимущество по сравнению с тем же питоном, но с окамлом уже почти нет.
..... T>Плотность ошибок ещё снизится.
Все это конечно хорошо, надо почитать.
Но если брать реальный код на сколько процентов он будет короче и насколько надежнее по сравнению
с тем же окамлом, опять таки есть подозрения что очень немного, кроме спицифичных вырожденных случаев
конечно.
T>>>Хаскель во многом лучше других инструментов. Аргументы против слабы, так как применимы не только к Хаскелю. Проблемы Хаскеля окупаются высокой производительностью программиста на нём. FR>>Угу только Хаскель не единственный инструмент который повышает производительность программиста, так что тоже не аргумент.
T>А что ещё повышает?
T>А это — то, что повышает, — ортогонально ЯП, или нет?
То что ортогонально ЯП уже дает колебания близкие к порядку.
Но кроме этого Хаскель не единственный высокоуровневый язык.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, BulatZiganshin, Вы писали:
FR>>>Угу только Хаскель не единственный инструмент который повышает производительность программиста
BZ>>а какие ещё (кроме утюга и паяльника)?
FR>Штанга и наркотические грибы.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, pgregory, Вы писали: P>>С первым не согласен. Continuations — это жесть, по аналогии с монадами. Мне это не нравится. MC>А тут-то что сложного? :xz: Всего лишь побочный эффект cps.
Scheme provides a very powerful control abstraction named call-with-current-continuation. Not only is the name intimidating, but many introductions to its semantics are as well.
По слогам: лично мне continuations кажутся сложными. Я не навязываю тебе свою точку зрения. Я пытаюсь донести, почему я так считаю.
P>>Не знаю, почему, но то, что мне не нравятся сложные языки программирования MC>Такое ощущение, что Вы готовы признать сложным все, выходящее за рамки сегодняшнего мейнстрима. Потому как Ваших критериев сложности яп я пока не понимаю.
Черт, жаль. Значит я плоха объясняю. Как я уже писал, например, CL без мусора обратной совместимости я тоже считаю простым.
Если на неделе появится время, постараюсь собрать свои мысли по поводу сложности и мейнстримности в одно сообщение.
